Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

The deployment evidence doesn’t support your position, Phil.  There are over a dozen interoperable implementations already deployed.  Those deployments demonstrate that the spec, as written, is already doing one thing well – enabling clients (as defined by RFC 6749) to register with Authorization Servers, obtaining client_id and optionally client_secret values that enable those clients to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the evidence says that we’ve achieved that.

It’s time to ship it!

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

I, of course, disagree. But that's what we're trying to figure out as a working group, after all.

 -- Justin
On 05/20/2013 12:41 PM, Phil Hunt wrote:
This draft isn't ready for LC.

Phil

On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org<mailto:jricher@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 <jricher@mitre.org<mailto:jricher@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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth