[Openid-specs-ab] Verifiable presentation question

Nat Sakimura nat at nat.consulting
Thu May 13 11:14:21 UTC 2021

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.

Since VC MUST identify the subject, it would have a subject identifier in
Additionally, it may contain a Holder identifier.

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
constructs a VP that includes claims included in VC and presents it to the

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.

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?
(2) How can Verifier verify the signature on VC? 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.
(3) Also, if there is a one-to-one relationship between the Holder and
Subject, Hoder cannot reveal its persistent identifiers or keys.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210513/d9af8b5f/attachment-0001.html>

More information about the Openid-specs-ab mailing list