Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require JAR typ value to be used in request objects #268

Open
jogu opened this issue Sep 20, 2024 · 2 comments · May be fixed by #355
Open

Require JAR typ value to be used in request objects #268

jogu opened this issue Sep 20, 2024 · 2 comments · May be fixed by #355

Comments

@jogu
Copy link
Collaborator

jogu commented Sep 20, 2024

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.)

@bc-pi
Copy link
Member

bc-pi commented Sep 20, 2024

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 #263

and never forget https://bitbucket.org/openid/fapi/issues/705/conformance-testing-for-typ-in-request

@babisRoutis
Copy link

@jogu 👍

jogu added a commit that referenced this issue Nov 30, 2024
@jogu jogu linked a pull request Nov 30, 2024 that will close this issue
jogu added a commit that referenced this issue Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants