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

Excellent points Bob, I did short sight that nuance in a way that could mislead readers in the wrong direction. Your breakdown of the differences between transfer of credentials and the delegation of credentials is slightly different and it affects the use cases. The reason I spoke in that way was because in my experience of describing how they technically work the data model will represent a delegated credential and the way a transfer of a credential is represented in the data model are very similar. 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. Both the controller of the did document and the controller of the verification method would effectively still be able to issue a verifiable credential on behalf of the subject acing as a controller. This is not a pattern that's widely used but is something that works with many current implementations of verifiable credential libraries today that rely on DIDs.

The point being that there's many ways to achieve this and technically they can be represented very similarly even though from a business logic layer they are very different. Thank you for raising this because it is an important point for people to catch if they didn't see it the last time you made it. I suspect as we standardize on the nuts and bolts of this topic more, we'll need to spend time finding how to align the work while also making sure that the nuances you point out in the examples are fully addressed going forward. We'll get there eventually as the priorities for it drive the work further and I'm sure those points will all be ones that will be considered as we take the concepts of transferability and delegation further through the standardization process at the data model layer.

-Kyle
________________________________
From: Bob Wyman <bob@wyman.us>
Sent: Friday, January 21, 2022 11:48 AM
To: Kyle Den Hartog <kyle.denhartog@mattr.global>
Cc: Adrian Gropper <agropper@healthurl.com>; 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.

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<mailto:agropper@healthurl.com>>
Sent: Friday, January 21, 2022 7:17 AM
To: W3C Credentials Community Group <public-credentials@w3.org<mailto: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<mailto: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/