[Openid-specs-ab] Identifiers and discovery.

Mike Jones Michael.Jones at microsoft.com
Thu Apr 14 00:08:57 UTC 2011 

Complexity is the enemy of adoption.  Turning discovery into a full OAuth protected resource is overkill.  We want to developers to say "of course I can build that"!

-----Original Message-----
From: Breno de Medeiros [mailto:breno at google.com] 
Sent: Wednesday, April 13, 2011 5:06 PM
To: John Bradley
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Identifiers and discovery.

On Wed, Apr 13, 2011 at 17:04, John Bradley <ve7jtb at ve7jtb.com> wrote:
> As a counter argument.
>
> By not having the non-reassignable ID discoverable the RP must now also store a additional identifier for the user if it wants to do public discovery of that user again for some reason.
>
> I think the better answer is to have a oAuth protected discovery service that the RP can access like any other for the user.

That also has the advantage of unifying public and protected discovery.

>
> John B.
> On 2011-04-13, at 7:56 PM, Breno de Medeiros wrote:
>
>> Yes, audience needs to be global in scope.
>>
>> user_ids need not, and they can't safely be declared global without 
>> tying in discovery with authentication, which I'd rather not do. I 
>> strongly prefer that discovery be defined to solve the problems for 
>> which it is required to be present, e.g., for a generic claims 
>> architecture, where the context makes obvious why discovery is 
>> required.
>>
>> On Wed, Apr 13, 2011 at 16:50, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>> 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/AIbEiAIAAABECOzLpfXm2dn7pAE
>>>> iC3 
>>>> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3M
>>>> mMx
>>>> 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
>>>
>>>
>>
>>
>>
>> --
>> --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