<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect Session Management 1.0 - draft 08</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Session Management 1.0 - draft 08">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">B. de Medeiros</td></tr>
<tr><td class="header"> </td><td class="header">N. Agarwal</td></tr>
<tr><td class="header"> </td><td class="header">Google</td></tr>
<tr><td class="header"> </td><td class="header">N. Sakimura, Ed.</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">Ping Identity</td></tr>
<tr><td class="header"> </td><td class="header">M. Jones</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">May 25, 2012</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Session Management 1.0 - draft 08</h1>
<h3>Abstract</h3>
<p>NOTE: This is a first cut of a significant rewrite based on May 5, 2012 WG meeting.
</p>
<p>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and RESTful manner.
</p>
<p>This document describes how to manage sessions for OpenID Connect.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#rnc">1.1.</a>
Requirements Notation and Conventions<br />
<a href="#terminology">1.2.</a>
Terminology<br />
<a href="#anchor2">2.</a>
Endpoint Discovery<br />
<a href="#anchor3">3.</a>
Creating and Updating Sessions<br />
<a href="#anchor4">4.</a>
Session status change notification<br />
<a href="#anchor5">4.1.</a>
OP iframe<br />
<a href="#anchor6">4.2.</a>
RP iframe<br />
<a href="#anchor7">5.</a>
RP initiated Logout<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#Security">7.</a>
Security Considerations<br />
<a href="#rfc.references1">8.</a>
Normative References<br />
<a href="#Acknowledgements">Appendix A.</a>
Acknowledgements<br />
<a href="#anchor9">Appendix B.</a>
Notices<br />
<a href="#anchor10">Appendix C.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>NOTE: Significant revisions are planned to the functionality described in this specification. Until then, developers should expect that any implementations based upon this specification will need to be changed as a result of the upcoming revisions.
</p>
<p>While OpenID Connect Messages and Standard defines the method to login the user to the RP based on the ID token, it does not talk about how to continuously monitor the user's login status at the OP so that the RP may logout the user once the user has logged out of the OP. This specification defines the method to achieve this.
</p>
<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Requirements Notation and Conventions</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<p>Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Terminology</h3>
<p>This specification uses the terms "Access Token", "Refresh Token", "Authorization Code", "Authorization Grant", "Authorization Server", "Authorization Endpoint", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Resource Owner", "Resource Server", and "Token Endpoint" defined by <a class='info' href='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2012.</span><span>)</span></a> [OAuth2.0], and the terms defined by <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2012.</span><span>)</span></a> [OpenID.Messages]. This specification also defines the following terms: </p>
<blockquote class="text"><dl>
<dt>OP Session State</dt>
<dd>The string that represents the session state at the OP. One of the "no_user", "not_authenticated", and "authenticated_user".
</dd>
</dl></blockquote>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Endpoint Discovery</h3>
<p>To support the OpenID Conenct session managment, the RP MUST obtain the session management related endpoint URLs. This can either be obtained out of band or through the OP configuration file as described in OpenID Connect Discovery.
</p>
<p>The OP endpoints defined in this specification are as follows:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>OP iframe URL</dt>
<dd>The URL from which OP iframe is being loaded. This URL provides a page that accepts postMessage from the relevant RP iframe and postMessage back the login status of the user at the OP.
</dd>
<dt>OP Logout endpoint URL</dt>
<dd>The URL that initiate the user logout at the OP.
</dd>
</dl></blockquote>
<p>The RP endpoints defined in this specification are as follows:
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Creating and Updating Sessions</h3>
<p>In OpenID Connect, the session at the RP typically starts when the RP verifies the user's ID Token. Refer to OpenID Connect Standard to find out how to obtain an ID Token and verify it. Typically, when the RP has enough knowledge on the user's identity, the RP sends the authentication request with previously obtained ID Token as the user hint with prompt=none.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Session status change notification</h3>
<p>ID Token typically comes with the expiry date. The RP MAY rely on it to expire the RP session. However, it is entirely possible that the user may have logged out of the IdP before the expiry date. Therefore, it is highly desirable to be able to find out the login status of the user at the OP.
</p>
<p>To do so, it is possible to repeat the authentication request with prompt=none. However, this causes network traffic and this is problematic on the mobile devices that are increasingly becoming popular. Therefore, once the session is established with the authentication request and response, it is desirable to be able to check the login status at the OP without causing network traffic by polling the hidden OP iframe from a RP iframe with origin restricted postMessage as follows.
</p>
<p>
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
OP iframe</h3>
<p>The RP loads typically invisible OP iframe in the page from the OP iframe URL with the following parameters.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>user_hint</dt>
<dd>REQUIRED. ID Token that the RP received when it logged in the user. The value of the aud field, which is a client_id of the RP, is used to set the source origin for the postMessage request. Note: If the id_token was asymmetrically encrypted for the RP, then the RP MUST decrypt it and use the decrypted version of the ID Token in this field.
</dd>
</dl></blockquote>
<p>The RP MUST assign an "id" attribute to the iframe so that it can address it later.
</p>
<p>The OP iframe MUST accept the postMessage from the source origin that was registered with the client. It MUST reject the postMessage request from other source origin.
</p>
<p>The postMessage from the RP iframe delevers session state, the concatenation of the following, as the data.
</p>
<p></p>
<ol class="text">
<li>sha256 hash of the concatenation of the Client ID, the source origin URL, the OP session state, and a salt which is 126 bits or more.
</li>
<li>An ascii period ".", i.e., 0x2E.
</li>
<li>the salt
</li>
</ol>
<p>The OP iframe MUST recalculate it from the previously obtained Client ID, the source origin URL, the current OP session state, and the salt obtained from the data. If the received value and the calculated value does not match, then the OP iframe MUST postMessage the string "changed" back to the source. If it matched, then it MUST postMessage the string "unchanged".
</p>
<p>Following is a non-normative example pseudo code for the OP iframe.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>window.addEventListener("message",receiveMessage, false);
function receiveMessage(e){
if ( e.origin !== "http://client.example.com" ) {
return;
}
var stat;
var opss = get_op_session_state();
var ss = sha256(client_id + origin + opss + salt) + "." + salt;
if (e.data == ss) {
stat = 'unchanged';
} else [
stat = 'changed';
}
e.source.postMessage(stat, e.origin);
};</pre></div><p>
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
RP iframe</h3>
<p>The RP also loads an invisible iframe from itself in the same page. This iframe MUST know the id of the OP iframe so that it can postMessage to the OP iframe.
</p>
<p>RP iframe polls OP iframe with postMessage with certain interval suitable for the RP application. With each postMessage, it sends the session state defined in Section 4.1. It also has to be able to receive the postMessage back from the OP iframe. The received data would either be "changed" or "unchanged". Upon receit of "changed",
</p>
<p>Following is a non-noramtive example pseudo code for the RP iframe
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>var mes = sha256(client_id + origin + opss + salt) + "." + salt;
function check_session()
{
var targetOrigin = "http://server.example.com";
var win = window.parent.document.getElementById("op").contentWindow;
win.postMessage( mes, targetOrigin);
}
function setTimer()
{
check_session();
timerID = setInterval("check_session()",3*1000);
}
function clearTimer()
{
clearInterval(timerID);
}
window.addEventListener("message", receiveMessage, false);
function receiveMessage(e)
{
var targetOrigin = "http://k1.sakimura.org";
if (e.origin !== targetOrigin ) {
return;
}
</pre></div><p>
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
RP initiated Logout</h3>
<p>Sometimes, the RP may want to notify the OP that the user has logged out of the site, and he may want to logout of the OP as well. In this case, the RP, after having logged out the user, sends the user to the OP's logout endpoint URL that is either advertised through IdP configuration file or out of band knowledge.
</p>
<p>Upon receipt of such message, the OP SHOULD prompt the user whether he wants to logout of the OP as well. If he says yes, then the OP MUST log him out.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
IANA Considerations</h3>
<p>This document makes no requests of IANA.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Security Considerations</h3>
<p>TBD
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>8. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OAuth2.0">[OAuth2.0]</a></td>
<td class="author-text">Hammer, E., Ed., Recordon, D., and D. Hardt, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">OAuth 2.0 Authorization Protocol</a>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Messages">[OpenID.Messages]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a href="http://openid.net/specs/openid-connect-messages-1_0.html">OpenID Connect Messages 1.0</a>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
<td class="author-text"><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a href="mailto:chris.newman@sun.com">C. Newman</a>, “<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>,” RFC 3339, July 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3339.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3339.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3548">[RFC3548]</a></td>
<td class="author-text">Josefsson, S., “<a href="http://tools.ietf.org/html/rfc3548">The Base16, Base32, and Base64 Data Encodings</a>,” RFC 3548, July 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3548.txt">TXT</a>).</td></tr>
</table>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Acknowledgements</h3>
<p>Breno, Naveen, George, Torsten, Axel, Amanda, Justin, Tony, Edmund, Mike, John, Nat.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.
Notices</h3>
<p>Copyright (c) 2012 The OpenID Foundation.
</p>
<p>The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
</p>
<p>The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C.
Document History</h3>
<p>[[ To be removed from the final specification ]]
</p>
<p>-08
</p>
<p></p>
<ul class="text">
<li>Complete rewrite based on the May 5, 2012 WG F2F meeting at Microsoft.
</li>
</ul>
<p>-07 </p>
<ul class="text">
<li>Added warning about the significant revisions planned to session management to the abstract and introduction.
</li>
<li>Changed client.example.com to client.example.org, per issue #251
</li>
<li>Listed author of ISO29115 as "International Telecommunication Union and International Organization for Standardization", per issue #589
</li>
<li>Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)
</li>
</ul>
<p>-06 </p>
<ul class="text">
<li>Updated Notices
</li>
<li>Updated References
</li>
</ul>
<p>-05 </p>
<ul class="text">
<li>Removed Check Session Endpoint
</li>
<li>Updated ID Token claims to reflect changes in Messages
</li>
</ul>
<p>-04 </p>
<ul class="text">
<li>Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard".
</li>
<li>Numerous cleanups, including updating references.
</li>
</ul>
<p>-03 </p>
<ul class="text">
<li>Corrected examples.
</li>
</ul>
<p>-02 </p>
<ul class="text">
<li>Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call.
</li>
</ul>
<p>-01 </p>
<ul class="text">
<li>Consistency and cleanup pass, including removing unused references.
</li>
</ul>
<p>-00 </p>
<ul class="text">
<li>Split from core when all optional features were removed.
</li>
</ul>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Breno de Medeiros</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Google</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:breno@google.com">breno@google.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Naveen Agarwal</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Google</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:naa@google.com">naa@google.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nat Sakimura (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nomura Research Institute, Ltd.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Bradley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ping Identity</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Michael B. Jones</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
</table>
</body></html>