Re: [OAUTH-WG] subdomain

[Jerry Leyendecker <[e-mail]>]

What would be my subdomain when entering authress.api

On Wed, Feb 24, 2021, 6:21 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 (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" <[e-mail]>
> To: "Warren Parad" <[e-mail]>
> Cc: "Carsten Bormann" <[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="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 <[e-mail]>
> 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
> >>   [e-mail]
> >>
> >>
>
> --
>   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/71b31a28/attachment.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Feb 2021 12:20:56 +0000
> From: Neil Madden <[e-mail]>
> To: Bron Gondwana <[e-mail]>
> Cc: Warren Parad <[e-mail]>, Carsten Bormann <[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 24 Feb 2021, at 11:39, Bron Gondwana <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 148, Issue 80
> **************************************
>