realm-based identifier differentiation

Mon Jul 12 10:03:15 UTC 2010

On 9 July 2010 16:03, John Bradley <john.bradley at wingaa.com> wrote:
> Hi Ben,
>
> Let me restate where Breno and I differ as I see it.
>
> Breno contends that mapping from http: identifiers to https: identifiers is the same as mapping between PPID type identifiers given to different realms.
>
> We agree that the http: to https: mapping can be done publicly and has no privacy implications,  and requires no direct involvement of the user.
>
> Where we differ is that I contend mapping between PPID may have privacy implications that need to be considered, and perhaps taken into account in the technical solution.

Indeed, and I agree with you. Is there any reason to use PPIDs other
than for privacy?

>
> It is true that Google forces the user to disclose there email to any site that requests it otherwise they can't login.
> This greatly reduces or eliminates the value of having a non-corralatable identifier.
>
> Other IdP using PPID may be using it for privacy reasons and may have different constraints on correlation of their users.
> If we are going to extend openID 2.0 we need to consider the needs of all of the OP not just one.
>
> Even at Google there is a significant issue that needs to be considered.
>
> On the face of it you could set up a mapping service that would take any google generated PPID identifier and translate it into the identifier that would be used at a different domain, (possible because the ID is encrypted not hashed as I understand it) however that would violate existing understandings Google has with RP who are counting on the identifiers being non-correlatable.
>
> Part of the US FICAM profile that google is certified under requires that if the RP asks for a PPID identifier the OP must return one even if the identifiers normally used by the OP are correlatable.   (The requirement is based on a federal law that prevents correlation across agencies.)
>
> Because Google elected to use the existing PPID identifiers for this,  you no longer have the option to just make all of them correlatable.
>
> I agree with Breno that both problems need to be addressed,  however I remain to be convinced that there is a simple solution that addresses both use cases adequately.
>
> I am happy to work on this to create a solution for openID 2.0 and/or OIC.
>
> Regards
> John B.
>
> On 2010-07-09, at 6:57 AM, Ben Laurie wrote:
>
>> 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
>>>
>
>