openid
Require JAR typ value to be used in request objects
https://www.rfc-editor.org/rfc/rfc9101.html defines a typ value to be used in the header of request objects, oauth-authz-req+jwt, but doesn't go as far as requiring it to be used, offering various cases where it can be omitted or the value JWT used instead for historical compatibility. But does say:
requiring explicit typing would be a good idea for new OAuth deployment profiles where compatibility with existing deployments is not a consideration.
Given any existing code or deployments is going to need a large number of changes to become a wallet or verifier, there doesn't seem to be any need for historical compatibility with existing deployment - hence it would be a "good idea" for VP to require explicit typing of request objects, and that should ensure there's never any possibility that request objects are confused with any other kind of object.
I suggest we add text along the lines:
Verifiers MUST include the
typheader in request objects with the value defined in RFC9101,oauth-authz-req+jwt. Wallets MUST reject request objects where thetypheader is not present or does not have the valueoauth-authz-req+jwt
(Mentioned by Kristina, as I believe this caused an interoperability problem for someone testing with the conformance suite - the conformance suite currently doesn't send the typ header as it's not required by the spec.)
This seems quite reasonable.
But if the quite reasonable premise that "any existing code or deployments is going to need a large number of changes to become a wallet or verifier, there doesn't seem to be any need for historical compatibility with existing deployment" is accepted as true, then there's no reason for the special treatment of "federation" in https://github.com/openid/OpenID4VP/pull/263
and never forget https://bitbucket.org/openid/fapi/issues/705/conformance-testing-for-typ-in-request
