openid / OpenID4VP

56 stars 20 forks source link

algs vs vp_formats_supported #53

Closed tlodderstedt closed 7 months ago

tlodderstedt commented 1 year ago

PE defines the format element of an input_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.

Sakurann commented 7 months ago

related/almost duplicative of #136.

selfissued commented 7 months ago

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.

peppelinux commented 7 months ago

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

tplooker commented 7 months ago

Closing in favour of #136

peppelinux commented 6 months ago

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.