spec requires requested_expiry be a string in the signed request object

[Joseph Heenan]

I’m not necessarily suggesting any change here, but do want to draw attention to this in case others missed it (as myself and a vendor both read the spec wrongly I believe).

When using a signed request object, the current spec requires that requested_expiry is passed as a string:

A signed authentication request is made by encoding all of the authentication request parameters as claims of a signed JWT, with each parameter name as the claim name and its value as a JSON string.

(from section https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-02.html#signed_auth_request - emphasis mine).

It might be worth at least updating the example to include requested_expiry to highlight this, particular as it’s different to max_age in an OIDCC request object, which is passed as a JSON number.

[Joseph Heenan]

The same clause might also possibly result in an undesirable outcome for parameters added by profiles that contain JSON (or at least mean they need to include some extra verbiage to make sure they don’t get caught by that clause) as it would (in my opinion) be more idiomatic to include them as JSON objects rather than escaping the JSON and including it as a string.

[Joseph Heenan]

Discussed on today’s call, seemed to be agreement for two options:

1. Make sure it’s clear that JSON type parameters can be used directly in extension profiles (i.e. they don’t have to be encoded as JSON strings)
2. Add an example that shows max_age encoded correctly as a string

[Brian Campbell]

I’m fine if requested_expiry is a number too. It’s not a big deal TBH.

[Bjorn Hjelm]

dav

[Dave Tonge]

A signed authentication request is made by encoding all of the authentication request parameters as claims of a signed JWT, with each parameter name as the claim name and its value as a JSON string.

Suggested text:

A signed authentication request is made by encoding all of the authentication request parameters as claims of a signed JWT, with each parameter name as the claim name and its value as a JSON string or number.

Plus suggest adding the following line:

An extension or profile may define additional authentication request parameters, these do not need to be JSON strings or numbers.

‌

‌

[Dave Tonge]

“with the exception of requested_expiry which may be sent as a JSON string or JSON number, OP must accept either type”

“these may be defined to be any JSON type”

[Dave Tonge]

Allow requested expiry to be sent as a number

Fixes #159

→ <<cset ede399dd0e6c>>

[Dave Tonge]

https://bitbucket.org/openid/mobile/pull-requests/71/allow-requested-expiry-to-be-sent-as-a/diff

[Brian Campbell]

Merged in i159 (pull request #71) to fix issue #159

Allow requested expiry to be sent as a number

→ <<cset 7a4da06fca36>>