(I tend to trend lightly in the pronoun area, mostly because I'm shocked that openid included gender but not pronouns)
I hadn't heard that to be called the NxM problem, so that definitely cleared up the potential confusion (at least for me). I think GNAPs lack of clarity is a non sequitur for the handling or not of the multitrust arbitrary-client with arbitrary-service, however it's lack of clarity for me prevents me from knowing whether GNAP actually seeks to solve this problem. So from an OAuth WG perspective we can still ask: *Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?* Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <br...@fastmailteam.com> wrote: > On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote: > > I would prefer Bron to answer that question, as they are the one who > started this email thread. > > > You can also use he when talking about me, or she for that matter - I do > enough group fitness classes where it's roughly assumed that the entire > class is female, and I have an ambiguous enough name that I'm used to it. > Most people use "he" most of the time. > > However let's look at GNAP, I've honestly been struggling to understand at > least one fully documented case that GNAP supports. It seems in every > document the only thing that is clear is GNAP wants to allow "everything", > doesn't actually talk about an example. > > > That's my biggest fear for GNAP - it too will try to be everything to > everybody and wind up being nothing to nobody because the super flexible > "everything protocol" is the same as no protocol at all, since you have to > special-case everybody you talk to anyway. > > By NxM, I assume we mean that the end user or client is free to select > whichever AS they want, in a way which the RS can verify the AS credential > and the user identity, without the RS having to (and really without the > ability to limit) which AS are allowed. > > > Let's get down to use cases then, rather than talking in abstracts. > > I'm an end user with a copy of {The Bat email client} and I want to > connect it to {Gmail} + {Yahoo} + {My ISP}. It supports {POP3}, a widely > popular open standard. I want to be able to authenticate to each of those > services without saving my plaintext passwords on my hard disk where the > next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and > all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, > leaving me destitute. > > But, {The Bat} doesn't have a trusted client cert from my isp, because who > does - so there's no good protocol for me - it's either plaintext auth, or > it's some architecture astronaut multi-party nonsense that's massively over > specified and doesn't work half the time. So I write a plain text password > on a post-it note which is lying in the dust under my monitor because the > glue has gone bad, and I hope I never accidentally click "remember me" when > I type it in. > > That's been the reality of the end user experience for very many years. > > NxM means that you can authenticate an arbitrary client against an > arbitrary server so long as they are both speaking a known public protocol, > without needing to build a trust relationship between the client vendor and > the server vendor first. > > Any "trust relationship" is made through a user both who trusts the client > and trusts the server, and it's not transitive over to other users of the > same client and the same server. The client author doesn't need to get a > signed "I trust you" from every single server, and the server author > doesn't have to go identify every single client. > > That's what NxM means to a user, the ability to use arbitrary clients with > arbitrary servers so long as they both implement a documented protocol. > Interoperability. > > OAuth has not given interoperability in the NxM sense outside some simple > web use cases. They're nice and all, but they don't tend to be useful with > open protocols - OAuth gets used for accessing proprietary API endpoints > after getting an access key for a single provider. At least you get Nx1 or > 1xM out of it depending who's the N and who's the M, and maybe some of your > code can rhyme so you're not doing everything from scratch each time. > > This is the sorry story of real open protocols. The floor for true > interoperability is still username + password over cleartext, over > hopefully a TLS tunnel that's providing some level of protection. Most so > than a few years ago when Fastmail wrote our "starttls considered > harmful"[1] objection to the IETF's habit at the time of putting a > "STARTTLS" upgrade into an initially plaintext protocol, where an active > intercepter could just strip the "I support STARTTLS" indicator from the > protocol and convince the client to send the credentials in the clear. > > We're a little better mostly these days, but it's still a tirefire, and in > my heart I do hold the OAuth working group's squatting on this area of the > landscape while failing to address this burning need partially > responsible. The result (as Phillip pointed out upthread) has been a > consolidation towards a few big players - because NxM becomes tractable > when you reduce the N and M to small enough numbers. > > Bron. > > [1] > https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > br...@fastmailteam.com > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
