[OAUTH-WG] Dyn Reg API Style: Was Re: Proposed Syntax Changes in Dynamic Registration

[Phil Hunt <[e-mail]>]

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
[e-mail]





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:[e-mail]] 
> Sent: Monday, May 20, 2013 11:10 AM
> To: Anthony Nadalin
> Cc: Phil Hunt; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Phil Hunt
> Sent: Monday, May 20, 2013 9:42 AM
> To: Justin Richer
> Cc: [e-mail]
> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>