<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>International Government Assurance Profile (iGov) for OpenID Connect 1.0</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* 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.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Requirements Notation and Conventions"/>
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terminology"/>
<link href="#rfc.section.1.3" rel="Chapter" title="1.3 Conformance"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Authorization Request"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Authorization Response"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Token Request"/>
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 ID Tokens"/>
<link href="#rfc.section.5" rel="Chapter" title="5 UserInfo Endpoint"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Request Objects"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Authentication Context"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Discovery"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Scope Profiles (UserInfo Attributes"/>
<link href="#rfc.section.10" rel="Chapter" title="10 Security Considerations"/>
<link href="#rfc.references" rel="Chapter" title="11 Normative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
<link href="#rfc.appendix.B" rel="Chapter" title="B Notices"/>
<link href="#rfc.appendix.C" rel="Chapter" title="C Document History"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.1 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Varley, M., Ed." />
<meta name="dct.identifier" content="urn:ietf:id:openid-igov-profile" />
<meta name="dct.issued" scheme="ISO8601" content="2016-7-18" />
<meta name="dct.abstract" content="The OpenID Connect protocol defines an identity federation system that allows a relying party to request and receive authentication and profile information about an end user." />
<meta name="description" content="The OpenID Connect protocol defines an identity federation system that allows a relying party to request and receive authentication and profile information about an end user." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left"></td>
<td class="right">M. Varley, Ed.</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">July 18, 2016</td>
</tr>
</tbody>
</table>
<p class="title">International Government Assurance Profile (iGov) for OpenID Connect 1.0<br />
<span class="filename">openid-igov-profile</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>The OpenID Connect protocol defines an identity federation system that allows a relying party to request and receive authentication and profile information about an end user.</p>
<p>This specification profiles the OpenID Connect protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) government and public service domains.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<ul><li>1.1. <a href="#rfc.section.1.1">Requirements Notation and Conventions</a></li>
<li>1.2. <a href="#rfc.section.1.2">Terminology</a></li>
<li>1.3. <a href="#rfc.section.1.3">Conformance</a></li>
</ul><li>2. <a href="#rfc.section.2">Authorization Request</a></li>
<li>3. <a href="#rfc.section.3">Authorization Response</a></li>
<li>4. <a href="#rfc.section.4">Token Request</a></li>
<ul><li>4.1. <a href="#rfc.section.4.1">ID Tokens</a></li>
</ul><li>5. <a href="#rfc.section.5">UserInfo Endpoint</a></li>
<li>6. <a href="#rfc.section.6">Request Objects</a></li>
<li>7. <a href="#rfc.section.7">Authentication Context</a></li>
<li>8. <a href="#rfc.section.8">Discovery</a></li>
<li>9. <a href="#rfc.section.9">Scope Profiles (UserInfo Attributes</a></li>
<li>10. <a href="#rfc.section.10">Security Considerations</a></li>
<li>11. <a href="#rfc.references">Normative References</a></li>
<li>Appendix A. <a href="#rfc.appendix.A">Acknowledgements</a></li>
<li>Appendix B. <a href="#rfc.appendix.B">Notices</a></li>
<li>Appendix C. <a href="#rfc.appendix.C">Document History</a></li>
<li><a href="#rfc.authors">Author's Address</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#Introduction" id="Introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">Government regulations for permitting users (citizens and non-citizens) online access to government resources vary greatly from region to region. There is a strong desire to leverage federated authentication and identity services for public access to government resources online to reduce 'password fatigue', increase overall account security, reduce cost, and provide reliable identity assurances from established and trusted sources when applicable.</p>
<p id="rfc.section.1.p.2">This specification aims to define an OpenID Connect profile that provides governments with a foundation for securing federated access to public services online.</p>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> <a href="#rnc" id="rnc">Requirements Notation and Conventions</a></h1>
<p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119">RFC 2119</a> <cite title="NONE">[RFC2119]</cite>.</p>
<p id="rfc.section.1.1.p.2">All uses of <a href="#RFC7515">JSON Web Signature (JWS)</a> <cite title="NONE">[RFC7515]</cite> and <a href="#RFC7516">JSON Web Encryption (JWE)</a> <cite title="NONE">[RFC7516]</cite> data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used.</p>
<h1 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2.</a> <a href="#Terminology" id="Terminology">Terminology</a></h1>
<p id="rfc.section.1.2.p.1">This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint" defined by <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite>, the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)" defined by <a href="#RFC7519">JSON Web Token (JWT)</a> <cite title="NONE">[RFC7519]</cite>, and the terms defined by <a href="#OpenID.Core">OpenID Connect Core 1.0</a> <cite title="NONE">[OpenID.Core]</cite>.</p>
<h1 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3.</a> Conformance</h1>
<p id="rfc.section.1.3.p.1">** Given the wide range of government domains (local, regional, national) and interactions, what kind of conformance statement can we have here? **</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#AuthRequest" id="AuthRequest">Authorization Request</a></h1>
<p id="rfc.section.2.p.1">The following describes the supported OpenID Connect Authorization Code Flow parameters for use with iGov compatible IdPs.</p>
<p id="rfc.section.2.p.2">Request Parameters: </p>
<dl>
<dt>client_id</dt>
<dd style="margin-left: 8">REQUIRED. OAuth 2.0 Client Identifier valid at the Authorization Server.</dd>
<dt>response_type</dt>
<dd style="margin-left: 8">REQUIRED. MUST be set to <samp>code</samp>.</dd>
<dt>acr_values</dt>
<dd style="margin-left: 8">REQUIRED. Lists the acceptable LoAs for this authentication. See (below)</dd>
<dt>scope</dt>
<dd style="margin-left: 8">REQUIRED. Indicates the attributes being requested. (See below)</dd>
<dt>redirect_uri</dt>
<dd style="margin-left: 8">REQUIRED. Indicates a valid endpoint where the client will receive the authentication response. See (core section 3.1.2.1)</dd>
<dt>state</dt>
<dd style="margin-left: 8">REQUIRED. Unguessable random string generated by the RP, used to protect against CSRF attacks. Must contain a sufficient amount of entropy to avoid guessing. Returned to the RP in the authentication response.</dd>
<dt>prompt</dt>
<dd style="margin-left: 8">REQUIRED. This value must be set to <samp>select_account</samp>.</dd>
<dt>nonce</dt>
<dd style="margin-left: 8">OPTIONAL. Unguessable random string generated by the client, used to protect against CSRF attacks. Must contain a sufficient amount of entropy to avoid guessing. Returned to the client in the ID Token.</dd>
</dl>
<p id="rfc.section.2.p.3">A sample request may look like:</p>
<pre>
https://idp.government.gov/oidc/authorization?
response_type=code
&client_id=827937609728-m2mvqffo9bsefh4di90saus4n0diar2h
&scope=d+openid
&redirect_uri=https%3A%2F%2Frp.fed1.gov%2Foidc%2FloginResponse
&state=2ca3359dfbfd0
&prompt=select_account
&acr_values=http%3A%2F%2Fidmanagement.gov%2Fns%2Fassurance%2Floa%2F1
+http%3A%2F%2Fidmanagement.gov%2Fns%2Fassurance%2Floa%2F2
+http%3A%2F%2Fidmanagement.gov%2Fns%2Fassurance%2Floa%2F3
+http%3A%2F%2Fidmanagement.gov%2Fns%2Fa
</pre>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#AuthorizationResponse" id="AuthorizationResponse">Authorization Response</a></h1>
<p id="rfc.section.3.p.1">The following data will be sent as an Authorization Response to the Authorization Code Flow as desribed above. The authentication response is sent via HTTP redirect to the redirect URI specified in the request.</p>
<p id="rfc.section.3.p.2">The following fields MUST be included in the response:</p>
<dl>
<dt>state</dt>
<dd style="margin-left: 8">REQUIRED. The value of the state parameter passed in in the authentication request. This value MUST match exactly.</dd>
<dt>code</dt>
<dd style="margin-left: 8">REQUIRED. The authorization code, a random string issued by the IdP to be used in the request to the token endpoint.</dd>
</dl>
<p id="rfc.section.3.p.3">The following is an example response:</p>
<pre>
https://int-rp.fed1.securekey.com/skrp1/web/oidc/loginResponse?
state=2ca3359dfbfd0
&code=gOIFJ1hV6Rb1sxUdFhZGACWwR1sMhYbJJcQbVJN0wHA
</pre>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#TokenRequest" id="TokenRequest">Token Request</a></h1>
<p id="rfc.section.4.p.1">To retrieve the access and ID tokens, the client sends a token request to the token endpoint using HTTP POST with parameters in the form encoded body.</p>
<p id="rfc.section.4.p.2">Clients must authenticate to the Token Endpoint using the <samp>client_secret_jwt</samp> or <samp>private_key_jwt</samp> method as described in (Core spec section 9).</p>
<p id="rfc.section.4.p.3">The following parameters are specified:</p>
<dl>
<dt>grant_type</dt>
<dd style="margin-left: 8">REQUIRED. MUST be set to <samp>authorization_code</samp>.</dd>
<dt>code</dt>
<dd style="margin-left: 8">REQUIRED. The value of the code parameter returned in the authorization response.</dd>
<dt>client_assertion_type</dt>
<dd style="margin-left: 8">REQUIRED. MUST be set to <samp>urn:ietf:params:oauth:client-assertion-type:jwt-bearer</samp>.</dd>
<dt>client_assertion</dt>
<dd style="margin-left: 8">REQUIRED. The value of the signed client authentication JWT generated as described below. The RP must generate a new assertion JWT for each call to the token endpoint.</dd>
</dl>
<p id="rfc.section.4.p.4">The signed client authentication token MUST contain the following parameters:</p>
<dl>
<dt>iss</dt>
<dd style="margin-left: 8">REQUIRED. The client ID.</dd>
<dt>sub</dt>
<dd style="margin-left: 8">REQUIRED. The client ID.</dd>
<dt>aud</dt>
<dd style="margin-left: 8">REQUIRED. The URL of the token endpoint.</dd>
<dt>jti</dt>
<dd style="margin-left: 8">REQUIRED. An unguessable random string generated by the client.</dd>
<dt>exp</dt>
<dd style="margin-left: 8">REQUIRED. An integer timestamp (in Unix Epoch format) of the expiration of this assertion. This should be a very small time in the future, such as five minutes from issuance.</dd>
</dl>
<p id="rfc.section.4.p.5">If the client is authenticating with the <samp>client_secret_jwt</samp> method, the client creates a JWS using an HMAC SHA algorithm, such as HMAC SHA-256. The HMAC (Hash-based Message Authentication Code) is calculated using the octets of the UTF-8 representation of the client_secret as the shared key. The server will have the same client_secret, and be able to verify the hash and therefore authenticate the client.</p>
<p id="rfc.section.4.p.6">If the client is authenticating with the <samp>private_key_jwt</samp> method, the client signs this JWT with its own private key and sends it to the server as described above in the client_assertion field. Since the client has registered its public key, the server will be able to verify the signature of the JWT and therefore authenticate the client.</p>
<p id="rfc.section.4.p.7">For example (with line wraps within values for display purposes only):</p>
<pre>
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=i1WsRn1uB1&
client_id=s6BhdRkqt3&
client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=PHNhbWxwOl ... ZT
</pre>
<h1 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1.</a> <a href="#IDToken" id="IDToken">ID Tokens</a></h1>
<p id="rfc.section.4.1.p.1">The token response includes an access token (which can be used to make a UserInfo request) and ID token (a signed and optionally encrypted JSON Web Token). ID Token values have the following meanings:</p>
<dl>
<dt>iss</dt>
<dd style="margin-left: 8">The "issuer" field is the Uniform Resource Locater (URL) of the expected issuer. MUST be verified by the client.</dd>
<dt>aud</dt>
<dd style="margin-left: 8">The "audience" field contains the client ID of the client. MUST be verified by the client.</dd>
<dt>sub</dt>
<dd style="margin-left: 8">The identifier of the user. SHOULD be a pairwize annonymous identifier, and be unique per client to prevent linkability and traceability between clients.</dd>
<dt>acr</dt>
<dd style="margin-left: 8">The LoA the user was authenticated at. MUST be a member of the <samp>acr_values</samp> list from the authentication request.</dd>
<dt>nonce</dt>
<dd style="margin-left: 8">The nonce value that was provided in the authentication request. Included if provided in authentication request.</dd>
<dt>jti</dt>
<dd style="margin-left: 8">A unique identifier for the token, which can be used to prevent reuse of the token.</dd>
<dt>exp, iat, nbf</dt>
<dd style="margin-left: 8">The "expiration", "issued at", and "not before" timestamps for the token are dates (integer number of seconds since from 1970-01-01T00:00:00Z UTC) within acceptable ranges</dd>
</dl>
<p id="rfc.section.4.1.p.2">All ID Tokens MUST be signed by the OpenID Provider's private signature key. All clients MUST validate the signature of an ID Token before accepting it using the public key of the issuing server, which is published in <a href="#RFC7517">JSON Web Key (JWK)</a> <cite title="NONE">[RFC7517]</cite> format. ID Tokens MAY be encrypted using the appropriate key of the requesting client.</p>
<p id="rfc.section.4.1.p.3">The ID Token MUST expire and SHOULD have an active lifetime no longer than five minutes.</p>
<p id="rfc.section.4.1.p.4">This example ID token has been signed using the server's RSA key:</p>
<pre>eyJhbGciOiJSUzI1NiJ9.eyJhdXRoX3RpbWUiOjE0
MTg2OTg3ODIsImV4cCI6MTQxODY5OTQxMiwic3ViI
joiNldaUVBwblF4ViIsIm5vbmNlIjoiMTg4NjM3Yj
NhZjE0YSIsImF1ZCI6WyJjMWJjODRlNC00N2VlLTR
iNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNzIjoi
aHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iL
CJpYXQiOjE0MTg2OTg4MTJ9mQc0rtL56dnJ7_zO_f
x8-qObsQhXcn-qN-FC3JIDBuNmP8i11LRA_sgh_om
RRfQAUhZD5qTRPAKbLuCD451lf7ALAUwoGg8zAASI
5QNGXoBVVn7buxPd2SElbSnHxu0o8ZsUZZwNpircW
NUlYLje6APJf0kre9ztTj-5J1hRKFbbHodR2I1m5q
8zQR0ql-FoFlOfPhvfurXxCRGqP1xpvLLBUi0JAw3
F8hZt_i1RUYWMqLQZV4VU3eVNeIPAD38qD1fxTXGV
Ed2XDJpmlcxjrWxzJ8fGfJrbsiHCzmCjflhv34O22
zb0lJpC0d0VScqxXjNTa2-ULyCoehLcezmssg</pre>
<p id="rfc.section.4.1.p.5">Its claims are as follows:</p>
<pre> {
"auth_time": 1418698782,
"exp": 1418699412,
"sub": "6WZQPpnQxV",
"nonce": "188637b3af14a",
"aud": [
"c1bc84e4-47ee-4b64-bb52-5cda6c81f788"
],
"iss": "https:\\/\\/idp-p.example.com\\/",
"iat": 1418698812
}
</pre>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#UserInfoEndpoint" id="UserInfoEndpoint">UserInfo Endpoint</a></h1>
<p id="rfc.section.5.p.1">Servers MUST support the UserInfo Endpoint and, at a minimum, the <samp>sub</samp> (subject) claim.</p>
<p id="rfc.section.5.p.2">In an example transaction, the client sends a request to the UserInfo Endpoint like the following:</p>
<pre>GET /userinfo HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTIsIm
F1ZCI6WyJjMWJjODRlNC00N2VlLTRiNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNzIjo
iaHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iLCJqdGkiOiJkM2Y3YjQ4Zi1iYzgx
LTQwZWMtYTE0MC05NzRhZjc0YzRkZTMiLCJpYXQiOjE0MTg2OTg4MTJ9i.HMz_tzZ90_b
0QZS-AXtQtvclZ7M4uDAs1WxCFxpgBfBanolW37X8h1ECrUJexbXMD6rrj_uuWEqPD738
oWRo0rOnoKJAgbF1GhXPAYnN5pZRygWSD1a6RcmN85SxUig0H0e7drmdmRkPQgbl2wMhu
-6h2Oqw-ize4dKmykN9UX_2drXrooSxpRZqFVYX8PkCvCCBuFy2O-HPRov_SwtJMk5qjU
WMyn2I4Nu2s-R20aCA-7T5dunr0iWCkLQnVnaXMfA22RlRiU87nl21zappYb1_EHF9ePy
q3Q353cDUY7vje8m2kKXYTgc_bUAYuW-W3SMSw5UlKaHtSZ6PQICoA
Accept: text/plain, application/json, application/*+json, */*
Host: idp-p.example.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.2.3 (java 1.5)
</pre>
<p id="rfc.section.5.p.3">And receives a document in response like the following:</p>
<pre>HTTP/1.1 200 OK
Date: Tue, 16 Dec 2014 03:00:12 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json;charset=ISO-8859-1
Content-Language: en-US
Content-Length: 333
Connection: close
{
"sub": "6WZQPpnQxV",
"iss": "https://idp-p.example.com"
"given_name": "Stephen",
"family_name": "Emeritus",
}
</pre>
<p id="rfc.section.5.p.4">Servers MUST support the generation of <a href="#RFC7519">JWT</a> <cite title="NONE">[RFC7519]</cite> encoded responses from the UserInfo Endpoint in addition to unsigned JSON objects. Signed responses MUST be signed by the OpenID Provider's key, and encrypted responses MUST be encrypted with the authorized client's key. The OpenID Provider MUST support the RS256 signature method (the Rivest, Shamir, and Adleman (RSA) signature algorithm with a 256-bit hash) and MAY use other asymmetric signature and encryption methods listed in the JSON Web Algorithms (<a href="#RFC7518">JWA</a> <cite title="NONE">[RFC7518]</cite>) specification.</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#RequestObjects" id="RequestObjects">Request Objects</a></h1>
<p id="rfc.section.6.p.1">Clients MAY optionally send requests to the authorization endpoint as signed or encrypted request objects using the <samp>request</samp> parameter as defined by <a href="#OpenID.Core">OpenID Connect</a> <cite title="NONE">[OpenID.Core]</cite>. Servers MUST accept requests containing a request object signed by the client's private key. Servers MUST validate the signature on such requests against the client's registered public key. Clients must register their keys during client registration as described in the HEART <a href="#HEART.OAuth2">OAuth 2.0</a> <cite title="NONE">[HEART.OAuth2]</cite> profile. Servers MUST accept request objects encrypted with the server's public key.</p>
<p id="rfc.section.6.p.2">Servers MAY accept request objects by reference using the <samp>request_uri</samp> parameter.</p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#AuthenticationContext" id="AuthenticationContext">Authentication Context</a></h1>
<p id="rfc.section.7.p.1">OpenID Providers MUST provide <samp>acr</samp> (authentication context class reference, equivalent to the Security Assertion Markup Language (SAML) element of the same name) and <samp>amr</samp> (authentication methods reference) values in ID tokens.</p>
<p id="rfc.section.7.p.2">It is recommended that both FICAM and eIDAS levels of assurance are supported in the authentication context by default.</p>
<p id="rfc.section.7.p.3">Current NIST Levels of Assurance:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>NIST Levels of Assurance</caption>
<thead>
<tr>
<th class="left">NIST LoA</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">http://idmanagement.gov/ns/assurance/loa/1</td>
</tr>
<tr>
<td class="left">http://idmanagement.gov/ns/assurance/loa/2</td>
</tr>
<tr>
<td class="left">http://idmanagement.gov/ns/assurance/loa/3</td>
</tr>
</tbody>
</table>
<p id="rfc.section.7.p.4">Current eIDAS Levels of Assurance:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>eIDAS Levels of Assurance</caption>
<thead>
<tr>
<th class="left">eIDAS LoA</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">http://eidas.europa.eu/LoA/low</td>
</tr>
<tr>
<td class="left">http://eidas.europa.eu/LoA/substantial</td>
</tr>
<tr>
<td class="left">http://eidas.europa.eu/LoA/high</td>
</tr>
</tbody>
</table>
<p id="rfc.section.7.p.5">There is no requirement for authentication methods to be described in the Authentication Context as standards for levels of assurance should be outcome based. This also removes the requirement for RPs and IDPs to have a shared understanding of the authentication method values.</p>
<p id="rfc.section.7.p.6">Note that OpenID Connect cannot provide LOA 4 identity assertions due to the way that the FICAM LOA values are currently defined.<a href="#RFC7800">Proof-of-Possession Key Semantics for JWTs</a> <cite title="NONE">[RFC7800]</cite> may provide a mechanism to verify user keys.</p>
<p id="rfc.section.7.p.7">The <samp>amr</samp> value is an array of strings describing the set of mechanisms used to authenticate the user to the OpenID Provider. Providers that require multi-factor authentication will typically provide multiple values (for example, memorized password plus hardware-token-generated one-time password). The specific values MUST be agreed upon and understood between the OpenID Provider and any Relying Parties.</p>
<p id="rfc.section.7.p.8">In the future, this profile will likely reference and make use of the draft <a href="#I-D.richer-vectors-of-trust">Vectors of Trust</a> <cite title="NONE">[I-D.richer-vectors-of-trust]</cite> standard.</p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#Discovery" id="Discovery">Discovery</a></h1>
<p id="rfc.section.8.p.1">All OpenID Connect servers are uniquely identified by a URL known as the <samp>issuer</samp>. This URL serves as the prefix of a service discovery endpoint as specified in the <a href="#OpenID.Discovery">OpenID Connect Discovery standard</a> <cite title="NONE">[OpenID.Discovery]</cite>. The discovery document MUST contain at minimum the following fields:</p>
<p/>
<dl>
<dt>issuer</dt>
<dd style="margin-left: 8">The fully qualified issuer URL of the server</dd>
<dt>authorization_endpoint</dt>
<dd style="margin-left: 8">The fully qualified URL of the server's authorization endpoint defined by <a href="#RFC6749">[RFC6749]</a></dd>
<dt>token_endpoint</dt>
<dd style="margin-left: 8">The fully qualified URL of the server's token endpoint defined by <a href="#RFC6749">[RFC6749]</a></dd>
<dt>introspection_endpoint</dt>
<dd style="margin-left: 8">The fully qualified URL of the server's introspection endpoint defined by <a href="#RFC7662">OAuth Token Introspection</a> <cite title="NONE">[RFC7662]</cite></dd>
<dt>revocation_endpoint</dt>
<dd style="margin-left: 8">The fully qualified URL of the server's revocation endpoint defined by <a href="#RFC7009">OAuth Token Revocation</a> <cite title="NONE">[RFC7009]</cite></dd>
<dt>jwks_uri</dt>
<dd style="margin-left: 8">The fully qualified URI of the server's public key in <a href="#RFC7517">JWK Set</a> <cite title="NONE">[RFC7517]</cite> format</dd>
</dl>
<p id="rfc.section.8.p.3">The following example shows the JSON document found at a discovery endpoint for an authorization server:</p>
<pre>{
"request_parameter_supported": true,
"id_token_encryption_alg_values_supported": [
"RSA-OAEP", "RSA1_5", "RSA-OAEP-256"
],
"registration_endpoint": "https://idp-p.example.com/register",
"userinfo_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
],
"token_endpoint": "https://idp-p.example.com/token",
"request_uri_parameter_supported": false,
"request_object_encryption_enc_values_supported": [
"A192CBC-HS384", "A192GCM", "A256CBC+HS512",
"A128CBC+HS256", "A256CBC-HS512",
"A128CBC-HS256", "A128GCM", "A256GCM"
],
"token_endpoint_auth_methods_supported": [
"private_key_jwt",
],
"userinfo_encryption_alg_values_supported": [
"RSA-OAEP", "RSA1_5",
"RSA-OAEP-256"
],
"subject_types_supported": [
"public", "pairwise"
],
"id_token_encryption_enc_values_supported": [
"A192CBC-HS384", "A192GCM", "A256CBC+HS512",
"A128CBC+HS256", "A256CBC-HS512", "A128CBC-HS256",
"A128GCM", "A256GCM"
],
"claims_parameter_supported": false,
"jwks_uri": "https://idp-p.example.com/jwk",
"id_token_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "none"
],
"authorization_endpoint": "https://idp-p.example.com/authorize",
"require_request_uri_registration": false,
"introspection_endpoint": "https://idp-p.example.com/introspect",
"request_object_encryption_alg_values_supported": [
"RSA-OAEP", ?RSA1_5", "RSA-OAEP-256"
],
"service_documentation": "https://idp-p.example.com/about",
"response_types_supported": [
"code", "token"
],
"token_endpoint_auth_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
],
"revocation_endpoint": "https://idp-p.example.com/revoke",
"request_object_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
],
"claim_types_supported": [
"normal"
],
"grant_types_supported": [
"authorization_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer",
],
"scopes_supported": [
],
"userinfo_endpoint": "https://idp-p.example.com/userinfo",
"userinfo_encryption_enc_values_supported": [
"A192CBC-HS384", "A192GCM", "A256CBC+HS512","A128CBC+HS256",
"A256CBC-HS512", "A128CBC-HS256", "A128GCM", "A256GCM"
],
"op_tos_uri": "https://idp-p.example.com/about",
"issuer": "https://idp-p.example.com/",
"op_policy_uri": "https://idp-p.example.com/about",
"claims_supported": [
"sub", "name", "preferred_username", "given_name", "family_name",
"middle_name", "nickname", "profile", "picture", "website",
"gender", "zone_info", "locale", "updated_time", "birthdate",
"email", "email_verified", "phone_number", "address"
]
}
</pre>
<p id="rfc.section.8.p.4">Clients and protected resources SHOULD cache this discovery information. It is RECOMMENDED that servers provide cache information through HTTP headers and make the cache valid for at least one week.</p>
<p id="rfc.section.8.p.5">The server MUST provide its public key in <a href="#RFC7517">JWK Set</a> <cite title="NONE">[RFC7517]</cite> format, such as the following 2048-bit RSA key:</p>
<pre>{
"keys": [
{
"alg": "RS256",
"e": "AQAB",
"n": "o80vbR0ZfMhjZWfqwPUGNkcIeUcweFyzB2S2T-hje83IOVct8gVg9FxvHPK1ReEW3-p7-A8GNcLAuFP_8jPhiL6LyJC3F10aV9KPQFF-w6Eq6VtpEgYSfzvFegNiPtpMWd7C43EDwjQ-GrXMVCLrBYxZC-P1ShyxVBOzeR_5MTC0JGiDTecr_2YT6o_3aE2SIJu4iNPgGh9MnyxdBo0Uf0TmrqEIabquXA1-V8iUihwfI8qjf3EujkYi7gXXelIo4_gipQYNjr4DBNlE0__RI0kDU-27mb6esswnP2WgHZQPsk779fTcNDBIcYgyLujlcUATEqfCaPDNp00J6AbY6w",
"kty": "RSA",
"kid": "rsa1"
}
]
}
</pre>
<p id="rfc.section.8.p.6">Clients and protected resources SHOULD cache this key. It is RECOMMENDED that servers provide cache information through HTTP headers and make the cache valid for at least one week.</p>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#ScopeProfiles" id="ScopeProfiles">Scope Profiles (UserInfo Attributes</a></h1>
<p id="rfc.section.9.p.1">In the interests of data minimisation balanced with the requirement to successfully identity the individual signing in to a service the default OpenID Connect profiles may not be appropriate.</p>
<p id="rfc.section.9.p.2">Matching of the identity assertion based on claims to a local identifier or ‘account’ related to the individual identity at a level of assurance is a requirement where the government in question is not able to provide a single identifier for all citizens based on an authoritative register of citizens.</p>
<p id="rfc.section.9.p.3">The requirement for matching is also of importance where a cross-border or cross-jurisdiction authentication is required and therefore the availability of a single identifier (e.g. social security number) cannot be guaranteed for the individual wishing to authenticate.</p>
<p id="rfc.section.9.p.4">This standard will define a set of common <samp>scope</samp> values that aim to provide maximum cross-jurisdictional identity matching while not being perscriptive on the exact attributes shared, as every jurisdiction will likely have varius levels of information available, and different policies for sharing personal data even if it is on file.</p>
<p/>
<dl>
<dt>basic</dt>
<dd style="margin-left: 8">Basic identity information that provides a baseline profile: <samp>name, current address, date of birth, and (optional) gender.</samp></dd>
<dt>document</dt>
<dd style="margin-left: 8">The identity document type and "number" the OP is capable of providing. This could be passport, driver's license, national ID card, health insurance no., and so on. The response should include: <samp>type, number</samp>.</dd>
<dt>biometric</dt>
<dd style="margin-left: 8">Biometric data related to the subject for verification at the client side. This can include simple descriptions for eye and hair color, height, or may include a photograph or some verifiable fingerprint/iris scan data.</dd>
</dl>
<h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> Security Considerations</h1>
<p id="rfc.section.10.p.1">All transactions MUST be protected in transit by TLS as described in <a href="#BCP195">BCP195</a> <cite title="NONE">[BCP195]</cite>.</p>
<p id="rfc.section.10.p.2">All clients MUST conform to applicable recommendations found in the Security Considerations sections of <a href="#RFC6749">[RFC6749]</a> and those found in the <a href="#RFC6819">OAuth 2.0 Threat Model and Security Considerations document</a> <cite title="NONE">[RFC6819]</cite>.</p>
<h1 id="rfc.references"><a href="#rfc.references">11.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="BCP195">[BCP195]</b>
</td>
<td class="top"><a>Sheffer, Y.</a>, <a>Holz, R.</a> and <a>P. Saint-Andre</a>, "<a href="http://tools.ietf.org/html/rfc7525">Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</a>", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="HEART.OAuth2">[HEART.OAuth2]</b>
</td>
<td class="top"><a href="mailto:openid@justin.richer.org">Richer, J.</a>, "<a href="http://openid.net/specs/openid-heart-oauth2-1_0.html">Health Relationship Trust Profile for OAuth 2.0</a>", February 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="I-D.ietf-oauth-pop-architecture">[I-D.ietf-oauth-pop-architecture]</b>
</td>
<td class="top"><a>Hunt, P.</a>, <a>Richer, J.</a>, <a>Mills, W.</a>, <a>Mishra, P.</a> and <a>H. Tschofenig</a>, "<a href="http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08">OAuth 2.0 Proof-of-Possession (PoP) Security Architecture</a>", Internet-Draft draft-ietf-oauth-pop-architecture-08, July 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="I-D.richer-vectors-of-trust">[I-D.richer-vectors-of-trust]</b>
</td>
<td class="top"><a>Richer, J.</a> and <a>L. Johansson</a>, "<a href="http://tools.ietf.org/html/draft-richer-vectors-of-trust-03">Vectors of Trust</a>", Internet-Draft draft-richer-vectors-of-trust-03, July 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Core">[OpenID.Core]</b>
</td>
<td class="top"><a title="Nomura Research Institute, Ltd.">Sakimura, N.</a>, <a title="Ping Identity">Bradley, J.</a>, <a title="Microsoft">Jones, M.</a>, <a title="Google">de Medeiros, B.</a> and <a title="Salesforce">C. Mortimore</a>, "<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</a>", August 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Discovery">[OpenID.Discovery]</b>
</td>
<td class="top"><a title="Nomura Research Institute, Ltd.">Sakimura, N.</a>, <a title="Ping Identity">Bradley, J.</a>, <a title="Microsoft">Jones, M.</a> and <a title="Illumila">E. Jay</a>, "<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>", August 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a>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, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2246">[RFC2246]</b>
</td>
<td class="top"><a>Dierks, T.</a> and <a>C. Allen</a>, "<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>", RFC 2246, DOI 10.17487/RFC2246, January 1999.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC3986">[RFC3986]</b>
</td>
<td class="top"><a>Berners-Lee, T.</a>, <a>Fielding, R.</a> and <a>L. Masinter</a>, "<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5246">[RFC5246]</b>
</td>
<td class="top"><a>Dierks, T.</a> and <a>E. Rescorla</a>, "<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>", RFC 5246, DOI 10.17487/RFC5246, August 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5322">[RFC5322]</b>
</td>
<td class="top"><a>Resnick, P.</a>, "<a href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>", RFC 5322, DOI 10.17487/RFC5322, October 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5646">[RFC5646]</b>
</td>
<td class="top"><a>Phillips, A.</a> and <a>M. Davis</a>, "<a href="http://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5785">[RFC5785]</b>
</td>
<td class="top"><a>Nottingham, M.</a> and <a>E. Hammer-Lahav</a>, "<a href="http://tools.ietf.org/html/rfc5785">Defining Well-Known Uniform Resource Identifiers (URIs)</a>", RFC 5785, DOI 10.17487/RFC5785, April 2010.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6125">[RFC6125]</b>
</td>
<td class="top"><a>Saint-Andre, P.</a> and <a>J. Hodges</a>, "<a href="http://tools.ietf.org/html/rfc6125">Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>", RFC 6125, DOI 10.17487/RFC6125, March 2011.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6749">[RFC6749]</b>
</td>
<td class="top"><a>Hardt, D.</a>, "<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", RFC 6749, DOI 10.17487/RFC6749, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6750">[RFC6750]</b>
</td>
<td class="top"><a>Jones, M.</a> and <a>D. Hardt</a>, "<a href="http://tools.ietf.org/html/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>", RFC 6750, DOI 10.17487/RFC6750, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6819">[RFC6819]</b>
</td>
<td class="top"><a>Lodderstedt, T.</a>, <a>McGloin, M.</a> and <a>P. Hunt</a>, "<a href="http://tools.ietf.org/html/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>", RFC 6819, DOI 10.17487/RFC6819, January 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7009">[RFC7009]</b>
</td>
<td class="top"><a>Lodderstedt, T.</a>, <a>Dronia, S.</a> and <a>M. Scurtescu</a>, "<a href="http://tools.ietf.org/html/rfc7009">OAuth 2.0 Token Revocation</a>", RFC 7009, DOI 10.17487/RFC7009, August 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7033">[RFC7033]</b>
</td>
<td class="top"><a>Jones, P.</a>, <a>Salgueiro, G.</a>, <a>Jones, M.</a> and <a>J. Smarr</a>, "<a href="http://tools.ietf.org/html/rfc7033">WebFinger</a>", RFC 7033, DOI 10.17487/RFC7033, September 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7515">[RFC7515]</b>
</td>
<td class="top"><a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="http://tools.ietf.org/html/rfc7515">JSON Web Signature (JWS)</a>", RFC 7515, DOI 10.17487/RFC7515, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7516">[RFC7516]</b>
</td>
<td class="top"><a>Jones, M.</a> and <a>J. Hildebrand</a>, "<a href="http://tools.ietf.org/html/rfc7516">JSON Web Encryption (JWE)</a>", RFC 7516, DOI 10.17487/RFC7516, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7517">[RFC7517]</b>
</td>
<td class="top"><a>Jones, M.</a>, "<a href="http://tools.ietf.org/html/rfc7517">JSON Web Key (JWK)</a>", RFC 7517, DOI 10.17487/RFC7517, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7518">[RFC7518]</b>
</td>
<td class="top"><a>Jones, M.</a>, "<a href="http://tools.ietf.org/html/rfc7518">JSON Web Algorithms (JWA)</a>", RFC 7518, DOI 10.17487/RFC7518, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7519">[RFC7519]</b>
</td>
<td class="top"><a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="http://tools.ietf.org/html/rfc7519">JSON Web Token (JWT)</a>", RFC 7519, DOI 10.17487/RFC7519, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7662">[RFC7662]</b>
</td>
<td class="top"><a>Richer, J.</a>, "<a href="http://tools.ietf.org/html/rfc7662">OAuth 2.0 Token Introspection</a>", RFC 7662, DOI 10.17487/RFC7662, October 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7800">[RFC7800]</b>
</td>
<td class="top"><a>Jones, M.</a>, <a>Bradley, J.</a> and <a>H. Tschofenig</a>, "<a href="http://tools.ietf.org/html/rfc7800">Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)</a>", RFC 7800, DOI 10.17487/RFC7800, April 2016.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> <a href="#Acknowledgements" id="Acknowledgements">Acknowledgements</a></h1>
<p id="rfc.section.A.p.1">The OpenID Community would like to thank the following people for their contributions to this specification: Justin Ritcher, Paul Grassi, John Bradley, Adam Cooper, ... </p>
<h1 id="rfc.appendix.B"><a href="#rfc.appendix.B">Appendix B.</a> <a href="#Notices" id="Notices">Notices</a></h1>
<p id="rfc.section.B.p.1">Copyright (c) 2015 The OpenID Foundation.</p>
<p id="rfc.section.B.p.2">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 id="rfc.section.B.p.3">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>
<h1 id="rfc.appendix.C"><a href="#rfc.appendix.C">Appendix C.</a> <a href="#History" id="History">Document History</a></h1>
<p id="rfc.section.C.p.1">-2016-07-25</p>
<p/>
<ul>
<li>Imported content from OpenID HEART 1.0 profile and Connect.Gov integration guide v 1.4</li>
</ul>
<h1 id="rfc.authors">
<a href="#rfc.authors">Author's Address</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Michael Varley</span> (editor)
<span class="n hidden">
<span class="family-name">Varley</span>
</span>
</span>
<span class="org vcardline"></span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:mike.varley@securekey.com">mike.varley@securekey.com</a></span>
</address>
</div>
</body>
</html>