[Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft

Wed Oct 23 19:25:47 UTC 2024

That reference is not in the credential, it's in the presentation.  And it is not a reference to the subject of the credential.

Even if the verifier were able to find the public key of the holder in the DID document of the holder,

it would no way of verifying cryptographically that the credential was issued to did:example:holder.

Francisco

-----Original message-----
From: Gabe Cohen <gabe at tbd.email>
Sent: Wednesday, October 23 2024, 12:01 pm
To: Digital Credentials Protocols List <openid-specs-digital-credentials-protocols at lists.openid.net>
Cc: Francisco Corella <fcorella at pomcor.com>; Veronica Wojnas <v.wojnas at gmail.com>; Sukhi Chuhan <sukhpreetchuhan at gmail.com>
Subject: Re: [Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft
 There is a reference to it in what you’ve quoted
     "verificationMethod": "did:example:holder#key-1"
 If your implementation understands DIDs then this is a standard way to express referencing key material in a DID Document.
 The examples do need to be updated, however, I would not classify this as a fundamental security flaw. I have an issue to make the W3C VC examples better. 
 Gabe
 On Oct 23, 2024 at 11:48:26 AM, Francisco Corella via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
  Hello Mike,

Thank you for sending the last call and the current Editor's draft of the OpenID4VP specification.

I think the draft is not ready because it has a fundamental security flaw.

Section 2 says:

Cryptographic Holder Binding:
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.

But Section B.1.2.3 has the following example of a verifiable presentation of a verifiable credential:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "id": "https://example.com/credentials/1872",
      "type": [
        "VerifiableCredential",
        "IDCredential"
      ],
      "issuer": {
        "id": "did:example:issuer"
      },
      "issuanceDate": "2010-01-01T19:23:24Z",
      "credentialSubject": {
        "given_name": "Max",
        "family_name": "Mustermann",
        "birthdate": "1998-01-11",
        "address": {
          "street_address": "Sandanger 25",
          "locality": "Musterstadt",
          "postal_code": "123456",
          "country": "DE"
        }
      },
      "proof": {
        "type": "Ed25519Signature2018",
        "created": "2021-03-19T15:30:15Z",
        "jws": "eyJhb...JQdBw",
        "proofPurpose": "assertionMethod",
        "verificationMethod": "did:example:issuer#keys-1"
      }
    }
  ],
  "id": "ebc6f1c2",
  "holder": "did:example:holder",
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2021-03-19T15:30:15Z",
    "challenge": "n-0S6_WzA2Mj",
    "domain": "https://client.example.org/cb",
    "jws": "eyJhb...IAoDA",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:holder#key-1"
  }
}

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.

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.

I plan to call a session at next week's IIW to discuss this issue.

Best regards,

Francisco

-----Original message-----
From: Michael Jones via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net>
Sent: Wednesday, October 23 2024, 7:34 am
To: openid-specs-digital-credentials-protocols at lists.openid.net <openid-specs-digital-credentials-protocols at lists.openid.net>
Cc: Michael Jones <michael_b_jones at hotmail.com>
Subject: [Openid-specs-digital-credentials-protocols] FW: Working group last call for proposed OpenID4VP Implementer's Draft
 FYI

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Michael Jones via Openid-specs-ab
Sent: Wednesday, October 23, 2024 7:31 AM
To: openid-specs-ab at lists.openid.net
Cc: Michael Jones <michael_b_jones at hotmail.com>
Subject: [Openid-specs-ab] Working group last call for proposed OpenID4VP Implementer's Draft

Dear OpenID Connect Working Group,

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.

The current OpenID4VP document to be reviewed can be found here: https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html.

The details of the Implementer’s Draft approval process can be found here: https://openid.net/wg/resources/approving-specifications/.  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.

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.

                                -- Mike (writing as working group chair)

P.S.  Thanks to Joseph Heenan for drafting most of the text above!

-- 

Openid-specs-digital-credentials-protocols mailing list

Openid-specs-digital-credentials-protocols at lists.openid.net

https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols

--
Openid-specs-digital-credentials-protocols mailing list
Openid-specs-digital-credentials-protocols at lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241023/c23bf880/attachment-0001.htm>