[Openid-specs-ab] Identifiers and discovery.

Breno de Medeiros breno at google.com
Wed Apr 13 23:15:27 UTC 2011 

On Wed, Apr 13, 2011 at 16:10, Mike Jones <Michael.Jones at microsoft.com> wrote:
> Taking your viewpoint for a minute, yes, in SWD the principal will of course
> be interpreted by the site at which discovery is being performed.  This
> somewhat corresponds to it being relative to an issuer, I suppose.
>
>
>
> As a thought experiment, are you also proposing that an audience value
> could/should also be similarly scoped in some manner?
>
>
>
> And do you agree with my architectural statement that the same entity could
> be any of a principal, an issuer, or an audience restriction value?  If so,
> the your statement that an issuer should be unique also implies that so
> should a principal and an audience restriction value, as they are logically
> of the same kind.

I am not sure I agree with this. Clearly an issuer is a type of
principal. However, in practice there is a lot of heavyweight logic
around interpreting what principals are. I guess that it's perfectly
fine to say that a user can be a principal and still assign user_ids
that are only global in the scope of the issuer. I very much doubt
it's possible to write safe code that manipulates principals from one
context into another without being aware of the semantics of each
context.

>
>
>
> Thanks for the thoughtful discussion…
>
>
>
>                                                             -- Mike
>
>
>
> From: Chuck Mortimore [mailto:cmortimore at salesforce.com]
> Sent: Wednesday, April 13, 2011 4:03 PM
> To: Mike Jones; Axel.Nennker at telekom.de; breno at google.com
>
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>
>
>
> When I said JWT I guess I actually meant JWT bearer token.   You are correct
> that JWT on it’s own doesn’t contain a principal.
>
> I agree that Issuer should be unique and is in JWT, SAML, etc.   In
> practice, it’s pretty difficult to enforce global uniqueness of this without
> some sort of discovery.
>
> I do not believe that the text of your JWT Bearer Token profile makes “prn”
> globally unique, nor do I think that it should.   The identifier should
> always be scoped to the issuer.  The result may be globally unique, but prn
> should always be interpreted in context of who’s asserting it.
>
> -cmort
>
>
> On 4/13/11 3:04 PM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:
>
> No, I don’t believe that captures it accurately, as JWT
> <http://self-issued.info/docs/draft-jones-json-web-token.html>  does not
> follow the first model as you wrote below.  Both SWD
> <http://self-issued.info/docs/draft-jones-simple-web-discovery.html>  and
> the OAuth JWT Profile
> <http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html>  assume
> that the principal is a globally unique identifier.  Likewise, all three of
> JWT <http://self-issued.info/docs/draft-jones-json-web-token.html> , SWD
> <http://self-issued.info/docs/draft-jones-simple-web-discovery.html> , and
> the OAuth JWT Profile
> <http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html>  assume
> that issuer is also a globally unique identifier.
>
> Furthermore, architecturally, a principal in one context may be an issuer in
> another context and an audience restriction value in a third.  All need to
> use the same data representation for the system to architecturally hang
> together.
>
> I believe that this is a strong architectural argument why
> https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u is the best
> choice.
>
>                                                             -- Mike
>
>
> From: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Chuck
> Mortimore
> Sent: Wednesday, April 13, 2011 2:43 PM
> To: Axel.Nennker at telekom.de; breno at google.com
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>
> I’d be concerned treating either 2 or 3 as an Identitfier.
>
> As I understand it, the main debate is around the persistent identifier, and
> if the issuer and principal are separate entities or if the issuer is
> reflected in the principal.   For example do we want
> issuer: https://login.salesforce.com/id
> principal: 00DD0000000FH8l/005D0000001Az1u
>
> Or
> principal: https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u
>
>
> The current ConnectCore uses the first model ( calling them user_id and
> domain ).  JWT and SAML follow the first model.   I believe this is Breno’s
> preference as well.
>
> We’ve currently deployed the second model; our focus was on simplicity and
> discoverability of the data behind the service.  It acts are both our
> user_info endpoint as well as a discovery service for endpoints authorized
> for the access_token.
>
> Does this capture it accurately?  Is so, let’s just hash out the pros/cons
> of each approach.    I’m loathe to starting issuing 3 different types of
> identifiers.
>
> -cmort
>
>
>
> On 4/13/11 1:53 AM, "Axel.Nennker at telekom.de" <Axel.Nennker at telekom.de>
> wrote:
> 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
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



-- 
--Breno

More information about the Openid-specs-ab mailing list