- From: Tamir Israel <tisrael@cippic.ca>
- Date: Thu, 14 Jun 2012 12:15:07 -0400
- To: JC Cannon <jccannon@microsoft.com>
- CC: "ifette@google.com" <ifette@google.com>, "public-tracking@w3.org Group WG" <public-tracking@w3.org>
- Message-ID: <4FDA0E0B.9060005@cippic.ca>
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