Roles

The DeRec protocol defines three roles: Owner, Helper, and Replica. The first two are present in every deployment; Replica is used when an Owner identity is backed up across more than one device. All three are logical responsibilities defined by the protocol — an implementation may deploy them in separate systems or within a single codebase, but their responsibilities and trust boundaries remain distinct.

Owner

The Owner is the entity that protects and recovers a Secret. The Owner orchestrates all protocol flows and is the only role that ever reconstructs the encryption key.

Responsibilities

The Owner is responsible for:

• Generating or managing the Secret to be protected

• Splitting the Secret into cryptographic shares using a threshold scheme

• Pairing with Helpers

• Establishing secure pairing sessions with Helpers

• Distributing shares to Helpers

• Initiating verification and recovery flows

• Reconstructing the Secret from recovered shares once the threshold is met

• The Owner controls the configuration of:

  • Number of Helpers (n)

  • Recovery threshold (t)

  • Helper set membership

Security Boundary

The Owner environment is assumed to be trusted during:

• Secret creation

• Key generation

• Share generation

Recovery and reconstruction

If Owner's environment is compromised during recovery, the confidentiality of the Secret cannot be guaranteed. The protocol does not attempt to protect against a compromised Owner.

Helper

A Helper is an independent entity that stores one share for a given secret version of the encryption key on behalf of the Owner. A Helper participates in protocol flows but never reconstructs the Secret or the full encryption key.

Responsibilities

A Helper is responsible for:

• Establishing secure communication with the Owner

• Receiving and storing a key share

• Enforcing protocol-defined validation rules

• Participating in verification flows

• Returning its stored share during a valid recovery session

• A Helper must not

  • Attempt to derive the encryption key from a single share

  • Store or request the plaintext Secret

Independence Requirement

Security relies on Helper independence. The protocol assumes that fewer than the threshold number of Helpers collude. If t or more Helpers collude and combine shares, reconstruction of the encryption key becomes possible.

Additionally, helpers are not required to know anything about the Helper Set. This means that Helpers can participate in the protocol without being aware of how many helpers (n) exist in the Helper Set nor how many Shares (t) are required to reconstruct the Encryption Key.

Replica

A Replica is another device under the same Owner identity, used to keep the Secret synchronized across more than one device. The full conceptual treatment lives in the Replicas section; this entry summarizes the role's responsibilities and trust boundary.

Replica devices share the Owner's trust boundary: they hold the full Secret, including the per-Helper shared keys and the replica-group shared key.

Responsibilities

A Replica is responsible for:

• Pairing with one or more other Replicas under the same Owner identity

• Keeping its local Secret in sync with the rest of the Owner identity's devices

• Acting toward Helpers on the same footing as the Owner — once synced, every Replica can drive any flow the Owner can drive

Trust Boundary

Everything in the Owner trust model applies to every Replica. A compromised Replica is equivalent to a compromised Owner — the protocol does not attempt to protect against it.

The wire-level distinction between the device that pushes Secret updates and the device that receives them, the replica_id identifier, and the conflict surface that arises when more than one Replica acts toward Helpers concurrently are covered in the Replicas section.

Role Interaction

The protocol defines structured interactions between Owner and Helpers. These include:

• Pairing or session establishment

• Share distribution

• Share verification

• Recovery requests

All interactions are performed using defined message schemas and protocol validation rules. Ad hoc communication outside protocol-defined flows is not considered valid participation.

These interactions correspond to the protocol flows defined in the Flows section.

Logical vs Physical Deployment

Roles are defined at the protocol level. In practice:

• A mobile wallet may implement the Owner role.

• A cloud service may implement the Helper role.

• An organization may operate multiple Helpers.

• A user backing the same identity across a phone and a laptop runs the Owner role on each device, with the two devices paired to each other as Replicas.

• A single vendor may implement both roles in separate services.

  The protocol enforces logical separation of responsibilities even if roles are implemented within the same organization.

Summary of Capabilities

Role	Can Access	Cannot Do
Owner	Full Secret lifecycle	Recover without threshold shares
Helper	One key share	Reconstruct the Secret independently
Replica	Full Secret under the same Owner identity (synced state)	Recover without threshold shares

The protocol’s security guarantees depend on maintaining these role boundaries and enforcing threshold-based reconstruction. The Replica role is documented in depth in the Replicas section.