[OpenID4VP] normative language about client_id_scheme `redirect_uri`

[Giuseppe De Marco]

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.

[Kristina Yasuda]

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.

[Giuseppe De Marco]

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

‌

[Kristina Yasuda]

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

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP