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

From: Vittorio Bertola <[email-masked]>
Date: Mon, 1 Mar 2021 11:44:24 +0100 (CET)

>     Il 26/02/2021 17:32 Aaron Parecki <[email-masked]> ha scritto:
> 
> 
>     Dynamic client registration does exist in OAuth: https://tools.ietf.org/html/rfc7591
> 
>     The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for so long (the Dynamic Client Registration draft was published several years after OAuth 2.0), as well as how large corporations have decided to run their ASs where they want to have (what feels like) more control over the things talking to their servers.
> 
This is indeed a matter of product design. I am active in an OIDC-based open identity project where the specs say that providers MUST accept dynamic client registration, without a pre-determined client secret. This is the only way to create a federation that can work on an Internet scale, with relying parties accepting identities managed by providers unknown to them. Then, of course, this also creates lots of opportunities for abuse: you end up in an email-like scenario in which you need ways to ascertain trust in unknown parties and decide whether you want to accept interoperating with them and believe the information they provide, which in turn depends a lot on your specific use case. But we think that that is preferrable to the centralization that is inherent in the original registration model.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Warren Parad <[email-masked]>
Date: Fri, 26 Feb 2021 17:22:19 +0100

A) I don't think it is helpful to talk about what other WGs are doing, or
how GNAP attempts to fix or not fix these problems.
B) Sharing statements like this:

> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration

Don't help everyone come to the same conclusion, Who is "we" here, it begs
the question "is there a mindset baked into OAuth", I think to work
effectively we need to be talking about how to best to tackle challenges
everyone and anyone brings up and not fallback on arbitrary statements. It
would be one thing to point to a document which outlines the exact issues
with dynamic registration and then we could potentially have a valuable
conversation about "are those reasons still relevant or do we need to
revisit."

Right now it seems there is "Someone in the past decided this was a bad
idea, so we can't do it", rather than actually having the conversation
about it.

Just based on the conversation, it seems like the obvious right thing to do
is provide dynamic registration in OAuth. Will client developers do the
wrong thing, sure. Might it be challenging to support in a simple way,
maybe. But having the addition to OAuth to solve the problem is better than
nothing, and further it starts to change the mindset that dynamic
registration is and should be provided when appropriate.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Fri, Feb 26, 2021 at 5:11 PM Justin Richer <[email-masked]> wrote:

> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration. It’s an extension that changes your trust model’s
> assumptions, and does so in a way that is challenging for a lot of large
> scale providers.
>
> That’s why I personally think it’s really important that we get away from
> that registration model in GNAP, so we don’t repeat that same problem in
> the same way. Some people will still deploy GNAP with static registration,
> but this model becomes more exceptional than baseline. The philosophy of
> what’s considered an extension vs. default is important.
>
>  — Justin
>
> On Feb 25, 2021, at 3:41 AM, Seán Kelleher <[email-masked]> 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.
>
> I'm also feeling a bit of confusion arising from a conflation of terms
> between the regular client/server model and the terminology used in OAuth.
> To be clear, in OAuth, the level of trust between the client and authZ
> server only really depends on policy; as mentioned, dynamic client
> registration can be used if you don't need any trust between the client and
> AS.
>
> On Thu, 25 Feb 2021 at 08:22, Seán Kelleher <[email-masked]> wrote:
>
>> Just to clarify, I assume in this discourse that the "server" in this
>> client and server relationship refers to an AS/RS pair in OAuth
>> terminology? Based on this, one big sticking point for me on the
>> applicability of NxM, or even 1xM, is that all of the "M" RSs need to
>> publish the same interface for any meaningful implementation in the first
>> place.
>>
>> It probably makes more sense with email clients, since as Bron said,
>> there is the common standard of POP. If we assume that all the email
>> services that we want to connect to publish the same POP interface, and
>> would accept tokens in the same way, then the way the authZ is handled is
>> indeed the point of divergence that needs to be resolved.
>>
>> However, we're talking about NxM in the general case here. I feel like
>> using the likes of discovery and dynamic registration, etc. that's already
>> supported by OAuth, the "N" part of this equation is surmountable. But each
>> of the "M" servers also need to export the same interface, otherwise a
>> client is going to have to write custom code to deal with talking to the
>> service after the authZ step anyway, reintroducing the "problem" part of
>> the NxM problem.
>>
>> As such, I would actually suggest constraining this discussion to just
>> the POP NxM problem rather than NxM in general because, for me at least,
>> the authZ part of the general case is the most "solved" part of the
>> problem, and the outstanding work lies more in consolidating the "M" RS
>> interfaces.
>>
>> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <[email-masked]>
>> wrote:
>>
>>> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>>>
>>> I agree that the NxM problem is the purview of the whole IETF, but it’s
>>> something that we’re particularly interested in over in GNAP. As the editor
>>> of OAuth’s dynamic registration extension and the GNAP core protocol, I
>>> hope I can add to this conversation.
>>>
>>> From a technical standpoint, OAuth’s dynamic client registration lets
>>> arbitrary clients talk to an AS, but the trust isn’t there in practice. On
>>> top of that I think this problem is exacerbated by a fundamental protocol
>>> design element of OAuth: the client_id that’s required. That field means
>>> there’s an assumption that a relationship was set up between the pieces of
>>> software, implied to be trusted by admins at the AS. Sure you can get that
>>> client_id under special circumstances, but there’s still a special weight
>>> handed to that and the dynamic stuff feels like you’re giving up control as
>>> an AS. In GNAP, the relationship is inverted, and it’s designed as
>>> “dynamic-first”, with pre-registered clients being an optimization on top
>>> of that.
>>>
>>>
>>> Yep, this is the big point - OAuth is designed to require the the third
>>> leg of trust that creates the NxM problem.
>>>
>>>
>>>
>>> If that dotted line between client and server requires a pre-existing
>>> trust relationship rather than the trust being entirely mediated by the
>>> user choosing to connect client A with server B, then you have the NxM
>>> problem.  This is the "you can only have your John Deere tractor serviced
>>> by an approved John Deere service centre" problem.  You can only use this
>>> client with servers who have pre-approved it.  Or fall back to the "cash of
>>> the internet" - plain text passwords.
>>>
>>> Does this solve the NxM problem? No, because companies are still going
>>> to decide that they only talk to keys or identifiers that they know ahead
>>> of time. But the protocol puts the dynamic case forward as baseline and
>>> fits in much better with the likes of JMAP than OAuth ever could:
>>>
>>> - {The Bat} creates a key pair.
>>> - {User} enters their email address into {Bat}, {Bat} does discovery
>>> (maybe that’s a JMAP thing? Webfinger?) and finds the JMAP server and the
>>> GNAP endpoint for authentication as an option.
>>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
>>> up. {ISP} has never seen this key, but knows how to talk GNAP and get the
>>> user to authorize {Bat} to access email.
>>> - {User} does this using GNAP and gets back an access token that’s tied
>>> to the key {Bat} made back at the beginning. That token is tied (at the
>>> {ISP}) to the user’s account.
>>>
>>> Yes, you can do all of this today with OAuth (and people have done so),
>>> but OAuth’s basic model of “go do discovery and registration first and THEN
>>> talk to me” is a trust impediment more than it is a technical impediment.
>>> The “negotiation” part of the GNAP name comes from the philosophy of “start
>>> talking first and figure out what you need as you go”. Instead of jumping
>>> through hoops to get something you can trust, you just start in and then
>>> decide how much you trust it. A corporate rollout could use its own key
>>> distribution mechanism and static registration to limit which client
>>> instances talk back to the company server, regardless of which accounts
>>> would authorize access on top of that. An internet-facing service is going
>>> to be more likely to take a TLS approach, of “I’ll talk to you in a secure
>>> fashion without caring who you are right now”.
>>>
>>> We really are trying to make GNAP a consistent protocol at its core and
>>> learn from problems with OAuth in the wild, all while letting GNAP address
>>> a wider variety of use cases. I agree that GNAP could be clearer about
>>> specific use cases, and we’re working on the spec still so any help here is
>>> appreciated.
>>>
>>>
>>> Excellent.  This is precisely what I've been waiting for for these very
>>> many years as a viable replacement for storing a password locally on disk.
>>> Just having the server able to distinguish between different client
>>> instances for the same user is a big start, because you can de-authorise
>>> one without having to lock out every connection - even if the user is still
>>> entering their password during the setup phase each time.
>>>
>>> This is what Fastmail already do with our own app, creating a long-lived
>>> access token and storing that on the device rather than storing the
>>> password itself - and you can log out any one client from your security
>>> settings page.  What's missing is a standard way to do that with any IMAP
>>> client.  The initial JMAP authentication proposal was a very simple case of
>>> pretty much this, build into to the protocol so everyone would do it.
>>>
>>> Making it easy to connect up arbitrary clients with per-client tokens
>>> the default, and easy rather than almost impossible to do in practice is
>>> where the big difference comes in.
>>>
>>> Bron.
>>>
>>> --
>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>   [email-masked]
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Jeff Craig <[email-masked]>
Date: Fri, 26 Feb 2021 15:58:58 -0600

On Fri, Feb 26, 2021 at 3:50 PM Aaron Parecki <[email-masked]> wrote:

> > Do you disagree that this gives them control over which things talk to
> their servers?
>
> Yes -- with a public client, I can impersonate a "real" app and it's
> basically non-detectable by the AS. For a theoretical example, if I wanted
> to use the Instagram API but they restrict which apps can upload photos to
> only their own mobile apps, I can find the client ID of their own app, then
> do an OAuth flow using their own client ID, and without a client secret it
> looks the same as their own client. I'm unlikely to be able to get
> arbitrary users to authorize my app because of limits and checks on the
> redirect URI, but I can certainly do it myself for my own account. This is
> the sort of false sense of security provided by the client registration
> step I'm talking about.
>

The fact that you're unlikely to be able to get arbitrary users authorized
as the client is precisely the attack vector that registration is meant to
avoid. The fact that any reasonably sophisticated AS is going to use
additional signals (Referer headers, etc) to limit the scope of the Public
Client to make hijacking harder, which is only possible with registration,
is another line of defense. OAuth doesn't need to protect *your* data from
you, it needs to protect other people's data from you, and registration
offers more opportunities to collect signals that can be used to protect
users.

None of it's perfect, and I agree that there are problems in the
app-identification space that need some additional work, but the
registration friction does serve a purpose in a lot of cases.

>
> I'd love to solve the app identity problem too, but that's only possible
> with cooperation from the mobile OSs.
>
> Aaron
>
> On Fri, Feb 26, 2021 at 1:36 PM David Waite <[email-masked]>
> wrote:
>
>>
>>
>> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki <[email-masked]> wrote:
>>
>> > The point is that basically nobody uses it because they don't want to
>> allow arbitrary client registration at their ASs. That's likely due to a
>> combination of pre-registration being the default model in OAuth for so
>> long (the Dynamic Client Registration draft was published several years
>> after OAuth 2.0), as well as how large corporations have decided to run
>> their ASs where they want to have (what feels like) more control over the
>> things talking to their servers.
>>
>> Do you disagree that this gives them control over which things talk to
>> their servers?
>>
>> FWIW my personal mental model here is pretty simple:
>>
>> With users, there are services you provide anonymously and services you
>> provide only to registered/authenticated/trusted parties for various
>> reasons. Once you are delegating user access, you still have many of the
>> same reasons to provide access to anonymous or
>> registered/authenticated/trusted delegates.
>>
>> Dynamic registration arriving later and requiring additional complexity
>> has unfortunately encouraged registration in use cases where anonymous
>> clients might have been acceptable, but shifting the timelines or
>> complexity balance would not  have changed business needs for
>> authentication and trust of delegates. Omitting registration would have
>> caused businesses to use other protocols that met their needs.
>>
>> If AS’s are only getting what feels like proper control for their
>> business needs, we should attempt to give them the actual control they
>> require.
>>
>> -DW
>