Recover Royal ID

Digital identity recovery presents a fundamental challenge: how do we balance security with the reality that people sometimes lose access to their accounts? The Royal Protocol approaches this challenge through an optional but powerful recovery system that maintains security while providing a path back when custody access is lost.

Core Concept: Recovery as a Design Choice

Think of a Royal ID’s recovery system like designating a trusted emergency contact who can help you regain access to your home if you lose your keys. Just as you might give a spare key to a family member or close friend, Royal ID owners can designate a recovery address that has the specific and limited power to transfer custody of the ID to a new address if access is lost.

This recovery system is:

• Optional: Users choose whether to enable recovery when creating their ID
• Limited: Recovery addresses can only transfer custody, not perform other actions
• Immutable: Recovery addresses can only be set or changed by the custody address
• Two-Party: Recovery requires cooperation between the recovery address and the new custody address

How Recovery Works

The recovery process involves three key players:

1. The Recovery Address: Previously designated by the ID owner
2. The New Custody Address: Where control of the ID will be transferred
3. The Protocol: Which validates and executes the recovery

When recovery is needed, it follows this flow:

1. The recovery address initiates the process by calling recover() or signing a message for recoverFor()
2. The new custody address must also approve the transfer through a signature
3. The protocol verifies both parties have approved and executes the transfer

This two-signature requirement ensures that recovery can’t be executed unilaterally - both the recovery address and the new custody must actively participate in the process.

Implementation Methods

The protocol supports two recovery approaches:

Direct Recovery

function recover(
    uint256 id,
    address to,
    uint256 deadline,
    bytes calldata sig
) external payable

Used when the recovery address directly submits the transaction. They must:

1. Pay the recovery fee in ETH
2. Provide the new custody address
3. Include a signature from the new custody address approving the transfer

Sponsored Recovery

function recoverFor(
    uint256 id,
    address to,
    uint256 recoveryDeadline,
    bytes calldata recoverySig,
    uint256 toDeadline,
    bytes calldata toSig
) external payable

Enables third-party submission of the recovery transaction. Requires:

1. A signature from the recovery address
2. A signature from the new custody address
3. Payment of the recovery fee

Both methods achieve the same result but offer flexibility in who submits and pays for the transaction.

Best Practices for Recovery

Setting Up Recovery

1. Choose a recovery address that is:
   • Highly secure
   • Controlled by a trusted party
   • Likely to remain accessible long-term
2. Document recovery information securely:
   • Store recovery address details safely
   • Record the process for initiating recovery
   • Keep instructions for proving identity to recovery address holder

Recovery Address Selection

Consider these options for recovery addresses:

• Hardware wallet in secure storage
• Multi-signature wallet
• Professional custody service
• Trusted family member or advisor’s address
• Corporate security team’s wallet

Managing Recovery Changes

When changing recovery addresses:

1. Ensure the new recovery address is fully set up first
2. Use the changeRecovery() function from the custody address
3. Verify the change through recoveryOf()
4. Update all documented recovery information

Technical Implementation

The recovery system is implemented through a series of smart contract functions that enforce these security properties:

// In IdGateway.sol
function recover(uint256 id, address to, uint256 deadline, bytes calldata sig) {
    // Verify caller is recovery address
    if (idRegistry.recoveryOf(id) != msg.sender) revert OnlyRecovery();

    // Verify new custody address signed acceptance
    _verifyRecoverSig({id: id, to: to, deadline: deadline, sig: sig});

    // Execute recovery through registry
    idRegistry.recover(id, to);
}

Key security checks include:

• Validation of recovery address authorization
• Verification of signatures and deadlines
• Atomic execution of custody transfer

Error Handling and Edge Cases

The recovery system handles several important edge cases:

1. No Recovery Address. If an ID was created without a recovery address (or the recovery address was cleared), recovery is impossible. This is by design - you cannot recover an ID that wasn’t set up for recovery.
2. Invalid Recovery Address. If the recovery address is no longer valid (e.g., an EOA whose private key is no longer available), the ID may become unrecoverable. This emphasizes the importance of careful recovery address selection.
3. Signature Timing. Recovery signatures have deadlines to prevent replay attacks. If signatures expire before submission, new signatures must be obtained.