<div dir="ltr">Yes. The law enforcement guy's use case was exactly that. <div>He wanted to generated ID Token and through it to the server to login to the server and receive service. </div><div style>His application was also location sensitive. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/3 Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>Hi,<br>
<br>
I agree with Nat on this use case. Another one is that the app wants to use the id_token as credential on its "home" IDP (probably via JWT bearer token profile). This is more or less 3rd party login for apps.<br>

<br>
regards,<br>
Torsten.<br><br><div class="gmail_quote"><br>
<br>
Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> schrieb:<div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div dir="ltr">Yes. If the app wants the identity information to evaluate its own access control, then it would probably want to know about the user identity (i.e., set of attributes related to the entity), and id_token is the right thing. <div>

<br></div><div>When I was talking to some law enforcement people in EU, they were talking similar things. Right now, we do not have any location data defined in the claims, but we may also want to do so in such cases. </div>

<div><br></div><div>Nat</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/3 Paul Madsen <span dir="ltr"><<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <font face="Arial">Hi Nat, the current AZA model does not preclude
      an access token being formatted as an id_token.<br>
      <br>
      I believe Torsten was conjecturing that there was potential value
      in an id_token being delivered to a native app in addition to an
      access token (whether formatted as id_token or not)<br>
      <br>
      Regards<span><font color="#888888"><br>
      <br>
      paul<br>
       </font></span></font><div><div><br>
    <div>On 7/2/13 10:53 AM, Nat Sakimura wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I actually do see some utility in the access token
        in the format of ID Token. 
        <div>It can give appropriate audience restriction etc. </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">
          2013/7/2 Paul Madsen <span dir="ltr"><<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>></span><br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> <font face="Arial">Hi
                Torsten, the current model is that the Authorization
                Agent (AZA) may itself obtain an id_token and use it to
                obtain an access token, but that only access tokens
                would be 'handed over' by the AZA to its constituent
                native apps.<br>
                <br>
                Are you proposing that there may be value in allowing
                the AZA to also hand over id_tokens (suitably targeted)
                as well?<br>
                <br>
                paul<br>
                <br>
              </font>
              <div>
                <div>
                  <div>On 7/1/13 1:38 PM, Torsten Lodderstedt wrote:<br>
                  </div>
                </div>
              </div>
              <blockquote type="cite">
                <div>
                  <div> Hi John,<br>
                    <br>
                    I interpreted the text of the charter the other way
                    around, so a client would be able to use an(y)
                    id_token (as a credential) to obtain an access
                    token. I'm fine if the mechanism is intended to
                    support id_token issuance.<br>
                    <br>
                    regards,<br>
                    Torsten.<br>
                    <br>
                     Am 01.07.2013 15:06, schrieb John Bradley:<br>
                    <blockquote type="cite"> Hi Torsten,
                      <div><br>
                      </div>
                      <div>In point 3 the charter talks about using
                        id_tokens to get access tokens.</div>
                      <div><br>
                      </div>
                      <div>So it is imagined that the mechanism would
                        issue id_tokens likely along the lines that
                        Google is doing for the play store by having a
                        3rd party as an audience and using "azp" to
                        indicate the client the token was issued to.  
                        We don't want to be too specific on the solution
                        in the charter.</div>
                      <div><br>
                      </div>
                      <div>If you think something needs to be added let
                        me know.</div>
                      <div><br>
                      </div>
                      <div>John B.</div>
                      <div><br>
                      </div>
                      <div>
                        <div>
                          <div>On 2013-07-01, at 2:17 AM, Torsten
                            Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>>


                            wrote:</div>
                          <br>
                          <blockquote type="cite">Hi,<br>
                            <br>
                            it would be great to have such a mechanism
                            across platforms!<br>
                            <br>
                            I'm wondering whether the mechanism should
                            issue id tokens as well. Right now it seems
                            to focus on access tokens.<br>
                            <br>
                            Regards,<br>
                            Torsten.<br>
                            <br>
                            <div class="gmail_quote"><br>
                              <br>
                              John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>>


                              schrieb:
                              <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                                <pre style="white-space:pre-wrap;word-wrap:break-word;font-family:sans-serif;margin-top:0px">The enclosed Work Group Charter is being sent to the Specs Council for review in anticipation of chartering the Group.

It is best have this activity under the foundation IPR as soon as possible.

Regards
John B.


</pre>
                                <div style="margin-top:2.5em;margin-bottom:1em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(0,0,0)"><br>
                                </div>
                                <pre style="white-space:pre-wrap;word-wrap:break-word;font-family:sans-serif;margin-top:0px"><hr>
specs mailing list
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
                              </blockquote>
                            </div>
                          </blockquote>
                        </div>
                        <br>
                      </div>
                    </blockquote>
                    <br>
                    <br>
                    <fieldset></fieldset>
                    <br>
                  </div>
                </div>
                <pre>_______________________________________________
specs mailing list
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
              </blockquote>
              <br>
            </div>
            <br>
            _______________________________________________<br>
            specs mailing list<br>
            <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
            <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        Nat Sakimura (=nat)
        <div>Chairman, OpenID Foundation<br>
          <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
          @_nat_en</div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>
</blockquote></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>