using credential_type as a key in issuer metadata.

[Kristina Yasuda]

Opening an issue because there is no corresponding one to a change being made in a PR #240.

It removes an identifier used as a key in the credentials_supported object and the types inside formats object, and insted uses type (also used in scopes) as a key in the credentials_supported object.

From below

{
  "credentials_supported": {
    "university_degree": {
       "formats": {
          "ldp_vc": {
              "types": ["VerifiableCredential", "UniversityDegreeCredential"]
          }
       }
     }
  }
}

to

{
  "UniversityDegreeCredential": {
    "university_degree": {
       "formats": {
          "ldp_vc": {
          }
       }
     }
  }
}

‌

‌

[David W Chadwick]

The reason is that the protocol is currently inconsistent. It uses the parameter credential_type in both the Initiate Issuance Request and the authorization_details Parameter of the Authorisation Request. But then it switches to type in the Credential Request. PR#240 changes the Credential Request to credential_type, and the metadata to match this.

[David Waite]

I don’t quite understand what is going on here - The credential issued in the first case would be both a VerifiableCredential and a UniversityDegreeCredential. Having a higher-level identifier for a credential like university_degree is necessary so that one can statically define what is available and how to request it. Otherwise, wallets must dynamically interact with the issuing authority to discover which facets of configuration parameters and which claims can be combined.

[David W Chadwick]

@David Waite When you say “statically define” what do you mean by this? If each Issuer has its own (different) static definition (which I believe the current specification requires) then all wallets must interact with each issuer to find out what their static definition is before they can interact with it. This does not seem like the correct approach.

Instead we need globally unique identifiers for each credential type that is to be issued (or an IANA register but this will be massive given the different number of VC types there will be). So my proposal is for globally unique identifiers. And you will notice that the first examples in the existing specification already do this. Fortunately this is not difficult to document. For W3C VCs, both VerifiableCredential and UniversityDegreeCredential are aliases for globally unique URIs defined in the @context property of the VC. Furthermore VerifiableCredential is mandatory in each W3C VC so can be ignored for selection purposes. So nothing in addition to the URI of UniversityDegreeCredential (or this alias if the @context can be assumed) is needed in order to uniquely refer to this particular W3C credential type. For mDL we can use the globally unique ID specified in the ISO standard. When new types of credentials are invented, we can require that they also have their own globally unique IDs.

‌

[Kristina Yasuda]

PR#240 changes the Credential Request to credential_type, and the metadata to match this.

PR #240 does this editorial change too. but it does much more, which is a normative change documented in this issue.

‌

[Kristina Yasuda]

PR merged