Closed tlodderstedt closed 7 months ago
related/almost duplicative of #136.
Supported algorithms are communicated in the metadata. Doing so in PE parameters would be duplicative.
As a design principle, we should support functionality in one way, to improve interoperability.
Over a year ago, we opened an issue regarding the specific parameters that should be included within the client metadata. I propose that we address this issue in conjunction with finalizing the contents of the client metadata.
My concern centers on the placement of the presentation_definition outside the metadata. Given that metadata can be conveyed through various means—within the request, via OpenID Federation (trust chain), or through a third party (also signed by a trusted third party)—locating it within the metadata allows for governance through metadata policies. It also facilitates distribution via trusted lists or public endpoints, such as well-known URLs.
While I am not opposed to including the presentation_definition in the HTTP request, I advocate for a comprehensive approach to defining client metadata, which would encompass the presentation_definition as part of the metadata.
see also: https://github.com/openid/OpenID4VP/issues/136#issuecomment-2067398887
Closing in favour of #136
I report here a comment given in issue #53
Over a year ago, we opened https://github.com/openid/OpenID4VP/issues/17 regarding the specific parameters that should be included within the client metadata. I propose that we address this issue in conjunction with finalizing the contents of the client metadata.
My concern centers on the placement of the presentation_definition outside the metadata. Given that metadata can be conveyed through various means—within the request, via OpenID Federation (trust chain), or through a third party (also signed by a trusted third party)—locating it within the metadata allows for governance through metadata policies. It also facilitates distribution via trusted lists or public endpoints, such as well-known URLs.
While I am not opposed to including the presentation_definition in the HTTP request, I advocate for a comprehensive approach to defining client metadata, which would encompass the presentation_definition as part of the metadata.
PE defines the
format
element of aninput_descriptor
as the place to convey the signature/protection algorithms a verifier supports. We decided to profile PE in OID4VP to use the client metadata mechanism for this purpose. It felt right at that time, as it is inline with the was metadata is managed and used in OAuth and OpenID Connect where the metadata is set up in advance.Experience shows that in the typical case, the metadata in OID4VP is exchanged as part of the presentation request (as there is no pre-registration with the wallet). This means we pass this data in the request, just in a different parameter that we introduced for that purpose (vp_formats_supported). I don't see an advantage over the PE approach, but the PE approach is more flexible (as the alg can be determined per requested credential).
I suggest to consider using the PE approach. Whether we keep the vp_formats_supported approach is another discussion point. Given that dropping it would be a breaking change, we might allow both.