<!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>FastFed Core 1.0 - draft 01</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Requirements Notation and Conventions">
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 Overview">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Metadata">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Endpoints">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Endpoint Discovery">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 FastFed Handshake">
<link href="#rfc.section.2.5" rel="Chapter" title="2.5 User Schemas and Provisioning">
<link href="#rfc.section.2.5.1" rel="Chapter" title="2.5.1 Schema Selection">
<link href="#rfc.section.2.5.2" rel="Chapter" title="2.5.2 Attribute Filtering">
<link href="#rfc.section.3" rel="Chapter" title="3 Metadata">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Metadata Serialization">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Metadata Languages and Scripts">
<link href="#rfc.section.3.3" rel="Chapter" title="3.3 Provider Metadata">
<link href="#rfc.section.3.3.1" rel="Chapter" title="3.3.1 Capabilities">
<link href="#rfc.section.3.3.2" rel="Chapter" title="3.3.2 Display Settings">
<link href="#rfc.section.3.3.3" rel="Chapter" title="3.3.3 Provider Authentication Metadata">
<link href="#rfc.section.3.3.4" rel="Chapter" title="3.3.4 Common Provider Metadata">
<link href="#rfc.section.3.3.5" rel="Chapter" title="3.3.5 Identity Provider Metadata">
<link href="#rfc.section.3.3.6" rel="Chapter" title="3.3.6 Application Provider Metadata">
<link href="#rfc.section.4" rel="Chapter" title="4 Metadata Endpoints">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Provider Metadata Endpoint">
<link href="#rfc.section.4.1.1" rel="Chapter" title="4.1.1 Endpoint Validation">
<link href="#rfc.section.4.1.2" rel="Chapter" title="4.1.2 Endpoint Discovery">
<link href="#rfc.section.4.1.2.1" rel="Chapter" title="4.1.2.1 Email-based Discovery via WebFinger">
<link href="#rfc.section.4.1.2.1.1" rel="Chapter" title="4.1.2.1.1 WebFinger Endpoints">
<link href="#rfc.section.4.1.2.1.2" rel="Chapter" title="4.1.2.1.2 WebFinger Queries">
<link href="#rfc.section.4.1.2.2" rel="Chapter" title="4.1.2.2 Alternative Discovery Mechanisms">
<link href="#rfc.section.4.1.3" rel="Chapter" title="4.1.3 Read Request">
<link href="#rfc.section.4.1.4" rel="Chapter" title="4.1.4 Read Response">
<link href="#rfc.section.4.1.5" rel="Chapter" title="4.1.5 Metadata Refresh">
<link href="#rfc.section.5" rel="Chapter" title="5 Provider Compatibility Evaluation">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Handling Empty Capabilities">
<link href="#rfc.section.6" rel="Chapter" title="6 Provider Authentication Methods">
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Key Discovery">
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Key Rotation">
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 Algorithm Selection">
<link href="#rfc.section.6.4" rel="Chapter" title="6.4 JWT Requirements">
<link href="#rfc.section.6.5" rel="Chapter" title="6.5 Protocol-specific Key Materials">
<link href="#rfc.section.6.6" rel="Chapter" title="6.6 OAuth Access Tokens">
<link href="#rfc.section.6.7" rel="Chapter" title="6.7 OAuth Client Registration">
<link href="#rfc.section.7" rel="Chapter" title="7 FastFed Handshake">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Common Considerations">
<link href="#rfc.section.7.1.1" rel="Chapter" title="7.1.1 TLS Requirements">
<link href="#rfc.section.7.1.2" rel="Chapter" title="7.1.2 HTTP Redirects">
<link href="#rfc.section.7.1.3" rel="Chapter" title="7.1.3 Query String Serialization">
<link href="#rfc.section.7.1.4" rel="Chapter" title="7.1.4 Halting the Handshake">
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Handshake Flow">
<link href="#rfc.section.7.2.1" rel="Chapter" title="7.2.1 Handshake Initiation at Application Provider">
<link href="#rfc.section.7.2.1.1" rel="Chapter" title="7.2.1.1 Prerequisites">
<link href="#rfc.section.7.2.1.2" rel="Chapter" title="7.2.1.2 Application Provider Reads Identity Provider Metadata">
<link href="#rfc.section.7.2.1.3" rel="Chapter" title="7.2.1.3 Application Provider Verifies Compatibility with Identity Provider">
<link href="#rfc.section.7.2.1.4" rel="Chapter" title="7.2.1.4 Application Provider Whitelists the Identity Provider">
<link href="#rfc.section.7.2.1.5" rel="Chapter" title="7.2.1.5 Application Provider Sends Request to the Identity Provider">
<link href="#rfc.section.7.2.1.5.1" rel="Chapter" title="7.2.1.5.1 HTTP Redirect">
<link href="#rfc.section.7.2.1.5.2" rel="Chapter" title="7.2.1.5.2 Alternative Channel">
<link href="#rfc.section.7.2.2" rel="Chapter" title="7.2.2 Handshake Receipt by Identity Provider">
<link href="#rfc.section.7.2.2.1" rel="Chapter" title="7.2.2.1 Identity Provider Authenticates Administrator">
<link href="#rfc.section.7.2.2.2" rel="Chapter" title="7.2.2.2 Identity Provider Reads Application Provider Metadata">
<link href="#rfc.section.7.2.2.3" rel="Chapter" title="7.2.2.3 Identity Provider Verifies Compatibility">
<link href="#rfc.section.7.2.2.4" rel="Chapter" title="7.2.2.4 Identity Provider Obtains Consent from Administrator">
<link href="#rfc.section.7.2.3" rel="Chapter" title="7.2.3 Handshake Registration">
<link href="#rfc.section.7.2.3.1" rel="Chapter" title="7.2.3.1 Identity Provider Sends Registration Request">
<link href="#rfc.section.7.2.3.2" rel="Chapter" title="7.2.3.2 Application Provider Handles Registration Request">
<link href="#rfc.section.7.2.3.3" rel="Chapter" title="7.2.3.3 Application Provider Sends Registration Response">
<link href="#rfc.section.7.2.3.4" rel="Chapter" title="7.2.3.4 Identity Provider Handles Registration Response">
<link href="#rfc.section.7.2.4" rel="Chapter" title="7.2.4 Handshake Finalization">
<link href="#rfc.section.8" rel="Chapter" title="8 Security Considerations">
<link href="#rfc.section.9" rel="Chapter" title="9 IANA Considerations">
<link href="#rfc.references" rel="Chapter" title="10 Normative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements">
<link href="#rfc.appendix.B" rel="Chapter" title="B Notices">
<link href="#rfc.appendix.C" rel="Chapter" title="C Document History">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.15.4 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="McAdams, D." />
<meta name="dct.identifier" content="urn:ietf:id:fastfed-01" />
<meta name="dct.issued" scheme="ISO8601" content="2019-08-27" />
<meta name="dct.abstract" content="FastFed simplifies the administrative effort to configure identity federation between an identity provider and a hosted application. The specification defines metadata documents, APIs, and flows to enable an administrator to quickly connect two providers that support common standards such as OpenID Connect, SAML, and SCIM, and allows configuration changes to be communicated directly between the identity provider and hosted application on a recurring basis. " />
<meta name="description" content="FastFed simplifies the administrative effort to configure identity federation between an identity provider and a hosted application. The specification defines metadata documents, APIs, and flows to enable an administrator to quickly connect two providers that support common standards such as OpenID Connect, SAML, and SCIM, and allows configuration changes to be communicated directly between the identity provider and hosted application on a recurring basis. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left"></td>
<td class="right">D. McAdams</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Amazon</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">August 27, 2019</td>
</tr>
</tbody>
</table>
<p class="title">FastFed Core 1.0 - draft 01<br />
<span class="filename">fastfed-01</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>FastFed simplifies the administrative effort to configure identity federation between an identity provider and a hosted application. The specification defines metadata documents, APIs, and flows to enable an administrator to quickly connect two providers that support common standards such as OpenID Connect, SAML, and SCIM, and allows configuration changes to be communicated directly between the identity provider and hosted application on a recurring basis. </p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Requirements Notation and Conventions</a>
</li>
<li>1.2. <a href="#rfc.section.1.2">Terminology</a>
</li>
</ul><li>2. <a href="#rfc.section.2">Overview</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Metadata</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Endpoints</a>
</li>
<li>2.3. <a href="#rfc.section.2.3">Endpoint Discovery</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">FastFed Handshake</a>
</li>
<li>2.5. <a href="#rfc.section.2.5">User Schemas and Provisioning</a>
</li>
<ul><li>2.5.1. <a href="#rfc.section.2.5.1">Schema Selection</a>
</li>
<li>2.5.2. <a href="#rfc.section.2.5.2">Attribute Filtering</a>
</li>
</ul></ul><li>3. <a href="#rfc.section.3">Metadata</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Metadata Serialization</a>
</li>
<li>3.2. <a href="#rfc.section.3.2">Metadata Languages and Scripts</a>
</li>
<li>3.3. <a href="#rfc.section.3.3">Provider Metadata</a>
</li>
<ul><li>3.3.1. <a href="#rfc.section.3.3.1">Capabilities</a>
</li>
<li>3.3.2. <a href="#rfc.section.3.3.2">Display Settings</a>
</li>
<li>3.3.3. <a href="#rfc.section.3.3.3">Provider Authentication Metadata</a>
</li>
<li>3.3.4. <a href="#rfc.section.3.3.4">Common Provider Metadata</a>
</li>
<li>3.3.5. <a href="#rfc.section.3.3.5">Identity Provider Metadata</a>
</li>
<li>3.3.6. <a href="#rfc.section.3.3.6">Application Provider Metadata</a>
</li>
</ul></ul><li>4. <a href="#rfc.section.4">Metadata Endpoints</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Provider Metadata Endpoint</a>
</li>
<ul><li>4.1.1. <a href="#rfc.section.4.1.1">Endpoint Validation</a>
</li>
<li>4.1.2. <a href="#rfc.section.4.1.2">Endpoint Discovery</a>
</li>
<ul><li>4.1.2.1. <a href="#rfc.section.4.1.2.1">Email-based Discovery via WebFinger</a>
</li>
<ul><li>4.1.2.1.1. <a href="#rfc.section.4.1.2.1.1">WebFinger Endpoints</a>
</li>
<li>4.1.2.1.2. <a href="#rfc.section.4.1.2.1.2">WebFinger Queries</a>
</li>
</ul><li>4.1.2.2. <a href="#rfc.section.4.1.2.2">Alternative Discovery Mechanisms</a>
</li>
</ul><li>4.1.3. <a href="#rfc.section.4.1.3">Read Request</a>
</li>
<li>4.1.4. <a href="#rfc.section.4.1.4">Read Response</a>
</li>
<li>4.1.5. <a href="#rfc.section.4.1.5">Metadata Refresh</a>
</li>
</ul></ul><li>5. <a href="#rfc.section.5">Provider Compatibility Evaluation</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Handling Empty Capabilities</a>
</li>
</ul><li>6. <a href="#rfc.section.6">Provider Authentication Methods</a>
</li>
<ul><li>6.1. <a href="#rfc.section.6.1">Key Discovery</a>
</li>
<li>6.2. <a href="#rfc.section.6.2">Key Rotation</a>
</li>
<li>6.3. <a href="#rfc.section.6.3">Algorithm Selection</a>
</li>
<li>6.4. <a href="#rfc.section.6.4">JWT Requirements</a>
</li>
<li>6.5. <a href="#rfc.section.6.5">Protocol-specific Key Materials</a>
</li>
<li>6.6. <a href="#rfc.section.6.6">OAuth Access Tokens</a>
</li>
<li>6.7. <a href="#rfc.section.6.7">OAuth Client Registration</a>
</li>
</ul><li>7. <a href="#rfc.section.7">FastFed Handshake</a>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">Common Considerations</a>
</li>
<ul><li>7.1.1. <a href="#rfc.section.7.1.1">TLS Requirements</a>
</li>
<li>7.1.2. <a href="#rfc.section.7.1.2">HTTP Redirects</a>
</li>
<li>7.1.3. <a href="#rfc.section.7.1.3">Query String Serialization</a>
</li>
<li>7.1.4. <a href="#rfc.section.7.1.4">Halting the Handshake</a>
</li>
</ul><li>7.2. <a href="#rfc.section.7.2">Handshake Flow</a>
</li>
<ul><li>7.2.1. <a href="#rfc.section.7.2.1">Handshake Initiation at Application Provider</a>
</li>
<ul><li>7.2.1.1. <a href="#rfc.section.7.2.1.1">Prerequisites</a>
</li>
<li>7.2.1.2. <a href="#rfc.section.7.2.1.2">Application Provider Reads Identity Provider Metadata</a>
</li>
<li>7.2.1.3. <a href="#rfc.section.7.2.1.3">Application Provider Verifies Compatibility with Identity Provider</a>
</li>
<li>7.2.1.4. <a href="#rfc.section.7.2.1.4">Application Provider Whitelists the Identity Provider</a>
</li>
<li>7.2.1.5. <a href="#rfc.section.7.2.1.5">Application Provider Sends Request to the Identity Provider</a>
</li>
<ul><li>7.2.1.5.1. <a href="#rfc.section.7.2.1.5.1">HTTP Redirect</a>
</li>
<li>7.2.1.5.2. <a href="#rfc.section.7.2.1.5.2">Alternative Channel</a>
</li>
</ul></ul><li>7.2.2. <a href="#rfc.section.7.2.2">Handshake Receipt by Identity Provider</a>
</li>
<ul><li>7.2.2.1. <a href="#rfc.section.7.2.2.1">Identity Provider Authenticates Administrator</a>
</li>
<li>7.2.2.2. <a href="#rfc.section.7.2.2.2">Identity Provider Reads Application Provider Metadata</a>
</li>
<li>7.2.2.3. <a href="#rfc.section.7.2.2.3">Identity Provider Verifies Compatibility</a>
</li>
<li>7.2.2.4. <a href="#rfc.section.7.2.2.4">Identity Provider Obtains Consent from Administrator</a>
</li>
</ul><li>7.2.3. <a href="#rfc.section.7.2.3">Handshake Registration</a>
</li>
<ul><li>7.2.3.1. <a href="#rfc.section.7.2.3.1">Identity Provider Sends Registration Request</a>
</li>
<li>7.2.3.2. <a href="#rfc.section.7.2.3.2">Application Provider Handles Registration Request</a>
</li>
<li>7.2.3.3. <a href="#rfc.section.7.2.3.3">Application Provider Sends Registration Response</a>
</li>
<li>7.2.3.4. <a href="#rfc.section.7.2.3.4">Identity Provider Handles Registration Response</a>
</li>
</ul><li>7.2.4. <a href="#rfc.section.7.2.4">Handshake Finalization</a>
</li>
</ul></ul><li>8. <a href="#rfc.section.8">Security Considerations</a>
</li>
<li>9. <a href="#rfc.section.9">IANA Considerations</a>
</li>
<li>10. <a href="#rfc.references">Normative References</a>
</li>
<li>Appendix A. <a href="#rfc.appendix.A">Acknowledgements</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Notices</a>
</li>
<li>Appendix C. <a href="#rfc.appendix.C">Document History</a>
</li>
<li><a href="#rfc.authors">Author's Address</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#Introduction" id="Introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">Despite the existence of well-established standards, identity federation remains difficult to configure and maintain. </p>
<p id="rfc.section.1.p.2">One source of difficulty arises because the existing standards each solve a portion of the ecosystem, such as authentication, schema definition, or end-user provisioning; but without a clear recommendation on how to assemble the pieces into a whole. As a result, each application may choose to assemble standards in different ways or even ignore them, such as by declaring their own user schema. The resulting impact is that each hosted application can be an architectural one-off that an administrator must study and understand before beginning to configure a federation relationship. </p>
<p id="rfc.section.1.p.3">Another area of difficulty arises because there is no standard mechanism for an identity provider and application provider to directly exchange metadata required by existing standards. Instead, a human administrator must copy-and-paste information between the two providers. This is typically done by opening a web page for each provider and following online instructions to copy information between them. Copy-and-paste errors, overlooked steps, or incomplete documentation can result in non-functional configuration that is difficult to debug. </p>
<p id="rfc.section.1.p.4">Finally, a working configuration may cease to function when the configuration becomes stale, such as when certificates expire. The lack of a direct communication channel between the identity provider and application provider requires that human administrators remember to periodically refresh the configuration and rotate certificates. In some implementations, planned refresh activities such as certificate rotation can temporarily break the ability for federated users to sign-in to the hosted application. </p>
<p id="rfc.section.1.p.5">As a result of these challenges, administrators find it necessary to acquire domain expertise in the identity standards and spend significant time configuring, debugging, and maintaining the federations. </p>
<p id="rfc.section.1.p.6">The goal of FastFed is to simplify the administrator experience. An ecosystem of FastFed-enabled providers enable administrators to instantiate new federation relationships with a few clicks in a web-based workflow, and without needing to understand the underlying technologies. </p>
<p id="rfc.section.1.p.7">To achieve this, FastFed defines additional metadata documents, APIs, and flows so that an administrator can quickly connect two providers that support common identity standards. In addition, FastFed defines interoperability profiles which describe the subset of existing standards which must be implemented for a Provider to label themselves as FastFed Compatible. </p>
<p id="rfc.section.1.p.8">This specification defines the core FastFed metadata formats and handshake flows. </p>
<p id="rfc.section.1.p.9">Additional FastFed Profiles extend this specification with protocol-specific requirements. For reference, see the FastFed Profiles for <a href="#FastFedProfile.OIDC" class="xref">OpenID Connect</a>, <a href="#FastFedProfile.SAML" class="xref">SAML</a>, and <a href="#FastFedProfile.SCIM" class="xref">SCIM Provisioning</a>. </p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#rnc" id="rnc">Requirements Notation and Conventions</a>
</h1>
<p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" class="xref">RFC 2119</a>. </p>
<p id="rfc.section.1.1.p.2">In the .txt version of this specification, 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. In the HTML version of this specification, values to be taken literally are indicated by the use of <samp>this fixed-width font</samp>. </p>
<h1 id="rfc.section.1.2">
<a href="#rfc.section.1.2">1.2.</a> <a href="#Terminology" id="Terminology">Terminology</a>
</h1>
<p id="rfc.section.1.2.p.1">FastFed acts as a high-level metadata description layer which references many different underlying standards. To avoid confusion of terminology, the FastFed specification will explicitly reference the relevent standards inline when using terminology from those standards. </p>
<p id="rfc.section.1.2.p.2">In addition, this specification defines the following terms. When used in this document, the terms refer to the definitions here and not to any terminology from related standards: </p>
<dl>
<dt>Administrator</dt>
<dd style="margin-left: 8">A human end-user who is reponsible for establishing the federation between an Identity Provider and Application Provider. An Administrator is typically a member of an organization with privileges to enable single sign-on to hosted applications for other members of their organization. </dd>
<dt>Application Provider</dt>
<dd style="margin-left: 8">An online service or website which requires end-user provisioning and authentication from an Identity Provider. </dd>
<dt>FastFed URL</dt>
<dd style="margin-left: 8">A shorthand alias for the FastFed Provider Metadata Endpoint (<a href="#ProviderMetadataEndpoint" class="xref">Section 4.1</a>). Providers may advertise their "FastFed URL" in documentation for enabling single sign-on. </dd>
<dt>Identity Provider</dt>
<dd style="margin-left: 8">A service that is capable of authenticating end-users and providing information about the authentation event and the end-user to an Application Provider. May also be capable of pre-provisioning user information to the Application Provider. </dd>
<dt>Multi-Tenant Provider</dt>
<dd style="margin-left: 8">A Provider who serves multiple customers from a single instance of a service. Each customer is logically isolated from other customers of the service. <br> The FastFed specification treats all Providers as potentially Multi-Tenant. </dd>
<dt>Provider</dt>
<dd style="margin-left: 8">An entity that can act as an Application Provider, an Identity Provider, or both. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#Overview" id="Overview">Overview</a>
</h1>
<p id="rfc.section.2.p.1">This section provides an introductory overview of the key concepts in FastFed. The following concepts are explored: </p>
<dl>
<dt>Metadata</dt>
<dd style="margin-left: 8">Configuration that describes the capabilities and preferences of a Provider. </dd>
<dt>Endpoints</dt>
<dd style="margin-left: 8">Locations where Metadata documents can be retrieved. </dd>
<dt>Handshake</dt>
<dd style="margin-left: 8">Flows that describe how an Identity Provider and Application Provider share Metadata documents with each other, thereby establishing the federation relationship. </dd>
<dt>User Schema and Provisioning</dt>
<dd style="margin-left: 8">Describes how Providers agree on a common user schema and declare capabilities for user provisioning. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#OverviewMetadata" id="OverviewMetadata">Metadata</a>
</h1>
<p id="rfc.section.2.1.p.1">FastFed uses Metadata documents to enable Identity Providers and Application Providers to programmatically discover the capabilities of one other and exchange any configuration necessary to enable federation. </p>
<p id="rfc.section.2.1.p.2">Metadata can be different for each tenant of a Provider. The various tenants may have different preferences, configurations, and namespaces that get reflected in their Metadata. </p>
<p id="rfc.section.2.1.p.3">Metadata includes the following: </p>
<ul>
<li>SSO protocols and provisioning methods implemented by the provider. </li>
<li>Endpoint locations for the FastFastFed Handshake (<a href="#Handshake" class="xref">Section 7</a>). </li>
<li>Optional values such as icon images that can aesthetically improve the handshake flows seen by Administrators. </li>
</ul>
<p> </p>
<p id="rfc.section.2.1.p.4">Provider Metadata is segmented into blocks for <samp>identity_provider</samp> and <samp>application_provider</samp>. An entity can define one, or both blocks, depending on the roles they are capable of performing. </p>
<p id="rfc.section.2.1.p.5">The following is a non-normative example of Provider Metadata: </p>
<pre>
{
"identity_provider": {
"provider_domain": "idp.example.com",
"tenant_id": "tenant-12345",
"display_settings": {
"display_name": "Example Identity Provider",
"logo_uri": "https://idp.example.com/images/logo.png",
"icon_uri": "https://idp.example.com/images/icon.png",
"license": "https://openid.net/intellectual-property/licenses/fastfed/1.0/"
}
"capabilities": {
"authentication_profiles": [
"urn:ietf:params:fastfed:1.0:authentication:SAML:Basic",
"urn:ietf:params:fastfed:1.0:authentication:OIDC:Basic"
],
"provisioning_profiles": [
"urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle"
],
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"signing_alg_values_supported": [
"ES512",
"RS256"
]
},
"provider_authentication": {
"jwks_uri": "https://idp.example.com/keys",
},
"fastfed_handshake_start_uri": "https://tenant-12345.idp.example.com/fastfed/start",
}
</pre>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#OverviewEndpoints" id="OverviewEndpoints">Endpoints</a>
</h1>
<p id="rfc.section.2.2.p.1">Endpoints describe the semantics for exchanging information between Providers. </p>
<p id="rfc.section.2.2.p.2">FastFed defines one Endpoint for retrieving Metadata documents: </p>
<ul><li>Provider Metadata Endpoint (<a href="#ProviderMetadataEndpoint" class="xref">Section 4.1</a>), also referred to as the "FastFed URL"</li></ul>
<p> </p>
<p id="rfc.section.2.2.p.3">And, two Endpoints for the FastFed Handshake </p>
<ul>
<li>FastFed Handshake Start Endpoint, hosted by the Identity Provider (<a href="#HandshakeApplicationProviderRedirectVia302" class="xref">Section 7.2.1.5.1</a>)</li>
<li>FastFed Handshake Register Endpoint, hosted by the Application Provider (<a href="#HandshakeRegistrationRequest" class="xref">Section 7.2.3.1</a>)</li>
</ul>
<p> </p>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#OverviewEndpointDiscovery" id="OverviewEndpointDiscovery">Endpoint Discovery</a>
</h1>
<p id="rfc.section.2.3.p.1">Discovery is the means by which Endpoint locations are determined. For example, when the administrator of an application wishes to enable SSO, the Application needs to know the administrator's Identity Provider Metadata Endpoint (e.g. "FastFed URL"). This is accomplished through Endpoint Discovery. </p>
<p id="rfc.section.2.3.p.2">The simplest discovery mechanism (though the least user-friendly) is for the end-user to manually paste their FastFed URL into a form field of the Application. The user may have discovered this value by consulting with an appropriate IT department in their organization, talking to peers, or reading internal documentation pages. This will vary by organization and is outside the scope of this specification. </p>
<p id="rfc.section.2.3.p.3">To simplify the experience, FastFed also supports automated discovery based upon an email address. If a user's Identity Provider supports it, the FastFed experience can be initiated simply by a user providing their email address to the Application (<a href="#ProviderMetadataEndpointDiscovery" class="xref">Section 4.1.2</a>). </p>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#OverviewFastFedHandshake" id="OverviewFastFedHandshake">FastFed Handshake</a>
</h1>
<p id="rfc.section.2.4.p.1">The FastFed Handshake flow is the means by which Metadata documents are exchanged and a federation relationship becomes established. </p>
<p id="rfc.section.2.4.p.2">The abstract flow follows these steps: </p>
<p></p>
<ol>
<li>Application Provider authenticates the Administrator. </li>
<li>Application Provider whitelists the Identity Provider and redirects the Administrator to the Identity Provider to perform the remainder of the registration. </li>
<li>Identity Provider authenticates the Administrator. </li>
<li>Identity Provider makes a registration request to the Application Provider with protocol-specific information necessary to formally establish the federation relationship. </li>
<li>Application Provider validates the Identity Provider is whitelisted and captures the federation configuration. </li>
<li>Application Provider responds with any protocol-specific configuration needed by the Identity Provider. </li>
<li>Identity Provider captures the federation configuration. This completes the registration. </li>
</ol>
<p> </p>
<pre>
+----------+ +----------------+ .----.
| User | | | |.____.|
| Agent |<-----(1)---->| Application |--(5)-->| Data |
| | | Provider | | Store|
| +-|------(2)----<| | "----"
| | | +----------------+
| | | ^ |
| | | | |
| | | | |
| | | (4) (6)
| | | | |
| | | | |
| | | | V
| | | +----------------+ .----.
| +-|------------->| | |.____.|
| | | Identity |--(7)-->| Data |
| |<-----(3)---->| Provider | | Store|
| | | | "----"
+----------+ +----------------+
Figure 1: Abstract Handshake Flow
</pre>
<h1 id="rfc.section.2.5">
<a href="#rfc.section.2.5">2.5.</a> <a href="#OverviewUser" id="OverviewUser">User Schemas and Provisioning</a>
</h1>
<p id="rfc.section.2.5.p.1">Federated Identity Management requires a common, agreed upon schema to describe user information, plus a mechanism to transmit user information across organizational boundaries. </p>
<p id="rfc.section.2.5.p.2">While previous standards each define pieces of the solution, they lack guidance on assembling the pieces into an end-to-end flow. For example, the SCIM specification defines a User schema, but does not specify how to bind the schema into SAML or OIDC assertions. Alternatively, OIDC defines a schema for Standard Claims and a User Info Endpoint to retrieve them. However, the claims are weighted toward describing social media users and may lack attributes necessary to describe users from the enterprise sector or educational sector. In addition, the OIDC claims are bound to the OIDC protocol and it is unspecified how the same schema could be reused with an Application Provider that requires SAML instead of OIDC. Finally, it is not uncommon for an Application Provider to completely ignore all preexisting standards and define their own schema which federation partners must adhere to in SAML or OIDC messages. </p>
<p id="rfc.section.2.5.p.3">Administrators bear the burden of this inconsistency. The lack of agreement amongst federation participants requires an Administrator to bridge the divide by defining schema transformation rules that map user attributes from an Identity Provider format into an Application Provider format. This mapping is unique for each Application Provider and must be defined for each federation. Understanding and defining these transformation rules is a major contributor to the friction of adopting federation. </p>
<p id="rfc.section.2.5.p.4">To eliminate the burden from Administrators, Providers must agree upon a shared vocabulary for user attributes. This is accomplished by requiring both parties to share a common schema for use within the FastFed Metadata documents. This schema serves as a common lingua franca for communicating the user attributes to be exchanged. </p>
<h1 id="rfc.section.2.5.1">
<a href="#rfc.section.2.5.1">2.5.1.</a> <a href="#OverviewUserSchemaSelection" id="OverviewUserSchemaSelection">Schema Selection</a>
</h1>
<p id="rfc.section.2.5.1.p.1">FastFed Metadata allows Providers to declare the schemas they understand. Providers should choose schemas that are likely to be shared by federation partners. The lack of a common schema between an Identity Provider and Application Provider will be regarded as an incompatibility and the FastFed handshake will be halted before completion. </p>
<p id="rfc.section.2.5.1.p.2">FastFed recommends the use of the SCIM User Resource Schema and the SCIM Enterprise User Schema Extension. This specification uses SCIM in examples and references. However, other schemas may be used. </p>
<p id="rfc.section.2.5.1.p.3">The following is a non-normative example showing a snippet of FastFed Metadata with a list of schemas understood by an Identity Provider: </p>
<pre>
{
"identity_provider": {
capabilities: {
...
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:enterprise:2.0:User"
],
}
...
</pre>
<h1 id="rfc.section.2.5.2">
<a href="#rfc.section.2.5.2">2.5.2.</a> <a href="#OverviewUserAttributeFiltering" id="OverviewUserAttributeFiltering">Attribute Filtering</a>
</h1>
<p id="rfc.section.2.5.2.p.1">User schemas can potentially contain many pieces of information about a user. For example, the SCIM User Resource defines more than 25 different attribute types, some containing sensitive user information. It is typically unnecessary to share all user information with a hosted application. In recognition of this, FastFed provides a mechanism for Application Providers to define the subset of attributes needed to use the application. </p>
<p id="rfc.section.2.5.2.p.2">Identity Providers MAY display the list of requested attributes during the FastFed Handshake so that Administrators can review and approve the attributes to be released. </p>
<p id="rfc.section.2.5.2.p.3">The following is a non-normative example showing a snippet of FastFed Metadata for an Application Provider who desires 3 attributes from a SCIM User Resource. </p>
<pre>
{
"application_provider": {
...
"desired_user_attributes": [
{"required": ["username", "emails[primary eq true]"],
"optional": ["name.formatted"]
}
],
...
</pre>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#Metadata" id="Metadata">Metadata</a>
</h1>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#MetadataSerialization" id="MetadataSerialization">Metadata Serialization</a>
</h1>
<p id="rfc.section.3.1.p.1">All FastFed Metadata is represented in JSON format. Property names and string values are represented as JSON strings. Numerical values are represented as JSON numbers. Boolean values are represented as JSON Booleans. Lists are represented as JSON arrays. Complex structures are represented as JSON objects. Omitted properties and properties with no value SHOULD be omitted from the object and not represented by a JSON null value. </p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#MetadataLanguages" id="MetadataLanguages">Metadata Languages and Scripts</a>
</h1>
<p id="rfc.section.3.2.p.1">Human-readable Metadata values and Metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, values such as display_name and logo_uri might have multiple locale-specific values for some Providers. </p>
<p id="rfc.section.3.2.p.2">To specify the languages and scripts, <a href="#RFC5646" class="xref">BCP47</a> [RFC5646] language tags are added to Provider Metadata member names, delimited by a # character. </p>
<p id="rfc.section.3.2.p.3">If such a human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems. </p>
<h1 id="rfc.section.3.3">
<a href="#rfc.section.3.3">3.3.</a> <a href="#ProviderMetadata" id="ProviderMetadata">Provider Metadata</a>
</h1>
<p id="rfc.section.3.3.p.1">Provider Metadata enables Providers to advertise their capabilities and evaluate compatibility with other Providers by comparing capabilities. The Metadata also contains the endpoint configuration needed to perform the FastFed Handshake. </p>
<p id="rfc.section.3.3.p.2">Provider Metadata is a structure with the following top-level attributes: </p>
<dl>
<dt>identity_provider</dt>
<dd style="margin-left: 8">OPTIONAL. Structure containing the attributes described by Identity Provider Metadata (<a href="#IdentityProviderMetadata" class="xref">Section 3.3.5</a>). The existence of this element indicates the entity is capable of acting as an Identity Provider. </dd>
<dt>application_provider</dt>
<dd style="margin-left: 8">OPTIONAL. Structure containing the attributes described by Application Provider Metadata (<a href="#ApplicationProviderMetadata" class="xref">Section 3.3.6</a>) The existence of this element indicates the entity is capable of acting as an Application Provider. </dd>
</dl>
<p> </p>
<p id="rfc.section.3.3.p.3">If a single Provider is capable of acting as both an Identity Provider and an Application Provider, the Provider Metadata MAY contain both parts. </p>
<p id="rfc.section.3.3.p.4">If neither part is specified, the FastFed Handshake will halt as per <a href="#HandshakeHalt" class="xref">Section 7.1.4</a>. </p>
<h1 id="rfc.section.3.3.1">
<a href="#rfc.section.3.3.1">3.3.1.</a> <a href="#ProviderMetadataCapabilities" id="ProviderMetadataCapabilities">Capabilities</a>
</h1>
<p id="rfc.section.3.3.1.p.1">Capabilities describe the supported behaviors of a Provider. They are included in the Metadata for both Identity Providers and Application Providers and are the primary tool to evaluate if two Providers are compatible with one another. </p>
<p id="rfc.section.3.3.1.p.2">Capabilities are represented as a structure with the following attributes: </p>
<dl>
<dt>authentication_profiles</dt>
<dd style="margin-left: 8">OPTIONAL. A list of URNs specifying the single sign-in authentication protocols supported by the Provider. For example, the value "urn:ietf:params:fastfed:1.0:authentication:OIDC:Basic" indicates the provider implements the <a href="#FastFedProfile.OIDC" class="xref">FastFed Basic Profile for OpenID Connect</a>. <br><br> If no value is specified by the Application Provider for <samp>authentication_profiles</samp>, this indicates the Provider does not require authentication, perhaps because FastFed is being used only to configure syncronization of user data between systems in a context without a need for single sign-on. See <a href="#ProviderCompatibilityEvaluationEmptyList" class="xref">Section 5.1</a> for handling empty capabilities. </dd>
<dt>provisioning_profiles</dt>
<dd style="margin-left: 8">OPTIONAL. A list of URNs specifying the user provisioning capabilities supported by the Provider. <br><br>For example, the value <samp>"urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle"</samp> indicates a Provider supports full user provisioning (and deprovisioning) as defined in the <a href="#FastFedProfile.SCIM" class="xref">FastFed Profile For SCIM Provisioning</a>. <br><br> If no value is specified by the Application Provider for <samp>provisioning_profiles</samp>, this indicates the Provider does not require provisioning or that provisioning happens through a non-standard mechanism that is out of scope of the FastFed specification. See <a href="#ProviderCompatibilityEvaluationEmptyList" class="xref">Section 5.1</a> for handling empty capabilities. </dd>
<dt>schemas</dt>
<dd style="margin-left: 8">REQUIRED. A list of URNs specifying the user schemas understood by the Provider. FastFed does not mandate a specific schema, but RECOMMENDS the use of SCIM. <br><br> If the SCIM User Schemas and Extensions defined in <a href="#RFC7643" class="xref">[RFC7643]</a> do not meet the needs of a Provider, the Provider SHOULD coordinate with other potential integration partners to agree upon a commonly understood schema with the necessary user attributes. The Provider SHOULD consider defining this schema as an extension of the core SCIM User Resource. <br><br> If SCIM is used, the SCIM Core Schemas defined in <a href="#RFC7643" class="xref">[RFC7643]</a> MUST be represented using the following values: <ul class="empty">
<li><samp>urn:ietf:params:scim:schemas:core:2.0:User</samp></li>
<li><ul class="empty"><li>Indicates the Provider understands the core SCIM User Resource Schema specified in Section 4.1 of <a href="#RFC7643" class="xref">SCIM Core</a> [RFC7643] </li></ul></li>
<li><samp>urn:ietf:params:scim:schemas:enterprise:2.0:User</samp></li>
<li><ul class="empty"><li>Indicates the provider understands the SCIM Enterprise User Schema Extension specified in Section 4.3 of <a href="#RFC7643" class="xref">SCIM Core</a> [RFC7643] </li></ul></li>
</ul>
<p> When one schema extends another schema, Providers MUST list both schemas if they are capable of using either the extended or the base schema when integrating with federation partners. If the extended schema is mandatory, Providers MUST list only the extended schema. </p>
</dd>
<dt>signing_alg_values_supported</dt>
<dd style="margin-left: 8">REQUIRED. A list of JWA <a href="#RFC7518" class="xref">[RFC7518]</a> signing algorithms supported by the Provider. Used for signing request objects within the FastFed Hanshake. May also be used by FastFed Profiles (for example, SCIM provisioning) which require authentication of a Provider.<br>At minimum, all Providers SHOULD support <samp>RS256</samp>, but MAY support additional algorithms. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.3.3.2">
<a href="#rfc.section.3.3.2">3.3.2.</a> <a href="#DisplaySettings" id="DisplaySettings">Display Settings</a>
</h1>
<p id="rfc.section.3.3.2.p.1">Display Settings contains the names, icons, logos, and licenses for a Provider. It is included in the Metadata for both Identity Providers and Application Providers.<br><br>If defined, these values supercede any overlapping specifications from underlying protocols; e.g. the <samp>logo_uri</samp> defined in <a href="#OpenID.Registration" class="xref">OpenID Connect Dynamic Client Registration 1.0</a> [OpenID.Registration] <br><br> Display Settings are represented as a structure with the following attributes: </p>
<dl>
<dt>display_name</dt>
<dd style="margin-left: 8">REQUIRED. The name of the Provider suitable for display to end-users. The value SHOULD be the primary textual label by which this Provider is normally displayed when presenting it to end-users. If desired, representation of this value in different languages and scripts is represented as described in <a href="#MetadataLanguages" class="xref">Section 3.2</a>. </dd>
<dt>icon_uri</dt>
<dd style="margin-left: 8">OPTONAL. A URL that points to a square image file that can be used as a tile in grid layouts. Commonly used in scenarios where clicking the icon results in launching an instance of the application for the user. Image dimensions MUST be 180x180 pixels. Image files SHOULD be in PNG format, but Providers MAY accept alternative formats. Providers who consume and display the image MAY resize the image to a smaller dimension and/or convert to alternative file formats. <br> If desired, representation of this value in different languages and scripts is represented as described in <a href="#MetadataLanguages" class="xref">Section 3.2</a>. </dd>
<dt>logo_uri</dt>
<dd style="margin-left: 8">OPTIONAL. A URL that points to a logo file for the business or organization. Image dimensions must be 180x80 pixels. Image files SHOULD be in PNG format, but Providers MAY accept alternative formats. Providers who consume and display the image MAY resize the image to a smaller dimension and/or convert to alternative file formats. <br> If desired, representation of this value in different languages and scripts is represented as described in <a href="#MetadataLanguages" class="xref">Section 3.2</a>. </dd>
<dt>license</dt>
<dd style="margin-left: 8">REQUIRED. A URL that points to a license granting use of the display name, icons, and logos. If the license is unrecognized by a participant in the FastFed flows, the participant MUST halt the FastFed Handshake as specified in <a href="#HandshakeHalt" class="xref">Section 7.1.4</a>. To maximize interoperability, all Providers are RECOMMENDED to use an existing FastFed license such as <samp>"https://openid.net/intellectual-property/licenses/fastfed/1.0/"</samp>. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.3.3.3">
<a href="#rfc.section.3.3.3">3.3.3.</a> <a href="#ProviderAuthentication" id="ProviderAuthentication">Provider Authentication Metadata</a>
</h1>
<p id="rfc.section.3.3.3.p.1">Provider Authentication Metadata specifies the location of key materials that allows a Provider to authenticate to other Providers, as defined in <a href="#ProviderAuthenticationMethods" class="xref">Section 6</a> ("Provider Authentication Methods"). </p>
<p id="rfc.section.3.3.3.p.2">Provider Authentication metadata is represented as a structure with the following attributes: </p>
<dl>
<dt>jwks_uri</dt>
<dd style="margin-left: 8">REQUIRED. URL of the Identity Provider's JSON Web Key Set <a href="#RFC7517" class="xref">[JWK]</a> containing the signing key(s) used by the Provider. The Provider MAY use the same key set for all tenants. </dd>
</dl>
<p> </p>
<p id="rfc.section.3.3.3.p.3">The following is a non-normative example of Provider Authentication metadata: </p>
<pre>
"provider_authentication": {
"jwks_uri": "https://idp.example.com/keys"
}
</pre>
<h1 id="rfc.section.3.3.4">
<a href="#rfc.section.3.3.4">3.3.4.</a> <a href="#CommonProviderMetadata" id="CommonProviderMetadata">Common Provider Metadata</a>
</h1>
<p id="rfc.section.3.3.4.p.1">Common Provider Metadata describes properties that are shared by both Identity Providers and Application Providers. </p>
<p id="rfc.section.3.3.4.p.2">Common Provider Metadata is a structure with the following values: </p>
<dl>
<dt>provider_domain</dt>
<dd style="margin-left: 8">REQUIRED. A Domain Name <a href="#RFC1034" class="xref">[RFC1034]</a> for the Provider. Serves as a globally unique primary key for programmatic use cases that require awareness of a distinct Provider identity. An example is duplicate detection of FastFed registrations where the combination of <samp>provider_domain</samp> and <samp>tenant_id</samp> can enable detection of a duplicate operations. See <a href="#ProviderMetadataEndpointValidation" class="xref">Section 4.1.1</a> for rules on defining and validating the <samp>provider_domain</samp>. </dd>
<dt>tenant_id</dt>
<dd style="margin-left: 8">REQUIRED. An opaque string representing a specific tenant within the Provider. The <samp>tenant_id</samp> must be locally unique within the Provider and never reassigned. </dd>
<dt>display_settings</dt>
<dd style="margin-left: 8">REQUIRED. A structure describing the display settings of the Provider, defined in <a href="#DisplaySettings" class="xref">Section 3.3.2</a>. </dd>
<dt>capabilities</dt>
<dd style="margin-left: 8">REQUIRED. A structure describing the capabilities of the Provider, defined in <a href="#ProviderMetadataCapabilities" class="xref">Section 3.3.1</a>. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.3.3.5">
<a href="#rfc.section.3.3.5">3.3.5.</a> <a href="#IdentityProviderMetadata" id="IdentityProviderMetadata">Identity Provider Metadata</a>
</h1>
<p id="rfc.section.3.3.5.p.1">Identity Provider Metadata is a structure that includes all the elements defined in <a href="#CommonProviderMetadata" class="xref">Common Provider Metadata</a>, plus the following additional elements: </p>
<dl>
<dt>provider_authentication</dt>
<dd style="margin-left: 8">REQUIRED. A structure describing the authentication metadata for the Identity Provider, defined in <a href="#ProviderAuthentication" class="xref">Section 3.3.3</a>. </dd>
<dt>fastfed_handshake_start_uri</dt>
<dd style="margin-left: 8">REQUIRED. A URL which specifies the endpoint for the Identity Provider to receive a FastFed Handshake initiation request. See <a href="#HandshakeApplicationProviderRedirectVia302" class="xref">Section 7.2.1.5.1</a>. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.3.3.6">
<a href="#rfc.section.3.3.6">3.3.6.</a> <a href="#ApplicationProviderMetadata" id="ApplicationProviderMetadata">Application Provider Metadata</a>
</h1>
<p id="rfc.section.3.3.6.p.1">Application Provider Metadata is a structure that includes all the elements defined in <a href="#CommonProviderMetadata" class="xref">Common Provider Metadata</a>, plus the following additional elements: </p>
<dl>
<dt>fastfed_handshake_register_uri</dt>
<dd style="margin-left: 8">REQUIRED. A URL which specifies the FastFed Handshake registration endpoint. See <a href="#HandshakeRegistrationRequest" class="xref">Section 7.2.3.1</a>. </dd>
<dt>desired_user_attributes</dt>
<dd style="margin-left: 8">REQUIRED. A structure describing the end-user attributes that the Application Provider desires from the Identity Provider. During the FastFed Handshake, Administrators have an opportunity to review and consent to the release of the desired attributes. <br><br> Attributes MUST be specified using the attribute path syntax for the chosen user schema. For SCIM schemas, attributes are referenced using the SCIM PATH specification as defined in section Section 3.5.2 of the <a href="#RFC7644" class="xref">SCIM Protocol Specification</a> [RFC7644]. E.g. the SCIM formatted name is referenced as <samp>name.formatted</samp>. <br><br> As per the SCIM specification, attribute paths MAY be fully qualified by prefixing with a schema URI. E.g. <samp>"urn:ietf:params:scim:schemas:core:2.0:User:name.formatted"</samp>. When no prefix is specified, the default SCIM Core schema is presumed. <br><br>A trailing asterisk <samp>*</samp> wildcard at the end of an attribute name MAY be used for prefix matching. This can be useful when an application wants to receive user data without knowing in advance which attributes are defined or available for the user. For example, <samp>"urn:ietf:params:scim:schemas:*"</samp> would match attributes from any schema defined in the SCIM specifications. Similarly, the value <samp>"*"</samp> would match all attributes from any schema, including custom-defined schemas. The latter is effectively asking for a complete copy of the user object. <br><br> The structure contains the following elements: <dl>
<dt>required_attributes</dt>
<dd style="margin-left: 8">A list of attributes which the Identity Provider MUST release to the Application Provider. The value of the attributes MUST NOT be null or empty. <br><br>If a required value is not defined for an end-user, the Application Provider MUST reject the end-user for any authentication or provisioning activity using an HTTP 4xx error message. To assist with debugging, the Identity Provider SHOULD signal to the end-user that the value is missing and is required by the Application. The means of doing so are outside the scope of the specification, but could include displaying an informative error message when the end-user attempts to SSO into the application, or making error logs available to the administrators of the Identity Provider if user provisioning fails due to the missing attributes. <br><br>When using SCIM schemas, the attributes <samp>id</samp> and <samp>userName</samp> are required and MUST always be released to the Application Provider. If these attributes are not explicitly specified in the list of <samp>required_attributes</samp>, they MUST be automatically added by the Identity Provider and henceforth available to the Application Provider. </dd>
<dt>optional_attributes</dt>
<dd style="margin-left: 8">A list of attributes which the Identity Provider MAY release to the Application Provider. The application MUST remain functional if the attributes are undefined or if the Identity Provider chooses not to release the <samp>optional_attributes</samp>; albeit with minor degradations in user experience; e.g. falling back to labeling end-users with an opaque <samp>userName</samp> instead of a human-readable <samp>displayName</samp>. <br><br>When using SCIM schemas, the attribute <samp>externalId</samp> is optional but encouraged to be used when available. If this attribute is not explicitly specified in the list of <samp>desired_attributes</samp>, it MUST be automatically added by the Identity Provider and henceforth available to the Application Provider whenever it is defined for a given user. </dd>
</dl>
<p> </p>
</dd>
</dl>
<p> </p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#MetadataEndpoints" id="MetadataEndpoints">Metadata Endpoints</a>
</h1>
<p id="rfc.section.4.p.1">Metadata Endpoints describe the semantics for reading Metadata documents. </p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#ProviderMetadataEndpoint" id="ProviderMetadataEndpoint">Provider Metadata Endpoint</a>
</h1>
<p id="rfc.section.4.1.p.1">A request to this endpoint will return the Provider Metadata document defined in <a href="#ProviderMetadata" class="xref">Section 3.3</a>. </p>
<p id="rfc.section.4.1.p.2">The Provider Metadata Endpoint MUST be accessible to other Providers who are permitted to initiate a FastFed Handhake Flow with the entity. Access to the Endpoint SHOULD NOT require Administrators to perform preconfiguration or preregistration of any form between the two Providers, except the necessary act of inputting the URL for the Provider Metadata Endpoint (a.k.a. "FastFed URL") to initiate the FastFed Handshake if the endpoint location is not discoverable through other means. Requests to the endpoint may be rate-limited or otherwise limited to prevent a denial-of-service attack. </p>
<h1 id="rfc.section.4.1.1">
<a href="#rfc.section.4.1.1">4.1.1.</a> <a href="#ProviderMetadataEndpointValidation" id="ProviderMetadataEndpointValidation">Endpoint Validation</a>
</h1>
<p id="rfc.section.4.1.1.p.1">To prevent impersonanation of Providers, the value of the <samp>provider_domain</samp> returned in the Metadata (<a href="#CommonProviderMetadata" class="xref">Section 3.3.4</a>) MUST match the domain of the Metadata Endpoint. </p>
<p id="rfc.section.4.1.1.p.2">The Metadata Endpoint MAY be hosted at a subdomain of the <samp>provider_domain</samp>. </p>
<p id="rfc.section.4.1.1.p.3">A TLS server certificate check MUST be performed when connecting to the Endpoint. </p>
<p id="rfc.section.4.1.1.p.4">The following is a non-normative example showing valid and invalid Metadata Endpoints. </p>
<pre>
For a Metadata document containing the following domain name:
{
"provider_domain: "idp.example.com",
...
}
The name is valid if retrieved from any of these Endpoints:
https://idp.example.com/ --> OK. Exact Match.
https://tenant-12345.idp.example.com/ --> OK. Suffix Match.
https://idp.example.com/fastfed/metadata --> OK. Exact Match + Path.
The name is invalid if retrieved from any of these Endpoints:
https://idp.example.com.otherdomain.com/ --> INVALID. No suffix match.
https://example.com/ --> INVALID. Incomplete match.
http://idp.example.com/ --> INVALID. Not https.
</pre>
<p id="rfc.section.4.1.1.p.5">If the <samp>provider_domain</samp> is invalid, the FastFed Handshake MUST be halted as specified in <a href="#HandshakeHalt" class="xref">Section 7.1.4</a>. </p>
<h1 id="rfc.section.4.1.2">
<a href="#rfc.section.4.1.2">4.1.2.</a> <a href="#ProviderMetadataEndpointDiscovery" id="ProviderMetadataEndpointDiscovery">Endpoint Discovery</a>
</h1>
<h1 id="rfc.section.4.1.2.1">
<a href="#rfc.section.4.1.2.1">4.1.2.1.</a> <a href="#ProviderMetadataEndpointDiscoveryWebFinger" id="ProviderMetadataEndpointDiscoveryWebFinger">Email-based Discovery via WebFinger</a>
</h1>
<p id="rfc.section.4.1.2.1.p.1">Discovering the location of a Provider Metadata Endpoint for a specific end-user can be achieved through several means. If the user's email address is available to the Application Provider, the RECOMMENDED method of discovery is via a WebFinger request to the user's email domain. </p>
<h1 id="rfc.section.4.1.2.1.1">
<a href="#rfc.section.4.1.2.1.1">4.1.2.1.1.</a> <a href="#ProviderMetadataEndpointDiscoveryWebFingerEndpoint" id="ProviderMetadataEndpointDiscoveryWebFingerEndpoint">WebFinger Endpoints</a>
</h1>
<p id="rfc.section.4.1.2.1.1.p.1">WebFinger traditionally requires a webserver hosted at the root domain. For example, if a user's email address is <samp>"user@company.com"</samp>, WebFinger requests are sent to <samp>"https://company.com/.well_known/webfinger"</samp>. </p>
<p id="rfc.section.4.1.2.1.1.p.2">However, administrators at large enterprises can experience organizational roadblocks when attempting to host this type of discovery endpoint at the root domain. This is because the root domain is often the publicly facing product or web presence for an organization and is maintained by different owners with security and operational privileges which FastFed administrators may not normally possess. </p>
<p id="rfc.section.4.1.2.1.1.p.3">Therefore, to simplify adoption, FastFed also supports WebFinger discovery using subdomains. A well-defined prefix can be prepended to the domain name to retrieve the FastFed Provider Metadata. </p>
<p id="rfc.section.4.1.2.1.1.p.4">The subdomain location is determined by prefixing the email domain with <samp>"webfinger._well_known"</samp>. For example, if the user email is <samp>"babs@example.com"</samp>, the resulting Webfinger endpoint is <samp>"https://webfinger._well_known.example.com"</samp>. </p>
<p id="rfc.section.4.1.2.1.1.p.5">Application Providers performing WebFinger discovery MUST first attempt to read from the subdomain endpoint. If the response is not an HTTP 200, the Application Provider MUST subsequently attempt reading from the traditional WebFinger path at the root domain. A non-normative example is illustrated in <a href="#ProviderMetadataEndpointDiscoveryWebFingerQueries" class="xref">Section 4.1.2.1.2</a>. </p>
<h1 id="rfc.section.4.1.2.1.2">
<a href="#rfc.section.4.1.2.1.2">4.1.2.1.2.</a> <a href="#ProviderMetadataEndpointDiscoveryWebFingerQueries" id="ProviderMetadataEndpointDiscoveryWebFingerQueries">WebFinger Queries</a>
</h1>
<p id="rfc.section.4.1.2.1.2.p.1">FastFed uses the following <samp>rel</samp> value in WebFinger <a href="#RFC7033" class="xref">[RFC7033]</a> </p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead><tr>
<th class="left">RelType</th>
<th class="left">URI</th>
</tr></thead>
<tbody><tr>
<td class="left">FastFed Provider</td>
<td class="left">https://openid.net/specs/fastfed/1.0/provider</td>
</tr></tbody>
</table>
<p id="rfc.section.4.1.2.1.2.p.2">To start discovery of FastFed endpoints, the Application Provider makes an HTTP GET request to the email domain's WebFinger [RFC7033] endpoint with the <samp>resource</samp> value set to the user email address prepended with the <samp>acct:</samp> scheme <a href="#RFC7565" class="xref">[RFC7565]</a>. All WebFinger communication MUST utilize TLS in the manner described in <a href="#HanshakeTLSRequirements" class="xref">Section 7.1.1</a>. </p>
<p id="rfc.section.4.1.2.1.2.p.3">The FastFed Provider Metadata location MUST be returned in the WebFinger response as the value of the <samp>href</samp> member of a <samp>links</samp> array element with <samp>rel</samp> member value <samp>http://openid.net/specs/fastfed/1.0/provider</samp>. (Per Section 7 of WebFinger <a href="#RFC7033" class="xref">[RFC7033]</a>, obtaining the WebFinger response may first involve following some redirects.) </p>
<p id="rfc.section.4.1.2.1.2.p.4">The returned Issuer location MUST be a URI <a href="#RFC3986" class="xref">[RFC3986]</a> with a scheme component that MUST be https, a host component, and optionally, port and path components and no query or fragment components. Note that the WebFinger request may return a metadata location hosted under a different domain than the user's email. </p>
<p id="rfc.section.4.1.2.1.2.p.5">The following non-normative example demonstrates the discovery of FastFed Provider Metadata for <samp>jane@example.com</samp>. The WebFinger parameters are as follows: </p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead><tr>
<th class="left">WebFinger Parameter</th>
<th class="left">Value</th>
</tr></thead>
<tbody>
<tr>
<td class="left">resource</td>
<td class="left">acct:jane@example.com</td>
</tr>
<tr>
<td class="left">host</td>
<td class="left">example.com</td>
</tr>
<tr>
<td class="left">rel</td>
<td class="left">https://openid.net/specs/fastfed/1.0/provider</td>
</tr>
</tbody>
</table>
<p id="rfc.section.4.1.2.1.2.p.6">The Application Provider would first make a WebFinger request to the well-known subdomain endpoint (with line wraps for display purposes only): </p>
<pre>
GET /
?resource=acct%3Ajane%40example.com
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Ffastfed%2F1.0%2Fprovider
HTTP/1.1
Host: webfinger._well_known.example.com
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "acct:jane@example.com",
"links":
[
{
"rel": "http://openid.net/specs/fastfed/1.0/provder",
"href": "https://tenant-12345.idp.example.com/fastfed"
}
]
}
</pre>
<p id="rfc.section.4.1.2.1.2.p.7">If the subdomain endpoint did not return an HTTP 200 response code, the same query would be performed against the root domain using the WebFinger path: </p>
<pre>
GET /.well-known/webfinger
?resource=acct%3Ajane%40example.com
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Ffastfed%2F1.0%2Fprovider
HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "acct:jane@example.com",
"links":
[
{
"rel": "http://openid.net/specs/fastfed/1.0/provder",
"href": "https://tenant-12345.idp.example.com/fastfed"
}
]
}
</pre>
<h1 id="rfc.section.4.1.2.2">
<a href="#rfc.section.4.1.2.2">4.1.2.2.</a> <a href="#ProviderMetadataEndpointDiscoveryAlternative" id="ProviderMetadataEndpointDiscoveryAlternative">Alternative Discovery Mechanisms</a>
</h1>
<p id="rfc.section.4.1.2.2.p.1">Application Providers MAY use other means of discovering the FastFed URL for an Identity Provider. This is an implementation detail. </p>
<p id="rfc.section.4.1.2.2.p.2">As a reference to implementers, another mechanism may be to ask the Administrator to read the the SSO documentation provided by their Identity Provider to find the FastFed URL and then paste the value into a form field. </p>
<h1 id="rfc.section.4.1.3">
<a href="#rfc.section.4.1.3">4.1.3.</a> <a href="#ProviderMetadataEndpointRead" id="ProviderMetadataEndpointRead">Read Request</a>
</h1>
<p id="rfc.section.4.1.3.p.1">After the endpoint is discovered, Provider Metadata can be read by making an HTTP GET request to the Provider Metadata Endpoint. </p>
<p id="rfc.section.4.1.3.p.2">The following is a non-normative example read request: </p>
<pre>
GET /fastfed/provider-metadata HTTP/1.1
Accept: application/json
Host: provider.example.com
</pre>
<h1 id="rfc.section.4.1.4">
<a href="#rfc.section.4.1.4">4.1.4.</a> <a href="#ProviderMetadataEndpointResponse" id="ProviderMetadataEndpointResponse">Read Response</a>
</h1>
<p id="rfc.section.4.1.4.p.1">Upon a successful read operation, the server SHOULD return all available Provider Metadata. </p>
<p id="rfc.section.4.1.4.p.2">A successful response SHOULD use the HTTP 200 OK status code and return a JSON document <a href="#RFC4627" class="xref">[RFC4627]</a> using the application/json_content type with the Provider Metadata values as top-level members of the root JSON object. </p>
<p id="rfc.section.4.1.4.p.3">The following is a non-normative example read response (with line wraps within values for display purposes only): </p>
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
{
"identity_provider": {
"provider_domain": "idp.example.com",
"tenant_id": "tenant-12345",
"display_settings": {
"display_name": "Example Identity Provider",
"logo_uri": "https://idp.example.com/images/logo.png",
"icon_uri": "https://idp.example.com/images/icon.png",
"license": "https://openid.net/intellectual-property/licenses/fastfed/1.0/"
}
"capabilities": {
"authentication_profiles": [
"urn:ietf:params:fastfed:1.0:authentication:SAML:Basic",
"urn:ietf:params:fastfed:1.0:authentication:OIDC:Basic"
],
"provisioning_profiles":[
"urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle"
],
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"signing_alg_values_supported": [
"RS256"
]
},
"provider_authentication": {
"jwks_uri": "https://idp.example.com/keys"
},
"fastfed_handshake_start_uri": "https://tenant-12345.idp.example.com/fastfed/start",
}
</pre>
<h1 id="rfc.section.4.1.5">
<a href="#rfc.section.4.1.5">4.1.5.</a> <a href="#MetadataRefresh" id="MetadataRefresh">Metadata Refresh</a>
</h1>
<p id="rfc.section.4.1.5.p.1">Provider Metadata contains information that is used on a recurring basis, such as the list of supported signing algorithms and URLs of image files. Consumers of the metadata SHOULD locally cache the metadata information and image files. </p>
<p id="rfc.section.4.1.5.p.2">Any cached information MUST be periodically refreshed. The following describes the responsibilities of metadata publishers and consumers to enable refresh activities. </p>
<p id="rfc.section.4.1.5.p.3">The following applies to a publisher of metadata information: </p>
<ul>
<li>MAY periodically alter the content of objects referenced by a URL. </li>
<li>MUST support the HTTP 1.1 ETag semantics <a href="#RFC2616" class="xref">[RFC2616]</a> for all requests to the URLs, including: <ul>
<li>Returning an ETag response header </li>
<li>Accepting an If-None-Match request header, and returning an HTTP 304 response if the object is unmodified. </li>
</ul>
<p> </p>
</li>
</ul>
<p> </p>
<p id="rfc.section.4.1.5.p.4">The following requirements apply to a consumer of metadata information: </p>
<ul>
<li>MUST re-query the URLs at least once every 24 hours to check if a new version of an object is available to replace a local copy. </li>
<li>MUST include the If-None-Match header in the query, populated with the value of the ETag response header received when initially downloading the content. </li>
<li>MUST handle an HTTP 304 response code which indicates that the content is unchanged. </li>
</ul>
<p> </p>
<p id="rfc.section.4.1.5.p.5">It is possible that refreshed metadata may contain errors or incompabilities. For example, an updated image URL may point to a missing or malformed image, or an updated list of signing algorithms may result in two providers no longer sharing a mutually compatible algorithm. In error situations, the consumer of the metadata MAY continue to rely on previously cached values. They SHOULD signal the error situation to the Administrator or Metadata Provider as necessary to resolve the error. Notification mechanisms are outside the scope of FastFed. </p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#ProviderCompatibilityEvaluation" id="ProviderCompatibilityEvaluation">Provider Compatibility Evaluation</a>
</h1>
<p id="rfc.section.5.p.1">A compatibility evaluation is the act of comparing the abilities of two Providers to determine if they can interoperate. For FastFed, this is accomplished by examining the intersection of <a href="#ProviderMetadataCapabilities" class="xref">Provider Capabilities</a>. The process is specified below. </p>
<p id="rfc.section.5.p.2">For reference, all FastFed Capabilities are represented as lists of strings. This includes the following attributes: </p>
<ul>
<li>authentication_profiles</li>
<li>provisioning_profiles</li>
<li>schemas</li>
<li>signing_alg_values_supported</li>
</ul>
<p> </p>
<p id="rfc.section.5.p.3">Required attributes MUST have at least one valid element in the list. Optional attributes MAY have any number of elements in the list, including no elements. An optional attribute that is omitted from the configuration, or defined as a null value, will be treated equivalently to an empty list. </p>
<p id="rfc.section.5.p.4">Each list is evaluated for compatibility via the following steps: </p>
<ul>
<li>If the list from Identity Provider and the list from the Application Provider are both defined and non-empty, the intersection is calculated between the lists. If the resulting intersection is also non-empty, the Providers are compatible for those elements in the intersection. </li>
<li>Otherwise, if one or both lists are empty, see <a href="#ProviderCompatibilityEvaluationEmptyList" class="xref">Section 5.1</a> for special handling of empty capabilities. </li>
</ul>
<p> </p>
<p id="rfc.section.5.p.5">The resulting intersection of capabilities represents the compatible choices which a Provider can select from when determining how to configure federation with another Provider. </p>
<p id="rfc.section.5.p.6">If the Providers are not compatible for one or more FastFed Capabilities, then the Providers MUST be treated as incompatible. </p>
<p id="rfc.section.5.p.7">The handling of incompatibilities depends on the context in which evaluation occured and is described elsewhere in the specification. The most common situation is when compatibility is tested during the FastFed handshake. In this situation, failure causes the handshake to halt and a diagnostic error message is displayed to the end-user. </p>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#ProviderCompatibilityEvaluationEmptyList" id="ProviderCompatibilityEvaluationEmptyList">Handling Empty Capabilities</a>
</h1>
<p id="rfc.section.5.1.p.1">A special case of compatiblity evaluation occurs when one of the Providers returns an empty value for an attribute, such as <samp>provisioning_profiles</samp> or <samp>authentication_profiles</samp>. </p>
<p id="rfc.section.5.1.p.2">Instead of handling as an incompatibility, a Provider MAY choose to treat the missing value as a signal not to enable the functionality it represents. </p>
<p id="rfc.section.5.1.p.3">As a reference to implementers, the following rules are RECOMMENDED for handling empty values: </p>
<ul>
<li>If the Application Provider returns an empty value for either <samp>provisioning_profiles</samp> or <samp>authentication_profiles</samp>, the Identity Provider SHOULD treat this as a signal that the Application Provider does not need the capability. The Identity Provider SHOULD omit the value from subsequent steps of the FastFed handshake and not enable the capability after the handshake completes. </li>
<li>If the Application Provider returns an empty value for BOTH <samp>provisioning_profiles</samp> an <samp>authentication_profiles</samp> such that the result of the FastFed handshake would be a no-op, with no functionality enabled, the Identity Provider SHOULD treat this as an incompatibility. </li>
<li>If the Identity Provider returns an empty value for either <samp>provisioning_profiles</samp> or <samp>authentication_profiles</samp> and the Application Provider considers the capability to be essential for successful usage of the application, the Application Provider SHOULD treat this as an incompatibility. </li>
</ul>
<p> </p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#ProviderAuthenticationMethods" id="ProviderAuthenticationMethods">Provider Authentication Methods</a>
</h1>
<p id="rfc.section.6.p.1">Portions of the FastFed Handshake require the transmission of signed messages from the Identity Provider to the Application Provider. Additionally, some profiles such as <a href="#FastFedProfile.SCIM" class="xref">SCIM Provisioning</a> also require authentication by a Provider. </p>
<p id="rfc.section.6.p.2">FastFed intentionally avoids long-lived shared secrets for signing and authentication purposes. Instead, FastFed Providers use public/private key pairs. The intention is to eliminate the burden upon Administrators who would otherwise be required to re-execute the FastFed Handshake to rotate long-lived shared secrets or update signing algorithms. </p>
<p id="rfc.section.6.p.3">This section specifies how keys are discovered and utilized in FastFed. </p>
<h1 id="rfc.section.6.1">
<a href="#rfc.section.6.1">6.1.</a> <a href="#ProviderAuthenticationMethodsKeyDiscovery" id="ProviderAuthenticationMethodsKeyDiscovery">Key Discovery</a>
</h1>
<p id="rfc.section.6.1.p.1">Public keys for a Provider are found at the location specified by the <samp>jwks_uri</samp> in the <a href="#ProviderAuthentication" class="xref">Provider Authentication Metadata</a>. The FastFed Handshake only necessitates authentication by the Identity Provider. Hence, in this specification, only the Identity Provider is required to provide a key set. (See <a href="#IdentityProviderMetadata" class="xref">Section 3.3.5</a>.) </p>
<p id="rfc.section.6.1.p.2">Providers MAY use the same <samp>jwks_uri</samp> across all tenants and all federation relationships. </p>
<h1 id="rfc.section.6.2">
<a href="#rfc.section.6.2">6.2.</a> <a href="#ProviderAuthenticationMethodsKeyRotation" id="ProviderAuthenticationMethodsKeyRotation">Key Rotation</a>
</h1>
<p id="rfc.section.6.2.p.1">Providers SHOULD rotate keys on an ongoing basis. </p>
<p id="rfc.section.6.2.p.2">Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at its jwks_uri location and includes the kid of the signing key in the JOSE 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 the jwks_uri location. The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri location to re-retrieve the keys when it sees an unfamiliar kid value. The JWK Set document at the jwks_uri SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition. </p>
<h1 id="rfc.section.6.3">
<a href="#rfc.section.6.3">6.3.</a> <a href="#ProviderAuthenticationMethodsAlgSelection" id="ProviderAuthenticationMethodsAlgSelection">Algorithm Selection</a>
</h1>
<p id="rfc.section.6.3.p.1">The signing algorithms supported by a Provider are specified in the <samp>signing_alg_values_supported</samp> attribute in the <a href="#ProviderMetadataCapabilities" class="xref">Provider Capabilities Metadata</a>. </p>
<p id="rfc.section.6.3.p.2">Current best practices for signing algorithms can evolve over time. Therefore, Providers SHOULD publish updated FastFed Metadata with new signing algorithms as necessary to evolve with current best practices. Consumers of the FastFed Metadata MUST periodically refresh any cached information as described in <a href="#MetadataRefresh" class="xref">Section 4.1.5</a> in order to maintain a current list of supported algorithms for a Provider. </p>
<p id="rfc.section.6.3.p.3">When updating, Providers SHOULD add new algorithms but SHOULD NOT remove existing algorithms that are actively being used unless necessary for security purposes, since removing an algorithm may break existing federation relationships. </p>
<p id="rfc.section.6.3.p.4">If two Providers are compatible for multiple signing algorithms, the signer may select any mutually compatible algorithm. The Provider SHOULD avoid known weak algorithms which do not reflect current best practices. </p>
<h1 id="rfc.section.6.4">
<a href="#rfc.section.6.4">6.4.</a> <a href="#ProviderAuthenticationMethodsJWT" id="ProviderAuthenticationMethodsJWT">JWT Requirements</a>
</h1>
<p id="rfc.section.6.4.p.1">Portions of the FastFed flows require the transmission of a signed JWT <a href="#RFC7519" class="xref">[RFC7519]</a>. This section describes the requirements for JWT usage within FastFed. </p>
<p id="rfc.section.6.4.p.2">JWT serialization MAY use either JWS Compact Serialization or JWS JSON Serialization. </p>
<p id="rfc.section.6.4.p.3">The JWT header MUST contain the following attributes; </p>
<dl>
<dt>alg</dt>
<dd style="margin-left: 8">The signing algorithm MUST be a compatible <a href="#RFC7515" class="xref">JWS</a> <samp>alg</samp> algorithm <a href="#RFC7518" class="xref">[JWA]</a> specified by both Providers in the <samp>signing_alg_values_supported</samp> attribute of the <a href="#ProviderMetadataCapabilities" class="xref">Provider Capabilities</a>. </dd>
<dt>kid</dt>
<dd style="margin-left: 8">The JWS signing key MUST exist in the JSON Web Key Set <a href="#RFC7517" class="xref">[JWK]</a> specified by the <samp>jwks_uri</samp> parameter of the <a href="#ProviderAuthentication" class="xref">Provider Authentication Metadata</a>. The <samp>alg</samp> associated with the signing key MUST match the <samp>alg</samp> used to sign the JWT. </dd>
</dl>
<p> </p>
<p id="rfc.section.6.4.p.4">The JWT payload MUST contain the following attributes: </p>
<dl>
<dt>iss</dt>
<dd style="margin-left: 8">The value MUST match the <samp>provider_domain</samp> of the entity generating the JWT, as specified in the <a href="#CommonProviderMetadata" class="xref">Provider Metadata</a>. </dd>
<dt>sub</dt>
<dd style="margin-left: 8">The value MUST match the <samp>tenant_id</samp> of the entity generating the JWT, as specified in the <a href="#CommonProviderMetadata" class="xref">Provider Metadata</a>. </dd>
<dt>aud</dt>
<dd style="margin-left: 8">The value MUST match the <samp>provider_domain</samp> of the intended recipient of the JWT, as specified in the recipient's <a href="#CommonProviderMetadata" class="xref">Provider Metadata</a>. </dd>
<dt>exp</dt>
<dd style="margin-left: 8">Expiration time SHOULD be as short as possible. As a reference to implementors, a 10 minute expiration window is often sufficient to reduce the risk of replayability while still allowing a small degree of clock skew between participants. </dd>
</dl>
<p> A JWT MAY include additional attributes in addition to the list above. </p>
<h1 id="rfc.section.6.5">
<a href="#rfc.section.6.5">6.5.</a> <a href="#ProviderAuthenticationMethodsProtocolSpecific" id="ProviderAuthenticationMethodsProtocolSpecific">Protocol-specific Key Materials</a>
</h1>
<p id="rfc.section.6.5.p.1">Protocols such as SAML and OpenID Connect each define their own protocol-specific key materials. </p>
<p id="rfc.section.6.5.p.2">Wherever they exist, the protocol-specific key materials should continue to be used. For example, SAML defines a Metadata format which includes a certificate. This certificate should continue to used for signing SAML messages as per the SAML specifications. FastFed provides the means to discover and exchange the SAML metadata files. </p>
<p id="rfc.section.6.5.p.3">However, not all protocols offer a built-in authentication mechanism. For example, SCIM <a href="#RFC7644" class="xref">[RFC7644]</a> does not define how to attain authentication materials. In these situations, FastFed fills the blanks with prescriptive guidance. The FastFed Profile for SCIM provisioning <a href="#FastFedProfile.SCIM" class="xref">[FastFedProfile.SCIM]</a> defines how to attain and use an OAuth <samp>access_token</samp> for SCIM endpoints. </p>
<h1 id="rfc.section.6.6">
<a href="#rfc.section.6.6">6.6.</a> <a href="#ProviderAuthenticationMethodsOAuth" id="ProviderAuthenticationMethodsOAuth">OAuth Access Tokens</a>
</h1>
<p id="rfc.section.6.6.p.1">It is not uncommon for certain protocols such as <a href="#FastFedProfile.SCIM" class="xref">SCIM Provisioning</a> to expect the use of an OAuth <samp>access_token</samp>. This section provides a common specification for how FastFed compatible providers may exchange a JWT for OAuth tokens. This specification may be referenced by any FastFed Profile with a need for OAuth tokens. </p>
<p id="rfc.section.6.6.p.2">OAuth-protected endpoints MUST support the JSON Web Token (JWT) Profile for OAuth 2.0 Authorization Grants <a href="#RFC7523" class="xref">[RFC7523]</a>. </p>
<p id="rfc.section.6.6.p.3">The token endpoint MUST accept JWTs formatted according to the <a href="#ProviderAuthenticationMethodsJWT" class="xref">FastFed JWT Requirements</a>. </p>
<p id="rfc.section.6.6.p.4">OAuth configuration SHOULD be communicated by including a structure named <samp>oauth_metadata</samp> in the FastFed Registration flows with the following attributes: </p>
<dl>
<dt>grant_type</dt>
<dd style="margin-left: 8">REQUIRED. Value MUST be <samp>urn:ietf:params:oauth:grant-type:jwt-bearer</samp> </dd>
<dt>token_endpoint</dt>
<dd style="margin-left: 8">REQUIRED. Location of the OAuth token endpoint. </dd>
<dt>scope</dt>
<dd style="margin-left: 8">OPTIONAL. Scope value to be used when requesting an <samp>access_token</samp>. </dd>
</dl>
<p> </p>
<p id="rfc.section.6.6.p.5">The following is a non-normative example of a FastFed registration response [<a href="#HandshakeRegistrationResponse" class="xref">Section 7.2.3.3</a>] that includes both <a href="#FastFedProfile.SAML" class="xref">SAML authentication metadata</a> and <a href="#FastFedProfile.SCIM" class="xref">SCIM provisoning</a> with OAuth-based authentication. </p>
<pre>
{
"urn:ietf:params:fastfed:1.0:authentication:SAML:Basic": {
"saml_metatadata_uri": "https://tenant-56789.app.example.com/saml-metadata.xml"
},
"urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle": {
"scim_service_uri": "https://tenant-56789.app.example.com/scim",
"oauth_metadata": {
"grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
"token_endpoint": "https://tenant-56789.app.example.com/oauth",
"scope": "scim"
}
}
}
</pre>
<h1 id="rfc.section.6.7">
<a href="#rfc.section.6.7">6.7.</a> <a href="#ProviderAuthenticationMethodsOAuthRegistration" id="ProviderAuthenticationMethodsOAuthRegistration">OAuth Client Registration</a>
</h1>
<p id="rfc.section.6.7.p.1">An OAuth <samp>client_id</samp> is not required by the FastFed flows, nor is OAuth client registration. </p>
<p id="rfc.section.6.7.p.2">The implementation of the OAuth authorization server is outside the scope of FastFed. As a reference to implementors who may require an explicit client registration within their internal implementation, a unique OAuth client_id may be formed by concatinating the <samp>provider_domain</samp> and <samp>tenant_id</samp> which together form a unique identifer. In addition, the FastFed Metadata such as the <samp>display_name</samp> may serve as a human-readable label for a registration. </p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#Handshake" id="Handshake">FastFed Handshake</a>
</h1>
<h1 id="rfc.section.7.1">
<a href="#rfc.section.7.1">7.1.</a> <a href="#HandshakeCommon" id="HandshakeCommon">Common Considerations</a>
</h1>
<h1 id="rfc.section.7.1.1">
<a href="#rfc.section.7.1.1">7.1.1.</a> <a href="#HanshakeTLSRequirements" id="HanshakeTLSRequirements">TLS Requirements</a>
</h1>
<p id="rfc.section.7.1.1.p.1">All implementations MUST require the use of TLS for all FastFed Endpoints, including the Metadata Endpoints and FastFed Handshake Endpoints. </p>
<p id="rfc.section.7.1.1.p.2">Which TLS version(s) ought to be implemented will vary over time, and depends on the widespread deployment and known security vulnerabilities at the time of implementation. 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.7.1.1.p.3">Whenever TLS is used, a TLS server certificate check MUST be performed, per <a href="#RFC6125" class="xref">[RFC6125]</a>. </p>
<h1 id="rfc.section.7.1.2">
<a href="#rfc.section.7.1.2">7.1.2.</a> <a href="#HandshakeHTTPRedirects" id="HandshakeHTTPRedirects">HTTP Redirects</a>
</h1>
<p id="rfc.section.7.1.2.p.1">This specification makes use of HTTP redirection, in which a Provider directs the Administrator's user-agent to another destination. While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail. </p>
<h1 id="rfc.section.7.1.3">
<a href="#rfc.section.7.1.3">7.1.3.</a> <a href="#HandshakeSerialization" id="HandshakeSerialization">Query String Serialization</a>
</h1>
<p id="rfc.section.7.1.3.p.1">The FastFed Handshake uses HTTP GET with Query String Serialization to transmit requests. </p>
<p id="rfc.section.7.1.3.p.2">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 of a URL using the application/x-www-form-urlencoded format as defined by <a href="#W3C.REC-html401-19991224" class="xref">[W3C.REC-html401-19991224]</a>. Query String Serialization is typically used in HTTP GET requests. The same serialization method is also used when adding parameters to the fragment component of a URL. </p>
<h1 id="rfc.section.7.1.4">
<a href="#rfc.section.7.1.4">7.1.4.</a> <a href="#HandshakeHalt" id="HandshakeHalt">Halting the Handshake</a>
</h1>
<p id="rfc.section.7.1.4.p.1">In certain circumstances, the FastFed Handshake cannot proceed and must be halted. This may occur, for example, if the Providers do not share common capabilities. </p>
<p id="rfc.section.7.1.4.p.2">When halting the handshake, the Provider who decides to halt SHOULD display an informative message to the Administrator explaining why the action was halted and any steps that can be taken by the Administrator to correct the situation. The details of this communication to the Administrator are outside the scope of the specification. </p>
<h1 id="rfc.section.7.2">
<a href="#rfc.section.7.2">7.2.</a> <a href="#HandshakeFlow" id="HandshakeFlow">Handshake Flow</a>
</h1>
<h1 id="rfc.section.7.2.1">
<a href="#rfc.section.7.2.1">7.2.1.</a> <a href="#HandshakeStart" id="HandshakeStart">Handshake Initiation at Application Provider</a>
</h1>
<h1 id="rfc.section.7.2.1.1">
<a href="#rfc.section.7.2.1.1">7.2.1.1.</a> <a href="#HandshakeApplicationProviderPrerequisites" id="HandshakeApplicationProviderPrerequisites">Prerequisites</a>
</h1>
<p id="rfc.section.7.2.1.1.p.1">Prior to beginning the FastFed Handshake, the Application Provider MUST perform Endpoint Discovery (<a href="#ProviderMetadataEndpointDiscovery" class="xref">Section 4.1.2</a>) to discover the Identity Provider Metadata Endpoint URI. </p>
<p id="rfc.section.7.2.1.1.p.2">The Application Provider MUST also authenticate the Administrator and verify they are authorized to initiate the FastFed Handshake. The means of doing so are outside the scope of this specification. </p>
<h1 id="rfc.section.7.2.1.2">
<a href="#rfc.section.7.2.1.2">7.2.1.2.</a> <a href="#HandshakeApplicationProviderReadsIdentityProviderMetadata" id="HandshakeApplicationProviderReadsIdentityProviderMetadata">Application Provider Reads Identity Provider Metadata</a>
</h1>
<p id="rfc.section.7.2.1.2.p.1">The Application Provider queries the <a href="#ProviderMetadataEndpoint" class="xref">Identity Provider Metadata Endpoint</a>. </p>
<p id="rfc.section.7.2.1.2.p.2">If the Identity Provider Metadata cannot be downloaded or is missing required elements, the FastFed Handshake MUST be halted. </p>
<p id="rfc.section.7.2.1.2.p.3">Prior to using any information in the metadata response, the Application Provider MUST validate the <samp>provider_domain</samp> as specified in <a href="#ProviderMetadataEndpointValidation" class="xref">Section 4.1.1</a>. </p>
<p id="rfc.section.7.2.1.2.p.4">If the tenant of the Application Provider already has an established federation relationship with the tenant of the Identity Provider, as determined by examining the <samp>provider_domain</samp> and <samp>tenant_id</samp> specified in the Identity Provider metadata, the Application Provider SHOULD alert the Administrator of a duplicate registration attempt. </p>
<h1 id="rfc.section.7.2.1.3">
<a href="#rfc.section.7.2.1.3">7.2.1.3.</a> <a href="#HandshakeApplicationProviderVerifiesCompatibilityWithIdentityProvider" id="HandshakeApplicationProviderVerifiesCompatibilityWithIdentityProvider">Application Provider Verifies Compatibility with Identity Provider</a>
</h1>
<p id="rfc.section.7.2.1.3.p.1">The Application Provider MUST compare its Provider Metadata against the Identity Provider Metadata to verify compatibility, as described in <a href="#ProviderCompatibilityEvaluation" class="xref">Section 5</a>. </p>
<p id="rfc.section.7.2.1.3.p.2">If the Providers are incompatible, the FastFed Handshake MUST be halted. </p>
<h1 id="rfc.section.7.2.1.4">
<a href="#rfc.section.7.2.1.4">7.2.1.4.</a> <a href="#HandshakeApplicationProviderWhitelistsIdentityProvider" id="HandshakeApplicationProviderWhitelistsIdentityProvider">Application Provider Whitelists the Identity Provider</a>
</h1>
<p id="rfc.section.7.2.1.4.p.1">The Application Provider whitelists that the tenant of the Identity Provider is permitted to create a federation relationship with the instance of the Application. This whitelisting will be utilized later in the handshake when the Identity Provider calls back to the Application Provider to complete the registration. </p>
<p id="rfc.section.7.2.1.4.p.2">The whitelisting record must capture the <samp>provider_domain</samp>, <samp>tenant_id</samp> and the <samp>jwks_uri</samp> from the Identity Provider Metadata document. The keys from the <samp>jwks_uri</samp> will be used to validate message signatures and confirm the authenticity of subsequent handshake messages from whitelisted providers. </p>
<p id="rfc.section.7.2.1.4.p.3">The representation of the whitelisting record is an implementation detail. </p>
<p id="rfc.section.7.2.1.4.p.4">If the handshake is never completed, whitelisting records SHOULD expire after a reasonable amount of time. The amount of time is an implementation detail. As a reference to implementors, some enterprises require multiple different parties to approve a new application for single sign-in. These approvals may take days or weeks to acquire. </p>
<h1 id="rfc.section.7.2.1.5">
<a href="#rfc.section.7.2.1.5">7.2.1.5.</a> <a href="#HandshakeApplicationProviderRedirect" id="HandshakeApplicationProviderRedirect">Application Provider Sends Request to the Identity Provider</a>
</h1>
<p id="rfc.section.7.2.1.5.p.1">If the preceding steps were successful, the Application Provider responds by issuing a request to the Identity Provider containing the following parameters: </p>
<dl>
<dt>app_metadata_uri</dt>
<dd style="margin-left: 8">REQUIRED. The location of the Provider Metadata for the Application Provider. </dd>
<dt>expiration</dt>
<dd style="margin-left: 8">OPTIONAL. The date/time when the Application Provider will consider the whitelisted pending registration to be expired and the administrator must restart the FastFed Handshake. This value is provided as a convenience to the Identity Provider so that it may be aware of the deadline for completing the flow. The value MUST be a number representing a NumericDate as defined in Section 2 of <a href="#RFC7519" class="xref">RFC 7519</a> [JWT]. </dd>
</dl>
<p> </p>
<p id="rfc.section.7.2.1.5.p.2">The request can be transmitted through the following mechanisms. </p>
<h1 id="rfc.section.7.2.1.5.1">
<a href="#rfc.section.7.2.1.5.1">7.2.1.5.1.</a> <a href="#HandshakeApplicationProviderRedirectVia302" id="HandshakeApplicationProviderRedirectVia302">HTTP Redirect</a>
</h1>
<p id="rfc.section.7.2.1.5.1.p.1">An Application Provider MAY issue an HTTP 302 redirect to the <samp>fastfed_handshake_start_uri</samp> specified in the <a href="#IdentityProviderMetadata" class="xref">Identity Provider Metadata</a> with the request parameters encoded using <a href="#HandshakeSerialization" class="xref">Query String Serialization</a>. </p>
<p id="rfc.section.7.2.1.5.1.p.2">The following is a non-normative example of a response (with line wraps within values for display purposes only): </p>
<pre>
HTTP/1.1 302 Found
Location: https://tenant-12345.idp.example.com/fastfed/handshake/start?
app_metadata_uri=https%3A%2F%2Ftenant-67890.app.example.com%2Ffastfed%2Fprovider-metadata
&expiration=1475878357
</pre>
<h1 id="rfc.section.7.2.1.5.2">
<a href="#rfc.section.7.2.1.5.2">7.2.1.5.2.</a> <a href="#HandshakeApplicationProviderRedirectViaOtherChannel" id="HandshakeApplicationProviderRedirectViaOtherChannel">Alternative Channel</a>
</h1>
<p id="rfc.section.7.2.1.5.2.p.1">In some circumstances, the end-user who is initiating the FastFed Handshake at the Application Provider may not be a valid end-user in the Identity Provider. This could occur, for example, when one organization is inviting members of a different organization to collaborate in a shared instance of an application. </p>
<p id="rfc.section.7.2.1.5.2.p.2">If the Application Provider has reason to believe that the end-user initiating the FastFed Handshake may not exist in the given Identity Provider, then the request message MAY be transmitted through alternate channels. Such channels may include, but are not limited to, email and instant messaging. </p>
<p id="rfc.section.7.2.1.5.2.p.3">The request message is conveyed as a URL with the host value set to the <samp>fastfed_handshake_start_uri</samp> specified in the <a href="#IdentityProviderMetadata" class="xref">Identity Provider Metadata</a> and the request parameters encoded using <a href="#HandshakeSerialization" class="xref">Query String Serialization</a>. </p>
<p id="rfc.section.7.2.1.5.2.p.4">The following is a non-normative example of a message (with line wraps within values for display purposes only): </p>
<pre>
Hello Jane,
Please click this link to finish setting up single sign-on with us.
https://tenant-12345.idp.example.com/fastfed/handshake/start?
app_metadata_uri=https%3A%2F%2Ftenant-67890.app.example.com%2Ffastfed%2Fprovider-metadata
&expiration=1475878357
</pre>
<h1 id="rfc.section.7.2.2">
<a href="#rfc.section.7.2.2">7.2.2.</a> <a href="#HandshakeReceiptByIdentityProvider" id="HandshakeReceiptByIdentityProvider">Handshake Receipt by Identity Provider</a>
</h1>
<h1 id="rfc.section.7.2.2.1">
<a href="#rfc.section.7.2.2.1">7.2.2.1.</a> <a href="#HandshakeIdentityProviderAuthenticatesAdministrator" id="HandshakeIdentityProviderAuthenticatesAdministrator">Identity Provider Authenticates Administrator</a>
</h1>
<p id="rfc.section.7.2.2.1.p.1">Upon receiving a handshake message from the Application Provider as specified in Step <a href="#HandshakeApplicationProviderRedirect" class="xref">7.2.1.5</a>, the Identity Provider MUST authenticate the end-user and verify they are authorized to initiate a federation relationship with the Application Provider. </p>
<p id="rfc.section.7.2.2.1.p.2">If the end-user cannot be authenticated, the FastFed Handshake MUST be halted. </p>
<p id="rfc.section.7.2.2.1.p.3">If the end-user is authenticated but not permitted to complete the registration process, an Identity Provider MAY pause the handshake flow at any point beyond this step, capture the registration information for approval by a different Adminstrator, and thereafter finish the remaining steps of the FastFed handshake. </p>
<h1 id="rfc.section.7.2.2.2">
<a href="#rfc.section.7.2.2.2">7.2.2.2.</a> <a href="#HandshakeIdentityProviderReadsProviderMetadata" id="HandshakeIdentityProviderReadsProviderMetadata">Identity Provider Reads Application Provider Metadata</a>
</h1>
<p id="rfc.section.7.2.2.2.p.1">Using the <samp>app_metadata_uri</samp> sent as a parameter in the handshake request, the Identity Provider queries the <a href="#ProviderMetadataEndpoint" class="xref">Application Provider Metadata Endpoint</a>. </p>
<p id="rfc.section.7.2.2.2.p.2">If the Application Provider Metadata cannot be downloaded or is missing required elements, the FastFed Handshake must be halted. </p>
<p id="rfc.section.7.2.2.2.p.3">If the tenant of the Identity Provider already has an established or pending federation relationship with the tenant of the Application Provider, as determined by examining the <samp>provider_domain</samp> and <samp>tenant_id</samp> specified in the Application Provider Metadata, the Identity Provider SHOULD alert the Administrator of the existing configuration and display the current status of the relationship, such as whether the relationship is active or pending approval. The Identity Provider MAY also allow the Administrator to proceed with modifying the existing configuration or creating a duplicate configuration. This is an implementation detail outside the scope of the specifiation. </p>
<h1 id="rfc.section.7.2.2.3">
<a href="#rfc.section.7.2.2.3">7.2.2.3.</a> <a href="#HandshakeIdentityProviderVerifiesCompatibility" id="HandshakeIdentityProviderVerifiesCompatibility">Identity Provider Verifies Compatibility</a>
</h1>
<p id="rfc.section.7.2.2.3.p.1">The Identity Provider MUST compare its Provider Metadata against the Application Provider Metadata in order to verify compatibility, as described in <a href="#ProviderCompatibilityEvaluation" class="xref">Section 5</a>. </p>
<p id="rfc.section.7.2.2.3.p.2">If the Providers are incompatible, the FastFed Handshake MUST be halted. </p>
<p id="rfc.section.7.2.2.3.p.3">It is possible that both Providers may share a list of capabilities, such as supporting both SAML and OpenID Connect for single sign-on. If multiple options are valid, the Identity Provider chooses one option to use. The Identity Provider MAY ask the Administrator to make the choice or MAY automatically choose based on default preferences of the provider. </p>
<h1 id="rfc.section.7.2.2.4">
<a href="#rfc.section.7.2.2.4">7.2.2.4.</a> <a href="#HandshakeIdentityProviderObtainsConsent" id="HandshakeIdentityProviderObtainsConsent">Identity Provider Obtains Consent from Administrator</a>
</h1>
<p id="rfc.section.7.2.2.4.p.1">The Identity Provider MUST obtain explicit consent from an Administrator to enable federation with the Application Provider. </p>
<p id="rfc.section.7.2.2.4.p.2">As a reference to implementers, consent could include displaying a verification page which summarizes the actions that will occur and asks the user to click a confirmation button. </p>
<h1 id="rfc.section.7.2.3">
<a href="#rfc.section.7.2.3">7.2.3.</a> <a href="#HandshakeRegistration" id="HandshakeRegistration">Handshake Registration</a>
</h1>
<p id="rfc.section.7.2.3.p.1">The registration phase of the handshake is the point at which Providers exchange information necessary to activate an authentication and provisioning relationship. For example, if the Identity Provider has chosen to use the SAML and SCIM protocols, this is the point at which SAML metadata files will be exchanged, and SCIM endpoints and authentication credentials established. </p>
<h1 id="rfc.section.7.2.3.1">
<a href="#rfc.section.7.2.3.1">7.2.3.1.</a> <a href="#HandshakeRegistrationRequest" id="HandshakeRegistrationRequest">Identity Provider Sends Registration Request</a>
</h1>
<p id="rfc.section.7.2.3.1.p.1">The Identity Provider registers with the Application Provider by issuing an HTTP POST to the <samp>fastfed_handshake_register_uri</samp> specified within the <a href="#ApplicationProviderMetadata" class="xref">Application Provider Metadata</a>. </p>
<p id="rfc.section.7.2.3.1.p.2">The content of the POST is a JWT <a href="#RFC7519" class="xref">[RFC7519]</a> as specified in <a href="#ProviderAuthenticationMethodsJWT" class="xref">Section 6.4</a>. </p>
<p id="rfc.section.7.2.3.1.p.3">In addition to the required attributes specified in <a href="#ProviderAuthenticationMethodsJWT" class="xref">Section 6.4</a>, the JWT includes the following additional attributes: </p>
<dl>
<dt>authentication_profiles</dt>
<dd style="margin-left: 8">OPTIONAL. A list containing the SSO authentication protocols to be enabled for sign-in between the Identity Provider and the Application Provider, chosen from the list of <samp>authentication_profiles</samp> defined in the <a href="#ProviderMetadataCapabilities" class="xref">Provider Capabilities</a>. </dd>
<dt>provisioning_profiles</dt>
<dd style="margin-left: 8">OPTIONAL. A list containing the user provisioning profiles to be enabled by the Identity Provider and Application Provider, chosen from the list of <samp>provisioning_profiles</samp> defined in the <a href="#ProviderMetadataCapabilities" class="xref">Provider Capabilities</a>. </dd>
<dt>schema</dt>
<dd style="margin-left: 8">REQUIRED. A string value containing the user schema to be used by the Identity Provider and Application Provider, chosen from the list of <samp>schemas</samp> defined in the <a href="#ProviderMetadataCapabilities" class="xref">Provider Capabilities</a>. </dd>
</dl>
<p> </p>
<p id="rfc.section.7.2.3.1.p.4">Specific authentication or provisioning profiles will typically extend the set of attributes in the JWT with additional values necessary for the chosen protocol. These extentions are defined elsewhere within the profile specifications. </p>
<p id="rfc.section.7.2.3.1.p.5">The following is a non-normative example of the contents of a registration request message prior to serialization, with protocol-specific values for SAML and SCIM: </p>
<pre>
{
"iss": "idp.example.com",
"sub": "tenant-12345",
"aud": "app.example.com",
"exp": 1234567890,
"authentication_profiles": ["urn:ietf:params:fastfed:1.0:authentication:SAML:Basic"],
"provisioning_profiles": ["urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle"],
"schema": "urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:fastfed:1.0:authentication:SAML:Basic": {
"saml_metatadata_uri": "https://tenant-12345.idp.example.com/saml-metadata.xml",
}
"urn:ietf:params:fastfed:1.0:authentication:SCIM:FullLifeCycle": {
"provider_authentication": {
"jwks_uri": "https://provisioning.example.com/keys",
}
}
}
</pre>
<h1 id="rfc.section.7.2.3.2">
<a href="#rfc.section.7.2.3.2">7.2.3.2.</a> <a href="#HandshakeRegistrationProcessing" id="HandshakeRegistrationProcessing">Application Provider Handles Registration Request</a>
</h1>
<p id="rfc.section.7.2.3.2.p.1">Upon receiving the registration request from the Identity Provider, the Application Provider MUST perform the following verification steps: </p>
<ul>
<li>Verify the JWT signature using the current JSON Web Key Set <a href="#RFC7517" class="xref">[JWK]</a> hosted at the <samp>jwks_uri</samp> captured in <a href="#HandshakeApplicationProviderWhitelistsIdentityProvider" class="xref">Section 7.2.1.4</a>. </li>
<li>Verify the <samp>iss</samp> attribute matches the whitelisted <samp>provider_domain</samp> captured in <a href="#HandshakeApplicationProviderWhitelistsIdentityProvider" class="xref">Section 7.2.1.4</a>. </li>
<li>Verify the <samp>sub</samp> attribute matches the whitelisted <samp>tenant_id</samp> captured in <a href="#HandshakeApplicationProviderWhitelistsIdentityProvider" class="xref">Section 7.2.1.4</a>. </li>
<li>Verify the <samp>aud</samp> attribute matches the <samp>provider_domain</samp> specified in the <a href="#ApplicationProviderMetadata" class="xref">Application Provider Metadata</a>. </li>
<li>Verify the <samp>exp</samp> date/time in the JWT is prior to current date/time. </li>
<li>If the Application Provider previously applied an expiration date to the whitelisting record (<a href="#HandshakeApplicationProviderWhitelistsIdentityProvider" class="xref">Section 7.2.1.4</a>), verify the expiration date of the whitelisting record has not been exceeded. </li>
</ul>
<p> </p>
<p id="rfc.section.7.2.3.2.p.2">In addition, the Application Provider MUST re-verify that the capabilities chosen by the Identity Provider successfully pass the FastFed compatibility evaluation (<a href="#ProviderCompatibilityEvaluation" class="xref">Section 5</a>), based upon the metadata documents exchanged during the FastFed handshake. </p>
<p id="rfc.section.7.2.3.2.p.3">If verification succeeds, the Application Provider MUST capture the configuration information and initiate any actions necessary to activate the federation relationship for the specific <samp>authentication_profile</samp> and <samp>provisioning_profile</samp> indicated in the registration request. These actions are defined in the FastFed Profile for each protocol. </p>
<p id="rfc.section.7.2.3.2.p.4">For example, if SCIM provisioning was enabled, one of the actions may include activating the SCIM endpoint and registering the Identity Provider as an authorized client to the SCIM endpoint. The details of how these activities are implemented are outside the scope of FastFed. </p>
<p id="rfc.section.7.2.3.2.p.5">Due transient failures, it is possible that an Identity Provider may send a registration request but fail to receive, or process, the response from the Application Provider. When this occurs, the Identity Provider SHOULD retry the request. If the Application Provider receives a duplicate request, it MUST return the same response that was returned in the original request, as defined in <a href="#HandshakeRegistrationResponse" class="xref">Section 7.2.3.3</a>. </p>
<p id="rfc.section.7.2.3.2.p.6">As a reference to implementors, a duplicate request may be identified by noting that the information supplied in the request, such as the <samp>provider_domain</samp> and <samp>tenant_id</samp>, match an existing, completed, registration. </p>
<p id="rfc.section.7.2.3.2.p.7">When a duplicate is detected, the Application Provider MAY skip validation of the whitelisting expiration date and the FastFed compatibility evaluation (<a href="#ProviderCompatibilityEvaluation" class="xref">Section 5</a>), as these checks are either unnecessary or inapplicable to an already completed registration. </p>
<h1 id="rfc.section.7.2.3.3">
<a href="#rfc.section.7.2.3.3">7.2.3.3.</a> <a href="#HandshakeRegistrationResponse" id="HandshakeRegistrationResponse">Application Provider Sends Registration Response</a>
</h1>
<p id="rfc.section.7.2.3.3.p.1">If the registration is successful, the Application Provider responds with protocol-specific attributes needed by the Identity Provider to fully complete the registration. </p>
<p id="rfc.section.7.2.3.3.p.2">A successful response SHOULD use the HTTP 200 status code and return a JSON document <a href="#RFC4627" class="xref">[RFC4627]</a> using the <samp>application/json</samp> content type. </p>
<p id="rfc.section.7.2.3.3.p.3">The JSON document contains the following attributes: </p>
<dl>
<dt>fastfed_handshake_finalize_uri</dt>
<dd style="margin-left: 8">OPTIONAL. URL that the Identity Provider will invoke to signal to the Application Provider that the registration response was successfully received, all information has been captured and stored by the Identity Provider, and the federation relationship may be considered established. See <a href="#HandshakeFinalization" class="xref">Section 7.2.4</a> for details. <br><br> As a reference to implementors, an Application Provider may use this information to inform the Application Adminstrator that a registration is complete so that follow-up actions may occur. Example actions could include sending proactive guidance to the Administrator to test the configuration, or providing instructions for how to disable any pre-existing password-based authentication in favor of using the newly established single-sign-on capabilities through the Identity Provider. <br><br> The URL may be omitted, and the callback skipped, if the Application Provider does not need to be informed that the Identity Provider has successfully finished handling the registration response. </dd>
</dl>
<p> </p>
<p id="rfc.section.7.2.3.3.p.4">FastFed Profiles may extend the response with protocol-specific values. For example, the use of the <a href="#FastFedProfile.SCIM" class="xref">SCIM Provisioning</a> profile will result in the location of the SCIM endpoint being included in the response. </p>
<p id="rfc.section.7.2.3.3.p.5">If the registration is unsuccessful, the Application Provider SHOULD use an HTTP 4xx status code if the error is the result of an invalid request such as an unauthorized request or malformed parameters. Otherwise, if the error is the result of a problem in the Application Provider, it SHOULD respond with an HTTP 5xx status code. </p>
<p id="rfc.section.7.2.3.3.p.6">The following is a non-normative example of a successful response for a Provider who has chosen to use SAML and SCIM. </p>
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"fastfed_handshake_finalize_uri": "https://tenant-56789.app.example.com/fastfed/finalize",
"urn:ietf:params:fastfed:1.0:authentication:SAML:Basic": {
"saml_metatadata_uri": "https://tenant-56789.app.example.com/saml-metadata.xml"
},
"urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle": {
"scim_service_uri": "https://tenant-56789.app.example.com/scim",
"oauth_metadata": {
"grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
"token_endpoint": "https://tenant-56789.app.example.com/oauth",
"scope": "scim"
}
}
}
</pre>
<h1 id="rfc.section.7.2.3.4">
<a href="#rfc.section.7.2.3.4">7.2.3.4.</a> <a href="#HandshakeRegistrationResponseHandling" id="HandshakeRegistrationResponseHandling">Identity Provider Handles Registration Response</a>
</h1>
<p id="rfc.section.7.2.3.4.p.1">Upon receiving a successful registration response from the Application Provider, the Identity Provider MUST capture the configuration information and initiate any actions necessary to activate the federation relationship for the specific <samp>authentication_profile</samp> and <samp>provisioning_profile</samp> indicated in the registration request. These actions are defined in the FastFed Profile for each protocol. </p>
<p id="rfc.section.7.2.3.4.p.2">For example, if SCIM provisioning was enabled, one of the actions may include initiating the SCIM provisioning flows to replicate user information into the application. The details of how these activities are implemented is outside the scope of FastFed. </p>
<h1 id="rfc.section.7.2.4">
<a href="#rfc.section.7.2.4">7.2.4.</a> <a href="#HandshakeFinalization" id="HandshakeFinalization">Handshake Finalization</a>
</h1>
<p id="rfc.section.7.2.4.p.1">If the registraton response from the Application Provider included a value for <samp>fastfed_handshake_finalize_uri</samp> (<a href="#HandshakeRegistrationResponse" class="xref">Section 7.2.3.3</a>), the Identity Provider MUST invoke this endpoint after successfully processing the registration response and activating the federation relationship. </p>
<p id="rfc.section.7.2.4.p.2">The federation relationship may be considered activated when single-sign-on has been enabled (if used), and provisioning of user information has been initiated (if used). It is not necessary for long-running jobs, such as SCIM provisioning, to be fully completed. </p>
<p id="rfc.section.7.2.4.p.3">The Identity Provider invokes the endpoint by sending an HTTP POST to the URL with <samp>Content-Length: 0</samp> and an empty message body. </p>
<p id="rfc.section.7.2.4.p.4">The Application Provider SHOULD respond with an HTTP 200 OK status code. </p>
<p id="rfc.section.7.2.4.p.5">If the Identity Provider does not receive an HTTP 200 response from the Application Provider, it MUST periodically retry the request until a successful response is received or 48 hours has elapsed, whichever comes first. </p>
<p id="rfc.section.7.2.4.p.6">Retry logic is outside the scope of this specificication. As a reference to implementors, a potentioinal retry strategy could include retrying on an hourly basis until 48 hours has elapsed. Alternatively, an exponential backoff strategy may be applied to retry more frequently and slowly backoff. </p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#Security" id="Security">Security Considerations</a>
</h1>
<p id="rfc.section.8.p.1">TODO </p>
<h1 id="rfc.section.9">
<a href="#rfc.section.9">9.</a> <a href="#IANA" id="IANA">IANA Considerations</a>
</h1>
<p id="rfc.section.9.p.1">TODO </p>
<h1 id="rfc.references">
<a href="#rfc.references">10.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="FastFedProfile.JIT">[FastFedProfile.JIT]</b></td>
<td class="top">
<a title="Amazon">McAdams, K.</a>, "<a href="http://example.com">FastFed Profile for Just-In-Time (JIT) Provisioning</a>", October 2019.</td>
</tr>
<tr>
<td class="reference"><b id="FastFedProfile.OIDC">[FastFedProfile.OIDC]</b></td>
<td class="top">
<a title="Amazon">McAdams, K.</a>, "<a href="http://example.com">FastFed Profile for OpenID Connect</a>", October 2019.</td>
</tr>
<tr>
<td class="reference"><b id="FastFedProfile.SAML">[FastFedProfile.SAML]</b></td>
<td class="top">
<a title="Amazon">McAdams, K.</a>, "<a href="http://example.com">FastFed Profile for SAML</a>", October 2019.</td>
</tr>
<tr>
<td class="reference"><b id="FastFedProfile.SCIM">[FastFedProfile.SCIM]</b></td>
<td class="top">
<a title="Amazon">McAdams, K.</a>, "<a href="http://example.com">FastFed Profile for SCIM</a>", October 2019.</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 href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client Registration 1.0</a>", November 2014.</td>
</tr>
<tr>
<td class="reference"><b id="RFC1034">[RFC1034]</b></td>
<td class="top">
<a>Mockapetris, P.</a>, "<a href="https://tools.ietf.org/html/rfc1034">Domain names - concepts and facilities</a>", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2616">[RFC2616]</b></td>
<td class="top">
<a>Fielding, R.</a>, <a>Gettys, J.</a>, <a>Mogul, J.</a>, <a>Frystyk, H.</a>, <a>Masinter, L.</a>, <a>Leach, P.</a> and <a>T. Berners-Lee</a>, "<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>", RFC 2616, DOI 10.17487/RFC2616, June 1999.</td>
</tr>
<tr>
<td class="reference"><b id="RFC3986">[RFC3986]</b></td>
<td class="top">
<a>Berners-Lee, T.</a>, <a>Fielding, R.</a> and <a>L. Masinter</a>, "<a href="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4627">[RFC4627]</b></td>
<td class="top">
<a>Crockford, D.</a>, "<a href="https://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>", RFC 4627, DOI 10.17487/RFC4627, July 2006.</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="https://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.</td>
</tr>
<tr>
<td class="reference"><b id="RFC6125">[RFC6125]</b></td>
<td class="top">
<a>Saint-Andre, P.</a> and <a>J. Hodges</a>, "<a href="https://tools.ietf.org/html/rfc6125">Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>", RFC 6125, DOI 10.17487/RFC6125, March 2011.</td>
</tr>
<tr>
<td class="reference"><b id="RFC6749">[RFC6749]</b></td>
<td class="top">
<a>Hardt, D.</a>, "<a href="https://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", RFC 6749, DOI 10.17487/RFC6749, October 2012.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7033">[RFC7033]</b></td>
<td class="top">
<a>Jones, P.</a>, <a>Salgueiro, G.</a>, <a>Jones, M.</a> and <a>J. Smarr</a>, "<a href="https://tools.ietf.org/html/rfc7033">WebFinger</a>", RFC 7033, DOI 10.17487/RFC7033, September 2013.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7515">[RFC7515]</b></td>
<td class="top">
<a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="https://tools.ietf.org/html/rfc7515">JSON Web Signature (JWS)</a>", RFC 7515, DOI 10.17487/RFC7515, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7517">[RFC7517]</b></td>
<td class="top">
<a>Jones, M.</a>, "<a href="https://tools.ietf.org/html/rfc7517">JSON Web Key (JWK)</a>", RFC 7517, DOI 10.17487/RFC7517, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7518">[RFC7518]</b></td>
<td class="top">
<a>Jones, M.</a>, "<a href="https://tools.ietf.org/html/rfc7518">JSON Web Algorithms (JWA)</a>", RFC 7518, DOI 10.17487/RFC7518, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7519">[RFC7519]</b></td>
<td class="top">
<a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="https://tools.ietf.org/html/rfc7519">JSON Web Token (JWT)</a>", RFC 7519, DOI 10.17487/RFC7519, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7523">[RFC7523]</b></td>
<td class="top">
<a>Jones, M.</a>, <a>Campbell, B.</a> and <a>C. Mortimore</a>, "<a href="https://tools.ietf.org/html/rfc7523">JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</a>", RFC 7523, DOI 10.17487/RFC7523, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7565">[RFC7565]</b></td>
<td class="top">
<a>Saint-Andre, P.</a>, "<a href="https://tools.ietf.org/html/rfc7565">The 'acct' URI Scheme</a>", RFC 7565, DOI 10.17487/RFC7565, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7643">[RFC7643]</b></td>
<td class="top">
<a>Hunt, P.</a>, <a>Grizzle, K.</a>, <a>Wahlstroem, E.</a> and <a>C. Mortimore</a>, "<a href="https://tools.ietf.org/html/rfc7643">System for Cross-domain Identity Management: Core Schema</a>", RFC 7643, DOI 10.17487/RFC7643, September 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7644">[RFC7644]</b></td>
<td class="top">
<a>Hunt, P.</a>, <a>Grizzle, K.</a>, <a>Ansari, M.</a>, <a>Wahlstroem, E.</a> and <a>C. Mortimore</a>, "<a href="https://tools.ietf.org/html/rfc7644">System for Cross-domain Identity Management: Protocol</a>", RFC 7644, DOI 10.17487/RFC7644, September 2015.</td>
</tr>
<tr>
<td class="reference"><b id="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</b></td>
<td class="top">
<a title="W3C">Raggett, D.</a>, <a title="W3C">Hors, A.</a> and <a title="W3C">I. Jacobs</a>, "<a href="https://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>", December 1999.</td>
</tr>
</tbody></table>
<h1 id="rfc.appendix.A">
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#Acknowledgements" id="Acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.A.p.1">The OpenID Community would like to thank the following people for their contributions to this specification: </p>
<p></p>
<ul class="empty"><li>TODO</li></ul>
<p> </p>
<h1 id="rfc.appendix.B">
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#Notices" id="Notices">Notices</a>
</h1>
<p id="rfc.section.B.p.1">Copyright (c) 2017 The OpenID Foundation.</p>
<p id="rfc.section.B.p.2">The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.</p>
<p id="rfc.section.B.p.3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.</p>
<h1 id="rfc.appendix.C">
<a href="#rfc.appendix.C">Appendix C.</a> <a href="#History" id="History">Document History</a>
</h1>
<p id="rfc.section.C.p.1">[[ To be removed from the final specification ]]</p>
<h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Darin K. McAdams</span>
<span class="n hidden">
<span class="family-name">McAdams</span>
</span>
</span>
<span class="org vcardline">Amazon</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:darinm@amazon.com">darinm@amazon.com</a></span>
</address>
</div>
</body>
</html>