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

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 14:19:57 -0400

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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Wed, 22 May 2013 18:30:05 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 11:20 AM
To: [email-masked]
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.

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:

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-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 May 2013 11:34:32 -0700

+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
[email-masked]

---

From: Roland Hedberg <[email-masked]>
Date: Thu, 23 May 2013 16:27:57 +0200

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".

>>> 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 defaul…

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

---

From: Edmund Jay <[email-masked]>
Date: Thu, 23 May 2013 07:48:47 -0700 (PDT)

I'm OK with changing expires_at and issued_at while keeping 
token_endpoint_auth_method the same.

________________________________
From: Roland Hedberg <[email-masked]>
To: Phil Hunt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Thu, May 23, 2013 7:28:22 AM
Subject: 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.

22 maj 2013 kl. 20:34 skrev Phil Hunt <[email-masked]>:

> +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
> [email-masked]
> 
> 
> 
> 
> 
>> 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
>> 
>> 
>>> 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. 
>>>
>>> 
>>> 
>>> 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:
>>> 
>>> 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
>>> 
>>> 

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

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 23 May 2013 17:23:35 +0000

For what it's worth, I am in favor of making the changes to (1) and (2) and leaving (3) unchanged.  (1) and (2) are definitely confusing to me, as I would normally have associated the issued and expiration times to the token.  (3) is obvious as it stands, and as other have mentioned, only clients authenticate to the endpoints, so adding client to the term doesn't add much value.

As mentioned, changing (1) and (2), it is not a difficult change, and anybody implementing to drafts will obviously understand that things change before getting RFC status.  Best to fix things now, that's what the last call is for after all.

-adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 1:20 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 -- Justin

Naming things is hard.

 -- Justin

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Thu, 23 May 2013 14:21:05 -0400

Thanks Adam (and others) for voicing your opinions on this. The OIDC 
working group has also been discussing this (since it would impact the 
registration draft there as well) and several of the members there have 
either changed to voicing support for the change or claiming ambivalence 
to it.

As such, I am now seeing reasonable support for changing (1) and (2) to 
the proposed new names in the next draft, and leaving (3) as is. I will 
do so unless I hear strong objections.

  -- Justin

On 05/23/2013 01:23 PM, Lewis Adam-CAL022 wrote:
>
> For what it's worth, I am in favor of making the changes to (1) and 
> (2) and leaving (3) unchanged.  (1) and (2) are definitely confusing 
> to me, as I would normally have associated the issued and expiration 
> times to the token. (3) is obvious as it stands, and as other have 
> mentioned, only clients authenticate to the endpoints, so adding 
> client to the term doesn't add much value.
>
> As mentioned, changing (1) and (2), it is not a difficult change, and 
> anybody implementing to drafts will obviously understand that things 
> change before getting RFC status. Best to fix things now, that's what 
> the last call is for after all.
>
> -adam
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Richer
> *Sent:* Wednesday, May 22, 2013 1:20 PM
> *To:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>
> 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.
>
> *[[ 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
>
>     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.
>
>
>     *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
>
>
>
>     [email-masked]  <mailto:[email-masked]>
>