> 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) > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
