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

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> wrote:

> 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/
>>
>>
>>