Verifier uses parameter `vp_formats_supported` instead of `vp_formats`

[gmulhearn]

relates to https://github.com/openwallet-foundation/credo-ts/issues/2070

I might be wrong in my interpretation of the spec, but i'm finding that credo 0.5.13 verifiers are returning vp_formats_supported in the JAR JWT request, rather than vp_formats.

it's a minor issue, but my reading comes from the following portion of the spec:

The Verifiable Credential and Verifiable Presentation formats supported by the Wallet should be published in its metadata using the metadata parameter vp_formats_supported (see Section 9). The formats supported by a Verifier may be set up using the metadata parameter vp_formats (see Section 10.1). The Wallet MUST ignore any format property inside a presentation_definition object if that format was not included in the vp_formats property of the metadata.

i.e. vp_formats_supported is a wallet metadata param, and vp_formats is a client metadata param.

Further, they specify that vp_formats is REQUIRED in the client metadata: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-10.1

REQUIRED. An object defining the formats and proof types of Verifiable Presentations and Verifiable Credentials that a Verifier supports. For specific values that can be used, see Appendix B. Deployments can extend the formats supported, provided Issuers, Holders and Verifiers all understand the new format.

Credo 0.5.13 example e.g. eyJraWQiOiJkaWQ6a2V5OnpEbmFlZkV6SldYV0JTR1hYanFZYzYxSldXUHU3c2FSMkVMOWQxcXl2QXk4ZUt2cngjekRuYWVmRXpKV1hXQlNHWFhqcVljNjFKV1dQdTdzYVIyRUw5ZDFxeXZBeThlS3ZyeCIsImFsZyI6IkVTMjU2IiwidHlwIjoiSldUIn0.eyJyZXNwb25zZV90eXBlIjoidnBfdG9rZW4iLCJjbGllbnRfaWQiOiJkaWQ6a2V5OnpEbmFlZkV6SldYV0JTR1hYanFZYzYxSldXUHU3c2FSMkVMOWQxcXl2QXk4ZUt2cngiLCJjbGllbnRfaWRfc2NoZW1lIjoiZGlkIiwicmVzcG9uc2VfdXJpIjoiaHR0cHM6Ly83NzhjNGZhODU4Yzkubmdyb2suYXBwL3Npb3AvYzAxZWEwZjMtMzRkZi00MWQ1LTg5ZDEtNTBlZjNkMTgxODU1L2F1dGhvcml6ZSIsInJlc3BvbnNlX21vZGUiOiJkaXJlY3RfcG9zdCIsIm5vbmNlIjoiNjExNDM3MjUzOTI4MTkyNjEwMjMyMTk5Iiwic3RhdGUiOiIxMTI3NTMyNTU5NTQ2NjAzNDY4OTY3NTY3IiwiY2xpZW50X21ldGFkYXRhIjp7ImNsaWVudF9pZCI6ImRpZDprZXk6ekRuYWVmRXpKV1hXQlNHWFhqcVljNjFKV1dQdTdzYVIyRUw5ZDFxeXZBeThlS3ZyeCIsInBhc3NCeSI6IlZBTFVFIiwicmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkIjpbInZwX3Rva2VuIl0sInN1YmplY3Rfc3ludGF4X3R5cGVzX3N1cHBvcnRlZCI6WyJkaWQ6a2V5IiwiZGlkOmp3ayIsImRpZDp3ZWIiXSwidnBfZm9ybWF0c19zdXBwb3J0ZWQiOnsibXNvX21kb2MiOnsiYWxnIjpbIkVkRFNBIiwiRVMyNTYiLCJFUzI1NksiXX0sImp3dF92YyI6eyJhbGciOlsiRWREU0EiLCJFUzI1NiIsIkVTMjU2SyJdfSwiand0X3ZjX2pzb24iOnsiYWxnIjpbIkVkRFNBIiwiRVMyNTYiLCJFUzI1NksiXX0sImp3dF92cCI6eyJhbGciOlsiRWREU0EiLCJFUzI1NiIsIkVTMjU2SyJdfSwibGRwX3ZjIjp7InByb29mX3R5cGUiOlsiRWQyNTUxOVNpZ25hdHVyZTIwMTgiLCJFZDI1NTE5U2lnbmF0dXJlMjAyMCJdfSwibGRwX3ZwIjp7InByb29mX3R5cGUiOlsiRWQyNTUxOVNpZ25hdHVyZTIwMTgiLCJFZDI1NTE5U2lnbmF0dXJlMjAyMCJdfSwidmMrc2Qtand0Ijp7ImtiX2p3dF9hbGdfdmFsdWVzIjpbIkVkRFNBIiwiRVMyNTYiLCJFUzI1NksiXSwic2Rfand0X2FsZ192YWx1ZXMiOlsiRWREU0EiLCJFUzI1NiIsIkVTMjU2SyJdfX19LCJwcmVzZW50YXRpb25fZGVmaW5pdGlvbiI6eyJpZCI6IjBkOWJjZDNlLTRlN2MtNGRmYy1iZTgxLTQ0MzY3ZGJiNWVkMiIsImlucHV0X2Rlc2NyaXB0b3JzIjpbeyJpZCI6ImZmMzJlYTYyLTRiOTUtNGIwZC1hYWYyLWUxMzM2ODkyZTNiNyIsImNvbnN0cmFpbnRzIjp7ImxpbWl0X2Rpc2Nsb3N1cmUiOiJwcmVmZXJyZWQiLCJmaWVsZHMiOltdfSwibmFtZSI6IlByZXNlbnQgYW55IGNyZWRlbnRpYWwiLCJwdXJwb3NlIjoiQ3JlZGVudGlhbCB0byBiZSBkaXNwbGF5ZWQifV19LCJpc3MiOiJkaWQ6a2V5OnpEbmFlZkV6SldYV0JTR1hYanFZYzYxSldXUHU3c2FSMkVMOWQxcXl2QXk4ZUt2cngiLCJzdWIiOiJkaWQ6a2V5OnpEbmFlZkV6SldYV0JTR1hYanFZYzYxSldXUHU3c2FSMkVMOWQxcXl2QXk4ZUt2cngiLCJhdWQiOiJodHRwczovL3NlbGYtaXNzdWVkLm1lL3YyIiwiZXhwIjoxNzMxMzYzMjA1LCJuYmYiOjE3MzEzNjMwODUsImlhdCI6MTczMTM2MzA4NSwianRpIjoiMGY5YzI3NDktZDc0Ni00YzBjLWJjZDgtZmNlZGE0Y2RlMjlhIn0.KZNY8AGI2HdBKoLkmTR2-o4slZEj1PY7uPhdO90Oomwm4iIRR7RYnmLwhUGz5XP68zII0qg7PfFhwdIAkZ2n2g

{
  "response_type": "vp_token",
  "client_id": "did:key:zDnaefEzJWXWBSGXXjqYc61JWWPu7saR2EL9d1qyvAy8eKvrx",
  "client_id_scheme": "did",
  "response_mode": "direct_post",
  "client_metadata": {
    "client_id": "did:key:zDnaefEzJWXWBSGXXjqYc61JWWPu7saR2EL9d1qyvAy8eKvrx",
    "passBy": "VALUE",
    "response_types_supported": [
      "vp_token"
    ],
    "subject_syntax_types_supported": [
      "did:key",
      "did:jwk",
      "did:web"
    ],
    "vp_formats_supported": {
      ..
    }
  },
  "presentation_definition": {..},
  "iss": "did:key:zDnaefEzJWXWBSGXXjqYc61JWWPu7saR2EL9d1qyvAy8eKvrx",
  "sub": "did:key:zDnaefEzJWXWBSGXXjqYc61JWWPu7saR2EL9d1qyvAy8eKvrx",
  "aud": "https://self-issued.me/v2",
  "exp": 1731363205,
  "nbf": 1731363085,
  "iat": 1731363085,
  "jti": "0f9c2749-d746-4c0c-bcd8-fceda4cde29a"
}

[TimoGlastra]

If you look at draft 21 of the spec it's still vp_formats_supported.

Credo doesn't support draft 22 yet (but will soon, we'll probably add both in that case)

https://openid.net/specs/openid-4-verifiable-presentations-1_0-21.html

[gmulhearn]

hey, the quotes i linked are still the same in draft 21 i believe. draft 21 seems to state that vp_formats_supported is for "wallet metadata" where as vp_formats is for "client metadata" (verifier). and the examples of auth requests they show use vp_formats in the client_metadata

[TimoGlastra]

Apologies i looked too quick. So we should just change vp_formats_supported to vp_formats in the request?

[gmulhearn]

yea that was my reading of the spec, only a minor thing. a bit confusing to me that they didn't just use the same single term/key/parameter for both verifier & wallet metadata

[TimoGlastra]

This will be fixed in #2088. I might backport it, as that branch is targeting 0.6 release

[gmulhearn]

Awesome, thanks a lot!