Advertising supported vp_formats and cipher suites

[gerardsn]

The OpenID4VP spec is unclear on how to advertise what data formats are supported. We will need decide what to do for our implementation and document this. Below is an overview of the bits of available information with followed by a proposal at the end.

Authorization Server metadata

According to the OpenID4VP specification the OAuth Authorization Server metadata MUST contain parameter vp_formats_supported and provides non-normative example:

"vp_formats_supported": {
  "jwt_vc_json": {
    "alg_values_supported": [
      "ES256K",
      "ES384"
    ]
  },
  "jwt_vp_json": {
    "alg_values_supported": [
      "ES256K",
      "EdDSA"
    ‌]
  }
}

Here and in appendix A the OpenID4VP spec uses formats jwt_vc_json and jwt_vp_json, which are said to use the JSON Web Signature and Encryption Algorithms registry. For Linked data protected formats the spec describes ldp_vc and ldp_vp, which should use their own cipher suite registry: Linked Data Cryptographic Suite Registry The rest of the spec provides no example of what the LD(P) notation for the vp_formats_supported metadata field should look like. It is also inconsistent in applying its own notation. Based on the available information the generic format should be:

"vp_formats_supported": {
  <format>: {
    "alg_values_supported": [
      <list-of-format-specific-algorithms>
    ]
  }
}

Which would look something like this

"vp_formats_supported": {
  "ldp_vc": {
    "alg_values_supported": [
      "JsonWebSignature2020"
    ‌]
  ‌},
  "jwt_vp_json": {
    "alg_values_supported": [
      "ES256K",
      "EdDSA"
    ]
  }
}

Client metadata

The OpenID4VP spec also describes the corresponding vp_formats field of type object that MUST be present without defining its format. It does contain an example using client metadata in the following body for an authorization request:

{
   "client_id": "did:example:123",
   "client_id_scheme": "did",
   "response_types": "vp_token",
   "redirect_uri": "https://client.example.org/callback",
   "nonce":"n-0S6_WzA2Mj",
   "presentation_definition": "...",
   "client_metadata": {
     "vp_formats": {
       "jwt_vp": {
         "alg": [
           "EdDSA",
           "ES256K"
         ]
       },
       "ldp_vp": {
         "proof_type": [
           "Ed25519Signature2018"
         ]
       }
     }
   }
}

The client metadata looks nothing like what is specced for AS metadata, but it is consistent with the spec for Presentation Exchange. Example from Presentation Exchange 2.0.0:

{
  "presentation_definition": {
    "id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "input_descriptors": [],
    "format": {
      "jwt": {
        "alg": ["EdDSA", "ES256K", "ES384"]
      },
      "jwt_vc": {
        "alg": ["ES256K", "ES384"]
      },
      "jwt_vp": {
        "alg": ["EdDSA", "ES256K"]
      },
      "ldp_vc": {
        "proof_type": [
          "JsonWebSignature2020",
          "Ed25519Signature2018",
          "EcdsaSecp256k1Signature2019",
          "RsaSignature2018"
        ]
      },
      "ldp_vp": {
        "proof_type": ["Ed25519Signature2018"]
      },
      "ldp": {
        "proof_type": ["RsaSignature2018"]
      }
    }
  }
}

Summarize

The spec is clearly unfinished on this part, so what are we going to implement? It looks like the OpenID4VP spec is converging towards what is described for the presentation exchange. Based on this I propose to implement the Presentation Exchange and Client Metadata as described, and make the following adjustments to the AS metadata:

• Drop _json from the JWT versions: jwt_vc and jwt_vp. (EBSI also did this)
• Rename of alg_values_supported to proof_type_values_supported for ldp_* formats. This matches PE and is also consistent with the "alg" field in jwts and "proof": { "type":... in the VC DATA model. (I cannot find any examples for ldp_* formats)

  "vp_formats_supported": {
  "jwt_vc": {
  "alg_values_supported": [
    "PS256", "PS384", "PS512",
    "ES256", "ES384", "ES512"
  ]
  },
  "jwt_vp": {
  "alg_values_supported": [
    "PS256", "PS384", "PS512",
    "ES256", "ES384", "ES512"
  ]
  },
  "ldp_vc": {
  "proof_type_values_supported": ["JsonWebSignature2020"]
  },
  "ldp_vp": {
  "proof_type_values_supported": ["JsonWebSignature2020"]
  }
  }

The only weird-ish things remaining are that

• alg_values_supported and proof_type_values_supported are nested under vp_formats_supported, and
• Client and AS use different formats to advertise what they support. (EBSI changed client format to match AS, should we do this?)

The decision should be clearly documented in the NUTS profile until the OpenID4VCI spec is clarified.

OpenID4VP - https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html EBSI - https://api-conformance.ebsi.eu/docs/ct/providers-and-wallets-metadata Presentation Exchange - https://identity.foundation/presentation-exchange/spec/v2.0.0/#presentation-definition

[reinkrul]

Are there any issues on the OpenID Connect bugtracker regarding the inconsistencies?

[woutslakhorst]

proof_type_values_supported should be proof_type?

[gerardsn]

proof_type_values_supported should be proof_type?

https://www.github.com/openid/OpenID4VP/issues/41

[gerardsn]

Current strategy is to support all options described in other wallets, and clean up things once the specs are clearer/consistent on the parameter names.

[gerardsn]

We have also opted for "jwt_vp_json" and "jwt_vc_json" since this is in the openid4vp spec, but that doesn't match the DIF claim format registry used everywhere else. Also, the j in jwt stands for json

[reinkrul]

Maybe just add both for now, for the sake of compaitibility?

[woutslakhorst]

Maybe just add both for now, for the sake of compaitibility?

that never hurts