Recovery

Full Title or Meme

The problem of giving and maintaining a continuing identifier for a real-world person on a digital network.

Context

The collection of User Private Information by a Data Controller now necessitates the ability Authenticate the User under a wide range of challenges, like:

1. Simplest of all the User needs to Authenticate from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and Alternate Authentication factors are lost or fail.
2. More severe Recovery problems occur when the User has lost control of their account and needs it to be reset. The level of Authentication for these situation can be severely taxing to a user desperate for access to their accounts.
3. When an Authentication factor like an alternate email or phone number is compromised, insecure Recovery methods themselves become a means of attack, especially since factors like phone number were never intended to be secure.

• Shane Weeden, IBM Account Recovery is just another Authentication Method

Problems

• Before the user can request a list of data that is held about them, or Redress for mistakes made by a Data Controller they must Authenticate themselves to the data controller to assure that the Recovery process itself does not leak data.
• Before any Data Controller can report to the user about leakage of User Private Information, they just have good contact information for the User.
• Before any Data Controller can allow access methods or factors to be changed on an account, they must be assured that this is not an attack.
• Recovery is a fertile place for attackers to take over user's accounts, particularly when a low security second factor, like SMS, is used for recovery.
• If the account the attacker subverts is an OpenID Provider (OP or IAP), the attacker can then move onto any Open ID Clients (RPs) that subscribe to that OP.
• Many Recovery Use Cases are unpleasant for the user. Following that link will bring you to a list of one dystopian and one eutopian possible uses cases.

Solutions

• As a part of creating a User Object to hold User Information any Site needs to first of all assure that they can contact the user.
• The two most common contact methods are email address and Smart Phone numbers. But such contact itself can become the vector for attack so any contact email must be recognizable and protected against spoofing by attackers.
• The downside to giving untrustworthy sites yet another means to reach out to users to capture their attention continues to occur

Proposed for Standardization

This proposal assumes that the user has continuing needs to use their identifiers to access their personal resources, even as the authentication factors become obsolete or are lost. Recovery in this sense means key rotation as well. More description can be found in this description of [Did Recovery] or this for [Regeneration]. The following are some of the known ways that loss of use of an authentication factor can occur:

1. The device holding the authentication factor is lost.
2. The algorithm or key strength is declared obsolete or unable to continue to protect the user's authentication factors.
3. A key has become compromised or is otherwise no longer usable.
4. The user wishes to enable more than one authenticator to access their resources.
5. The identifier method has become obsolete or no longer supported.

For these or any other reason the user needs to enable a different key and bind that key to their resources. Recovery of access uses the same process as identity theft which makes it similar to sim swapping to gain access to a user's phone number, which is often used in identify proofing. This document is designed to provide secure means for that recovery without increasing the risk of identity theft.

Note that recovery of the user access, which is the topic of this specification, may also be a part of a larger process that includes the recovery of user data.

1. Key is stored in a (e.g.) pfx file that is encrypted to a user secret.
2. Key is contained in a removable data store and can be restored if the user is authenticated.
3. Key could be shared between multiple user devices and any one could back up the other. (Android already enables this.)
4. A Seed can be used to create the key see examples in: [Emtrust], [SeedQuest] and [DCM],
5. WebAuthn dual PRF function that takes two salts are returns two keys, use that with 2FA to get decryption key for user secret.
6. OpenID Moderna Account forward spec OpenID Connect Account Porting https://openid.net/specs/openid-connect-account-porting-1_0.html also requires a trusted server.
7. Include the WebAuthn credentialID in the did document as part of bootstrapping info. Only the person with the authenticator would be able to decrypt the user secrets into the wallet. (John Bradley)
8. A collection of pictures (or phrases) could be presented to the user until the key data was fully recovered. (No small number of matches would suffice.) One example is [Fuzzy Vault]. Another is Account Recovery with Expanded Password System [Regeneration].
9. A set of biometric data can be used to grant access as described in [Horcrux].
10. A new key could be generated and bound to the user's ID. This would require assistance from a trusted server as well as some helper authentication factors.

The following helper functions can be used to enable recovery when a trusted server approach is chosen.

1. A FIDO / Web AuthN key is created on a key fob that can be used to initialize the user's identity on any device.
2. A QR could be used to provide the secret information to unlock the user's secrets.

Recovery can aslo be enabled by providing the user with a method to "roll-over" or recreate the key on the device.

1. In KERI the keys are "pre-rolled" in the sense that one or more alternative key an listed in the user ID document that can be angled as desired.