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 <aa...@parecki.com> 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 <j...@willeke.com> 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 <aa...@parecki.com> 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 <neil.mad...@forgerock.com> >>> wrote: >>> >>>> On 24 Feb 2021, at 11:39, Bron Gondwana <br...@fastmailteam.com> 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 >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> -- >>> --- >>> Aaron Parecki >>> https://aaronparecki.com >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > --- > Aaron Parecki > https://aaronparecki.com > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
