[Openid-specs-ab] Verifiable presentation question

Tom Jones thomasclinganjones at gmail.com
Thu May 13 03:06:54 UTC 2021


This needs to be unpacked a little.

1. there is no VP spec, there is only a VC spec.
2. There is no case where a naked VC should ever go to a verifier - aka
relying party. I would state that even stronger. Naked creds should NEVER
appear in an OpenID protocol.
3. But there is a case where a simple VC can be encapsulated inside a VP,
which really subverts the goals of the spec which is to allow the user
selective disclosure.
4. Daniel is working on a PE spec(let) that describes how a request to a
wallet, with VCs, can be returned as a VP.
5. There is no concept worked out in CCG of a user having more than one
wallet. Which makes the problem of a RP creating a request
incomprehensibly difficult, if not impossible.
6. I worry a lot about any effort to create an ad hoc request from an RP
for aggregated claims or VPs. I really cannot understand how that might
work and believe it should be the primary focus of AB/C for the immediate
future.

Be the change you want to see in the world ..tom


On Wed, May 12, 2021 at 7:49 PM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> 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.
>
> When you are aggregating credentials from multiple sources into
> presentation(s), you can no longer count on a single authoritative subject
> identifier. So you need to provide proper confirmation(s), or else the
> credentials are (comparatively weaker) evidence.
>
> 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.
>
> 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.
>
>
>    - 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 list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210512/d155e16f/attachment.html>


More information about the Openid-specs-ab mailing list