Re: Attempts to block work (was: Re: VC HTTP Authorization Conversation)

I’m not arguing for UMA. I mentioned it because the problem it’s designed
to solve, as an extension of OAuth2, is real and I was challenged, in jest,
about panhandling for a better cup of coffee.

There’s a reason those of us that worked on and implemented OAuth and UMA
for about a decade are now working on GNAP. I am not qualified to explain
the technical issues but I have linked to the explanation that is an
appendix to the GNAP draft 5 doc.

OAuth2 is fine for what it does and I have not argued against it. All I’m
saying is that self-sovereign protocols raise privacy issues that UMA and
GNAP are designed to address.

W3C may decide to address the privacy issue somewhere other than  VC-HTTP.

Adrian

On Fri, Jun 11, 2021 at 5:36 PM Jim St.Clair <jim.stclair@lumedic.io> wrote:

> By way of background, here’s the work done by Kantara on UMA:
>
> https://kantarainitiative.org/confluence/display/uma/UMA+FAQ
>
>
>
> Best regards,
>
> Jim
>
> *_______________*
>
>
>
> *Jim St.Clair *
>
> Chief Trust Officer
>
> jim.stclair@lumedic.io | 228-273-4893
>
> *Let’s meet to discuss patient identity exchange*:
> https://calendly.com/jim-stclair-1
>
>
>
> *From:* Brian Richter <brian@aviary.tech>
> *Sent:* Friday, June 11, 2021 4:13 PM
> *To:* Adrian Gropper <agropper@healthurl.com>
> *Cc:* Orie Steele <orie@transmute.industries>; Manu Sporny <
> msporny@digitalbazaar.com>; W3C Credentials CG (Public List) <
> public-credentials@w3.org>
> *Subject:* Re: Attempts to block work (was: Re: VC HTTP Authorization
> Conversation)
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Ok I'll speak up. I've heard references to UMA many times now and have no
> idea what it is or where to find out more. At least with GNAP a google
> search returns relevant results. UMA comes back with uma thurman and a defi
> crypto token I doubt you're referring to..
>
>
>
> On Fri, Jun 11, 2021 at 2:09 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> The privacy issue I’m raising can be handled with UMA.
>
>
>
> - Adrian
>
>
>
> On Fri, Jun 11, 2021 at 4:46 PM Orie Steele <orie@transmute.industries>
> wrote:
>
> Adrian,
>
> Nobody can stop GNAP from being worked on, only you.... can *please* stop
> asking every DIF / ToIP / W3C / OIDF working group to help fix it :)
>
> Since it already has its own dedicated working group here:
>
> https://github.com/ietf-wg-gnap/gnap-core-protocol
>
> and its own dedicated mailing list here:
> https://www.ietf.org/mailman/listinfo/txauth
>
> I'm not sure why we need every possibly related conversation to be an
> advertisement for the fact that GNAP needs more contributors...
>
> Certainly that is the message I am getting.
>
> Current contributor counts here:
> -
> https://github.com/ietf-wg-gnap/gnap-resource-servers/graphs/contributors
> (2)
> - https://github.com/ietf-wg-gnap/gnap-core-protocol/graphs/contributors
> (9)
>
> Time spent on standards and in working group calls costs money... and is
> an investment, one which you / GNAP / GNAP contributors are not entitled to
> receive in unlimited amounts from every person who attempts to attend
> working group calls in the W3C, DIF, ToIP, OIDF or really anywhere other
> than IETF-GNAP-WG....
>
> You have asked for $1 here, $3.50 there... At a certain point, if you
> persist, you are an @type of GnapPanHandler2021 ; )
>
> Obstructing working groups composed of members who could potentially help
> GNAP grow seems a terrible strategy for growing contributors.
>
> https://youtu.be/GEl8IBv98vg?t=228 (GNAP humor to diffuse tension /
> frustration)
>
> Smurf jokes aside, I hope IETF-GNAP-WG gets more contributors and matures
> quickly, and I have nothing against the wg or spec...
>
> Since concrete proposals were requested, here are some to consider:
>
> OS.PROP.0: The W3C CCG VC-HTTPI-API WG and IETF-GNAP-WG agree to joint IPR
> protected development of the GNAP specification  (this is what you appear
> to be insisting on)
> OS.PROP.1: The W3C CCG VC-HTTPI-API DRAFT recommends using
> IETF-GNAP-DRAFT.
> OS.PROP.2: The W3C CCG VC-HTTPI-API DRAFT does not mention IETF-GNAP-DRAFT.
> OS.PROP.3: The W3C CCG VC-HTTPI-API DRAFT recommends not using
> IETF-GNAP-DRAFT
> OS.PROP.4: The W3C CCG VC-HTTPI-API DRAFT forbids using IETF-GNAP-DRAFT.
>
> OS
>
>
>
>
>
>
> On Fri, Jun 11, 2021 at 1:53 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> To keep things in @context, I’m not trying to block work on OAuth2. I’m
> asking for GNAP to be done simultaneously.
>
>
>
> - Adrian
>
>
>
> On Fri, Jun 11, 2021 at 1:00 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> On 6/10/21 11:00 AM, Adrian Gropper wrote:
> > I indeed am attempting to block work on VC-related protocols until "we"
> as
> > a community deal openly with this issue
>
> Given the number of concerns I'm getting related to the "I indeed am
> attempting to block work" statement above, let me try and clarify why that
> is
> not a useful strategy in communities that follow standards-body process,
> like
> this one. Please take a moment to read about how W3C determines consensus:
>
> https://www.w3.org/2020/Process-20200915/#Consensus
>
> As you can imagine, W3C has a process to deal with individuals that
> attempt to
> block work. That process is described in detail above and is very
> effective at
> 1) ensuring that everyone is able to have their point of view considered,
> 2)
> provide concrete proposals to be considered, and finally 3) make decisions
> and
> move on.
>
> We are doing #1 and #2 above right now, and we will get to #3 very soon
> now..
>
>
>
> I suggest that people involved in the discussion 1) spend their time
> attempting to clearly lay out their position, and 2) put concrete proposals
> forward that will result in the least amount of dissent.
>
> Attempting to block work without proposing workable concrete
> counter-proposals
> will not be tolerated and will be dealt with accordingly.
>
> -- 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/
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> <https://www.transmute.industries/>
>
>