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

> Il 26/02/2021 17:32 Aaron Parecki ha scritto: > > > Dynamic client registration does exist in OAuth: > https://tools.ietf.org/html/rfc7591 > > The point is that basically nobody uses it because they don't want to > allow arbitrary client registration at their ASs. That's

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

On Thu, Feb 25, 2021, at 19:22, Seán Kelleher wrote: > Just to clarify, I assume in this discourse that the "server" in this client > and server relationship refers to an AS/RS pair in OAuth terminology? Based > on this, one big sticking point for me on the applicability of NxM, or even >

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

On Fri, Feb 26, 2021 at 11:32 AM Tim Bray wrote: > > > On Fri, Feb 26, 2021 at 8:10 AM Justin Richer wrote: > >> Right, it’s possible to patch OAuth to do this, but the whole >> “registration equals trust” mindset is baked into OAuth at a really core >> level. That’s one of the main reasons

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

> Do you disagree that this gives them control over which things talk to their servers? Yes -- with a public client, I can impersonate a "real" app and it's basically non-detectable by the AS. For a theoretical example, if I wanted to use the Instagram API but they restrict which apps can upload

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

> On Feb 26, 2021, at 9:32 AM, Aaron Parecki wrote: > The point is that basically nobody uses it because they don't want to allow > arbitrary client registration at their ASs. That's likely due to a > combination of pre-registration being the default model in OAuth for so long > (the

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

On 2/26/2021 8:31 AM, Tim Bray wrote: On Fri, Feb 26, 2021 at 8:10 AM Justin Richer > wrote: Right, it’s possible to patch OAuth to do this, but the whole “registration equals trust” mindset is baked into OAuth at a really core level. That’s one of the main

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

Dynamic client registration does exist in OAuth: https://tools.ietf.org/html/rfc7591 The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for

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

On Fri, Feb 26, 2021 at 8:10 AM Justin Richer wrote: > Right, it’s possible to patch OAuth to do this, but the whole > “registration equals trust” mindset is baked into OAuth at a really core > level. That’s one of the main reasons there’s been hesitance at deploying > dynamic registration. It’s

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

A) I don't think it is helpful to talk about what other WGs are doing, or how GNAP attempts to fix or not fix these problems. B) Sharing statements like this: > Right, it’s possible to patch OAuth to do this, but the whole > “registration equals trust” mindset is baked into OAuth at a really core

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

Right, it’s possible to patch OAuth to do this, but the whole “registration equals trust” mindset is baked into OAuth at a really core level. That’s one of the main reasons there’s been hesitance at deploying dynamic registration. It’s an extension that changes your trust model’s assumptions,

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

> On Feb 25, 2021, at 2:59 PM, Evert Pot wrote: > On 2021-02-25 3:41 a.m., Seán Kelleher wrote: >> Yep, this is the big point - OAuth is designed to require the the third leg >> of trust that creates the NxM problem. >> >> I believe the snippet of Justin's that you quoted actually shows you how

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

On 2021-02-25 3:41 a.m., Seán Kelleher wrote: Yep, this is the big point - OAuth is designed to require the the third leg of trust that creates the NxM problem. I believe the snippet of Justin's that you quoted actually shows you how you can forgo the trust element using dynamic

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

On 2021-02-25 3:22 a.m., Seán Kelleher wrote: Just to clarify, I assume in this discourse that the "server" in this client and server relationship refers to an AS/RS pair in OAuth terminology? Based on this, one big sticking point for me on the applicability of NxM, or even 1xM, is that all

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

Sent: Wednesday, February 24, 2021 3:30:33 PM To: Justin Richer Cc: Phillip Hallam-Baker ; oauth@ietf.org ; i...@ietf.org Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote: I agree that the NxM problem is the purview of the whol

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

> > Yep, this is the big point - OAuth is designed to require the the third > leg of trust that creates the NxM problem. I believe the snippet of Justin's that you quoted actually shows you how you can forgo the trust element using dynamic client registration. It still allows a "server" to

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

Just to clarify, I assume in this discourse that the "server" in this client and server relationship refers to an AS/RS pair in OAuth terminology? Based on this, one big sticking point for me on the applicability of NxM, or even 1xM, is that all of the "M" RSs need to publish the same interface

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

On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote: > I agree that the NxM problem is the purview of the whole IETF, but it’s > something that we’re particularly interested in over in GNAP. As the editor > of OAuth’s dynamic registration extension and the GNAP core protocol, I hope > I can add

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

One thing that this thread is overlooking (Hannes and others have mentioned it) is that OAuth is an *authorization* protocol not intended for authentication. OAuth is not really for federation and sharing of claims. The idea is for an authz server to issue short term tokens that contain

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

Justin Richer wrote: > From a technical standpoint, OAuth’s dynamic client registration lets > arbitrary clients talk to an AS, but the trust isn’t there in > practice. As an example of a fail even in a closed ecosystem: neither Google nor Facebook nor LinkedIn nor .. permit one to

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

I'll add just one more thing here, even if the protocol exists, the clarity, and was supported, I'm not sure that it would even be that widely used. Thinking about this from the user perspective, I just can't imagine how many would really choose to even need or want to set up these other

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

The OAuth work has successfully built a perfectly reasonable syntax and protocol for exchanging identity and attribute assertions, and that's fine. What it hasn't done is opened up the world of Identity Provision, but that's not a technical problem. OAuth flowed out of OpenID back in the day.

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

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 wrote: > > Sure, you could write it off as "a business problem" but

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

> 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

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

I agree that the NxM problem is the purview of the whole IETF, but it’s something that we’re particularly interested in over in GNAP. As the editor of OAuth’s dynamic registration extension and the GNAP core protocol, I hope I can add to this conversation. From a technical standpoint, OAuth’s

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

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

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

> 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

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

On 24 Feb 2021, at 11:39, Bron Gondwana 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 >

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

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

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

(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

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

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

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

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

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

On 2021-02-24, at 11:22, Warren Parad wrote: > > Should we solve the NxM problem, and if so, how do you propose we do that? Let GNAP do that. Grüße, Carsten ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

Should we solve the NxM problem, and if so, how do you propose we do that? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed, Feb 24, 2021 at 8:08 AM Bron Gondwana wrote: > On Wed, Feb 24, 2021, at 17:26,

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

On Wed, Feb 24, 2021, at 17:26, Jim Manico wrote: > I think it’s important to point out that OAuth is not an authentication > protocol. It’s for delegation. OAuth is one of the most mis-used protocols on > the modern web. If you really want to support end users, a good place to > start is to