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

Thanks, Kyle, for your thoughtful perspective.

My hope was / is that GNAP could form the bridge to "champion the other
side of the work". GNAP as a technical foundation for protocols involving
VCs and DIDs could shift the "legal" or regulatory discussions out of CCG.
The problem, as I understand it, is that adopting GNAP as a MUST in VC-API
and a few other protocols such as Confidential Storage, would invalidate a
lot of implementers' pre-standards work.

- Adrian

On Thu, Jan 20, 2022 at 4:19 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/
>
>
>