My Name is Jerry L Leyendecker. could you please explain to me how, why, and what am I suppose to be doing as litigating OAuth please. That would be great.
On Wed, Feb 24, 2021, 5:41 AM <oauth-requ...@ietf.org> wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > 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 > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > 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 (Carsten Bormann) > 2. Send me the autherized paperwork (Jerry Leyendecker) > 3. Re: We appear to still be litigating OAuth, oops (Warren Parad) > 4. Re: We appear to still be litigating OAuth, oops (Bron Gondwana) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Feb 2021 11:36:13 +0100 > From: Carsten Bormann <c...@tzi.org> > To: Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > Cc: Bron Gondwana <br...@fastmailteam.com>, Phillip Hallam-Baker > <ph...@hallambaker.com>, "oauth@ietf.org" <oauth@ietf.org>, > i...@ietf.org > Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops > Message-ID: <dab127d7-809f-4ec2-a043-9b15e2db8...@tzi.org> > Content-Type: text/plain; charset=utf-8 > > On 2021-02-24, at 11:22, Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > wrote: > > > > Should we solve the NxM problem, and if so, how do you propose we do > that? > > Let GNAP do that. > > Gr??e, Carsten > > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Feb 2021 04:41:40 -0600 > From: Jerry Leyendecker <jleyendecker...@gmail.com> > To: oauth@ietf.org > Subject: [OAUTH-WG] Send me the autherized paperwork > Message-ID: > <CABv2g9z5TL-6z= > 64b6sjzoda8kj0tnzkfawb5_jdu5sbhuz...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Approved > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/6c850fa3/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Feb 2021 12:04:40 +0100 > From: Warren Parad <wpa...@rhosys.ch> > To: Carsten Bormann <c...@tzi.org> > Cc: Bron Gondwana <br...@fastmailteam.com>, Phillip Hallam-Baker > <ph...@hallambaker.com>, "oauth@ietf.org" <oauth@ietf.org>, > i...@ietf.org > Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops > Message-ID: > < > cajot-l1e8gegjxjadrq87tgqnsreoo4beklx+kpkzfsqpev...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I would prefer Bron to answer that question, as they are the one who > started this email thread. > > 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. > > 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. > > Would you agree with that statement? > > 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 11:36 AM Carsten Bormann <c...@tzi.org> wrote: > > > On 2021-02-24, at 11:22, Warren Parad <wparad=40rhosys...@dmarc.ietf.org > > > > wrote: > > > > > > Should we solve the NxM problem, and if so, how do you propose we do > > that? > > > > Let GNAP do that. > > > > Gr??e, Carsten > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/dbb69cff/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Wed, 24 Feb 2021 22:39:11 +1100 > From: "Bron Gondwana" <br...@fastmailteam.com> > To: "Warren Parad" <wpa...@rhosys.ch>, "Carsten Bormann" > <c...@tzi.org> > Cc: "Phillip Hallam-Baker" <ph...@hallambaker.com>, "oauth@ietf.org" > <oauth@ietf.org>, i...@ietf.org > Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops > Message-ID: <66be0ffe-a638-45a0-ba05-1585ea02e...@www.fastmail.com> > Content-Type: text/plain; charset="us-ascii" > > 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 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/c559b617/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 148, Issue 78 > ************************************** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
