I'm having trouble understanding > We already have OAuth doing dynamic registration, I don’t think there is a > need to force it into OAuth. >
I would be open to a scim dyn reg version. Particularly to discuss instance metadata mgt which scim is good at and the credential managemenr/bootstrap process as it pertains to oauth. Never-the-less the overwhelming priority has been apparently to simply standardize oidc and uma implementations as is. This I am not comfortable with but i can live with if there is give and take. I feel the subject is well in charter and is an important issue due to the life-cycle management issues behind clients and the need to make public clients the security equiv. of confidential clients. Phil On 2013-05-22, at 14:22, Anthony Nadalin <tony...@microsoft.com> wrote: > I totally disagree with your characterization of SCIM, while it can be used > from server to server (provision one system to another) it can also be client > to endpoint (initial provisioning and JIT provisioning). SCIM is fairly > simple (but can be complex), I also have concerns about SCIM not being 100% > restful but that does not stop us from using it. I also agree that we should > let OAuth do what it’s good at and don’t try to force it into something that > it’s not. We already have OAuth doing dynamic registration, I don’t think > there is a need to force it into OAuth. > > > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Wednesday, May 22, 2013 1:35 PM > To: Anthony Nadalin > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > I'm not sure why you don't think it's in scope, it's in the working group's > charter: > > http://www.ietf.org/dyn/wg/charter/oauth-charter.html > > So ... it's definitely in scope, and has been for over a year and a half. > This is the tenth version of this document-- an IETF Working Group document > at that-- that's been posted to the group with every revision and there has > been significant conversation around it, especially over the last six months > since I took over the editor role. There are also a handful of > implementations of this, and while most of them are built to do OpenID > Connect or UMA (which are directly built on OAuth), I know there are some > that also do plain OAuth. (Not the least of which is one that I have > personally implemented and deployed.) > > SCIM doesn't solve client management particularly well, since it's made for > users more than anything. The usage model of SCIM is also quite different -- > it's really intended to be used between two servers to transfer information, > as opposed to handling self-asserted claims. I understand that some > implementations like UAA have done their static registration using a SCIM > profile, but it's not dynamic registration, really. I think it's too much of > a square-peg-round-hole problem, at least with SCIM as it is today; so let > SCIM do what it's good at, and don't try to force it into something it's not. > > Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic > Registration was meant to be a fairly simple REST/JSON API that would be easy > to implement, especially for clients. Just because SCIM is RESTful doesn't > mean it's a good structure for other RESTful APIs. Namely, I don't think the > extra structure and hooks with SCIM really buy you anything here, especially > with the additions and changes you'd have to make to SCIM. > > And finally, nobody to date has actually written a proposal that is even > remotely SCIM based. > > -- Justin > > On 05/22/2013 02:39 PM, Anthony Nadalin wrote: > So, I really don’t understand why dynamic registration is in scope, I > understand this relative to OpenID Connect but not OAuth, if this is indeed > in scope then I would have expected that the endpoint be based upon SCIM and > not something else like what has been done here. > > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Monday, May 20, 2013 11:10 AM > To: Anthony Nadalin > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > Tony, can you be more specific? What needs to be changed in your opinion? > What text changes would you suggest? > > -- Justin > > On 05/20/2013 02:09 PM, Anthony Nadalin wrote: > Agree > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Phil Hunt > Sent: Monday, May 20, 2013 9:42 AM > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > This draft isn't ready for LC. > > Phil > > On 2013-05-20, at 8:49, Justin Richer <jric...@mitre.org> wrote: > > But also keep in mind that this is last-call, and that we don't really want > to encourage avoidable drastic changes at this stage. > > -- Justin > > > > > On 05/20/2013 11:21 AM, Phil Hunt wrote: > Keep in mind there may be other changes coming. > > The issue is that new developers can't figure out what token is being > referred to. > > Phil > > On 2013-05-20, at 8:09, Justin Richer <jric...@mitre.org> wrote: > > Phil Hunt's review of the Dynamic Registration specification has raised a > couple of issues that I felt were getting buried by the larger discussion > (which I still strongly encourage others to jump in to). Namely, Phil has > suggested a couple of syntax changes to the names of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method > > > I'd like to get a feeling, especially from developers who have deployed this > draft spec, what we ought to do for each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to the parameter *definitions* so > that it's more clear to people reading the spec what each piece does. > Speaking as the editor: "A" is the default as far as I'm concerned, since we > shouldn't change syntax without very good reason to do so. That said, if it's > going to be better for developers with the new parameter names, I am open to > fixing them now. > > Naming things is hard. > > -- Justin > _______________________________________________ > 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
