[Openid-specs-digital-credentials-protocols] A proposed solution, based on Orie's
Tom Jones
thomasclinganjones at gmail.com
Sat Oct 26 05:35:36 UTC 2024
Franciso's solution solves two problems:
1. The verifier does not need to be online to verify the signature.
2 The verifier does not get the reusable ID from the user, although the
public key has the potential for similar tracking capabilities.
It would be a simple adjustment to privacy laws to prohibit any verifier
from sharing any keying material for any reason.
For a gov't cred there really is no interesting difference between a social
ins number and a gov't approved DID.
Peace ..tom jones
On Thu, Oct 24, 2024 at 11:52 AM Francisco Corella <fcorella at pomcor.com>
wrote:
> Hi Orie,
>
>
>
> Thank you for asking if I can propose a solution. I wasn't planning to, I
> was just reporting a problem. But since you asked I came up with one,
> which builds on what you propose in the message below.
>
>
>
> To motivate the solution, let me point out that there are two distinct
> kinds of cryptography: traditional cryptography (the cryptography of
> academia, the crypto conferences and the Journal of Cryptology) and W3C
> cryptography.
>
>
>
> One thing I like about W3C cryptography is that it is innovative. It has
> come up with both good and bad innovations. The solution I'm proposing
> includes one good innovation and remedies for two bad innovations.
>
>
>
> One bad innovation is verifiable presentations. In traditional
> cryptography, a credential presentation is a protocol for presenting the
> credential, not something with a life of its own, signed by a party
> possible different from the subject. Allowing the presentation to be
> signed by a party other than the subject creates opportunities for
> application errors and increases the attack surface, enabling impersonation
> attacks like the one I described yesterday.
>
>
>
> The remedy to this is what you proposed: a cnf field in the credential.
> The verificationMethod field in the VP should be deprecated, not just made
> redundant or optional, since leaving it there would not reduce the attack
> surface.
>
>
>
> The other bad innovation is burying the public key used to verify the
> presentation in a DID document, instead of having it explicitly signed by
> the issuer. That also provides opportunities for application
> vulnerabilities and increases the attack surface.
>
>
>
> To remedy this I propose using one the good innovations of W3C
> cryptography: using the hash of a public key instead of the public key
> itself. I found that idea in the did:peer specification. I propose the
> use an encoded hash of the public key as the value of the cnf field. When
> presenting the credential, the subject would send the public key along with
> the signature, and the verifier would check that the hash of the public key
> that it receives agrees with the value of the cnf field.
>
>
>
> Using the hash of the public key has two advantages over using the public
> key itself as is done in traditional public key certificates: the hash is
> shorter, and the private key is protected against post-quantum attacks by
> an attacker with access to the certificate. This is a valuable innovation
> with many possible uses, which could be retrofitted from W3C cryptography
> into traditional cryptography. I've mentioned this to a traditional
> cryptographer and he was impressed by the potential benefit.
>
>
>
> Francisco
>
> -----Original message-----
> *From:* Orie Steele <orie at transmute.industries>
> *Sent:* Wednesday, October 23 2024, 1:47 pm
> *To:* Francisco Corella <fcorella at pomcor.com>
> *Cc:* Digital Credentials Protocols List <
> openid-specs-digital-credentials-protocols at lists.openid.net>; Gabe Cohen
> <gabe at tbd.email>; 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
>
> Then the issue is solved by doing this:
>
> {
> "@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",
> *"cnf": { "kid": "**did:example:holder" },*
> "credentialSubject": {
> *"id": "**did:example:holder",*
> "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"
> }
> }
>
> 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".
>
> Your suggestion is that the error in this example is grounds for not
> progressing the document, can you propose a solution?
>
> 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 (
> https://w3c-ccg.github.io/lds-ed25519-2018/) is now:
> https://www.w3.org/TR/vc-di-eddsa
>
> I recommend removing the example, or updating it to support version 2.
>
> Regards,
>
> OS
>
>
>
>
>
>
> On Wed, Oct 23, 2024 at 2:55 PM Francisco Corella <fcorella at pomcor.com>
> wrote:
>
>> The issue is NOT how you resolve DIDs, nor any other technical details of
>> decentralized identifiers.
>>
>>
>>
>> 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.
>>
>>
>>
>> Francisco
>>
>>
>>
>>
>>
>> -----Original message-----
>> *From:* Orie Steele <orie at transmute.industries>
>> *Sent:* Wednesday, October 23 2024, 12:48 pm
>> *To:* Digital Credentials Protocols List <
>> openid-specs-digital-credentials-protocols at lists.openid.net>
>> *Cc:* Gabe Cohen <gabe at tbd.email>; 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
>>
>> 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.
>>
>> So in W3C VCDM where you see:
>>
>> kid: did:example:holder#key-1
>>
>> You can mentally replace that with:
>>
>>
>> - urn:ietf:params:oauth:ckt:sha-256:SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w
>> -
>> urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> 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.
>>
>> In terms of "credential binding", you can use the "cnf" claim in W3C VCDM
>> credentials just like you can use it with CWTs / JWTs.
>>
>> - https://www.iana.org/assignments/cwt/cwt.xhtml#confirmation-methods
>> - https://www.iana.org/assignments/jwt/jwt.xhtml#confirmation-methods
>>
>> 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.
>>
>> Notice that "kid" is in both registries as a valid confirmation method.
>>
>> I'd suggest removing the DID examples from this specification before
>> publishing or documenting what I have written above in the specification.
>>
>> OS
>>
>>
>> On Wed, Oct 23, 2024 at 2:26 PM Francisco Corella via
>> Openid-specs-digital-credentials-protocols <
>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>
>>> 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
>>> <https://github.com/openid/OpenID4VP/issues/5> 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
>>>>
>>> --
>>> 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
>>
>>
>>
>> --
>>
>>
>>
>> *ORIE STEELE*
>> Chief Technology Officer
>> www.transmute.industries
>>
>> <https://transmute.industries>
>>
>>
>
> --
>
>
>
> *ORIE STEELE*
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241025/8052613a/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list