Re: Request for CCG Chair Intervention in CCG Process

There is only 1 PR open, it's been open for 22 days.:

https://github.com/w3c-ccg/vc-http-api/pull/224

It attempts to apply the following resolutions:

https://github.com/w3c-ccg/vc-http-api/pull/224/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R314

As Adrian points out, there was not unanimous consensus on them.

The safest thing to do would be to not attempt to merge any of these
resolutions and wait for guidance from the chairs
regarding the position that Justin, Markus and Adrian are holding.

I interpret their position as generally "The spec SHALL NOT speak of OAuth2
UNLESS the spec also speaks of GNAP".... I don't agree with this
perspective, I think it's harmful, and distracting.

Perhaps we should try to run this proposal directly, if it passes, we can
safely move API security out of scope for the work item :)

I will continue to object to including GNAP in a spec that is meant to
define a usable API.

I would be happy to have the chairs overrule either side of the argument at
this point.

OS


On Sat, Aug 21, 2021 at 1:13 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 8/19/21 1:04 PM, Adrian Gropper wrote:
> > Thank you for the quick and thorough response. I believe the other two
> > resolutions made that day do not meet the criteria for group consensus.
> > Should they be removed entirely, as well?
>
> Adrian, could you explicitly state which two resolutions you're talking
> about?
>
> On 8/19/21 2:57 PM, Orie Steele wrote:
> >> Should they be removed entirely, as well?
> >
> > Yes, PRs for resolutions that have objections should not be merged.
>
> Orie, could you explicitly state which resolutions you're talking about?
>
> ----------
>
> To help everyone understand the remaining resolutions we're contemplating,
> here they are:
>
> The VC HTTP API work item group will separate GNAP from OAuth2 until it is
> clear how much extra work GNAP would add within the scope of the
> specification.
>
> One of the authorization mechanisms defined for the VC-HTTP-API MUST be
> OAuth
> 2 Bearer tokens.
>
> How a VC HTTP API server validates an authorization token is out of scope.
>
> One of the authorization protocols that will be defined for use in the
> VC-HTTP-API MUST be OAuth 2 Client Credentials.
>
> -- 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>