[OpenID] Doubt about identifier

[sknvn-openid at yahoo.com]

Other options? i.e. merge three OPs into one? How is that going to work for 
existing RPs who have the identifier from two OPs that are going away?
The problem is that for an OP there is no way to migrate the identifier (hey RP, 
here was the old one and here is the new one you should use). Unless that is 
added into the protocol the migration is probably not going to happen. The worse 
part is that each and every RP would have to make a change to support it and I 
am sure for some RPs this may not be trivial.

Thanks

Naveen




________________________________
From: Kleber - Corujito <corujito at gmail.com>
To: John Bradley <ve7jtb at ve7jtb.com>
Cc: openid-general <openid-general at lists.openid.net>
Sent: Thu, February 3, 2011 9:03:02 AM
Subject: Re: [OpenID] Doubt about identifier


Thanks guys

On Thu, Feb 3, 2011 at 2:49 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

You are correct.  The user is using two separate OP.  They return different 
identifiers.
>
>
>The confusion is that all of the OP happen to be controlled by Google.  
>
>
>It is a deployment choice by Google, not a design flaw in the protocol.  They do 
>have other options, though trying to merge the Blogger openID with the Google 
>ones creates other issues.
>
>
>John B.
>
>On 2011-02-03, at 1:39 PM, Kleber - Corujito wrote:
>
>Thanks for the reply.
>>
>>
>>- Let's imagine an individual RP.
>>- user uses a Google button to authenticate (OP identifier)
>>here Google will return an identifier 
>>like https://www.google.com/accounts/o8/id?id=blablablablabla
>>
>>
>>- another day the same user try to authenticate using a URL (not a Google 
>>button) http://google.com/profiles/LOGIN
>>here Google will return an identifier different from the first to the same RP 
>>(return http://google.com/profiles/LOGIN).
>>
>>
>>In this case would return different identifiers for the same user and same RP.
>>Am I wrong?
>>
>>
>>On Thu, Feb 3, 2011 at 12:48 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:
>>
>>On Thu, Feb 3, 2011 at 5:07 AM, Kleber - Corujito <corujito at gmail.com> wrote:
>>>
>>>Hi everyone! I'm new here and I have some doubts.
>>>>
>>>>
>>>>OP returns something that identifiers users uniquely.
>>>>
>>>>
>>>>Must (or should) OP return always the same identifier for an user?
>>>>if not, that is bad to RPs, isn't?
>>>>
>>>Generally yes.  However, "directed identity" allows an OP to always send the 
>>>same claimed identifier to an individual RP, but each individual RP gets a 
>>>unique claimed id for the same user.  Thus each RP sees the same id, but across 
>>>multiple RPs the identifier varies, so that RPs can't correlate user data. 
>>> Google is the only (large) OP that I know of that leverages this capability.
>>>
>>>
>>>
>>>>
>>>>I noticed that I have different ways to use my Google openid and each one may 
>>>>return something different (or RPs are doing something wrong).
>>>>ex:
>>>>1. https://www.google.com/accounts/o8/id (OP identifier)
>>>>2. http://google.com/profiles/LOGIN
>>>>3. http://www.google.com/profiles/1234567890
>>>>4. https://www.google.com/accounts/o8/id?id=blablablablabla
>>>>
>>>>
>>
>>
>>Google has 3 distinct OPs.  Their primary one which uses directed identity, and 
>>accounts for #4 (claimed id) and #1 (OP identifier) on your list.  Then Google 
>>Profiles has an OP that does not use directed identity, which is #2/#3 on your 
>>list (people can choose whether the identifier is your login name or not).  
>>Their third OP isn't on your list -- it's the OpenID 1.1 OP that is behind their 
>>Blogger service.  As the version number implies, it's been long in need of an 
>>update, or a replacement. 
>>
>>
>>-- 
>>Kleber Manoel Infante (Corujito)
>>
_______________________________________________
>>general mailing list
>>general at lists.openid.net
>>http://lists.openid.net/mailman/listinfo/openid-general
>>
>


-- 
Kleber Manoel Infante (Corujito)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20110203/cb0e8884/attachment.html>