Thank you, I just reviewed the diff and the changes to the draft look good.
Best regards, Kathleen On Wed, Feb 25, 2015 at 11:23 AM, Justin Richer <[email protected]> wrote: > John’s assessment is correct and this is what we’ve tried to capture in > the privacy considerations section of the latest draft: > > In general, the metadata for a client, such as the client name and > software identifier, are common across all instances of a piece of > client software and therefore pose no privacy issues for end-users. > Client identifiers, on the other hand, are often unique to a specific > instance of a client. For clients such as web sites that are used by > many users, there may not be significant privacy concerns regarding > the client identifier, but for clients such as native applications > that are installed on a single end-user's device, the client > identifier could be uniquely tracked during OAuth 2.0 transactions > and its use tied to that single end-user. However, as the client > software still needs to be authorized by a resource owner through an > OAuth 2.0 authorization grant, this type of tracking can occur > whether or not the client identifier is unique by correlating the > authenticated resource owner with the requesting client identifier. > > Note that clients are forbidden by this specification from creating > their own client identifier. If the client were able to do so, an > individual client instance could be tracked across multiple colluding > authorization servers, leading to privacy and security issues. > Additionally, client identifiers are generally issued uniquely per > registration request, even for the same instance of software. In > this way, an application could marginally improve privacy by > registering multiple times and appearing to be completely separate > applications. However, this technique does incur significant > usability cost in the form of requiring multiple authorizations per > resource owner and is therefore unlikely to be used in practice. > > > Hopefully this is more clear now. > > Thanks for the feedback and close review, > — Justin > > > On Feb 24, 2015, at 8:55 PM, John Bradley <[email protected]> wrote: > > > > Yes but it is authenticating the client to the AS as part of the > resource owners consent. > > > > Ther eis a one to one mapping of resource owner to client in that case. > > > > The client ID is no more identifying than the refresh token that maps to > the RO by design. > > > > Yes the grant identifies the RO in some way. The client_id and secret > prevent that from being used in a different client if the bearer token > leaks. > > > > Remember the client_id is going to be different at different AS as each > will have a separate registration. > > If the client_id was fixed across multiple AS then it would be a > correlation issue, but that is not the case. > > > > Perhaps I am not understanding the concern? > > > > John B. > > > >> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig < > [email protected]> wrote: > >> > >> 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 > >>> > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
