> On Feb 25, 2021, at 2:59 PM, Evert Pot <m...@evertpot.com> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
