<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><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></body>
</html>