OpenID4VCI: properties in Credential Issuer Metadata get dropped with JSON-LD

[Judith Kahrer]

The Credential Issuer Metadata as defined in 10.2.3 must contain a credentials_supported parameter.
According to 10.2.3.1 this parameter is an array of JSON objects with certain properties (some of which are mandatory).
Appendix E 1.3.2 Credential Issuer Metadata adds even more properties for a supported credential object. In particular, it emphasis JSON-LD processing.

When processing a supported credential using JSON-LD, any properties that cannot be expanded to an IRI, i.e. that do not have a matching term definition via @context, will be dropped (see step 4 in overview of expansion algorithm for JSON-LD 1.1 ). The only required context in OpenID4VCI is https://www.w3.org/2018/credentials/v1 (via the VC Data Model as defined in E1.3.2). Consequently, many of the parameters defined in 10.2.3.1 and E1.3.2 will be ignored when applying JSON-LD processing. So, the current draft does not support (is incompatible with) JSON-LD processing because the resulting object won’t confirm with the specification as required properties are also ignored.

Suggested solution: Create and publish a dedicated context for OpenID4VCI that enables JSON-LD processing for supported credential objects.

[Kristina Yasuda]

Credential Issuer Metadata itself is JSON and was not meant to be processed using JSON-LD. only the issued credential is meant to be in JSON-LD when credential format requires so.

In the previous calls, and on the mailing list WG seems to agree that the way to address this is to dropp the text that indicates that JSON-LD processing is required for anything other than the credential.

there is PR #463 addressing this issue, which is ready to be merged.

Please indicate if the PR does not address this issue, otherwise will merge it and resolve this issue.

[Judith Kahrer]

No, I don’t think PR #463 resolves this issue, because even if JSON-LD processing is not explicitly required, the supported credential object still includes the @context which indicates support for JSON-LD and implementations may use JSON-LD to process the object anyways.

The more I think about it, it makes sense to keep the @context (and JSON-LD processing) for the supported credential object in the credential issuer metadata and the credential_definition in the request (at last for jwt_vc_json-ld). jwt_vc_json-ld without JSON-LD processing is basically the same as jwt_vc_json. There’s a benefit of using JSON-LD. How would a client be able to request a dedicated type of credential without the @context and JSON-LD? For example, imagine a server supporting two different types of UniversityDegreeCredential, one defined in https://www.w3.org/2018/credentials/examples/v1 and one in https://example.org/credentials/v1. How will a client/wallet be able to differentiate between the two different types if it doesn’t use JSON-LD processing? How will it be able to request a dedicated type without JSON-LD? If the credential supports JSON-LD but the request doesn't, how can the wallet check that the response and request match?
How will a server be able to announce the support for different credentials with the same type name without also processing the @context? How can it to process a request in this case without JSON-LD? Pure JSON processing ignores any @context and information may get lost.

When I suggested to remove the requirement of JSON-LD processing (that resulted in PR #463) I believe I jumped to a conclusion too fast. I missed the big picture.

[Pedro Felix]

I’m also of the opinion that if the credential is to be processed according to JSON-LD rules (i.e. format is jwt_vc_json-ld or ldp_vc), then the associated credential_definition object and credentials_supported item object should also be processes according to JSON-LD rules, namely to avoid confusion between what is announced, what is requested, and what is issued. I’m not sure if the standard should absolutely require it (i.e. a MUST) but it should strongly recommend it (i.e. SHOULD?) and warn for the negative consequences of not doing it.
Using Judith’s example, where:

• Context at https://www.w3.org/2018/credentials/examples/v1 defines UniversityDegreeCredential type as being https://www.w3.org/2018/credentials/examples/v1#UniversityDegreeCredential
• Context at https://example.org/credentials/v1 defines UniversityDegreeCredential type as being https://example.org/credentials/v1/UniversityDegreeCredential

Consider an issuer that does support the second one, as announced by the metadata

"credentials_supported":[
  {
    format": "ldp_vc",
    "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://example.org/credentials/v1"
    ],
    "types": [
        "VerifiableCredential",
        "UniversityDegreeCredential"
    ],
    ...
  }
]

How can a wallet know that the UniversityDegreeCredential is indeed https://example.org/credentials/v1/UniversityDegreeCredential without using JSON-LD to process the above object?
In the reverse direction, if the issuer receives a request with

"credential_definition": {
      "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://example.org/credentials/v1
      ],
      "types": [
         "VerifiableCredential",
         "UniversityDegreeCredential"
      ],
      ...
   },

how can the issuer know that the type that is being requested is https://example.org/credentials/v1/UniversityDegreeCredential without using JSON-LD to process the credential_definition object?
Failing to do so may result in the wallet requesting https://example.org/credentials/v1/UniversityDegreeCredential and the issuer issuing https://www.w3.org/2018/credentials/examples/v1#UniversityDegreeCredential.

To the best of my knowledge, this type of confusion due to collision between “simple identifiers” is one of the things JSON-LD tries to solve. But that IMO requires fully-contextualizing not only the issued VCs but also the metadata and credential definition objects.

‌

[Kristina Yasuda]

If the credential supports JSON-LD but the request doesn't, how can the wallet check that the response and request match?

Let’s separate two issues.

First, can we agree that no need to use JSON-LD processing to the entire Credential Offer, Authorization Details, Credential Request and Credential Issuer Metadata objects? They themselves DO NOT use JSON-LD. All of the parameters in them are defined, so no need for “global semantic interoperability“, and no need to use Knowledge Graph to visualize relations between multiple Credential Requests, etc.

Second, @context was included in Credential Offer, Authorization Details, Credential Request and Credential Issuer Metadata for the purpose of identifying which credential is being requested to be issued. I think you are saying that to interpret credential_definition and credentials_supported objects, JSON-LD processing is needed.

I think that’s fair - will update a PR to separate these two cases.

[Judith Kahrer]

Yes, I fully agree on point 1.

Yes, I believe that with how the spec is designed now, you need some JSON-LD processing of a credential_definition and an object comprising credentials_supported parameter to "resolve the type".

[Kristina Yasuda]

great. I updated PR #463 - do you have any issues with the text there? there is a general guidance how to treat credential_definition and an object comprising credentials_supported parameter.

[Pedro Felix]

Regarding PR #463:

• I also agree with allowing only the credential_definition object and the credentials_supported entry to be processed using JSON-LD rules, when format is ldp_vc or jwt_vc_json-ld. The top level metadata, offer, authorization details, and credential request objects should not be processed according to JSON-LD rules.
• However, don’t we need to provide a JSON-LD context for the format, cryptographic_binding_methods_supported, cryptographic_suites_supported, and display properties, that may appear on a credentials_supported entry object? The type and credentialSubject properties are already defined on the context pointed by https://www.w3.org/2018/credentials/v1, but the others aren’t.

‌

[Kristina Yasuda]

Thanks for bringing up the second point. What I would suggest doing and will reflect in a PR is to introduce credential_definition property inside credentials_supported so that the rule would become “JSON-LD processing is applied only to credential_definition“. Hence no need to apply JSON-LD processing to the credentials_supported object itself, and no need to define JSON-LD context for format, cryptographic_binding_methods_supported, cryptographic_suites_supported, and display properties.

[Judith Kahrer]

That sounds like a good way forward!

‌

[Kristina Yasuda]

PR #469 updated :)

[Judith Kahrer]

I believe you mean PR #463 ;) Do you want me to provide feedback directly in the PR or should we continue the discussion here?

[Kristina Yasuda]

let' try sort things out in a PR for now, but I agree I am getting increasingly confused, so we might have to come back to the issue, though I hope we won’t have to…

[Kristina Yasuda]

PR merged. agreed to gather more implementation experience on this topic.