typ in request objects

[Joseph Heenan]

I think JAR (as well as PAR/FAPI1/FAPI2) don’t say anything very explicit about the typ header in request objects.

In the conformance suite I believe the situation is:

• All OP tests: We do not send a typ value in request objects
• All RP tests: We do not do any validation on typ in received request objects

This came up as an interoperability question in Brazil, and it does look like we should probably be doing more validation.

One suggestion would be:

• All OP tests: Try sending each of typ: JWT, typ: oauth-authz-req+jwt and no typ header in request objects (expecting all 3 options to succeed)
• All RP tests: We validate typ is either absent, JWT or oauth-authz-req+jwt

Feedback from the WG is welcome. If we did do this we might need normative text making it clear that OPs have to accept all 3 values.

[Brian Campbell]

"typ":"JWT" is largely meaningless and it seems to get employed mostly just due to cargo cult or copy/paste usage. The conformance suite shouldn’t disallow it, of course, but really shouldn’t be doing things that encourage its use.

‌

[Dave Tonge]

For message signing spec, clients must use "oauth-authz-req+jwt" and servers must reject if not present

[Dave Tonge]

PR for message signing, more discussion for FAPI1 tests

[Brian Campbell]

For message signing spec, clients must use "oauth-authz-req+jwt" and servers must reject if not present

I worry about the interoperability implications of being that strict with it. That media type came along pretty late in the process of developing JAR/rfc9101, which itself was an evolution of the signed request object from OIDC. Consequently some/many implementations don’t use it and don’t require it and need to be lax about not requiring it to facilitate interop.

‌

[Filip Skokan]

As always I concur with Brian.

I think we should

• not mention the use of either JWT or untyped
• at most; say clients should use `oauth-authz-req+jwt` and that servers must accept it (but not restrict them to only accept that type)

As Brian said the type came in very late in the RFC process and existing implementations would have to jump through a lot hurdles to make it the only accepted value, especially given they already have 10 years of OIDC Request Object use and plenty of existing integrations behind them.

I don’t believe there is a likelyhood of either Request Objects being used in other places and likewise other existing assertions being used as Request Objects so the only objective would be interop here. should for the client gives way for existing client implementations to work and certify regardless of the type (albeit with a warning if it’s not oauth-authz-req+jwt) while the servers probably already accept the type we’d say they must accept?

@Brian Campbell wdyt?

[Brian Campbell]

As usual, I concur with Filip. And, as usual, he articulated the reasoning better than I.

[Joseph Heenan]

I don’t believe there is a likelyhood of either Request Objects being used in other places and likewise other existing assertions being used as Request Objects

I think I’d like to challenge that a little bit - there’s a pretty thin line between a request object and a private_key_jwt client assertion, so I think there is a security aspect. (Adding ‘typ’ to just the request object doesn’t particularly help with that case of course.)

That doesn’t necessarily change the conclusion that it might be a step too far though. Particularly as I think the security concern doesn’t really apply in FAPI2 when the request object isn’t in the front channel.

[Brian Campbell]

There are some pretty thin lines and subtleties in all this that we could quibble about but looking at it overall it doesn’t seem like requiring explicit typing of the request object now adds any meaningful security but it would hamper interoperability. So the conclusion that it’s a step too far seems correct.

[Filip Skokan]

there’s a pretty thin line between a request object and a private_key_jwt client assertion

If I recall the subtleties correctly, JWT Client Auth assertion has a REQUIRED sub claim which is not present in a Request Object. So a Request Object cannot be used as a JWT Client Auth assertion and JWT Client Auth assertion cannot be used as Request Object because it clearly lacks all the Authorization Request parameters. While the validation rules are not 100% exclusive the likelyhood that a non-Request Object JWT has the necessary Authorization Request parameters is bordering on 0.

‌

[Joseph Heenan]

If I recall the subtleties correctly, JWT Client Auth assertion has a REQUIRED sub claim which is not present in a Request Object.

Exactly, except I would word as is “sub claim which is not INTENDED to be present in a Request Object with the value being the client_id”. (We have a check in the conformance suite to fail clients that do include it in the request object, and I’m pretty certain we’ve seen clients fail that check.)

[Joseph Heenan]

Dima asked me about this so it would be good to discuss this on a WG call soon.

I think we’d had some discussion about what we should say in the spec, but not really any clarify about how the conformance tests should work (which may be different between FAPI1 & FAPI2).

The minimum concern is that clients feel it’s okay to send oauth-authz-req+jwt and I think clients are actually sending JWT as well, but we’re not testing servers to require that these values are accepted.

A reminder that the current situation for testing is:

• All OP tests: We do not send a typ value in request objects
• All RP tests: We do not do any validation on typ in received request objects

My original proposal was:

‌

• All OP tests: Try sending each of typ: JWT, typ: oauth-authz-req+jwt and no typ header in request objects (expecting all 3 options to succeed)
• All RP tests: We validate typ is either absent, JWT or oauth-authz-req+jwt

Are people okay with these, or are there alternative suggestions that would solve the interoperability issues we’re seeing in FAPI1/FAPI2 ecosystems?

[Dima Postnikov]

Thanks Joseph,

I enjoyed reading the thread ;-)

Some comments from me:

1. The question came up because an OP didn’t not accept a typ of oauth-authz-req+jwt or potentially typ with any value..

‌ IMO, at least we should be clear that OP “shall accept typ”. Joseph has it covered by his proposal.

2. RFC9101 implies that there is a security benefit of explicitly typed request objects at least in some scenarios for some attacks. If these are applicable to FAPI ecosystems, perhaps we should say “Client should send type of oauth-authz-req+jwt“. If ecosystems feel strong about it, they could profile it to “shall“.
3. It could also help if the formal proofing of message signing specification provides recommendation too.

‌