Pluggable Backup Services for BRC-140 Share Vaults

Abstract

This BRC defines an HTTP backup service profile for optional recovery of BRC-140 key shares. A backup service stores at most one BRC-140 share per authenticated account and releases it only after authentication. Wallets may enroll a list of independent service URLs, deposit distinct shares across them under a threshold scheme, and reconstruct the key locally after obtaining enough shares.

A backup service MUST NOT be required for ordinary wallet operation under BRC-100. It MUST NOT receive the root private key, and a conforming wallet MUST NOT send enough shares to any single service to meet the wallet’s recovery threshold.

Motivation

BRC-140 specifies threshold key sharing and the canonical share serialization. It does not define how optional network providers store and release those shares. Without a shared service profile, wallets invent incompatible recovery APIs and users concentrate recovery on a single operator.

This BRC specifies a minimal, pluggable wire contract so any operator can run a share vault and any wallet can enroll multiple providers interchangeably. Cryptography remains BRC-140; this document covers discovery metadata, authentication for release, share endpoints, and operator lifecycle signaling.

Specification

Terminology

Relationship to other BRCs

Non-goals

• Threshold signatures or spend-time co-signing.
• Requiring backup services for send, receive, or BRC-100 connect.
• A global registry of providers.
• Wallet UTXO / history synchronization.
• Mandating a particular identity or KYC regime.

Cryptographic model

1. The wallet splits its root private key with BRC-140.
2. The wallet deposits at most one share per backup service.
3. Reconstruction happens only in the wallet after enough shares are obtained.
4. Services MUST NEVER receive the reconstructed key.

Invariant (service): store at most one share per authenticated account; reject non-BRC-140 share strings.

Invariant (wallet): MUST NOT send the root private key, mnemonic, or ≥ threshold shares from one split to any single backup service.

A common enrollment scheme is threshold 2 of 3 total shares. Other thresholds are permitted if the wallet and user agree on the scheme before deposit.

Account binding

The bearer session returned by authentication MUST be bound to a provider-local account. Share endpoints operate on that authenticated account and MUST NOT accept a caller-supplied email, handle, public key, or account hash to select another account's share.

The provider MAY use any internal account identifier. That identifier is not part of this wire profile and MUST NOT be treated as an anonymity mechanism: a provider can associate the stored share with the identity presented during authentication.

HTTP profile

Base URL is an HTTPS origin (loopback HTTP MAY be used for development). Paths are relative to that origin. JSON UTF-8 bodies. Unknown JSON fields MUST be ignored.

GET /info

No auth required.

{
  "name": "Example Backup",
  "version": "0.1.0",
  "role": "backup-service",
  "authMethods": ["com.example.connect", "webauthn", "email-otp"],
  "lifecycle": {
    "status": "active",
    "sunsetAt": null,
    "retireAt": null,
    "message": null,
    "successorUrl": null
  }
}

Lifecycle

Wallets SHOULD refresh /info for enrolled URLs and stop new enrolls when status is not active. Operators SHOULD provide a sunset window before retireAt.

Authentication

Authentication is capability-negotiated. This BRC defines a common start/complete envelope but does not mandate a specific identity provider or factor.

authMethods contains identifiers for authentication profiles understood by the service. Provider-specific identifiers SHOULD use reverse-domain form (for example com.example.connect). Existing standardized identifiers such as webauthn MAY be used directly. Email OTP, redirect-based Connect providers, passkeys, and challenge-response systems are all possible profiles; none is required by this BRC. Wallets MUST ignore methods they do not implement.

An authentication method used for recovery MUST remain usable without possession of the secret being recovered. A signature key derived only from the BRC-140-protected root key MUST NOT be the sole recovery method, because that creates a circular dependency. Redirect or challenge methods are conforming only when their credential can be recovered independently.

POST /auth/start

{
  "method": "com.example.connect",
  "params": {}
}

Response (200):

{
  "requestId": "<opaque>",
  "expiresInSec": 600,
  "action": {
    "type": "redirect",
    "url": "https://identity.example/authorize?request=<opaque>"
  }
}

params and action are method-specific objects. Defined action.type values are:

• redirect — open action.url; the authorization result is supplied to /auth/complete.
• challenge — produce a proof over action.challenge.
• outOfBand — complete the externally delivered challenge (such as an OTP).

Unknown action fields MUST be ignored.

POST /auth/complete

{
  "requestId": "<opaque>",
  "response": {}
}

Response (200):

{
  "token": "<bearer secret>",
  "expiresInSec": 1800
}

response is method-specific. The service MUST validate that it completes the referenced request and MUST bind the returned bearer token to the authenticated provider-local account.

Share endpoints use Authorization: Bearer <token>. Tokens SHOULD be short-lived and scoped to backup-service operations.

Share endpoints

All share endpoints require a valid bearer session.

{
  "share": "<BRC-140 backup string>"
}

(share only where noted.)

POST /share/enroll

• MUST validate share as BRC-140 backup serialization.
• MUST fail with 403 when lifecycle forbids enroll.
• Stores exactly one share for the authenticated account (overwrite policy is operator-defined; /share/rotate SHOULD be preferred for explicit replacement).

Response (200):

{ "ok": true, "enrolledAt": "<RFC 3339>" }

POST /share/retrieve

Request: {}.

Response (200):

{ "share": "<BRC-140 backup string>", "enrolledAt": "<RFC 3339>" }

• MUST NOT return a share without successful auth under the service’s policy.
• MUST fail when lifecycle is retired or past retireAt.
• MUST 404 when no share is stored.

POST /share/rotate (SHOULD)

Replace the stored share after auth. Same validation as enroll.

POST /share/delete

Request: {}. Idempotent; response { "ok": true }.

Wallet requirements

1. Support a list of backup-service base URLs; an empty list MUST be valid.
2. Ordinary spend / BRC-100 use MUST NOT depend on any backup service.
3. Deposit at most one share from a given split to a given service origin.
4. Reconstruct only locally.
5. Keep offline BRC-140 and/or BRC-75 recovery available without services.

Security considerations

Protect share transport with TLS. Minimize logging of share material. Encrypt shares at rest under an operator key that is not the user’s root key.

Implementations

HandCash Desktop and its backup-service prototype implement multi-provider BRC-140 share storage on branch feat/backup-services. The prototype's original email-OTP exchange predates the capability-negotiated authentication envelope in this draft and is not presented as a complete conforming implementation.

References

• <a name="footnote-1">1</a>: BRC-140 — Threshold Key Sharing and Backup via Shamir's Secret Sharing Scheme
• <a name="footnote-2">2</a>: BRC-100 — Unified Wallet-to-Application Interface
• <a name="footnote-3">3</a>: https://github.com/HandCash/HANDCASH-DESKTOP (branch feat/backup-services)