Re: Proposal for Authorization in VC HTTP API

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