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 >> <kathleen.moriarty.i...@gmail.com >> <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
