Structure and location of OP metadata to support credential issuance

[Tobias Looker]

Currently the spec makes use of credential manifest as the primary source of syntax for a provider to advertise what credentials it supports the issuance of. I propose that we opt to define our own simpler syntax that is more in keeping with how existing OpenID metadata is defined. Below is an annotated sample of my proposal

{
    "credentials_supported": [ // An array of objects
        {
            "name": "University Credential",
            "type": "university_degree", // Normatively defined as a string so CAN be something stricter like a URI/URL
            "formats": {
                "w3c_vc" : { // The structure of the object to be somewhat dictated by the format identifer
                  "binding_methods_supported": [ "did" ],
                  "proof_types_supported": [ "Ed25519Signature2018" ]
                }
            },
            "claims": { // Optional This abstraction could be difficult to maintain, need to validate it more
                "given_name": {
                    "display": "Given Name",
                    "description": "The given name of the subject of the degree",
                    "path": "$.values.given_name", // Potential path expression
                    "mandatory": true // Assume default is false if omitted
                },
                "last_name": {
                  "mandatory": true
                },
                "degree": {
                  "mandatory": true
                },
                "gpa": {
                  "mandatory": false
                }
            }
        }
    ],
    "credential_endpoint": "https://server.example.com/credential", // Endpoint for obtaining the issued credential
    "pop_supported": [ "did" ]
  }

‌

[Torsten Lodderstedt]

I support this proposal.

I suggest to use the same credential format identifiers as in the OIDC4VP spec, e.g. “ldp_vc”.

[David W Chadwick]

I agree that we should simplify the meta-data but for VCs I think we should use the schema property from VCs since issuers will already be familiar with this and most likely inserting it into their issued VCs (which allows for dynamic discovery if an RP receives a VC that it has not seen before)

   "formats": {
                "w3c_vc" : { // The structure of the object to be somewhat dictated by the format identifer
                  "binding_methods_supported": [ "did" ],
                  "proof_types_supported": [ "Ed25519Signature2018" ],
                  "credentialSchema": "https://<the same URL inserted into the issued VC>"
                  },
                  "iso_mdl":{ "<whatever is defined for this format>"}
                  }
              }
  Note that claims are no longer needed with this structure

‌

[Tobias Looker]

I think I mostly agree with what you are suggesting david, but could you elaborate more on “credentialSchema”? Does this resolve to a JSON schema or some other data structure and if so what does it contain exactly?

[Tobias Looker]

@Torsten Lodderstedt , yes we can choose to inherit those, I was under the assumption there would likely be some IANA registry for these identifiers, so we may have some license with how they are defined? In general though its best not to re-invent if the existing P.E identifiers are being used in meaningful ways in communities today.

‌

[David W Chadwick]

@Tobias. My bad, it was a hurried response. I should of course have added the type to the credentialSchema as per the W3C spec e.g.

"credentialSchema": {
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchemaValidator2018"
  }

In this way the IdP is indicating the format of data structure that can be found at the URL.

[Tobias Looker]

No worries, thanks David yes this makes sense. How would you propose we describe the claims offered in say the CBOR based iso_mdl format? Ideally I was hoping we could make the claims description generic (e.g span multiple formats), but that may be to complex to support

[David W Chadwick]

I think we should follow the W3C VCDM model, in which the type specifies its contents. Applying this model to formats, then the value of the property (w3c_vc, iso_mdl, etc.) determines its content. Alternatively formats could be a set of values, where each value is an object whose first element is type=xxx.

The main point is that whoever has implemented a particular credential format already has the tools for processing and understanding that format, so it makes sense for the format metadata to follow the syntax specified for that credential type.

‌

[Tobias Looker]

The main point is that whoever has implemented a particular credential format already has the tools for processing and understanding that format, so it makes sense for the format metadata to follow the syntax specified for that credential type.

Yes I agree with this particular point but I think we need to order some of the concepts a bit here so we know their relationship, I was thinking the following

- credential
    - type
    - formats
        - schema validation
        - binding_methods
        - signature schemes (proof types)
    - claims

However what I think you might be advocating for is

- credential
    - type
    - formats
        - claims (schema representation)
        - binding_methods
        - signature schemes (proof types)

To which I would ask what is left at the credential level, would it not be better to conceptually collapse to this in your model to

- credential
    - type
    - format
    - claims (schema representation)
    - binding_methods
    - signature schemes (proof types)

To me the above then means the “credential type” would then implicitly communicate the format?

[David W Chadwick]

I was proposing a structure more like this

- credential
    - type
        - what ever is required for this type

then when type is W3C VC we would have

- credential
    - type = W3C VP
        - schema validation (type and id as per W3C VC spec)
        - binding_methods (did:meth1,... did:methi, jwk, jwk-uri)
        - signature schemes (proof types)

if it is an ISO mDL then the parameters that follow type will be dictated by the different options in mDL that need to be set to ensure interop (which might include transport methods of NFC, BLE, or Internet etc.)

‌

[Tobias Looker]

Right I think I understand now thanks, just to confirm, with your approach it would mean a credential type infers the format and everything else, so you could not have a single credential type where it is available in multiple formats like what I outlined above?

[Tobias Looker]

Also it appears the type in your proposal is the format not the credential type as I was intending e.g "university_degree”

[David W Chadwick]

An X.509 PKC is a credential, so is a SAML assertion, so is an mDL. So do you call these different types of credentials or something else? I have called them types. (But I admit that for VCs this could be confusing because there are different types of VCs as you say e.g. university degree.) In my proposal the type does infer the format, because it infers everything about the credential. But I am not quite sure what you mean by format. Is it the credential structure, or encoding rules or something else. I think the format of the various credentials (X.509 PKCs and W3C VCs etc) will be specified in the relevant standards. The encoding rules may also be specified as well e.g. for X.509 is it BER or DER? For VCs we may eventually have a CBOR encoding. Thus the various properties that define the credential type will be specific to each type of credential.

[Tobias Looker]

Right yeah this is good to understand, in my mental model the top level concept is a credential and its respective type where the type infers the purpose and abstractly the contents of the credential, examples include “drivers_license” or “university_degree”, credential then have formats and this is where the concrete technology comes in (e.g mDL or VC-JWT VC-JSONLD), suffice to say you can offer a specific “type of credential” in multiple formats. I think the credential type should communicate this rather than the format because the basis of the exchange protocols is about what the information being exchange is rather than the form it comes in.

[Tobias Looker]

So just to clarify david I see PKC, SAML and mDL as credential formats, not credential types.

[Torsten Lodderstedt]

that’s my mental model as well

[Torsten Lodderstedt]

yes we can choose to inherit those, I was under the assumption there would likely be some IANA registry for these identifiers, so we may have some license with how they are defined? In general though its best not to re-invent if the existing P.E identifiers are being used in meaningful ways in communities today.

We use the PE identifiers in OIDC4VPs (https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html#name-rp-metadata) and I think it makes a lot of sense to use the same identifiers in the credential issuance draft as well. I also think it is a good idea to discuss extensibility with the PE folks. PR #142 might be a good intro into this discussion.

[David W Chadwick]

“that’s my mental model as well”. Yes I can go along with this mental model instead. But it then means that we will have thousands of credential types rather than just a handful of them. I am not sure how it would work for say a university degree that was issued as a VC and an X.509 AC and as an ISO mdoc. I presume you would have multiple formats below the type. Whereas with my model you would have multiple types with a single “format” below each of them. Its just a different way of structuring a multi-dimensional array.

[Kristina Yasuda]

So just to clarify david I see PKC, SAML and mDL as credential formats, not credential types.

are JWT_VC, LDP_VC on the same level as PKC, SAML, mDL? because that is what I think of as credential formats

‌

[Michael Jones]

I agree with using the same credential format identifiers as in the OIDC4VP spec, e.g. “ldp_vc”.

I agree that PKC, JWT, SAML, mDL, etc. are credential formats, not credential types.

And Kristina asked a good question about the placement of JWT_VC, LDP_VC, etc. in the heirarchy.

[Tobias Looker]

“that’s my mental model as well”. Yes I can go along with this mental model instead. But it then means that we will have thousands of credential types rather than just a handful of them. I am not sure how it would work for say a university degree that was issued as a VC and an X.509 AC and as an ISO mdoc. I presume you would have multiple formats below the type. Whereas with my model you would have multiple types with a single “format” below each of them. Its just a different way of structuring a multi-dimensional array.

Understood David but just to be clear I think there would be more credential types in your model right? E.g instead of one credential type for university degree and offering it in 3 formats, you would have 3 credential types for a university degree expressed individually in each different format?

I agree that PKC, JWT, SAML, mDL, etc. are credential formats, not credential types.

And Kristina asked a good question about the placement of JWT_VC, LDP_VC, etc. in the heirarchy.

This is a good question to ask, IMO JWT could be the basis for a credential format, but I dont think we should consider it one on its own, for example we would probably need some profile of JWT to define any normative processing requirements implementers MUST conform to, much like there is an id_token profile for openid connect.

[Tobias Looker]

So JWT_VC, LDP_VC, mDL I think are what we would refer to as credential formats, JWT is a generic token format that can be the basis of one or multiple credential formats.

[Tobias Looker]

Also, and this is which is why I felt a bit wary in accepting P.Es identifiers for these formats, is that I dont regard verifiable presentations as a credential format (e.g LDP_VP), they are a presentation vehicle which is different to the underlying credential format.

[Torsten Lodderstedt]

I agree. The problem is PE does not really differentiate between credential and presentation formats. We can nevertheless use the existing identifiers for credential formats, which are ldp_vc and jwt_vc. We also need a proper way for extensibility, either in PE or in our protocol suite.

[David W Chadwick]

Yes we need extensibility, because we need to be able to cater for say an insurance certificate type that is formatted as either an ISO mdoc, or a jwt_vc (or in future some CBOR format).

[Kristina Yasuda]

Please review PR #145. I also updated the PR to include metadata on the input from the user (vc or any other data - when VC, presentation_definition object must be used, but overall structure is still much simpler than credential manifest) and display - issuer’s logo, etc., which is very important to make sure the credential is displayed without harming the issuer’s reputation/brand.

[Kristina Yasuda]

I caught up with the conversation and updated a PR to include types array of strings at the same level as formats and claims. please review

[Michael Jones]

Simpler than Credential Manifest is a very good thing!

[Kristina Yasuda]

PR #145