I’ll incorporate this feedback into another draft, to be posted by the end of the week. Thanks everyone!
— Justin > On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > > > On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > snip >> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty >> <kathleen.moriarty.i...@gmail.com <mailto:kathleen.moriarty.i...@gmail.com>> >> wrote: >> >> > The client_id *could* be short lived, but they usually aren't. I don't see >> > any particular logging or tracking concerns using a dynamic OAuth client >> > above using any other piece of software, ever. As such, I don't think it >> > requires special calling out here. >> >> Help me understand why there should not be text that shows this is not an >> issue or please propose some text. This is bound to come up in IESG reviews >> if not addressed up front. >> > > The client_id is used to communicate to the Authorization server to get a > code or refresh token. Those tokens uniquely identify the user from a > privacy perspective. > It is the access tokens that are sent to the RS and those can and should be > rotated, but the client)id is not sent to the RS in OAuth as part of the > spec. > > If you did rotate the client_id then the AS would track it across rotations, > so it wouldn’t really achieve anything. > > One thing we don’t do is allow the client to specify the client_id, that > could allow correlation of the client across multiple AS and that might be a > privacy issue, but we don’t allow it. > > Thanks, John. It may be helpful to add in this explanation unless there is > some reason not to? > > John B. > > > > > -- > > Best regards, > Kathleen > _______________________________________________ > 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
