[Openid-specs-ab] Identifiers and discovery.

Wed Apr 13 14:11:25 UTC 2011

We decided early on that identifier portability was out of scope.

We want to have a easy way for people to migrate between providers. 

From my time in the phone industry number portability is a nightmare.  
It requires central registries to do the indirection.   Relying on IdP to do the forwarding requires the cooperation of the donor IdP, and increases complexity.

So I don't think that is part of Mike's proposal.

I think it comes down to the argument that the canonical ID should be anonymously discoverable like it was in openID 2, or if having multiple reasonable identifiers for public discovery is sufficient,  and make the IsP unique ID just that (more like SAML)

With pseudonymous or possibly ephemeral ID there may be a big advantage to not trying to make those anonymously discoverable.  

John B.
On 2011-04-13, at 8:18 AM, Kick Willemse wrote:

> I like the separation of the identifiers in the different categories, look
> forward for the examples like Axel suggested. I am not sure if Mike's
> solutions claims to have the same for cat 2 and 3 or that he is only looking
> for a single identifier within the scope of cat 1.
> 
> I wonder how the following use cases fit this discussion/ suggested
> solution:
> 
> 1. The option to take your unique identifier from one IDP to another, like
> the current situation for mobile (number) or banking (accountnumber). When
> switching IDP there isn't a clear picture on what identifier to re-use from
> user perspective and doing all new registrations of your ID at different
> RP's. Although RP's like to re-use identifier type 1, identifier type 3
> seems like the most flexible one. But the current situation is that there is
> a lot of difference between the identifiers type 3 supported (ie. e-mail,
> and the risk of not being unique or issued to someone else in a later stage)
> 
> Combining the IDP identifier and user identifier in one could make it
> difficult to switch and keep the same identifier.
> 
> 2. RP's that want to support anonymous login tend to use the identifier type
> 1, in most cases they like to have a specific identifier for the service.
> Does the suggested solution make it possible to have different identifiers
> for different services at the same IDP?
> 
> I understand that some of these features can be part of the market
> proposition of the IDP, but I wonder if it is possible to support this using
> the suggested spec.
> 
> 
> Kick
> 
> -----Oorspronkelijk bericht-----
> Van: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] Namens
> Axel.Nennker at telekom.de
> Verzonden: woensdag 13 april 2011 10:54
> Aan: breno at google.com
> CC: openid-specs-ab at lists.openid.net
> Onderwerp: Re: [Openid-specs-ab] Identifiers and discovery.
> 
> You say:
> 1) Persistent Identifier (in the scope of the OP), never reassigned
> lasjkflasdflsajfljal02384ß20183lskadjfölsafj
> 
> 2) UI Identifier
> Fullname: Axel Nennker
> Profilepicref:
> https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC3ZjYXJk
> X3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3MmMxMAH08_TJz4El
> Y-WIBPBE1pmNuOStyQ (is this persistent?)
> 
> 3) Contact Identifier
> Work: axel.nennker at telekom.de
> Private: ignisvulpis at gmail.com
> Personal: axel at nennker.de
> Tel: +491702275312
> 
> Right?
> 
> Is https://www.google.com/profiles/ignisvulpis in category 1? Never
> reassigned?
> 
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno at google.com] 
>> Sent: Wednesday, April 13, 2011 10:38 AM
>> To: Nennker, Axel
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>> 
>> On Wed, Apr 13, 2011 at 01:15,  <Axel.Nennker at telekom.de> wrote:
>>> 
>>> Similar for me. I gave up on trying to attend because 4pm 
>> PT is 1am here, so I went to sleep at 23:30 and could have 
>> made it for midnight.
>>> Anyway.
>>> 
>>> Regarding identifiers: Some people expect that the openid 
>> is "fancy" and easy to distiguish.
>>> Example: @t is much cooler than @AxelNennker or pt at fb.com 
>> is cooler than user4711 at facebook.com or
>>> https://me.google.com/AxelNennker is cooler than 
>> https://me.google.com/users/lasjkflasdflsajfljal02384ß20183lsk
>> adjfölsafj
>>> 
>>> The uglier ones achieve the goal of beeing not reassigned 
>> much easier than the prettier ones.
>>> 
>>> Display Names are an related issue: I guess that there are 
>> more than one "Mike Jones" in Microsoft possibly even more 
>> than one "Michael B. Jones". Each has a unique identifier 
>> which might be reassigned (after a grace period) to a new 
>> Michael B. Jones.
>>> 
>>> This is not only a technical problem. People want the 
>> pretty identifiers.
>> 
>> It is a technical problem. If we label the identifiers in the 
>> protocol as:
>> 
>> - Identifier 1: This is persistent. Use as index in your DB. E.g: a
>> numeric value.
>> - Identifier 2: This is what the user wants you to represent him as.
>> E.g: a name, photo, business card, etc.
>> - Identifier 3: This is what the user thinks you can use to find who
>> he is. E.g.: an email address
>> 
>>> The best we can achieve, I think, is that users never see 
>> the unique, never reassigned (, maybe global) identifiers.
>>> And that the UI for the display names is powerfull enough 
>> to help me to find the Mike Jones I want to reach.
>>> 
>>> Example: Consider a blog post with comments by openid 
>> users. The blog received a sreg fullname and the 
>> openid.claimed_id and openid.identity.
>>> Now it renders the fullname on the html page giving us 
>> comment by several Mike Jones. The "social" rendering would 
>> allow my user agent to render the comments from my friend 
>> list other than comments from people I don't know.
>>> 
>>> Ok, this moves away from pure protocol issues and issuer 
>> policy to OC best practices and UI issues.
>>> I am not sure how the openid abc wg "protocol" group can 
>> solve this non technical problems.
>>> 
>> 
>> No, that's the mistake OpenID2 fell into. We should have different
>> identifiers for different purposes so that it's foolproof how to deal
>> with this.
>> 
>> My proposal is that the identifier used in auth is number 1. You know
>> you can't use to do anything presentational with it.
>> Identifier #2 is the easiest: we return attributes at the user info
>> endpoint that can be used to personalize the user experience.
>> Identifier #3 is missing from the current drafts. I can see two
>> sensible approaches:
>> 
>> - Define a discovery protocol that starts by going to the issuer and
>> asking what it knows about the asserted user_id. The advantage of
>> doing this is that we can support both public and protected (meaning
>> that user needs to consent) discovery with the same set of techniques.
>> 
>> - Use the email or profile URL (both which will be returned as user
>> attributes) as discovery starting points. This has some advantages in
>> that we may be able to re-use some existing ideas and techniques.
>> 
>> Again, what we don't want is an identifier that does all 
>> three jobs poorly.
>> 
>>> -Axel
>>> 
>>>> -----Original Message-----
>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf
>>>> Of Breno de Medeiros
>>>> Sent: Tuesday, April 12, 2011 6:18 PM
>>>> To: openid-specs-ab at lists.openid.net
>>>> Subject: [Openid-specs-ab] Identifiers and discovery.
>>>> 
>>>> I hope Nat's well.
>>>> 
>>>> I was in a meeting at 3:00pm (that I scheduled after 
>> JBradley asserted
>>>> the conference call would take place as usual at 4pm). 
>> When I joined,
>>>> Mike Jones and Nat were dropping off the call.
>>>> 
>>>> That left JBradley and I on the call. We had a discussion on
>>>> identifiers and discovery.
>>>> 
>>>> I would like to continue this conversation via email, as it's
>>>> an important one.
>>>> 
>>>> 
>>>> Currently, Google's proposal on identifiers is:
>>>> 
>>>> - Identifiers are unique to the user and non-reassignable 
>> within the
>>>> scope of the issuer. However, they need not be globally unique.
>>>> 
>>>> - Id_tokens attest to the issuer and therefore provide a 
>> statement of
>>>> the globally unique (issuer_id, user_id) pair. If the signature is
>>>> based on PK, these tokens are also universally verifiable and fully
>>>> portable.
>>>> 
>>>> Looking forward to an interesting discussion,
>>>> 
>>>> --
>>>> --Breno
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> --Breno
>> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab