[has-PR] `vp_formats_supported` server metadata in OpenID4VP underspecified

[Kristina Yasuda]

Clarify that the vp_formats_supported server metadata in OpenID4VP should be expressed as following (PE v2 syntax)

"vp_formats_supported": {

‌ "jwt_vc": {

‌ "alg": [

‌ "ES256K",

‌ "ES384"

‌ ]

‌ },

‌ "jwt_vp": {

‌ "alg": [

‌ "EdDSA",

‌ "ES256K"

‌ ]

‌ },

‌ "mdl_iso_cbor": {

‌ "alg": [

‌ "EdDSA",

‌ "ES256"

‌ ]

‌ }

}

‌

‌

[Michael Jones]

Syntactically, we tend to use names like id_token_signing_alg_values_supported rather than alg.

[Kristina Yasuda]

Something like this? I am ok renaming alg with alg_values_supported

vp_formats_supported": {
‌ "jwt_vc": {
  ‌ "alg_values_supported": [
    ‌ "ES256K",
    ‌ "ES384"
  ‌ ]
‌ },
‌ "jwt_vp": {
  ‌ "alg_values_supported": [
    ‌ "EdDSA",
    ‌ "ES256K"
  ‌ ]
‌ }
}

‌

[Kristina Yasuda]

during Aug-11 SIOP call, comments were made that the above proposed structure is well suited to express alg_values_supported per credential format, since if we have a separate parameters alg_values_supported and formats_supported, it is not clear alg values for which format.

[David W Chadwick]

I think we need a structure similar to this in order to group related metadata items together. Without this structure and having a simple list of metadata items, it becomes impossible to know which of the metadata values go together without having an explosion of property names. For example, two metadata properties, one with two different credential formats supported and one with 3 different crypto algorithms supported does not indicate which credential format supports which of the crypto algorithms. But the nested structure above does do this.

[Kristina Yasuda]

(duplicate of #1572)

[Kristina Yasuda]

PR #270

[Kristina Yasuda]

PR #270 merged