I think it might be confusing to developers to have multiple access tokens. I don't think I've seen any other Connect/OAuth type implementations that return multiple access tokens. Are there any examples out there?<div>
<div><br></div><div>Instead of using the id_token as the access_token for the check session endpoint, it might seem more natural to validate the id_token by submitting it as a regular parameter instead?</div><div><br></div>
<div>Allen</div><div><br></div><div><br><div class="gmail_quote">On Mon, Aug 22, 2011 at 11:22 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">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><font color="#888888"><div>John</div></font><div><div></div><div class="h5"><div><br></div><div><br></div><div><div>On 2011-08-19, at 10:06 PM, Nat Sakimura wrote:</div><br><blockquote type="cite"><div bgcolor="#FFFFFF">
<div>question: </div><div><br></div><div>The messages spec states: </div><div><br></div><div><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif;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></div><blockquote><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 style="font-family:verdana, charcoal, helvetica, arial, sans-serif;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></div><blockquote><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></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" target="_blank">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><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" target="_blank"></a><a href="mailto:allentomdude@gmail.com" target="_blank">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" target="_blank">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>