<div dir="ltr">This needs to be unpacked a little.<div><br><div>1. there is no VP spec, there is only a VC spec.</div><div>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.</div><div>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.</div><div>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.</div><div>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.</div><div>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.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 7:49 PM David Waite via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">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 style="overflow-wrap: break-word;"><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">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><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. So you need to provide proper confirmation(s), or else the credentials are (comparatively weaker) evidence.</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><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><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">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">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></div>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>