Re: VC-HTTP-API - A follow up on the RAR presentation

+1 agree. The VC HTTP API shouldn’t care how someone got the token, only what it’s good for. Constraining it to “client credentials” constrains how the client gets the token, constraining to “RAR” constrains describing what it’s good for.

 — Justin

> On Jul 6, 2021, at 11:02 AM, Adrian Gropper <agropper@healthurl.com> wrote:
> 
> If we’re trying to constrain the scope, why do we need OAuth2 and client credentials? As I see it, an issuer’s endpoint presented with an HTTP Authorization: Bearer token need only trust the signature on the token and understand it’s content.
> 
> What am I missing?
> 
> - Adrian
> 
> On Tue, Jul 6, 2021 at 10:34 AM Mike Prorock <mprorock@mesur.io <mailto:mprorock@mesur.io>> wrote:
> Implementer hat from mesur.io <http://mesur.io/> on for the following...
> I think Manu's read on this is good.  A big concern for mesur.io <http://mesur.io/> is scope creep and expansion to the standard without someone volunteering to "do the work", vs items with broad commercial support and with implementers (including ourselves) able to contribute immediately.
> 
> mesur.io <http://mesur.io/> would likewise +1 the following:
> 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.
> 
>  
> Mike Prorock
> CTO, Founder
> https://mesur.io/ <https://mesur.io/>
> 
> 
> 
> On Tue, Jul 6, 2021 at 10:25 AM Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
> 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/ <https://www.linkedin.com/in/manusporny/>
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/>
> 
>