- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 10 Jun 2021 10:52:37 -0400
- To: W3C Credentials Community Group <public-credentials@w3.org>
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