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