On Thu, Feb 25, 2021, at 19:22, Seán Kelleher 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.
Sorry for the delay in responding - real life got in they way of this general discussion. Yes, the common standard of POP - or indeed any common standard. A fine example of common standards is the move towards many devices being charged by USB-C these days. Previously, there was this: https://en.wikipedia.org/wiki/Common_external_power_supply Why? So you that you don't need a new charger for each new device. The whole point of being a standards org is to try to guide each "M" towards exporting the same interface when providing the same (or similar enough) underlying service, so that the network effects of interoperability are realised. So yes, constrain to POP (and IMAP, and SMTP submission, and file storage, and calendars, and ... everything where there's enough similarity that clients should be able to portably interoperate with multiple services). Right now the problem with POP/IMAP/etc is that the interoperable authentication choice is "username+password". There's nothing better than that because there's no Micro-USB-like thing that has sufficient technical and political clout behind it that everyone implements it. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
