Re: Identity providers as first parties

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 provider."****
>
> ** **
>
> Clearly when the user is logging in, there is a meaningful interaction ****
>
> with what was previously a third party widget, thus pr
>
>