<HTML>
<HEAD>
<TITLE>Re: [Openid-specs-ab] Identifiers and discovery.</TITLE>
</HEAD>
<BODY>
<FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>Agreed – we don’t want discovery happing in the middle of an authentication flow. The IDP is known at this phase<BR>
<BR>
-cmort<BR>
<BR>
<BR>
On 4/13/11 5:12 PM, "Breno de Medeiros" <<a href="breno@google.com">breno@google.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>On Wed, Apr 13, 2011 at 17:11, Mike Jones <<a href="Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<BR>
>> (I don't know that we resolved how to discover a IdP in SWD.<BR>
><BR>
> Edmund Jay has worked out a simple way to discover IdPs from user identifiers using SWD. I hope to see it posted to the list shortly! :-)<BR>
<BR>
It still begs the question of why discovery is needed here. In which<BR>
way authentication benefits from discoverable identifiers? If<BR>
discovery is required for completion of the authentication step at the<BR>
very minimum it adds latency.<BR>
<BR>
><BR>
> -- Mike<BR>
><BR>
> -----Original Message-----<BR>
> From: John Bradley [<a href="mailto:ve7jtb@ve7jtb.com">mailto:ve7jtb@ve7jtb.com</a>]<BR>
> Sent: Wednesday, April 13, 2011 4:58 PM<BR>
> To: Breno de Medeiros<BR>
> Cc: Mike Jones; <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><BR>
> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<BR>
><BR>
> I think that we can probably agree that EnttiyID/Issuer names should be globally scoped.<BR>
> I also think they need to be discoverable for services. (I don't know that we resolved how to discover a IdP in SWD.<BR>
><BR>
> The thing that we seem split on is if the non reassignable identifier needs to be publicly discoverable.<BR>
><BR>
> In XRI one reason they were discoverable was they supported delegation of sub identifiers.<BR>
> Probably not something we want.<BR>
><BR>
> However using iNumbers the non-reassignable ID were clearly separated from the user enterable reassignable ones.<BR>
><BR>
> I do like the idea of using the user info endpoint for the user as the ID. However that prevents IdP from ever changing there endpoint URL.<BR>
><BR>
> John B.<BR>
><BR>
> On 2011-04-13, at 7:46 PM, Breno de Medeiros wrote:<BR>
><BR>
>> You can have a global federation with IDP-scoped user identifiers, as<BR>
>> long as the IDP/issuer names are global in scope.<BR>
>><BR>
>> On Wed, Apr 13, 2011 at 16:40, Mike Jones <<a href="Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<BR>
>>> I agree that uniqueness is only required within the federation. But<BR>
>>> if you adopt the OpenID Foundation's position that we are trying to<BR>
>>> build open systems where any party can be a full participant, then<BR>
>>> one of the things that our architecture needs to support is precisely a global federation.<BR>
>>> (And yes, of course, being a full participant in any particular<BR>
>>> context requires that the party is appropriately trusted by the other<BR>
>>> parties with which it is interacting.) But before trust can be<BR>
>>> established, the first step is being able to identify and perform<BR>
>>> discovery on the participants in the global federation to discover<BR>
>>> their services that you need to interact with.<BR>
>>><BR>
>>><BR>
>>><BR>
>>> I obviously agree with you that any TRUST decision based on a claim<BR>
>>> must be based upon the issuer of that claim. But that's actually<BR>
>>> independent of whether the IDENTIFIER for a principal (which yes,<BR>
>>> would be used in a claim signed by an issuer) is globally unique or not.<BR>
>>><BR>
>>><BR>
>>><BR>
>>> -- Mike<BR>
>>><BR>
>>><BR>
>>><BR>
>>> From: Chuck Mortimore [<a href="mailto:cmortimore@salesforce.com">mailto:cmortimore@salesforce.com</a>]<BR>
>>> Sent: Wednesday, April 13, 2011 4:31 PM<BR>
>>><BR>
>>> To: Mike Jones; <a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>; <a href="breno@google.com">breno@google.com</a><BR>
>>> Cc: <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><BR>
>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<BR>
>>><BR>
>>><BR>
>>><BR>
>>> On 4/13/11 4:10 PM, "Mike Jones" <<a href="Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<BR>
>>><BR>
>>> Taking your viewpoint for a minute, yes, in SWD the principal will of<BR>
>>> course be interpreted by the site at which discovery is being<BR>
>>> performed. This somewhat corresponds to it being relative to an issuer, I suppose.<BR>
>>><BR>
>>> It really must be interpreted in the context of the issuer, else<BR>
>>> you'd have issuers asserting principals for which they are not authoritative.<BR>
>>><BR>
>>> As a thought experiment, are you also proposing that an audience<BR>
>>> value could/should also be similarly scoped in some manner?<BR>
>>><BR>
>>> In federation deployments, the issuer and audience must be unique within the<BR>
>>> federation. It's not mandatory that they are globally unique. We could<BR>
>>> go for a global federation here which would change that, but I<BR>
>>> suspect that would actually limit some use-cases.<BR>
>>><BR>
>>> And do you agree with my architectural statement that the same entity<BR>
>>> could be any of a principal, an issuer, or an audience restriction<BR>
>>> value? If so, the your statement that an issuer should be unique<BR>
>>> also implies that so should a principal and an audience restriction<BR>
>>> value, as they are logically of the same kind.<BR>
>>><BR>
>>> I agree that an entity may be playing multiple roles, however we<BR>
>>> always need to interpret a claim in the context of who is making it.<BR>
>>><BR>
>>> For example, at Salesforce I can act as both a SAML SP and a SAML IDP. If<BR>
>>> a customer passes me an assertion I create session for the subject relative<BR>
>>> to the issuer, and check to see if the audience is me. If I turn around<BR>
>>> and act as an IDP, the entity id I previously used for audience now<BR>
>>> becomes my issuer, and I may send the exact same subject. However,<BR>
>>> the receiving service provider needs to interpret that subject as relative to me, and not<BR>
>>> the original IDP, as I'm the one making the assertion. It would<BR>
>>> technically be possible to form multi-party claims, or to pass along<BR>
>>> claims, but in all cases you must consider the subject in the light<BR>
>>> of who's making the assertion.<BR>
>>><BR>
>>> Note this isn't yet arguing for or against separating them :-)<BR>
>>><BR>
>>> -cmort<BR>
>>><BR>
>>> Thanks for the thoughtful discussion.<BR>
>>><BR>
>>> -- Mike<BR>
>>><BR>
>>><BR>
>>> From: Chuck Mortimore [<a href="mailto:cmortimore@salesforce.com">mailto:cmortimore@salesforce.com</a>]<BR>
>>> Sent: Wednesday, April 13, 2011 4:03 PM<BR>
>>> To: Mike Jones; <a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>; <a href="breno@google.com">breno@google.com</a><BR>
>>> Cc: <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><BR>
>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<BR>
>>><BR>
>>> When I said JWT I guess I actually meant JWT bearer token. You are correct<BR>
>>> that JWT on it's own doesn't contain a principal.<BR>
>>><BR>
>>> I agree that Issuer should be unique and is in JWT, SAML, etc. In<BR>
>>> practice, it's pretty difficult to enforce global uniqueness of this<BR>
>>> without some sort of discovery.<BR>
>>><BR>
>>> I do not believe that the text of your JWT Bearer Token profile makes "prn"<BR>
>>> globally unique, nor do I think that it should. The identifier should<BR>
>>> always be scoped to the issuer. The result may be globally unique,<BR>
>>> but prn should always be interpreted in context of who's asserting it.<BR>
>>><BR>
>>> -cmort<BR>
>>><BR>
>>><BR>
>>> On 4/13/11 3:04 PM, "Mike Jones" <<a href="Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<BR>
>>> No, I don't believe that captures it accurately, as JWT<BR>
>>> <<a href="http://self-issued.info/docs/draft-jones-json-web-token.html">http://self-issued.info/docs/draft-jones-json-web-token.html</a>> does<BR>
>>> not follow the first model as you wrote below. Both SWD<BR>
>>> <<a href="http://self-issued.info/docs/draft-jones-simple-web-discovery.html">http://self-issued.info/docs/draft-jones-simple-web-discovery.html</a>><BR>
>>> and the OAuth JWT Profile<BR>
>>> <<a href="http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html">http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html</a>><BR>
>>> assume that the principal is a globally unique identifier. Likewise,<BR>
>>> all three of JWT<BR>
>>> <<a href="http://self-issued.info/docs/draft-jones-json-web-token.html">http://self-issued.info/docs/draft-jones-json-web-token.html</a>> , SWD<BR>
>>> <<a href="http://self-issued.info/docs/draft-jones-simple-web-discovery.html">http://self-issued.info/docs/draft-jones-simple-web-discovery.html</a>><BR>
>>> , and the OAuth JWT Profile<BR>
>>> <<a href="http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html">http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html</a>> assume that issuer is also a globally unique identifier.<BR>
>>><BR>
>>> Furthermore, architecturally, a principal in one context may be an<BR>
>>> issuer in another context and an audience restriction value in a<BR>
>>> third. All need to use the same data representation for the system<BR>
>>> to architecturally hang together.<BR>
>>><BR>
>>> I believe that this is a strong architectural argument why<BR>
>>> <a href="https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u">https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u</a> is<BR>
>>> the best choice.<BR>
>>><BR>
>>> -- Mike<BR>
>>><BR>
>>><BR>
>>> From: <a href="openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><BR>
>>> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Chuck<BR>
>>> Mortimore<BR>
>>> Sent: Wednesday, April 13, 2011 2:43 PM<BR>
>>> To: <a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>; <a href="breno@google.com">breno@google.com</a><BR>
>>> Cc: <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><BR>
>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<BR>
>>><BR>
>>> I'd be concerned treating either 2 or 3 as an Identitfier.<BR>
>>><BR>
>>> As I understand it, the main debate is around the persistent<BR>
>>> identifier, and if the issuer and principal are separate entities or if the issuer is<BR>
>>> reflected in the principal. For example do we want<BR>
>>> issuer: <a href="https://login.salesforce.com/id">https://login.salesforce.com/id</a><BR>
>>> principal: 00DD0000000FH8l/005D0000001Az1u<BR>
>>><BR>
>>> Or<BR>
>>> principal:<BR>
>>> <a href="https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u">https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u</a><BR>
>>><BR>
>>><BR>
>>> The current ConnectCore uses the first model ( calling them user_id and<BR>
>>> domain ). JWT and SAML follow the first model. I believe this is Breno's<BR>
>>> preference as well.<BR>
>>><BR>
>>> We've currently deployed the second model; our focus was on<BR>
>>> simplicity and discoverability of the data behind the service. It<BR>
>>> acts are both our user_info endpoint as well as a discovery service<BR>
>>> for endpoints authorized for the access_token.<BR>
>>><BR>
>>> Does this capture it accurately? Is so, let's just hash out the pros/cons<BR>
>>> of each approach. I'm loathe to starting issuing 3 different types of<BR>
>>> identifiers.<BR>
>>><BR>
>>> -cmort<BR>
>>><BR>
>>><BR>
>>><BR>
>>> On 4/13/11 1:53 AM, "<a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>"<BR>
>>> <<a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>><BR>
>>> wrote:<BR>
>>> You say:<BR>
>>> 1) Persistent Identifier (in the scope of the OP), never reassigned<BR>
>>> lasjkflasdflsajfljal02384ß20183lskadjfölsafj<BR>
>>><BR>
>>> 2) UI Identifier<BR>
>>> Fullname: Axel Nennker<BR>
>>> Profilepicref:<BR>
>>> <a href="https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC">https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC</a><BR>
>>> 3ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3Mm<BR>
>>> MxMAH08_TJz4ElY-WIBPBE1pmNuOStyQ<BR>
>>> (is this persistent?)<BR>
>>><BR>
>>> 3) Contact Identifier<BR>
>>> Work: <a href="axel.nennker@telekom.de">axel.nennker@telekom.de</a><BR>
>>> Private: <a href="ignisvulpis@gmail.com">ignisvulpis@gmail.com</a><BR>
>>> Personal: <a href="axel@nennker.de">axel@nennker.de</a><BR>
>>> Tel: +491702275312<BR>
>>><BR>
>>> Right?<BR>
>>><BR>
>>> Is <a href="https://www.google.com/profiles/ignisvulpis">https://www.google.com/profiles/ignisvulpis</a> in category 1? Never<BR>
>>> reassigned?<BR>
>>><BR>
>>>> -----Original Message-----<BR>
>>>> From: Breno de Medeiros [<a href="mailto:breno@google.com">mailto:breno@google.com</a>]<BR>
>>>> Sent: Wednesday, April 13, 2011 10:38 AM<BR>
>>>> To: Nennker, Axel<BR>
>>>> Cc: <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><BR>
>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<BR>
>>>><BR>
>>>> On Wed, Apr 13, 2011 at 01:15, <<a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>> wrote:<BR>
>>>>><BR>
>>>>> Similar for me. I gave up on trying to attend because 4pm<BR>
>>>> PT is 1am here, so I went to sleep at 23:30 and could have made it<BR>
>>>> for midnight.<BR>
>>>>> Anyway.<BR>
>>>>><BR>
>>>>> Regarding identifiers: Some people expect that the openid<BR>
>>>> is "fancy" and easy to distiguish.<BR>
>>>>> Example: @t is much cooler than @AxelNennker or <a href="pt@fb.com">pt@fb.com</a><BR>
>>>> is cooler than <a href="user4711@facebook.com">user4711@facebook.com</a> or<BR>
>>>>> <a href="https://me.google.com/AxelNennker">https://me.google.com/AxelNennker</a> is cooler than<BR>
>>>> <a href="https://me.google.com/users/lasjkflasdflsajfljal02384ß20183lsk">https://me.google.com/users/lasjkflasdflsajfljal02384ß20183lsk</a><BR>
>>>> adjfölsafj<BR>
>>>>><BR>
>>>>> The uglier ones achieve the goal of beeing not reassigned<BR>
>>>> much easier than the prettier ones.<BR>
>>>>><BR>
>>>>> Display Names are an related issue: I guess that there are<BR>
>>>> more than one "Mike Jones" in Microsoft possibly even more than one<BR>
>>>> "Michael B. Jones". Each has a unique identifier which might be<BR>
>>>> reassigned (after a grace period) to a new Michael B. Jones.<BR>
>>>>><BR>
>>>>> This is not only a technical problem. People want the<BR>
>>>> pretty identifiers.<BR>
>>>><BR>
>>>> It is a technical problem. If we label the identifiers in the<BR>
>>>> protocol as:<BR>
>>>><BR>
>>>> - Identifier 1: This is persistent. Use as index in your DB. E.g: a<BR>
>>>> numeric value.<BR>
>>>> - Identifier 2: This is what the user wants you to represent him as.<BR>
>>>> E.g: a name, photo, business card, etc.<BR>
>>>> - Identifier 3: This is what the user thinks you can use to find who<BR>
>>>> he is. E.g.: an email address<BR>
>>>><BR>
>>>>> The best we can achieve, I think, is that users never see<BR>
>>>> the unique, never reassigned (, maybe global) identifiers.<BR>
>>>>> And that the UI for the display names is powerfull enough<BR>
>>>> to help me to find the Mike Jones I want to reach.<BR>
>>>>><BR>
>>>>> Example: Consider a blog post with comments by openid<BR>
>>>> users. The blog received a sreg fullname and the openid.claimed_id<BR>
>>>> and openid.identity.<BR>
>>>>> Now it renders the fullname on the html page giving us<BR>
>>>> comment by several Mike Jones. The "social" rendering would allow my<BR>
>>>> user agent to render the comments from my friend list other than<BR>
>>>> comments from people I don't know.<BR>
>>>>><BR>
>>>>> Ok, this moves away from pure protocol issues and issuer<BR>
>>>> policy to OC best practices and UI issues.<BR>
>>>>> I am not sure how the openid abc wg "protocol" group can<BR>
>>>> solve this non technical problems.<BR>
>>>>><BR>
>>>><BR>
>>>> No, that's the mistake OpenID2 fell into. We should have different<BR>
>>>> identifiers for different purposes so that it's foolproof how to<BR>
>>>> deal with this.<BR>
>>>><BR>
>>>> My proposal is that the identifier used in auth is number 1. You<BR>
>>>> know you can't use to do anything presentational with it.<BR>
>>>> Identifier #2 is the easiest: we return attributes at the user info<BR>
>>>> endpoint that can be used to personalize the user experience.<BR>
>>>> Identifier #3 is missing from the current drafts. I can see two<BR>
>>>> sensible approaches:<BR>
>>>><BR>
>>>> - Define a discovery protocol that starts by going to the issuer and<BR>
>>>> asking what it knows about the asserted user_id. The advantage of<BR>
>>>> doing this is that we can support both public and protected (meaning<BR>
>>>> that user needs to consent) discovery with the same set of techniques.<BR>
>>>><BR>
>>>> - Use the email or profile URL (both which will be returned as user<BR>
>>>> attributes) as discovery starting points. This has some advantages<BR>
>>>> in that we may be able to re-use some existing ideas and techniques.<BR>
>>>><BR>
>>>> Again, what we don't want is an identifier that does all three jobs<BR>
>>>> poorly.<BR>
>>>><BR>
>>>>> -Axel<BR>
>>>>><BR>
>>>>>> -----Original Message-----<BR>
>>>>>> From: <a href="openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><BR>
>>>>>> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of<BR>
>>>>>> Breno de Medeiros<BR>
>>>>>> Sent: Tuesday, April 12, 2011 6:18 PM<BR>
>>>>>> To: <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><BR>
>>>>>> Subject: [Openid-specs-ab] Identifiers and discovery.<BR>
>>>>>><BR>
>>>>>> I hope Nat's well.<BR>
>>>>>><BR>
>>>>>> I was in a meeting at 3:00pm (that I scheduled after<BR>
>>>> JBradley asserted<BR>
>>>>>> the conference call would take place as usual at 4pm).<BR>
>>>> When I joined,<BR>
>>>>>> Mike Jones and Nat were dropping off the call.<BR>
>>>>>><BR>
>>>>>> That left JBradley and I on the call. We had a discussion on<BR>
>>>>>> identifiers and discovery.<BR>
>>>>>><BR>
>>>>>> I would like to continue this conversation via email, as it's an<BR>
>>>>>> important one.<BR>
>>>>>><BR>
>>>>>><BR>
>>>>>> Currently, Google's proposal on identifiers is:<BR>
>>>>>><BR>
>>>>>> - Identifiers are unique to the user and non-reassignable<BR>
>>>> within the<BR>
>>>>>> scope of the issuer. However, they need not be globally unique.<BR>
>>>>>><BR>
>>>>>> - Id_tokens attest to the issuer and therefore provide a<BR>
>>>> statement of<BR>
>>>>>> the globally unique (issuer_id, user_id) pair. If the signature is<BR>
>>>>>> based on PK, these tokens are also universally verifiable and<BR>
>>>>>> fully portable.<BR>
>>>>>><BR>
>>>>>> Looking forward to an interesting discussion,<BR>
>>>>>><BR>
>>>>>> --<BR>
>>>>>> --Breno<BR>
>>>>>> _______________________________________________<BR>
>>>>>> Openid-specs-ab mailing list<BR>
>>>>>> <a href="Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><BR>
>>>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><BR>
>>>>>><BR>
>>>>><BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>>> --<BR>
>>>> --Breno<BR>
>>>><BR>
>>> _______________________________________________<BR>
>>> Openid-specs-ab mailing list<BR>
>>> <a href="Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><BR>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><BR>
>><BR>
>><BR>
>><BR>
>> --<BR>
>> --Breno<BR>
>> _______________________________________________<BR>
>> Openid-specs-ab mailing list<BR>
>> <a href="Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><BR>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><BR>
><BR>
><BR>
><BR>
<BR>
<BR>
<BR>
--<BR>
--Breno<BR>
_______________________________________________<BR>
Openid-specs-ab mailing list<BR>
<a href="Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><BR>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>