On 8 July 2010 17:18, Breno de Medeiros <[email protected]> wrote: > On Thu, Jul 8, 2010 at 07:50, John Bradley <[email protected]> wrote: >> The principal point of users electing to use a non-corralatable identifier >> is that they are no-corralatable for privacy reasons. >> >> OP's may have other reasons for using them, but if a user elected to use a >> PPID type identifier having the RP and OP collude behind the users back >> without consent is a privacy violation. >> >> Yes there are ways that a RP could prove it has knowledge of a shared secret >> across sites. >> >> If sites like google and others who may have been perceived to offer this as >> a privacy feature, change their policy, it needs to be well communicated >> and probably opt in. >> >> We know that changing privacy policy arbitrarily has caused PR problems for >> some social networks. >> >> The technical solution will be the easy part. > > Not true. For instance, if the user approves disclosure of the email > address, that's an unmistakable signal that the user is comfortable > with disclosing global identifiers.
Not really, the user: a) might not understand the implications b) have no reasonable alternative (i.e. disclosure of email is non-optional). > > The policy part is tractable. The spec solution is non-existent. > >> >> John B. >> On 2010-07-07, at 9:48 PM, mat...@gmail wrote: >> >>>> The PPID type identifier is intended to prevent correlation of identifiers >>>> between providers. >>>> >>>> There are two sorts of ways that PPID are used. >>>> >>>> 1. The user doesn't want correlation. >>>> 2. The RP is under some requirement not to collect PII or correlatable >>>> information. Perhaps for COPA compliance as an example. >>>> >>>> At least for the first case the user should be asked for permission to do >>>> the mapping. >>> >>> >>> Even if site A could prove it is the same party with site B, should OP ask >>> users to use the same identifier for them? >>> This issue should be solved between RP and OP without confusing users, non? >>> >>> I think OAuth is useful to verify site A and site B is the same. >>> basic idea is >>> - RP send authentication request from site A with its identifier >>> - OP discover site A, do the normal authentication flow and establish user >>> identifier based on the realm >>> - OP also connect the identifier with realm (OAuth signature is useful >>> method to verify RP identifier) >>> - RP send authentication request from site B with its identifier >>> - OP discover site B, do the normal authentication flow >>> - OP also find the RP identifier connected with the realm of site A, and >>> use the same identifier >>> >>>> I suspect that is going to be way more complicated than real people will >>>> want to deal with. >>>> >>>> Probably the best thing is to not use PPID type identifiers unless there >>>> is an actual reason. >>> >>> I agree. >>> >>> -- >>> Nov Matake (=nov) >>> http://matake.jp >>> http://twitter.com/nov >>> >>> On 2010/07/08, at 2:24, John Bradley wrote: >>> >>>> It is a similar problem but not the same one. >>>> >>>> The PPID type identifier is intended to prevent correlation of identifiers >>>> between providers. >>>> >>>> There are two sorts of ways that PPID are used. >>>> >>>> 1. The user doesn't want correlation. >>>> 2. The RP is under some requirement not to collect PII or correlatable >>>> information. Perhaps for COPA compliance as an example. >>>> >>>> At least for the first case the user should be asked for permission to do >>>> the mapping. >>>> >>>> Perhaps a special AX attribute could be defined to return the identifier >>>> based on a different realm that the user could be prompted to confirm >>>> >>>> eg Site A wants to know what your Private identifier for site B is. >>>> >>>> I suspect that is going to be way more complicated than real people will >>>> want to deal with. >>>> >>>> Probably the best thing is to not use PPID type identifiers unless there >>>> is an actual reason. >>>> >>>> John B. >>>> On 2010-07-07, at 12:45 PM, Breno de Medeiros wrote: >>>> >>>>> On Wed, Jul 7, 2010 at 09:12, mat...@gmail <[email protected]> wrote: >>>>>> Hi John, >>>>>> >>>>>>> Using a pairwise identifier based on Realm is not in the spec. >>>>>>>>> There is a PAPE message that can be sent to request one. This is a >>>>>>>>> requirement for some RP that are precluded from correlating across >>>>>>>>> sites as some Government agencies are. >>>>>> >>>>>> I see. >>>>>> >>>>>>> I think Google is the only OP to use them by default for all RP. >>>>>> >>>>>> NTT, biggest telecom company in Japan, is also doing same thing. >>>>>> (and unfortunately they don't support AX or any other method to give >>>>>> verified email address) >>>>>> >>>>>>> You may be able to do a migration based on the Google verified email >>>>>>> address. >>>>>> >>>>>> >>>>>> It's good idea, and seems the only solution for now. >>>>>> Some Google OpenID users don't have gmail address though.. >>>>> >>>>> This is a particular instance of a larger problem, dealing with legacy >>>>> IDs in the same OP. For instance, some providers would like to port >>>>> their existing http URLs to https URLs for security reasons. The spec >>>>> does not support it. >>>>> >>>>> It'd be useful if future versions of OpenID specs provided some >>>>> guidance in this area. >>>>> >>>>> >>>>>> >>>>>>> Using something other than the realm is possible but it needs to >>>>>>> maintain the anti-corralation property. >>>>>> >>>>>> >>>>>> Yes, but this issue will become bigger and bigger. >>>>>> Consider that RP has only PC site (example.com) now, and is opening new >>>>>> mobile site (m.example.com) on different domain, so that they have to >>>>>> use different realm. >>>>>> Of course RP can use wildcard realm for both site, but anyway the realm >>>>>> changes. >>>>>> >>>>>> If I want to discuss this issue in this group, PAPE list is the best >>>>>> place? >>>>>> >>>>>> thanks >>>>>> >>>>>> -- >>>>>> Nov Matake (=nov) >>>>>> http://matake.jp >>>>>> http://twitter.com/nov >>>>>> >>>>>> On 2010/07/08, at 0:11, John Bradley wrote: >>>>>> >>>>>>> Using a pairwise identifier based on Realm is not in the spec. >>>>>>> >>>>>>> There is a PAPE message that can be sent to request one. This is a >>>>>>> requirement for some RP that are precluded from correlating across >>>>>>> sites as some Government agencies are. >>>>>>> >>>>>>> I think Google is the only OP to use them by default for all RP. >>>>>>> >>>>>>> You may be able to do a migration based on the Google verified email >>>>>>> address. >>>>>>> >>>>>>> I don't think there is an easy way to do the migration. >>>>>>> >>>>>>> Using something other than the realm is possible but it needs to >>>>>>> maintain the anti-corralation property. >>>>>>> >>>>>>> John B. >>>>>>> On 2010-07-07, at 3:21 AM, mat...@gmail wrote: >>>>>>> >>>>>>>> Hi experts, >>>>>>>> >>>>>>>> I have an issue related to realm-based identifier differentiation >>>>>>>> which Google is doing. >>>>>>>> >>>>>>>> We are plaining to change our domain (= realm). >>>>>>>> After that, we can't identify the Google OpenID users because their >>>>>>>> OpenID identifier changes. >>>>>>>> >>>>>>>> Do you have any solution for that, or any other places/person I should >>>>>>>> ask? >>>>>>>> >>>>>>>> ps. >>>>>>>> I would like OpenID spec allows using non-realm RP identifier (ie. >>>>>>>> OAuth consumer key?), I'm not sure the realm-base identifier >>>>>>>> differentiation itself is in the spec though. >>>>>>>> >>>>>>>> -- >>>>>>>> Nov Matake (=nov) >>>>>>>> http://matake.jp >>>>>>>> http://twitter.com/nov >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> specs mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> specs mailing list >>>>>> [email protected] >>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --Breno >>>>> >>>>> +1 (650) 214-1007 desk >>>>> +1 (408) 212-0135 (Grand Central) >>>>> MTV-41-3 : 383-A >>>>> PST (GMT-8) / PDT(GMT-7) >>>> >>> >> >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
