On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote: > (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?*
Honestly I think the problem space is the whole ietf's responsibility. Protocols that allow an end user to safely transfer data between two parties that don't have a pre-existing trust relationship are a key part of enabling user freedom and user choice. Bron. > > *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 >> >> -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
