OpenID4VCI: properties in Credential Issuer Metadata get dropped with JSON-LD
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.
Comments (14)
-
-
reporter 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 thecredential_definition
in the request (at last forjwt_vc_json-ld
).jwt_vc_json-ld
without JSON-LD processing is basically the same asjwt_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 ofUniversityDegreeCredential
, one defined inhttps://www.w3.org/2018/credentials/examples/v1
and one inhttps://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.
-
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
orldp_vc
), then the associatedcredential_definition
object andcredentials_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
definesUniversityDegreeCredential
type as beinghttps://www.w3.org/2018/credentials/examples/v1#UniversityDegreeCredential
- Context at
https://example.org/credentials/v1
definesUniversityDegreeCredential
type as beinghttps://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 indeedhttps://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 thecredential_definition
object?
Failing to do so may result in the wallet requestinghttps://example.org/credentials/v1/UniversityDegreeCredential
and the issuer issuinghttps://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.
- Context at
-
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 interpretcredential_definition
andcredentials_supported
objects, JSON-LD processing is needed.I think that’s fair - will update a PR to separate these two cases.
-
reporter 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 comprisingcredentials_supported
parameter to "resolve the type". -
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 comprisingcredentials_supported
parameter. -
- changed status to open
-
Regarding PR #463:
- I also agree with allowing only the
credential_definition
object and thecredentials_supported
entry to be processed using JSON-LD rules, whenformat
isldp_vc
orjwt_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
, anddisplay
properties, that may appear on acredentials_supported
entry object? Thetype
andcredentialSubject
properties are already defined on the context pointed byhttps://www.w3.org/2018/credentials/v1
, but the others aren’t.
- I also agree with allowing only the
-
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
, anddisplay
properties. -
reporter That sounds like a good way forward!
-
PR #469 updated :)
-
reporter I believe you mean PR #463 ;) Do you want me to provide feedback directly in the PR or should we continue the discussion here?
-
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…
-
- changed status to resolved
PR merged. agreed to gather more implementation experience on this topic.
- Log in to comment
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.