<html><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: small; "><h3 style="font-family: helvetica, monaco, 'MS Sans Serif', arial, sans-serif; font-weight: bold; font-style: normal; color: rgb(51, 51, 51); background-color: transparent; ">Connect Messaages</h3><h3 style="font-family: helvetica, monaco, 'MS Sans Serif', arial, sans-serif; font-weight: bold; font-style: normal; color: rgb(51, 51, 51); background-color: transparent; ">3.1.1. ID Token</h3><p style="margin-left: 2em; margin-right: 2em; ">The ID Token is a token that contains claims pertinent to the authentication event. The default format of an ID Token is a JWT which contains JSON claims. Authorization servers MAY return ID Tokens in a different format. Clients can discover the ID Token format used by authorization servers via <a class="info" href="https://mail.google.com/mail/s/?view=att&th=131df4e4ea3201e6&attid=0.2&disp=attd&zw#OpenID.Discovery" style="font-weight: bold; position: relative; z-index: 24; text-decoration: none; color: rgb(153, 0, 0); background-color: transparent; ">OpenID Connect Discovery</a> [OpenID.Discovery] or by possessing prior knowledge of the authorization server.</p><div><br></div></span><br>=nat via iPad</div><div><br>On 2011/08/20, at 10:10, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>The default and only defined token format for id_token is JWT.<div><br></div><div>We were careful not to preclude using other token types in lite, however no other token types are defined and no mechanism for a RP to discriminate between token types has been defined.</div><div><br></div><div>We did have a discussion that content sniffing is not a good idea. </div><div><br></div><div>That leaves indicating the token type in the response or in the registration.</div><div><br></div><div>If at registration then the client needs to remember to always use Check session if they don't know how to parse the token.</div><div><br></div><div>A legitimate question would be is there anyone actually planning on using something other then JWT for the id_token.</div><div><br></div><div>I don't want to add complexity and find out that everyone uses JWT anyway.</div><div><br></div><div>John<br><div><div>On 2011-08-19, at 9:04 PM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>To be exact, the default format of the I'd_token is JWT, I believe. </div><div>If the server provides type of the token via either discovery or out of band information, it could use other formats, like FB signed request. <br><br>=nat via iPad</div><div><br>On 2011/08/20, at 4:12, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>The id_token is the access token for the check session endpoint.<div><br></div><div>Only the id_token is sent to the check session endpoint.</div><div><br></div><div>As Oauth only has one access token we have to give the access token for the session endpoints a separate name. That is id_token. I did rase the possibility of calling it session but no one took me up on that.</div><div><br></div><div>The access token for the check session endpoint is a signed JWT that way a client can inspect it directly and never use the check session endpoint.</div><div><br></div><div>John B.<br><div><div>On 2011-08-19, at 3:06 PM, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">In section 3.3.1 - Are both the access_token and the id_token supposed to be sent to the Check Session endpoint? The way that Section 3.3.1 in Draft 9 is currently written, it sounds like only the id_token is sent in the request, and that the id_token is actually the access_token.<div>
<br></div><div>It would probably be helpful to have an example Check Session request in the spec.<br><div><br></div><div>Allen</div><div><div><br></div><div><br><div class="gmail_quote">On Fri, Aug 19, 2011 at 12:02 PM, Allen Tom <span dir="ltr"><<a href="mailto:allentomdude@gmail.com"></a><a href="mailto:allentomdude@gmail.com"><a href="mailto:allentomdude@gmail.com">allentomdude@gmail.com</a></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The explanation in Section 3 regarding when to use the Implicit vs Code flow is vague, because it's not clear as to what it means for a client to securely maintain state between itself and the auth server.<div>
<br></div>
<div>It might be better to just say that the Code flow should be used if the redirect_uri doesn't use HTTPS, and if the client is able to securely store its client_secret.</div><div><br></div><font color="#888888"><div>
Allen</div><div><br>
<div><br></div></div>
</font></blockquote></div><br></div></div></div>
</blockquote></div><br></div></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"><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a></span><br></div></blockquote></div></blockquote></div><br></div></div></blockquote></body></html>