What would be my subdomain when entering authress.api On Wed, Feb 24, 2021, 6:21 AM <[email protected]> wrote:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: We appear to still be litigating OAuth, oops (Bron Gondwana) > 2. Re: We appear to still be litigating OAuth, oops (Neil Madden) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Feb 2021 23:15:15 +1100 > From: "Bron Gondwana" <[email protected]> > To: "Warren Parad" <[email protected]> > Cc: "Carsten Bormann" <[email protected]>, "Phillip Hallam-Baker" > <[email protected]>, "[email protected]" <[email protected]>, > [email protected] > Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > > 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 <[email protected]> > 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 > >> [email protected] > >> > >> > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > [email protected] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/71b31a28/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Feb 2021 12:20:56 +0000 > From: Neil Madden <[email protected]> > To: Bron Gondwana <[email protected]> > Cc: Warren Parad <[email protected]>, Carsten Bormann <[email protected]>, > Phillip Hallam-Baker <[email protected]>, "[email protected]" > <[email protected]>, [email protected] > Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > On 24 Feb 2021, at 11:39, Bron Gondwana <[email protected]> wrote: > > > >> > >> [?] > > > > 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. > > Does the following meet your needs? > > You type your email address into {The Bat} to begin configuration. {The > Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}. > The discovery document reveals that {My ISP} supports open dynamic client > registration [3][4] so {The Bat} registers and gets issued with a client id > and client secret. {The Bat} then does a normal OAuth flow to get an access > token to access your emails from {My ISP}. If you later stop using {The > Bat} you can go to your page on {My ISP} and revoke its access because it > has a unique client id. > > [1]: https://openid.net/specs/openid-connect-discovery-1_0.html < > https://openid.net/specs/openid-connect-discovery-1_0.html> > [2]: https://tools.ietf.org/html/rfc8414 < > https://tools.ietf.org/html/rfc8414> > [3]: https://openid.net/specs/openid-connect-registration-1_0.html < > https://openid.net/specs/openid-connect-registration-1_0.html> > [4]: https://tools.ietf.org/html/rfc7591 < > https://tools.ietf.org/html/rfc7591> > > > > > 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. > > That?s fine for your use-case, but that isn?t everybody?s use-case. Other > use-cases (such as Open Banking) involve regulatory or policy frameworks in > which open dynamic client registration is not appropriate. JMAP could have > an RFC describing the use of OAuth with JMAP that mandates open dynamic > client registration and discovery. > > > ? Neil > > > -- > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/ac3ed3af/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 148, Issue 80 > ************************************** >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
