- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 6 Jul 2021 10:23:13 -0400
- To: public-credentials@w3.org
On 6/29/21 9:50 PM, Mike Varley wrote: > (original title for this email was planned to be “Red Fish, Blue Fish, OAuth > Fish, RAR Fish”…) *lol* I'm fighting the urge to re-title the thread... :P Without my organizer hat on... specifically with my "Digital Bazaar as an implementer of the VC HTTP API" hat on: > P1: Only the ‘Green Box’ is in scope for the VC-HTTP-API +1 Digital Bazaar does not want to pull the complexity of token acquisition and life cycle management into an already complex discussion. Putting the yellow and purple boxes firmly out of scope will help the group focus. > so a client needs to know how to ask for permissions > (green box) and how to present the resulting token (green box). Digital Bazaar would like to narrow the scope further. The client asking for permissions should be deferred. We do believe that designing the sorts of permissions using RAR as a template is useful, and that doing so while the API is being developed is useful... but if push came to shove, we'd be happy with an opaque `client_credentials` token provided over OAuth2. To put it another way, if we're going to start getting into rich delegation use cases, Digital Bazaar is going to insist that we pull ZCAPs into scope since there is a data model there, it's been implemented, and we know how to apply it to this API. We also think it would be a bad idea to pull that into scope, and were hoping that the use of RAR would mitigate Adrian's concerns. Since Adrian stated that it wouldn't, we don't see the need to pull RAR into the discussion (as it would be adding complexity and wouldn't bring us closer to consensus). Keep in mind that we're being nuanced in our position -- we do think it's useful to go through the thought exercise of applying RAR to the HTTP API (just as it would be useful to apply ZCAPs) -- but we see doing either as a medium-to-low priority, not a high priority. We expect the priority to increase over the next 6-9 months. > P2: VC-HTTP-API MUST support OAuth 2.0 as an authorization protocol. +1. We would go a step further, suggest, and +1 the following proposal: P5: VC-HTTP-API MUST support OAuth2 Client Credentials as an authorization protocol. > P3: VC-HTTP-API MAY support RAR > P4: VC-HTTP-API MAY support GNAP -1 because you can always do MAY statements. MAY statements are fairly useless in specifications because you MAY do just about anything that the specification doesn't prohibit... and I don't expect we're going to prohibit all authorization mechanisms except for OAuth2. We would be (+0.25) supportive of Justin's reframing: “A VC-HTTP-API using OAuth2 with RAR/GNAP MUST use the following authorization details types:” but only if someone is actually stepping forward to and volunteering to do (and be accountable for) that work in a complementary specification. It was clear that we had no volunteers to do this work on the last call, and until there are volunteers to do that work, we shouldn't say anything about it. Digital Bazaar does think that Justin's proposal for developing this in parallel is a good one, but without someone stepping forward to do that work, it'll be a constant drag and/or distraction. Contrast this to OAuth2 + client_credentials, where we know that there are multiple organizations that would be willing to volunteer to put the work in to make that happen. To summarize, Digital Bazaar would +1 the following proposals: P1: Only the ‘Green Box’ is in scope for the VC-HTTP-API P2: VC-HTTP-API MUST support OAuth 2.0 as an authorization protocol. P5: VC-HTTP-API MUST support OAuth2 Client Credentials as an authorization protocol. -- 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/
Received on Tuesday, 6 July 2021 14:23:30 UTC