<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I would also like to echo Justin sentiments on this issue, this seems like a step backwards and does not allow for a easy path forward to integrate OIDC idP's  into systems that already rely on a username type claim. </div>
<div><br>
</div>
<div>While I work at MITRE I am actually on a different project than that of Justin. My project is currently using/profiling the use of OpenID Connect as a means to provide distributed identity and authentication across the Healthcare Domain for the Office
 of the National Coordinator for Health IT (ONC)  under the Nationwide Health Information Network (NwHIN ).   As part of our profile for OIDC there will be a required claim of username for identifying users across multiple local health domains.  This lets us
 integrate and use existing identifiers  already declared in other NwHIN projects based on username@healthdomain semantics.  For us a username is an absolutely must have claim and our profile will require it's use.   It's that or we are forced to use the user_id
 field for such requirements because nobody wants to use lkasdf66778asdf6asd55ksdksdf7@example.com as an identifier to remember.  </div>
<div><br>
</div>
<div>Additionally I would like to add that there is already implicitly declared the need for a username in the discovery protocol and  specification for that has examples showing it's use.  Whether or not it has been called that or not that is essentially what
 it is . What else would the joe in joe@example.com be.   The discover protocol states that while using an email address for discovery the principle is the full email address and that idP is the host  section  of that address.  So what does that make "joe". </div>
<div><br>
</div>
<div>You cannot just pull this out of the email address for a user.  The email addresses are not scoped to the domain of the idP and multiple users could have the same username portion of an email address just at different hosts, joe@hotmail.com vs joe @gmail.com
 vs joe@example.com.  I cannot see how including a username claim adds more confusion when not having one makes parts of the specs already written  vastly more confusing without it.</div>
<div><br>
</div>
<div>Also on a side tangent though somewhat related by way of the discovery specs. how do you verify a person is who they have claimed to be during discovery?  If I put into a form an email address identifier that then on the backend uses discovery to find
 the idP and redirect me to authenticate how does the RP know that is who I actually authenticated as at the idP?  There appears to be a step missing here that would allow the RP to know who actually authenticated. Otherwise I could put in joe@example.com but
 authenticate as joes_<span style="font-style: italic; ">evil_twin</span>@example.com and there does not appear to be away to verify that I actually authenticated as joe and not his evil twin.  If there was a username claim that could resolve some of this,
 but is should be baked into the authorization request somehow.</div>
<div><br>
</div>
<div>Rob</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>><br>
<span style="font-weight:bold">Date: </span>Friday, June 8, 2012 9:57 AM<br>
<span style="font-weight:bold">To: </span>Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>" <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-ab] Spec call notes 7-Jun-12<br>
</div>
<div><br>
</div>
<div>
<div bgcolor="#FFFFFF" text="#000000">I think that the resolution to issue #584 (Username claim) is a mistake. We're regressing from capability available and used in OpenID 2.0 via SREG and AX. We're ignoring what an existing IdP, Facebook, already does.
<br>
<br>
Telling clients to parse out the email address and pull in a name there is a ludicrous suggestion. Why don't we also drop given_name and family_name since the RP could just try and parse those out of "name"? It's absurd to make something this simple so complicated.<br>
<br>
I'm sorry that I can't make the telephone calls for the WG (for several personal reasons), especially since that seems to be where decisions like this get made. I would be happy to grab some other time to discuss this with people if more discussion is warranted.
 I'll even gladly submit a pull request of the spec changes for the issue. It will be about five lines tops, including all the XML.<br>
<br>
I can also say that our IdP implementation *will* have a username claim, and our in-house RP's *will* rely on it. I imagine that it other IdPs in the wild will as well. We might as well just decide here and now to standardize on it.<br>
<br>
And yes, I do think this is important.<br>
<br>
 -- Justin<br>
<br>
On 06/07/2012 08:07 PM, Mike Jones wrote:
<blockquote cite="mid:4E1F6AAD24975D4BA5B16804296739436652E450@TK5EX14MBXC284.redmond.corp.microsoft.com" type="cite">
<meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-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-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@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]-->
<div class="WordSection1">
<p class="MsoNormal">Spec call notes 7-Jun-12<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">George Fletcher<o:p></o:p></p>
<p class="MsoNormal">Edmund Jay<o:p></o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agenda:<o:p></o:p></p>
<p class="MsoNormal">                Next Interop<o:p></o:p></p>
<p class="MsoNormal">                claims_in_id_token Issue<o:p></o:p></p>
<p class="MsoNormal">                Session Management<o:p></o:p></p>
<p class="MsoNormal">                Edits and Release<o:p></o:p></p>
<p class="MsoNormal">                Open Issues<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Interop:<o:p></o:p></p>
<p class="MsoNormal">                We agreed that we need to clone the OC3 interop to create OC4 before adding<o:p></o:p></p>
<p class="MsoNormal">                We will need Pam's buy-in and time to do this<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">claims_in_id_token Issue:<o:p></o:p></p>
<p class="MsoNormal">                We agreed that it is easier to reach consensus when you can hear one another's voices than via e-mail<o:p></o:p></p>
<p class="MsoNormal">                                We will try to resolve this issue soon that way<o:p></o:p></p>
<p class="MsoNormal">                Nat will send out a Doodle poll for special call time to discuss this issue<o:p></o:p></p>
<p class="MsoNormal">                We will schedule the call at a time that makes it convenient for Europeans<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">                We discussed that at John's proposal to have 4 new scope elements makes the scope elements not stateful<o:p></o:p></p>
<p class="MsoNormal">                                profile_idt email_idt address_idt phone_idt<o:p></o:p></p>
<p class="MsoNormal">                Developers are rejecting claims_in_id_token because it made the 4 scope definitions stateful<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Session Management:<o:p></o:p></p>
<p class="MsoNormal">                Nat began transcribing the Session Management notes<o:p></o:p></p>
<p class="MsoNormal">                He sent out initial notes that he needs feedback on<o:p></o:p></p>
<p class="MsoNormal">                He noted that this spec will be quite different than the others, as it contains local APIs<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Edits and Release:<o:p></o:p></p>
<p class="MsoNormal">                The self-issued edits may be ready for review tomorrow - issue #566<o:p></o:p></p>
<p class="MsoNormal">                After that, we'll do a release with that functionality only<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Open Issues:<o:p></o:p></p>
<p class="MsoNormal">                We discussed some of the open issues.  There were no new ones.<o:p></o:p></p>
<p class="MsoNormal">                #576: Discovery - Monitor IETF discovery spec decisions
<o:p></o:p></p>
<p class="MsoNormal">                                We're seeing no movement on WebFinger<o:p></o:p></p>
<p class="MsoNormal">                                We will need to decide soon what to do<o:p></o:p></p>
<p class="MsoNormal">                                We could:<o:p></o:p></p>
<p class="MsoNormal">                                                Stay with SWD<o:p></o:p></p>
<p class="MsoNormal">                                                Try to profile a subset of WebFinger<o:p></o:p></p>
<p class="MsoNormal">                                                Profile host-meta<o:p></o:p></p>
<p class="MsoNormal">                #257: Acknowledgements and other sections need review<o:p></o:p></p>
<p class="MsoNormal">                                Nat complied a proposed list of acknowledgements<o:p></o:p></p>
<p class="MsoNormal">                #539 Messages - 0. Add scope for offline access<o:p></o:p></p>
<p class="MsoNormal">                                AOL's approach requires stateful session state, Google's is stateless<o:p></o:p></p>
<p class="MsoNormal">                                This issue needs an owner and a concrete proposal<o:p></o:p></p>
<p class="MsoNormal">                                                Assigned to George, who will work with Breno<o:p></o:p></p>
<p class="MsoNormal">                #584 Messages - Username claim<o:p></o:p></p>
<p class="MsoNormal">                                We discussed whether syntax restrictions should be imposed and if so, what<o:p></o:p></p>
<p class="MsoNormal">                                No one on the call was particularly enamored with the claim<o:p></o:p></p>
<p class="MsoNormal">                                Relying parties could just use the part of the e-mail address before the @ to achieve approximately the same thing<o:p></o:p></p>
<p class="MsoNormal">                                The consensus on the call was that this field is adding more confusion than value<o:p></o:p></p>
<p class="MsoNormal">                                Resolved as WontFix<o:p></o:p></p>
<p class="MsoNormal">                #593 Standard: redirect_uri registration & matching<o:p></o:p></p>
<p class="MsoNormal">                                George argued that requiring matching query parameters is overkill<o:p></o:p></p>
<p class="MsoNormal">                We only got through the issues up to #593<o:p></o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset> <br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></pre>
</blockquote>
<br>
</div>
</div>
</span>
</body>
</html>