Indeed, id_token works as a detached signature over a blob including but not limited to an access token by design. As you point out, this capability can be quite interesting in various ways. <br><br>2015年5月28日木曜日、Peter Williams<<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>>さんは書きました:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div dir="ltr"><div>one thing I'm finding interesting is the world in which .js apps not only obtain control over the an id_token blob (via openid connect handshakes using the implicit flow) but use it (vs an access token) to talk to one or more API endpoints.</div><div><br></div><div>Its interesting because of semantic differences - differences from the classical oauth2 world of access tokens, of course. Certs are audience-free, of course (being intended for use by anyone, in a process of relying on digital signatures). Both Audience-free and audience-controlled id_tokens are now interesting. The combination of the audience-free cert (shared with an API endpoint using SSL client authn) and the audience-free/controlled id_token, is also very interesting combination - particularly when the cert is self-signed.</div><div><br></div><div>One can see a world in which consumers post the (self-signed) cert and the id_token to a discovery-site ...that allows others to discover the asserted binding between the cert and the id_token, facilitating lots more digital signature uptake. One sees how the id_token might be "signing" that document (if you recall how in ws-* land, tokens could "sign" (XML) messages).</div>                                        </div></div>
</blockquote><br><br>-- <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><br>