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

As an implementor like Justin, I see no problem with changing "expires_at" and "issued_at" to the values proposed below.
It's a minor code change and I don't have a large deployment to deal with.

I also agree with Justin and Phil about "token_endpoint_auth_method".

22 maj 2013 kl. 20:34 skrev Phil Hunt <phil.hunt@oracle.com>:

> +1
> 
> I also agree with Justin's comment on token_endpoint_auth_method. Never-the-less, I did want to pass along the feedback that some were confused.
> 
> The expires_at, issued_at thing though is particularly confusing (though the text may be clear) and is a higher priority issue in my opinion.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> 
> 
> 
> 
> 
> On 2013-05-22, at 11:19 AM, Justin Richer wrote:
> 
>> 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
>>> 
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> 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

-- Roland
"Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain