RE: RWOT Holder Binding paper got published

I somewhat like the notion that the word ‘hints’ implies. 

 

For example: Let’s say, as a verifier I have a claim in front of me but know nothing about the issuer of that claim AND it is very important to me that the claim be correct and accurate. As a verifier, I potentially have to take on a lot of work to understand who the issuer is, what sort of governance they operate under, how consistent they are at following their governance, how good is their internal process and data hygiene, what is their ability to indemnify me against errors and omissions on their part, etc. All of this ideally related specifically to the claim that was issued and not some other claim they might issue.

 

Option 1: Push a comprehensive set of metadata along with the claim so the verifier has everything they need to evaluate the (little ‘c’) context of the claim. This is useful for certain use cases and I’ve been talking with several people who are beginning to convince me that some of these use cases are significant enough to warrant the overhead.

 

Option 2: Assume the verifier has already performed due diligence regarding the issuer, evaluated the issuer’s ability to make the claim they have made and evaluated the risk the verifier is able to take on in accepting the claim – all activity external to this particular transaction. I think this will represent the bulk of the use cases out there, especially over the next 5 years or so. This is the way it mostly happens today and has been working well for literally generations. 

 

Option 3: Surface ‘hints’ along with the claim that limits the amount of due diligence work a verifier must do outside of the transaction. TBH, I don’t know where to best draw the line of what to surface. An issuer ID is the most basic (and reliable) form of a ‘hint’ to the verifier to understand who issued the claim. Bracketed levels of assurance (e.g.l LOA1, LOA2, …) that are backed by well understood government or industry standard seems like another reasonable thing to include for some use cases, but certainly not all.

 

My final thought is that the need for metadata that supports the (little ‘c’) context of a particular (transaction) claim diminishes greatly the more a verifier accepts a particular verifiers claims. To the extent that over time is becomes mostly dead weight. 

 

How do we best balance keeping the payload light and broadly useful while providing enough contextual data to help a verifier determine if they can trust an unknown (or untrusted) issuer?

 

From: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl> 
Sent: Tuesday, February 7, 2023 8:02 AM
To: Bastian, Paul <Paul.Bastian@BDR.de>; Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
Cc: public-credentials@w3.org
Subject: RE: RWOT Holder Binding paper got published

 

Dear Paul and Rieks,

 

Thanks for your detailed and thoughtful responses.

 

* Paul: ... these levels could be stated explicitly in the VC and its binding type, but it could also be implied by the binding type itself.
* Rieks: … From that, I conclude that while it is important, it should not (necessarily) be made part of credentials, claims or bindings.

Whereas I may agree with those statements, I am unsure about the practicality and scalability of VCs-with-holder binding, if the VC does not contain any hints about the assurances about the provided holder bindings, e.g. at least some hints where the (implied) information can be found.

 

A future reality is that verifiers may need to recognise of hundreds or more issuers. If we don’t want to require verifiers to inspect the implicit assurances with each and every issuer, then some hints/standards will be essential. Europe has standardised LoA’s “eIDAS-low”, “eIDAS-substantial” and “eIDAS-high”, which are a set of procedural requirements that an issuer assures to have satisfied when issuing the VC. I believe that it will be quite useful that a VC-with-holder-binding provides such hints. I believe that accidents will happen, if issuers e.g. allow their holders to fill in their passport numbers themselves, and verifiers assume that an implied eIDAS-high identity verification has happened.

 

* The same holds for any other assertions/claims about entities – it is not specific to bindings.

Universities are accredited for giving proper education. Are they also accredited for the quality of their identity checks?

 

Oskar

 

 

From: Joosten, H.J.M. (Rieks) rieks.joosten@tno.nl <mailto:rieks.joosten@tno.nl>  
Sent: dinsdag 7 februari 2023 16:37
To: Deventer, M.O. (Oskar) van oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl> ; Terbu, Oliver oliver.terbu@spruceid.com <mailto:oliver.terbu@spruceid.com> ; Credentials Community Group public-credentials@w3.org <mailto:public-credentials@w3.org> 
Subject: RE: RWOT Holder Binding paper got published

 

Oskar,

 

I would personally not to into a “level-of-assurance” discussion because the term can mean lots of things in different contexts. Your point is about the procedures that the issuer has followed to conclude that a particular binding that it states about an identifier is in fact statable (i.e., what did the issuer do to ensure that id “somevaliduri” is related to the same entity as, for example, the person whose attributes are in the Dutch passport with serial number 012345678). 

 

While I acknowledge the importance for verifiers to be able to learn such things:

* The same holds for any other assertions/claims about entities – it is not specific to bindings. For example, a claim stating that “somevaliduri” has passed exam “second order logic” might equally well need a description of how the exam was run, what security precautions were taken to prevent people to learn about the questions before the exam, etc.
* Verifiers are likely to need to learn these things before they construct a presentation request, as it seems very inefficient to ask for credential data only to learn that it cannot be used because the data wasn’t produced in a way that the verifier can trust.

From that, I conclude that while it is important, it should not (necessarily) be made part of credentials, claims or bindings.

 

Rieks

 

 

From: Paul Bastian <paul.bastian@posteo.de <mailto:paul.bastian@posteo.de> > 
Sent: dinsdag 7 februari 2023 15:55
To: public-credentials@w3.org <mailto:public-credentials@w3.org> 
Subject: Re: RWOT Holder Binding paper got published

 

Hi Oskar,

thanks for your appreciation and your feedback. As most of your questions are going into the same direction I hope to address them altogether with my response instead of going through them one by one.

In general our paper tried to lay a foundation for the discussion on holder binding, as the term has been used in quite different circumstances and assumptions, many people mean different things and still using the same words. So first of all we identified that currently the terminology and vocabulary that is used in W3C is very vague and we tried to improve this be introducing a more detailed terminology.

Secondly, we did not try to define the "best" way to do holder binding, instead we propose a framework, syntax and semantic have different types and mechanisms of holder binding can fit together under the umbrella of W3C Verifiable Credentials and Presentations. Different use cases require different forms of holder binding (or identifier binding as we rephrase it in our paper): On-site vs Remote/Online, Supervised vs Automated and so on. Some use cases work best to compare portrait pictures while others leverage keys bound to a trusted wallet that does the work of binding it to its owner thorugh PINs/biometrics, there will always be room for many mechanisms and our first contribution is to bring them to a common property under W3C terms. These binding types are then ideally registered under a (W3C) registry and each binding type can then be more detailed in its description. Level of assurances is on of the most important things and it can be discussed if this is another property next to "id" and "type". Level of assurances and the assurances of the initial identity proofing can therefore be defined in each binding type, these levels could be stated explicitly in the VC and its binding type, but it could also be implied by the binding type itself. So in general these questions have to be answered for each specific binding type and this description should be linked in a Binding Type registry. 

*         Has the issuer actually verified the physical person or legal entity that is the subject of the VC, and with what level-of-assurance?

*         Has the issuer performed an in-person verification of the person + passport, conformant to the “eIDAS high” level of assurance?

*         Has the issuer checked that the portrait corresponds with the face of the physical person?

*         Has the issuer performed these checks at a physical location, or over the internet?

*         Had the issuer perform the verification by a human being or by an automated system?
And can the provenance of that verification be established?

*         Did the verification include proof-of-liveliness?

*         --> all of the above questions: I think there is a tradeoff, were some of these information will be explicitly stated in the binding, while others are implicitly coming from the binding type. Having everything as metadata in the VC seems quite ambitious and unrealistic to me

*         Has verification been performed on each binding property, or have any been provided by the subject without further verification?

*         --> the issuer is responsible for any binding types that he issues.

*         What are the assurances that all three binding properties are about the same subject?

*         --> If the bindings are stated from the same issuer and he is referring to the same "id" or the bindings are within the same "credentialSubject" then all bindings relate to the same subject.

*         Within what legal framework has the verification by the issuer taken place? (E.g. Europe eIDAS, PIPEDA Canada, ...)

*         --> level of assurances are not global, and hardly comparable. So if a VC/binding type reflects a level of assurance, it will probably be a very specific one, or a list of

I hope this answers some of your questions.

Best regards,
Paul

On 03.02.23 11:30, Deventer, M.O. (Oskar) van wrote:

Oliver, all,

 

This is great work that deserves further development at W3C-CCG, hopefully leading to a technical specification.

 

I am missing a discussion on “level-of-assurance” at the issuer side. Suppose a verifier receives a VC with the following binding property, then what does that mean?



At this moment, the following remains unclear.

1.       Has the issuer actually verified the physical person or legal entity that is the subject of the VC, and with what level-of-assurance?

2.       Has the issuer performed an in-person verification of the person + passport, conformant to the “eIDAS high” level of assurance?

3.       Has the issuer checked that the portrait corresponds with the face of the physical person?

4.       Has the issuer performed these checks at a physical location, or over the internet?

5.       Had the issuer perform the verification by a human being or by an automated system?
And can the provenance of that verification be established?

6.       Did the verification include proof-of-liveliness?

7.       Has verification been performed on each binding property, or have any been provided by the subject without further verification?

8.       What are the assurances that all three binding properties are about the same subject?

9.       Within what legal framework has the verification by the issuer taken place? (E.g. Europe eIDAS, PIPEDA Canada, ...)

10.   ... likely more level-of-assurance-related questions ...

 

Best regards,

 

Oskar

 

 

From: Oliver Terbu  <mailto:oliver.terbu@spruceid.com> <oliver.terbu@spruceid.com> 
Sent: donderdag 2 februari 2023 17:38
To: Orie Steele  <mailto:orie@transmute.industries> <orie@transmute.industries>
Cc: Credentials Community Group  <mailto:public-credentials@w3.org> <public-credentials@w3.org>
Subject: Re: RWOT Holder Binding paper got published

 

On Thu, Feb 2, 2023 at 5:24 PM Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries> > wrote:

Thanks for this!

It seems like a naive interpretation of "holder binding" is ... a credential / claim bound to a specific key.

 

Yes, in our paper, this is still a possible option and probably one of the most common once I have seen in applications.

 


Instead of binding to a "generic subject" the binding is to a specific key (possibly in hardware or software isolation).

Is that correct?

 

Yes, the binding is to a specific "identifier" which can be a key. For the sake of this paper we used our definition for "identifier" (which includes a public key). We DO NOT want to start a discussion on terminology here on the CCG mailing list. When reading the paper, please just bear with us and keep in mind we used the following definitions:

 

Identifier
Data that is used for the purpose of recognizing a (real world) entity, typically to distinguish it from other entities in some set. The data is typically in the form of characters (or attribute sets), but could also take the form of audio (speech), pictures (portrait), etc., or a combination of those.

Identifier Binding
The situation 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.

 

 


OS

 

On Thu, Feb 2, 2023 at 10:21 AM Oliver Terbu <oliver.terbu@spruceid.com <mailto:oliver.terbu@spruceid.com> > wrote:

Dear all,

 

Since we had a number of issues and lots of discussions on holder binding in the last couple of months, we wrote a RWOT paper and it got published finally. I'm sharing this already since it is relevant to upcoming discussions on holder binding in W3C.

 

IDENTIFIER BINDING: DEFINING THE CORE OF HOLDER BINDING

- https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.pdf

- https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md

 

by Paul Bastian, Rieks Joosten, Zaïda Rivai, Oliver Terbu, Snorre Lothar von Gohren Edwin, Antonio Antonino, Nikos Fotiou, Stephen Curran, and Ahamed Azeem

 

Lead author: Oliver Terbu

 

Over the last year(s), various issues have been raised that revolve around what has been called 'holder binding'. The term 'holder binding' itself isn't clearly defined, and is in fact quite contentious. This paper seeks to come to grips with this discussion. Our first contribution is the specification of a terminology, which is intended to help readers understand what we mean to say without requiring them to make assumptions about such meanings (as is often the case in discussions about 'holder binding'). Our second contribution is an analysis of a (fictitious) use-case that suggests that verifiers typically do not need to know who the holder is (i.e. who has presented the claims to be verified). This analysis shows that verifiers need capabilities to (a) learn which entity is the subject of a particular claim, and (b) to know whether or not two subject identifiers refer to the same entity or to different entities. Also, they may need assurances regarding the party on whose behalf the component that has electronically presented the claims, has been using those capabilities. Our third contribution is a proposal for the syntax and semantics of a new property that can be used in (different parts of) VCs/VPs, that will provide verifiers with such capabilities.

 



 

Thanks,

Oliver




 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries <http://www.transmute.industries> 

 

 <https://www.transmute.industries/> 

 

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.