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

["Donald F Coffin" <[e-mail]>]

Justin,

 

We are still working on the requirement document for integrating OAuth 2.0
into the NAESB ESPI standard.  To date, no one who has implemented the
current "Download My Data" or "Connect My Data" features of the ESPI
standard would be affected, since they have not implemented OAuth 2.0.  I
would vote for "B" as I believe it clarifies intention of the field, but am
also satisfied if "A" is the final result.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      [phone]

Email:       [e-mail]

 

From: Justin Richer [mailto:[e-mail]] 
Sent: Monday, May 20, 2013 8:09 AM
To: [e-mail]
Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

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