For what it's worth, I also agree that (3) is overkill. The other two, I
believe, have more potential value in clarity, and I haven't yet heard
evidence that making this particular syntax change would be either easy
or difficult from other developers. It's possible (though completely
conjectural on my part) that nobody's actually using these informational
fields yet, so changing them now would be relatively painless on the
ground and would make things clearer going forward.
-- Justin
On 05/20/2013 12:52 PM, Mike Jones wrote:
I believe that no syntax changes are necessary.
Of the three possible changes described below, I particularly believe
that (3) is completely unnecessary, as there is nothing that
authenticates to the Token Endpoint other than the client. Thus,
adding “client_” to the name adds no useful semantic content. This
proposed change is especially superfluous.
-- Mike
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Phil Hunt
*Sent:* Monday, May 20, 2013 8:21 AM
*To:* Justin Richer
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
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
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
