realm-based identifier differentiation

[John Bradley]

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, matake at gmail <matake at gmail.com> 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, matake at 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
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> 
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> 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)