Re: RWOT Holder Binding paper got published

This is indeed an important paper and a service to the digital credentials
ecosystem.

Section 3.2
<https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md#32-using-identifier-binding-across-multiple-vcs>
clearly
presents the risk to decentralization: "The assessment of whether two or
more *claims* that originate from different *issuers* have the same
*subject*, is a difficult matter that cannot be resolved in the context of
the VCDM. Rather, it requires *verifiers* to make assumptions that they can
ground, e.g., on legislation or governance frameworks that the *issuers* are
subjected (or committed) to, or on experience, best practices, or a risk
assessment." Legislation and governance frameworks are, by definition,
centralized under some enforcement authority.

*We can ask the question: How far can tech take us and what would best
practice be for digital credential components?*

Section 3.1
<https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md#31-the-binding-property>
lists
three kinds of binding property: a public key, a centralized number, or a
biometric. All three of these are potentially non-repudiable and can
therefore hold a subject accountable. Only the public key can be considered
decentralized and used without a witness, e.g. online.

To avoid correlation, each VC *issuer* should be using a different *entity* and
the tech *component* that creates the pair and secures the private key must
provide the *verifier* contextually sufficient assurance that *entity* will
be held accountable under the (effectively centralized) authority.

The "difficult matter" of Section 3.2 boils down providing a witness
acceptable to the *verifier*. That witness could be a *certified* component
that securely manages the link between a centralized number or biometric
and the different *entities* in the different VCs. Public notaries are
common examples of such a witness. They keep a private log linking the
centralized number (e.g. driver's license number) with the non-correlatable
public key. Unfortunately, this kind of witness adds unacceptable
complexity and cost to most transactions.

What would a digital witness look like? An easy answer is a certified ankle
cuff or a certified mobile device biometrically linked to one subject. Even
then, the log of the transaction must be made accessible to the
*verifier* without
the cooperation of the *subject* and this is hardly self-sovereign.

My point is that the "difficult matter" boils down to how biometrics are
used by various *authentication components*. If the biometrics are based on
a *public* template the *component* itself need not be certified as long as
the *party* compiles it from a trusted source.

The log that links the *entity* to the *subject* must then be kept
somewhere where a *verifier* (or *issuer*) can present a transaction ID
along with justification for their request. The obvious place to keep these
logs is with the accountability enforcer. For example, a medical board
could keep a log of signed transactions for their physician context. A
pharmacist *party* could send the physician *entity* along with a
transaction ID to the medical board and keep a record for themselves. In
case of a problem, a court could ask the medical board for the *subject*
 physician.

Continuing, the patient *entity* is *authenticated* by the physician and a
log must be kept by the physician *issuer* in case of an issue ;-) A chain
of custody and accountability in a particular context is thereby
established in a relatively decentralized fashion. The prescription
credential presented to the pharmacist need not include the same *entity*
as the *entity* that is *authenticated* as the *holder* of the
prescription.

Notably, if the public biometrics template is good enough to be
non-repudiable, no general (context neutral) motor vehicle registry of
biometrics is needed. The physician can salt and hash the biometric
template of the patient to prevent the patient *subject* from getting
prescriptions as multiple *entities*. But how would we prevent the patient
from getting parallel prescriptions from multiple physicians? For
controlled substances, the states run prescription drug monitoring programs
(PDMP) that are supposed to be checked by each prescriber and pharmacist.
Credit bureaus and voter registrations are other common examples. That
leaves drug diversion, where an addict *subject* colludes with multiple
patient *subjects* to get the controlled substance. Pharmacists are also
required to check the PDMP but the holder of the prescription would not be
useful in this case unless the addict was stupid enough to present to the
pharmacists as multiple *entities* and be correlated as the *holder* at the
PDMP.

Bottom line, assuming biometric tech is good enough, each reputation
context gets to specify its own policies for accountability and keeps its
own secret deduplication registry. I think that's the best we can do for
decentralization and the "difficult matter" of Section 3.2.

Adrian



On Thu, Feb 2, 2023 at 10:39 AM Oliver Terbu <oliver.terbu@spruceid.com>
wrote:

> On Thu, Feb 2, 2023 at 5:24 PM Orie Steele <orie@transmute.industries>
> wrote:
>
>> Thanks for this!
>>
>> It seems like a naive interpretation of "holder binding" is ... a
>> credential / claim bound to a specific key.
>>
>
> Yes, in our paper, this is still a possible option and probably one of the
> most common once I have seen in applications.
>
>
>>
>> Instead of binding to a "generic subject" the binding is to a specific
>> key (possibly in hardware or software isolation).
>>
>> Is that correct?
>>
>
> Yes, the binding is to a specific "identifier" which can be a key. For the
> sake of this paper we used our definition for "identifier" (which includes
> a public key). *We DO NOT want to start a discussion on terminology here
> on the CCG mailing list*. When reading the paper, please just bear with
> us and keep in mind we used the following definitions:
>
> Identifier
> Data that is used for the purpose of recognizing a (real world) entity,
> typically to distinguish it from other entities in some set. The data is
> typically in the form of characters (or attribute sets), but could also
> take the form of audio (speech), pictures (portrait), etc., or a
> combination of those.
>
> Identifier Binding
> The situation in which there is an identifier that a particular party has
> bound to some entity that it knows to exist, and has specified one or more
> means that other parties can use to identify and/or authenticate that
> entity. Such means are typically specified as part of a VC.
>
>
>
>>
>> OS
>>
>>
>> On Thu, Feb 2, 2023 at 10:21 AM Oliver Terbu <oliver.terbu@spruceid.com>
>> wrote:
>>
>>> Dear all,
>>>
>>> Since we had a number of issues and lots of discussions on holder
>>> binding in the last couple of months, we wrote a RWOT paper and it got
>>> published finally. I'm sharing this already since it is relevant to
>>> upcoming discussions on holder binding in W3C.
>>>
>>> IDENTIFIER BINDING: DEFINING THE CORE OF HOLDER BINDING
>>> -
>>> https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.pdf
>>> -
>>> https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md
>>>
>>> by Paul Bastian, Rieks Joosten, Zaïda Rivai, Oliver Terbu, Snorre
>>> Lothar von Gohren Edwin, Antonio Antonino, Nikos Fotiou, Stephen Curran,
>>> and Ahamed Azeem
>>>
>>> Lead author: Oliver Terbu
>>>
>>> Over the last year(s), various issues have been raised that revolve
>>> around what has been called 'holder binding'. The term 'holder binding'
>>> itself isn't clearly defined, and is in fact quite contentious. This paper
>>> seeks to come to grips with this discussion. Our first contribution is the
>>> specification of a terminology, which is intended to help readers
>>> understand what we mean to say without requiring them to make assumptions
>>> about such meanings (as is often the case in discussions about 'holder
>>> binding'). Our second contribution is an analysis of a (fictitious)
>>> use-case that suggests that verifiers typically do not need to know who the
>>> holder is (i.e. who has presented the claims to be verified). This analysis
>>> shows that verifiers need capabilities to (a) learn which entity is the
>>> subject of a particular claim, and (b) to know whether or not two subject
>>> identifiers refer to the same entity or to different entities. Also, they
>>> may need assurances regarding the party on whose behalf the component that
>>> has electronically presented the claims, has been using those capabilities.
>>> Our third contribution is a proposal for the syntax and semantics of a new
>>> property that can be used in (different parts of) VCs/VPs, that will
>>> provide verifiers with such capabilities.
>>>
>>> [image: Screenshot 2023-02-02 at 17.17.33.png]
>>>
>>> Thanks,
>>> Oliver
>>>
>>
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>>
>