Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Hannes Tschofenig <[e-mail]>]

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
>> <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>     <[e-mail]
>>>     <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>