Google

1600 Amphitheatre Pkwy Mountain View CA 94043 USA +1 650-253-0000 wdenniss@google.com http://google.com/

Security OAuth Working Group 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).

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. 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. 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. 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.

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 . If these words are used without being spelled in uppercase then they are to be interpreted with their normal natural language meanings.

In addition to the terms defined in referenced specifications, this document uses the following terms: 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. OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider. Fast Identity Verification, an optimisation to OpenID Connect that is the subject of this specification. An OpenID Connect request that qualifies for FastIDV processing, as per

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.

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: login_hint MUST be supplied. The prompt parameter MUST NOT be present. response_type MUST be 'code', 'id_token', or both. The scope 'openid' MUST be present. One of the scopes 'email' and 'phone' MAY be present. 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. 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. OpenID Connect requests meeting the above requirements qualify as "FastIDV Requests and can be processed per . 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.

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. login_hint MUST match a valid, logged in user. If a login_hint 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 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. If the request contains Additional Scopes, as defined by , 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.

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. 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.

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. 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).

If the OP supports OpenID Connect Discovery, it uses this metadata value to advertise its support for Fast Identity Verification: 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. 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.

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.

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. 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. 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.

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. 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.

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. 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. 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. 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 , and process them as normal OpenID Connect requests instead. 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 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.

To prevent a malicious RP trying multiple FastIDV requests in serial, requests with a prompt parameter must be disqualified from FastIDV processing (and instead processed as regular OpenID Connect requests), as specified in . 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 prompt, it just means that FastIDV processing should not apply to those requests.

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 ) on every HTTP request to prevent the RP embedding the request. For example, "X-Frame-Options: DENY".

As a failsafe incase other countermeasures fail, abuse protection that rate-limits the number of failed FastIDV requests from a given client is RECOMMENDED.

To protect against an unrelated party sending users through a FastIDV flow, the 'state' MUST be used as recommended in Section 10.12 of .

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.