Device and Member Enrollment

ClearDNS needs to solve a problem that account systems normally hide behind "send an invitation to this email address." A ClearDNS policy may contain multiple devices and multiple member scopes, but those relationships are created without requiring every participant to register an account.

ClearDNS therefore treats enrollment as a controlled transfer of permission to create a new binding.

Two different enrollment intents#

Add another device#

A new device is attached to an existing member scope.

Add another member#

A new member scope is created under the policy, with its own device relationship and the permissions allowed by the invitation.

Those are different operations even when the user experience is presented through a QR code or link.

Invitation as a possession capability#

An invitation is a temporary possession capability. The server generates the invitation using a cryptographically secure random source rather than trusting a client-supplied identifier.

A production invitation is:

• difficult to guess;
• time-bounded;
• constrained to its enrollment intent;
• permission-checked when created;
• single-use once accepted; and
• revocable through the policy's normal device/member controls after enrollment.

The raw invitation value is sensitive while it is valid.

Why invitations expire#

A shareable link can be copied through messaging, QR scanning, clipboard history or screenshots. A permanent invitation would unnecessarily extend that exposure. ClearDNS therefore gives invitations a finite acceptance window; after it closes, a new invitation is required. Expired pending invitations are also cleaned up so they cannot linger as latent capabilities.

Single-use acceptance#

Successful acceptance changes the invitation from a pending capability into a concrete policy/member/device relationship. The same invitation is not intended to keep minting unrelated device identities after successful use. An enrollment link is a bootstrap mechanism, not a permanent master credential.

Exact binding before resolver artifacts#

ClearDNS separates two events:

1. deciding which policy/member/device tuple is being enrolled; and
2. issuing the platform-specific resolver configuration for that tuple.

Resolver-bearing artifacts do not become authoritative merely because an earlier database insertion was attempted. The enrollment flow verifies that the exact intended binding exists in authoritative state before issuing the corresponding resolver/profile artifact. That helps the system converge safely across retries and partial failures.

Retry-safe enrollment#

Enrollment often occurs on mobile networks, embedded browsers and OS configuration flows where a request can be repeated or interrupted. A robust invitation flow therefore tolerates:

• a response being lost after part of an operation completed;
• the client retrying;
• two requests racing;
• a device record being created before a later step;
• a configuration download being retried.

The desired result is not "create a different identity every time." The desired result is convergence on the one authoritative tuple claimed by the successful enrollment. The public contract is the outcome: retries do not turn one legitimate invitation into uncontrolled duplicate identities.

Platform recognition and artifact issuance#

Different platforms need different configuration artifacts. ClearDNS keeps the identity relationship separate from the platform representation.

An enrollment path therefore:

1. establishes the policy/member/device relationship;
2. establishes the relevant platform class from evidence the server can verify;
3. verifies that the persisted binding and device state agree;
4. issues the configuration appropriate to that platform.

This prevents a profile-bearing response from being treated as authority when the underlying tuple is missing or inconsistent.

Browser enrollment#

A browser can itself be represented as a separately controlled binding where the product requires it. Browser enrollment has additional lifetime and acceptance semantics because a browser may initially be attached through an invitation before it becomes a durable accepted relationship. ClearDNS handles that as binding state rather than creating a conventional browser account.

Device removal#

Removing or disabling a device is an authority change. A device configuration that still contains an old resolver credential does not by itself force the backend to keep the binding active forever. Resolver processing consults current authoritative binding/policy state and stops granting normal service to a binding that has been disabled or invalidated.

Recovery is not the same as enrollment#

ClearDNS has several sensitive artifacts:

• the internal identity tuple;
• resolver configuration artifacts;
• temporary enrollment capabilities;
• artifact-recovery capabilities; and
• browser sessions.

They are not interchangeable. A recovery flow must prove the specific authority required to recover an artifact rather than accepting "I know the Policy ID." This is also why sensitive resolver artifacts are stored in platform secure storage when an app needs to retain them.

First-run Security PIN#

Security PIN establishment is part of first-run activation and provides the baseline credential for ongoing Dashboard administration.

If the member does not yet have a Security PIN, first-run activation establishes one and generates a PIN Recovery Code set. If the member already has a Security PIN, the new binding uses the member's current Dashboard security requirement, PIN by default or MFA when enabled.

The Security PIN belongs to the member within the policy, while the first-run security step is completed independently by each device binding. This gives one member one Security PIN and one PIN Recovery Code set across that member's devices without allowing a new device to skip the mandatory first-run step.

Family sharing without an account directory#

The result is a family/team model in which the policy can know which member scopes exist, which devices belong to each member, which roles are authorized, and which devices are active, without requiring an email-address directory as the identity layer.

Security summary#

Related technical references#

• Identity and Resolver Credentials
• Accountless Dashboard Authentication
• Security Model