<html><head></head><body bgcolor="#FFFFFF"><div>We are going to have a call at a separate time for the claims_in_id_token issue at 7am Pacific. I am going to send out a doodle poll for that. Perhaps we can do the same for this one. <br>
<br>=nat</div><div><br>On 2012/06/08, at 22:57, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
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 http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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>
<div class="WordSection1">
<p class="MsoNormal">Spec call notes 7-Jun-12</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Nat Sakimura</p>
<p class="MsoNormal">Mike Jones</p>
<p class="MsoNormal">George Fletcher</p>
<p class="MsoNormal">Edmund Jay</p>
<p class="MsoNormal">John Bradley</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Agenda:</p>
<p class="MsoNormal"> Next Interop</p>
<p class="MsoNormal"> claims_in_id_token Issue</p>
<p class="MsoNormal"> Session Management</p>
<p class="MsoNormal"> Edits and Release</p>
<p class="MsoNormal"> Open Issues</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Next Interop:</p>
<p class="MsoNormal"> We agreed that we need to
clone the OC3 interop to create OC4 before adding</p>
<p class="MsoNormal"> We will need Pam's buy-in
and time to do this</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">claims_in_id_token Issue:</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</p>
<p class="MsoNormal"> We will try
to resolve this issue soon that way</p>
<p class="MsoNormal"> Nat will send out a Doodle
poll for special call time to discuss this issue</p>
<p class="MsoNormal"> We will schedule the call
at a time that makes it convenient for Europeans</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> We discussed that at John's
proposal to have 4 new scope elements makes the scope elements
not stateful</p>
<p class="MsoNormal"> profile_idt
email_idt address_idt phone_idt</p>
<p class="MsoNormal"> Developers are rejecting
claims_in_id_token because it made the 4 scope definitions
stateful</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Session Management:</p>
<p class="MsoNormal"> Nat began transcribing the
Session Management notes</p>
<p class="MsoNormal"> He sent out initial notes
that he needs feedback on</p>
<p class="MsoNormal"> He noted that this spec
will be quite different than the others, as it contains local
APIs</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Edits and Release:</p>
<p class="MsoNormal"> The self-issued edits may
be ready for review tomorrow - issue #566</p>
<p class="MsoNormal"> After that, we'll do a
release with that functionality only</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Open Issues:</p>
<p class="MsoNormal"> We discussed some of the
open issues. There were no new ones.</p>
<p class="MsoNormal"> #576: Discovery - Monitor
IETF discovery spec decisions
</p>
<p class="MsoNormal"> We're
seeing no movement on WebFinger</p>
<p class="MsoNormal"> We will
need to decide soon what to do</p>
<p class="MsoNormal"> We could:</p>
<p class="MsoNormal">
Stay with SWD</p>
<p class="MsoNormal">
Try to profile a subset of WebFinger</p>
<p class="MsoNormal">
Profile host-meta</p>
<p class="MsoNormal"> #257: Acknowledgements and
other sections need review</p>
<p class="MsoNormal"> Nat
complied a proposed list of acknowledgements</p>
<p class="MsoNormal"> #539 Messages - 0. Add
scope for offline access</p>
<p class="MsoNormal"> AOL's
approach requires stateful session state, Google's is
stateless</p>
<p class="MsoNormal"> This issue
needs an owner and a concrete proposal</p>
<p class="MsoNormal">
Assigned to George, who will work with Breno</p>
<p class="MsoNormal"> #584 Messages - Username
claim</p>
<p class="MsoNormal"> We
discussed whether syntax restrictions should be imposed and if
so, what</p>
<p class="MsoNormal"> No one on
the call was particularly enamored with the claim</p>
<p class="MsoNormal"> Relying
parties could just use the part of the e-mail address before
the @ to achieve approximately the same thing</p>
<p class="MsoNormal"> The
consensus on the call was that this field is adding more
confusion than value</p>
<p class="MsoNormal"> Resolved as
WontFix</p>
<p class="MsoNormal"> #593 Standard: redirect_uri
registration & matching</p>
<p class="MsoNormal"> George
argued that requiring matching query parameters is overkill</p>
<p class="MsoNormal"> We only got through the
issues up to #593</p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
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></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></body></html>