Re: [OAUTH-WG] OAuth Digest, Vol 148, Issue 78

[Jerry Leyendecker <[e-mail]>]

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 <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 <[e-mail]>
> To: Warren Parad <wparad=[e-mail]>
> Cc: Bron Gondwana <[e-mail]>, Phillip Hallam-Baker
>         <[e-mail]>, "[e-mail]" <[e-mail]>,
>         [e-mail]
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID: <[e-mail]>
> Content-Type: text/plain;       charset=utf-8
>
> On 2021-02-24, at 11:22, Warren Parad <wparad=[e-mail]>
> 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 <[e-mail]>
> To: [e-mail]
> Subject: [OAUTH-WG] Send me the autherized paperwork
> Message-ID:
>         <CABv2g9z5TL-6z=
> [e-mail]>
> 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 <[e-mail]>
> To: Carsten Bormann <[e-mail]>
> Cc: Bron Gondwana <[e-mail]>, Phillip Hallam-Baker
>         <[e-mail]>,  "[e-mail]" <[e-mail]>,
>         [e-mail]
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID:
>         <
> [e-mail]>
> 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 <[e-mail]> wrote:
>
> > On 2021-02-24, at 11:22, Warren Parad <wparad=[e-mail]
> >
> > 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" <[e-mail]>
> To: "Warren Parad" <[e-mail]>, "Carsten Bormann"
>         <[e-mail]>
> Cc: "Phillip Hallam-Baker" <[e-mail]>, "[e-mail]"
>         <[e-mail]>, [e-mail]
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID: <[e-mail]>
> 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
>   [e-mail]
>
> -------------- 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 148, Issue 78
> **************************************
>