[Openid-specs-ab] Identifiers and discovery.

Mike Jones Michael.Jones at microsoft.com
Wed Apr 13 23:50:14 UTC 2011 

The Audience values also need to also be global in scope.  Correct?

As an example why this needs to be true, if the audience were simply the user-id string "mbj", then something intended for mbj at microsoft.com might be received/intercepted an considered valid if used by mbj at gmail.com.

				-- Mike

-----Original Message-----
From: Breno de Medeiros [mailto:breno at google.com] 
Sent: Wednesday, April 13, 2011 4:47 PM
To: Mike Jones
Cc: Chuck Mortimore; Axel.Nennker at telekom.de; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Identifiers and discovery.

You can have a global federation with IDP-scoped user identifiers, as long as the IDP/issuer names are global in scope.

On Wed, Apr 13, 2011 at 16:40, Mike Jones <Michael.Jones at microsoft.com> wrote:
> I agree that uniqueness is only required within the federation.  But 
> if you adopt the OpenID Foundation's position that we are trying to 
> build open systems where any party can be a full participant, then one 
> of the things that our architecture needs to support is precisely a global federation.
> (And yes, of course, being a full participant in any particular 
> context requires that the party is appropriately trusted by the other 
> parties with which it is interacting.) But before trust can be 
> established, the first step is being able to identify and perform 
> discovery on the participants in the global federation to discover 
> their services that you need to interact with.
>
>
>
> I obviously agree with you that any TRUST decision based on a claim 
> must be based upon the issuer of that claim.  But that's actually 
> independent of whether the IDENTIFIER for a principal (which yes, 
> would be used in a claim signed by an issuer) is globally unique or not.
>
>
>
>                                                             -- Mike
>
>
>
> From: Chuck Mortimore [mailto:cmortimore at salesforce.com]
> Sent: Wednesday, April 13, 2011 4:31 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.
>
>
>
> On 4/13/11 4:10 PM, "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.
>
> It really must be interpreted in the context of the issuer, else you'd 
> have issuers asserting principals for which they are not authoritative.
>
> As a thought experiment, are you also proposing that an audience value 
> could/should also be similarly scoped in some manner?
>
> In federation deployments, the issuer and audience must be unique 
> within the federation.   It's not mandatory that they are globally 
> unique.   We could go for a global federation here which would change 
> that, but I suspect that would actually limit some use-cases.
>
> 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 agree that an entity may be playing multiple roles, however we 
> always need to interpret a claim in the context of who is making it.
>
> For example, at Salesforce I can act as both a SAML SP and a SAML IDP.   
> If a customer passes me an assertion I create session for the subject 
> relative to the issuer, and check to see if the audience is me.   If I 
> turn around and act as an IDP, the entity id I previously used for 
> audience now becomes my issuer, and I may send the exact same subject.  
> However, the receiving service provider needs to interpret that 
> subject as relative to me, and not the original IDP, as I'm the one 
> making the assertion.    It would technically be possible to form 
> multi-party claims, or to pass along claims, but in all cases you must 
> consider the subject in the light of who's making the assertion.
>
> Note this isn't yet arguing for or against separating them :-)
>
> -cmort
>
> 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/AIbEiAIAAABECOzLpfXm2dn7pAEiC3
> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3MmMx
> MAH08_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