<div dir="ltr">I'm okay with it.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 1, 2013 at 11:21 AM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    While I'm hesitant to add more specialized parameters to the auth
    endpoint, I can see the logic here. Thus, at first instinct, I could
    take it or leave it.<br>
    <br>
     -- Justin<div><div class="h5"><br>
    <br>
    <br>
    <div>On 02/01/2013 01:15 PM, Mike Jones
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      
      
      
      <div>
        <p class="MsoNormal">Currently “preferred_locales” and “max_age”
          are specified as occurring under the “userinfo” and “id_token”
          elements of the request object.  I would propose moving them
          up to being top-level elements of the request object, and
          possibly also allowing them to be used directly as request
          parameters.  My reasoning is that it makes no practical sense
          to use different locales for UserInfo claim values versus ID
          Token claim values.  Likewise, while “max_age” does apply
          logically to the ID Token, it would cause no confusion to have
          it apply to the whole request and it could be useful to allow
          specifying “max_age” as a query parameter.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">One consequence of allowing
          “preferred_locales” to also be specified as a query parameter
          is that its syntax would change from a JSON array to a
          space-separated list of strings.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">If we did this change, it would both
          simplify the parsing for the MTI Fallback Position described
          in my previous message (one would just ignore “userinfo” and
          “id_token” rather than ignoring the “claims” members of
          “userinfo” and “id_token”) and would enable more important
          functionality to be used without using the request object,
          which I think would make many developers happy.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Thoughts?<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">                                                           
          -- Mike<u></u><u></u></p>
        <p class="MsoNormal"><u></u><u></u></p>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>