On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> snip > > On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty < > 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
