<html><body><div dir="ltr"><div dir="ltr">Francisco, thanks for the detailed scenario.</div><div dir="ltr"><br></div><div dir="ltr">The W3C Verifiable Credentials Data Model intentionally allows for different approaches to proving possession of credentials beyond strict cryptographic holder binding. This flexibility exists because:</div><div dir="ltr"><br></div><div dir="ltr">1. There are valid use cases where a credential's subject may not be identified by a single identifier, and where attribute-based verification is more appropriate or privacy-preserving.</div><div dir="ltr"><br></div><div dir="ltr">2. The determination of whether a holder is authorized to present a credential may require a semantic understanding of the credential contents and context that exists at a layer above the cryptographic mechanisms.</div><div dir="ltr"><br></div><div dir="ltr">3. Some credentials are intentionally designed to be presented by authorized agents or delegates (e.g. legal guardians, spouses) rather than just the subject.</div><div dir="ltr"><br></div><div dir="ltr">That said, I agree that the specification could be clearer about:</div><div dir="ltr"><br></div><div dir="ltr">1. The relationship between VP holder binding and VC holder binding</div><div dir="ltr">2. The responsibility of verifiers to validate this relationship when required by their trust framework</div><div dir="ltr">3. The security implications of different holder binding approaches</div><div dir="ltr"><br></div><div dir="ltr">Section 7.6 could be improved to note that verifiers must:</div><div dir="ltr">- Validate any holder binding mechanisms required by the credential format</div><div dir="ltr">- Verify the relationship between the VP holder and the VC subject according to their trust framework requirements</div><div dir="ltr">- Consider potential relay attacks in their security model</div><div dir="ltr"><br></div><div dir="ltr">I do not think this is serious enough to block progression of the specification. Each implementer must understand the specifics of credential formats they support. The language can (and should) be improved. If you'd like, let's please collaborate on some text that would address your concerns here.</div><div dir="ltr"><br></div><div dir="ltr">Gabe</div></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Oct 23, 2024 at 9:50:03 PM, Francisco Corella <<a href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</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" type="cite">
<div>
<div>
<meta name="Generator" content="Amazon WorkMail v3.1.2911.0">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>RE: [Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft</title>
</div>
<div>
<div><div></div><div><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Hi Gabe,</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Section 7.6 does not address the problem.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">A verifier that follows the instructions in Section 7.6 (the Victim Verifier) will fail to detect the following impersonation attack against the subject of a credential (the Victim Subject):</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">1. The Attacker sets up a Malicious Verifier, and tricks the Victim Subject into authenticating to it.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">2. The wallet of the Victim Subject makes a credential presentation to the Malicious Verifier like the one of Example B.1.2.3, where the Victim Subject is the subject of the VC and the holder of the VP.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">3. The Attacker sets up its own wallet and copies the VC of the Victim Subject from the Malicious Verifier to the its own wallet.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">4. Using its own wallet, the Attacker makes a credential presentation to the Victim Verifier like the one of Example B.1.2.3, where the Victim Subject is the subject of the VC but the Attacker is the holder of VP.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">The instructions in Section 7.6 do not detect the above attack because:</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 1 requires validation of the format of the VP token, which will be correct if the Attacker has implemented its own wallet correctly.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 2 requires validating the integrity and authenticity of the VP, which will be valid if the Attacker has implemented its own wallet correctly.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 2 also requires validating the "Holder Binding of any Verifiable Presentation provided in the VP Token". This could potentially catch the attack if the Victim Verifier looked up Section 2 and found what I cited in my first message: "a Verifiable Credential with Cryptographic Holder Binding contains a public key or a reference to a public key that matches to the private key controlled by the Holder." But Section 2 is talking about holder binding of a VC, while Instruction 2 Section 7.2 is talking about holder binding of a VP and makes no reference to a VC or to the need to look for cross-reference between a VC and a VP. The Victim Verifier is likely to interpret "Holder Binding" of the VP as the challenge being signed by the holder, which will be the case since the holder is the Attacker.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 2 also requires making the checks for preventing replay of of the VP Token of Section 13.1, which the VP Token created by the Attacker's wallet will pass.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 3 requires checking the issuer's signature in the VC, which will be valid in the Victim Subject's credential.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 4 requires checking that the claims in the VC meet all criteria defined in the query in the Authorization Request, which will be the case for the Victim Subject's credential if the Attacker's wallet is implemented correctly.</p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> </p><p style="margin:0px;font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">Instruction 5 requires checking the trust requirements of the of the Victim Verifier such as revocation checks of trust frameworks are satisfied, which will be the case for the Victim Subject's credential.<br> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><blockquote style="border-left:2px solid rgb(176,176,183);margin-left:5px;margin-right:0px;padding-left:5px">-----Original message-----<br><strong>From:</strong> Gabe Cohen <gabe@tbd.email><br><strong>Sent:</strong> Wednesday, October 23 2024, 3:13 pm<br><strong>To:</strong> <a href="mailto:peace@acm.org">peace@acm.org</a> <<a href="mailto:peace@acm.org">peace@acm.org</a>><br><strong>Cc:</strong> Francisco Corella <<a href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</a>>; Orie Steele <orie@transmute.industries>; Veronica Wojnas <<a href="mailto:v.wojnas@gmail.com">v.wojnas@gmail.com</a>>; Sukhi Chuhan <<a href="mailto:sukhpreetchuhan@gmail.com">sukhpreetchuhan@gmail.com</a>>; Digital Credentials Protocols List <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><strong>Subject:</strong> Re: [Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft<br> <div dir="ltr">Orie’s solution is fine, but not necessary. There is not a requirement that the one presenting the credential is understood to be the subject of the credential upon issuance. It’s possible that the presentation would be accepted from a wide array of holders or presenters. </div><div dir="ltr"> </div><div dir="ltr">It’s also possible that the same individual / organization could be identified by multiple DIDs/keys, so adding an id property to the credentialSubject would be insufficient or worse, misleading.</div><div dir="ltr"> </div><div dir="ltr">There is a practical concern, as you note, about <em>how does the verifier know to accept this presentation</em> and that’s not purely a technical problem, nor should it be addressed in full by the specification. The specification can reference guidance for securing W3C VCs which includes using fields like cnf (see that <a title="This external link opens in a new window" href="https://w3c.github.io/vc-jose-cose/#cnf">here</a>).</div><div dir="ltr"> </div><div dir="ltr">The spec should speak to determining how to resolve the keys of the presenter and verify the presentation.</div><div dir="ltr"> </div><div dir="ltr">I believe the existing language here is sufficient — <a title="This external link opens in a new window" href="https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-7.6">https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-7.6</a>.</div><div dir="ltr"> </div><div dir="ltr">Gabe</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Oct 23, 2024 at 1:54:44 PM, Tom Jones <<a title="This external link opens in a new window" href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</a>> wrote:</div><blockquote type="cite" style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote"><div dir="ltr">i never noticed that the cred subject is optional. Not sure how that ever happened?<div>The other issue that the subject might not be the same as the holder has been a problem from the beginning.</div><div>It is not possible for a government to issue digital credentials that require the subject to own a smartphone.</div><div>The following report from Kantara addresses that issue</div><div>file:///C:/Users/rp_to/Downloads/Kantara-Initiative-RIUP-Digital-Identifier-Inclusion-Final-Report-1.pdf</div><div> <div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="-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"><span style="background-color:rgb(242,242,242);font-size:14px">Peace ..tom jones</span></font></div></div></div></div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 23, 2024 at 1:47 PM Orie Steele via Openid-specs-digital-credentials-protocols <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:</div><blockquote style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote"><div dir="ltr">Then the issue is solved by doing this:<br><br><font face="monospace">{<br> "@context": [<br> "<a title="This external link opens in a new window" href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>"<br> ],<br> "type": [<br> "VerifiablePresentation"<br> ],<br> "verifiableCredential": [<br> {<br> "@context": [<br> "<a title="This external link opens in a new window" href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>",<br> "<a title="This external link opens in a new window" href="https://www.w3.org/2018/credentials/examples/v1">https://www.w3.org/2018/credentials/examples/v1</a>"<br> ],<br> "id": "<a title="This external link opens in a new window" href="https://example.com/credentials/1872">https://example.com/credentials/1872</a>",<br> "type": [<br> "VerifiableCredential",<br> "IDCredential"<br> ],<br> "issuer": {<br> "id": "did:example:issuer"<br> },<br> "issuanceDate": "2010-01-01T19:23:24Z",<br> </font><font face="monospace"><strong>"cnf": { "kid": "</strong></font><span style="font-family:monospace"><strong>did:example:holder" },</strong></span><br><font face="monospace"> "credentialSubject": {<br> <strong>"id": "</strong></font><span style="font-family:monospace"><strong>did:example:holder",</strong></span><br><font face="monospace"> "given_name": "Max",<br> "family_name": "Mustermann",<br> "birthdate": "1998-01-11",<br> "address": {<br> "street_address": "Sandanger 25",<br> "locality": "Musterstadt",<br> "postal_code": "123456",<br> "country": "DE"<br> }<br> },<br> "proof": {<br> "type": "Ed25519Signature2018",<br> "created": "2021-03-19T15:30:15Z",<br> "jws": "eyJhb...JQdBw",<br> "proofPurpose": "assertionMethod",<br> "verificationMethod": "did:example:issuer#keys-1"<br> }<br> }<br> ],<br> "id": "ebc6f1c2",<br> "holder": "did:example:holder",<br> "proof": {<br> "type": "Ed25519Signature2018",<br> "created": "2021-03-19T15:30:15Z",<br> "challenge": "n-0S6_WzA2Mj",<br> "domain": "<a title="This external link opens in a new window" href="https://client.example.org/cb">https://client.example.org/cb</a>",<br> "jws": "eyJhb...IAoDA",<br> "proofPurpose": "authentication",<br> "verificationMethod": "did:example:holder#key-1"<br> }<br>}</font><br><br>Per the W3C VCDM the credential subject id is optional, as is "cryptographic binding" between credentials and subjects / holders using mechanisms like "cnf" or "DIDs".<br><br>Your suggestion is that the error in this example is grounds for not progressing the document, can you propose a solution?<br><br>There are lots of other problems with this example such as being for VCDM v1 (v2 is in progress right now, and including data integrity proofs that have been deprecated Ed25519Signature2018 (<a title="This external link opens in a new window" href="https://w3c-ccg.github.io/lds-ed25519-2018/">https://w3c-ccg.github.io/lds-ed25519-2018/</a>) is now: <a title="This external link opens in a new window" href="https://www.w3.org/TR/vc-di-eddsa/">https://www.w3.org/TR/vc-di-eddsa</a><br><br>I recommend removing the example, or updating it to support version 2.<br><br>Regards,<br><br>OS<br><br><br><br><br> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 23, 2024 at 2:55 PM Francisco Corella <<a title="This external link opens in a new window" href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</a>> wrote:</div><blockquote style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote"><div><div><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">The issue is NOT how you resolve DIDs, nor any other technical details of decentralized identifiers.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">The issue is that there is no relationship between the credential subject and the holder of the presentation that can be cryptographically verified by the relying party.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Francisco</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><blockquote style="border-left:2px solid rgb(176,176,183);margin-left:5px;margin-right:0px;padding-left:5px">-----Original message-----<br><strong>From:</strong> Orie Steele <orie@transmute.industries><br><strong>Sent:</strong> Wednesday, October 23 2024, 12:48 pm<br><strong>To:</strong> Digital Credentials Protocols List <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><strong>Cc:</strong> Gabe Cohen <gabe@tbd.email>; Francisco Corella <<a title="This external link opens in a new window" href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</a>>; Veronica Wojnas <<a title="This external link opens in a new window" href="mailto:v.wojnas@gmail.com">v.wojnas@gmail.com</a>>; Sukhi Chuhan <<a title="This external link opens in a new window" href="mailto:sukhpreetchuhan@gmail.com">sukhpreetchuhan@gmail.com</a>><br><strong>Subject:</strong> Re: [Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft<br> <div dir="ltr">The idea with these JSON-LD graph node identifiers, is that you have some document loader that resolves the identifiers to cryptographic material or other credentials.<br><br>So in W3C VCDM where you see:<br><br><font face="monospace">kid: did:example:holder#key-1</font><br><br>You can mentally replace that with:<br><br><font face="monospace">- urn:ietf:params:oauth:ckt:sha-256:SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w<br>- urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs</font><br><br><font face="arial, sans-serif">And then assume that *somehow* the issuers, holders and verifiers have all agreed to resolve key identifiers to public keys the same way, and that they confirm signatures the same way.<br><br>In terms of "credential binding", you can use the "cnf" claim in W3C VCDM credentials just like you can use it with CWTs / JWTs.<br><br>- </font><a title="This external link opens in a new window" href="https://www.iana.org/assignments/cwt/cwt.xhtml#confirmation-methods">https://www.iana.org/assignments/cwt/cwt.xhtml#confirmation-methods</a><br><font face="arial, sans-serif">- </font><a title="This external link opens in a new window" href="https://www.iana.org/assignments/jwt/jwt.xhtml#confirmation-methods">https://www.iana.org/assignments/jwt/jwt.xhtml#confirmation-methods</a><br><br><font face="arial, sans-serif">From this view a "DID URL" aka "JSON-LD graph node identifier for a verification method", is just a special case of "weird looking" kid.<br><br>Notice that "kid" is in both registries as a valid confirmation method.<br><br>I'd suggest removing the DID examples from this specification before publishing or documenting what I have written above in the specification.<br><br>OS</font><br> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 23, 2024 at 2:26 PM Francisco Corella via Openid-specs-digital-credentials-protocols <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:</div><blockquote style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote"><div><div><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">That reference is not in the credential, it's in the presentation. And it is not a reference to the subject of the credential.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Even if the verifier were able to find the public key of the holder in the DID document of the holder,</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">it would no way of verifying cryptographically that the credential was issued to <span style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small">did:example:holder.</span></p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Francisco</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><blockquote style="border-left:2px solid rgb(176,176,183);margin-left:5px;margin-right:0px;padding-left:5px">-----Original message-----<br><strong>From:</strong> Gabe Cohen <gabe@tbd.email><br><strong>Sent:</strong> Wednesday, October 23 2024, 12:01 pm<br><strong>To:</strong> Digital Credentials Protocols List <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><strong>Cc:</strong> Francisco Corella <<a title="This external link opens in a new window" href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</a>>; Veronica Wojnas <<a title="This external link opens in a new window" href="mailto:v.wojnas@gmail.com">v.wojnas@gmail.com</a>>; Sukhi Chuhan <<a title="This external link opens in a new window" href="mailto:sukhpreetchuhan@gmail.com">sukhpreetchuhan@gmail.com</a>><br><strong>Subject:</strong> Re: [Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft<br> <div dir="ltr">There is a reference to it in what you’ve quoted</div><div dir="ltr"> </div><blockquote type="cite" style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote"><div dir="ltr"><span style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small"> "verificationMethod": "did:example:holder#key-1"</span></div></blockquote><div> </div><div dir="ltr">If your implementation understands DIDs then this is a standard way to express referencing key material in a DID Document.</div><div dir="ltr"> </div><div dir="ltr">The examples do need to be updated, however, I would not classify this as a <em>fundamental security flaw</em>. I have an <a title="This external link opens in a new window" href="https://github.com/openid/OpenID4VP/issues/5">issue to make the W3C VC</a> examples better. </div><div dir="ltr"> </div><div dir="ltr">Gabe</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Oct 23, 2024 at 11:48:26 AM, Francisco Corella via Openid-specs-digital-credentials-protocols <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:</div><blockquote type="cite" style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote"><div><div> </div><div><div><div> </div><div><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Hello Mike,</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Thank you for sending the last call and the current Editor's draft of the OpenID4VP specification.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">I think the draft is not ready because it has a fundamental security flaw.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Section 2 says:</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Cryptographic Holder Binding:<br>Ability of the Holder to prove legitimate possession of a Verifiable Credential by proving control over the same private key during the issuance and presentation. Mechanism might depend on the Credential Format. For example, in jwt_vc_json Credential Format, a Verifiable Credential with Cryptographic Holder Binding contains a public key or a reference to a public key that matches to the private key controlled by the Holder.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">But Section B.1.2.3 has the following example of a verifiable presentation of a verifiable credential:</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">{<br> "@context": [<br> "<a title="This external link opens in a new window" href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>"<br> ],<br> "type": [<br> "VerifiablePresentation"<br> ],<br> "verifiableCredential": [<br> {<br> "@context": [<br> "<a title="This external link opens in a new window" href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>",<br> "<a title="This external link opens in a new window" href="https://www.w3.org/2018/credentials/examples/v1">https://www.w3.org/2018/credentials/examples/v1</a>"<br> ],<br> "id": "<a title="This external link opens in a new window" href="https://example.com/credentials/1872">https://example.com/credentials/1872</a>",<br> "type": [<br> "VerifiableCredential",<br> "IDCredential"<br> ],<br> "issuer": {<br> "id": "did:example:issuer"<br> },<br> "issuanceDate": "2010-01-01T19:23:24Z",<br> "credentialSubject": {<br> "given_name": "Max",<br> "family_name": "Mustermann",<br> "birthdate": "1998-01-11",<br> "address": {<br> "street_address": "Sandanger 25",<br> "locality": "Musterstadt",<br> "postal_code": "123456",<br> "country": "DE"<br> }<br> },<br> "proof": {<br> "type": "Ed25519Signature2018",<br> "created": "2021-03-19T15:30:15Z",<br> "jws": "eyJhb...JQdBw",<br> "proofPurpose": "assertionMethod",<br> "verificationMethod": "did:example:issuer#keys-1"<br> }<br> }<br> ],<br> "id": "ebc6f1c2",<br> "holder": "did:example:holder",<br> "proof": {<br> "type": "Ed25519Signature2018",<br> "created": "2021-03-19T15:30:15Z",<br> "challenge": "n-0S6_WzA2Mj",<br> "domain": "<a title="This external link opens in a new window" href="https://client.example.org/cb">https://client.example.org/cb</a>",<br> "jws": "eyJhb...IAoDA",<br> "proofPurpose": "authentication",<br> "verificationMethod": "did:example:holder#key-1"<br> }<br>}</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">The public key of the holder is "did:example:holder#key-1". There is no reference to it in the verifiable credential, so cryptographic holder binding cannot be verified.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">The root of this problem is that, in a verifiable credential, the signature of the issuer does not cover the public key of the subject.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">I plan to call a session at next week's IIW to discuss this issue.</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Best regards,</p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px"> </p><p style="font-family:Arial,Tahoma,Helvetica,sans-serif;font-size:small;margin:0px">Francisco<br> </p><blockquote style="border-left:2px solid rgb(176,176,183);margin-left:5px;margin-right:0px;padding-left:5px">-----Original message-----<br><strong>From:</strong> Michael Jones via Openid-specs-digital-credentials-protocols <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><strong>Sent:</strong> Wednesday, October 23 2024, 7:34 am<br><strong>To:</strong> <a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a> <<a title="This external link opens in a new window" href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><strong>Cc:</strong> Michael Jones <<a title="This external link opens in a new window" href="mailto:michael_b_jones@hotmail.com">michael_b_jones@hotmail.com</a>><br><strong>Subject:</strong> [Openid-specs-digital-credentials-protocols] FW: Working group last call for proposed OpenID4VP Implementer's Draft<br> <div><p class="MsoNormal"><span style="font-size:11pt">FYI</span></p><p class="MsoNormal"><span style="font-size:11pt"> </span></p><div><div style="border-bottom:none;border-left:none;border-right:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><strong><span style="font-family:Calibri,sans-serif;font-size:11pt">From:</span></strong><span style="font-family:Calibri,sans-serif;font-size:11pt"> Openid-specs-ab <<a title="This external link opens in a new window" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>> <strong>On Behalf Of </strong>Michael Jones via Openid-specs-ab<br><strong>Sent:</strong> Wednesday, October 23, 2024 7:31 AM<br><strong>To:</strong> <a title="This external link opens in a new window" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br><strong>Cc:</strong> Michael Jones <<a title="This external link opens in a new window" href="mailto:michael_b_jones@hotmail.com">michael_b_jones@hotmail.com</a>><br><strong>Subject:</strong> [Openid-specs-ab] Working group last call for proposed OpenID4VP Implementer's Draft</span></p></div></div><p class="MsoNormal"> </p><p class="MsoNormal">Dear OpenID Connect Working Group,</p><p class="MsoNormal"> </p><p class="MsoNormal">We would like to get working group consensus that the current OpenID4VP draft is ready to start the Implementer’s draft approval process. Please respond to this e-mail within the next week, by Wednesday, October 30th end of business hours in Pacific Time, saying whether you believe the current draft should proceed or not.</p><p class="MsoNormal"> </p><p class="MsoNormal">The current OpenID4VP document to be reviewed can be found here: <a title="This external link opens in a new window" href="https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html">https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html</a>.</p><p class="MsoNormal"> </p><p class="MsoNormal">The details of the Implementer’s Draft approval process can be found here: <a title="This external link opens in a new window" href="https://openid.net/wg/resources/approving-specifications/">https://openid.net/wg/resources/approving-specifications/</a>. This e-mail is about the first bullet point on this list, which is sometimes called Working Group Last Call. Following that, there’s a 45-day Foundation-wide review, followed by a 7-day voting period. (The poll itself will actually open 7 days before the end of the Foundation-wide review ends.) If all goes smoothly, the voting will hopefully start on Monday, 16th December.</p><p class="MsoNormal"> </p><p class="MsoNormal">As shared on the working group calls, completing this Implementer’s Draft process promptly is an important step in obtaining IPR commitments for the specification, thereby enabling the DCP working group to adopt it. This will allow the DCP WG to hopefully publish a final specification by the end of March for inclusion into the EUDI implementing acts. We hope to get implementers’ feedback on this draft over the next few months so we can continue to perfect the specification before it becomes final.</p><p class="MsoNormal"> </p><p class="MsoNormal"><span style="font-size:11pt"> -- Mike (writing as working group chair)</span></p><p class="MsoNormal"><span style="font-size:11pt"> </span></p><p class="MsoNormal"><span style="font-size:11pt">P.S. Thanks to Joseph Heenan for drafting most of the text above!</span></p><p class="MsoNormal"><span style="font-size:11pt"> </span></p></div><pre>--
Openid-specs-digital-credentials-protocols mailing list
<a title="This external link opens in a new window" href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net">Openid-specs-digital-credentials-protocols@lists.openid.net</a>
<a title="This external link opens in a new window" href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a>
</pre></blockquote></div></div></div></div><div><div>--<br>Openid-specs-digital-credentials-protocols mailing list<br><a title="This external link opens in a new window" href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br><a title="This external link opens in a new window" href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a></div></div></blockquote></div></blockquote></div></div>--<br>Openid-specs-digital-credentials-protocols mailing list<br><a title="This external link opens in a new window" href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br><a title="This external link opens in a new window" href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a></blockquote></div> <div> </div><span class="gmail_signature_prefix">-- </span><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p dir="ltr" style="margin-bottom:0pt;margin-top:0pt"> </p><p dir="ltr" style="margin-bottom:0pt;margin-top:0pt;padding:10pt 0pt"><span><strong>ORIE STEELE</strong><br><span style="background-color:transparent;color:rgb(32,18,77);font-family:Arial;font-size:10pt">Chief Technology Officer</span><br><span style="background-color:transparent;color:rgb(32,18,77);font-family:Arial;font-size:8pt">www.transmute.industries</span></span></p><p dir="ltr" style="margin-bottom:0pt;margin-top:0pt;padding:0pt 0pt 10pt"><span><a title="This external link opens in a new window" href="https://transmute.industries"><img width="96" height="22" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></a></span></p></div></div></div></div></div></div></blockquote></div></div></blockquote></div> <div> </div><span class="gmail_signature_prefix">-- </span><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p dir="ltr" style="margin-bottom:0pt;margin-top:0pt"> </p><p dir="ltr" style="margin-bottom:0pt;margin-top:0pt;padding:10pt 0pt"><span><strong>ORIE STEELE</strong><br><span style="background-color:transparent;color:rgb(32,18,77);font-family:Arial;font-size:10pt">Chief Technology Officer</span><br><span style="background-color:transparent;color:rgb(32,18,77);font-family:Arial;font-size:8pt">www.transmute.industries</span></span></p><p dir="ltr" style="margin-bottom:0pt;margin-top:0pt;padding:0pt 0pt 10pt"><span><a title="This external link opens in a new window" href="https://transmute.industries"><img width="96" height="22" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></a></span></p></div></div></div></div></div></div> --<br>Openid-specs-digital-credentials-protocols mailing list<br><a title="This external link opens in a new window" href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br><a title="This external link opens in a new window" href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a></blockquote></div></blockquote></div></blockquote></div></div>
</div>
</div>
</blockquote>
</div></body></html>