[Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft
Gabe Cohen
gabe at tbd.email
Wed Oct 23 22:13:55 UTC 2024
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.
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.
There is a practical concern, as you note, about *how does the verifier
know to accept this presentation* 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 here
<https://w3c.github.io/vc-jose-cose/#cnf>).
The spec should speak to determining how to resolve the keys of the
presenter and verify the presentation.
I believe the existing language here is sufficient —
https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-7.6
.
Gabe
On Oct 23, 2024 at 1:54:44 PM, Tom Jones <thomasclinganjones at gmail.com>
wrote:
> i never noticed that the cred subject is optional. Not sure how that
> ever happened?
> The other issue that the subject might not be the same as the holder has
> been a problem from the beginning.
> It is not possible for a government to issue digital credentials that
> require the subject to own a smartphone.
> The following report from Kantara addresses that issue
>
> file:///C:/Users/rp_to/Downloads/Kantara-Initiative-RIUP-Digital-Identifier-Inclusion-Final-Report-1.pdf
>
> Peace ..tom jones
>
>
> On Wed, Oct 23, 2024 at 1:47 PM Orie Steele via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
>> 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>
>> --
>> 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/2c19d485/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list