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

Alan, I don't understand. I'm not trying to propose VCs as permissions.
Enrollment is a level of indirection between the issuer and a future
verifier.
1 - Enrollment gives the subject a set of capabilities, not a VC.
2 - A subset of the capabilities can later be used by a client to get a VC.
3 - The client may or may not be operated by the subject themselves if the
subject chooses to be a "holder"

By introducing this indorection, I'm adding agency to the subject since #3
is entirely their choice. The negotiation or enrollment contract in #1
clearly gives the issuer control over what capabilities to offer the
subject.

The DMV example is confusing because the staffer is not the subject of the
VC and the driver's license has a biometric. The DMV as issuer will send
the license to the subject as holder but it's the biometric (face and
signature) that actually matters to a notary or other verifier, not the
address. In the general case, verifiers are delegated by the subject the
right to query DMV for VCs associated with the subject. Handing over the
license to the cop is effectively a delegation to access a VC.

Our discussion of delegation would be clearer if the VC is a grade report,
letter of recommendation, prescription, or vaccination record. None of
these typically include a biometric and some of them, like the letter of
recommendation, are not to be accessible to the subject at all.

- Adrian


On Sun, Jan 23, 2022 at 2:21 PM Alan Karp <alanhkarp@gmail.com> wrote:

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