<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi,</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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 <a href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a> is not appropriate as requests and metadata are not credentials. </div></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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. </div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">The <font face="Courier New">@context</font>-field is used for various objects in Appendix E that are not credentials. For example in the credential issuer metadata as in <a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#server_metadata_ldp_vc">E.1.3.2</a>. 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 (<a href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>) 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.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">The current specification explicitly requires JSON-LD processing for certain objects (beyond credentials) as Pedro noted - namely the <font face="Courier New">credentials_supported</font> and <font face="Courier New">credentials_definition</font>.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">The credential issuer metadata as defined for <a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-3">VC signed as a JWT, using JSON-LD and VC</a> and <a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-4">VC secured using Data Integrity, using JSON-LD, with proof suite requiring Linked Data canonicalization</a> contains the claim <font face="Courier New">credentials_supported</font> which is an array of supported credentials. E.1.3.2 states:</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">> Any object comprising <font face="Courier New">credentials_supported</font> parameter of Credential format <font face="Courier New">ldp_vc</font> MUST be processed using full JSON-LD processing.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I think this statement is misleading. It indicates that the objects in the <font face="Courier New">credentials_supported</font> 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 <font face="Courier New">credentials_supported</font>) 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. </div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto">There is a similar issue with the <font face="Courier New">credential_definition</font> claim. Currently, the draft reads (<a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-e.1.3.3">E.1.3.3</a>) as follows:</div><div dir="auto"><br></div><div dir="auto">> <font face="Courier New">credential_defintion</font>: REQUIRED. JSON object containing (and isolating) the detailed description of the credential type. This object MUST be processed using full JSON-LD processing …</div><div dir="auto"><br></div><div dir="auto">The question is actually not whether the current specification of the <font face="Courier New">credential_definition</font> claim (or an object in <span style="font-family: "Courier New";">credentials_supported</span>) 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).</div></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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 <a href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a> as the context (as currently required) is not appropriate. </div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">In the second case, remove the requirement regarding JSON-LD processing for the claims.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Regards,</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Judith</div><div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div>
</div>
<div><br><blockquote type="cite"><div>On 15 Feb 2023, at 22:45, David Chadwick via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div><p>Hi Pedro<br>
</p>
<div class="moz-cite-prefix">On 16/02/2023 04:58, Pedro Felix via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAM-Bv-qHxntX3sqjaH9EOJpGLDTU8nYTrPphfrUGFYzPSteHnA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi,
The latest OpenID4VCI spec
(<a class="moz-txt-link-freetext" href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html">https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html</a>)
requires that certain JSON objects "... MUST be processed using full
JSON-LD processing", namely credentials_supported and
credentials_definition (e.g
<a class="moz-txt-link-freetext" href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#section-e.1.3.3">https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#section-e.1.3.3</a>),
when the format is jwt_vc_json-ld or ldp_vc.</pre>
</blockquote>
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.<br>
<blockquote type="cite" cite="mid:CAM-Bv-qHxntX3sqjaH9EOJpGLDTU8nYTrPphfrUGFYzPSteHnA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
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 <a class="moz-txt-link-freetext" href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a> context
(credentialSubject maps to
<a class="moz-txt-link-freetext" href="https://www.w3.org/2018/credentials#credentialSubject">https://www.w3.org/2018/credentials#credentialSubject</a>)
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.</pre>
</blockquote><p>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)</p><p><br>
</p>
<blockquote type="cite" cite="mid:CAM-Bv-qHxntX3sqjaH9EOJpGLDTU8nYTrPphfrUGFYzPSteHnA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
So,
1) Doesn't the OpenID4VCI spec need to map those fields to full URIs,</pre>
</blockquote>
Not if they remain in the metadata file only<br>
<blockquote type="cite" cite="mid:CAM-Bv-qHxntX3sqjaH9EOJpGLDTU8nYTrPphfrUGFYzPSteHnA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-freetext" href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>?</pre>
</blockquote><p>Yes it would be best to, if it also says that these new
properties can be properties of the issued credentials</p><p>Kind regards</p><p>David<br>
</p>
<blockquote type="cite" cite="mid:CAM-Bv-qHxntX3sqjaH9EOJpGLDTU8nYTrPphfrUGFYzPSteHnA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
Thanks.
Regards,
Pedro
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>Openid-specs-ab mailing list<br>Openid-specs-ab@lists.openid.net<br>https://lists.openid.net/mailman/listinfo/openid-specs-ab<br></div></blockquote></div><br></body></html>