<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 12, 2021, at 5:11 PM, Nat Sakimura via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi<div class=""><br class=""></div><div class=""><div class="">I have got a few generic questions regarding the verifiable presentation. </div><div class="">If any of you can help, it is much appreciated. </div><div class=""><ul class=""><li class="">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 class=""></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 class=""></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 class=""></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 class=""></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" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><ul class=""><li class="">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" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><ul class=""><li class="">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/" class="">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/" class="">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 class=""></div><div>-DW</div></div></body></html>