Improved privacy, social recovery for apps, no need for contexts


This is a simplification of ideas from Private contexts through blind signatures and social recovery of any application.

The main recommendations are as follows.

  1. Limit the number of identifiers per application (formerly contextid) to one per person.
  2. Use BrightID to facilitate Shamir’s Secret Sharing for social recovery for any application.
  3. Deprecate contexts. If the user would like to link their accounts in different applications (which is how we saw “contexts” being used), or link profile information or credentials, we recommend using Decentralized Identifiers (DIDs) managed by an identity wallet. It’s no longer the scope of BrightID to manage mappings of identifiers.
  4. The mapping between BrightIDs and contextIds on nodes is deprecated: linking and sponsoring can both be achieved without any mapping on nodes using blind signatures.

Linking accounts

A user selects a single account (identifier) for use with an application. To make this practical, we want to encourage the use of social recovery for all application accounts.

If accounts need to be linked within an application or across two applications, this is can be managed in applications or with DIDs and is out of the scope of BrightID.

Replacing contextIds with blind signatures

BrightID nodes will have no concept of a contextID; just a single identifier per user per application will be allowed, and BrightID nodes will not know what it is because of the use of blind signatures.

Process overview

A user commits to a single identifier (for example, an account id) for an application, blinds it, and submits the blinded message as a (signed) operation to the BrightID network along with the plaintext unique application name. Each node signs the message + application name[1] and records that the user has registered an identifier for the application. Because the message was blinded, nodes don’t know which identifier the user chose.

The user unblinds the signed message and shares it with the application. The identifier to which the user committed is then permanently linked to them as a unique human user of the application.

Limit to one identifier per person

BrightID nodes will refuse to sign more than one blind link per user per application. If a user wants to link their own accounts to each other (within or across apps), it needs to be handled outside of the BrightID architecture.


To allow uniqueness credentials to expire, applications can require users to append a unique epoch id–that can’t be guessed ahead of time–to the unique application name accompanying the blinded messages. For example, “RabbitHole-wFLe1” could be the application name in a user’s first presentation of a signed message. A month later, after the next epoch starts, they may be required to obtain another signed message with the application name “RabbitHole-OftLG” and so forth.

Sponsoring using blind signatures

BrightID nodes don’t need to know about application identifiers (account ids or context ids) to allow sponsoring. Instead, we can use blind signatures.

A user that has performed whatever steps an application requires for sponsorship can present a blinded message containing their BrightID to the application. The application signs the message with their sponsorship private key. The user then unblinds the message and submits the sponsorship operation to the BrightID network. All BrightID nodes will have the application’s sponsorship public key.

Social recovery for any application

Limiting the user of an application to one account identifier becomes more tenable if there’s an easy and robust solution for account recovery. BrightID’s social recovery can serve this purpose.


The secret

The secret should be the private key of a key pair. The user can share the public key with an application to associate it with an account they would like to be able to recover in the future. For applications that allow decentralized accounts represented as DIDs, a user can add the public key as a controller to a DID document to allow the user to update the DID document via social recovery in cases of malicious activity or key loss.

The secret can be destroyed after the encrypted shares are published to prevent it from being stolen; it won’t be needed until social recovery is used.

Generating and publishing shares

When a users selects recovery connections or changes their selection, they can generate and publish shares of the secret (see Shamir’s Secret Sharing), with each share encrypted with the target connection’s public key (every BrightID user has a signing key pair), choosing whatever threshold they prefer (the m value in an m of n signature scheme). They should be published somewhere easily retrieved by the user’s connections in the future, such as ceramic. (Privacy isn’t important since the shares are encrypted.)


To recover the secret (and therefore any accounts or DIDs associated with it), the user’s recovery connections each retrieve their share from the public location, unencrypt it, and reencrypt it with the public portion of the user’s new signing key. They then send the reencrypted shares to the user who can combine them to recover the secret. This can easily be combined with the existing BrightID recovery flow.

Passwordless encryption of profile data

The public key related to the secret could be used to encrypt the profile data a user has collected for their connections. This way a user could recover that data at social recovery time without needing a password or other authentication.

End notes


Perhaps not all nodes are eligible to sign a particular message. Perhaps only m of n signatures of eligible nodes are needed. (See Threshold Blind Signatures, for example.)