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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <
> [e-mail]> 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
> >>>> <[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
> >>>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
>


-- 

Best regards,
Kathleen