- From: Justin Richer <jricher@mit.edu>
- Date: Tue, 24 Aug 2021 17:23:06 -0400
- To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
- Cc: public-credentials@w3.org
- Message-Id: <5E826698-6402-4229-BEC5-86CF20DF367A@mit.edu>
I agree with loose coupling, which is why I’m against mandating details like “client credentials” in the spec and believe we should stick to describing how to request access from an API-focused perspective. What are the different kinds of actions that this API will allow? Then we can talk about how to ask for each of those kinds of actions. I’ve put together a concrete proposal for the authorization section because I don’t believe it’s actually as complex or interwoven as it’s being made out to be: https://github.com/w3c-ccg/vc-http-api/pull/226 <https://github.com/w3c-ccg/vc-http-api/pull/226> As such, I don’t think it really makes sense to pull this out into a separate spec. If you want to get into the gritty details about token formats and grant types and client deployment types, then yeah that belongs nowhere near this core spec, and I’ve said that all along. But if you look at an API, the API ought to be self-describing in terms of its intrinsic security model, and as an API the security model should be focused around what can be done with the API. That’s what this tries to address, and the work should stop there. — Justin > On Aug 23, 2021, at 4:24 AM, David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote: > > On 22/08/2021 20:25, Joe Andrieu wrote: >> >> On Sun, Aug 22, 2021, at 11:25 AM, David Chadwick wrote: >>> For example, I think the minimum authz token that should be accepted, where one is needed, is an X.509 PKC. Plain and simple. No authz/delegation infrastructure is needed for this. Requiring an Oauth token is heavier lifting as Oauth requires Https as the foundation. (And yes I accept that some calls may not require any authz at all, and be publicly accessible) >> >> This is a great example for why any early binding at this stage is likely a poor choice. > > that's exactly my point about why the http api spec should concentrate on functionality first and foremost, and leave all the authz and security issues to either last or preferably a subsequent spec. > > David > >> >> IMO, what we should be doing is defining an extension mechanism that allows any number of auth mechanisms to work interchangeably, like we did with crypto-suites for the DID and VC specs. >> >> Then, we can focus on the actual mechanism using real spectext rather than getting lost in rathole discussions about which auth approach is best. >> >> The devil will be in the details for that extension mechanism. Whatever mechanism we choose may not be able to treat all options equally, but at least we can separate the debate about good v bad authorization strategies from the specific means through which we will support authorization. >> >> -j >> >> -- >> Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com> >> LEGENDARY REQUIREMENTS +1(805)705-8651 >> Do what matters. http://legreq.com <http://www.legendaryrequirements.com/>
Received on Tuesday, 24 August 2021 21:23:28 UTC