typ in the Request Object?

[Nat Sakimura]

Brock Allen in the OAuth WG (May 7, 2020) that:

1. When decoded, all the JWT samples are missing the "typ" claim from the header, which I think should be "oauth.authz.req+jwt".
2. When validating the JAR if we are to validate the "typ" then this would be incompatible with OIDC's request object, I think?
3. When the JAR is passed by reference, then the HTTP response Content-Type of "application/oauth.authz.req+jwt" would also seem to break or be incompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing this w/ an OIDC OP implementation. 

‌

Draft -23 of OAuth JAR https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23

has implemented the Content-Type but has not done so for “typ” claim as we thought it came in way too late and it may be breaking the compatibility with the Connect too much.

Please discuss.

Also, should we try to back-port these?

[Filip Skokan]

I think the ship has sailed on adding “typ” checking to Request Object validation. If the OAuth WG wants to keep OIDC implementations working that is.

The requirements for a request object are also very unlikely to match any existing JWT profile.

[Joseph Heenan]

I’d probably be in favour of adding the typ header but only recommending clients use it at this stage. Servers would be required to reject objects with incorrect typ, but should accept objects with no typ for backwards compatibility.

That feels like a move in the right direction, and at least is not a Big Bang breaking change?

It’s based on an assumption that most OIDC OP implementations currently won’t reject requests objects that have a typ header though, and I’m not sure how good an assumption that is.

I also wonder if we should have an explicit conformance test that verifies that a request object isn’t accepted by an AS as a valid client assertion. In theory no one should fail that test, but I’ve said that about other tests before and been wrong…

‌

[Nat Sakimura]

Requiring typ does not seem to have security advantage as ID Toekn etc. and Request Object is very different.

‌

[Michael Jones]

Per the 4-Jun-20 Connect call, we don’t think that adding this would provide sufficient additional security value to add it at this time.

[Torsten Lodderstedt]

I think adding the typ would allow to distinguish OIDC and OAuth request objects. That would mean running both in parallel should be easier. Am I wrong?

[Michael Jones]

Closing, per the decision on the 4-Jun-20 working group call