<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Judith</p>
<p>thankyou for your excellent response. I agree with most of what
you say, but not the following "This object MUST be processed
using full JSON-LD processing". It is my understanding that the
protocol and metadata are pure JSON and should not be referred to
as JSON-LD. Thus the current text is wrong if it either states or
implies this. OTOH, the retrieved object may be a W3C Conformant
VC (in which case it MUST contain the @context property) but this
does not mean that the wallet has to perform any JSON LD
processing on it. On the contrary pure JSON processing is
sufficient if the semantics of JSON-LD are not required and JWT
proofs are being used (I am not sure if the same is true for LD
proofs). Interworking between JSON-LD processing and pure JSON
processing issuers and wallets has already been adequately
demonstrated (in the JFF plugfest). So I do not believe having an
@context property in a credential is an issue that OID4VCI should
be concerned with. Personally I do not think that our protocol
should be supporting non-standard credential formats (i.e. any
type of JWT) and should only support ISO mdl and W3C VCs either
JWT or LD-proofed (but I think I am in a minority here). However,
the W3C VC F2F this week has now agreed that verifiable
credentials must have an @context property. Other serialisations
that do not contain an @context property may be specified, but
mapping rules from these to W3C VCs must be defined for them to be
accepted in the W3C VC v2 recommendation. The mapping may be one
way (from serialisation X to W3C VCs) or bi-directional and
lossless. However, no examples of serialisation X have been fully
specified so far, so until they are I do not think OID4VCI should
include them (which currently it does).</p>
<p>Kind regards</p>
<p>David<br>
</p>
<div class="moz-cite-prefix">On 17/02/2023 01:25, Judith Kahrer via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:AC0F0572-0D2A-4225-8B81-2C5755EE05D5@curity.io">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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 <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab@lists.openid.net"><openid-specs-ab@lists.openid.net></a>
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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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 moz-txt-link-freetext" href="mailto:Openid-specs-ab@lists.openid.net" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" moz-do-not-send="true">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<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><br>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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>
</body>
</html>