- From: Paul Bastian <paul.bastian@posteo.de>
- Date: Tue, 14 Feb 2023 13:00:14 +0000
- To: public-credentials@w3.org
- Message-ID: <3aab0ac3-9ca6-8363-0db8-37d397d01c6d@posteo.de>
I think you missunderstood parts of our paper. Of course you can do everything as a claim. But why is e.g. issuanceDate a mandatory toplevel property as it could also be made with a a simple claim? The purpose of our proposal for holder binding is to give clear, future-proof mechanisms for syntax and semantics how the issuer can give guidance for verifiers how to identify the legitimate holder. The intention and meanings of the issuer and the mechanisms how he identified the holder or subject are very valueable information and is best to not let the verifiers guess which claims should be used in which matters and circumstances. We do not even give exact means on how to do this but create the framework and examples, becacuse we do not claim to have a golden solution nor will there be a golden solution. This is also the reason why I doubt it is useful to put this now as normative guidance into the spec as we cannot foresee this yet. Best regards, Paul On 14.02.23 09:19, David Chadwick wrote: > > > On 14/02/2023 19:14, Oliver Terbu wrote: >> 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. > > We can add normative guidance for this without creating a new binding > property in the VC. > > Kind regards > > David > >> >> 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> >>>> <mailto:luca.boldrin@infocert.it> >>>> *Date: *Thursday, February 9, 2023 at 3:27 AM >>>> *To: *Paul Bastian <paul.bastian@posteo.de> >>>> <mailto:paul.bastian@posteo.de>, >>>> public-credentials@w3.org <public-credentials@w3.org> >>>> <mailto:public-credentials@w3.org> >>>> *Cc: *Luca Boldrin <luca.boldrin@infocert.it> >>>> <mailto: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 >>>> >>>> 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 >>>> >>>> A picture containing text Description automatically >>>> generated***E *luca.boldrin@infocert.it >>>> <mailto:luca.boldrin@infocert.it>,**_luca.boldrin@unipd.it >>>> <mailto:luca.boldrin@unipd.it>_ >>>> >>>> ***P****/Think before printing/* >>>> >>>> *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>*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>***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>***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>***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> >>>> <mailto:paul.bastian@posteo.de> >>>> *Date: *Tuesday, 7 February 2023 at 18:48 >>>> *To: *public-credentials@w3.org >>>> <public-credentials@w3.org> >>>> <mailto: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> >>>> <mailto:oskar.vandeventer@tno.nl> >>>> *Sent:* Tuesday, February 7, 2023 8:02 AM >>>> *To:* Bastian, Paul <Paul.Bastian@BDR.de> >>>> <mailto:Paul.Bastian@BDR.de>; Joosten, H.J.M. >>>> (Rieks) <rieks.joosten@tno.nl> >>>> <mailto: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. >>>> >>>> 3. 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> >>>> <mailto:oliver.terbu@spruceid.com> >>>> *Sent:* donderdag 2 februari 2023 17:38 >>>> *To:* Orie Steele <orie@transmute.industries> >>>> <mailto:orie@transmute.industries> >>>> *Cc:* Credentials Community Group >>>> <public-credentials@w3.org> >>>> <mailto: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. >>>>
Received on Tuesday, 14 February 2023 14:04:00 UTC