<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Nat<br>
    </p>
    <div class="moz-cite-prefix">On 13/05/2021 12:14, Nat Sakimura via
      Openid-specs-ab wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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. <br>
        </div>
      </div>
    </blockquote>
    <p>Its not quite as simple as store and forward as all VCs work in
      that mode. It is defined in the W3C standard to work that way. So
      without store and forward it is not W3C VC compliant.<br>
    </p>
    <p>The question is "are these VCs long lived and revocable (like
      X.509 PKCs) or short lived and not revocable (like OIDC claims)?"</p>
    <p>This is a much more interesting question, since the subject ID in
      the first case provides a long lived correlatable handle like an
      X.509 DN. In the second case the subject ID can be created
      dynamically on a transaction by transaction basis.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Since VC MUST identify the subject, it would have a subject
          identifier in it. <br>
        </div>
      </div>
    </blockquote>
    <p>Actually the VC standard also supports bearer credentials such as
      tickets to events that belong to whoever possesses them. In this
      case there is no subject identifier.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <div>Additionally, it may contain a Holder identifier. <br>
        </div>
      </div>
    </blockquote>
    <p>How this is performed is currently not standardised. So lets keep
      it simple for now and assume that the subject is the holder.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <div> </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?), <br>
        </div>
      </div>
    </blockquote>
    <p>this is not documented an any standard as far as I know. The W3C
      standard suggests several ways in which the relationship between
      the holder and subject can be identified, but these are only
      suggestions.<br>
    </p>
    <p>This is why I suggest we keep it simple for now, and only cater
      for subject=holder. Once this is documented to your satisfaction
      we can move on to the more complex cases of delegation of
      authority and power of attorney (guardianship).<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <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. <br>
        </div>
      </div>
    </blockquote>
    <p>It is IMPOSSIBLE for the subject to remain 100% anonymous. The
      fact that the claims (in most cases) contain one or more
      identifying attributes means that some PII is transferred from the
      issuer to the verifier. Pseudonymous is more realistic.
      Furthermore the issuer always knows who it has issued the VC to,
      and this has a unique serial number.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <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>
        </div>
      </div>
    </blockquote>
    <p>I dont see how it can. But maybe it does not need to, e.g. if the
      verifier is a ticket collector at a cinema</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <div>(2) How can Verifier verify the signature on VC? </div>
      </div>
    </blockquote>
    <p>With jwt the verifier gets the signature on the VC to verify. So
      that is easy. The same goes for the VP. <br>
    </p>
    <p>But that is not the interesting question. It is how can the
      verifier prove possession?. There are multiple ways the verifier
      can independently authenticate the holder if it needs to e.g. it
      can request that its un/pw be in the VP, it can look at the photo
      in the VC and compare it to the face of the person presenting the
      VP etc. But this is outside the scope of the W3C standard.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <div>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>
        </div>
      </div>
    </blockquote>
    <p>ZKPs only prove that the presenter knows a master secret and this
      can be shared between multiple users.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <div>(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>
    </blockquote>
    <p>this is why our implementation uses ephemeral keys</p>
    <p>Kind regards</p>
    <p>David<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJcjuEJCbU5aFbpZanLAfeQk9hGKAmyi60jsvcz1yXsN1hyW2w@mail.gmail.com">
      <div dir="ltr">
        <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"
            moz-do-not-send="true">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" moz-do-not-send="true">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" 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/"
                    target="_blank" 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>
                </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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
          <a
            href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
            rel="noreferrer" target="_blank" moz-do-not-send="true">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>
      <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>