[Openid-specs-ab] OpenID4VCI: JSON-LD processing of request and metadata fields

Thu Feb 16 12:25:33 UTC 2023

Hi,

I believe there are different issues and Appendix E seems to mix the JSON-LD context of the VC-data-model with the protocol. If there is an intention to support or require JSON-LD processing for request and/or metadata fields, a dedicated OpenID4VCI context for JSON-LD will be required. Reusing or referring to  https://www.w3.org/2018/credentials/v1 is not appropriate as requests and metadata are not credentials. 

I agree with David that JSON-LD can be handled just like any JSON object. Furthermore, it is possible to include credentials that are LD compliant in conventional JSON objects like in a credential response. 

The @context-field is used for various objects in Appendix E that are not credentials. For example in the credential issuer metadata as in E.1.3.2 <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#server_metadata_ldp_vc>. As David states, the context attribute turns the JSON into JSON-LD. Consequently, the credential issuer metadata becomes a JSON-LD document. The context for this document points to the VD-data-model (https://www.w3.org/2018/credentials/v1) which is not appropriate because the credential issuer metadata does not represent a credential. The only place where credentials occur are in the credential response. If the credential issuer metadata is supposed to be a JSON-LD document, then it will require a dedicated context for OpenID4VCI.

The current specification explicitly requires JSON-LD processing for certain objects (beyond credentials) as Pedro noted - namely the credentials_supported and credentials_definition.

The credential issuer metadata as defined for VC signed as a JWT, using JSON-LD and VC <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-3>  and VC secured using Data Integrity, using JSON-LD, with proof suite requiring Linked Data canonicalization <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-4> contains the claim credentials_supported which is an array of supported credentials. E.1.3.2 states:

> Any object comprising credentials_supported parameter of Credential format ldp_vc MUST be processed using full JSON-LD processing.

I think this statement is misleading. It indicates that the objects in the credentials_supported property are to be processed using full JSON-LD processing but I believe, what E.1.2 and E.1.3 are all about, is that the issued credential (that is of one of the types listed in the credentials_supported) is a JSON-LD conformant object, i.e. the issued credential MUST be processed using full JSON-LD processing. The latter makes much more sense but that is not what the above statement says, thus the confusion. 

There is a similar issue with the credential_definition claim. Currently, the draft reads (E.1.3.3 <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-e.1.3.3>) as follows:

> credential_defintion: REQUIRED. JSON object containing (and isolating) the detailed description of the credential type. This object MUST be processed using full JSON-LD processing …

The question is actually not whether the current specification of the  credential_definition claim (or an object in credentials_supported) is JSON-LD conformant or not but more fundamental, whether it is supposed to be a JSON-LD document in the first place (implied by the statement from above) or rather a conventional JSON object (removing the requirement regarding JSON-LD processing).
In the first case, if OpenID4VCI aims to support JSON-LD processing for request and metadata fields, it must provide a OpenID4VCI context for the related objects because those objects are not credentials and thus reusing the https://www.w3.org/2018/credentials/v1 as the context (as currently required) is not appropriate. 
In the second case, remove the requirement regarding JSON-LD processing for the claims.

Regards,
Judith

> On 15 Feb 2023, at 22:45, David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi Pedro
> 
> On 16/02/2023 04:58, Pedro Felix via Openid-specs-ab wrote:
>> Hi,
>> 
>> The latest OpenID4VCI spec
>> (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html)
>> requires that certain JSON objects "... MUST be processed using full
>> JSON-LD processing", namely credentials_supported and
>> credentials_definition (e.g
>> https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#section-e.1.3.3),
>> when the format is jwt_vc_json-ld or ldp_vc.
> This is not actually the case. JSON-LD is fully conformant JSON and JSON processing tools can be used to obtain VCs that are LD compliant. There is currently a discussion in the VC-WG about the use of the @context property (which turns JSON into JSON-LD) and this is still ongoing. Once this issue has been resolved we will need to revisit the OID4VCI spec to make it conformant to the VC-DMv2 spec.
>> 
>> IINM, this requires all the internal fields to be
>> "fully-contextualized", i.e., they need to be mapped to URIs by a
>> JSON-LD context. This already happens for credentialSubject, which is
>> defined on the https://www.w3.org/2018/credentials/v1 context
>> (credentialSubject maps to
>> https://www.w3.org/2018/credentials#credentialSubject)
>> However, there are other fields which are introduced by the OpenID4VCI
>> spec, such as cryptographic_binding_methods_supported,
>> cryptographic_suites_supported, used inside credentials_supported and
>> which aren't mapped to URIs.
> These are metadata properties that are in the issuer's metadata file. They are not necessarily in the VCs that the issuer issues (though they could optionally be placed there, in which case a new @context may need to be defined for them - but again this will have to wait until the @context issue is resolved in the VC-WG, because the use of @vocab may cover these (and any other) new properties)
> 
> 
> 
>> 
>> So,
>> 1) Doesn't the OpenID4VCI spec need to map those fields to full URIs,
> Not if they remain in the metadata file only
>> if they are to be used with "full JSON-LD processing"?
>> 2) Should the OpenID4VCI spec define a context with those mappings and
>> make it available in a openid.net URL, similar to what the W3C does
>> with https://www.w3.org/2018/credentials/v1?
> Yes it would be best to, if it also says that these new properties can be properties of the issued credentials
> 
> Kind regards
> 
> David
> 
>> 
>> Thanks.
>> Regards,
>> Pedro
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230216/4232a401/attachment.html>