JARM response contents clarifications

[Joseph Heenan]

I'm trying to prototype some tests for JARM but I'm not 100% clear on the meaning on the spec:

1) Can servers optionally return nbf/iat (they're not mentioned in JARM spec) in the response JWT?

1a) If they can, must those values by valid as per normal JWT rules for nbf/iat?

2) Can servers return other claims in the response JWT or would that be an error or warning? (e.g. returning ‘sub', 'c_hash’ or 'nonce' claims would seem to indicate the server is not really doing the right thing)

3) Is 'kid' a MUST in the header? The text seems to imply so with explicit mentions of kid.

4) Is it an error for a server to return (say) state in the normal query parameters (i.e. returning state both inside and outside the JWT)?

5) It is mandatory for clients to supply ‘state' when using JARM [and scope=openid]? The spec reads like it is required, but ‘state’ is not generally required in FAPI-RW.

‌

(raised as a bug as I suspect it may turn out to be worth clarifying some of these in the spec)

[Torsten Lodderstedt]

1)

nbf does not hurt but is (in my impression) rarely used nowadays.

iat does not hurt but would only make sense for auditing purposes.

2)

Everything that’s not standard JWT metadata should result in a warning.

3)

I think that was not the intention as a kid is not required in the simplest case of just a single key.

@Brian Campbell do you agree?

4) yes, that’s an error since it renders the mechanism useless.

5) well, PKCE and nonce would work as well. We haven’t really come up with a consistent concept on what security measures we consider a MUST and which are equivalent and can substitute each other. So for a first attempt, I would recommend to make the state parameter mandatory.

[Brian Campbell]

IMHO based on the general guidance in JOSE/JWT/OAuth/OIDC that unrecognized things should/must be ignored:

1) yes and 1a) yes

2) yes (I suppose a warning for things that are known to not make sense would be okay though)

3) The intent, I think, was that kid is required only when there’s more than one key that would work in the given context. Perhaps an explicit pointer to https://openid.net/specs/openid-connect-core-1_0.html#SigEnc would be good. I kinda thought we had that already but apparently not.

4) not an error (but a warning might be okay)

5) JARM doesn’t add any additional constraints on the authorization response (or request for that matter) parameters. "state" is required only if the "state" parameter was present in the client’s authorization request. And "state" is optional in the authorization request. And JARM doesn’t say anything about scope (so no, scope=openid is definitely not required).

‌

‌

‌

‌

[Joseph Heenan]

Thanks Brian and Torsten! Both for responding and for largely agreeing

Seems to be disagreement on ‘4' on whether it’s a warning or an error. My personal opinion is that it’s probably an error; the intent of JARM really does seem to be that if the server returns something it should be inside the signed/encrypted package. Returning the authorization code outside of the encrypted JWT would definitely be an error in my opinion. (It’s probably more important in client tests where the client mustn’t use things outside the signed object, but I’m not even thinking about client tests for JARM yet.)

Note that (assuming my understanding is correct) when using JARM without scope=openid, ‘state’ is mandatory due to https://openid.net/specs/openid-financial-api-part-1-ID2.html#public-client (which also applies to confidential clients). [I’m currently only considering FAPI-RW + JARM; whether there’s any appetite for non-FAPI JARM tests I have no idea.]

[Dave Tonge]

Tosten will check what improvements can be made to the spec, e.g. to make it clear that kid isn’t required.

[Joseph Heenan]

I’ve opened https://bitbucket.org/openid/fapi/issues/270/jarm-fapi-rw-openid-client-session-binding to discuss the state issue in more detail. I think it may well need a change in FAPI-R or RW.

‌

[Brian Campbell]

There’s been no activity on this in over two years. Can we close?

FWIW, I did check to see if the OIDC section about jwks and kids etc is mentioned and it is. I noticed some other issues with recently broken references, which https://bitbucket.org/openid/fapi/pull-requests/323 should fix.

[Joseph Heenan]

I think it can be. I probably still need to implement checks in certification that nbf/exp are valid if present, but I guess I’ll also need to do another pass through the spec to check the certification tests are aligned to any changes made since I first implemented it.

[Brian Campbell]

thanks Joseph, marking this one as resolved