Hi Justin, Hi John, I believe that provisioning a client with a unique id (which is what a client id/client secret is) allows some form of linkability. While it may be possible to associate the client to a specific user I could very well imagine that the correlation between activities from a user and those from the client (particularly when the client is running on the user's device) is quite possible.
Ciao Hannes On 02/18/2015 06:37 PM, Justin Richer wrote: > 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 >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[email protected] >> <mailto:[email protected]>> wrote: >> >> snip >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty >>> <[email protected] >>> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
