Require JAR typ value to be used in request objects

[jogu]

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]

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

[bc-pi]

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