`credentials_supported`credential object with different formats

[patatoid]

Hi,

I implemented OID4VCI and got a complete flow up and running, thank you for the specification that leverages SSI on top of OAuth.

I expose the same credential in different formats and end up with the following example. I wondered if there was any way to have the same credential object with different formats since it exposes the same data.

[
  {
    "claims": [
      "linkedin_email",
      "linkedin_name",
      "linkedin_picture",
      "linkedin_email_verified"
    ],
    "cryptographic_binding_methods_supported": [
      "did:example"
    ],
    "display": [
      {
        "background_color": "#ffd758",
        "locale": "en-US",
        "logo": {
          "alt_text": "Malachit logo",
          "url": "https://io.malach.it/assets/images/logo.png"
        },
        "name": "Linkedin profile (jwt_vc)",
        "text_color": "#333333"
      }
    ],
    "format": "jwt_vc",
    "id": "FederatedBorutaCredentialJwtVc",
    "types": [
      "VerifiableCredential",
      "BorutaCredentialJwtVc"
    ]
  },
  {
    "claims": [
      "linkedin_email",
      "linkedin_name",
      "linkedin_picture"
    ],
    "cryptographic_binding_methods_supported": [
      "did:example"
    ],
    "display": [
      {
        "background_color": "#ffd758",
        "locale": "en-US",
        "logo": {
          "alt_text": "Malachit logo",
          "url": "https://io.malach.it/assets/images/logo.png"
        },
        "name": "Linkedin profile (jwt_vc_json)",
        "text_color": "#333333"
      }
    ],
    "format": "jwt_vc_json",
    "id": "FederatedBorutaCredentialJwtVcJson",
    "types": [
      "VerifiableCredential",
      "BorutaCredentialJwtVcJson"
    ]
  },
  {
    "claims": [
      "linkedin_email",
      "linkedin_name",
      "linkedin_picture"
    ],
    "cryptographic_binding_methods_supported": [
      "did:example"
    ],
    "display": [
      {
        "background_color": "#ffd758",
        "locale": "en-US",
        "logo": {
          "alt_text": "Malachit logo",
          "url": "https://io.malach.it/assets/images/logo.png"
        },
        "name": "Linkedin profile (vc+sd-jwt)",
        "text_color": "#333333"
      }
    ],
    "format": "vc+sd-jwt",
    "id": "FederatedBorutaCredentialVcSdJwt",
    "types": [
      "VerifiableCredential",
      "BorutaCredentialVcSdJwt"
    ]
  }
]

[Sakurann]

Hi! Thank you for implementing and thank you for the issue!

entries in credential_configurations_supported are per format right now, partially because how claims are expressed is credential format specific: while vc+sd-jwt uses claims parameter, jwt_vc_json would use credential_definition.credentialSubject. (we don't define in jwt_vc in VCI rn).

[babisRoutis]

@patatoid the metadata are not totally correct.

Please check the claims. In SD-jWT-VC format this is not a JSON array but an object. Something like:

{
"claims" : {
    "linkedin_email" : {}
    "linkedin_name" : {}
}
}

Furthermore, In jwt_vc_json format there is no claims'. You should usecredential_definition` as @Sakurann noted above

[patatoid]

Thank you for the precisions about the claims needed per format.

I still think that we would not have different credential objects per format since it is semantically the same object. Grouping the common attributes and having a section for custom attributes per format can be an idea to have one object per credential not regarding the format.

[babisRoutis]

Thank you for the precisions about the claims needed per format.

I still think that we would not have different credential objects per format since it is semantically the same object. Grouping the common attributes and having a section for custom attributes per format can be an idea to have one object per credential not regarding the format.

You have a point, for sure.

Keep in mind though that this is not as easy as it seems, because the same logical data model has to be mapped differently to a specific format.

Indicatively

• in mso_mdoc format each attribute is identifier by a) namespace and b) an attribute name
• in jwt_vc_json your credential should be nested inside a credential_definition and use also JWT registered claims
• in sd-jwt-vc you must firstly use registered claims and then use custom claims

Let me give an example: In eidas 2.0 there would be a credential named PID (personal identity) which defines an attribute birth date.

In mso_mdoc format this corresponds to eu.europa.ec.eudiw.pid.1 / birth_date while in sd-jwt-vc would be birhdate

Notice

• that the first is a combination of namespace and an attribute name
• the second is just an attribute without underscore because this is how OIDC registered that claim

[patatoid]

A possible schema to take into account the constraints could look like the following:

  {
    "cryptographic_binding_methods_supported": [
      "did:example"
    ],
    "display": [
      {
        "background_color": "#ffd758",
        "locale": "en-US",
        "logo": {
          "alt_text": "Malachit logo",
          "url": "https://io.malach.it/assets/images/logo.png"
        },
        "name": "Linkedin profile (jwt_vc)",
        "text_color": "#333333"
      }
    ],
    "formats": ["jwt_vc", "sd+jwt-vc"],
    "id": "FederatedBorutaCredentialJwtVc",
    "types": [
      "VerifiableCredential",
      "BorutaCredentialJwtVc"
    ],
    "claim_definitions": {
        "jwt_vc": {
            "claims": [
              "linkedin_email",
              "linkedin_name",
              "linkedin_picture",
              "linkedin_email_verified"
          ],
        },
        "sd+jwt-vc": { ... }
    }
  }

It would include the different formats but also keep the credential definitions scoped by the data it contains.

[babisRoutis]

Dear @patatoid

Each format has its own metadata, not because VCI says so, but rather because that is by how formats are defined.

Some (more) examples:

types In your example you have a types attribute which a JSON array of strings. That is specific to W3C. In mso_mdoc there is a doctype which is string. That is defined in the relevant mso_mdoc ISO spec. Not in VCI Similarly, there is no types in SD-JWT-VC format. The spec of SD-JWT-VC defines an attribute vct.

claims I believe I tried to explain in an earlier comment this is not common across format.

So, in general, I think that correctly VCI keeps metadata of each format separate.

[patatoid]

I realize that my example is not up to date with the latest draft. Following it, it would be the credential_definition that would be scoped by format.

That said if you think it is not relevant, feel free to close the issue.

Thank you for your explanations.

[Sakurann]

even with the approach taken in PR #276 I think it would be hard to have a unified claims object across formats... would close in a week unless strong opposition