<div dir="ltr">Thanks, David W and David C, for your help. <div><br></div><div>Let's just think about the store and forward use-case, where the subject obtains VCs in advance and stores them in the Holder. </div><div><br></div><div>Since VC MUST identify the subject, it would have a subject identifier in it. </div><div>Additionally, it may contain a Holder identifier. </div><div><br></div><div>At a later point in time, Verifier asks for Verifiable Presentation to the subject through the Holder. </div><div>Holder creates proof with the consent of the Subject (where is it documented?), </div><div>constructs a VP that includes claims included in VC and presents it to the Verifier. </div><div><br></div><div>If the subject is OK to be correlated, the story is simple. However, if the subject wants to remain pseudonymous or anonymous, it gets complicated. </div><div><br></div><div>First, VP can now not include the Subject Identifier, as that would be correlatable. Rember that it is pre-issued and not dynamic. </div><div>My questions: </div><div><br></div><div>(1) How can Verifier establish the link between this subject-identifier-less VC and the proof in the VP? <br>(2) How can Verifier verify the signature on VC? Yes, ZKP etc., but then VC itself should not be present in the VP. Even the signature itself of VC will break pseudonymity, not to mention anonymity. <br>(3) Also, if there is a one-to-one relationship between the Holder and Subject, Hoder cannot reveal its persistent identifiers or keys. <br></div><div><br></div><div>Best, </div><div><br></div><div>Nat Sakimura</div><div><br></div><div><br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 3:33 PM David Chadwick via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Most of David Waite's points are correct but not all, see below<br>
</p>
<div>On 13/05/2021 03:48, David Waite via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite">
<br>
<div><br>
<blockquote type="cite">
<div>On May 12, 2021, at 5:11 PM, Nat Sakimura via
Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">Hi
<div><br>
</div>
<div>
<div>I have got a few generic questions
regarding the verifiable presentation. </div>
<div>If any of you can help, it is
much appreciated. </div>
<div>
<ul>
<li>How do the claims in the VC can be
bound to an ephemeral identifier and keys in a
trustworthy manner when presented to the RP. (What
is being written in the current Claims Aggregation
draft is a way of achieving it in the context of
regular OIDC response but it cannot be done
independently of the verified claims issuance.) </li>
</ul>
</div>
</div>
</div>
</div>
</blockquote>
<div>Typically you are doing a signature-based proof of
possession (based on a stable or ephemeral key pair) or doing
a zero knowledge proof of knowledge of a secret or private
key. The confirmation by the holder is what differentiates a
credential from a presentation.</div>
<div><br>
</div>
<div>Many use cases aim to isolate the issuer of a credential
from knowing when and to whom it is used, hence the inability
to do audience constraints for bearer confirmation.</div>
</div>
</blockquote>
<p>However, the holder is able to indicate audience restrictions by
inserting this into the presentation, as described in the W3C VC
recommendation.</p>
<p>This is the natural way of presenting credentials, and mirrors
the way we work today with plastic cards. The card issuer does not
place audience restrictions on the card (and if they do they can
be ignored by both the holder and verifier). Instead the card
holder determines the audience when presenting the card.<br>
</p>
<blockquote type="cite">
<div>
<div><br>
</div>
<div>When you are aggregating credentials from multiple sources
into presentation(s), you can no longer count on a single
authoritative subject identifier. </div>
</div>
</blockquote>
<p>this is not true. A single ephemeral public key can be inserted
into all the short lived issued credentials and the holder can
then prove possession of them all.<br>
</p>
<blockquote type="cite">
<div>
<div>So you need to provide proper confirmation(s), or else the
credentials are (comparatively weaker) evidence.</div>
</div>
</blockquote>
<p>The evidence is just as strong in the above ephemeral case.</p>
<p>But as you point out below there are correlation risks. But these
are no more than, and most probably less than, the risks
associated with sending email addresses or telephone numbers etc
as claims. <br>
</p>
<blockquote type="cite">
<div>
<div><br>
</div>
<div>If the subject identifier is resolvable (such as a DID with
verification methods registered, or a HTTPS URL with
appropriate .well-known metadata), the confirmation method may
be externally resolved and mutable. There are correlation
risks for using a subject identifier here, so this winds up
being most useful for public credentials.</div>
</div>
</blockquote>
<p>I disagree with this, since correlation between the verifier and
issuer is needed in order to handle cases of abuse by the holder.
I would suggest that verifiers who have no way of determining who
user is in cases of abuse are unlikely to accept such credentials.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>A single proof mechanism may not be applicable to all of the
credentials when multiple are being returned, hence the ability
for a VP to contain multiple VCs, and for multiple VPs to also
be returned.</div>
</blockquote>
<p>Even when a single proof mechanism is applicable there is still
the requirement for a VP to contain multiple VCs - when each VC is
issued by a different authoritative source</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<ul>
<li>I do not know ZKP almost at all but I
was assuming that there would be several exchanges
between the verifier and the holder. However, the
current OIDC4VCO draft seems to be just talking
about a simple request/response protocol: It just
looks to me to be defining adding a member
parallel to id_token in the request. Defining
another format for the response. Am I missing
something? </li>
</ul>
</div>
</div>
</div>
</div>
</blockquote>
I believe these are typically 1-round or non-interactive proofs,
hence letting them fit into a request/response model.</div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<ul>
<li>Where can I find the authoritative copy
of W3C Verifiable Presentation spec? </li>
</ul>
</div>
</div>
</div>
</div>
</blockquote>
<div>The only recommendation is the Verifiable Credentials Data
Model at <a href="https://www.w3.org/TR/vc-data-model/" target="_blank">https://www.w3.org/TR/vc-data-model/</a>
. There is a WG note with use cases at <a href="https://www.w3.org/TR/vc-use-cases/" target="_blank">https://www.w3.org/TR/vc-use-cases/</a>
. LD-Proofs are at draft charter stage, with a maze of draft
specifications by the W3C CCG.</div>
<div><br>
</div>
<div>-DW</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Nat Sakimura<div>NAT.Consulting LLC</div></div></div>