Holder Binding

Confirmation Method

Oliver Terbu @W3C CCG

April 11th, 2023

Problem Statement

• How can the verifier trust that the entity, the one the issuer issued the verifiable credentials to, presented the verifiable presentation and the entity did not simply get a copy of the included verifiable credentials?
• Relates to wallet security, consent, authentication (strong/multi-factor, certain level of assurance), selective disclosure, non-correlatable identifier, enabling pure online use cases, …�

Problem Statement

• A VP can be created by anyone which can be different from the Subject of the VCs in the presentation.
• VC Data Model defines a proof in the VP but it does not define further semantics other than the proof of the VP can be used to verify the VP was not tampered with and to verify the authorship.
• Authorship means that the VP was generated by the Holder of the VP. It does not ensure that the Holder is the intended Holder of the presented VCs.
• Verifier would typically need to perform extra steps to ensure that the Holder is the intended Holder of the presented VCs.
• Trivial if VC is bound to a Subject and the Holder of the VP is the same as the Subject, and Subject and Holder are identified by DIDs.

What a lot of people do today …

{

"@context":[ ... ],

"type":[

"VerifiablePresentation",

"CredentialManagerPresentation"

],

"holder":"did:example:subject",

"verifiableCredential":[{

"@context":[ ... ],

"type":[ "VerifiableCredential",

"UniversityDegreeCredential" ],

"issuer":"https://example.edu/issuers/565049",

"issuanceDate":"2010-01-01T00:00:00Z",

"credentialSubject":{

"id":"did:example:subject",

"degree":{

"type":"BachelorDegree",

"name":"Bachelor of Science and Arts"

}

},

"proof":{ ... }

}],

"proof":{

"type":"JsonWebSignature2020",

"created":"2019-12-11T03:50:55Z",

"jws":"ey...",

"proofPurpose":"authentication",

"verificationMethod":"did:example:subject#key-1"

}

}

​

​

​

“holder” is non-normative and optional, unclear who is “holder” when omitted

​

“credentialSubject.id” is optional

​

​

IF (holder.id == credentialSubject.id AND hasAuthnMethod(resolve(holder.id), vp.proof.verificationMethod) AND isValid(vp.proof)) THEN

Print “Holder Binding validated”

Problem Statement: holder + VP don’t solve the issue

Confirmation Method

A Confirmation Method can be included by an issuer in a verifiable credential to declare that the subject controls, or a holder has been designated to use, one or more particular confirmation methods. This binds a specific claim about a subject to one or more confirmation methods. In this way, an issuer explicitly gives guidance around how a verifier can validate that the holder is bound to the claims presented in a verifiable credential.

​

Assumptions

• Issuer should never know who the verifier is
• Issuer may attempt to control the use of the verifiable credential through the termsOfUse property, �… but termsOfUse is VC metadata and doesn’t work with multiple credentialSubject objects.�
• Issuers are trusted → If not, then don’t accept the VCs they issue
• Each issuer is making statements of facts (in its opinion) about the VC it is issuing.
• The issuer MUST verify these statements before inserting them into the VC, otherwise it is not acting in a trustworthy manner. So, the issuer must be trusted by the verifier to make correct statements, or else it will not accept these VC. �→ also applies to <confirmation methods>
• The issuer may insert evidence into the VC to tell the verifier which procedures it followed when asserting these facts → important topic but not in scope of this session!

Consequences

• ANY property of the subject of a VC may be used by the verifier to determine if the presenter of the VP is the subject of a presented VC
• Also applies to claims about <confirmation methods>
• In certain cases, e.g., selective disclosure, non-correlatable identifier, support for ZKPs, there are not many useful claims that can be used for this.
• The issuer does not need to tell the verifier what properties to use for verification, as this applies to all subject properties. The verifier decides which subject properties to use.
• If the verifier is interested in confirmation of the verifiable presentation, then it can get too complicated for the verifier to check everything themselves.
• Since the verifier trusts the issuer, the verifier can also trust the <confirmation methods> endorsed by the issuer.

Context Matters

• The term Holder Binding is misleading since the term depends strongly �on the context the term is used in …
• For example, the Dutch government definition of holder of an identity document is the person in whose name the identity document is issued and for whom it has been issued.
• In VCDM, that person would be referred to as the subject (of the identity document), and the holder would be the entity that possesses it and can present it, which could be, but is not necessarily, its subject.

Holder Binding → Identifier Binding

• Proposal based on RWOT Holder Binding Group
• Paul Bastian, Rieks Joosten, Zaïda Rivai, Oliver Terbu�Snorre Lothar von Gohren Edwin, Antonio Antonino�Nikos Fotiou, Stephen Curran, and Ahamed Azeem�
• RWOT paper can be found here
• Definition of Identifier Binding (from the RWOT paper): “The process in which there is an identifier that a particular party has bound to some entity that it knows to exist, and has specified one or more means that other parties can use to identify and/or authenticate that entity. Such means are typically specified as part of a VC.”

→ However, although this slide deck uses examples from the paper, it deviates by saying “to verify that entity confirmed the presentation” where authentication is one aspect of the process and where confirmation methods are those “means”.

Use Case

• Bob offers a course "Making Logic Arguments Stick" in different scenarios …
• Fully online course with no human teachers (FOCUS of this presentation)
• Fully online course where some classes are held by human teachers (see RWOT paper)
• In-person classes with limited seats (see RWOT paper)�
• Alice wants to enroll for Bob’s course in the scenarios above
• Bob requires the completion of another course “Second Order Logic” (SOL) before students can enroll for his course
• Ivan offers a course “Second Order Logic” to students
• Trevor wants to enroll Alice
• Mallory wants to enroll for Bob’s course without a “Second Order Logic” certificate by using Alice’s certificate.

Scenario 1 | Fully remote

• Alice receives a verifiable credential from Ivan upon completion of the course “Second Order Logic” (SOL).�
• The verifiable credential does not contain any other claims than the credential subject passed the exam for the course SOL.

Scenario 1 | Fully remote

The verifiable credential looks like this:

...�"credentialSubject": {� "id": "<some-uri>",� "passedExam": "SOL"�}�...

Without additional information, the verifiable credential cannot be used by Alice to enrol for Bob’s course in a secure way (online, in-person). Also Bob cannot verify that it was Alice that provided the verifiable presentation that embeds the VC above.

Scenario 1 | Fully remote

​

We could add additional claims, so Bob could ask for an identity document that can be used to confirm Alice by comparing claims from the VC below against claims in the trusted identity document:

...�"credentialSubject": {� "id": "<some-uri>",� "passedExam": "SOL",� "firstName": "Alice",� "lastName": "Wonderland"�}

...

�

Implications

• Requires Alice to tell Ivan additional claims and provide evidence such as an identity document.
• If the identity document is not a digital credential, then it is very hard to use online.
• Alice cannot use the VC above in a pseudo/anonymous way anymore.
• When enrolling online there is no way for Bob to verify whether Alice provided the verifiable presentation herself. Note, Trevor could enrol Alice with the VC above for a in-person course and Alice would then show her identity document when going to the class but for fully remote courses this is very challenging.

Scenario 1 | Fully remote

​

Alice needs to present some cryptographic proof specifically for online use cases. Ivan could just include Alice’s cryptographic key as a claim like this:

...�"credentialSubject": {� "id": "<some-uri>", ; OR "did:..."� "passedExam": "SOL",� "publicKey": "..." ; OR "verificationMethod"�}

...

�But this does not give the verifier enough guidance to verify the verifiable presentation since the verifier does not know the intention or further semantics of the publicKey claim. Note, if verificationMethod was used, it would be DID spec specific. A normative reference for such a mechanism is missing in the VCDM.

Scenario 1 | Fully remote

​

For that reason, we propose a new property confirmationMethod (subject to bikeshedding):

...�"credentialSubject": {� "id": "<some-uri>",� "passedExam": "SOL",� "confirmationMethod": [{� "type": "KeyConfirmationMethod2023",� "publicKeyBase58": "did:key:z6...#key-1"� }]�}

...

�

NOTE: DID/Key is not owned by issuer → issuer attested that claim after, for example, a DIDAuth challenge was verified.

This makes it clear and Alice can enroll for Bob’s course fully remotely. Mallory could also not just copy Alice’s verifiable credential and enroll for Bob’s course without passing the SOL exam first, since the verifiable credential is bound to a key that Alice possesses and that was endorsed by Ivan as the confirmation method for that VC. Only if Alice and Mallory would collude (friendly relay/fraud), Mallory would be able to confirm the verifiable presentation on behalf of Alice.

Scenario 1 | Fully remote (PROPOSAL)

​

Because confirmation methods can be quite different and a VC could have many confirmation methods endorsed by the VC issuer, we propose a new property where each confirmation method is described by its type and where each type is registered in the VC directory. The VCDM should also define 1-2 basic types such as KeyConfirmationMethod2023. For high assurance use cases it might not be even feasible to add all required claims to the VC (number too high, lack of standards, not possible to be verified by verifier etc.).��...

{� "confirmationMethod": [ � { "type": "...", ... }, <more elements of array of confirmation-method-elements> ]�},�...

​

Scenario 1 | Other Examples

​

...

"credentialSubject": {� "id": "<some-uri>",� "passedExam": "SOL",� "confirmationMethod": [{� "type": "DIDConfirmationMethod2023",� "did": "did:key:z6..."� },{� "type": "KeyConfirmationMethod2023",� "publicKeyBase58": "did:key:z6...#key-1",� "loa": "high", ; additional properties � ; allowed� "some": "other" ; additional properties � ;allowed� "realm": "eIDAS" ; additional properties � ; allowed� },{� "type": "AnonCredsLinkedSecret2023",� "blindedLinkedSecret": "..."� }]�}

...

...

"credentialSubject": {� "id": "<some-uri>",� "passedExam": "SOL",� "confirmationMethod": [{� "type": "BiometricTemplate2023",� "portrait": "data:..."� }]�}

...

Scenario 1 | Linking Confirmation Methods

​

"credentialSubject": [ {� "id": "uri:9021678535", //mandatory� "confirmationMethod": [ {� "type": "secureWallet� RemoteBindingDIF",� "walletName": "Example Wallet",� //optional� "walletVersion": "1.3.0",� //optional� "hardwarePublicKey": � "did:jwk:123", � //links and other formats� // possible� "holderAuthentication": � ["FaceID", "PIN"]� } ],� "firstName": "Alice",� "familyName": "Wonderland",�...�}�],�...

...

"credentialSubject": [ {� "id": "uri:492754832663",� "confirmationMethod": [ {� "type": "linkedBinding",� "link": "uri:9021678535"� } ],� "hasPassedExam": "SOL"�}],�...

​

...�"credentialSubject": [ {� "id": "uri:399912",� "confirmationMethod": [ {� "type": "linkedCredential",� "link": "uri:9021678535"� } ],� "isEnrolledFor": "MLAS-3"�}�],�...

Applications (non-exhaustive list)

• Where specific assurance or confidence levels are required to prevent identity fraud
• Where common attacks such as replay, credential theft etc. has to be prevented where damage potential is high.
• Where pseudonymous verifiable credentials have to be preserved
• Where strong/multi-factor authentication is required and where it is hard for the verifier to verify the result from individual authenticators
• To support non-correlatable identifier and ZKPs
• To support fully online use cases where it is hard to provide additional evidence about the subject.

Applications (non-exhaustive list)

• Other Ecosystems using similar approaches
• eIDAS 2.0 ARF [1] → sole control / holder authentication
• e.g. SIM eRegistration, Bank Account Opening, eDriving Licence, eGov Services, eSignature, ePrescription [2]
• ISO 23220-4 Holder Confirmation Binding, ISO 18013-7 mDL
• HyperLedger, Anoncreds
• ICAO DTC → Biometric Template sent upfront, so travelers can use pre-registered traveler programs and use automated border controls.

[1] https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework (2023)�[2] https://www.digital-identity-wallet.eu/ (2023)

Privacy Considerations

• Similar considerations as already described in the VCDM
• Selective disclosure of binding/confirmation methods and the use of non-correlatable identifier becomes even more important
• Some people might think that issuer endorsed binding or confirmation methods are too restrictive
• But binding/confirmation methods are just one claim,
• and verifiers can use other claims as well.

Status of “Holder Binding”

• A number of “Holder Binding” issues were created in W3C VCDM Github
• “Holder Binding” discussion kicked-off at W3C TPAC 2022
• “Holder Binding” paper at RWOT 2022
• “Holder Binding” paper acted as foundation for presentation�at W3C VCWG Miami F2F
• Pending PR to add semantics to W3C VCDM 2.0�https://github.com/w3c/vc-data-model/pull/1054
• Next steps
• Agree on PR
• Adding support to W3C VCDM 2.0 Test Suite
• Potentially normatively defining 1-2 specific “Holder Binding” types, e.g., based on DID Auth
• Call for implementers to show interop based on W3C VCDM 2.0 Test Suite

​

Thank you!