Re: VC HTTP Authorization Conversation

Inline

On 6/10/2021 4:52 PM, Manu Sporny wrote:
> 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.
+1 from the use-case team.  We are coming up fast on the deadline for 
"first drafts" of use cases that are far enough along to anchor PRs. If 
you have opinions about #3 and #4 (especially an opinion like, "I would 
hate to see mTLS discouraged as a valid option for #3/4"), a quick way 
to lobby for that opinion is to submit a first-draft use case.  Feel 
free to "fork," riff, or expand on other peoples' submissions that are 
halfway to what you want to see, but too brief, too specific in in 
describing a solution rather than a problem, etc.
>> 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.
Agreed that a tighter scope for this group will get results faster from 
this group.
>> 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.
Agreed that this group needs uncontroversial, concrete results, not 
design constraints imported from discusssions about standards or 
technologies still in flux. The people volunteering to make this API 
testable and get it taken seriously by today's vendors of 
production-grade software are not volunteering to build for the future, 
they are volunteering to build for their paying clients and customers.
>> 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.
Everyone is unanimous in leaving the door open.  Parties asking for 
multiple recommendations have not volunteered to do the extra work; we 
have volunteers committed to doing the OAuth2 work.
>> 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.
-1 as well, ONE viable option is a stronger proposition than 0 viable 
options, 1.5, or even 1.9.
>> 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.
+1 discussing possible futures for this spec is taking up way too much 
time.  Given the timeline for use-cases (and my own commitment to be at 
all meetings until they are stabilized), I'd propose that Tuesday's 
agenda be:
1.) PRs
2.) Issues
3.) Use-cases
> 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.
Thanks for that.  Manu, you've been doing great work moving us through 
the issues as efficiently as possible given the lack of consensus on scope.
> -- manu
>
-----------------
Juan Caballero
Research Lead,
Spherity <https://www.spherity.com> GmbH, Emil-Figge-Straße 80, 44227 
Dortmund
Co-chair, DIF Healthcare Use-cases Discussion Group 
<https://www.eventbrite.com/o/dif-healthcare-special-interest-group-31363301995> 
and DIF Interoperability Working Group 
<https://github.com/decentralized-identity/interoperability/blob/master/agenda.md> 


Berlin-based: +49 1573 5994525 Signal/whatsapp: +1 415-3101351