<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<title>Re: [Openid-specs-ab] Identifiers and discovery.</title>
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Lucida Grande";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">As a thought experiment, are you also proposing that an audience value could/should also be similarly scoped in some manner?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">Thanks for the thoughtful discussion…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Chuck Mortimore [mailto:cmortimore@salesforce.com]
<br>
<b>Sent:</b> Wednesday, April 13, 2011 4:03 PM<br>
<b>To:</b> Mike Jones; Axel.Nennker@telekom.de; breno@google.com<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Identifiers and discovery.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Lucida Grande","serif"">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. <br>
<br>
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. <br>
<br>
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.<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:</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Lucida Grande","serif"">No, I don’t believe that captures it accurately, as JWT <<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 not follow the first model as you wrote below. Both SWD <<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>> and the OAuth JWT Profile <<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 the principal is a globally unique identifier. Likewise, all three of JWT <<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 <<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>>
, and the OAuth JWT Profile <<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 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.<br>
<br>
I believe that this is a strong architectural argument why <a href="https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u">
https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u</a> is the best choice.<br>
<br>
-- Mike<br>
<br>
<br>
</span><b><span style="font-size:10.0pt;font-family:"Lucida Grande","serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Lucida Grande","serif"">
<a href="openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Chuck Mortimore<br>
<b>Sent:</b> Wednesday, April 13, 2011 2:43 PM<br>
<b>To:</b> <a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>; <a href="breno@google.com">
breno@google.com</a><br>
<b>Cc:</b> <a href="openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Identifiers and discovery.<br>
</span><br>
<span style="font-size:11.0pt;font-family:"Lucida Grande","serif"">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 identifier, and if the issuer and principal are separate entities or if the issuer is 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: <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 domain ). JWT and SAML follow the first model. I believe this is Breno’s preference as well. <br>
<br>
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. <br>
<br>
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.<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>" <<a href="Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>> 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: <a href="https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC3ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3MmMxMAH08_TJz4ElY-WIBPBE1pmNuOStyQ">
https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC3ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3MmMxMAH08_TJz4ElY-WIBPBE1pmNuOStyQ</a> (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 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<br>
> made it 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<br>
> than one "Michael B. Jones". Each has a unique identifier<br>
> which might be reassigned (after a grace period) to a new<br>
> 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<br>
> openid.claimed_id 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<br>
> allow my user agent to render the comments from my friend<br>
> list other than 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 deal<br>
> with this.<br>
><br>
> My proposal is that the identifier used in auth is number 1. You know<br>
> 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 in<br>
> 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<br>
> three jobs 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<br>
> >> Of 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<br>
> >> an 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 fully<br>
> >> 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></span><o:p></o:p></p>
</div>
</body>
</html>