+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.h...@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
