<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Most of David Waite's points are correct but not all, see below<br>
</p>
<div class="moz-cite-prefix">On 13/05/2021 03:48, David Waite via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:629E109B-829A-4F1F-8C50-23B32A57BECA@alkaline-solutions.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On May 12, 2021, at 5:11 PM, Nat Sakimura via
Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net" class=""
moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi
<div class=""><br class="">
</div>
<div class="">
<div class="">I have got a few generic questions
regarding the verifiable presentation. </div>
<div class="">If any of you can help, it is
much appreciated. </div>
<div class="">
<ul class="">
<li class="">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 class="">
</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"
cite="mid:629E109B-829A-4F1F-8C50-23B32A57BECA@alkaline-solutions.com">
<div>
<div><br class="">
</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"
cite="mid:629E109B-829A-4F1F-8C50-23B32A57BECA@alkaline-solutions.com">
<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"
cite="mid:629E109B-829A-4F1F-8C50-23B32A57BECA@alkaline-solutions.com">
<div>
<div><br class="">
</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"
cite="mid:629E109B-829A-4F1F-8C50-23B32A57BECA@alkaline-solutions.com">
<div><br class="">
</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"
cite="mid:629E109B-829A-4F1F-8C50-23B32A57BECA@alkaline-solutions.com">
<div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<ul class="">
<li class="">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" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<ul class="">
<li class="">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/"
class="" moz-do-not-send="true">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/" class=""
moz-do-not-send="true">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 class="">
</div>
<div>-DW</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></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="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>