- From: Tamir Israel <tisrael@cippic.ca>
- Date: Thu, 14 Jun 2012 22:58:20 -0400
- To: ifette@google.com
- CC: "rob@blaeu.com" <rob@blaeu.com>, JC Cannon <jccannon@microsoft.com>, "public-tracking@w3.org Group WG" <public-tracking@w3.org>
- Message-ID: <4FDAA4CC.20309@cippic.ca>
If I understand the spec, it was just my 'outsourcing' suggestion that raised the silo-ing problem, correct? If it can work through the out-of-band consent stream, we're good, yes? Best, Tamir On 6/14/2012 5:48 PM, 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 >>>
Received on Friday, 15 June 2012 02:58:58 UTC