Re: Identity providers as first parties

I am not proclaiming data silo-ing. Normative text addressing the fact 
that data must only be used for the purpose intended is useful in my 
opinion. Purpose limitation doesn't necessarily imply technical 
safeguards. If a party claims to be compliant with DNT, such normative 
text can put limits. The carve out you might be looking for is 
legitimate business interests, under which I see security, in this 
specific context. So I think it can fly with tailwind:

Identity providers must not use user data beyond the purpose of 
identification and authentication unless this user data is needed for a 
legitimate business interest like for example fraudulent login attempts 
across multiple third party sites.


On 14-6-2012 23:48, Ian Fette (イアンフェッティ) wrote:
> Define "help" :-)
>
> I can tell you that as an identity provider, there is no way I would 
> silo this data as that would cause huge problems, e.g. I detect 
> someone trying to compromise your account via one access mechanism and 
> there's nothing I can do because it's siloed off? Or I can't rate 
> limit authentication attempts because each third party is separate? 
> Not going to fly.
>
> In other words, define what you mean by "those extra things."
>
> On Thursday, June 14, 2012, Rob van Eijk wrote:
>
>     identification and authentication is far from our starting point,
>     however an interesting use case.
>     If identity providers are in the business of using the knowledge
>     for different purposes then what the user intended (ie logging
>     into a service), then for those extra things, the identity
>     providers should be submitted to the DNT preference signal. Would
>     that help?
>
>     Rob
>
>
>     On 14-6-2012 19:46, Ian Fette (イアンフェッティ) wrote:
>>     I think this would probably be ok. I want to be clear though that
>>     I would not expect data siloing here. E.g. We are going to watch
>>     for fraudulent login attempts across multiple third party sites
>>     yada yada yada.
>>
>>     On Thursday, June 14, 2012, Tamir Israel wrote:
>>
>>         Would this be workable?
>>
>>         Treat the IdP as first party for the authentication process
>>         itself on the basis of substantial interaction, but leave
>>         significant downstream personalization to out-of-band consent
>>         (I think this can be acquired as part of the authentication
>>         process in those cases where it is envisions a need to do so).
>>
>>         On 6/14/2012 11:36 AM, JC Cannon wrote:
>>>
>>>         No, that’s a different scenario. The identity provider is
>>>         supplying the first-party site information on behalf of the
>>>         user to simplify transfer of data.
>>>
>>>         JC
>>>
>>>         *From:*Tamir Israel [mailto:tisrael@cippic.ca]
>>>         *Sent:* Thursday, June 14, 2012 6:35 AM
>>>         *To:* JC Cannon
>>>         *Cc:* ifette@google.com; public-tracking@w3.org Group WG
>>>         *Subject:* Re: Identity providers as first parties
>>>
>>>         Ok.
>>>
>>>         Could/should some of this fall under Jonathan's outsourcing
>>>         scenario?
>>>
>>>         /3.3.2.3 Outsourcing
>>>         A first party MAY outsource website functionality to a third
>>>         party, in which case the third party may act as the first
>>>         party under this standard with the following additional
>>>         restrictions./
>>>
>>>         With accompanying conditions?
>>>
>>>
>>>         On 6/13/2012 10:29 AM, JC Cannon wrote:
>>>
>>>         There may be cases where the identity provider supplies ongoing profile or configuration information on behalf of the user.
>>>           
>>>         JC
>>>           
>>>         -----Original Message-----
>>>         From: Tamir Israel [mailto:tisrael@cippic.ca]
>>>         Sent: Wednesday, June 13, 2012 7:25 AM
>>>         To:ifette@google.com
>>>         Cc:public-tracking@w3.org  Group WG
>>>         Subject: Re: Identity providers as first parties
>>>           
>>>         Hi Ian,
>>>           
>>>         I'm not certain this is as clear as you imply. The entire concept of a federated identity system, for example, is to segregate the identity provider from any processing tasks beyond identity authentication. I would not expect an OpenID identity provider, for example, to suddenly become a 1st party simply because I used it to sign in). The role of that provider should be completed once my identity has been authenticated.
>>>           
>>>         Best,
>>>         Tamir
>>>           
>>>         On 6/13/2012 10:13 AM, Ian Fette (イアンフェッティ) wrote:
>>>
>>>             This email is intended to satisfy ACTION-187 and ISSUE-99
>>>
>>>               
>>>
>>>             I propose adding to the compliance spec the following:
>>>
>>>               
>>>
>>>             "If a site offers users the choice to log in with an identity
>>>
>>>             provider, via means such as OpenID, OAuth, or other conceptually
>>>
>>>             similar mechanisms, the identity provider is considered a first party
>>>
>>>             for the current transactions and subsequent transactions for which the
>>>
>>>             user remains authenticated to the site via the identity
>>>