[Openid-specs-ab] Identifiers and discovery.

Wed Apr 13 08:53:45 UTC 2011

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/AIbEiAIAAABECOzLpfXm2dn7pAEiC3ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3MmMxMAH08_TJz4ElY-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
> 