<!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>OpenID Connect 1.0 - Final draft-01</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
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";3
}
@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.2" rel="Chapter" title="2 Terminology"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Authorization Endpoint"/>
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Request Parameters"/>
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Server Processings"/>
<link href="#rfc.section.3.2.1" rel="Chapter" title="3.2.1 ID Token"/>
<link href="#rfc.section.3.3" rel="Chapter" title="3.3 Authorization Response"/>
<link href="#rfc.section.3.3.1" rel="Chapter" title="3.3.1 Case: response_type=code"/>
<link href="#rfc.section.3.3.2" rel="Chapter" title="3.3.2 Case: response_type=id_token"/>
<link href="#rfc.section.3.3.3" rel="Chapter" title="3.3.3 Case: response_type=token id_token"/>
<link href="#rfc.section.3.3.4" rel="Chapter" title="3.3.4 Authorization Error Response"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Token Endpoint"/>
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Access Token Response"/>
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 ID Token Validation"/>
<link href="#rfc.section.5" rel="Chapter" title="5 (OPTIONAL) UserInfo Endpoint"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 UserInfo Request"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 UserInfo Response"/>
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 UserInfo Error Response"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Scope Values"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Subject Identifier Types"/>
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Pairwise Identifier Algorithm"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Standard Claims"/>
<link href="#rfc.section.8.1" rel="Chapter" title="8.1 Address Claim"/>
<link href="#rfc.section.8.2" rel="Chapter" title="8.2 Claims Languages and Scripts"/>
<link href="#rfc.section.8.3" rel="Chapter" title="8.3 Claim Stability and Uniqueness"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Signatures and Encryption"/>
<link href="#rfc.section.9.1" rel="Chapter" title="9.1 Supported Algorithms"/>
<link href="#rfc.section.9.2" rel="Chapter" title="9.2 Keys"/>
<link href="#rfc.section.9.3" rel="Chapter" title="9.3 Signing"/>
<link href="#rfc.section.9.3.1" rel="Chapter" title="9.3.1 Rotation of Asymmetric Signing Keys"/>
<link href="#rfc.section.9.4" rel="Chapter" title="9.4 Encryption"/>
<link href="#rfc.section.9.4.1" rel="Chapter" title="9.4.1 Rotation of Asymmetric Encryption Keys"/>
<link href="#rfc.section.10" rel="Chapter" title="10 Serializations"/>
<link href="#rfc.section.10.1" rel="Chapter" title="10.1 Query String Serialization"/>
<link href="#rfc.section.10.2" rel="Chapter" title="10.2 Form Serialization"/>
<link href="#rfc.section.11" rel="Chapter" title="11 String Operations"/>
<link href="#rfc.section.12" rel="Chapter" title="12 TLS Version"/>
<link href="#rfc.section.13" rel="Chapter" title="13 Implementation Considerations"/>
<link href="#rfc.section.13.1" rel="Chapter" title="13.1 Mandatory to Implement Features for All OpenID Providers"/>
<link href="#rfc.section.13.2" rel="Chapter" title="13.2 Mandatory to Implement Features for Dynamic OpenID Providers"/>
<link href="#rfc.section.13.3" rel="Chapter" title="13.3 Related Specifications"/>
<link href="#rfc.section.14" rel="Chapter" title="14 Security Considerations"/>
<link href="#rfc.section.14.1" rel="Chapter" title="14.1 Request Disclosure"/>
<link href="#rfc.section.14.2" rel="Chapter" title="14.2 Server Masquerading"/>
<link href="#rfc.section.14.3" rel="Chapter" title="14.3 Token Manufacture/Modification"/>
<link href="#rfc.section.14.4" rel="Chapter" title="14.4 Server Response Disclosure"/>
<link href="#rfc.section.14.5" rel="Chapter" title="14.5 Server Response Repudiation"/>
<link href="#rfc.section.14.6" rel="Chapter" title="14.6 Request Repudiation"/>
<link href="#rfc.section.14.7" rel="Chapter" title="14.7 Access Token Redirect"/>
<link href="#rfc.section.14.8" rel="Chapter" title="14.8 Token Reuse"/>
<link href="#rfc.section.14.9" rel="Chapter" title="14.9 Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)"/>
<link href="#rfc.section.14.10" rel="Chapter" title="14.10 Token Substitution"/>
<link href="#rfc.section.14.11" rel="Chapter" title="14.11 Timing Attack"/>
<link href="#rfc.section.14.12" rel="Chapter" title="14.12 Other Crypto Related Attacks"/>
<link href="#rfc.section.14.13" rel="Chapter" title="14.13 Signing and Encryption Order"/>
<link href="#rfc.section.14.14" rel="Chapter" title="14.14 Issuer Identifier"/>
<link href="#rfc.section.14.15" rel="Chapter" title="14.15 TLS Requirements"/>
<link href="#rfc.section.14.16" rel="Chapter" title="14.16 Lifetimes of Access Tokens and Refresh Tokens"/>
<link href="#rfc.section.14.17" rel="Chapter" title="14.17 Symmetric Key Entropy"/>
<link href="#rfc.section.14.18" rel="Chapter" title="14.18 Need for Signed Requests"/>
<link href="#rfc.section.14.19" rel="Chapter" title="14.19 Need for Encrypted Requests"/>
<link href="#rfc.section.15" rel="Chapter" title="15 Privacy Considerations"/>
<link href="#rfc.section.15.1" rel="Chapter" title="15.1 Personally Identifiable Information"/>
<link href="#rfc.section.15.2" rel="Chapter" title="15.2 Data Access Monitoring"/>
<link href="#rfc.section.15.3" rel="Chapter" title="15.3 Correlation"/>
<link href="#rfc.section.15.4" rel="Chapter" title="15.4 Offline Access"/>
<link href="#rfc.section.16" rel="Chapter" title="16 IANA Considerations"/>
<link href="#rfc.section.16.1" rel="Chapter" title="16.1 JSON Web Token Claims Registry"/>
<link href="#rfc.section.16.1.1" rel="Chapter" title="16.1.1 Registry Contents"/>
<link href="#rfc.section.16.2" rel="Chapter" title="16.2 OAuth Parameters Registry"/>
<link href="#rfc.section.16.2.1" rel="Chapter" title="16.2.1 Registry Contents"/>
<link href="#rfc.section.16.3" rel="Chapter" title="16.3 OAuth Extensions Error Registry"/>
<link href="#rfc.section.16.3.1" rel="Chapter" title="16.3.1 Registry Contents"/>
<link href="#rfc.references" rel="Chapter" title="17 References"/>
<link href="#rfc.references.1" rel="Chapter" title="17.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="17.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
<link href="#rfc.appendix.B" rel="Chapter" title="B Notices"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.4.2 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore" />
<meta name="dct.identifier" content="urn:ietf:id:openid-connect-1_0" />
<meta name="dct.issued" scheme="ISO8601" content="2013-7-31" />
<meta name="dct.abstract" content="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 REST-like manner." />
<meta name="description" content="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 REST-like manner." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">OpenID Connect Working Group</td>
<td class="right">N. Sakimura</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">NRI</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">J. Bradley</td>
</tr>
<tr>
<td class="left">Expires: February 01, 2014</td>
<td class="right">Ping Identity</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">M. Jones</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Microsoft</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">B. de Medeiros</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Google</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">C. Mortimore</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Salesforce</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">July 31, 2013</td>
</tr>
</tbody>
</table>
<p class="title">OpenID Connect 1.0 - Final draft-01<br />
<span class="filename">openid-connect-1_0</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<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 REST-like manner.</p>
<p>OpenID Connect Code Grant Server 1.0 defines how to perform authentication using OAuth <samp>authorization_code</samp> grant type.</p>
<p>OpenID Providers and non-Web-based applications should instead consult the Messages and Standard specifications.</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>
<li>1.1. <a href="#rfc.section.1.1">Requirements Notation and Conventions</a></li>
<li>2. <a href="#rfc.section.2">Terminology</a></li>
<li>3. <a href="#rfc.section.3">Authorization Endpoint</a></li>
<li>3.1. <a href="#rfc.section.3.1">Request Parameters</a></li>
<li>3.2. <a href="#rfc.section.3.2">Server Processings</a></li>
<li>3.2.1. <a href="#rfc.section.3.2.1">ID Token</a></li>
<li>3.3. <a href="#rfc.section.3.3">Authorization Response</a></li>
<li>3.3.1. <a href="#rfc.section.3.3.1">Case: response_type=code</a></li>
<li>3.3.2. <a href="#rfc.section.3.3.2">Case: response_type=id_token</a></li>
<li>3.3.3. <a href="#rfc.section.3.3.3">Case: response_type=token id_token</a></li>
<li>3.3.4. <a href="#rfc.section.3.3.4">Authorization Error Response</a></li>
<li>4. <a href="#rfc.section.4">Token Endpoint</a></li>
<li>4.1. <a href="#rfc.section.4.1">Access Token Response</a></li>
<li>4.2. <a href="#rfc.section.4.2">ID Token Validation</a></li>
<li>5. <a href="#rfc.section.5">(OPTIONAL) UserInfo Endpoint</a></li>
<li>5.1. <a href="#rfc.section.5.1">UserInfo Request</a></li>
<li>5.2. <a href="#rfc.section.5.2">UserInfo Response</a></li>
<li>5.3. <a href="#rfc.section.5.3">UserInfo Error Response</a></li>
<li>6. <a href="#rfc.section.6">Scope Values</a></li>
<li>7. <a href="#rfc.section.7">Subject Identifier Types</a></li>
<li>7.1. <a href="#rfc.section.7.1">Pairwise Identifier Algorithm</a></li>
<li>8. <a href="#rfc.section.8">Standard Claims</a></li>
<li>8.1. <a href="#rfc.section.8.1">Address Claim</a></li>
<li>8.2. <a href="#rfc.section.8.2">Claims Languages and Scripts</a></li>
<li>8.3. <a href="#rfc.section.8.3">Claim Stability and Uniqueness</a></li>
<li>9. <a href="#rfc.section.9">Signatures and Encryption</a></li>
<li>9.1. <a href="#rfc.section.9.1">Supported Algorithms</a></li>
<li>9.2. <a href="#rfc.section.9.2">Keys</a></li>
<li>9.3. <a href="#rfc.section.9.3">Signing</a></li>
<li>9.3.1. <a href="#rfc.section.9.3.1">Rotation of Asymmetric Signing Keys</a></li>
<li>9.4. <a href="#rfc.section.9.4">Encryption</a></li>
<li>9.4.1. <a href="#rfc.section.9.4.1">Rotation of Asymmetric Encryption Keys</a></li>
<li>10. <a href="#rfc.section.10">Serializations</a></li>
<li>10.1. <a href="#rfc.section.10.1">Query String Serialization</a></li>
<li>10.2. <a href="#rfc.section.10.2">Form Serialization</a></li>
<li>11. <a href="#rfc.section.11">String Operations</a></li>
<li>12. <a href="#rfc.section.12">TLS Version</a></li>
<li>13. <a href="#rfc.section.13">Implementation Considerations</a></li>
<li>13.1. <a href="#rfc.section.13.1">Mandatory to Implement Features for All OpenID Providers</a></li>
<li>13.2. <a href="#rfc.section.13.2">Mandatory to Implement Features for Dynamic OpenID Providers</a></li>
<li>13.3. <a href="#rfc.section.13.3">Related Specifications</a></li>
<li>14. <a href="#rfc.section.14">Security Considerations</a></li>
<li>14.1. <a href="#rfc.section.14.1">Request Disclosure</a></li>
<li>14.2. <a href="#rfc.section.14.2">Server Masquerading</a></li>
<li>14.3. <a href="#rfc.section.14.3">Token Manufacture/Modification</a></li>
<li>14.4. <a href="#rfc.section.14.4">Server Response Disclosure</a></li>
<li>14.5. <a href="#rfc.section.14.5">Server Response Repudiation</a></li>
<li>14.6. <a href="#rfc.section.14.6">Request Repudiation</a></li>
<li>14.7. <a href="#rfc.section.14.7">Access Token Redirect</a></li>
<li>14.8. <a href="#rfc.section.14.8">Token Reuse</a></li>
<li>14.9. <a href="#rfc.section.14.9"> Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)</a></li>
<li>14.10. <a href="#rfc.section.14.10">Token Substitution</a></li>
<li>14.11. <a href="#rfc.section.14.11">Timing Attack</a></li>
<li>14.12. <a href="#rfc.section.14.12">Other Crypto Related Attacks</a></li>
<li>14.13. <a href="#rfc.section.14.13">Signing and Encryption Order</a></li>
<li>14.14. <a href="#rfc.section.14.14">Issuer Identifier</a></li>
<li>14.15. <a href="#rfc.section.14.15">TLS Requirements</a></li>
<li>14.16. <a href="#rfc.section.14.16">Lifetimes of Access Tokens and Refresh Tokens</a></li>
<li>14.17. <a href="#rfc.section.14.17">Symmetric Key Entropy</a></li>
<li>14.18. <a href="#rfc.section.14.18">Need for Signed Requests</a></li>
<li>14.19. <a href="#rfc.section.14.19">Need for Encrypted Requests</a></li>
<li>15. <a href="#rfc.section.15">Privacy Considerations</a></li>
<li>15.1. <a href="#rfc.section.15.1">Personally Identifiable Information</a></li>
<li>15.2. <a href="#rfc.section.15.2">Data Access Monitoring</a></li>
<li>15.3. <a href="#rfc.section.15.3">Correlation</a></li>
<li>15.4. <a href="#rfc.section.15.4">Offline Access</a></li>
<li>16. <a href="#rfc.section.16">IANA Considerations</a></li>
<li>16.1. <a href="#rfc.section.16.1">JSON Web Token Claims Registry</a></li>
<li>16.1.1. <a href="#rfc.section.16.1.1">Registry Contents</a></li>
<li>16.2. <a href="#rfc.section.16.2">OAuth Parameters Registry</a></li>
<li>16.2.1. <a href="#rfc.section.16.2.1">Registry Contents</a></li>
<li>16.3. <a href="#rfc.section.16.3">OAuth Extensions Error Registry</a></li>
<li>16.3.1. <a href="#rfc.section.16.3.1">Registry Contents</a></li>
<li>17. <a href="#rfc.references">References</a></li>
<li>17.1. <a href="#rfc.references.1">Normative References</a></li>
<li>17.2. <a href="#rfc.references.2">Informative 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><a href="#rfc.authors">Authors' Addresses</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">OpenID Connect 1.0 defines how to perfom federated login using OAuth 2.0. It does so by extending Authorization Endoint and Token Endpoint by defining standardized scope and a new token type called ID Token.</p>
<p id="rfc.section.1.p.2">As this specification is built on top of OAuth 2.0, the readers are expected to be familiar witth OAuth 2.0 to read this specification.</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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119">[RFC2119]</a>.</p>
<p id="rfc.section.1.1.p.2">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>
<p id="rfc.section.1.1.p.3">All uses of <a href="#JWS">JSON Web Signature (JWS)</a> <cite title="NONE">[JWS]</cite> data structures in this specification utilize the JWS Compact Serialization; the JWS JSON Serialization is not used.</p>
<p id="rfc.section.1.1.p.4">When the RFC 2119 language applies to the behavior of OpenID Providers, it is in this specification for explanatory value to help Client implementers understand the expected behavior of OpenID Providers.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#terminology" id="terminology">Terminology</a></h1>
<p id="rfc.section.2.p.1">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 href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite>.</p>
<p id="rfc.section.2.p.2">This specification also defines the following terms: </p>
<dl>
<dt>Claim</dt>
<dd style="margin-left: 8">Piece of information asserted about an Entity.</dd>
<dt>Claims Provider</dt>
<dd style="margin-left: 8">Server that can return Claims about an Entity.</dd>
<dt>End-User</dt>
<dd style="margin-left: 8">Human Resource Owner.</dd>
<dt>Entity</dt>
<dd style="margin-left: 8">Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity.</dd>
<dt>ID Token</dt>
<dd style="margin-left: 8"><a href="#JWT">JSON Web Token (JWT)</a> <cite title="NONE">[JWT]</cite> that contains Claims about the authentication event. It MAY contain other Claims.</dd>
<dt>Identifier</dt>
<dd style="margin-left: 8">Value that uniquely characterizes an Entity in a specific context.</dd>
<dt>Issuer</dt>
<dd style="margin-left: 8">Entity that issues a set of Claims.</dd>
<dt>Issuer Identifier</dt>
<dd style="margin-left: 8">Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the <samp>https</samp> scheme that contains scheme, host, and OPTIONALLY, port number and path components and no query or fragment components.</dd>
<dt>OpenID Provider (OP)</dt>
<dd style="margin-left: 8">OAuth 2.0 Authorization Server that is capable of providing Claims to a Relying Party.</dd>
<dt>Pairwise Pseudonymous Identifier (PPID)</dt>
<dd style="margin-left: 8">Identifier that identifies the Entity to a Relying Party that cannot be correlated with the Entity's PPID at another Relying Party.</dd>
<dt>Personally Identifiable Information (PII)</dt>
<dd style="margin-left: 8">Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates.</dd>
<dt>Relying Party (RP)</dt>
<dd style="margin-left: 8">OAuth 2.0 Client application requiring Claims from an OpenID Provider.</dd>
<dt>UserInfo Endpoint</dt>
<dd style="margin-left: 8">Protected resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding Authorization Grant.</dd>
<dt>Validation</dt>
<dd style="margin-left: 8">Process intended to establish the soundness or correctness of a construct.</dd>
<dt>Verification</dt>
<dd style="margin-left: 8">Process intended to test or prove the truth or accuracy of a fact or value.</dd>
<dt>Voluntary Claim</dt>
<dd style="margin-left: 8">Claim specified by the Client as being useful but not Essential for the specific task requested by the End-User.</dd>
</dl>
<p id="rfc.section.2.p.3">IMPORTANT NOTE TO READERS: The terminology definitions in this section are a normative portion of this specification, imposing requirements upon implementations. All the capitalized words in the text of this specification, such as "Issuer Identifier", reference these defined terms. Whenever the reader encounters them, their definitions found in this section must be followed.</p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#authz_ep" id="authz_ep">Authorization Endpoint</a></h1>
<p id="rfc.section.3.p.1">For Authorization Endpoint, OpenID Connect defines a few parameter values for OAuth 2.0 Authorization Request as well as a few extension parameters. Followings are the OAuth 2.0 parameters with some defined values. They are sent to the Authorization Endpoint using HTTPS and the server MUST be able to process these parameters.</p>
<h1 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1.</a> <a href="#RequestParameters" id="RequestParameters">Request Parameters</a></h1>
<p/>
<dl>
<dt>response_type</dt>
<dd style="margin-left: 8">REQUIRED. The value would be one of "<samp>code</samp>", "<samp>id_token</samp>", or "<samp>token id_token</samp>".</dd>
<dt></dt>
<dd style="margin-left: 8">
<dl>
<dt>code</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include an Authorization Code as defined in OAuth 2.0. Both successful and error responses MUST be added as parameters to the query component of the response. All tokens are returned from the Token Endpoint. When used by OpenID Connect, an ID Token is also returned from the Token Endpoint. OpenID Providers that are not Self-Issued OPs MUST support this <samp>response_type</samp>.</dd>
<dt>id_token</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include an ID Token. Both successful and error responses SHOULD be fragment-encoded. OpenID Providers MUST support this <samp>response_type</samp>.</dd>
<dt>token id_token</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include both an Access Token and an ID Token. Both successful and error responses SHOULD be fragment-encoded. OpenID Providers MUST support this <samp>response_type</samp>.</dd>
</dl>
</dd>
<dt></dt>
<dd style="margin-left: 8">All OpenID Providers MUST support the <samp>id_token</samp> response type and all OpenID Providers that are not Self-Issued OPs MUST also support the <samp>id_token token</samp> and <samp>code</samp> response types. Refer to <a href="#OAuth.Responses">[OAuth.Responses]</a> for more details about those response types. </dd>
<dt>client_id</dt>
<dd style="margin-left: 8">REQUIRED. OAuth 2.0 Client Identifier.</dd>
<dt>scope</dt>
<dd style="margin-left: 8">REQUIRED. OpenID Connect requests MUST contain the <samp>openid</samp> scope value. OPTIONAL scope values of <samp>profile</samp>, <samp>email</samp>, <samp>address</samp>, <samp>phone</samp>, and <samp>offline_access</samp> are also defined. See <a href="#scopes">Section 6</a> for more about the scope values defined by this specification.</dd>
<dt>redirect_uri</dt>
<dd style="margin-left: 8">REQUIRED. Redirection URI to which the response will be sent. This MUST be pre-registered with the OpenID Provider. This URI MUST exactly match one of the <samp>redirect_uris</samp> registered for the Client, with the matching performed as described in Section 6.2.1 of <a href="#RFC3986">[RFC3986]</a> (Simple String Comparison). If the Client uses the OAuth implicit grant type, the redirection URI MUST NOT use the <samp>http</samp> scheme unless the Client is a native application, in which case it MAY use the <samp>http:</samp> scheme with <samp>localhost</samp> as the hostname. If the Client only uses the OAuth <samp>authorization_code</samp> grant type, the redirection URI MAY use the <samp>http</samp> scheme, provided that the Client Type is <samp>confidential</samp>, as defined in Section 2.1 of OAuth 2.0.</dd>
<dt>state</dt>
<dd style="margin-left: 8">RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with the browser cookie.</dd>
</dl>
<p>Followings are the extension parameters that this specification defines. </p>
<p/>
<dl>
<dt>nonce</dt>
<dd style="margin-left: 8">OPTIONAL. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authorization Request to the ID Token. Sufficient entropy MUST be present in the <samp>nonce</samp> values used to prevent attackers from guessing values. Use of the nonce is OPTIONAL when using the code flow.</dd>
<dt>display</dt>
<dd style="margin-left: 8">OPTIONAL. ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User. The defined values are: <dl><dt>page</dt><dd style="margin-left: 8">The Authorization Server SHOULD display authentication and consent UI consistent with a full User-Agent page view. If the display parameter is not specified this is the default display mode.</dd><dt>popup</dt><dd style="margin-left: 8">The Authorization Server SHOULD display authentication and consent UI consistent with a popup User-Agent window. The popup User-Agent window SHOULD be 450 pixels wide and 500 pixels tall.</dd><dt>touch</dt><dd style="margin-left: 8">The Authorization Server SHOULD display authentication and consent UI consistent with a device that leverages a touch interface. The Authorization Server MAY attempt to detect the touch device and further customize the interface.</dd><dt>wap</dt><dd style="margin-left: 8">The Authorization Server SHOULD display authentication and consent UI consistent with a "feature phone" type display.</dd></dl></dd>
<dt>prompt</dt>
<dd style="margin-left: 8">OPTIONAL. Space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are: <dl><dt>none</dt><dd style="margin-left: 8">The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if the End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing. This can be used as a method to check for existing authentication and/or consent.</dd><dt>login</dt><dd style="margin-left: 8">The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot prompt the End-User, it MUST return an error.</dd><dt>consent</dt><dd style="margin-left: 8">The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client.</dd><dt>select_account</dt><dd style="margin-left: 8">The Authorization Server SHOULD prompt the End-User to select a user account. This allows an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot prompt the End-User, it MUST return an error.</dd></dl><p> The </p><samp>prompt</samp> parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request. If this parameter contains <samp>none</samp> with any other value, an error is returned.</dd>
<dt>max_age</dt>
<dd style="margin-left: 8">OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. When <samp>max_age</samp> is used, the ID Token returned MUST include an <samp>auth_time</samp> Claim Value.</dd>
<dt>ui_locales</dt>
<dd style="margin-left: 8">OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of <a href="#RFC5646">BCP47</a> <cite title="NONE">[RFC5646]</cite> language tag values, ordered by preference. For instance, the value "fr-CA fr en" represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.</dd>
<dt>claims_locales</dt>
<dd style="margin-left: 8">OPTIONAL. End-User's preferred languages and scripts for Claims being returned, represented as a space-separated list of <a href="#RFC5646">BCP47</a> <cite title="NONE">[RFC5646]</cite> language tag values, ordered by preference. An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.</dd>
<dt>id_token_hint</dt>
<dd style="margin-left: 8">OPTIONAL. Previously issued ID Token passed to the Authorization Server as a hint about the End-User's current or past authenticated session with the Client. This SHOULD be present when <samp>prompt=none</samp> is used. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return a negative response. The Authorization Server need not be listed as an audience of the ID Token when it is used as an <samp>id_token_hint</samp> value.</dd>
<dt>login_hint</dt>
<dd style="margin-left: 8">OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the <samp>phone_number</samp> Claim. The use of this parameter is left to the OP's discretion.</dd>
<dt>acr_values</dt>
<dd style="margin-left: 8">OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the <samp>acr</samp> values that the Authorization Server is being requested to use for processing this authentication request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the <samp>acr</samp> Claim Value, as specified in <a href="#id_token">Section 3.2.1</a>. The <samp>acr</samp> Claim is requested as a Voluntary Claim by this parameter.</dd>
</dl>
<p>Following is a non-normative example using HTTP redirect (with line wraps within values for display purposes only):</p>
<pre>
HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
</pre>
<p class="figure"></p>
<h1 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2.</a> Server Processings</h1>
<p id="rfc.section.3.2.p.1">Upon receipt of the parameters, the server MUST perform the following.</p>
<p/>
<ol>
<li>Check if scope includes openid. If it does not, just proceed with normal OAuth processing;</li>
<li>Authenticate the user and obtain authorization from the user as needed;</li>
<li>Create the id_token;</li>
<li>Find out what response_type the request was using and send the result back accordingly;</li>
</ol>
<h1 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1.</a> <a href="#id_token" id="id_token">ID Token</a></h1>
<p id="rfc.section.3.2.1.p.1">The ID Token is a security token that contains Claims about the authentication event and other requested Claims. The ID Token is represented as a <a href="#JWT">JSON Web Token (JWT)</a> <cite title="NONE">[JWT]</cite>.</p>
<p id="rfc.section.3.2.1.p.2">The ID Token is used to manage the authentication event and user identifier and is scoped to a particular Client via the <samp>aud</samp> (audience) Claim.</p>
<p id="rfc.section.3.2.1.p.3">The following Claims are used within the ID Token and MUST be supported by the server:</p>
<p/>
<dl>
<dt>iss</dt>
<dd style="margin-left: 8">REQUIRED. Issuer Identifier for the Issuer of the response. The <samp>iss</samp> value is a case sensitive URL using the <samp>https</samp> scheme that contains scheme, host, and OPTIONALLY, port number and path components and no query or fragment components.</dd>
<dt>sub</dt>
<dd style="margin-left: 8">REQUIRED. Subject identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., <samp>24400320</samp> or <samp>AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</samp>. It MUST NOT exceed 255 ASCII characters in length. The <samp>sub</samp> value is a case sensitive string.</dd>
<dt>aud</dt>
<dd style="margin-left: 8">REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 <samp>client_id</samp> of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the <samp>aud</samp> value is an array of case sensitive strings. In the special case when there is one audience, the <samp>aud</samp> value MAY be a single case sensitive string.</dd>
<dt>exp</dt>
<dd style="margin-left: 8">REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. The time is represented as the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. See <a href="#RFC3339">RFC 3339</a> <cite title="NONE">[RFC3339]</cite> for details regarding date/times in general and UTC in particular. The <samp>exp</samp> value is a number.</dd>
<dt>iat</dt>
<dd style="margin-left: 8">REQUIRED. Time at which the JWT was issued. The time is represented as the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. The <samp>iat</samp> value is a number.</dd>
<dt>auth_time</dt>
<dd style="margin-left: 8">OPTIONAL. JSON Number that represents the time when the End-User authentication occurred. The time is represented as the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. When a <samp>max_age</samp> request is made then this Claim is REQUIRED.</dd>
<dt>nonce</dt>
<dd style="margin-left: 8">OPTIONAL. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authorization Request to the ID Token. The Client MUST verify that the <samp>nonce</samp> Claim Value is equal to the value of the <samp>nonce</samp> parameter sent in the Authorization Request. If present in the Authorization Request, Authorization Servers MUST include a <samp>nonce</samp> Claim in the ID Token with the Claim Value being the nonce value sent in the Authorization Request. Use of the nonce is OPTIONAL when using the code flow. The <samp>nonce</samp> value is a case sensitive string.</dd>
<dt>at_hash</dt>
<dd style="margin-left: 8">Access Token hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the <samp>access_token</samp> value, where the hash algorithm used is the hash algorithm used in the <samp>alg</samp> parameter of the ID Token's <a href="#JWS">JWS</a> <cite title="NONE">[JWS]</cite> header. For instance, if the <samp>alg</samp> is <samp>RS256</samp>, hash the <samp>access_token</samp> value with SHA-256, then take the left-most 128 bits and base64url encode them. The <samp>at_hash</samp> value is a case sensitive string.OPTIONAL if the Access Token is issued from the Token Endpoint. REQUIRED if Access Token is issued from Authorization Endpoint.</dd>
<dt>acr</dt>
<dd style="margin-left: 8">OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of <a href="#ISO29115">ISO/IEC 29115</a> <cite title="NONE">[ISO29115]</cite> level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD never be used to authorize access to any resource of any monetary value. An absolute URI or a <a href="#RFC6711">registered name</a> <cite title="NONE">[RFC6711]</cite> SHOULD be used as the <samp>acr</samp> value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The <samp>acr</samp> value is a case sensitive string.</dd>
<dt>amr</dt>
<dd style="margin-left: 8">OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the <samp>amr</samp> Claim is beyond the scope of this specification. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The <samp>amr</samp> value is an array of case sensitive strings.</dd>
<dt>azp</dt>
<dd style="margin-left: 8">Authorized Party, the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 <samp>client_id</samp> of the party that will be using it. This Claim is only REQUIRED when the party requesting the ID Token is not the same as the sole audience of the ID Token. It MAY be included even when the Authorized Party is the same as the sole audience. The <samp>azp</samp> value is a case sensitive string containing a StringOrURI value.</dd>
</dl>
<p id="rfc.section.3.2.1.p.5">ID Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored.</p>
<p id="rfc.section.3.2.1.p.6">ID Tokens MUST be signed using <a href="#JWS">JWS</a> <cite title="NONE">[JWS]</cite> and OPTIONALLY both signed and then encrypted using <a href="#JWS">JWS</a> <cite title="NONE">[JWS]</cite> and <a href="#JWE">JWE</a> <cite title="NONE">[JWE]</cite> respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per <a href="#signing_order">Section 14.13</a>. ID Tokens MUST NOT use <samp>none</samp> as the <samp>alg</samp> value.</p>
<p id="rfc.section.3.2.1.p.7">ID Tokens SHOULD NOT use the JWS or JWE <samp>x5u</samp>, <samp>x5c</samp>, <samp>jku</samp>, or <samp>jwk</samp> header parameter fields. Instead, key values and key references used for ID Tokens are communicated in advance using Discovery and Registration parameters.</p>
<p>The following is a non-normative example of a base64url decoded ID Token:</p>
<pre> {
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"exp": 1311281970,
"iat": 1311280970
}
</pre>
<p class="figure"></p>
<h1 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3.</a> Authorization Response</h1>
<p id="rfc.section.3.3.p.1">If the Resource Owner authenticates and authorizes, the Authorization Endpoint returns the OAuth 2.0 response as follows:</p>
<h1 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1.</a> <a href="#code_ok" id="code_ok">Case: response_type=code</a></h1>
<p id="rfc.section.3.3.1.p.1">The Authorization Server saves the association between code and id_token, and returns code and other OAuth 2.0 parameters as defined in Section 4.1.2 of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite>.</p>
<p>The following is a non-normative example (with line wraps for the display purposes only):</p>
<pre> HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
</pre>
<p class="figure"></p>
<h1 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2.</a> Case: response_type=id_token</h1>
<p id="rfc.section.3.3.2.p.1">The Authorization Server send the id_token back to the redirect_uri in the fragment.</p>
<pre> HTTP/1.1 302 Found
Location: https://client.example.org/cb#
id_token=previously.created.id_token
&state=af0ifjsldkj</pre>
<p class="figure"></p>
<h1 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3.</a> Case: response_type=token id_token</h1>
<p id="rfc.section.3.3.3.p.1">The Authorization Server sends the Access Token and ID Token back to the redirect_uri in the fragment.</p>
<pre> HTTP/1.1 302 Found
Location: https://client.example.org/cb#
id_token=previously.created.id_token&access_token=SlAV32hkKG
&state=af0ifjsldkj</pre>
<p class="figure"></p>
<h1 id="rfc.section.3.3.4"><a href="#rfc.section.3.3.4">3.3.4.</a> <a href="#AuthError" id="AuthError">Authorization Error Response</a></h1>
<p id="rfc.section.3.3.4.p.1">If the End-User denies the access request or if the request fails, the OP (Authorization Server) informs the RP (Client) by using the Error Response parameters defined in Sections 4.1.2.1 or 4.2.2.1 of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite>, according to the <samp>response_type</samp> used.</p>
<p id="rfc.section.3.3.4.p.2">In addition to the error codes defined in Sections 4.1.2.1 and 4.2.2.1 of OAuth 2.0, this specification also defines the following error codes:</p>
<p/>
<dl>
<dt>interaction_required</dt>
<dd style="margin-left: 8">The Authorization Server requires End-User interaction of some form to proceed. This error MAY be returned when the <samp>prompt</samp> parameter in the Authorization Request is set to <samp>none</samp> to request that the Authorization Server SHOULD NOT display any user interfaces to the End-User, but the Authorization Request cannot be completed without displaying a user interface for End-User interaction.</dd>
<dt>login_required</dt>
<dd style="margin-left: 8">The Authorization Server requires End-User authentication. This error MAY be returned when the <samp>prompt</samp> parameter in the Authorization Request is set to <samp>none</samp> to request that the Authorization Server SHOULD NOT display any user interfaces to the End-User, but the Authorization Request cannot be completed without displaying a user interface for user authentication.</dd>
<dt>session_selection_required</dt>
<dd style="margin-left: 8">The End-User is REQUIRED to select a session at the Authorization Server. The End-User MAY be authenticated at the Authorization Server with different associated accounts, but the End-User did not select a session. This error MAY be returned when the <samp>prompt</samp> parameter in the Authorization Request is set to <samp>none</samp> to request that the Authorization Server SHOULD NOT display any user interfaces to the End-User, but the Authorization Request cannot be completed without displaying a user interface to prompt for a session to use.</dd>
<dt>consent_required</dt>
<dd style="margin-left: 8">The Authorization Server requires End-User consent. This error MAY be returned when the <samp>prompt</samp> parameter in the Authorization Request is set to <samp>none</samp> to request that the Authorization Server SHOULD NOT display any user interfaces to the End-User, but the Authorization Request cannot be completed without displaying a user interface for End-User consent.</dd>
<dt>invalid_request_uri</dt>
<dd style="margin-left: 8">The <samp>request_uri</samp> in the Authorization Request returns an error or contains invalid data.</dd>
<dt>invalid_request_object</dt>
<dd style="margin-left: 8">The <samp>request</samp> parameter contains an invalid Request Object.</dd>
<dt>registration_not_supported</dt>
<dd style="margin-left: 8">The OP does not support use of the <samp>registration</samp> parameter.</dd>
<dt>request_not_supported</dt>
<dd style="margin-left: 8">The OP does not support use of the <samp>request</samp> parameter.</dd>
<dt>request_uri_not_supported</dt>
<dd style="margin-left: 8">The OP does not support use of the <samp>request_uri</samp> parameter.</dd>
</dl>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#token_request" id="token_request">Token Endpoint</a></h1>
<p id="rfc.section.4.p.1">As in OAuth 2.0, if the response type was 'code', the Client interacts with the Token Endpoint. </p>
<p id="rfc.section.4.p.2">In OpenID Connect, this communication MUST be over TLS. See <a href="#TLS_requirements">Section 14.15</a> for more information on using TLS.</p>
<h1 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1.</a> <a href="#access_token_response" id="access_token_response">Access Token Response</a></h1>
<p id="rfc.section.4.1.p.1">OpenID Connect compliant Token Endpoint does the following upon the receipt of the Authorization Code Request described in Section 4.1.3 of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite>. The check if it is associated with a previously created ID Token. It could be that ‘code’ has a special strtucture that indicates it or you might pull it from the database you created. Pull the associated ID Token out from wherever you have stored it and return it in the JSON response with the name “id_token”, e.g.:</p>
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"SlAV32hkKG",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"id_token":"previously.created.id_token"
}
</pre>
<p class="figure"></p>
<p id="rfc.section.4.1.p.2">OpenID Connect Constrains the parameters in the response as follows:</p>
<p/>
<dl>
<dt>access_token</dt>
<dd style="margin-left: 8">REQUIRED. Access Token for the UserInfo Endpoint.</dd>
<dt>token_type</dt>
<dd style="margin-left: 8">REQUIRED. OAuth 2.0 Token Type value. The value MUST be <samp>Bearer</samp> or another <samp>token_type</samp> value that the Client has negotiated with the Authorization Server. Clients implementing this profile MUST support the <a href="#RFC6750">OAuth 2.0 Bearer Token Usage</a> <cite title="NONE">[RFC6750]</cite> specification. This profile only describes the use of bearer tokens.</dd>
<dt>id_token</dt>
<dd style="margin-left: 8">REQUIRED. ID Token.</dd>
<dt>expires_in</dt>
<dd style="margin-left: 8">OPTIONAL. Expiration time of the Access Token in seconds since the response was generated.</dd>
<dt>refresh_token</dt>
<dd style="margin-left: 8">OPTIONAL. Refresh Token.</dd>
</dl>
<h1 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2.</a> <a href="#id.token.validation" id="id.token.validation">ID Token Validation</a></h1>
<p id="rfc.section.4.2.p.1">To validate the ID Token in the Authorization or Token Endpoint Response, the Client MUST do the following:</p>
<p/>
<ol>
<li>If the Client has provided an <samp>id_token_encrypted_response_alg</samp> parameter during Registration, decrypt the ID Token using the key pair specified during Registration.</li>
<li>The Client MUST validate that the <samp>aud</samp> (audience) Claim contains its <samp>client_id</samp> value registered at the Issuer identified by the <samp>iss</samp> (issuer) Claim as an audience. The <samp>aud</samp> (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.</li>
<li>If the ID Token contains multiple audiences, the Client SHOULD verify that an <samp>azp</samp> Claim is present.</li>
<li>If an <samp>azp</samp> (authorized party) Claim is present, the Client SHOULD verify and that its <samp>client_id</samp> is the Claim value.</li>
<li>If the <samp>id_token</samp> is received via direct communication between the Client and the Token Endpoint, the TLS server validation MAY be used to validate the issuer in place of checking the token signature. The Client MUST validate the signature of all other ID Tokens according to <a href="#JWS">JWS</a> <cite title="NONE">[JWS]</cite> using the algorithm specified in the <samp>alg</samp> parameter of the JWT header.</li>
<li>The <samp>alg</samp> value SHOULD be the default of <samp>RS256</samp> or the algorithm sent by the Client in the <samp>id_token_signed_response_alg</samp> parameter during Registration.</li>
<li>If the <samp>alg</samp> parameter of the JWT header is a MAC based algorithm such as <samp>HS256</samp>, <samp>HS384</samp>, or <samp>HS512</samp>, the octets of the UTF-8 representation of the <samp>client_secret</samp> corresponding to the <samp>client_id</samp> contained in the <samp>aud</samp> (audience) Claim are used as the key to validate the signature. Multiple audiences are not supported for MAC based algorithms.</li>
<li>For other Signing algorithms, the Client MUST use the signing key provided in Discovery by the Issuer. The issuer MUST exactly match the value of the <samp>iss</samp> (issuer) Claim.</li>
<li>The current time MUST be less than the value of the <samp>exp</samp> Claim.</li>
<li>The <samp>iat</samp> Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.</li>
<li>If a nonce value was sent in the Authorization Request, a <samp>nonce</samp> Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authorization Request. The Client SHOULD check the <samp>nonce</samp> value for replay attacks. The precise method for detecting replay attacks is Client specific.</li>
<li>If the <samp>acr</samp> Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of <samp>acr</samp> Claim Values is out of scope for this specification.</li>
<li>If the <samp>auth_time</samp> Claim was requested, either through a specific request for this Claim or by using the <samp>max_age</samp> parameter, the Client SHOULD check the <samp>auth_time</samp> Claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication.</li>
</ol>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#userinfo" id="userinfo">(OPTIONAL) UserInfo Endpoint</a></h1>
<p id="rfc.section.5.p.1">The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. The location of the UserInfo Endpoint MUST be a URL using the <samp>https</samp> scheme, which MAY contain port, path, and query parameter components. The returned Claims are represented by a JSON object that contains a collection of name and value pairs for the Claims.</p>
<p id="rfc.section.5.p.2">Communication with the UserInfo Endpoint MUST utilize TLS. See <a href="#TLS_requirements">Section 14.15</a> for more information on using TLS.</p>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> <a href="#UserInfoRequest" id="UserInfoRequest">UserInfo Request</a></h1>
<p id="rfc.section.5.1.p.1">Clients send requests to the UserInfo Endpoint to obtain Claims about the End-User. The UserInfo Endpoint is an <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite> Protected Resource that complies with the <a href="#RFC6750">OAuth 2.0 Bearer Token Usage</a> <cite title="NONE">[RFC6750]</cite> specification. The Access Token SHOULD be sent using the <samp>Authorization</samp> header field. The following parameters are defined for use in UserInfo Requests:</p>
<p/>
<dl>
<dt>access_token</dt>
<dd style="margin-left: 8">REQUIRED. Access Token obtained from an OpenID Connect Authorization Request. This parameter MUST only be sent using one method using either the <samp>Authorization</samp> header field or a form-encoded <samp>POST</samp> body parameter.</dd>
</dl>
<p>The following is a non-normative example of a UserInfo Request:</p>
<pre>
GET /userinfo HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG
</pre>
<p class="figure"></p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> <a href="#UserInfoResponse" id="UserInfoResponse">UserInfo Response</a></h1>
<p id="rfc.section.5.2.p.1">The UserInfo Claims MUST be returned as the members of a JSON object. The response body SHOULD be encoded using UTF-8. The Claims defined in <a href="#StandardClaims">Section 8</a> can be returned, as can additional Claims not specified there.</p>
<p id="rfc.section.5.2.p.2">If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.</p>
<p id="rfc.section.5.2.p.3">The <samp>sub</samp> (subject) Claim MUST always be returned in the UserInfo Response.</p>
<p id="rfc.section.5.2.p.4">NOTE: The UserInfo Endpoint response is not guaranteed to be about the End-User identified by the <samp>sub</samp> (subject) element of the ID Token. The <samp>sub</samp> Claim in the UserInfo Endpoint response MUST be verified to exactly match the <samp>sub</samp> Claim in the ID Token before using additional UserInfo Endpoint Claims.</p>
<h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> <a href="#UserInfoErrorResponse" id="UserInfoErrorResponse">UserInfo Error Response</a></h1>
<p id="rfc.section.5.3.p.1">When an error condition occurs, the UserInfo Endpoint returns an Error Response as defined in Section 3 of <a href="#RFC6750">OAuth 2.0 Bearer Token Usage</a> <cite title="NONE">[RFC6750]</cite>.</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#scopes" id="scopes">Scope Values</a></h1>
<p id="rfc.section.6.p.1">OpenID Connect Clients use <samp>scope</samp> values as defined in 3.3 of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite> to specify what access privileges are being requested for Access Tokens. The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints. For OpenID Connect, scopes can be used to request that specific sets of information be made available as Claim Values. This specification describes only the scope values used by OpenID Connect.</p>
<p id="rfc.section.6.p.2">OpenID Connect allows additional scope values to be defined and used. Scope values used that are not understood by an implementation SHOULD be ignored.</p>
<p id="rfc.section.6.p.3">Claims requested by the following scopes are treated by Authorization Servers as Voluntary Claims.</p>
<p id="rfc.section.6.p.4">OpenID Connect defines the following <samp>scope</samp> values:</p>
<p/>
<dl>
<dt>openid</dt>
<dd style="margin-left: 8">REQUIRED. Informs the Authorization Server that the Client is making an OpenID Connect request. If the <samp>openid</samp> scope value is not present, the behavior is entirely unspecified.</dd>
<dt>profile</dt>
<dd style="margin-left: 8">OPTIONAL. This scope value requests access to the End-User's default profile Claims, which are: <samp>name</samp>, <samp>family_name</samp>, <samp>given_name</samp>, <samp>middle_name</samp>, <samp>nickname</samp>, <samp>preferred_username</samp>, <samp>profile</samp>, <samp>picture</samp>, <samp>website</samp>, <samp>gender</samp>, <samp>birthdate</samp>, <samp>zoneinfo</samp>, <samp>locale</samp>, and <samp>updated_at</samp>.</dd>
<dt>email</dt>
<dd style="margin-left: 8">OPTIONAL. This scope value requests access to the <samp>email</samp> and <samp>email_verified</samp> Claims.</dd>
<dt>address</dt>
<dd style="margin-left: 8">OPTIONAL. This scope value requests access to the <samp>address</samp> Claim.</dd>
<dt>phone</dt>
<dd style="margin-left: 8">OPTIONAL. This scope value requests access to the <samp>phone_number</samp> and <samp>phone_number_verified</samp> Claims.</dd>
<dt>offline_access</dt>
<dd style="margin-left: 8">OPTIONAL. This scope value requests that an OAuth 2.0 Refresh Token be issued that can be used to obtain an Access Token that grants access to the End-User's UserInfo Endpoint even when the End-User is not present (not logged in).</dd>
</dl>
<p id="rfc.section.6.p.6">Multiple scope values MAY be used by creating a space delimited, case sensitive list of ASCII scope values.</p>
<p id="rfc.section.6.p.7">The Claims requested by the <samp>profile</samp>, <samp>email</samp>, <samp>address</samp>, and <samp>phone</samp> scope values are returned from the UserInfo Endpoint, as described in <a href="#UserInfoResponse">Section 5.2</a>.</p>
<p id="rfc.section.6.p.8">In some cases, the End-User will be given the option to have the OpenID Provider decline to provide some or all information requested by Clients. To minimize the amount of information that the End-User is being asked to disclose, a Client can elect to only request a subset of the information available from the UserInfo Endpoint.</p>
<p>The following is a non-normative example of a <samp>scope</samp> Request.</p>
<pre>
scope=openid profile email phone
</pre>
<p class="figure"></p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#idtype" id="idtype">Subject Identifier Types</a></h1>
<p id="rfc.section.7.p.1">The OpenID Provider's Discovery document SHOULD list its supported identifier types in the <samp>subject_types_supported</samp> element. If there is more than one type listed in the array, the Client MAY elect to provide its preferred identifier type using the <samp>subject_type</samp> parameter during Registration. The types supported by this specification are:</p>
<p/>
<dl>
<dt>public</dt>
<dd style="margin-left: 8">This provides the same <samp>sub</samp> (subject) value to all Clients. It is the default if the provider has no <samp>subject_types_supported</samp> element in its discovery document.</dd>
<dt>pairwise</dt>
<dd style="margin-left: 8">This provides a different <samp>sub</samp> value to each Client, to prevent correlation of the End-User's activities by Clients without his permission.</dd>
</dl>
<h1 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1.</a> <a href="#idtype.pairwise.alg" id="idtype.pairwise.alg">Pairwise Identifier Algorithm</a></h1>
<p id="rfc.section.7.1.p.1">The OpenID Provider MUST calculate a unique <samp>sub</samp> (subject) value for each Sector Identifier. The subject value MUST NOT be reversible by any party other than the OpenID Provider.</p>
<p id="rfc.section.7.1.p.2">Providers who use pairwise <samp>sub</samp> values SHOULD support the <samp>sector_identifier_uri</samp> in <a href="#OpenID.Registration">Dynamic Client Registration</a> <cite title="NONE">[OpenID.Registration]</cite>. It provides a way for a group of websites under common administrative control to have consistent pairwise <samp>sub</samp> values independent of the individual domain names. It also provides a way for Clients to change <samp>redirect_uri</samp> domains without having to reregister all of their users.</p>
<p id="rfc.section.7.1.p.3">If the Client has not provided a value for <samp>sector_identifier_uri</samp> in <a href="#OpenID.Registration">Dynamic Client Registration</a> <cite title="NONE">[OpenID.Registration]</cite>, the Sector Identifier used for pairwise identifier calculation is the host component of the registered <samp>redirect_uri</samp>. If there are multiple hostnames in the registered <samp>redirect_uris</samp>, the Client MUST register a <samp>sector_identifier_uri</samp>.</p>
<p id="rfc.section.7.1.p.4">When a <samp>sector_identifier_uri</samp> is provided, the host component of that URL is used as the Sector Identifier for the pairwise identifier calculation. The value of the <samp>sector_identifier_uri</samp> MUST be a URL using the <samp>https</samp> scheme that points to a JSON file containing an array of <samp>redirect_uri</samp> values. The values of the registered <samp>redirect_uris</samp> MUST be included in the elements of the array, or the registration MUST fail.</p>
<p id="rfc.section.7.1.p.5">A number of algorithms can be used by OpenID Providers to calculate pairwise identifiers. Three example methods are: </p>
<ol>
<li>The Sector Identifier can be concatenated with a local account ID and a salt value that is kept secret by the Provider. The concatenated string is then hashed using an appropriate algorithm. <br/><br/> Calculate <samp>sub</samp> = SHA-256 ( sector_identifier | local_account_id | salt ). <br/><br/></li>
<li>The Sector Identifier can be concatenated with a local account ID and a salt value that is kept secret by the Provider. The concatenated string is then encrypted using an appropriate algorithm. <br/><br/> Calculate <samp>sub</samp> = AES-128 ( sector_identifier | local_account_id | salt ). <br/><br/></li>
<li>The Issuer creates a Globally Unique Identifier (GUID) for the pair of Sector Identifier and local account ID and stores this value.</li>
</ol>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#StandardClaims" id="StandardClaims">Standard Claims</a></h1>
<p id="rfc.section.8.p.1">This profile defines a set of standard Claims. They are returned in the UserInfo Response.</p>
<div id="rfc.table.1"/>
<div id="ClaimTable"/>
<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>Reserved Member Definitions</caption>
<thead>
<tr>
<th class="left">Member</th>
<th class="left">Type</th>
<th class="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">sub</td>
<td class="left">string</td>
<td class="left">Subject - Identifier for the End-User at the Issuer.</td>
</tr>
<tr>
<td class="left">name</td>
<td class="left">string</td>
<td class="left">End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences.</td>
</tr>
<tr>
<td class="left">given_name</td>
<td class="left">string</td>
<td class="left">Given name(s) or first name(s) of the End-User. Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters.</td>
</tr>
<tr>
<td class="left">family_name</td>
<td class="left">string</td>
<td class="left">Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters.</td>
</tr>
<tr>
<td class="left">middle_name</td>
<td class="left">string</td>
<td class="left">Middle name(s) of the End-User. Note that in some cultures, people can have multiple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used.</td>
</tr>
<tr>
<td class="left">nickname</td>
<td class="left">string</td>
<td class="left">Casual name of the End-User that may or may not be the same as the <samp>given_name</samp>. For instance, a <samp>nickname</samp> value of <samp>Mike</samp> might be returned alongside a <samp>given_name</samp> value of <samp>Michael</samp>.</td>
</tr>
<tr>
<td class="left">preferred_username</td>
<td class="left">string</td>
<td class="left">Shorthand name that the End-User wishes to be referred to at the RP, such as <samp>janedoe</samp> or <samp>j.doe</samp>. This value MAY be any valid JSON string including special characters such as <samp>@</samp>, <samp>/</samp>, or whitespace. This value MUST NOT be relied upon to be unique by the RP. (See <a href="#claim.stability">Section 8.3</a>.)</td>
</tr>
<tr>
<td class="left">profile</td>
<td class="left">string</td>
<td class="left">URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User.</td>
</tr>
<tr>
<td class="left">picture</td>
<td class="left">string</td>
<td class="left">URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User.</td>
</tr>
<tr>
<td class="left">website</td>
<td class="left">string</td>
<td class="left">URL of the End-User's Web page or blog. This Web page SHOULD contain information published by the End-User or an organization that the End-User is affiliated with.</td>
</tr>
<tr>
<td class="left">email</td>
<td class="left">string</td>
<td class="left">End-User's preferred e-mail address. Its value MUST conform to the <a href="#RFC5322">RFC 5322</a> <cite title="NONE">[RFC5322]</cite> addr-spec syntax. This value MUST NOT be relied upon to be unique by the RP, as discussed in <a href="#claim.stability">Section 8.3</a>.</td>
</tr>
<tr>
<td class="left">email_verified</td>
<td class="left">boolean</td>
<td class="left">True if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is <samp>true</samp>, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.</td>
</tr>
<tr>
<td class="left">gender</td>
<td class="left">string</td>
<td class="left">End-User's gender. Values defined by this specification are <samp>female</samp> and <samp>male</samp>. Other values MAY be used when neither of the defined values are applicable.</td>
</tr>
<tr>
<td class="left">birthdate</td>
<td class="left">string</td>
<td class="left">End-User's birthday, represented as an <a href="#ISO8601-2004">ISO 8601:2004</a> <cite title="NONE">[ISO8601-2004]</cite> <samp>YYYY-MM-DD</samp> format. The year MAY be <samp>0000</samp>, indicating that it is omitted. To represent only the year, <samp>YYYY</samp> format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates.</td>
</tr>
<tr>
<td class="left">zoneinfo</td>
<td class="left">string</td>
<td class="left">String from zoneinfo <a href="#zoneinfo">[zoneinfo]</a> time zone database representing the End-User's time zone. For example, <samp>Europe/Paris</samp> or <samp>America/Los_Angeles</samp>.</td>
</tr>
<tr>
<td class="left">locale</td>
<td class="left">string</td>
<td class="left">End-User's locale, represented as a <a href="#RFC5646">BCP47</a> <cite title="NONE">[RFC5646]</cite> language tag. This is typically an <a href="#ISO639-1">ISO 639-1 Alpha-2</a> <cite title="NONE">[ISO639-1]</cite> language code in lowercase and an <a href="#ISO3166-1">ISO 3166-1 Alpha-2</a> <cite title="NONE">[ISO3166-1]</cite> country code in uppercase, separated by a dash. For example, <samp>en-US</samp> or <samp>fr-CA</samp>. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, <samp>en_US</samp>; Implementations MAY choose to accept this locale syntax as well.</td>
</tr>
<tr>
<td class="left">phone_number</td>
<td class="left">string</td>
<td class="left">End-User's preferred telephone number. <a href="#E.164">E.164</a> <cite title="NONE">[E.164]</cite> is RECOMMENDED as the format of this Claim, for example, <samp>+1 (425) 555-1212</samp> or <samp>+56 (2) 687 2400</samp>. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the <a href="#RFC3966">RFC 3966</a> <cite title="NONE">[RFC3966]</cite> extension syntax, for example, <samp>+1 (604) 555-1234;ext=5678</samp>.</td>
</tr>
<tr>
<td class="left">phone_number_verified</td>
<td class="left">boolean</td>
<td class="left">True if the End-User's phone number has been verified; otherwise false. When this Claim Value is <samp>true</samp>, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the <samp>phone_number</samp> Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format.</td>
</tr>
<tr>
<td class="left">address</td>
<td class="left">JSON object</td>
<td class="left">End-User's preferred address. The value of the <samp>address</samp> member is a <a href="#RFC4627">JSON</a> <cite title="NONE">[RFC4627]</cite> structure containing some or all of the members defined in <a href="#address_claim">Section 8.1</a>.</td>
</tr>
<tr>
<td class="left">updated_at</td>
<td class="left">number</td>
<td class="left">Time the End-User's information was last updated. The time is represented as the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time.</td>
</tr>
</tbody>
</table>
<p>Following is a non-normative example of such a response:</p>
<pre>
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"preferred_username": "j.doe",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
</pre>
<p class="figure"></p>
<p id="rfc.section.8.p.2">The UserInfo Endpoint MUST return Claims in JSON format unless a different format was specified during Registration <a href="#OpenID.Registration">[OpenID.Registration]</a>. The UserInfo Endpoint MUST return a content-type header to indicate which format is being returned. The following are accepted content types:</p>
<table cellpadding="3" cellspacing="0" class="tt all center">
<thead>
<tr>
<th class="left">Content-Type</th>
<th class="left">Format Returned</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">application/json</td>
<td class="left">plain text JSON object</td>
</tr>
<tr>
<td class="left">application/jwt</td>
<td class="left">JSON Web Token (JWT)</td>
</tr>
</tbody>
</table>
<h1 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1.</a> <a href="#address_claim" id="address_claim">Address Claim</a></h1>
<p id="rfc.section.8.1.p.1">The Address Claim represents a physical mailing address. Implementations MAY return only a subset of the fields of an <samp>address</samp>, depending upon the information available and the End-User's privacy preferences. For example, the <samp>country</samp> and <samp>region</samp> might be returned without returning more fine-grained address information.</p>
<p id="rfc.section.8.1.p.2">Implementations MAY return just the full address as a single string in the formatted sub-field, or they MAY return just the individual component fields using the other sub-fields, or they MAY return both. If both variants are returned, they SHOULD be describing the same address, with the formatted address indicating how the component fields are combined.</p>
<p/>
<dl>
<dt>formatted</dt>
<dd style="margin-left: 8">Full mailing address, formatted for display or use on a mailing label. This field MAY contain multiple lines, separated by newline characters.</dd>
<dt>street_address</dt>
<dd style="margin-left: 8">Full street address component, which MAY include house number, street name, Post Office Box, and multi-line extended street address information. This field MAY contain multiple lines, separated by newline characters.</dd>
<dt>locality</dt>
<dd style="margin-left: 8">City or locality component.</dd>
<dt>region</dt>
<dd style="margin-left: 8">State, province, prefecture or region component.</dd>
<dt>postal_code</dt>
<dd style="margin-left: 8">Zip code or postal code component.</dd>
<dt>country</dt>
<dd style="margin-left: 8">Country name component.</dd>
</dl>
<h1 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2.</a> <a href="#ClaimsLanguagesAndScripts" id="ClaimsLanguagesAndScripts">Claims Languages and Scripts</a></h1>
<p id="rfc.section.8.2.p.1">Human-readable Claim Values and Claim Values that reference human-readable values MAY be represented in multiple languages and scripts. To specify the languages and scripts, <a href="#RFC5646">BCP47</a> <cite title="NONE">[RFC5646]</cite> language tags are added to member names, delimited by a <samp>#</samp> character. For example, <samp>family_name#ja-Kana-JP</samp> expresses the Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same represented as <samp>family_name#ja-Hani-JP</samp>. As another example, both <samp>website</samp> and <samp>website#de</samp> Claim Values might be returned, referencing a Web site in an unspecified language and a Web site in German.</p>
<p id="rfc.section.8.2.p.2">Since Claim Names are case sensitive, it is strongly RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the <a href="#IANA.Language">IANA Language Subtag Registry</a> <cite title="NONE">[IANA.Language]</cite>. In particular, normally language names are spelled with lowercase characters, region names are spelled with uppercase characters, and scripts are spelled with mixed case characters. However, since BCP47 language tag values are case insensitive, implementations SHOULD interpret the language tag values supplied in a case insensitive manner.</p>
<p id="rfc.section.8.2.p.3">Per the recommendations in BCP47, language tag values for Claims SHOULD only be as specific as necessary. For instance, using <samp>fr</samp> might be sufficient in many contexts, rather than <samp>fr-CA</samp> or <samp>fr-FR</samp>. Where possible, OPs SHOULD try to match requested Claim locales with Claims it has. For instance, if the Client asks for a Claim with a <samp>de</samp> (German) language tag and the OP has a value tagged with <samp>de-CH</samp> (Swiss German) and no generic German value, it would be appropriate for the OP to return the Swiss German value to the Client. (This intentionally moves as much of the complexity of language tag matching to the OP as possible, to simplify Clients.)</p>
<p id="rfc.section.8.2.p.4">A <samp>claims_locales</samp> request can be used to specify the preferred languages and scripts to use for the returned Claims.</p>
<p id="rfc.section.8.2.p.5">When the OP determines, either through the <samp>claims_locales</samp> parameter, or by other means, that the End-User and Client are requesting Claims in only one set of languages and scripts, it is RECOMMENDED that OPs return Claims without language tags when they employ this language and script. It is also RECOMMENDED that Clients be written in a manner that they can handle and utilize Claims using language tags.</p>
<h1 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3.</a> <a href="#claim.stability" id="claim.stability">Claim Stability and Uniqueness</a></h1>
<p id="rfc.section.8.3.p.1">The <samp>sub</samp> (subject) and <samp>iss</samp> (issuer) Claims are the only Claims that a Client can rely upon as a stable identifier for the End-User, since the <samp>sub</samp> Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in <a href="#id_token">Section 3.2.1</a>. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the <samp>iss</samp> Claim and the <samp>sub</samp> Claim.</p>
<p id="rfc.section.8.3.p.2">All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and Issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use an <samp>email</samp> Claim value across different End-Users at different points in time, and the claimed <samp>email</samp> address for a given End-User MAY change over time. Therefore, other Claims such as <samp>email</samp>, <samp>phone_number</samp>, and <samp>preferred_username</samp> and MUST NOT be used as unique identifiers for the End-User.</p>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#sigenc" id="sigenc">Signatures and Encryption</a></h1>
<p id="rfc.section.9.p.1">Depending on the transport through which the messages are sent, the integrity of the message might not be guaranteed and the originator of the message might not be authenticated. To mitigate these risks, Request Object, Token Request, ID Token, and UserInfo Response values MAY utilize <a href="#JWS">JSON Web Signature (JWS)</a> <cite title="NONE">[JWS]</cite> to sign the contents.</p>
<p id="rfc.section.9.p.2">To achieve message confidentiality, Request Object, Token Request, ID Token, and UserInfo Response values MAY use <a href="#JWE">JSON Web Encryption (JWE)</a> <cite title="NONE">[JWE]</cite> to encrypt the content.</p>
<p id="rfc.section.9.p.3">When the message is both signed and encrypted, it MUST be signed first and then encrypted, per <a href="#signing_order">Section 14.13</a>, with nesting performed in the same manner as specified for JWTs <a href="#JWT">[JWT]</a>. Note that all JWE encryption methods perform integrity checking.</p>
<h1 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1.</a> <a href="#sigenc.alg" id="sigenc.alg">Supported Algorithms</a></h1>
<p id="rfc.section.9.1.p.1">The server advertises its supported signing and encryption algorithms in its discovery document. The algorithm identifiers are specified in <a href="#JWA">JWA</a> <cite title="NONE">[JWA]</cite>. The related elements are:</p>
<p/>
<dl>
<dt>userinfo_signing_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWS <a href="#JWS">[JWS]</a> signing algorithms (<samp>alg</samp> values) <a href="#JWA">[JWA]</a> supported by the UserInfo Endpoint to encode the Claims in a JWT <a href="#JWT">[JWT]</a>.</dd>
<dt>userinfo_encryption_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWE <a href="#JWE">[JWE]</a> encryption algorithms (<samp>alg</samp> values) <a href="#JWA">[JWA]</a> supported by the UserInfo Endpoint to encode the Claims in a JWT <a href="#JWT">[JWT]</a>.</dd>
<dt>userinfo_encryption_enc_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWE encryption algorithms (<samp>enc</samp> values) <a href="#JWA">[JWA]</a> supported by the UserInfo Endpoint to encode the Claims in a JWT <a href="#JWT">[JWT]</a>.</dd>
<dt>id_token_signing_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWS signing algorithms (<samp>alg</samp> values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT <a href="#JWT">[JWT]</a>.</dd>
<dt>id_token_encryption_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWE encryption algorithms (<samp>alg</samp> values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT <a href="#JWT">[JWT]</a>.</dd>
<dt>id_token_encryption_enc_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWE encryption algorithms (<samp>enc</samp> values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT <a href="#JWT">[JWT]</a>.</dd>
<dt>request_object_signing_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWS signing algorithms (<samp>alg</samp> values) supported by the Authorization Server for Request Object values. Servers SHOULD support <samp>none</samp> and <samp>RS256</samp>.</dd>
<dt>request_object_encryption_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWE encryption algorithms (<samp>alg</samp> values) supported by the Authorization Server for Request Object values.</dd>
<dt>request_object_encryption_enc_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWE encryption algorithms (<samp>enc</samp> values) supported by the Authorization Server for Request Object values.</dd>
<dt>token_endpoint_auth_signing_alg_values_supported</dt>
<dd style="margin-left: 8">JSON array containing a list of the JWS signing algorithms (<samp>alg</samp> values) supported by the Token Endpoint for the <samp>private_key_jwt</samp> and <samp>client_secret_jwt</samp> methods to encode the JWT <a href="#JWT">[JWT]</a>. Servers SHOULD support <samp>RS256</samp>.</dd>
</dl>
<p id="rfc.section.9.1.p.3">The Client registers its REQUIRED algorithms for Signing and Encryption using the following Registration parameters:</p>
<p/>
<dl>
<dt>request_object_signing_alg</dt>
<dd style="margin-left: 8">OPTIONAL. JWS signature algorithm <a href="#JWA">[JWA]</a> REQUIRED for Request Objects by the Authorization Server. All Request Objects from this <samp>client_id</samp> MUST be rejected if not signed by this algorithm. Servers SHOULD support <samp>RS256</samp>.</dd>
<dt>userinfo_signed_response_alg</dt>
<dd style="margin-left: 8">OPTIONAL. JWS signature algorithm <a href="#JWA">[JWA]</a> REQUIRED for UserInfo Responses. If this is specified the response will be <a href="#JWT">JWT</a> <cite title="NONE">[JWT]</cite> serialized.</dd>
<dt>userinfo_encrypted_response_alg</dt>
<dd style="margin-left: 8">OPTIONAL. JWE <samp>alg</samp> algorithm <a href="#JWA">[JWA]</a> REQUIRED for UserInfo Responses. If this is requested in combination with signing, the response MUST be signed first then encrypted, per <a href="#signing_order">Section 14.13</a>. If this is specified, the response will be <a href="#JWT">JWT</a> <cite title="NONE">[JWT]</cite> serialized.</dd>
<dt>userinfo_encrypted_response_enc</dt>
<dd style="margin-left: 8">OPTIONAL. JWE <samp>enc</samp> algorithm <a href="#JWA">[JWA]</a> REQUIRED for UserInfo Responses. If <samp>userinfo_encrypted_response_alg</samp> is specified the default for this value is <samp>A128CBC-HS256</samp>.</dd>
<dt>id_token_signed_response_alg</dt>
<dd style="margin-left: 8">OPTIONAL. JWS signature algorithm <a href="#JWA">[JWA]</a> REQUIRED for ID Tokens issued to this <samp>client_id</samp>. The default if not specified is <samp>RS256</samp>. The public key for validating the signature is provided by retrieving the JWK Set referenced by the <samp>jwks_uri</samp> element from Discovery.</dd>
<dt>id_token_encrypted_response_alg</dt>
<dd style="margin-left: 8">OPTIONAL. JWE <samp>alg</samp> algorithm <a href="#JWA">[JWA]</a> REQUIRED for ID Tokens issued to this <samp>client_id</samp>. If this is requested, the response MUST be signed then encrypted. The default if not specified is no encryption.</dd>
<dt>id_token_encrypted_response_enc</dt>
<dd style="margin-left: 8">OPTIONAL. JWE <samp>enc</samp> algorithm <a href="#JWA">[JWA]</a> REQUIRED for ID Tokens issued to this <samp>client_id</samp>. If <samp>id_token_encrypted_response_alg</samp> is specified the default for this value is <samp>A128CBC-HS256</samp>.</dd>
</dl>
<h1 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2.</a> <a href="#sigenc.key" id="sigenc.key">Keys</a></h1>
<p id="rfc.section.9.2.p.1">The OpenID Provider provides its public keys during Discovery using the following element: </p>
<dl>
<dt>jwks_uri</dt>
<dd style="margin-left: 8">REQUIRED. URL of the OP's JSON Web Key Set <a href="#JWK">[JWK]</a> document. This contains the signing key(s) the Client uses to validate signatures from the OP. The JWK Set MAY also contain the Server's encryption key(s), which are used by Clients to encrypt requests to the Server. When both signing and encryption keys are made available, a <samp>use</samp> (Key Use) parameter value is REQUIRED for all keys in the document to indicate each key's intended usage.</dd>
</dl>
<p id="rfc.section.9.2.p.2">Likewise, the Client can provide its public keys during Registration using the following element: </p>
<dl>
<dt>jwks_uri</dt>
<dd style="margin-left: 8">OPTIONAL. URL for the Client's JSON Web Key Set <a href="#JWK">[JWK]</a> document. If the Client signs requests to the Server, it contains the signing key(s) the Server uses to validate signatures from the Client. The JWK Set MAY also contain the Client's encryption keys(s), which are used by the Server to encrypt responses to the Client. When both signing and encryption keys are made available, a <samp>use</samp> (Key Use) parameter value is REQUIRED for all keys in the document to indicate each key's intended usage.</dd>
</dl>
<p id="rfc.section.9.2.p.3">When both signing and encryption keys are made available, the <samp>use</samp> (Key Use) parameter value is REQUIRED for all keys in the JWK Set at the <samp>jwks_uri</samp> to indicate each key's intended usage. Although some algorithms allow the same key pair to be used for both signatures and encryption, doing so is NOT RECOMMENDED, as it is less secure.</p>
<p id="rfc.section.9.2.p.4">In both cases, the JWK <samp>x5c</samp> parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate.</p>
<h1 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3.</a> <a href="#sigs" id="sigs">Signing</a></h1>
<p id="rfc.section.9.3.p.1">The signing party MUST select a signature algorithm based on the supported algorithms of the recipient in <a href="#sigenc.alg">Section 9.1</a>.</p>
<p/>
<dl>
<dt>Asymmetric Signatures</dt>
<dd style="margin-left: 8">When using RSA or ECDSA Signatures, the <samp>alg</samp> Claim of the JWS header MUST be set to the appropriate algorithm as defined in <a href="#JWA">JSON Web Algorithms</a> <cite title="NONE">[JWA]</cite>. The private key MUST be the one associated with the Public Signing Key provided in <a href="#sigenc.key">Section 9.2</a>. If there are multiple keys in the referenced JWK document, a <samp>kid</samp> value MUST be provided in the JWS header. The key usage of the respective keys MUST support signature.</dd>
<dt>Symmetric Signatures</dt>
<dd style="margin-left: 8">When using MAC-based signatures, the <samp>alg</samp> Claim of the JWS header MUST be set to a MAC algorithm, as defined in <a href="#JWA">JSON Web Algorithms</a> <cite title="NONE">[JWA]</cite>. The MAC key used is the octets of the UTF-8 representation of the <samp>client_secret</samp> value. See <a href="#SymmetricKeyEntropy">Section 14.17</a> for a discussion of entropy requirements for <samp>client_secret</samp> values. Symmetric signatures MUST never be used by public (non-confidential) Clients because of their inability to keep secrets.</dd>
</dl>
<p id="rfc.section.9.3.p.3">See <a href="#NeedForSignedRequests">Section 14.18</a> for Security Considerations about the need for signed requests.</p>
<h1 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1.</a> <a href="#rotate.sig.keys" id="rotate.sig.keys">Rotation of Asymmetric Signing Keys</a></h1>
<p id="rfc.section.9.3.1.p.1">Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at the <samp>jwks_uri</samp> location and includes the <samp>kid</samp> of the signing key in the JWS header of each message to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over by periodically adding new keys to the JWK Set at <samp>jwks_uri</samp>. The signer can begin using a new key at its discretion and signals the change to the verifier using the <samp>kid</samp> value. The verifier knows to go back to the <samp>jwks_uri</samp> to re-retrieve the keys when it sees an unfamiliar <samp>kid</samp> value. The JWK Set document at the <samp>jwks_uri</samp> SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.</p>
<h1 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4.</a> <a href="#enc" id="enc">Encryption</a></h1>
<p id="rfc.section.9.4.p.1">The encrypting party MUST select an encryption algorithm based on the supported algorithms of the recipient in <a href="#sigenc.alg">Section 9.1</a>. All JWTs MUST be signed before encryption to enable verification of the Issuer.</p>
<p/>
<dl>
<dt>Asymmetric Encryption: RSA</dt>
<dd style="margin-left: 8">Use the link registered/discovered in <a href="#sigenc.key">Section 9.2</a> to retrieve the relevant key. If there are multiple keys in the referenced JWK document, a <samp>kid</samp> value MUST be provided in the JWE header. Use the supported RSA key wrapping algorithm to wrap a random <samp>Content Master Key</samp> to be used for encrypting the signed JWT. The key usage of the respective keys MUST include encryption.</dd>
<dt>Asymmetric Encryption: Elliptic Curve</dt>
<dd style="margin-left: 8">Create an ephemeral Elliptic Curve public key for the <samp>epk</samp> element of the JWE header. Use the link registered/discovered in <a href="#sigenc.key">Section 9.2</a> to retrieve the relevant key. If there are multiple keys in the referenced JWK document, a <samp>kid</samp> value MUST be provided in the JWE header. Use the ECDH-ES algorithm to wrap a random <samp>Content Master Key</samp> to be used for encrypting the signed JWT. The key usage of the respective keys MUST support encryption.</dd>
<dt>Symmetric Encryption</dt>
<dd style="margin-left: 8">The symmetric encryption key is derived from the <samp>client_secret</samp> value by using a left truncated SHA-256 hash of the octets of the UTF-8 representation of the <samp>client_secret</samp>. The SHA-256 value MUST be left truncated to the appropriate bit length for the AES key wrapping algorithm used, for instance, to 128 bits for <samp>A128KW</samp>. If a key wrapping key with greater than 256 bits is needed, a different method of deriving the key from the <samp>client_secret</samp> would have to be defined by an extension. Symmetric encryption MUST never be used by public (non-confidential) Clients because of their inability to keep secrets.</dd>
</dl>
<p id="rfc.section.9.4.p.3">See <a href="#NeedForEncryptedRequests">Section 14.19</a> for Security Considerations about the need for encrypted requests.</p>
<h1 id="rfc.section.9.4.1"><a href="#rfc.section.9.4.1">9.4.1.</a> <a href="#rotate.enc.keys" id="rotate.enc.keys">Rotation of Asymmetric Encryption Keys</a></h1>
<p id="rfc.section.9.4.1.p.1">Rotating encryption keys is necessarily a different process than for signing keys because the encrypting party starts the process and thus cannot rely on a change in kid as a signal to know that keys need to change. The encrypting party still uses the kid header in the JWE to tell the decrypting party which private key to use to decrypt, however, the encrypting party needs to first select the most appropriate key from those provided in the JWK Set at <samp>jwks_uri</samp>. To rotate keys, the decrypting party can publish new keys at <samp>jwks_uri</samp> and remove from the JWK Set those that are being decommissioned. The <samp>jwks_uri</samp> SHOULD include a <samp>Cache-Control</samp> header in the response that contains a <samp>max-age</samp> directive, as defined in <a href="#RFC2616">RFC 2616</a> <cite title="NONE">[RFC2616]</cite>, which allows the encrypting party to safely cache the JWK Set and not have to re-retrieve the document for every encryption event. The decrypting party SHOULD remove decommissioned keys from the JWK Set at <samp>jwks_uri</samp> but retain them internally for some reasonable period of time, coordinated with the cache duration, to facilitate a smooth transition between keys by allowing the encrypting party some time to obtain the new keys. The cache duration SHOULD also be coordinated with the issuance of new signing keys as described in <a href="#rotate.sig.keys">Section 9.3.1</a>.</p>
<h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a href="#Serializations" id="Serializations">Serializations</a></h1>
<p id="rfc.section.10.p.1">A request message MAY be serialized using one of the following methods: </p>
<ol>
<li>Query String Serialization</li>
<li>Form Serialization</li>
</ol>
<h1 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1.</a> <a href="#qss" id="qss">Query String Serialization</a></h1>
<p id="rfc.section.10.1.p.1">In order to serialize the parameters using the Query String Serialization, the Client constructs the string by adding the parameters and values to the query component using the <samp>application/x-www-form-urlencoded</samp> format as defined by <a href="#W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a>. Query String Serialization is typically used in HTTP <samp>GET</samp> requests.</p>
<p>Following is a non-normative example of this serialization (with line wraps within values for display purposes only):</p>
<pre>
GET /authorize?scope=openid
&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
</pre>
<p class="figure"></p>
<h1 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2.</a> <a href="#form_serialization" id="form_serialization">Form Serialization</a></h1>
<p id="rfc.section.10.2.p.1">Parameters and their values are Form Serialized by adding the parameter names and values to the entity body of the HTTP request using the <samp>application/x-www-form-urlencoded</samp> format as defined by <a href="#W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a>. Form Serialization is typically used in HTTP <samp>POST</samp> requests.</p>
<p>Following is a non-normative example of this serialization (with line wraps within values for display purposes only):</p>
<pre>
POST /authorize HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
scope=openid
&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
</pre>
<p class="figure"></p>
<h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a href="#stringops" id="stringops">String Operations</a></h1>
<p id="rfc.section.11.p.1">Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the Claim Names returned by the UserInfo Endpoint might be compared to specific Claim Names such as <samp>sub</samp>. Comparing Unicode strings, however, has significant security implications.</p>
<p id="rfc.section.11.p.2">Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below: </p>
<ol>
<li>Remove any JSON applied escaping to produce an array of Unicode code points.</li>
<li><a href="#USA15">Unicode Normalization</a> <cite title="NONE">[USA15]</cite> MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against.</li>
<li>Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.</li>
</ol>
<p id="rfc.section.11.p.3">In several places, this specification uses space delimited lists of strings. In all such cases, only the ASCII space character (0x20) MAY be used for this purpose.</p>
<h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a href="#tls" id="tls">TLS Version</a></h1>
<p id="rfc.section.12.p.1">Whenever Transport Layer Security (TLS) is used by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 <a href="#RFC5246">[RFC5246]</a> is the most recent version, but has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 <a href="#RFC2246">[RFC2246]</a> is the most widely deployed version and will provide the broadest interoperability.</p>
<h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a href="#ImplementationConsiderations" id="ImplementationConsiderations">Implementation Considerations</a></h1>
<p id="rfc.section.13.p.1">This specification defines features used by both Relying Parties and OpenID Providers. Features that are mandatory to implement for Relying Parties are already described in the <a href="#OpenID.Basic">OpenID Connect Basic Client Profile 1.0</a> <cite title="NONE">[OpenID.Basic]</cite> and <a href="#OpenID.Implicit">OpenID Connect Implicit Client Profile 1.0</a> <cite title="NONE">[OpenID.Implicit]</cite> specifications, and so are not discussed again here.</p>
<p id="rfc.section.13.p.2">It is expected that some OpenID Providers will require static, out-of-band configuration of RPs using them, whereas others will support dynamic usage by RPs without a pre-established relationship between them. For that reason, the mandatory-to-implement features for OPs are listed below in two groups: the first for all OPs and the second for "Dynamic" OpenID Providers.</p>
<h1 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1.</a> <a href="#ServerMTI" id="ServerMTI">Mandatory to Implement Features for All OpenID Providers</a></h1>
<p id="rfc.section.13.1.p.1">All OpenID Providers MUST implement the following features defined in this specification. This list augments the set of features that are already listed elsewhere as being "REQUIRED" or are described with a "MUST", and so is not, by itself, a comprehensive set of implementation requirements for OPs.</p>
<p/>
<dl>
<dt>Signing ID Tokens with RSA SHA-256</dt>
<dd style="margin-left: 8">OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an <samp>alg</samp> value of <samp>RS256</samp>).</dd>
<dt>Prompt Parameter</dt>
<dd style="margin-left: 8">OPs MUST support the <samp>prompt</samp> parameter, as defined in <a href="#RequestParameters">Section 3.1</a>, including the specified user interface behaviors such as <samp>none</samp> and <samp>login</samp>.</dd>
<dt>Display Parameter</dt>
<dd style="margin-left: 8">OPs MUST support the <samp>display</samp> parameter, as defined in <a href="#RequestParameters">Section 3.1</a>. (Note that the minimum level of support required for this parameter is simply to have its use not result in an error.)</dd>
<dt>Preferred Locales</dt>
<dd style="margin-left: 8">OPs MUST support requests for preferred languages and scripts for the user interface and for Claims via the <samp>ui_locales</samp> and <samp>claims_locales</samp> request parameters, as defined in <a href="#RequestParameters">Section 3.1</a>. (Note that the minimum level of support required for these parameters is simply to have their use not result in errors.)</dd>
<dt>Authentication Time</dt>
<dd style="margin-left: 8">OPs MUST support returning the time at which the End-User authenticated via the <samp>auth_time</samp> Claim, as defined in <a href="#id_token">Section 3.2.1</a>.</dd>
<dt>Maximum Authentication Age</dt>
<dd style="margin-left: 8">OPs MUST support enforcing a maximum authentication age via the <samp>max_age</samp> parameter, as defined in <a href="#RequestParameters">Section 3.1</a>.</dd>
<dt>Authentication Context Class Reference</dt>
<dd style="margin-left: 8">OPs MUST support requests for specific Authentication Context Class Reference values via the <samp>acr_values</samp> parameter, as defined in <a href="#RequestParameters">Section 3.1</a>. (Note that the minimum level of support required for this parameter is simply to have its use not result in an error.)</dd>
</dl>
<h1 id="rfc.section.13.2"><a href="#rfc.section.13.2">13.2.</a> <a href="#DynamicMTI" id="DynamicMTI">Mandatory to Implement Features for Dynamic OpenID Providers</a></h1>
<p id="rfc.section.13.2.p.1">In addition to the features listed above, OpenID Providers supporting dynamic establishment of relationships with RPs that they do not have a pre-configured relationship with MUST also implement the following features defined in this and related specifications.</p>
<p/>
<dl>
<dt>Discovery</dt>
<dd style="margin-left: 8">These OPs MUST support Discovery, as defined in <a href="#OpenID.Discovery">OpenID Connect Discovery 1.0</a> <cite title="NONE">[OpenID.Discovery]</cite>.</dd>
<dt>Dynamic Registration</dt>
<dd style="margin-left: 8">These OPs MUST support Dynamic Client Registration, as defined in <a href="#OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</a> <cite title="NONE">[OpenID.Registration]</cite>.</dd>
<dt>UserInfo Endpoint</dt>
<dd style="margin-left: 8">All dynamic OPs that issue Access Tokens MUST support the UserInfo Endpoint, as defined in <a href="#userinfo">Section 5</a>. (Self-Issued OPs do not issue Access Tokens.)</dd>
<dt>Public Keys Published as Bare Keys</dt>
<dd style="margin-left: 8">These OPs MUST publish their public keys as bare keys, rather than in X.509 format.</dd>
<dt>Request URI</dt>
<dd style="margin-left: 8">These OPs MUST support requests made using a Request Object value that is retrieved from a Request URI that is provided with the <samp>request_uri</samp> parameter, as defined in <a href="#RequestParameters">Section 3.1</a>.</dd>
</dl>
<h1 id="rfc.section.13.3"><a href="#rfc.section.13.3">13.3.</a> <a href="#related" id="related">Related Specifications</a></h1>
<p id="rfc.section.13.3.p.1">This specification is an abstract specification. It needs to be bound to a protocol to be used in practice. One such example of protocol binding is: </p>
<ul>
<li><a href="#OpenID.Standard">OpenID Connect Standard 1.0</a> <cite title="NONE">[OpenID.Standard]</cite> - Protocol binding for the full set of OpenID Connect messages</li>
</ul>
<p id="rfc.section.13.3.p.2">These related OpenID Connect specifications MAY OPTIONALLY be used in combination with this specification to provide additional functionality: </p>
<ul>
<li><a href="#OpenID.Discovery">OpenID Connect Discovery 1.0</a> <cite title="NONE">[OpenID.Discovery]</cite> - Dynamic discovery for user and Authorization Server endpoints and information</li>
<li><a href="#OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</a> <cite title="NONE">[OpenID.Registration]</cite> - Dynamic registration of OpenID Connect Clients with OpenID Providers</li>
<li><a href="#OpenID.Basic">OpenID Connect Basic Client Profile 1.0</a> <cite title="NONE">[OpenID.Basic]</cite> - Protocol binding for a subset of the OpenID Connect Messages that is intended for use by basic Web-based Relying Parties using the OAuth <samp>authorization_code</samp> grant type.</li>
<li><a href="#OpenID.Implicit">OpenID Connect Implicit Client Profile 1.0</a> <cite title="NONE">[OpenID.Implicit]</cite> - Protocol binding for a subset of the OpenID Connect Messages that is intended for use by basic Web-based Relying Parties using the OAuth implicit grant type.</li>
<li><a href="#OpenID.Session">OpenID Connect Session Management 1.0</a> <cite title="NONE">[OpenID.Session]</cite> - Session management for OpenID Connect sessions</li>
</ul>
<h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a href="#security_considerations" id="security_considerations">Security Considerations</a></h1>
<p><a href="#RFC6819">OAuth 2.0 Threat Model and Security Considerations</a> <cite title="NONE">[RFC6819]</cite> provides an extensive list of threats and controls that applies to this standard as well. <a href="#ISO29115">ISO/IEC 29115</a> <cite title="NONE">[ISO29115]</cite> also provides threats and controls that implementers need to take into account. In addition, this standard provides additional control measures listed below.</p>
<h1 id="rfc.section.14.1"><a href="#rfc.section.14.1">14.1.</a> <a href="#request_disclosure" id="request_disclosure">Request Disclosure</a></h1>
<p id="rfc.section.14.1.p.1">If appropriate measures are not taken, a request might be disclosed to an attacker, posing security and privacy threats.</p>
<p id="rfc.section.14.1.p.2">In addition to what is stated in Section 5.1.1 of <a href="#RFC6819">[RFC6819]</a>, this standard provides a way to provide the confidentiality of the request end to end through the use of <samp>request</samp> or <samp>request_uri</samp> parameters, where the content of the <samp>request</samp> is an encrypted JWT with the appropriate key and cipher. This protects even against a compromised User-Agent in the case of indirect request.</p>
<h1 id="rfc.section.14.2"><a href="#rfc.section.14.2">14.2.</a> <a href="#server_masquerading" id="server_masquerading">Server Masquerading</a></h1>
<p id="rfc.section.14.2.p.1">A malicious Server might masquerade as the legitimate server using various means. To detect such an attack, the Client needs to authenticate the server.</p>
<p id="rfc.section.14.2.p.2">In addition to what is stated in Section 5.1.2 of <a href="#RFC6819">[RFC6819]</a>, this standard provides a way to authenticate the Server through either the use of Signed or Encrypted JWTs with an appropriate key and cipher.</p>
<h1 id="rfc.section.14.3"><a href="#rfc.section.14.3">14.3.</a> <a href="#token_manufacture" id="token_manufacture">Token Manufacture/Modification</a></h1>
<p id="rfc.section.14.3.p.1">An Attacker might generate a bogus token or modify the token content (such as the authentication or attribute statements) of an existing parseable token, causing the RP to grant inappropriate access to the Client. For example, an Attacker might modify the parseable token to extend the validity period; a Client might modify the parseable token to have access to information that they should not be able to view.</p>
<p id="rfc.section.14.3.p.2">There are two ways to mitigate this attack:</p>
<p/>
<ol>
<li>The token can be digitally signed by the OP. The Relying Party SHOULD validate the digital signature to verify that it was issued by a legitimate OP.</li>
<li>The token can be sent over a protected channel such as TLS. See <a href="#TLS_requirements">Section 14.15</a> for more information on using TLS. In this specification, the token is always sent over a TLS protected channel. Note however, that this measure is only a defense against third party attackers and is not applicable to the case where the Client is the attacker.</li>
</ol>
<h1 id="rfc.section.14.4"><a href="#rfc.section.14.4">14.4.</a> <a href="#response_disclosure" id="response_disclosure">Server Response Disclosure</a></h1>
<p id="rfc.section.14.4.p.1">The server response might contain authentication and attribute statements that include sensitive Client information. Disclosure of the response contents can make the Client vulnerable to other types of attacks.</p>
<p id="rfc.section.14.4.p.2">The server response disclosure can be mitigated in the following two ways: </p>
<ol>
<li>Using the <samp>code</samp> response type. The response is sent over a TLS protected channel, where the Client is authenticated by the <samp>client_id</samp> and <samp>client_secret</samp>.</li>
<li>For other response types, the signed response can be encrypted with the Client's public key or a shared secret as an encrypted JWT with an appropriate key and cipher.</li>
</ol>
<h1 id="rfc.section.14.5"><a href="#rfc.section.14.5">14.5.</a> <a href="#server_response_repudiation" id="server_response_repudiation">Server Response Repudiation</a></h1>
<p id="rfc.section.14.5.p.1">A response might be repudiated by the server if the proper mechanisms are not in place. For example, if a Server does not digitally sign a response, the Server can claim that it was not generated through the services of the Server.</p>
<p id="rfc.section.14.5.p.2">To mitigate this threat, the response MAY be digitally signed by the Server using a key that supports non-repudiation. The Client SHOULD validate the digital signature to verify that it was issued by a legitimate Server and its integrity is intact.</p>
<h1 id="rfc.section.14.6"><a href="#rfc.section.14.6">14.6.</a> <a href="#request_repudation" id="request_repudation">Request Repudiation</a></h1>
<p id="rfc.section.14.6.p.1">Since it is possible for a compromised or malicious Client to send a request to the wrong party, a Client that was authenticated using only a bearer token can repudiate any transaction.</p>
<p id="rfc.section.14.6.p.2">To mitigate this threat, the Server MAY require that the request be digitally signed by the Client using a key that supports non-repudiation. The Server SHOULD validate the digital signature to verify that it was issued by a legitimate Client and the integrity is intact.</p>
<h1 id="rfc.section.14.7"><a href="#rfc.section.14.7">14.7.</a> <a href="#access_token_redirect" id="access_token_redirect">Access Token Redirect</a></h1>
<p id="rfc.section.14.7.p.1">An Attacker uses the Access Token generated for one resource to obtain access to a second resource.</p>
<p id="rfc.section.14.7.p.2">To mitigate this threat, the Access Token SHOULD be audience and scope restricted. One way of implementing it is to include the identifier of the resource for whom it was generated as audience. The resource verifies that incoming tokens include its identifier as the audience of the token.</p>
<h1 id="rfc.section.14.8"><a href="#rfc.section.14.8">14.8.</a> <a href="#token_reuse" id="token_reuse">Token Reuse</a></h1>
<p id="rfc.section.14.8.p.1">An Attacker attempts to use a one-time use token such as an Authorization Code that has already been used once with the intended Resource. To mitigate this threat, the token SHOULD include a timestamp and a short validity lifetime. The Relying Party then checks the timestamp and lifetime values to ensure that the token is currently valid.</p>
<p id="rfc.section.14.8.p.2">Alternatively, the server MAY record the state of the use of the token and check the status for each request.</p>
<h1 id="rfc.section.14.9"><a href="#rfc.section.14.9">14.9.</a> <a href="#auth_code_capture" id="auth_code_capture"> Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)</a></h1>
<p id="rfc.section.14.9.p.1">In addition to the attack patterns described in Section 4.4.1.1 of <a href="#RFC6819">[RFC6819]</a>, an Authorization Code can be captured in the User-Agent where the TLS session is terminated if the User-Agent is infected by malware. However, capturing it is not useful as long as the profile uses either Client authentication or an encrypted response.</p>
<h1 id="rfc.section.14.10"><a href="#rfc.section.14.10">14.10.</a> <a href="#token_substitution" id="token_substitution">Token Substitution</a></h1>
<p id="rfc.section.14.10.p.1">Token Substitution is a class of attacks in which a malicious user swaps various tokens, including swapping an Authorization Code for a legitimate user with another token that the attacker has. One means of accomplishing this is for the attacker to copy a token out one session and use it in an HTTP message for a different session, which is easy to do when the token is available to the browser; this is known as the "cut and paste" attack.</p>
<p id="rfc.section.14.10.p.2">The implicit flow of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite> is not designed to mitigate this risk. In Section 10.16, it normatively requires that any use of the authorization process as a form of delegated End-User authentication to the Client MUST NOT use the implicit flow without employing additional security mechanisms that enable the Client to determine whether the Access Token was issued for its use.</p>
<p id="rfc.section.14.10.p.3">In OpenID Connect, this is mitigated through mechanisms provided through the ID Token. The ID Token is a signed security token that provides Claims such as <samp>iss</samp> (issuer), <samp>sub</samp> (subject), <samp>aud</samp> (audience), <samp>azp</samp> (authorized party), <samp>at_hash</samp> (access token hash), and <samp>c_hash</samp> (code hash). Using the ID Token, the Client is capable of detecting the Token Substitution Attack.</p>
<p id="rfc.section.14.10.p.4">The <samp>c_hash</samp> in the ID Token enables Clients to prevent <samp>code</samp> substitution.</p>
<p id="rfc.section.14.10.p.5">Also, a malicious user may attempt to impersonate a more privileged user by subverting the communication channel between the Authorization Endpoint and Client, or the Token Endpoint and Client, for example by swapping the <samp>code</samp> or reordering the messages, to convince the Token Endpoint that the attacker's authorization grant corresponds to a grant sent on behalf of a more privileged user.</p>
<p id="rfc.section.14.10.p.6">For HTTP bindings such as OpenID Connect Standard 1.0, the responses to Token Requests are bound to the corresponding requests by message order in HTTP, as both the response containing the token and requests are protected by TLS, which will detect and prevent packet reordering.</p>
<p id="rfc.section.14.10.p.7">When designing another binding of OpenID Connect Messages to a protocol incapable of strongly binding Token Endpoint requests to responses, additional mechanisms to address this issue MUST be utilized. One such mechanism could be to include an ID Token with a <samp>c_hash</samp> Claim in the token request and response.</p>
<h1 id="rfc.section.14.11"><a href="#rfc.section.14.11">14.11.</a> <a href="#TimingAttack" id="TimingAttack">Timing Attack</a></h1>
<p id="rfc.section.14.11.p.1">A timing attack allows the attacker to obtain an unnecessary large amount of information through the elapsed time differences in the code paths taken by successful and unsuccessful decryption operations or successful and unsuccessful signature validation of a message. It can be used to reduce the effective key length of the cipher used.</p>
<p id="rfc.section.14.11.p.2">Implementations SHOULD NOT terminate the validation process at the instant of the finding an error but SHOULD continue running until all the octets have been processed to avoid this attack.</p>
<h1 id="rfc.section.14.12"><a href="#rfc.section.14.12">14.12.</a> <a href="#OtherCryptoAttacks" id="OtherCryptoAttacks">Other Crypto Related Attacks</a></h1>
<p id="rfc.section.14.12.p.1">There are various crypto related attacks possible depending on the method used for encryption and signature / integrity checking. Implementers need to consult the Security Considerations for the <a href="#JWT">JWT</a> <cite title="NONE">[JWT]</cite> specification and specifications that it references to avoid the vulnerabilities identified in these specifications.</p>
<h1 id="rfc.section.14.13"><a href="#rfc.section.14.13">14.13.</a> <a href="#signing_order" id="signing_order">Signing and Encryption Order</a></h1>
<p id="rfc.section.14.13.p.1">Signatures over encrypted text are not considered valid in many jurisdictions. Therefore, for integrity and non-repudiation, this specification requires signing the plain text JSON Claims.</p>
<h1 id="rfc.section.14.14"><a href="#rfc.section.14.14">14.14.</a> <a href="#issuer_identifier" id="issuer_identifier">Issuer Identifier</a></h1>
<p id="rfc.section.14.14.p.1">OpenID Connect supports multiple issuers per Host and Port combination. The issuer returned by discovery MUST exactly match the value of <samp>iss</samp> in the ID Token.</p>
<p id="rfc.section.14.14.p.2">OpenID Connect treats the path component of any URI as part of the user identifier. For instance, the subject "1234" with an issuer of "https://example.com" is not equivalent to the subject "1234" with an issuer of "https://example.com/sales".</p>
<p id="rfc.section.14.14.p.3">It is RECOMMENDED that only a single issuer per host be used.</p>
<h1 id="rfc.section.14.15"><a href="#rfc.section.14.15">14.15.</a> <a href="#TLS_requirements" id="TLS_requirements">TLS Requirements</a></h1>
<p id="rfc.section.14.15.p.1">Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 <a href="#RFC5246">[RFC5246]</a> is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 <a href="#RFC2246">[RFC2246]</a> is the most widely deployed version, and will give the broadest interoperability.</p>
<p id="rfc.section.14.15.p.2">To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.</p>
<p id="rfc.section.14.15.p.3">Whenever TLS is used, a TLS server certificate check MUST be performed, per <a href="#RFC6125">RFC 6125</a> <cite title="NONE">[RFC6125]</cite>.</p>
<h1 id="rfc.section.14.16"><a href="#rfc.section.14.16">14.16.</a> <a href="#token_lifetime" id="token_lifetime">Lifetimes of Access Tokens and Refresh Tokens</a></h1>
<p id="rfc.section.14.16.p.1">Access Token grants are not revocable by the Authorization Server. Access Token grant lifetimes SHOULD be kept to single use or very short lifetimes.</p>
<p id="rfc.section.14.16.p.2">If access to the UserInfo Endpoint or other protected resources is required, a Refresh Token SHOULD be used. The Client MAY then exchange the Refresh Token at the Token Endpoint for a fresh short-lived Access Token that can be used to access the resource.</p>
<p id="rfc.section.14.16.p.3">The Authorization Server SHOULD clearly identify long-term grants to the User during Authorization. The Authorization Server SHOULD provide a mechanism for the End-User to revoke Refresh Tokens granted to a Client.</p>
<h1 id="rfc.section.14.17"><a href="#rfc.section.14.17">14.17.</a> <a href="#SymmetricKeyEntropy" id="SymmetricKeyEntropy">Symmetric Key Entropy</a></h1>
<p id="rfc.section.14.17.p.1">In <a href="#sigs">Section 9.3</a> and <a href="#enc">Section 9.4</a>, keys are derived from the <samp>client_secret</samp> value. Thus, when used with symmetric signing or encryption operations, <samp>client_secret</samp> values MUST contain sufficient entropy to generate cryptographically strong keys. Also, <samp>client_secret</samp> values MUST also contain at least the minimum of number of octets required for MAC keys for the particular algorithm used. So for instance, for <samp>HS256</samp>, the <samp>client_secret</samp> value MUST contain at least 8 octets (and almost certainly SHOULD contain more, since <samp>client_secret</samp> values are likely to use a restricted alphabet.</p>
<h1 id="rfc.section.14.18"><a href="#rfc.section.14.18">14.18.</a> <a href="#NeedForSignedRequests" id="NeedForSignedRequests">Need for Signed Requests</a></h1>
<p id="rfc.section.14.18.p.1">In some situations, Clients might need to use signed requests to ensure that the desired request parameters are delivered to the OP without having been tampered with. For instance, the <samp>max_age</samp> and <samp>acr_values</samp> provide more assurance about the nature of the authentication performed when delivered in signed requests.</p>
<h1 id="rfc.section.14.19"><a href="#rfc.section.14.19">14.19.</a> <a href="#NeedForEncryptedRequests" id="NeedForEncryptedRequests">Need for Encrypted Requests</a></h1>
<p id="rfc.section.14.19.p.1">In some situations, knowing the contents of an OpenID Connect request can, in and of itself, reveal sensitive information about the End-User. For instance, knowing that the Client is requesting a particular Claim or that it is requesting that a particular authentication method be used can reveal sensitive information about the End-User. OpenID Connect enables requests to be encrypted to the OpenID Provider to prevent such potentially sensitive information from being revealed.</p>
<h1 id="rfc.section.15"><a href="#rfc.section.15">15.</a> <a href="#privacy_considerations" id="privacy_considerations">Privacy Considerations</a></h1>
<h1 id="rfc.section.15.1"><a href="#rfc.section.15.1">15.1.</a> <a href="#PII" id="PII">Personally Identifiable Information</a></h1>
<p id="rfc.section.15.1.p.1">The UserInfo Response typically contains Personally Identifiable Information (PII). As such, End-User consent for the release of the information for the specified purpose SHOULD be obtained at or prior to the authorization time in accordance with relevant regulations. The purpose of use is typically registered in association with the <samp>redirect_uris</samp>.</p>
<p id="rfc.section.15.1.p.2">Only necessary UserInfo data should be stored at the Client and the Client SHOULD associate the received data with the purpose of use statement.</p>
<h1 id="rfc.section.15.2"><a href="#rfc.section.15.2">15.2.</a> <a href="#AccessMonitoring" id="AccessMonitoring">Data Access Monitoring</a></h1>
<p id="rfc.section.15.2.p.1">The Resource Server SHOULD make the UserInfo access log available to the End-User so that the End-User can monitor who accessed his data.</p>
<h1 id="rfc.section.15.3"><a href="#rfc.section.15.3">15.3.</a> <a href="#Correlation" id="Correlation">Correlation</a></h1>
<p id="rfc.section.15.3.p.1">To protect the End-User from a possible correlation among Clients, the use of a Pairwise Pseudonymous Identifier (PPID) as the <samp>sub</samp> (subject) SHOULD be considered.</p>
<h1 id="rfc.section.15.4"><a href="#rfc.section.15.4">15.4.</a> <a href="#OfflineAccessPrivacy" id="OfflineAccessPrivacy">Offline Access</a></h1>
<p id="rfc.section.15.4.p.1">Offline access enables access to Claims when the user is not present, posing greater privacy risk than the Claims transfer when the user is present. Therefore, it is prudent to obtain explicit consent for offline access to resources. This specification mandates the use of the <samp>prompt</samp> parameter to obtain consent unless it is a priori known that the request complies with the conditions for processing in each jurisdiction.</p>
<p id="rfc.section.15.4.p.2">When an Access Token is returned in the front channel, there is a greater risk of it being exposed to an attacker, who could later use it to access the UserInfo endpoint. If the Access Token does not enable offline access and the server can differentiate whether the Client request has been made offline or online, the risk will be substantially reduced. Therefore, this specification mandates ignoring the offline access request when the Access Token is transmitted in the front channel. Note that differentiating between online and offline access from the server can be difficult especially for native clients. The server may well have to rely on heuristics. Also, the risk of exposure for the Access Token delivered in the front channel for the response types of <samp>code token</samp> and <samp>token</samp> is the same. Thus, the implementations should be prepared to detect the channel from which the Access Token was issued and deny offline access if the token was issued in the front channel.</p>
<p id="rfc.section.15.4.p.3">Note that although these provisions require an explicit consent dialogue through the <samp>prompt</samp> parameter, the mere fact that the user pressed an "accept" button etc., might not constitute a valid consent. Developers should be aware that for the act of consent to be valid, typically, the impact of the terms have to be understood by the End-User, the consent must be freely given and not forced (i.e., other options have to be available), and the terms must fair and equitable. In general, it is advisable for the service to follow the required privacy principles in each jurisdiction and rely on other conditions of processing than simply explicit consent, as online self-service "explicit consent" often does not form a valid consent in some jurisdictions.</p>
<h1 id="rfc.section.16"><a href="#rfc.section.16">16.</a> <a href="#IANA" id="IANA">IANA Considerations</a></h1>
<h1 id="rfc.section.16.1"><a href="#rfc.section.16.1">16.1.</a> <a href="#ClaimsRegistry" id="ClaimsRegistry">JSON Web Token Claims Registry</a></h1>
<p id="rfc.section.16.1.p.1">This specification registers the Claims defined in <a href="#StandardClaims">Section 8</a> and <a href="#id_token">Section 3.2.1</a> in the IANA JSON Web Token Claims registry defined in <a href="#JWT">[JWT]</a>.</p>
<h1 id="rfc.section.16.1.1"><a href="#rfc.section.16.1.1">16.1.1.</a> <a href="#ClaimsContents" id="ClaimsContents">Registry Contents</a></h1>
<p/>
<ul>
<li>Claim Name: <samp>name</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>given_name</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>family_name</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>middle_name</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>nickname</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>preferred_username</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>profile</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>picture</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>website</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>email</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>email_verified</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>gender</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>birthdate</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>zoneinfo</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>locale</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>phone_number</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>address</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>updated_at</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#StandardClaims">Section 8</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>azp</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>nonce</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>auth_time</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>at_hash</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>c_hash</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>acr</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>amr</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<p/>
<ul>
<li>Claim Name: <samp>sub_jwk</samp></li>
<li>Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification Document(s): <a href="#id_token">Section 3.2.1</a> of this document</li>
</ul>
<h1 id="rfc.section.16.2"><a href="#rfc.section.16.2">16.2.</a> <a href="#OAuthParametersRegistry" id="OAuthParametersRegistry">OAuth Parameters Registry</a></h1>
<p id="rfc.section.16.2.p.1">This specification registers the following parameters in the IANA OAuth Parameters registry defined in <a href="#RFC6749">RFC 6749</a> <cite title="NONE">[RFC6749]</cite>.</p>
<h1 id="rfc.section.16.2.1"><a href="#rfc.section.16.2.1">16.2.1.</a> <a href="#ParametersContents" id="ParametersContents">Registry Contents</a></h1>
<p/>
<ul>
<li>Parameter name: <samp>nonce</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>display</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>prompt</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>max_age</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>ui_locales</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>claims_locales</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>id_token_hint</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>login_hint</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>acr_values</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>claims</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>registration</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>request</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>request_uri</samp></li>
<li>Parameter usage location: Authorization Request</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#RequestParameters">Section 3.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<p/>
<ul>
<li>Parameter name: <samp>id_token</samp></li>
<li>Parameter usage location: Authorization Response, Access Token Response</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#access_token_response">Section 4.1</a> of this document</li>
<li>Related information: None</li>
</ul>
<h1 id="rfc.section.16.3"><a href="#rfc.section.16.3">16.3.</a> <a href="#OAuthErrorRegistry" id="OAuthErrorRegistry">OAuth Extensions Error Registry</a></h1>
<p id="rfc.section.16.3.p.1">This specification registers the following errors in the IANA OAuth Extensions Error registry defined in <a href="#RFC6749">RFC 6749</a> <cite title="NONE">[RFC6749]</cite>.</p>
<h1 id="rfc.section.16.3.1"><a href="#rfc.section.16.3.1">16.3.1.</a> <a href="#ErrorContents" id="ErrorContents">Registry Contents</a></h1>
<p/>
<ul>
<li>Error name: <samp>interaction_required</samp></li>
<li>Error usage location: Authorization Endpoint</li>
<li>Related protocol extension: OpenID Connect</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#AuthError">Section 3.3.4</a> of this document</li>
</ul>
<p/>
<ul>
<li>Error name: <samp>login_required</samp></li>
<li>Error usage location: Authorization Endpoint</li>
<li>Related protocol extension: OpenID Connect</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#AuthError">Section 3.3.4</a> of this document</li>
</ul>
<p/>
<ul>
<li>Error name: <samp>session_selection_required</samp></li>
<li>Error usage location: Authorization Endpoint</li>
<li>Related protocol extension: OpenID Connect</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#AuthError">Section 3.3.4</a> of this document</li>
</ul>
<p/>
<ul>
<li>Error name: <samp>consent_required</samp></li>
<li>Error usage location: Authorization Endpoint</li>
<li>Related protocol extension: OpenID Connect</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#AuthError">Section 3.3.4</a> of this document</li>
</ul>
<p/>
<ul>
<li>Error name: <samp>invalid_request_uri</samp></li>
<li>Error usage location: Authorization Endpoint</li>
<li>Related protocol extension: OpenID Connect</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#AuthError">Section 3.3.4</a> of this document</li>
</ul>
<p/>
<ul>
<li>Error name: <samp>invalid_request_object</samp></li>
<li>Error usage location: Authorization Endpoint</li>
<li>Related protocol extension: OpenID Connect</li>
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</li>
<li>Specification document(s): <a href="#AuthError">Section 3.3.4</a> of this document</li>
</ul>
<h1 id="rfc.references"><a href="#rfc.references">17.</a> References</h1>
<h1 id="rfc.references.1"><a href="#rfc.references.1">17.1.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="E.164">[E.164]</b>
</td>
<td class="top"><a>International Telecommunication Union</a>, "<a>E.164: The international public telecommunication numbering plan</a>", 2010.</td>
</tr>
<tr>
<td class="reference">
<b id="IANA.Language">[IANA.Language]</b>
</td>
<td class="top"><a>Internet Assigned Numbers Authority (IANA)</a>, "<a>Language Subtag Registry</a>", 2005.</td>
</tr>
<tr>
<td class="reference">
<b id="ISO29115">[ISO29115]</b>
</td>
<td class="top"><a>International Organization for Standardization</a>, "<a>ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework</a>", ISO/IEC 29115, March 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="ISO3166-1">[ISO3166-1]</b>
</td>
<td class="top"><a>International Organization for Standardization</a>, "<a>ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes</a>", 1997.</td>
</tr>
<tr>
<td class="reference">
<b id="ISO639-1">[ISO639-1]</b>
</td>
<td class="top"><a>International Organization for Standardization</a>, "<a>ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code</a>", 2002.</td>
</tr>
<tr>
<td class="reference">
<b id="ISO8601-2004">[ISO8601-2004]</b>
</td>
<td class="top"><a>International Organization for Standardization</a>, "<a>ISO 8601:2004. Data elements and interchange formats - Information interchange - Representation of dates and times</a>", 2004.</td>
</tr>
<tr>
<td class="reference">
<b id="JWA">[JWA]</b>
</td>
<td class="top"><a title="Microsoft">Jones, M.</a>, "<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms">JSON Web Algorithms (JWA)</a>", Internet-Draft draft-ietf-jose-json-web-algorithms, May 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="JWE">[JWE]</b>
</td>
<td class="top"><a title="Microsoft">Jones, M.</a>, <a title="RTFM, Inc.">Rescorla, E.</a> and <a title="Cisco Systems, Inc.">J. Hildebrand</a>, "<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption">JSON Web Encryption (JWE)</a>", Internet-Draft draft-ietf-jose-json-web-encryption, May 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="JWK">[JWK]</b>
</td>
<td class="top"><a title="Microsoft">Jones, M.</a>, "<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key">JSON Web Key (JWK)</a>", Internet-Draft draft-ietf-jose-json-web-key, May 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="JWS">[JWS]</b>
</td>
<td class="top"><a title="Microsoft">Jones, M.</a>, <a title="Ping Identity">Bradley, J.</a> and <a title="Nomura Research Institute, Ltd.">N. Sakimura</a>, "<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">JSON Web Signature (JWS)</a>", Internet-Draft draft-ietf-jose-json-web-signature, May 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="JWT">[JWT]</b>
</td>
<td class="top"><a title="Microsoft">Jones, M.</a>, <a title="Ping Identity">Bradley, J.</a> and <a title="Nomura Research Institute, Ltd.">N. Sakimura</a>, "<a href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token">JSON Web Token (JWT)</a>", Internet-Draft draft-ietf-oauth-json-web-token, May 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OAuth.Assertions">[OAuth.Assertions]</b>
</td>
<td class="top"><a title="Ping Identity">Campbell, B.</a>, <a title="Salesforce.com">Mortimore, C.</a>, <a title="Microsoft">Jones, M.</a> and <a title="Microsoft">Y. Goland</a>, "<a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions">Assertion Framework for OAuth 2.0</a>", Internet-Draft draft-ietf-oauth-assertions, March 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OAuth.JWT">[OAuth.JWT]</b>
</td>
<td class="top"><a title="Microsoft">Jones, M.</a>, <a title="Ping Identity">Campbell, B.</a> and <a title="Salesforce">C. Mortimore</a>, "<a href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer">JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0</a>", Internet-Draft draft-ietf-oauth-jwt-bearer, March 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OAuth.Responses">[OAuth.Responses]</b>
</td>
<td class="top"><a title="Google">de Medeiros, B.</a>, <a title="Google">Scurtescu, M.</a> and <a title="Facebook">P. Tarjan</a>, "<a>OAuth 2.0 Multiple Response Type Encoding Practices</a>", June 2013.</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>OpenID Connect Discovery 1.0</a>", July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Registration">[OpenID.Registration]</b>
</td>
<td class="top"><a title="Nomura Research Institute, Ltd.">Sakimura, N.</a>, <a title="Ping Identity">Bradley, J.</a> and <a title="Microsoft">M. Jones</a>, "<a>OpenID Connect Dynamic Client Registration 1.0</a>", July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">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.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2246">[RFC2246]</b>
</td>
<td class="top"><a href="mailto:tdierks@certicom.com" title="Certicom">Dierks, T.</a> and <a href="mailto:callen@certicom.com" title="Certicom">C. Allen</a>, "<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>", RFC 2246, January 1999.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2616">[RFC2616]</b>
</td>
<td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a> and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, "<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>", RFC 2616, June 1999.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC3339">[RFC3339]</b>
</td>
<td class="top"><a href="mailto:GK@ACM.ORG" title="Clearswift Corporation">Klyne, G.</a> and <a href="mailto:chris.newman@sun.com" title="Sun Microsystems">C. Newman</a>, "<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>", RFC 3339, July 2002.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC3966">[RFC3966]</b>
</td>
<td class="top"><a>Schulzrinne, H.</a>, "<a href="http://tools.ietf.org/html/rfc3966">The tel URI for Telephone Numbers</a>", RFC 3966, December 2004.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC3986">[RFC3986]</b>
</td>
<td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a> and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, "<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>", STD 66, RFC 3986, January 2005.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC4627">[RFC4627]</b>
</td>
<td class="top"><a>Crockford, D.</a>, "<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>", RFC 4627, July 2006.</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, August 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5322">[RFC5322]</b>
</td>
<td class="top"><a href="mailto:presnick@qualcomm.com" title="Qualcomm Incorporated">Resnick, P.</a>, "<a href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>", RFC 5322, 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, September 2009.</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, March 2011.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6711">[RFC6711]</b>
</td>
<td class="top"><a>Johansson, L.</a>, "<a href="http://tools.ietf.org/html/rfc6711">An IANA Registry for Level of Assurance (LoA) Profiles</a>", RFC 6711, August 2012.</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, 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, 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, January 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="USA15">[USA15]</b>
</td>
<td class="top"><a href="mailto:markdavis@google.com">Davis, M.</a>, <a href="mailto:ken@unicode.org">Whistler, K.</a> and <a>M. Dürst</a>, "<a>Unicode Normalization Forms</a>", Unicode Standard Annex 15, 09 2009.</td>
</tr>
<tr>
<td class="reference">
<b id="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</b>
</td>
<td class="top"><a>Hors, A.</a>, <a>Raggett, D.</a> and <a>I. Jacobs</a>, "<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999.</td>
</tr>
<tr>
<td class="reference">
<b id="zoneinfo">[zoneinfo]</b>
</td>
<td class="top"><a>Public Domain</a>, "<a>The tz database</a>", June 2011.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.references.2"><a href="#rfc.references.2">17.2.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="OpenID.2.0">[OpenID.2.0]</b>
</td>
<td class="top"><a>OpenID Foundation</a>, "<a>OpenID Authentication 2.0</a>", December 2007.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Basic">[OpenID.Basic]</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>OpenID Connect Basic Client Profile 1.0</a>", July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Implicit">[OpenID.Implicit]</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>, <a title="Salesforce">Mortimore, C.</a> and <a title="Illumila">E. Jay</a>, "<a>OpenID Connect Implicit Client Profile 1.0</a>", July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.PAPE">[OpenID.PAPE]</b>
</td>
<td class="top"><a href="mailto:david@sixapart.com" title="Six Apart, Ltd.">Recordon, D.</a>, <a href="mailto:mbj@microsoft.com" title="Microsoft Corporation">Jones, M.</a>, <a href="mailto:johnny.bufu@gmail.com" title="Independent">Bufu, J.</a>, <a href="mailto:cygnus@janrain.com" title="JanRain">Daugherty, J.</a> and <a href="mailto:n-sakimura@nri.co.jp" title="Nomura Research Institute, Ltd.">N. Sakimura</a>, "<a>OpenID Provider Authentication Policy Extension 1.0</a>", December 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Session">[OpenID.Session]</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>, <a title="Salesforce">Mortimore, C.</a> and <a title="Illumila">E. Jay</a>, "<a>OpenID Connect Session Management 1.0</a>", July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Standard">[OpenID.Standard]</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>, <a title="Salesforce">Mortimore, C.</a> and <a title="Illumila">E. Jay</a>, "<a>OpenID Connect Standard 1.0</a>", July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC4949">[RFC4949]</b>
</td>
<td class="top"><a>Shirey, R.</a>, "<a href="http://tools.ietf.org/html/rfc4949">Internet Security Glossary, Version 2</a>", RFC 4949, August 2007.</td>
</tr>
<tr>
<td class="reference">
<b id="X.1252">[X.1252]</b>
</td>
<td class="top"><a>International Telecommunication Union</a>, "<a>ITU-T Recommendation X.1252 -- Cyberspace security -- Identity management -- Baseline identity management terms and definitions</a>", ITU-T X.1252, November 2010.</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">As a successor version of OpenID, this specification heavily relies on ideas explored in <a href="#OpenID.2.0">OpenID Authentication 2.0</a> <cite title="NONE">[OpenID.2.0]</cite>. Please refer to Appendix C of OpenID Authentication 2.0 for the full list of the contributors for that specification.</p>
<p id="rfc.section.A.p.2">In addition, the OpenID Community would like to thank the following people for the work they have done in the drafting and editing of this specification.</p>
<p/>
<ul class="empty">
<li>Naveen Agarwal (naa@google.com), Google</li>
<li>Amanda Anganes (aanganes@mitre.org), Mitre</li>
<li>Casper Biering (cb@peercraft.com), Peercraft</li>
<li>John Bradley (ve7jtb@ve7jtb.com), Ping Identity</li>
<li>Tim Bray (tbray@textuality.com), Google</li>
<li>Johnny Bufu (jbufu@janrain.com), Janrain</li>
<li>Brian Campbell (bcampbell@pingidentity.com), Ping Identity</li>
<li>Breno de Medeiros (breno@gmail.com), Google</li>
<li>Pamela Dingle (pdingle@pingidentity.com), Ping Identity</li>
<li>Vladimir Dzhuvinov (vladimir@nimbusds.com), Nimbus Directory Services</li>
<li>George Fletcher (george.fletcher@corp.aol.com), AOL</li>
<li>Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea</li>
<li>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.</li>
<li>Edmund Jay (ejay@mgi1.com), Illumila</li>
<li>Michael B. Jones (mbj@microsoft.com), Microsoft</li>
<li>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom</li>
<li>Nov Matake (nov@matake.jp), Independent</li>
<li>Chuck Mortimore (cmortimore@salesforce.com), Salesforce</li>
<li>Anthony Nadalin (tonynad@microsoft.com), Microsoft</li>
<li>Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications</li>
<li>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom</li>
<li>David Recordon (dr@fb.com), Facebook</li>
<li>Justin Richer (jricher@mitre.org), Mitre</li>
<li>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.</li>
<li>Luke Shepard (lshepard@fb.com), Facebook</li>
<li>Andreas Akre Solberg (andreas.solberg@uninett.no), UNINET</li>
<li>Paul Tarjan (pt@fb.com), Facebook</li>
</ul>
<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) 2013 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.authors">
<a href="#rfc.authors">Authors' Addresses</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Nat Sakimura</span>
<span class="n hidden">
<span class="family-name">Sakimura</span>
</span>
</span>
<span class="org vcardline">Nomura Research Institute, Ltd.</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:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">John Bradley</span>
<span class="n hidden">
<span class="family-name">Bradley</span>
</span>
</span>
<span class="org vcardline">Ping Identity</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:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Michael B. Jones</span>
<span class="n hidden">
<span class="family-name">Jones</span>
</span>
</span>
<span class="org vcardline">Microsoft</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:mbj@microsoft.com">mbj@microsoft.com</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Breno de Medeiros</span>
<span class="n hidden">
<span class="family-name">de Medeiros</span>
</span>
</span>
<span class="org vcardline">Google</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:breno@google.com">breno@google.com</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Chuck Mortimore</span>
<span class="n hidden">
<span class="family-name">Mortimore</span>
</span>
</span>
<span class="org vcardline">Salesforce</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:cmortimore@salesforce.com">cmortimore@salesforce.com</a></span>
</address>
</div>
</body>
</html>