<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>OpenID Connect Fast Identity Verification</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.2" rel="Chapter" title="2 Notational Conventions"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Terminology"/>
<link href="#rfc.section.4" rel="Chapter" title="4 The FastIDV Optimisation"/>
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Qualifying FastIDV Requests"/>
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Processing FastIDV Requests"/>
<link href="#rfc.section.5" rel="Chapter" title="5 OpenID Provider Discovery"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Privacy Considerations"/>
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Confirming the Login State of the User"/>
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Asserting Hinted Values"/>
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 Hint-to-sub Mapping"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Security Considerations"/>
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Programmatic Detection of Signed-in Users"/>
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Cross-site forgery"/>
<link href="#rfc.references" rel="Chapter" title="8 References"/>
<link href="#rfc.references.1" rel="Chapter" title="8.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="8.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.1.dev0 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Denniss, W." />
<meta name="dct.identifier" content="urn:ietf:id:draft-wdenniss-oidc-fastidv-00" />
<meta name="dct.issued" scheme="ISO8601" content="2015-9-20" />
<meta name="dct.abstract" content="Fast Identity Verification is a technique that OpenID Connect providers can implement to enable relying parties to verify identity information they already know about a user, in a way that is completely transparent to the user (provided they have an active authentication session). " />
<meta name="description" content="Fast Identity Verification is a technique that OpenID Connect providers can implement to enable relying parties to verify identity information they already know about a user, in a way that is completely transparent to the user (provided they have an active authentication session). " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">OAuth Working Group</td>
<td class="right">W. Denniss</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Google</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">September 20, 2015</td>
</tr>
<tr>
<td class="left">Expires: March 23, 2016</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">OpenID Connect Fast Identity Verification<br />
<span class="filename">draft-wdenniss-oidc-fastidv-00</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>Fast Identity Verification is a technique that OpenID Connect providers can implement to enable relying parties to verify identity information they already know about a user, in a way that is completely transparent to the user (provided they have an active authentication session). </p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on March 23, 2016.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>2. <a href="#rfc.section.2">Notational Conventions</a></li>
<li>3. <a href="#rfc.section.3">Terminology</a></li>
<li>4. <a href="#rfc.section.4">The FastIDV Optimisation</a></li>
<ul><li>4.1. <a href="#rfc.section.4.1">Qualifying FastIDV Requests</a></li>
<li>4.2. <a href="#rfc.section.4.2">Processing FastIDV Requests</a></li>
</ul><li>5. <a href="#rfc.section.5">OpenID Provider Discovery</a></li>
<li>6. <a href="#rfc.section.6">Privacy Considerations</a></li>
<ul><li>6.1. <a href="#rfc.section.6.1">Confirming the Login State of the User</a></li>
<li>6.2. <a href="#rfc.section.6.2">Asserting Hinted Values</a></li>
<li>6.3. <a href="#rfc.section.6.3">Hint-to-sub Mapping</a></li>
</ul><li>7. <a href="#rfc.section.7">Security Considerations</a></li>
<ul><li>7.1. <a href="#rfc.section.7.1">Programmatic Detection of Signed-in Users</a></li>
<li>7.2. <a href="#rfc.section.7.2">Cross-site forgery</a></li>
</ul><li>8. <a href="#rfc.references">References</a></li>
<ul><li>8.1. <a href="#rfc.references.1">Normative References</a></li>
<li>8.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Acknowledgements</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="#intro" id="intro">Introduction</a></h1>
<p id="rfc.section.1.p.1">The OpenID Connect specification, as an identity layer on OAuth 2.0, allows relying parties to get identity assertions from identity providers. Typically the user is prompted to grant access to their identity as part of the authentication flow. </p>
<p id="rfc.section.1.p.2">In some cases, the relying party (RP) may already have identity information about the user, such as their email address or phone number which may have been supplied in an identifier first sign-in flow, from an account chooser (such as AccountChooser.com), or in a registration form. In these cases, it may be possible to not prompt the user to consent to share identity information, as the relying party already has that information. </p>
<p id="rfc.section.1.p.3">If user consent is not required in certain specific circumstances, OpenID Connect flows can be used seamlessly to verify the identity of the supplied user by using their signed-in state at the identity provider. This technique is referred to as FastIDV, and is the subject of this specification. </p>
<p id="rfc.section.1.p.4">By using the FastIDV pattern, OPs can enable email first flows with a highly efficient user experience for federated sign-in. It also offers an alternative UX to traditional "verify your email address" emails and "verify your phone number" SMS messages. Another potential advantage over those traditional verification flows is that if the provider supports account signals as being developed by the OIDF RISK workgroup, then this FastIDV flow can be used to enable the provider to remember that the site requesting the verification should be notified of any account signals in the future. </p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#NotationalConventions" id="NotationalConventions">Notational Conventions</a></h1>
<p id="rfc.section.2.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 Key words for use in RFCs to Indicate Requirement Levels <a href="#RFC2119">[RFC2119]</a>. If these words are used without being spelled in uppercase then they are to be interpreted with their normal natural language meanings. </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#terminology" id="terminology">Terminology</a></h1>
<p id="rfc.section.3.p.1">In addition to the terms defined in referenced specifications, this document uses the following terms:</p>
<p/>
<dl>
<dt>"OpenID Provider (OP)"</dt>
<dd style="margin-left: 8">OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User. </dd>
<dt>"Relying Party (RP)"</dt>
<dd style="margin-left: 8">OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider. </dd>
<dt>"FastIDV"</dt>
<dd style="margin-left: 8">Fast Identity Verification, an optimisation to OpenID Connect that is the subject of this specification. </dd>
<dt>"FastIDV Request"</dt>
<dd style="margin-left: 8">An OpenID Connect request that qualifies for FastIDV processing, as per <a href="#fast_idv_processing">Section 4.2</a> </dd>
</dl>
<p> </p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#fast_idv_flow" id="fast_idv_flow">The FastIDV Optimisation</a></h1>
<p id="rfc.section.4.p.1">FastIDV enhances the Authorization Code, Implicit and Hybrid flows of OpenID Connect with additional logic that if met means that the user consent step can be bypassed. </p>
<h1 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1.</a> <a href="#fast_idv_request" id="fast_idv_request">Qualifying FastIDV Requests</a></h1>
<p id="rfc.section.4.1.p.1">FastIDV requests represent a subset of valid OpenID Connect requests. Any invalid OpenID Connect request is by definition also invalid for FastIDV. In addition to being a normal, valid, OpenID Connect request, FastIDV requests must meet the following requirements: </p>
<p/>
<ol>
<li><samp>login_hint</samp> MUST be supplied. </li>
<li>The <samp>prompt</samp> parameter MUST NOT be present. </li>
<li><samp>response_type</samp> MUST be 'code', 'id_token', or both. </li>
<li>The scope 'openid' MUST be present. </li>
<li>One of the scopes 'email' and 'phone' MAY be present. </li>
<li>Scopes other than those listed above MAY also be present although it is NOT RECOMMENDED for clients to supply them. Any such scopes are referred to as 'Additional Scopes' for the purposes of FastIDV. </li>
<li>If the 'email' or 'phone' scope is present, the login_hint supplied MUST match that scope's format, i.e. the login_hint should be an email address when 'email' is supplied, and a phone number when 'phone' is supplied. Where the login_hint format does not match these scopes, they are treated as Additional Scopes. </li>
</ol>
<p> </p>
<p id="rfc.section.4.1.p.3">OpenID Connect requests meeting the above requirements qualify as "FastIDV Requests and can be processed per <a href="#fast_idv_processing">Section 4.2</a>. </p>
<p id="rfc.section.4.1.p.4">Requests that are not FastIDV Requests MUST be processed following the OpenID Connect standard. The OP MUST NOT respond with a FastIDV specific error message if an OpenID Connect request does not qualify as a FastIDV Request. </p>
<h1 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2.</a> <a href="#fast_idv_processing" id="fast_idv_processing">Processing FastIDV Requests</a></h1>
<h1 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1.</a> <a href="#fast_idv_validating" id="fast_idv_validating">Validating the FastIDV Request for the signed-in user</a></h1>
<p id="rfc.section.4.2.1.p.1">On receipt of a FastIDV Request, the OP performs the following additional checks to see if the request is valid for the current signed-in user state. </p>
<p/>
<ol>
<li><samp>login_hint</samp> MUST match a valid, logged in user. </li>
<li>If a <samp>login_hint</samp> of type other than the subject identifier is used, the OP MAY disqualify an otherwise valid FastIDV request if hint-to-sub lookups are disallowed by policy (see <a href="#login_hint">Section 6</a> for a non-normative discussion of the privacy implications of the hint-to-sub lookup). The policy choices of an OP regarding hint-to-sub lookups is outside the scope of this specification. </li>
<li>If the request contains Additional Scopes, as defined by <a href="#fast_idv_request">Section 4.1</a>, the OP SHOULD disqualify an otherwise valid FastIDV request if proper user consent has not been previously obtained for those scopes, as per the policy of the OP. The exact policy for handling of Additional Scopes within FastIDV Requests is outside the scope of this specification. </li>
</ol>
<p> </p>
<h1 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2.</a> <a href="#fast_idv_valid" id="fast_idv_valid">Processing Valid FastIDV Requests</a></h1>
<p id="rfc.section.4.2.2.p.1">If the FastIDV Request isn't invalidated by the above checks, then the OP SHOULD process the request according to the OpenID Connect specification but without an interactive dialog (as defined in 3.1.2.4., and referenced in sections 3.2.2.4. and 3.3.2.4.) that interrupts the flow. </p>
<p id="rfc.section.4.2.2.p.2">FastIDV supporting OPs MAY prompt the user even on a valid FastIDV request, if they determine it is needed for any reason. It is expected however, by declaring support for this standard, that OPs do not present an interactive dialog in normal circumstances for valid FastIDV requests. </p>
<h1 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3.</a> <a href="#fast_idv_invalid" id="fast_idv_invalid">Processing Invalid FastIDV Requests</a></h1>
<p id="rfc.section.4.2.3.p.1">If the FastIDV request was invalidated, it MUST be processed according to the OpenID Connect standard as usual. The OP MUST NOT respond with a FastIDV specific error message if an OpenID Connect request was disqualified as a FastIDV Request. </p>
<p id="rfc.section.4.2.3.p.2">It is a common case for users to be signed-out of the OP, thus it is expected for honest clients attempting to use FastIDV to hint identifiers for users that are not signed-in. When the user specified by 'login_hint' is not signed-in, the OP SHOULD redirect to a sign-in page, reverting to normal OpenID Connect protocol behavior. It is RECOMMENDED that the 'login_hint' is used to optimise the sign-in experience (for example, by pre-filling the email address field). </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#openid-provider-discovery" id="openid-provider-discovery">OpenID Provider Discovery</a></h1>
<p id="rfc.section.5.p.1">If the OP supports OpenID Connect Discovery, it uses this metadata value to advertise its support for Fast Identity Verification: </p>
<p/>
<dl>
<dt>"fastidv_supported"</dt>
<dd style="margin-left: 8">OPTIONAL. Boolean value specifying whether the OP supports Fast Identity Verification, with true indicating support (and compliance with this specification). If omitted, the default value is false. </dd>
<dt>"fastidv_scopes"</dt>
<dd style="margin-left: 8">OPTIONAL. String value specifying the list of scopes the OP supports for FastIDV, any combination of 'openid', 'email' and 'phone'. Multiple scope values are separated by spaces. The OP MUST support login_hint formats that match scopes declared here. For example "openid email" implies that login_hints in the form of either the OpenID Connect subject identifier ('sub'), or email will be accepted. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#login_hint" id="login_hint">Privacy Considerations</a></h1>
<p id="rfc.section.6.p.1">The following is a non-normative discussion of the privacy considerations with by-passing user consent for OpenID Connect requests that qualify for FastIDV handling. </p>
<h1 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1.</a> <a href="#login_hint_confirm" id="login_hint_confirm">Confirming the Login State of the User</a></h1>
<p id="rfc.section.6.1.p.1">Successful FastIDV requests result in the login state of the user being revealed. FastIDV does not explicitly confirm the negative (that the user was not logged in), though it can be roughly inferred by the lack of a response. </p>
<p id="rfc.section.6.1.p.2">Typically the user supplied their account identifier to the RP with the intent to sign-in or verify their identity at the RP, which is what prompted the RP to initiate the FastIDV flow. Thus, the RP confirming the signed-in state of the user using the identifier they supplied is reasonable behavior. </p>
<p id="rfc.section.6.1.p.3">OPs that do not wish to reveal the sign-in state of a user based on a hint supplied by the RP SHOULD NOT implement this spec. In that case, the OP should evaluate what visual experience their users will encounter if an RP uses an account chooser like AccountChooser.com. Users may be confused if they feel they used an account chooser to consent to sharing their identifier with a site, but are then "asked again" to consent on another page. </p>
<h1 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2.</a> <a href="#login_hint_assertion" id="login_hint_assertion">Asserting Hinted Values</a></h1>
<p id="rfc.section.6.2.p.1">ID Tokens contain user information beyond the simple fact that the user is logged in, such as their 'sub' and in some cases 'email' and 'phone' identifiers. Typically this information is not revealed via OpenID Connect without user consent. In the case of FastIDV however, the RP has given the identifiers to the OP in the form of the login_hint, and thus when the ID Token contains this information, it is not new information for the RP. </p>
<p id="rfc.section.6.2.p.2">As the RP already has access to the information they hinted, the OP does not need additional consent to return that same information as claims in an ID Token. </p>
<h1 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3.</a> <a href="#login_hint_mapping" id="login_hint_mapping">Hint-to-sub Mapping</a></h1>
<p id="rfc.section.6.3.p.1">When FastIDV is used with the 'email' or 'phone' login_hint types, the 'sub' is still included in the ID Token despite that fact that this identifier was not hinted by the RP. </p>
<p id="rfc.section.6.3.p.2">For some OPs, hint-to-sub mapping with FastIDV is not a concern, as hint-to-sub lookups are already supported in an unauthenticated fashion. For example, an email provider may already support the looking up of a user's profile page when an email is supplied, to enrich the email composition experience. </p>
<p id="rfc.section.6.3.p.3">OPs that return a client-specific subject identifier (also known as a directed identifier) would normally be unconcerned with providing hint-to-sub mapping, as the identifier is only useful the context of that client. </p>
<p id="rfc.section.6.3.p.4">The exact policy of revealing the 'sub' to RPs who know other user identifiers varies from OP to OP, and is outside the scope of this specification. OPs who do not support hint-to-sub lookups for particular login_hint types, may chose to disqualify FastIDV requests for the unsupported login_hint types as per <a href="#fast_idv_processing">Section 4.2</a>, and process them as normal OpenID Connect requests instead. </p>
<p id="rfc.section.6.3.p.5">OPs that support OpenID Connect Discovery SHOULD declare the scopes that match the login_hint types they support in their OpenID Connect discovery document as per <a href="#openid-provider-discovery">Section 5</a>. </p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a></h1>
<h1 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1.</a> <a href="#prog_detection" id="prog_detection">Programmatic Detection of Signed-in Users</a></h1>
<p id="rfc.section.7.1.p.1">A risk of FastIDV is that a relying party could potentially query the OP with a large list of email addresses, in order to scan for a currently signed-in user. This can be mitigated in a number of ways. </p>
<h1 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1.</a> <a href="#security_no_errors" id="security_no_errors">Disqualifying requests with the 'prompt' parameter</a></h1>
<p id="rfc.section.7.1.1.p.1">To prevent a malicious RP trying multiple FastIDV requests in serial, requests with a <samp>prompt</samp> parameter must be disqualified from FastIDV processing (and instead processed as regular OpenID Connect requests), as specified in <a href="#fast_idv_request">Section 4.1</a>. </p>
<p id="rfc.section.7.1.1.p.2">As such, an OP MUST NOT return an error for a FastIDV qualified request. It will either return a success response, or redirect the user to a prompt. This doesn't prevent normal use of <samp>prompt</samp>, it just means that FastIDV processing should not apply to those requests. </p>
<h1 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2.</a> <a href="#security_iframe" id="security_iframe">Preventing use in iframes</a></h1>
<p id="rfc.section.7.1.2.p.1">To prevent a malicious RP using hidden iframes to execute multiple requests looking for a success response, the Authorization Endpoint MUST set a X-Frame-Options header (as defined by <a href="#RFC7034">[RFC7034]</a>) on every HTTP request to prevent the RP embedding the request. For example, "X-Frame-Options: DENY". </p>
<h1 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3.</a> <a href="#security_rate_limiting" id="security_rate_limiting">Rate Limiting</a></h1>
<p id="rfc.section.7.1.3.p.1">As a failsafe incase other countermeasures fail, abuse protection that rate-limits the number of failed FastIDV requests from a given client is RECOMMENDED. </p>
<h1 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2.</a> <a href="#security_state" id="security_state">Cross-site forgery</a></h1>
<p id="rfc.section.7.2.p.1">To protect against an unrelated party sending users through a FastIDV flow, the 'state' MUST be used as recommended in Section 10.12 of <a href="#RFC6749">[RFC6749]</a>. </p>
<h1 id="rfc.references"><a href="#rfc.references">8.</a> References</h1>
<h1 id="rfc.references.1"><a href="#rfc.references.1">8.1.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="RFC6749">[RFC6749]</b>
</td>
<td class="top"><a>Hardt, D.</a>, "<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", RFC 6749, DOI 10.17487/RFC6749, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="OIDC.Core">[OIDC.Core]</b>
</td>
<td class="top"><a>Sakimura, N.</a>, <a>Bradley, J.</a>, <a>Jones, M.</a>, <a>de Medeiros, B.</a> and <a>C. Mortimore</a>, "<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0 incorporating errata set 1</a>", February 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7034">[RFC7034]</b>
</td>
<td class="top"><a>Ross, D.</a> and <a>T. Gondrom</a>, "<a href="http://tools.ietf.org/html/rfc7034">HTTP Header Field X-Frame-Options</a>", RFC 7034, DOI 10.17487/RFC7034, October 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a>Bradner, S.</a>, "<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.references.2"><a href="#rfc.references.2">8.2.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="RFC6819">[RFC6819]</b>
</td>
<td class="top"><a>Lodderstedt, T.</a>, <a>McGloin, M.</a> and <a>P. Hunt</a>, "<a href="http://tools.ietf.org/html/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>", RFC 6819, DOI 10.17487/RFC6819, January 2013.</td>
</tr>
</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 author would like to acknowledge the contributions of the following individuals: Adam Dawes, Breno de Medeiros, Eric Sachs, Mengcheng Duan, Michael Dietz, Naveen Agarwal. </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">William Denniss</span>
<span class="n hidden">
<span class="family-name">Denniss</span>
</span>
</span>
<span class="org vcardline">Google</span>
<span class="adr">
<span class="vcardline">1600 Amphitheatre Pkwy</span>
<span class="vcardline">
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="code">94043</span>
</span>
<span class="country-name vcardline">USA</span>
</span>
<span class="vcardline">Phone: +1 650-253-0000</span>
<span class="vcardline">EMail: <a href="mailto:wdenniss@google.com">wdenniss@google.com</a></span>
<span class="vcardline">URI: <a href="http://google.com/">http://google.com/</a></span>
</address>
</div>
</body>
</html>