[OpenID4VP] normative language about client_id_scheme `redirect_uri`

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1995

Original Reporter: peppelinux

In the section “Verifier Metadata Management“ we read:
”
redirect_uri: This value indicates that the Verifier's redirect URI is also the value of the Client Identifier. In this case, the Authorization Request MUST NOT be signed, the Verifier MAY omit the redirect_uri Authorization Request parameter, and all Verifier metadata parameters MUST be passed using the client_metadata or client_metadata_uriparameter defined in (#vp_token_request)
”

This specification doesn’t give any clarification about why a request that uses the redirect_uri must not be signed, moreover this constraint reduces the security of the solution, since it should be at the will of the involved parties.

there are cases where the requirement of the non-repudiability of the requests using cryptographic mechanisms, is defined in a trust model regulation, making this sentence an important issue for the implementers.

For these reasons I ask to remove that constraint or change to SHOULD NOT with the explanation about it should no be signed.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

The reason why Authorization Request must be signed when client_id = redirect_uri is because there is no way to obtain the keys to validate such signature and no way to establish trust in the redirect_uri. client_id = redirect_uri option is meant for the scenarios when the high security is not needed, and it is more suitable for testing/PoC, rather than production.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

assuming that a redirect_uri is equal to the entity id of a client (client_id) there comes to my mind at least three ways to obtain the keys to validate such signature:

‌

1. oidc federation discovery, where the .well-known/openid-federation is appended to the client_id/redirect_uri
2. .well-known/jwt-issuer as proposed within vcstuff
3. by giving an x5c (or x5u…) within the signed request and have in the x.509 certificate the SAN/CN equal to the client_id

‌

I fully agree with you about that’s more suitable for testing/PoC rather than production, then, If my previous assumptions are wrong I’d simply suggest to give some explanatory text. While, if my assumptions makes sense, we should wonder if it would be better to remove that normative language that prevents the use of signed requests

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I think there is a certain benefit to having an option when there is no expectations for the request to be signed, so maybe let’s start with adding more explanation on this one? (btw I am happy to be convinced that keeping an unsigned option is a bad idea and that this might turn out to be a security hole like alg = none…)

for option1 and option3 you outline, we already have separate client_id_schemes defined. for option2, I agree with you it would be a good idea to define a new client_id_scheme :)

[tlodderstedt]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

assuming that a redirect_uri is equal to the entity id of a client (client_id) there comes to my mind at least three ways to obtain the keys to validate such signature:

‌

1. oidc federation discovery, where the .well-known/openid-federation is appended to the client_id/redirect_uri
2. .well-known/jwt-issuer as proposed within vcstuff
3. by giving an x5c (or x5u…) within the signed request and have in the x.509 certificate the SAN/CN equal to the client_id

‌

I fully agree with you about that’s more suitable for testing/PoC rather than production, then, If my previous assumptions are wrong I’d simply suggest to give some explanatory text. While, if my assumptions makes sense, we should wonder if it would be better to remove that normative language that prevents the use of signed requests

‌

All the option you list are supported by distinct client id schemes (including signed requests). So I fail do understand why the current definition of the redirect_uri client id scheme prevents you from doing what you want to do. Can you please explain?

[mdobrinic]

The text in the current draft (version 1.0 - Draft 20) says this: redirect_uri: This value indicates that the Verifier's redirect URI is also the value of the Client Identifier. In this case, the Authorization Request MUST NOT be signed, the Verifier MAY omit the redirect_uri Authorization Request parameter, and all Verifier metadata parameters MUST be passed using the client_metadata or client_metadata_uri parameter defined in [Section 5](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#vp_token_request).

Note: the Authorization Request MUST NOT be signed

I agree with the aforementioned idea of explaining why a signed request would not add extra security (because I don't understand it :) ), as well as I'd like to propose to remove that hard MUST NOT requirement from the spec.

I also agree with peppelinux, there are ways to obtain the verification key from a more-or-less trustworthy location (as in that the location can be verified against the web-origin of the redirect_uri value, or federation/TLS cert).

One reason to remove the MUST NOT is consistency with how JAR can be used for the verifier. We would like to support the redirect_uri scheme and stick with JAR for now, instead of having to read the parameters from the querystring.

[Sakurann]

a small PR clarifying why the request does not have to be signed seems appropriate.