W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

Re: VC HTTP Authorization Conversation

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 10 Jun 2021 10:52:37 -0400
To: W3C Credentials Community Group <public-credentials@w3.org>
Message-ID: <c16e95da-4eda-6478-a161-db7384f3418f@digitalbazaar.com>
On 6/10/21 10:04 AM, Orie Steele wrote:
> I see the scope of the VC-HTTP-API as limited to the following:
> 
> 1. HTTP endpoints for producing and consuming the W3C VC Data Model Objects
> 2. HTTP endpoints for producing and consuming extensions to the VC Data Model,
> or data structures it relies on, like Revocation Status and Credential Schemas
> 3. Recommendations for securing these HTTP endpoints using HTTP Headers.
> 4. Recommendations for exposing these HTTP endpoints inside and across trust
> domains.

The above feels like a good start to a scoping statement.

> Perhaps it would be better to start a CCG work item dedicated to GNAP and VCs?

+1 to this, Adrian clearly wants to have this discussion, and polling of the
VC HTTP API group is showing that there is not a lot of support for doing that
in that group:

https://w3c-ccg.github.io/meetings/2021-06-01-vchttpapi/#57

A more focused group on how one gets authorization tokens to use with the VC
HTTP API using GNAP might result in 1) a more focused discussion on that
topic, and 2) a tighter scope for the VC HTTP API.

> Or a battle royal between OAuth2.0 the only "real" standard being discussed
> and the drafts for GNAP, OIDF-SIOP, ZCaps with HTTP Signatures and DIDComm
> hosted by the ccg?

I expect this to turn into painful discussion for everyone involved. While I'm
pretty sure Orie was joking about this option, -1 to the concept of comparing
half-baked things against each other when we're trying to make some concrete
decisions for the VC HTTP API.

> I'd prefer we either recommend OAuth2.0 and leave the door open to other ways
> to get an authorization token... 

+1 to this proposal.

> or we label the vc-http-api agnostic to
> authorization, and warn users that they will need to pair it with other specs
> to address security issues associated with exposing http endpoints on the
> internet.

-1 to this proposal, we have kicked the "authorization can" down the road long
enough... 18+ months now... let's not keep doing it when there is a fairly
clear solution that all implementers seem to feel is a viable path forward as
ONE option for authorization.

> I would also love to just do Issue and PR review, and have less open
> discussion on calls, we seem to be discouraging asynchronous work, maybe we
> can limit open discussion to 50% of the call time?

Yes, agreed. Perhaps we start out with PR review first -- because that rewards
the thing we want to see, which is work being done.

Then issue review, because it rewards the second thing we want to see -- which
is asynchronous work.

However, the Authorization discussion HAS been processing issues. Namely:

https://github.com/w3c-ccg/vc-http-api/issues/108
https://github.com/w3c-ccg/vc-http-api/issues/181
https://github.com/w3c-ccg/vc-http-api/issues/187

I try very hard not to do open discussion that's not driving toward some sort
of PROPOSAL or POLL at the end. What I've been trying to do is to make sure
that we get to at least one concrete proposal on each call. Sometimes you
can't get there w/o discussion, which is the case with authorization... but to
be clear, we have been processing registered issues, even though we haven't
been calling them out by issue number.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches
Received on Thursday, 10 June 2021 14:54:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 10 June 2021 14:56:05 UTC