<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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 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><!--[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>
</body>
</html>