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

I agree with much of what Adrian says, but there's one distinction between
VC as credential vs. VS as permission that he doesn't point out.

On Fri, Jan 21, 2022 at 7:49 PM Adrian Gropper <agropper@healthurl.com>
wrote:

>
> 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.
>
>
> The term delegation implies that the delegator is granting the delegatee
some property that the delegator has.  That implication is certainly true
for permissions;  a system in which you can delegate a permission you don't
have is clearly broken.  That's not always true for a credential VC.  For
example, you might work at the Department of Motor Vehicles in a job in
which you issue drivers' licenses even though you don't have one yourself.

--------------
Alan Karp


On Fri, Jan 21, 2022 at 7:49 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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