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. 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 <[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
