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

[Jim Willeke <[e-mail]>]

I didn't mean to imply "you" were writing it off and you are probably right
technology may not be able to solve it, I was just looking for ways we
might help?

--
-jim
Jim Willeke


On Wed, Feb 24, 2021 at 10:21 AM Aaron Parecki <[e-mail]> wrote:

> > 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
>
>