Re: RWOT Holder Binding paper got published

Without such a mechanism, implementing pure online use cases is really hard
in an interoperable fashion. Also note that having credentialSubject.id
being a DID and simply proving control over that DID doesn't necessarily
represent such a confirmation. It just happened that people implemented
such approaches but there is no real normative guidance.

In the current ISO 23220 specification (mdoc) experts work on a similar
mechanism that is called Holder Confirmation Binding (HCB).

On Tue, Feb 14, 2023 at 1:10 AM Oliver Terbu <oliver.terbu@spruceid.com>
wrote:

> IMO, there is value in having a binding property in terms of confirmation
> methods. In that regard, the confirmation method becomes a claim about the
> subject. In the simplest form the confirmation method is a key identifier
> that is endorsed by the issuer that when the verifier receives a proof from
> that key identifier (or a DID, or linked secret etc.), the verifier can
> trust the subject confirmed (+ consent, + authentication, + etc. but
> depending on issuer) the presentation. The confirmation method can also be
> a trusted secure wallet, a link to a personal identification (PID)
> verifiable credential with a high assurance level, or in general a device
> key that unlocks a signature after strong/multi-factor authentication was
> done by the intended entity that got the verifiable credential issued to
> their wallet.
>
> This is useful in *pure online* use cases if the verifiable credential
> contains only pseudonymous information that doesn't allow to
> identify/authenticate the presenter as the designated entity with other
> means. Examples for such verifiable credentials might include "passedExam":
> "Second Order Logic", "isEligibleToDrive": true etc.
>
> Thanks,
> Oliver
>
> On Mon, Feb 13, 2023 at 9:21 PM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>> Agreed that it needs to be explicit. This is made by the holder when
>> creating the VP. The holder provides hints to the verifier (in a VP
>> property that needs to be standardised) to say effectively "I am bound to
>> this embedded VC in this way, and this other embedded VC in this other
>> way.....". The issuer, by issuing the VC, is saying explicitly "I am
>> binding the subject to all the subject's properties (otherwise I would not
>> be including these properties in the VC), and, if the entity I issued it to
>> is not the subject, then its identity is in this property (which also needs
>> to be standardised)"
>>
>> Kind regards
>>
>> David
>> On 14/02/2023 14:05, Oliver Terbu wrote:
>>
>> The binding can be achieved with normal claims as well. IMO, the problem
>> is that it is hard to achieve interop if it is not more explicit.
>>
>> Thanks,
>> Oliver
>>
>> On Mon, Feb 13, 2023 at 7:51 PM David Chadwick <
>> d.w.chadwick@truetrust.co.uk> wrote:
>>
>>>
>>> On 14/02/2023 13:15, Dietrich, Paul (Consultant) wrote:
>>>
>>> Catching up late on this before the face to face.
>>>
>>>
>>>
>>> The doc was hard for me to read (still a newcomer), but reading Orie and
>>> Olivers exchange, I wonder if someone can clarify why this binding can’t be
>>> achieved with a claim (or even a whole VC) that binds the identifier URI to
>>> biometric, key etc. In other words, why is special binding element required
>>> to convey this and does that point to a deficit in the claim model itself?
>>>
>>> I don't think a special binding element is needed to bind the VC to any
>>> of the subject attributes since the issuer has already verified that ALL of
>>> the subject attributes are correct (otherwise  it would not be inserting
>>> them into the VC). Thus the verifier can use ANY of the subject attributes
>>> to verify that the presenter/holder is the subject, at its own discretion.
>>>
>>> However if the VC is not issued to the subject, then the issuer may
>>> indicate to whom the VC was issued in another VC property that is
>>> structurally identical to the subject object - lets call this property Z
>>> for now. Again the issuer must have verified all of the properties that it
>>> inserts into Z, allowing the verifier to use any of these properties to
>>> verify if the presenter/holder is the same Z as the issuer issued the VC to.
>>>
>>> Kind regards
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Luca Boldrin <luca.boldrin@infocert.it>
>>> <luca.boldrin@infocert.it>
>>> *Date: *Thursday, February 9, 2023 at 3:27 AM
>>> *To: *Paul Bastian <paul.bastian@posteo.de> <paul.bastian@posteo.de>,
>>> public-credentials@w3.org <public-credentials@w3.org>
>>> <public-credentials@w3.org>
>>> *Cc: *Luca Boldrin <luca.boldrin@infocert.it> <luca.boldrin@infocert.it>
>>> *Subject: *Re: RWOT Holder Binding paper got published
>>>
>>> CAUTION: This email originated from outside of the organization. Do not
>>> click links or open attachments unless you recognize the sender and know
>>> the content is safe.
>>>
>>>
>>>
>>> Dear Paul, all,
>>>
>>> I appreciate the clarity of the paper in singling out the “binding”
>>> issue.
>>>
>>>
>>>
>>> W.r.t  the sentence:
>>>
>>>
>>>
>>>
>>>
>>> As you all know, separating key binding is the practice in X.509 based
>>> systems, where public-key certificates (key-id binding) are distinct from
>>> attribute certificates  (subjectName may well be a pseudonym, i.e.
>>> issuer-specific ID)
>>>
>>>
>>>
>>> (an example, drawn from
>>> https://profsandhu.com/confrnc/acsac/acsac00(org).pdf
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprofsandhu.com%2Fconfrnc%2Facsac%2Facsac00(org).pdf&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1sIBiglV1hFG7IoI%2BPi3nzn3jR2oew5u003Jjt%2BZpGY%3D&reserved=0>)
>>>
>>>
>>>
>>>
>>> Additionally, Qualified CAs issuing public-key certificates *MUST issue
>>> such certificates in specific  devices owned by the entity to which the id
>>> refers *.
>>>
>>>
>>>
>>> Your paper presents a conceptually clear extension of this binding
>>> concept to cover authentication by different means.
>>>
>>> Best,
>>>
>>>
>>>
>>> --luca
>>>
>>>
>>>
>>> [image: Icon Description automatically generated with medium confidence]*Luca
>>> Boldrin, PhD*
>>>
>>> R&D *INFOCERT **S.p.A.*​
>>>
>>> Professor *U**niversità degli studi di Padova*​​
>>>
>>> *M* +39 329 9043511​
>>>
>>> [image: A picture containing text Description automatically generated]
>>> *E *luca.boldrin@infocert.it​, *luca.boldrin@unipd.it
>>> <luca.boldrin@unipd.it>*​
>>>
>>>   *P* * Think before printing*
>>>
>>> ​*[image: signature_181319461]*
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Finfocert_it%3Flang%3Dit&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ypVIOxpS5rL%2Bb1P4evKkJKj8rnv%2FNUSKZ5Lu7hjCHEg%3D&reserved=0>*[image:
>>> signature_94942281]*
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fit.linkedin.com%2Fcompany%2Finfocert&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5n8hIsYud5ejcKSHe46gwE2auHP1rtM7D7HcPVgjD9w%3D&reserved=0>
>>>  *[image: signature_3724288091]*
>>> <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffuturodigitale.infocert.it%2F&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FC5UlSKa5Mynb8OfyLOwZLaF6M%2B7Mgr1LnYdjD20aD0%3D&reserved=0>
>>>  *[image: signature_1149165980]*
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fit-it.facebook.com%2FInfoCertSpA%2F&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y4KnSj8%2B3jWIklZxOuEEdTto%2FCsKIbrpd%2FWnwSAkogI%3D&reserved=0>
>>>  *[image: signature_175839328]*
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fuser%2Finfocert&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lXeRMOF22GYycqjUg6YSa1uvYLxBbwmxcRxGqLEN%2FOc%3D&reserved=0>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Paul Bastian <paul.bastian@posteo.de> <paul.bastian@posteo.de>
>>> *Date: *Tuesday, 7 February 2023 at 18:48
>>> *To: *public-credentials@w3.org <public-credentials@w3.org>
>>> <public-credentials@w3.org>
>>> *Subject: *Re: RWOT Holder Binding paper got published
>>>
>>> This email is from an unusual correspondent. Make sure this is someone
>>> you trust.
>>>
>>> Thanks Steve and Oskar,
>>>
>>> I think we have a common understanding of the underlying tradeoff about
>>> what metadata to put into the VC and what's "implicit" from a particular
>>> binding type. However I think that the trust/level of assurance problem
>>> should not be mixed up with the holder binding problem too much, they are
>>> definitely related.
>>>
>>> Whether a verifier can trust the holder's credential and if this trust
>>> or level of assurance is enough for his use case is a fundamental building
>>> block of his business logic that he will usually do upfront (so I agree
>>> with Option2 being the majority today). The verifier will maintain
>>> therefore his own list of trusted issuers or he will import an external
>>> trusted issuer list(governed by a trusted third party). In the best case,
>>> these constraints should be reflected in his presentation request,
>>> otherwise this will result in a bad UX.
>>>
>>> I think its a good idea to include a hint or reference into the VC how
>>> to query the LoA os this particular VC. But who is actually trustworthy to
>>> say that this VC is LoA eIDAS-substantial? Probably an EU trusted registry
>>> that lists all issuers and their VCs that were audited and accredited to be
>>> at such LoA. What's the value of the issuer claiming himself the LoA?
>>>
>>> These questions are very important. But this discussion is in my opinion
>>> not what the paper is about. We are proposing a unified way how to convey
>>> the different binding information for W3C VCs.
>>>
>>> An imaginary example: Under eIDAS, an PID issuer issues a W3C VC, the VC
>>> might give the hint that this is eIDAS-substantial/high, the trusted source
>>> for this issuer and his LoA is the EU trusted list, the issuer provides 2
>>> binding types: "eIDAS-portrait" provides a portrait picture of the subject
>>> and shall be used for on-site/offline verification. "eIDAS-remote" provides
>>> a key pair(that is linked to MFA) that can be used to
>>> authorize/authenticate the VC in an online scenario. both binding types are
>>> described in a standard somewhere and particularly describe the LoA, the
>>> required identity proofing process and what is neccessary for a correct
>>> holder binding etc
>>>
>>> Best regards,
>>> Paul
>>>
>>> On 07.02.23 17:49, steve.e.magennis@gmail.com wrote:
>>>
>>> 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>
>>> <oskar.vandeventer@tno.nl>
>>> *Sent:* Tuesday, February 7, 2023 8:02 AM
>>> *To:* Bastian, Paul <Paul.Bastian@BDR.de> <Paul.Bastian@BDR.de>;
>>> Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl> <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.
>>>
>>>
>>>
>>>    1. 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.
>>>    2. 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.
>>>
>>>
>>>
>>>    1. 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
>>> *Sent:* dinsdag 7 februari 2023 16:37
>>> *To:* Deventer, M.O. (Oskar) van oskar.vandeventer@tno.nl; Terbu,
>>> Oliver oliver.terbu@spruceid.com; Credentials Community Group
>>> 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:
>>>
>>>    1. 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.
>>>    2. 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>
>>> *Sent:* dinsdag 7 februari 2023 15:55
>>> *To:* 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.
>>>
>>> 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?
>>>
>>> 1.       --> 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
>>>
>>> 7.       Has verification been performed on each binding property, or
>>> have any been provided by the subject without further verification?
>>>
>>> 1.       --> the issuer is responsible for any binding types that he
>>> issues.
>>>
>>> 8.       What are the assurances that all three binding properties are
>>> about the same subject?
>>>
>>> 1.       --> 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.
>>>
>>> 9.       Within what legal framework has the verification by the issuer
>>> taken place? (E.g. Europe eIDAS, PIPEDA Canada, ...)
>>>
>>> 1.       --> 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 <oliver.terbu@spruceid.com>
>>> <oliver.terbu@spruceid.com>
>>> *Sent:* donderdag 2 februari 2023 17:38
>>> *To:* Orie Steele <orie@transmute.industries>
>>> <orie@transmute.industries>
>>> *Cc:* Credentials Community Group <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>
>>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furlsand.esvalabs.com%2F%3Fu%3Dhttps%253A%252F%252Fgithub.com%252FWebOfTrustInfo%252Frwot11-the-hague%252Fblob%252Fmaster%252Ffinal-documents%252Fidentifier-binding.pdf%26e%3Dfe314e73%26h%3D86e570f3%26f%3Dy%26p%3Dn&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QKPtJsJU%2BEYJkgoX8Wpb8977%2BGxyTHt5c%2BzgiPiWbFw%3D&reserved=0>
>>>
>>> -
>>> https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furlsand.esvalabs.com%2F%3Fu%3Dhttps%253A%252F%252Fgithub.com%252FWebOfTrustInfo%252Frwot11-the-hague%252Fblob%252Fmaster%252Ffinal-documents%252Fidentifier-binding.md%26e%3Dfe314e73%26h%3D9c5eb6ca%26f%3Dy%26p%3Dn&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PVAO2yqP7J45bQFTIqHju2%2FTXC4vH%2BJRfqw4ZzwdWqQ%3D&reserved=0>
>>>
>>>
>>>
>>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furlsand.esvalabs.com%2F%3Fu%3Dhttp%253A%252F%252Fwww.transmute.industries%26e%3Dfe314e73%26h%3D20f3697c%26f%3Dy%26p%3Dn&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588085107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w%2FcKdT%2BjumWECmo8vXtfWEF%2BS9Vxnls0G6MTYCLHpZU%3D&reserved=0>
>>>
>>>
>>>
>>>
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furlsand.esvalabs.com%2F%3Fu%3Dhttps%253A%252F%252Fwww.transmute.industries%252F%26e%3Dfe314e73%26h%3D764910fc%26f%3Dy%26p%3Dn&data=05%7C01%7Cpdietrich%40gs1us.org%7C58db16b59ea144ed896308db0a90a3ce%7C862adc931361478abb32c28d2d00df8d%7C0%7C1%7C638115388588242040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ko2MBoLmSSa8XDkJyRCC84L%2FZfZuFOooaH3rXgW9s3w%3D&reserved=0>
>>>
>>>
>>>
>>> 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.
>>>
>>>