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: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>
Sent: vrijdag 3 februari 2023 11:30
To: Terbu, Oliver <oliver.terbu@spruceid.com>; Credentials Community Group <public-credentials@w3.org>
Subject: RE: RWOT Holder Binding paper got published

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?
[cid:image003.png@01D93B12.49BAA880]
At this moment, the following remains unclear.

  *   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?
  *   Has verification been performed on each binding property, or have any been provided by the subject without further verification?
  *   What are the assurances that all three binding properties are about the same subject?
  *   Within what legal framework has the verification by the issuer taken place? (E.g. Europe eIDAS, PIPEDA Canada, ...)
  *   ... likely more level-of-assurance-related questions ...

Best regards,

Oskar


From: Oliver Terbu <oliver.terbu@spruceid.com<mailto:oliver.terbu@spruceid.com>>
Sent: donderdag 2 februari 2023 17:38
To: Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>>
Cc: Credentials Community Group <public-credentials@w3.org<mailto: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.

[cid:image004.png@01D93B12.49BAA880]

Thanks,
Oliver


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[cid:image005.png@01D93B12.49BAA880]<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.