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. John B.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
