<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">In my discussion with Breno, his intention is that the Check Session endpoint is a OAuth protected resource. The id_token is sent as the access token for accessing that resource, per the OAuth spec.<div><br></div><div>It is NOT a parameter for a API, it is the access token.</div><div><br></div><div>Breno should correct if I have that wrong.</div><div><br></div><div>It makes the most sense to me to think of openID Connect returning two access tokens for two protected resources, perhaps I am simple.</div><div><br></div><div>John</div><div><br></div><div><br></div><div><div>On 2011-08-19, at 10:06 PM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>question: </div><div><br></div><div>The messages spec states: </div><div><br></div><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; ">3.4.1. Check Session Request</h3><p style="margin-left: 2em; margin-right: 2em; ">To request the information about the authentication performed on the user, the following parameters are sent to the Check Session endpoint:</p><div style="margin-left: 2em; margin-right: 2em; "><br class="webkit-block-placeholder"></div><blockquote class="text"><dl><dt>id_token</dt><dd>REQUIRED. The ID Token obtained from an OpenID Connect authorization request.</dd></dl></blockquote></span><br>and the Standard spec states:</div><div><br></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; ">7.1. Client Session Requests</h3><p style="margin-left: 2em; margin-right: 2em; ">Clients MUST make a HTTP POST request using transport-layer security with the following <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace; font-size: small; ">application/x-www-form-urlencoded</tt>parameters in the request body:</p><div style="margin-left: 2em; margin-right: 2em; "><br class="webkit-block-placeholder"></div><blockquote class="text"><dl><dt>id_token</dt><dd>REQUIRED. The ID Token obtained from an OpenID Connect authorization request.</dd></dl></blockquote><div style="margin-left: 2em; margin-right: 2em; "><br class="webkit-block-placeholder"></div><p style="margin-left: 2em; margin-right: 2em; ">The Following is a non-normative example of an Check Session request:</p></span><div><br></div><div>I think these descriptions are correct from older drafts point of view. Since it is just a parameter, it can be used in conjunction with authentication. </div><div><br></div><div>If it is changed to be an access token, this description is wrong needs to be updated. </div><div><br></div><div>Could you kindly clarify?</div><div><br></div><div>=nat via iPad</div><div><br>On 2011/08/20, at 4:12, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</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">allentomdude@gmail.com</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">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></div></blockquote></div><br></body></html>