<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 14/05/2021 15:54, Nat Sakimura
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJcjuE+o1R6oft6m006Ly=j4pKMkVxie-sf2=jOt_XdRBsoAxw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Thanks, David.
<div><br>
</div>
<div>That is very helpful. </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 8:57
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>Hi Nat<br>
</p>
<div>On 13/05/2021 12:14, Nat Sakimura via Openid-specs-ab
wrote:<br>
</div>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div>Right. OIDC generally opted for the latter and I was kind
of thinking that VC is taking the former approach but it
seems there are a lot of variations in VC. </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> </p>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div>My Bad. I just misread "A verifiable credential MUST have
a credentialSubject property." in Section 4.4. The "id"
property is optional so it can be committed. </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> </p>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div>OK. One reason I tend to try to delineate Holder and the
Subject is that I do think of a Malicious or Compromised
Holder besides PoA etc. <br>
</div>
</div>
</div>
</blockquote>
<br>
<p>I don't know of any way to determine if the holder's device has
been compromised and whether the RP is talking to the real owner
or to a thief/attacker. FIDO tries to do this with its ceremony,
but that can be broken. Even worse, the RP cannot tell if it is
the real holder with a gun held to his head by an attacker or a
holder freely entering into the relationship with the RP. So, it
is impossible to protect against every conceivable threat. We
should document our assumptions so that people know what the
boundaries of our proposal are, and what is out of scope.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJcjuE+o1R6oft6m006Ly=j4pKMkVxie-sf2=jOt_XdRBsoAxw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
<div>Hmmm. </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> </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">
<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>
</div>
</blockquote>
<div>Re: "IMPOSSIBLE", I suppose you are talking about long
term VC. Am I right? <br>
</div>
</div>
</div>
</blockquote>
<p>No short lived as well. Because the issuer always knows who it
has issued the VC to. And the RP knows who the issuer is. So the
RP can ask the Issuer to reveal the holder in cases of abuse. I
believe that even the ZKP anonymous credentials scheme wanted to
(or did) build this into their group signature scheme.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJcjuE+o1R6oft6m006Ly=j4pKMkVxie-sf2=jOt_XdRBsoAxw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
<div>I see. Thanks. </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> </p>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div>I see. </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> </p>
<blockquote type="cite">
<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">
<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>
</div>
</blockquote>
<div>Got it. One of the reasons I wrote about the delineation
of the subject and the holder is that I was wondering if
Holders can share the identifiers and use group signature to
avoid the linking of the subject through the holder
identification. Has there been any discussion on something
like it? <br>
</div>
</div>
</div>
</blockquote>
<p>I am not that knowledgable about the various ZKP schemes. You
need to ask a cryptographer.</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite"
cite="mid:CAJcjuE+o1R6oft6m006Ly=j4pKMkVxie-sf2=jOt_XdRBsoAxw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Best, </div>
<div><br>
</div>
<div>Nat </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>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<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"
target="_blank" 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">
<div dir="ltr">Nat Sakimura
<div>NAT.Consulting LLC</div>
</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>
</div>
</blockquote>
</body>
</html>