Define the concept of a credential type

[danielfett]

We should define more clearly what a credential type (identified by the vct claim) actually means.

The current description is a bit handwavy and that may be a sign that we have not yet defined the concept well.

I think that there is a set of metadata usually associated with each SD-JWT VC type, for example

• Display information for the whole credential
• A schema for the JSON structure (may or may not be defined in JSON schema)
• Information about the claims, including
  • Display information
  • Type information
  • Status information (self-attested vs. verified etc.)
• Maybe: What kind of binding is supported/usually used for this credential type
• Maybe: What issuers are allowed to issue this credential type

Such metadata would help Wallets (e.g., for displaying the credential to the user) and Verifiers (e.g., for determining the status of claims). It would also help developers of Verifiers, as they would get structured information about the credential they can expect.

The need for such metadata has been discussed in Issue #171 and similar approaches have shown up in HAIP.

The metadata may or may not be embedded into the credential itself, or provided externally. Assuming we allow for registered vct values (e.g., UniversityCredential), this metadata could go into the registry. It could also be distributed manually.

But it can also be made discoverable, e.g., by providing it at a .well-known URI derived from the URL in vct.

---

Here is a completely made-up example of what this metadata could look like:

{
    "vct": "https://credentials.example.com/example1",
    "display": [
        {
            "en-US": {
                "name": "University Credential",
                "logo": {
                    "url": "https://exampleuniversity.com/public/logo.png",
                    "alt_text": "a square logo of a university"
                },
                "background_color": "#12107c",
                "text_color": "#FFFFFF"
            }
        }
    ],
    "claims": // mapping from JSON pointer to information about this claim
    {
        "/name": {
            "display": {
                "de-DE": {
                    "label": "Vor- und Nachname",
                    "description": "Der Name des Studenten"
                },
                "en-US": {
                    "label": "Name",
                    "description": "The name of the student"
                }
            },
            "status": "verified"
        },
        "/degree": {
            "display": {
                "de-DE": {
                    "label": "Abschluss",
                    "description": "Der Abschluss des Studenten"
                },
                "en-US": {
                    "label": "Degree",
                    "description": "Degree earned by the student"
                }
            },
            "status": "verified"
        },
        // ...
        "/address": {
            "display": {
                "de-DE": {
                    "label": "Adresse",
                    "description": "Adresse zum Zeitpunkt des Abschlusses"
                },
                "en-US": {
                    "label": "Address",
                    "description": "Address at the time of graduation"
                }
            },
            "status": "self-attested"
        },
        "/address/street_address": {
            "display": {
                "de-DE": {
                    "label": "Straße"
                },
                "en-US": {
                    "label": "Street Address"
                }
            },
            "status": "self-attested"
        }
    }
}

---

Important:

• This mechanism will not be format-agnostic, but defined only for SD-JWT VC for now.
• There are overlaps with mechanisms defined in HAIP, for example, and part of this issue here is to figure out what data should go where and to avoid duplications by getting the concept right. I think that the claims element defined for the credential issuer metadata in HAIP could be replaced by just a vct identifier (the metadata could be discovered from there, or retrieved from the registry).

[peppelinux]

Interesting point, I have the following approach to satisfy the requirement of having the credential metadata along with a credential:

using openid federation a trust chain is needed to attests the cryptographic keys of the issuer to verify the credential. Within the trust chain the openid_credential_issuer metadata is provided.

in the openid_credential_issuer metadata there are the display information for all the credential types. Then, using this approach, the credential doesn't need any metadata. Fed trust chain can be made available in a static form, within the credential jws/MSO headers

Let's see other points:

• I would not use status, because its value seems more close to the concept of issuance type. I would say iss_type set(self-issued, authority-issued). Also the name status may semantically collide with all about status lists

Maybe: What issuers are allowed to issue this credential type

It would be up to the trust model and the credential metadata or trust marks or attestations. We cannot allow an italian PID provider to issue a Polish PID, then the domestic italian credential identifier must be linked with one or more italian credential issuers. This information must be made available according to the infrastructure of trust, where the issued credentials are not involved yet. During a discovery phase the user/holder knows which are the credential issuers, which credential types they offers to users. Generally this is made available in the openid_credential_metadata and must be granted by an accreditation body. That's why I mentioned trusted lists or federation trust marks or X.509 custom extentions (for strong stomachs) or federation metadata policy.

Without openid federation I would have to find a solution and the credential metadata sounds resonable but I use federation and this requirement is already satisfied. Another point of interest is that the credential metadata should be issued by credential issuer and bound to the credential.

I would change this sentence we have in the current text: A type is associated with rules defining which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable. because the metadata should be issued by credential issuers and be tamper proof, otherwise a bogus implementation would use a valid credential with a fake presentation of the claims that may swaps some value and change the interpretation of the data to a verifier. Let's imagine that Giuseppe Marco would be swapped to Marco Giuseppe and pass through a supervised verifier as Marco, while the credential is still valid and verified

[tlodderstedt]

I like the idea to define schema and display information in the context of the credential definition (in contrast to issuance protocol) as I believe this information should be consistent across issuers and needs to be available for verifier developers. I also believe some information could be useful at the level of individual credentials for visual customization in the wallet.

[paulbastian]

we may add:

• type of binding of the vc ,e.g. key-binding, claim-based-binding, none
• vct could be either URL linking to the resource directly or an identifier that links to e.g. an (ISO) specification to get the credential metdata
• IANA registry is probably not a good option
• versioning of the metadata
• protection against change e.g. put a hash of metadata in the vc

It might be worth to consider reducing the credential format specific Issuer metadata defined in OpenID4VCI and define that in a credential format specific credential metadata resource:

{
    "credential_issuer": "https://credential-issuer.example.com",
    "authorization_servers": [ "https://server.example.com" ],
    "credential_endpoint": "https://credential-issuer.example.com",
    "batch_credential_endpoint": "https://credential-issuer.example.com/batch_credential",
    "deferred_credential_endpoint": "https://credential-issuer.example.com/deferred_credential",
    "display": [
        {
            "name": "Example University",
            "locale": "en-US"
        },
        {
            "name": "Example Université",
            "locale": "fr-FR"
        }
    ],
    "credentials_supported": {
        "UniversityDegreeCredential-jwt-vc": { //issuer-specific
            "format": "jwt_vc_json",
            ...
        },
       "UniversityDegreeCredential-sd-jwt-vc": { //issuer-specific
            "format": "sd-jwt+vc",
            "vct": "https://link-to-a-resolvable-crednetial-metadata.com/UniversityDegreeCredentialSelectiveDisclosable"
        },
        "mDL": { //issuer-specific
            "format": "mso_mdoc",
            "uri": "org.iso.18013.5.1.mDL"
        }
   }
}

However, there will remain issuer-specific things e.g. cryptographic support that should stay in the Issuer Metadata. These would need to be defined in SD-JWT-VC.

[awoie]

Using the VC type metadata, one could also include an ecosystem-specific parameter that contains a JSON patch that allows you to map to any data model one want. It would also allow automatic fetching and executing the transformation algorithm quite easily.

[danielfett]

I prepared a first draft for the SD-JWT VC metadata. I wrote this as a separate draft for working on it, but of course we can consider integrating this into SD-JWT VC — whatever works best. I'm looking forward to your feedback.

https://vcstuff.github.io/sd-jwt-vc-types/draft-fett-oauth-sd-jwt-vc-types.html

[decentralgabe]

@danielfett I like the document and think it's a great start. I think there's a lot more to do around JSON Schema, similar to the work we've put into this document at the W3C. I'm happy to help here. Similarly, the display reminds me of this document from DIF, which could be a standalone thing. Perhaps the types document should be transformed to a 'hub' document?