- From: Paul Bastian <paul.bastian@posteo.de>
- Date: Tue, 7 Feb 2023 14:55:14 +0000
- To: public-credentials@w3.org
- Message-ID: <efe91480-5b3a-8fba-ab8c-1e9a793e2bd4@posteo.de>
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?
o --> 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?
o --> 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?
o --> 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, ...)
o --> 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.
>
> * 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 <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.
>
Received on Tuesday, 7 February 2023 14:56:53 UTC