Re: RWOT Holder Binding paper got published

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