Clarification on Request URI response

[KiruthikaJeyashankar]

Description

Requesting clarification on whether the request_uri response can be an unsigned JWS or if it is required to be signed.

Use Case

For clients using the redirect_uri prefix, signed requests are not supported. In this scenario, is reference mode using request_uri achievable with an unsigned request_uri response?

Example JWT header:

{
  "alg": "none"
}

Example JWS:

eyJhbGciOiJub25lIn0./*Payload in B64 encoded form*/.

References

The following references indicate that the request_uri response is expected to be signed:

OpenID4VP — Request URI Response

The Request URI response MUST be an HTTP response with the content type application/oauth-authz-req+jwt and the body being a signed, optionally encrypted ([OpenID4VP ref](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-5.10.1-1)).

RFC 9101 — Authorization Request Object

The Authorization Request Object MUST be one of the following:
(a) JWS signed
(b) JWS signed and JWE encrypted
([RFC 9101 ref](https://www.rfc-editor.org/info/rfc9101/#section-5-7))

Based on these requirements, clarification is requested on whether an unsigned request_uri response is permitted or if signing is mandatory.

[c2bo]

relevant discussion: #392

[KiruthikaJeyashankar]

Hello @jogu

We checked out the discussions around issue #392 and related topics, we understand that the working group intend to allow a request object that does not have a cryptographic signature while still using the JWT structure required by the specification for Client ID prefixes that allow unsigned requests.

We would highly appreciate confirmation on the following behavior:

1. Unsigned JWT Request Objects (alg: none): Is it fully compliant for a Verifier to serve an unsigned JWT (alg: none) via request_uri if the utilized client_id_prefix (e.g., redirect_uri: or an allowed pre-registered:) allow unsigned requests?
2. Wallet Validation:
   • When a Wallet fetches a request object using a prefix that allows unsigned requests, and require_signed_request_object is omitted or false, should the Wallet explicitly accept alg: none, bypass the cryptographic signature check, and proceed?
   • Conversely, If a Wallet declares require_signed_request_object=true in its metadata, does this effectively make the redirect_uri: prefix and by request_uri combinable unacceptable? (Since the metadata demands a signed object, but the redirect_uri: specification rules state the request object must not be signed).
3. typ Header Requirement: Even when a request object is unsigned (alg: none), does the requirement to include typ: oauth-authz-req+jwt (per Section 5.2) strictly apply? Should Wallets continue to reject the request if this header is missing or incorrect?

Thanks!