<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>