<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>