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.h...@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.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 -- Roland "Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
