[Openid-specs-digital-credentials-protocols] NOT READY --- RE: FW: Working group last call for proposed OpenID4VP Implementer's Draft
Sancho Sancho Canela
ssanchocanela at gmail.com
Thu Oct 24 04:37:54 UTC 2024
Dear all.
We are using credentialSubject to stablish the binding. What you prove as
holder is control over the did on the credential subject. It is quite well
defined in the EBSI VC Framework.
I don't see any issue. Maybe the issue or gap is in the example. And I
would say the this should be defined in the profile for VC that you define
at business level. The protocol shall give you the options. How is that
defined in detail is a layer over OID4VP, for sure examples are more than
welcome.
Regards,
Sancho
El jue, 24 oct 2024 a las 0:14, Gabe Cohen via
Openid-specs-digital-credentials-protocols (<
openid-specs-digital-credentials-protocols at lists.openid.net>) escribió:
> 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
>>>
>> --
> 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/20241024/b70a7a1c/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list