Re: RWOT Holder Binding paper got published

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.
>>
>>