W3C home > Mailing lists > Public > public-credentials@w3.org > August 2021

Proposal for Authorization in VC HTTP API

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 21 Aug 2021 15:04:25 -0400
To: W3C Credentials CG <public-credentials@w3.org>
Message-ID: <3204c714-f387-f9ff-c886-53eb65a5792a@digitalbazaar.com>
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

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.


-- manu


Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Received on Saturday, 21 August 2021 19:04:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:21 UTC