W3C home > Mailing lists > Public > public-tracking@w3.org > June 2012

Re: Identity providers as first parties

From: Tamir Israel <tisrael@cippic.ca>
Date: Thu, 14 Jun 2012 12:15:07 -0400
Message-ID: <4FDA0E0B.9060005@cippic.ca>
To: JC Cannon <jccannon@microsoft.com>
CC: "ifette@google.com" <ifette@google.com>, "public-tracking@w3.org Group WG" <public-tracking@w3.org>
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  <mailto:ifette@google.com>
> Cc:public-tracking@w3.org  <mailto: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 promoting it to a
>
>     first party. If all that's being provided is a userid, then the
>
>     interaction is basically over at that point. If more info is being
>
>     provided from the user's account (such as a friend list, a chat
>
>     widget, or whatever), I think one could still assume that the user
>
>     made a meaningful interaction with that party and thus the party is
>
>     still a first party.
>
>       
>
>     -Ian
>
Received on Thursday, 14 June 2012 16:15:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:30 UTC