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

Implementer hat from mesur.io on for the following...
I think Manu's read on this is good.  A big concern for 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 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/



On Tue, Jul 6, 2021 at 10:25 AM Manu Sporny <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/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>