Re: Ideals meet Implementations - Blockchains, NFTs, Decentralization, Oh My!

Christopher Allen’s essay about Principal Authority and delegation law is
helpful to this thread by defining some terms as they relate to DIDs and
Issuers of VCs. For example:

Principal, for the purposes of this thread, is a biometric for a sentient
or “natural” person. Otherwise, how could the principal exert authority or
control?

DID’s have elaborate and diverse control schemes. However, when the subject
of a DID is a natural person, the control scheme could be linked to a
biometric for intellectual simplicity. A biometric-locked secure element
could be self-sovereign and control pseudonymous identifiers without any
external dependency, as did:peer and KERI have shown.

As Joe points out, using DIDs to delegate has issues. To the extent
delegation is key to Principal Authority it has to be considered in terms
of VCs.

A VC with a human subject could be referenced by a biometric (e.g. driver’s
license) or a DID. The link between the DID and the biometric of a
Principal can be established in various ways including a notary, a
standardized biological scanner and template, and indirectly through
reputation registries such as a long-standing social media account.

From the legal, Principal Authority perspective, A VC issuer is a delegate
of the subject. I don’t see any other choice. The delegation may be subject
to regulation or common law, as described by Allen. In some cases, the
relationship between the subject and (a state or powerful employer) issuer
is coerced. In coerced cases, Principal Authority and self-sovereign
identity are limited, but outside of slavery, the subject still has somne
control over the issuer.

Mapping the role of VC issuer onto Principal Authority is therefore a
delegation relationship with the VC subject as described in the Principal
Authority post. The act of delegation is captured in a contract between the
Issuer and the Subject often called enrollment or registration.

Enrollment may or may not result in a VC. It could result in capabilities
that enable the subject to delegate access to a VC as an embodiment of
Principal Authority. The capabilities enable the subject to delegate
control to various experts in order to reduce the burden of answering
verifier requests.

Finally, translating Principal Authority into technical protocols involving
VCs determines how regulators such as Wyoming can innovate and protect
citizens around SSI. The type of subject identifier associated with a
verification event, be it a biometric or a pseudonymous DID must not
restrict the Principal’s ability to delegate to issuers or to intermediary
agents. Such a restriction would be regulatory capture by the standards
groups and completely against the principles of SSI.

- Adrian

On Fri, Jan 21, 2022 at 1:42 AM Joe Andrieu <joe@legreq.com> wrote:

> Kyle Den Hartog <kyle.denhartog@mattr.global> wrote:
>
> > Additionally, the concept of adding a separate
> > controller's verification method into a DID
> > Document would effectively allow for the new
> > controller to represent their ability to act on
> > behalf of the subject.
>
> Unfortunately, this is a huge anti pattern that should not be promoted.
> The semantics are different than what you suggest. It does much more than
> allow the "new" controller to act on behalf of the subject: it makes the
> new controller indistinguishable from the other controllers, without
> distinction of who delegated to whom. E. G., the two could be peers set by
> the party in control of the DID Document, who may not even be listed as a
> formal controller.
>
> Yes, in a loosey goosey way, it approximates delegation, but it does not
> allow the accountability that best of class delegating mechanisms ensure.
> It isn't enough to just enable the specific positive affordance to trigger
> a cryptographic function (which you can do using the controller property as
> you suggest), delegation also needs to provide for accountability and
> restrictions regarding who delegated the ability to do what, to whom.
>
> Sadly, this is wrapped up in the semantic conflation of "controller" in
> the DID spec. It refers to both the role of the party in control of the DID
> document, as enforced by the VDR, *and* to other DIDs whose DID Document's
> verification relationships should be considered as if they were in this DID
> Document. The latter's semantics are closer to inclusion than delegation
> and absolutely will lead to security problems because so few understand how
> it actually works.
>
>
>
> Sent from my Galaxy
>
>
>