Re: Proposal for Authorization in VC HTTP API

hello Colleagues,

Not having sufficient expertise I've been very loath to comment on this
long running question of authorisation.  However, as an observer, may I say
that I'm still a bit confused about where authorisation is required.

   - there's some nice diagrams emerging that show various different VC-API
   interactions
   - there's robust discussion about whether OAuth or GNAP should be used
   for VC-APIs
   - But I'm unclear about which VC-API interactions should require
   authorisation and which should not.

I know there's a lot more than just holder->issuer and holder->verifier
interactions but I'll use them to illustrate the case

   - I can imagine that an issuer will certainly want to authorise a
   subject that is requesting a VC.  "yes, that's the john smith we know,
   here's your digital drivers license"
   - But I cant imagine why or how a verifier will want to authorise John
   when he presents his license as proof of age in a bottle shop because
   there's very unlikely to have been any a-priori registration of either john
   or his chosen system to the bottle shop system. Instead I'd expect an
   anonymous access "yes, that's a valid drivers license and, yes, the photo
   on it looks like you sir, here's your vodka".

would it be possible to see a diagram of VC-API interactions with some
indication of which require auth and which dont?

On Sun, 22 Aug 2021 at 06:08, Orie Steele <orie@transmute.industries> wrote:

> > It's our responsibility as Editors to ensure that we create secure APIs.
>
> We obviously can't force people to acknowledge that OAuth2.0 is the
> defacto solution to this problem which imposes the smallest burden on
> implementers.
>
> A group that allows a vocal minority to hold up implementers who are
> trying to implement reasonable security recommendations either lacks
> leadership or security experts, or both.
>
> We can't lead folks who don't want to follow us, if we split the group up
> between folks that want an API that works with off the shelf authorization
> servers, and folks that want to bundle support for an
> emerging authorization protocol into an API... we'd make instant progress.
>
> Just move authorization with GNAP or OAuth into its own spec... Stop
> trying to force feed OAuth believers GNAP and vice versa.
>
> I would personally love to see both, I just don't want to be forced to
> LEAD both.
>
> OS
>
>
>
>
> On Sat, Aug 21, 2021 at 2:06 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 8/19/21 2:57 PM, Orie Steele wrote:
>> >> As an editor ... note that the working group could not agree to any
>> >> normative requirements regarding securing HTTP APIs.
>> >
>> >> ... admitting that the group couldn't handle basic api security
>> >> recommendations sends probably not the signal we were all hoping
>> for...
>> >> but it is an accurate reflection of the current state of the work.
>>
>> Orie, I'd like you to reconsider your position for at least two reasons
>> 1) it
>> is not an accurate reflection of the current state of the work, and 2)
>> doing
>> what you suggest (saying "we couldn't agree to secure the API, but here
>> are
>> some externally defined options") would result in an insecure technology.
>> It's
>> our responsibility as Editors to ensure that we create secure APIs.
>>
>> For the first item: at this point we have confirmation from all of the
>> implementers (except Adrian) that they are going to, at a minimum,
>> implement
>> OAuth2 Authorization with Client Credentials. We did not have that
>> confirmation until recently. So, it is not an accurate reflection that the
>> group "couldn't handle basic api security recommendations", when the vast
>> majority of the implementers seem to be on that path and the objections
>> seem
>> to be coming from a vocal minority.
>>
>> For the second item; it is indefensible to formally object to the group
>> defining at least one concrete authorization mechanism for normatively
>> securing the API.
>>
>> Given the two assertions above, and the CCG Chairs current guidance to
>> enable
>> the Editors to seek consensus and record dissent, here is the proposed
>> path
>> forward.
>>
>> I expect that Adrian will request that we strike some aspect of the OAuth2
>> Client Credentials resolution (even though all the implementers except
>> for him
>> plan to support that authorization mechanism).
>>
>> This signals to the group that writing a PR to 1) normatively state that
>> certain endpoints require authorization, and 2) define Oauth2 Client
>> Credentials as one of those mechanisms won't be a waste of anyone's time.
>> If
>> someone wants to object to merging that PR, they will have to have an
>> excellent technical/security/privacy/sovereignty argument to back it up.
>>
>> If the individuals that support GNAP/RAR would like to write a similar PR,
>> they are welcome to do so, but given the feedback we have so far (no
>> implementer, except for Adrian, plans to implement it at this time), it's
>> not
>> clear that doing so would be a good use of one's time (at least, for the
>> next
>> couple of months).
>>
>> Therefore, I suggest that the group runs the following proposal:
>>
>> PROPOSAL: Internal VC HTTP API endpoints[1] MUST be protected by at least
>> one
>> authorization mechanism.
>>
>> I would hope that we can achieve consensus on the item above.
>>
>> Then, people that want to see OAuth2 Client Credentials or GNAP happen
>> should
>> raise a PR so the group can discuss. People can object to those PRs at
>> that
>> time. In other words, we shouldn't spend any more time passing proposals
>> for
>> things that we intend to write. We were doing that as a proxy for trying
>> to
>> understand what people would support. We now know at least one thing that
>> people would support... and folks should just get on with writing the
>> things
>> about authorization that they want to see happen.
>>
>> Thoughts?
>>
>> -- manu
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit
>>
>> --
>> 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/
>>
>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>


-- 
Steve Capell