Re: RWOT Holder Binding paper got published

I believe these questions are great questions! But as we have discussed in
the paper, it is a bit up to the subspecs to detail these things. The
overarching thought is to open up for flexibility and expansion. And that
it can be a spec detailing these questions clearly and how the data
attributes are defined.

On Fri, Feb 3, 2023, 10:33 Deventer, M.O. (Oskar) van <
oskar.vandeventer@tno.nl> 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.
>
>    - 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>
> *Sent:* donderdag 2 februari 2023 17:38
> *To:* Orie Steele <orie@transmute.industries>
> *Cc:* Credentials Community Group <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>
> 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>
> 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
>
>
>
> <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.
>
>