Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Justin Richer <[e-mail]>]

> On Feb 25, 2021, at 2:59 PM, Evert Pot <[e-mail]> wrote:
> On 2021-02-25 3:41 a.m., Seán Kelleher wrote:
>> Yep, this is the big point - OAuth is designed to require the the third leg of trust that creates the NxM problem.
>> 
>> I believe the snippet of Justin's that you quoted actually shows you how you can forgo the trust element using dynamic client registration. It still allows a "server" to identify requests and impose security policies via the client ID, but without requiring the client author to manually register the client in advance of using it (e.g. in the case where the client author doesn't even know what servers the client is going to be connecting to). You still need the client ID, but anyone can get one whenever they need it.
> Apologies if this a dumb question, but how would you discover the dynamic client registration endpoint after getting a 401 unauthorized?
> 
> I couldn't really find anything in RFC7591 about this.
> 
We deliberately left that level of discovery out of the registration spec (7591) because, as it turns out, RS-first discovery is a lot harder than it looks on the surface. There are some tricky privacy considerations around divulging an AS to an unknown party, and while not a dead-stop there you’ve got a lot of use cases where it hurts more than it helps.

In the end, we decided not to solve those aspects together and leave discovery for another spec. I think the call made sense at the time. Now, obviously, this assumption goes halfway out the window when you start doing the registration programmatically, and so discovery on a static relationship vs. discovery on a dynamic relationship are pretty different. 

We’re taking a different approach in GNAP, based on work that was done in User Manage Access (UMA):

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name-requesting-resources-with-i <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name-requesting-resources-with-i>

Caveat, there are still a lot of open questions about the details of this, the focus in GNAP has been on the core delegation protocol so far, but it’s on our radar and we welcome the input.

And then there’s the considerations about hooking up more RS’s in real time, or even having the user/client SPECIFY the AS for the RS to talk to. So ultimately it’s an NxMxP problem, with client, AS, and RS in each slot varying differently depending on the API in question. In most OAuth use cases, the AS and RS have a pre-existing relationship that the client doesn’t know or care about. The client’s just trying to “call this API” and so it gets configured with all the bits it needs to ahead of time when it gets registered. But with a common API, like POP or IMAP, the client just needs to know how to get to the next step to keep going. 

This is one thing I’ve found security engineers simply Do Not Get more often than not: client developers don’t care about your security protocol. Your security is what gets in the way of them doing what they want to do, which is use the API and build an awesome thing. The simpler-to-follow we can make the security process, the better it will be for everyone.

 — Justin