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

Exactly right.

I would only add an example to make clear how responsibility works.  Alice
delegates some permissions to Bob and will hold him responsible for actions
he takes with the delegated permission.  Bob delegates a subset of those
permissions to Carol.  He will hold Carol responsible for actions she takes
with the delegated permissions.  Alice, on the other hand, will hold Bob
responsible for the actions Carol takes.  Of course, Alice might have
independent knowledge of Carol and can hold her responsible, but that's not
necessarily the case.

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


On Thu, Jan 20, 2022 at 2:51 PM Bob Wyman <bob@wyman.us> wrote:

> I may be over-parsing Kyle Den Hartog's note, however, I am concerned that
> his comments seem to equate "transfer of credentials" with "delegation." I
> believe that these are two very distinct matters, rather than just two
> terms for the same thing.
>
> Delegation typically means something like "the potentially limited
> transfer of some right or capability while retaining accountability for the
> outcome of its use." One can delegate a right or capability, but not the
> responsibility for the consequences of its use. If both the right and the
> accountability are transferred, then a simple transfer has occurred, not a
> delegation. This is why I have argued, in previous discussions, that
> delegations should not be performed by transferring VCs. In order to ensure
> that the connection between the delegated VC and the delegator are
> maintained, a delegation should be instantiated as a new, distinct
> "delegation" VC which refers to that VC which represents the right or
> capability which is being delegated. The act of delegation would not modify
> or invalidate the original VC, only annotate it by reference. Additionally,
> the delegating VC should typically include some description of the
> delegation's limitations. For instance, how long the delegation is to
> remain in force, or the scope of the delegation. And, VCs for things which
> might be delegated should have a means of specifying whether delegation is
> permitted and, if only partial delegations is permitted, what limits may
> exist on the ability to delegate.
>
> Some examples:
>
>    - I may hold a VC which is a license to operate vehicles of some type.
>    Typically, such a VC can be neither transferred nor delegated.
>    - I may hold a VC which establishes my ownership of some specific
>    vehicle:
>       - I could "rent" that VC to you, via a delegation, and thus
>       delegate to you the right to operate and maintain the vehicle as though it
>       were your own. Nonetheless, I remain the owner of the vehicle and continue
>       to bear the responsibilities associated with its ownership. Additionally, I
>       may limit the delegation by requiring that you not operate the vehicle
>       outside some specified geographic area and also that you may not
>       re-delegate the delegated rights to anyone else (i.e. only you can drive
>       it.).
>       - I may "sell" the VC to you, via a transfer, and thus transfer to
>       you both the rights associated with ownership as well as the
>       responsibilities. Upon the conclusion of such a transfer,I am no longer the
>       owner of the vehicle.
>
> I believe that it is important that we clearly distinguish between
> "transfers" and "delegations." They are very different things. Both involve
> transfers of rights, but delegations neither transfer responsibilities nor
> sever the link between the right and its pre-delegation holder.
>
> bob wyman
>
>
> On Thu, Jan 20, 2022 at 4:22 PM Kyle Den Hartog
> <kyle.denhartog@mattr.global> wrote:
>
>> I think it's worth pointing out that in a technical sense delegation is
>> not that tricky of a problem, since it's mainly focused on establishing
>> patterns of usage in either the DID or VC layer and evaluating the
>> different tradeoffs that come with the chosen patterns. However, I don't
>> believe enough of us haven't had time or business cases that have driven
>> the priority for us to standardize a solution for this problem quite yet.
>> That's not to say we haven't thought about the issue or started to explore
>> it. I know many people in the ToIP ecosystem have, there's some brief
>> mention of capabilities mentioned in the VC spec already, and there's
>> aspects of consideration that I know have been brought up in the past based
>> on credential transferability and whether it should be acceptable or not.
>>
>> With this in mind, I think Moxie's original points are very important to
>> us. They're not outside the realm of possibility for us to extend the VC or
>> DID Core data model to make our work aligned with his description and
>> potentially standardize on the designs in future working groups. The two
>> key methods I see being usable here are either via the addition of
>> non-controller based verification methods for the did document or via some
>> method of transferring of credentials between holders. My thinking is that
>> the VC credential transfer method is probably the better option because it
>> serves the purpose of credential portability and multi-device flows. The
>> downside is that this could run up against the requirements that come from
>> subject authenticity and needing to understand acceptable usages of
>> transfer and unacceptable usages.In any case, I think we're well positioned
>> to address these concerns if we choose to focus on enabling transparent
>> portability in a way that avoids confused deputy issues, balances the
>> desires of the user (as Moxie points out not wanting to run their own
>> server which implies the need of custodial services), and takes a balanced
>> and measured approach to get there that will apply broadly to many
>> different use cases and deployment patterns.
>>
>> Furthermore, by combining these aspects with other legal approaches like
>> terms of services and other methods I believe we're slowly on track to
>> aligning with the human rights described by Adrian.  Unfortunately, I only
>> have the knowledge to contribute on the technical levels. I assume many
>> others in this forum are likely caught in the same boat with a few people
>> here able to champion the other side of the work. However, It may be that
>> there's too few of people here who do have that level of legal expertise to
>> keep that moving forward here and so those discussions need to be had else
>> where. I'm not certain but what I can say is that for the technical aspects
>> we are heading in the right direction (even if it takes longer than
>> expected) to align with Moxie's thinking to set up the technical rails for
>> broader decentralization of systems.
>>
>> -Kyle
>> ------------------------------
>> *From:* Adrian Gropper <agropper@healthurl.com>
>> *Sent:* Friday, January 21, 2022 7:17 AM
>> *To:* W3C Credentials Community Group <public-credentials@w3.org>
>> *Subject:* Re: Ideals meet Implementations - Blockchains, NFTs,
>> Decentralization, Oh My!
>>
>> EXTERNAL EMAIL: This email originated outside of our organisation. Do not
>> click links or open attachments unless you recognise the sender and know
>> the content is safe.
>>
>> Manu, thank you for the blunt response and your focused suggestion. I
>> also thank Anil and the others that have contributed to this thread.
>>
>> I hear you and I will keep my CCG comments to this thread as I try to
>> find a co-lead and write something as Manu is suggesting. I will work hard
>> to avoid introducing this issue into other discussions on CCG. In VC-API, I
>> will stick with the authorization/delegation related Issues and avoid
>> discussing human rights or burdens except in the context of specific
>> issues.
>>
>> This thread is specific to the broad decentralization issues raised by
>> https://moxie.org/2022/01/07/web3-first-impressions.html so I hope it
>> continues to the extent any of the 450+ people in CCG find it useful.
>>
>> In an attempt to name and scope a CCG Work Item, I would point to two
>> relevant calls today. ToIP discussed the relationship between KERI (and
>> did:peer) as it relates to DIDComm. The notes are superb:
>> https://wiki.trustoverip.org/display/HOME/2022-01-20+TATF+Meeting+Notes My
>> takeaway, as it relates to this thread, is that the reputation associated
>> with an identifier needs to be handled at a different layer from the
>> messaging associated with the identifier. Although the meeting ended
>> without a conclusion, I urge everyone in CCG to listen or at least read the
>> notes whether you have a direct interest in ToIP or not. That is
>> particularly important for Anil and others that hope to regulate the
>> interaction between non-repudiable (as in, for example, biometric)
>> identities and pseudonymous identifiers as they are used in CCG-related
>> protocols.
>>
>> The other relevant call today was a GNAP interim meeting where Dmitri
>> Zagidulin presented on the applicability of the GNAP interaction model to
>> VC-API.
>> https://docs.google.com/presentation/d/1fCUvUHo_x34rHfjvd4YSMcnuSqM-94V-ds_V7Lyc-Sc/edit#slide=id.p
>> The minutes will be posted here
>> https://datatracker.ietf.org/wg/gnap/meetings/ This conversation is
>> exactly what I have been hoping for, as it makes explicit support for
>> delegation of access to a VC and the  privacy considerations for requests
>> that might include a VC and/or result in access to a VC.
>>
>> So, this reply is not yet a formal work item proposal but if anyone
>> thinks there's a relationship between Moxie's delegation to servers
>> perspective, KERI's clarification of reputation relative to messaging, and
>> the way GNAP handles requests to an authorization server, then we're making
>> progress.
>>
>> And yes, I do apologize to all for my circuitous path on the way to being
>> able to reference specific technical concerns that are hopefully relevant
>> to CCG.
>>
>> Adrian
>>
>> On Thu, Jan 20, 2022 at 10:54 AM Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>> Adrian, I'm going to try and speak directly below. It might come off as
>> rude,
>> but that's not my intent.
>>
>> The responses to your questions on the mailing list from others have gone
>> out
>> of their way to be polite in their framing. Since I've worked with you for
>> going on five years now, having met you in person and shared a number of
>> nice
>> meals and conversation, I'm going to take the approach of being politely
>> blunt. There was a time where your input was helpful, but it has
>> degenerated
>> into commentary that is largely unhelpful over the past year or so. You
>> have
>> been harming your cause by continuing to engage in the way that you are
>> and
>> people are starting to increasingly ignore your input.
>>
>> I'm saying this because I respect your time and the time of everyone else
>> that
>> is responding to you.
>>
>> On 1/18/22 9:50 PM, Adrian Gropper wrote:
>> > CCG rules require two leads for the work item. Ideally, the two people
>> > structuring the work item should both represent implementers and I
>> could
>> > continue to play my advisor role.
>>
>> Adrian, you need to step up and become ONE of the co-leads for the work
>> item.
>> You can't continue to insist that other people do the work that you want
>> done.
>>
>> The best work items tend to have ONE technical lead and ONE non-technical
>> lead. My suggestion to you is to find a technical lead to help you with
>> the
>> work item, while taking lead.
>>
>> > If there aren't two separate people in CCG that are concerned about the
>> > burdens of standardized digital credentials and/or the relationship to
>> > biometrics in DIDs and VCs, then pushing a work item seems pointless.
>>
>> There are 450+ people in this community group. You are not the only one
>> that
>> cares about the things that you do.
>>
>> This has been repeatedly stated to you, but it does not seem to be
>> sinking in.
>> There's a certain amount of social unawareness at play here that is
>> frustrating to many of us, as well as you, I'm sure.
>>
>> I know others are deeply concerned about "the burdens of standardized
>> digital
>> credentials on those that hold them" and "the relationship to biometrics
>> in
>> DIDs and VCs". I know I am and I've spoken with others that have the same
>> concerns, but your continued insistence that this is not a priority for
>> everyone but you pushes people to not want to work with you. That you keep
>> asking vague questions and citing passages in United Nations documents
>> that
>> have tenuous links to the vague questions you're asking are not helping
>> make
>> your case.
>>
>> A number of us have had one-on-one conversations w/ you and continue to
>> try to
>> guide your input in a positive direction. You have been reminded, multiple
>> times, on calls to find a way to contribute in a way that is positive and
>> at
>> least to stop derailing conversations that have nothing to do with
>> delegation
>> or "digital slavery" or GNAP or biometrics or "digital burdens".
>>
>> Please step up, Adrian, and write something that you can get others on the
>> mailing list to rally behind. Until you do that, your pleas for others to
>> care
>> as much about this stuff as you do will continue to result in nothing
>> actionable and wasted effort on everyone's part, including yours.
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> News: Digital Bazaar Announces New Case Studies (2021)
>> https://www.digitalbazaar.com/
>>
>>
>>