Facebook, Inc. B. Hill, Ed. Unofficial Draft Facebook, Inc. October 26, 2017 Expires: April 29, 2018 Delegated Account Recovery draft-hill-delegated-recovery Abstract Delegated Account Recovery allows an application to delegate the capability to recover an account (e.g. in the event of a credential loss or compromise) to an account controlled by the same user or entity at a third party service provider. Status of This Memo This Unofficial Draft will expire on April 29, 2018. Copyright Notice Copyright (c) 2016-2017 Facebook, Inc. and the persons identified as the document authors and published under the Creative Commons Attribution 4.0 International license. Table of Contents 1. Introduction 1.1. Notational Conventions 1.1.1. Presentation Language 1.2. Challenges with Existing Account Recovery Solutions 1.2.1. Recovery Questions 1.2.2. Password Hints 1.2.3. Email Recovery 1.2.4. Federated Authentication 1.2.5. Alternate Methods 1.3. Relationship to Other Protocols 1.4. Goals 1.5. Roles 1.6. Protocol Flow 1.6.1. Establishing a Delegated Recovery Capability 1.6.2. Exercising a Delegated Recovery Capability 1.7. TLS Version 1.8. HTTP Redirections 1.9. Application User Agents 2. Fetching Configuration 3. Protocol Endpoints 3.1. Save Token Endpoint 3.1.1. Processing Instructions 3.2. Save Token Return Endpoint 3.3. Save Token Async API Endpoint 3.3.1. Asynchronous Message Contract 3.4. Recover Account Endpoint 3.5. Recover Account Return Endpoint 3.6. Token Status Endpoint 3.6.1. Processing Instructions 3.6.2. Security Considerations 4. Token Generation 4.1. Recovery Token 4.1.1. Internal Structure 4.1.2. Opaque Data 4.1.3. Signature 4.2. Counter-Signed Recovery Token 4.2.1. Internal Structure 4.2.2. Counter-Signed Recovery Token Signature 5. Use in Key Recovery 6. Security Considerations 6.1. Deterministic Use of ECDSA 6.2. User Notification 6.3. Additional Verification 6.3.1. At the Recovery Provider 6.3.2. At the Account Provider 6.4. Low Friction Tokens and Delegated Multi-Factor Authentication 6.5. Cross-Site Request Forgery 6.6. Breach Detection 6.7. Clock Skew 6.8. Key Loss and Compromise 6.9. TLS or HTTPS Certificate Compromise 6.10. Token Leakage 7. Implementation Notes 8. IANA Considerations 9. Acknowledgements 10. Normative References Appendix A. Initial Algorithm Registry Contents Author's Address 1. Introduction 1.1. Notational Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 1.1.1. Presentation Language This document deals with the formatting of tokens in an external representation using a casually defined syntax drawing from that used in [RFC5246] and resembling the programming language "C". The purpose is to document the binary token format only. The basic numeric data type is an unsigned byte (uint8). All larger numeric data types are formed from fixed-length series of bytes concatenated from left to right and are also unsigned. The following numeric types are predefined. uint8 uint16[2]; uint8 uint32[4]; uint8 uint64[8]; All values, here and elsewhere in the specification, are stored in network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060. The type string is defined as a concatenated sequence of octet sequences representing ASCII characters, one per octet. [RFC3629] The term URL is defined by reference to [RFC3986] in this document. "URL" is used deliberately in preference to "URI" as all such objects in this document are used to access network resources and such objects as used by this document lack any persistent meaning after the resource to which they refer ceases to exist. 1.2. Challenges with Existing Account Recovery Solutions Network services that rely on user credentials must also cope with the reality that users may forget or lose exclusive control of these credentials. As a consequence, nearly every such service must implement an alternate authentication process to enable a user to recover control of an account. In practice, there are few good options for doing this, and these recovery flows are often the weakest link in securing accounts. 1.2.1. Recovery Questions A common and self-contained method of account recovery is to ask the user additional questions that they are less likely to forget the answer to than a more arbitrary password. The same features that make such a question useful for recovery also reduce its security: o Things that are memorable may often not be fully private. Friends and family members likely know the answers to many such questions, and for highly public figures it may be possible to research this information. o Allowing users to select their own questions may result in questions with a small possible domain of answers (favorite color, favorite superhero) that make brute force guessing highly effective, even if rate-limiting is applied. o Choosing questions that are both secure and memorable is difficult, and common choices of subject matter may not be applicable across cultural contexts (mother's maiden name, name of a pet), age ranges (first car) or other differentiating characteristics of large and diverse audiences. o The limited selection of questions which are both memorable and applicable to the broadest possible audience makes re-use of these questions and answers common among many service providers, with attendant risks that disclosure of answers to a malicious party by any provider may compromise many accounts at unrelated providers. Furthermore it is difficult for a user to change their answers in the event of such a compromise. 1.2.2. Password Hints Password hints are extremely problematic - by definition they must be revealed to an unauthenticated user, which implies reversibly encrypted storage at best, reveals information about a password (or often the password itself), and common hints at multiple services may reveal where a password is reused, facilitating further attacks. 1.2.3. Email Recovery Users are unlikely to forget their email address, and a common practice is to email the user URL that encodes the ability to recover the account. This is the most widely deployed mechanism at the time of this writing, but it has a number of shortcomings. o Forcing users to everywhere use an email address has privacy implications, potentially allowing service providers to collude to track individuals' activity across many domains. o Email addresses are not universal, and are becoming less so. Especially in the developing world or with younger audiences, email may not be the first network service individuals provision for themselves, if they provision it at all. o Email addresses get recycled and reassigned to new owners. o Users may use a weakly-secured email addresses when signing up for a new service, for example an address maintained to collect the unwanted commercial correspondence often expected to result from signing up for a new online service. o Email does not provide guarantees of deliverability or end-to-end transport security. An adversary performing pervasive surveillance may likely be able to abuse such weaknesses. o Emails in large organizations are rarely private to their recipient. In addition to the commonplace that high-value accounts belonging to executives may be accessible by their assistants, the contents and especially links in the email of every user in a modern organization may commonly be logged for legal discovery purposes, or crawled to identify malware and phishing attacks. o The capabilities of an emailed reset link must be encoded in the GET string to ensure compatibility with non-HTML capable mail user agents, and so may leak in the HTTP Referer header to any other content included in a recovery page. (e.g. an analytics script hosted at a third-party origin) o Users are commonly authenticated to email services all the time on many devices. Account recovery through email is an unstructured process which does not ensure the user was strongly authenticated for a high-risk action. A simple password compromise, or even brief loss of control of an unlocked device where the user is logged in, may be sufficient to transitively compromise many other accounts of the user. If the only way to notify the user that their account was reset is back through the same email channel, an attacker can easily cover their tracks. o The wide diversity of mail user agents means that even if account recovery emails could be detected heuristically by providers or explicitly identified with metadata from senders, it would be remain difficult for email providers to apply special treatment to such messages. o An attacker that compromises a user's account may change the email address associated with it. Without very carefully designed processes, it may be impossible for the genuine user to recover their account after such a change if recovery flows are purely email-based. o Email recovery flows cannot be used to recover capabilities, such as cryptographic keys, that may be necessary to use an account (e.g. a network-based file store that offers encrypted files) but which the user does not want the account provider to have access to at all times. 1.2.4. Federated Authentication Federated systems for authentication take many forms and solve the problem of account recovery (or at least delegate it implicitly to the Identity Provider). However, after fifteen years of widespread deployment of such systems, we see few mainstream services that are willing to rely exclusively on federated logins for a variety of reasons. o A user may be unwilling to disclose their identity, other information, or grant permissions to a new service they have just begun to use and about which they have not yet formed an opinion of its value or trustworthiness. o A service may be unwilling to depend on a third-party for access to its customer base. They may view "owning" their relationship with the customer as having business value, may have a regulatory mandate to do so, or may not want to be beholden to the availability of a third party for their most important customer interactions. o A service may view providers of federated login services as competitors or potential competitors, and not wish to disclose information about how often users are logging on, who their most active users are or not desire to show a competitor's logo as part of their login process. 1.2.5. Alternate Methods Methods do exist to strongly re-authenticate an account holder in the absence of a password or other primary credential. Device-based or multi-factor authentication, multi-device authentication, or trusted connections in a social network are possibilities. Unfortunately, of the potentially hundreds of services a user interacts with in a year, only a few are likely able to leverage such factors. The rest will lack the information, resources, and user consent needed. Furthermore, the characteristics that make good recovery systems strong also may make them unique to a particular service, preventing broad adoption as a best practice by other providers. 1.3. Relationship to Other Protocols Delegated Recovery is similar in some respects to OAuth [RFC5849]and related protocols. It is not constructed simply as a profile of one these protocols as it relies on different trust semantics. Because tokens granting an account recovery capability are expected to have an indefinite lifetime and should be able to remain valid even following the compromise and/or rotation of the keys they were originally issued under, tokens in this protocol derive their authority at a point in time from being signed with currently published public keys, discoverable over HTTPS. As this trust model is different than other protocols in the broad OAuth family, profiling an existing protocol to fit these needs would likely be considerably more complex than implementing a new, minimalist protocol from scratch. As such, the latter approach has been taken here. 1.4. Goals Goals for Delegated Account Recovery include: o Allow network services that do not have the resources or information to build a secure and usable account recovery process to delegate the function to network services that can. o Allow users to choose to use service providers that can strongly re-authenticate them to recover accounts at other services. o Disclose as little information as possible, and no more than is necessary, to protocol participants. o As much as possible, require multiple points of failure in order for accounts to be compromised through the recovery process. o Be resilient in the face of compromises, including loss of exclusive control of cryptographic key material, and allow re- establishment of trust in stored recovery capabilities without user action. o Provide, through the protocol semantics, explicit information about security-critical account actions and information flow between providers to enable better auditing, anomaly detection and remediation in the event of compromises. o Allow users to set up a durable recovery capability when in control of their account, which can be exercised even after malicious changes to the account (such as changing an associated email address or personal information) following a compromise. 1.5. Roles Delegated Recovery defines three roles: User The entity in control of the accounts. Account Provider The network service at which a user has an account they need to establish a recovery capability for. Recovery Provider The network service which offers the delegated account recovery service, and at which a user has an account and wishes to use to recover control of other accounts. 1.6. Protocol Flow 1.6.1. Establishing a Delegated Recovery Capability +--------+ +------+ +----+---+ |Account | | User | |Recovery| |Provider| | | |Provider| | | | | | | +-+------+ +--+---+ +----+---+ | | | | 1. Select Recovery | | | Provider | | |<--------------------+ | | | 2. Retrieve | | | Configuration | +---------------------------------------->| |<----------------------------------------+ | | | +----+ 3. Generate Recovery| | | | Token | | +--->| | | | | | | 4. Redirect User | | | Agent to Recovery | | | Provider with Token | | +-------------------->+------------------>| | | | | | 5. (if needed) | | | Authenticate User | | |<------------------+ | +------------------>| | | | | | 6. Retrieve | | | Configuration | |<----------------------------------------+ +---------------------------------------->| | | | | (optional) | 7. Verify and +---+ | 8. Notify Account | Save Recovery | | | Provider with | Token |<--+ | Result Code for | | | token ID | | |<----------------------------------------+ | | | | 9. Redirect User | | | Agent back to | | | Account Provider | | | | | |<--------------------+<------------------+ | | | | | | V V V Figure 1: Recovery Capability Establishment The abstract Delegated Recovery capability establishment flow illustrated in Figure 1 describes the interaction between the three roles and includes the following steps: 1. The User, having already established control of an account with the Account Provider, indicates to the Account Provider which Recovery Provider they would like to use. 2. The Account Provider makes a GET request to determine if the service of the user's choice offers the Delegated Recovery service and what its protocol endpoint URLs are. This step may be unnecesssary if the Account Provider already knows the configuration for the chosen Recovery Provider. 3. The Account Provider generates a recovery token for the User and Recovery Provider. 4. The Account Provider sends the Token to the User Agent with instructions to deliver it to the Recovery Provider URL indicated in the configuration. 5. Upon receiving the Token, the Recovery Provider authenticates the user if they are not logged in. 6. The Recovery Provider makes a GET request to the Account Provider to discover its public keys and protocol URLs. 7. The Recovery Provider validates the signature on the token and saves it. 8. The Recovery Provider optionally notifies the Account Provider of the status of the operation. 9. The Recovery Provider redirects the user agent back to the callback URL indicated by the configuration with a status code. 1.6.2. Exercising a Delegated Recovery Capability +--------+ +------+ +----+---+ |Account | | User | |Recovery| |Provider| | | |Provider| | | | | | | +-+------+ +--+---+ +----+---+ | (optional) | | | 1. Initiate Recovery| | | | | |<--------------------+ | | | | | | (optional) | | | 2. Retrieve | | | Configuration | +---------------------------------------->| |<----------------------------------------+ | | | | (optional) | | | 3. Offer User link | 1. Initiate | | to Recovery Provider| Recovery | | with origin hint | | +-------------------->+------------------>| | | | | | 4. (if needed) | | | Authenticate User | | |<------------------+ | +------------------>| | | | | | 5. Retrieve | | | Configuration | |<----------------------------------------+ +---------------------------------------->| | | | | | 6. Retrieve and +---+ | 7. Send User | Counter-Sign | | | Agent to Account | Recovery Token |<--+ | Provider with | | | Counter-Signed | | | Recovery Token | | |<--------------------+<------------------+ | | | | | 8. Retrieve | | | Configuration | +---------------------------------------->| |<----------------------------------------+ | | | +----+ 9. Validate | | | | Recovery Token | | +--->| | | | | | | | | | 10. Restore Control | | | of Account | | |-------------------->| | | | | V V V Figure 2: Exercising a Recovery Capability The abstract flow depicting the exercising of a Delegated Recovery capability in Figure 2 describes the interaction between the the roles and includes the following steps: 1. The user initiates a recovery, either at the Account Provider, or with the Recovery Provider. 2. (optional) the Account Provider GETs the current configuration for the Recovery Provider to be used. 3. (optional) The Account Provider offers or redirects the user to the Recovery Provider's endpoint, with a hint of the origin of the account the User wants to recover. 4. The Recovery Provider authenticates the user appropriately for conducting a recovery transaction. 5. The Recovery Provider makes a GET request to discover the current URL for exercising recovery at the Account Provider. 6. The Recovery Provider counter-signs the token and additional fields with its published key. 7. The Recovery Provider sends the user agent to the Account Provider's recovery URL with the counter-signed token. 8. The Account Provider receives a token, and retrieves the Recovery Provider's current configuration to discover its keys. 9. The Account Provider validates the counter-signature, additional fields, its originally issued token, and takes any other necessary steps to complete risk-appropriate re-authentication of the user. 10. The Account Provider restores control of the account to the user and allows a new primary authentication method or credential to be established. 1.7. TLS Version Whenever Transport Layer Security (TLS) is used by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 [RFC5246]is the most recent and widely deployed version. Implementations may also support additional transport-layer security mechanisms that meet their security requirements. 1.8. HTTP Redirections This specification makes extensive use of HTTP redirections, in which the client or the authorization server directs the resource owner'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. When retrieving configuration servers SHOULD NOT follow redirects to reduce the risk of Server Side Request Forgery. 1.9. Application User Agents This specification is written primarily for a general purpose web browser as user agent but this is not the only possible implementation choice. On some platforms, some of either or both of the Account Provider and Recovery Provider functionality may be provided as part of a dedicated, platform-native application, AKA an "app". Generally, as the protocol aims to coordinate between authenticated sessions at multiple service providers, the platform standard web browser is the most standardized and convenient mechanism available and should be preferred. 2. Fetching Configuration Fetching Configuration is the process of determining the protocol endpoints and public keys used by Account Providers and Recovery Providers. Service providers may indicate that configuration responses are cacheable and may cache responses but cache lifetimes should be kept reasonably short to enable timely responses to events such as key compromise. Fetching configuration begins by normalizing the service provider to be used into an RFC6454[RFC6454] ASCII serialization of an Origin with an "https" scheme. Retrieval of the configuration is done using an HTTP "GET" request to the provider's configuration endpoint at the following absolute path relative to the https:// Origin. "/.well-known/delegated-account-recovery/configuration" The configuration resource path on the http:// scheme MUST NOT redirect to the https:// protocol, as this may mask configuration mistakes by consumers. Servers MUST return an empty response body and an HTTP status code in the 400 range (401 is recommended) if "/.well-known/delegated-account-recovery/configuration" is accessed with the http:// scheme When fetching configuration, service providers MUST NOT follow redirects that do not use an https:// scheme. Service providers generally should avoid utilizing redirects when returning configuration responses. As it is not mandatory that the issuer field or endpoints in a configuration agree with the origin of the configuration URL, directly returning the canonical data rather than a redirect reduces latency in the protocol. A Recovery Provider MUST return the following information in a JSON dictionary comprising the entire response body: +-------------------------------+-----------------------------------+ | name | value | +-------------------------------+-----------------------------------+ | issuer | the RFC6454 ASCII Serialization | | | of the Origin to which this | | | configuration statement applies. | | | MUST have an https: scheme | | | component. | +-------------------------------+-----------------------------------+ | countersign-pubkeys-secp256r1 | An array of ECDSA public keys on | | | the secp256r1 curve, encoded | | | uncompressed with the named curve | | | OID as per X9.62. The Recovery | | | Provider should not publish more | | | than two keys; enabling key | | | rotation with a small overlap | | | period is the primary purpose of | | | allowing more than one key to be | | | published. | +-------------------------------+-----------------------------------+ | token-max-size | The maximum length, in bytes, of | | | a recovery token that the | | | Recovery Provider will accept. | +-------------------------------+-----------------------------------+ | save-token | URL of the save token API | | | endpoint defined in section 3 | +-------------------------------+-----------------------------------+ | save-token-async-api-iframe | URL of the save async token API | | | resource defined in section 3 | +-------------------------------+-----------------------------------+ | recover-account | URL of the account recovery API | | | endpoint defined in section 3 | +-------------------------------+-----------------------------------+ | privacy-policy | The URL of a data privacy policy | | | that describes how the issuer | | | handles user data related to | | | account recovery. | +-------------------------------+-----------------------------------+ | icon-152px | The URL of a 152x152 pixel PNG | | | file representing the issuer | +-------------------------------+-----------------------------------+ * NOTE: A Recovery Provider may also impose per-account limitations on the total storage or number of recovery tokens it allows. The token-max-size property only sets an upper bound on the length of a single token, and it may still reject tokens below this bound for reasons not discoverable in public configuration. An Account Provider MUST return the following information in a JSON dictionary comprising the entire response body: +-----------------------------+-------------------------------------+ | name | value | +-----------------------------+-------------------------------------+ | issuer | The RFC6454 ASCII Serialization of | | | the Origin to which this | | | configuration statement applies. | | | MUST have an https: scheme | | | component. | +-----------------------------+-------------------------------------+ | tokensign-pubkeys-secp256r1 | An array of ECDSA public keys on | | | the secp256r1 curve, encoded | | | uncompressed with the named curve | | | OID as per X9.62. An Account | | | Provider should not publish more | | | than two keys; enabling key | | | rotation with a small overlap | | | period is the primary purpose of | | | allowing more than one key to be | | | published. | +-----------------------------+-------------------------------------+ | save-token-return | URL of the save token return URL | | | defined in section 3 | +-----------------------------+-------------------------------------+ | recover-account-return | URL of the account recovery | | | callback API endpoint defined in | | | section 3 | +-----------------------------+-------------------------------------+ | privacy-policy | The URL of a data privacy policy | | | that describes how the issuer | | | handles user data related to | | | account recovery. | +-----------------------------+-------------------------------------+ | icon-152px | The URL of a 152x152 pixel PNG file | | | representing the issuer | +-----------------------------+-------------------------------------+ An origin that acts as both an Account and a Recovery provider MUST return a single JSON dictionary as the entire response body containing all required keys. URLs [RFC3986]MUST have a scheme component that is "https", a host component, and optionally, port and path components, and no query or fragment components. Note that no relationship can be assumed between the host component of the "issuer" input and those of of the URLs in the configuration. (e.g. "https://www.messenger.com" might have account recovery endpoints at "https://www.facebook.com") 3. Protocol Endpoints Each phase (establishing, and exercising, an account recovery capability) utilizes three protocol endpoints. (HTTP resources) All protocol endpoints MUST use the https:// scheme, and the protocol endpoint paths at the http:// scheme MUST NOT redirect to the https:// protocol, as this may mask configuration mistakes by clients. A GET or POST to protocol endpoint paths using the http:// scheme MUST yield an empty response body and an HTTP status code 401. When establishing a recovery capability, the following endpoints are used: o "Save Token" at the Recovery Provider is the endpoint to which the Account Provider will instruct the user agent to deliver the Recovery Token. o "Save Token Async IFrame API" is a URL from which an HTML resource supporting an async postMessage API for saving tokens can be loaded. o "Save Token Return" is the endpoint at the Account Provider where the Recovery Provider redirects the user agent after processing an invocation of the "Save Token" endpoint. When exercising a recovery capability, the following endpoints are used: o "Recover Account" at the Recovery Provider is the endpoint at which the User will initiate an account recovery action at an Account Provider. The User may be directed to this resource by the Recovery Provider, or the Account Provider may utilize published configuration to direct the User to this endpoint. o "Recover Account Return" is the endpoint at the Account Provider where the Recovery Provider redirects the user agent with a counter-signed recovery token to complete the recovery of their account Additionally, an Account Provider may optionally provide a "Token Status" endpoint at a well-known location to allow the Recovery Provider to provide direct status updates for tokens, such as the success or failure of saving a token, token deletion, or repudiation of the exercise of a recovery capability. 3.1. Save Token Endpoint "save-token" is used to interact with the Recovery Provider and save a recovery token for later use. The Recovery Provider MUST first authenticate the User. The way in which the Recovery Provider authenticates the User is beyond the scope of this specification. Save Token endpoints which expect to receive invocations by web user agents MUST support the HTTP "POST" method and SHOULD reject the HTTP "GET" method. If navigating from an Account Provider implemented as a native app to a general purpose web browser and POST is not available, the Account Provider SHOULD first navigate the user agent to a resource under its control and use that resource to perform the POST. The POST body MUST be "application/x-www-form-urlencoded" formatted. It MUST contain a parameter "token" containing the recovery token. The POST body MAY contain the additional parameter 'login_hint'. This value may be set to indicate the Account Provider's notion of the primary contact point for the user. A Recovery Provider might match this against the currently logged in user to determine what UI treatments, if any, to apply to confirm saving of the recovery token. The POST body MAY contain the additional parameter 'login_hint_sha256'. This value may be set to indicate the Account Provider's notion of the primary contact point for the user. A Recovery Provider might match this against the currently logged in user to determine what UI treatments, if any, to apply to confirm saving of the recovery token. The value should contain the base64 encoded concatenation of a 256 bit random salt value with the binary output of the SHA-256 hashing algorithm applied to the concatenation of the salt and an octet string representing the ASCII serialization of the primary contact point hint for the user at the Account Provider. Use of 'login_hint_sha256', when compared to 'login_hint', allows matching without disclosure, but introduces the possibility that legitimate matches will not be discovered due to differences in how contact point hints are represented or canonicalized before hashing. The POST body MAY contain an additional parameter 'nickname_hint' to suggest a nickname for the account to which the token relates. The POST body MAY contain an additional parameter 'confirmation'. If set to the value 'required', this indicates to the Recovery Provider that it SHOULD show some form of interstitial explicitly informing the user that a token will be saved, with the option to decline. The POST body type MAY contain an additional parameter, 'obsoletes'. The value of the 'obsoletes' is a token id which the current token is intended to replace. If the user at the Recovery Provider has a saved token with an id and issuer matching this property, it should be deleted or marked as invalid if the new token is successfully saved. The POST body MAY contain an additional parameter 'state', the value of which will be passed to the 'save-token-return' endpoint, unmodified. 3.1.1. Processing Instructions When a user wishes to save a recovery token, the Account Provider takes the following processing steps: 1. Authenticate the User. The exact nature of how the Account Provider authenticates the User is beyond the scope of this specification. 2. Obtain and normalize an origin with an "https" scheme from the user indicating the domain of their chosen Recovery Provider. Users might indicate this choice by picking among pre-configured options, entering a domain name, or it might be inferred from the domain portion of an email address. 3. Retrieve the Recovery Provider configuration as described in Section 2. 4. If necessary configuration cannot be obtained, abort these steps. 5. Prepare a recovery token as described in Section 4. Use the 'issuer' field of the retrieved configuration as the value of the 'audience' field in the token. 6. The Account Provider may save the token_id and audience fields from the token associated with the User's account, to assist the user in completing a recovery process at a future time. 7. The Account Provider should have some method of mapping an issued recovery token to the original public key it was issued under and any key used to encrypt the opaque data, to be able to complete the protocol when the token is returned. This might be maintained as server-side state, or key ids might be encoded into the token_id field. 8. Instruct the user's agent to POST the token to the Save Token endpoint at the Recovery Provider. The Account Provider may choose to do this in a new browsing context. (e.g. a popup) Upon receiving an invocation of the Save Token endpoint the Recovery Provider takes the following processing steps: 1. Authenticate the User. The exact nature of how the Recovery Provider authenticates the User is beyond the scope of this specification. 2. Parse the token. 3. Validate that the version value is 0. 4. Validate that the type value is 0. 5. Retrieve the Account Provider configuration as described in Section 2 using the issuer field of the token as the subject. HTTP redirects SHOULD NOT be followed. 6. Validate that the value of the issuer field of the configuration matches the value of the issuer field of the recovery token. 7. Validate the signature over the token according to processing rules for the algorithm implied by the version. 8. Validate that the audience field of the token identifies an origin which the provider considers itself authoritative for. (Often the audience will be same-origin with the Recovery Provider, but other values may be acceptable, e.g. "https://mail.example.com" and "https://social.example.com" may be acceptable audiences for "https://recovery.example.com".) 9. Validate that the timestamp is fresh within an acceptable clock skew. 10. If a token binding is present or required, validate that it is acceptable. 11. Save the token for the User. The means by which a Recovery Provider saves the token is beyond the scope of this specification. 12. Because recovery tokens do not reveal the account name at the Account Provider, and because a User might have multiple accounts, Recovery Providers may give the User an option to add attach a nickname (e.g. "home", "work") or other means of identifying the account the token is associated with. 13. When the user has completed the operation successfully, or if the user aborted or abandoned the operation, or if the operation cannot be completed due to an unrecoverable error, if the token's "status_requested" field is 1, the Recovery Provider MAY invoke the Token Status endpoint "token-status" for the "save- success" or "save-failure" status, as appropriate, following the processing instructions for that operation described below. 14. Redirect the User or user agent to the "save-token-return" endpoint defined by the Account Provider configuration, including the GET parameter "status" set to the value "save- success" or "save-failure" to report whether a token was successfully saved, regardless of whether asynchronous status updates for the token were requested. 15. If a 'state' parameter was included with the original request, send its value, unmodified, as an additional parameter in the redirect. 3.2. Save Token Return Endpoint Save Token Return is used to return the User to the Account Provider after invoking Save Token at the Recovery Provider. Save Token Return endpoints MUST support both the HTTP "GET" and "POST" methods. Upon receiving an invocation of the Save Token Return endpoint the Recovery Provider may use the "status" parameter to report whether a token was successfully saved, regardless of whether asynchronous status updates for the token were requested. The 'state' parameter may be used, if needed, to determine the next action to be taken. 3.3. Save Token Async API Endpoint In order to facilitate greater control over the user experience for an Account Provider, or to expose advanced features, a Recovery Provider may optionally provide as part of its configuration a save- token-async-api-iframe URL. This URL may be used as the src attribute of an