You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 typ header in request objects with the value defined in RFC9101, oauth-authz-req+jwt. Wallets MUST reject request objects where the typ header is not present or does not have the value oauth-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.)
The text was updated successfully, but these errors were encountered:
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 #263
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 valueJWT
used instead for historical compatibility. But does say: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:
(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.)The text was updated successfully, but these errors were encountered: