[Openid-specs-ab] Verifiable presentation question

Fri May 14 14:54:48 UTC 2021

Thanks, David.

That is very helpful.

On Thu, May 13, 2021 at 8:57 PM David Chadwick via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Nat
> On 13/05/2021 12:14, Nat Sakimura via Openid-specs-ab wrote:
>
> Thanks, David W and David C, for your help.
>
> Let's just think about the store and forward use-case, where the subject
> obtains VCs in advance and stores them in the Holder.
>
> 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.
>
> The question is "are these VCs long lived and revocable (like X.509 PKCs)
> or short lived and not revocable (like OIDC claims)?"
>
> 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.
>
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.

>
> Since VC MUST identify the subject, it would have a subject identifier in
> it.
>
> 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.
>
>
> 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.

> Additionally, it may contain a Holder identifier.
>
> How this is performed is currently not standardised. So lets keep it
> simple for now and assume that the subject is the holder.
>
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.

>
> At a later point in time, Verifier asks for Verifiable Presentation to the
> subject through the Holder.
> Holder creates proof with the consent of the Subject (where is it
> documented?),
>
> 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.
>
Hmmm.

> 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).
>
> constructs a VP that includes claims included in VC and presents it to the
> Verifier.
>
> 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.
>
> 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.
>
Re: "IMPOSSIBLE", I suppose you are talking about long term VC. Am I right?

> First, VP can now not include the Subject Identifier, as that would be
> correlatable. Rember that it is pre-issued and not dynamic.
> My questions:
>
> (1) How can Verifier establish the link between this
> subject-identifier-less VC and the proof in the VP?
>
> 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
>
>
> I see. Thanks.

> (2) How can Verifier verify the signature on VC?
>
> With jwt the verifier gets the signature on the VC to verify. So that is
> easy. The same goes for the VP.
>
> 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.
>
>
> I see.

> 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.
>
> ZKPs only prove that the presenter knows a master secret and this can be
> shared between multiple users.
>
> (3) Also, if there is a one-to-one relationship between the Holder and
> Subject, Hoder cannot reveal its persistent identifiers or keys.
>
> this is why our implementation uses ephemeral keys
>
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?

Best,

Nat

> Kind regards
>
> David
>
>
> Best,
>
> Nat Sakimura
>
>
>
>
>
> On Thu, May 13, 2021 at 3:33 PM David Chadwick via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> Most of David Waite's points are correct but not all, see below
>> On 13/05/2021 03:48, David Waite via Openid-specs-ab wrote:
>>
>>
>>
>> On May 12, 2021, at 5:11 PM, Nat Sakimura via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>> Hi
>>
>> I have got a few generic questions regarding the verifiable presentation.
>> If any of you can help, it is much appreciated.
>>
>>    - 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.)
>>
>> 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.
>>
>> 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.
>>
>> However, the holder is able to indicate audience restrictions by
>> inserting this into the presentation, as described in the W3C VC
>> recommendation.
>>
>> 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.
>>
>>
>> When you are aggregating credentials from multiple sources into
>> presentation(s), you can no longer count on a single authoritative subject
>> identifier.
>>
>> 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.
>>
>> So you need to provide proper confirmation(s), or else the credentials
>> are (comparatively weaker) evidence.
>>
>> The evidence is just as strong in the above ephemeral case.
>>
>> 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.
>>
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> 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.
>>
>> 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
>>
>> Kind regards
>>
>> David
>>
>>
>>    - 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?
>>
>> I believe these are typically 1-round or non-interactive proofs, hence
>> letting them fit into a request/response model.
>>
>>
>>    - Where can I find the authoritative copy of W3C Verifiable
>>    Presentation spec?
>>
>> The only recommendation is the Verifiable Credentials Data Model at
>> https://www.w3.org/TR/vc-data-model/ . There is a WG note with use cases
>> at https://www.w3.org/TR/vc-use-cases/ . LD-Proofs are at draft charter
>> stage, with a maze of draft specifications by the W3C CCG.
>>
>> -DW
>>
>> _______________________________________________
>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
> --
> Nat Sakimura
> NAT.Consulting LLC
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-- 
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210514/6acb01e5/attachment.html>