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

[Seán Kelleher <[e-mail]>]

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 <[e-mail]> 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
>   [e-mail]
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>