realm-based identifier differentiation

Ben Laurie benl at google.com
Fri Jul 9 10:57:56 UTC 2010


On 8 July 2010 17:18, Breno de Medeiros <breno at google.com> wrote:
> On Thu, Jul 8, 2010 at 07:50, John Bradley <john.bradley at wingaa.com> 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, matake at 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, 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)
>>>>
>>>
>>
>>
>
>
>
> --
> --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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>


More information about the specs mailing list