Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Aaron Parecki <[e-mail]>]

> Sure, you could write it off as "a business problem" but

I did not mean to suggest that I was *writing it off* as a business
problem.

It *is* a very real problem, and I would very much like to see a solution,
however based on my experience it is not something that technology will
solve. This is demonstrated by the fact that there are all the pieces in
place already yet many organizations refuse to adopt them, and it’s
definitely not for a lack of understanding.

Aaron



On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke <[e-mail]> wrote:

> But in reality, Just "because the technology" is there there leaves out
> the practicality of creating a secure implementation. Sure, you could write
> it off as "a business problem" but many of the developers are small and not
> unusually single person operations that do not have the resources to create
> a specific team, or even a specific person, to work through all the
> specifications that are involved.
>
> I do believe, in general, specific implementations should not be within
> the specifications but a "Best Practices" or "Common Implementations"
> document to coincide with the specifications might be in order.
>
> Just spend some time on https://stackexchange.com/filters/4229/oauth and
> you will see the issue and struggles.
>
>
> --
> -jim
>
> Jim Willeke
>
>
> On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki <[e-mail]> wrote:
>
>> > 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.
>>
>> Like Neil says, the building blocks are all already there. The fact that
>> companies choose not to use them is not because the technology isn't there,
>> it's because it's a business problem.
>>
>> I'd be thrilled if the NxM problem were solved in practice, but
>> unfortunately that doesn't seem to be what's happened in the market. The
>> technical solution has been there a long time, so there's something else
>> going on.
>>
>> When I've brought up this topic in the past, most of the responses I've
>> gotten from the "big players" are along the lines of "lol we're not going
>> to let someone's software talk to us unless we have a legal arrangement
>> with the developer". The fact that dynamic client registration is barely
>> used is more because these service operators want the software developers
>> to agree to their terms of service before being able to access APIs.
>>
>> This is all to say that I agree it'd be nice to solve this problem, but
>> in the end, the IETF can't tell companies what to do with their products
>> and services.
>>
>> Aaron
>>
>>
>>
>>
>> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden <[e-mail]>
>> wrote:
>>
>>> 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
>>> [2]: https://tools.ietf.org/html/rfc8414
>>> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
>>> [4]: 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>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com