Let's make a new thread for this. It is worth some discussion. We have some strong cases for this, and I do think dyn reg involves some credential management issues that SCIM doesn't yet handle.
I think Justin is planning to make these aspects more clear in the draft. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-05-22, at 11:39 AM, 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
