On 9 July 2010 16:03, John Bradley <[email protected]> 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 <[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
