I'm neutral with changing (1) and (2) because they're not highly breaking
changes. These are optional parameters and code already has to be prepared to
not receive them and to ignore not understood parameters. If the change is
made, the result would be that existing implementations wouldn't receive
issuance and expiration times that they understand until they change their
code. That being said, the documentation for these parameters is already
clear, so I don't think that much confusion is likely to arise if we change
nothing.
I am very strongly against changing (3) because this is truly a gratuitous and
fully breaking change. There's only thing that authenticates to token
endpoints - clients - and so adding "client_" to the name adds no semantic or
disambiguating value.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of
Justin Richer
Sent: Wednesday, May 22, 2013 11:20 AM
To: [email protected]
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
Speaking as an implementor, I'm actually in favor of changing "expires_at" and
"issued_at" to the values proposed below. It would require some minor code
changes on my end, but the impact would be minimal, and I think that the new
names are *much* more clear to new developers. I think it will save us a lot of
questions and headaches going forward. I believe that changing it now will have
minimal impact on any deployed and running code (there are no large-scale
services that I am aware of), and it will make things clearer. So I vote for
"B" for #1 and #2.
I believe "token_endpoint_auth_method" is sufficient as is, since the client is
the only thing that authenticates to the token endpoint.
[[ Note: As an editor, I don't believe it's really in my power to make that
change unless there's support in the working group for making it. I really want
more feedback from people, with explanation if you can. ]]
-- Justin
On 05/20/2013 11:09 AM, Justin Richer 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
