<meta charset="utf-8">This is a note that records the decisions made at July 7 Spec Call. <div>This for the Session Management. </div><br><div class="gmail_quote">On Fri, Jul 8, 2011 at 3:07 AM, Johnny Bufu <span dir="ltr"><<a href="mailto:jbufu@janrain.com">jbufu@janrain.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi John,<br>
<br>
On 11-07-06 08:30 PM, John Bradley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the feedback.<br>
</blockquote>
<br>
Found the Session Management spec which covers some of the questions I had about the ID Token, but is not linked from any of the documents I've explored previously - it should be referenced from Core, I think.<br>
<br>
Following is a review of it.<br>
<br>
Johnny<br>
<br>
------------------------------<u></u>------------------------------<u></u>----<br>
<br>
Session Management (draft 00 / June 29, 2011)<br>
<br>
2. Terminology<br>
<br>
Client definition overloaded, Core terminology already references OAuth.<br></blockquote><div><br></div><div>Remove. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Client Servlet is not defined</blockquote><div><br></div><div>Define. Serverside client? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
ID Token has two definitions.<br></blockquote><div><br></div><div>Unite. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3. Session Management<br>
<br>
"In addition, session management for fourth parties such as desktop, native or mobile applications that utilizes authorization server credentials at fourth party web sites are also supported."<br></blockquote><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Grammar needs to be fixed here. Semantic is unclear: who are the fourth parties - desktop/native/mobile apps, web sites mentioned later, both groups?<br></blockquote><div><br></div><meta charset="utf-8"><div>Confirm with Breno and fix. </div>
<div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3.1.4.2. Implicit Flow Response<br>
<br>
"when response_type includes id_token, an ID Token MUST be returned in the response."<br>
<br>
Where is the ID Token added? Query parameters or fragment?<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
The example includes the access token as a query parameter, contrary to the referenced OAuth 2.0 / Section 4.2.2 (which says it should be added to the fragment).<br></blockquote><div><br></div><meta charset="utf-8"><div>
Clarify. </div><div>Must be returned in the fragment of the response. </div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The example misses the required token_type parameter.<br></blockquote><div><br></div><div>fix</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3.1.5.4. Token Access Response<br>
<br>
"The request format is defined in section 4.1.4 of the OAuth 2.0 [OAuth2.0] specification."<br>
<br>
Should say "response format".<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3.1.6.1. Browser Load<br>
<br>
"The client servlet then gets an ID Token that is session synchronized with the authorization server."<br>
<br>
"session synchronized" should link to the corresponding section (reading through this section I had no idea what was meant by it, or that an explanation was following).<br></blockquote><div><br></div><div>Clarify. Link. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Also consider moving the Session Synchronization up in the document.<br>
<br>
The "session synchronized" attribute of the ID Token could be asserted by the OP and part of the ID Token (rather than requiring clients to keep track of it separately).<br></blockquote><div><br></div><div>Accept. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3.2.1. Refresh Session<br>
<br>
"In a typical HTTP binding, an HTTP 302 redirect to the specified redirect_uri in the request with a new ID Token."<br>
<br>
Grammar needs to be checked (missing predicate).<br></blockquote><div><br></div><div>Fix. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
How is the new ID Token returned? Added to the query parameters or fragment, or either?</blockquote><div><br></div><div>Query. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
------------------------------<u></u>------------------------------<u></u>----<br>
______________________________<u></u>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.<u></u>net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-specs-<u></u>ab</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>