Use a Privacy Vault as a Compartment Index

A privacy vault should index compartments, not become an identity dossier

As an editorial model—not a requirement stated in RFC 6973—a privacy vault should hold only the fields needed to locate and maintain each compartment, while a complete real-world identity crosswalk and independent recovery material stay outside the central index.

The evidence base is RFC 6973. This page does not attribute its editorial vault model to RFC 6973 or to the Internet Architecture Board. RFC 6973 says pseudonymity is strengthened when less personal data is linked to a pseudonym, the same pseudonym is used less often and across fewer contexts, and independently chosen pseudonyms are more frequently used for new actions. It also explains that persistent identifiers can facilitate correlation over time and that data from one context can be combined with an authenticating context to identify a user.

Those principles support a narrow objective: keep the vault useful without making it the clearest cross-context record. The separation of index fields, identity narratives, and recovery material is an editorial application. RFC 6973 does not prescribe a vault schema, a storage location for excluded material, or a guarantee that moving material makes it safer.

Build compartments before centralizing their index

Define the compartment boundaries and identifiers before choosing or filling a vault, because the index should record an existing separation model rather than decide that model after accounts have already been linked.

RFC 6973 gives the reason for that sequence. Using pseudonyms or no identifiers weakens the link between an individual and communications, while creating new or randomized identifiers periodically reduces cross-interaction correlation. Pseudonymity is also stronger when less personal data is linked and a pseudonym appears in fewer contexts.

Define which context each compartment serves, which identifier belongs to it, and which contexts it must not absorb. Then give the vault a neutral label and maintenance pointers. Reusing one persistent email address, device identifier, certificate, or other identifier across contexts can facilitate correlation over time; a vault entry cannot undo that reuse, only make it visible for review.

Tooling follows the compartment model. Choosing a vault does not decide which identifiers may cross a boundary. Compartmentalization and pseudonymous identifiers covers the underlying definitions.

What the compartment index records

The recommended compartment index records seven maintenance fields: a neutral label, an account locator, a credential-item pointer, a recovery-channel category, a second-factor location pointer, a legacy-link flag, and a last-review date.

This schema is an editorial implementation derived from RFC 6973's correlation principles; the RFC does not require these fields. Each entry should maintain one compartment without explaining a complete identity or every account relationship.

1. Neutral compartment label: distinguish the context without embedding a real name or identity narrative.
2. Service or account locator: record enough to find the account without listing every connected identity.
3. Credential-item pointer: point to the credential record instead of copying its secret into the description.
4. Recovery-channel category: record the kind of recovery path, not its recovery secret.
5. Second-factor location pointer: note where the factor is managed without copying its seed.
6. Legacy-link flag: mark an older identifier or relationship that may cross the intended boundary.
7. Last-review date: show when the entry was checked so stale pointers can be revisited.

These fields answer where to look, what dependency category exists, and what needs review. They do not answer who the person is in every context. A narrative explaining how identities connect belongs outside this minimal index.

What remains outside the central index

Keep the real-name narrative, identity-document archive, full cross-context relationship graph, master recovery material, and separate-factor seeds outside the central compartment index under this editorial model.

The boundary limits concentration; it does not make excluded material safe. RFC 6973 says pseudonymity is strengthened when less personal data is linked to a pseudonym and explains that data from one context can be combined with an authenticating context. An index that names every identity, records every relationship, and contains every recovery path would recreate a cross-context view.

This page does not establish a universal storage location. The limited recommendation is that the central index should not hold both the compartment map and the complete material for interpreting or recovering every compartment. It may point to a category or location while the identity narrative, document archive, master recovery material, and factor secrets remain outside.

Outside does not mean unrecorded, inaccessible, offline, or breach-proof. Placement depends on a separate storage and recovery model.

Shared recovery paths can reconnect separated accounts

A recovery channel or second-factor location reused across compartments can become a cross-context linkage, so the index should expose the category of that dependency without storing the recovery secret itself.

RFC 6973 explains the mechanism: persistent identifiers can facilitate correlation over time, and data from one context can be combined with an authenticating context to identify a user. Applied editorially, a repeated recovery address, identifier, or authentication relationship deserves review because it can connect intended compartments.

Record enough to find the dependency. A recovery-channel category shows the kind of path, a second-factor pointer shows where a factor is managed, and a legacy-link flag marks an older shared identifier. These pointers support review without copying recovery material or a factor seed into the index.

This does not establish that a channel is compromised or one factor arrangement fits every threat model. For passkey credential location, synchronization, biometric processing, and user-verification limits, see Passkeys and Second-Factor Location.

Audit the index for identifiers that cross compartments

Review the index by finding repeated identifiers, flagging cross-context authentication or recovery relationships, retiring stale pointers, and recording the date of the review.

The first two checks apply RFC 6973: pseudonymity is stronger when a pseudonym appears in fewer contexts, persistent identifiers can facilitate correlation, and data from an unauthenticated context can be combined with an authenticating context. The last two checks are editorial maintenance steps, not RFC requirements.

1. Identify repeated identifiers: compare entries for the same pseudonym, account locator, email address, device identifier, certificate, or other persistent identifier.
2. Flag cross-context authentication or recovery: note when one compartment points toward a path that can authenticate another, without storing the secret.
3. Retire stale pointers: update locators and flags that no longer describe maintenance; do not infer that an external record disappeared.
4. Record the review date: distinguish a recently checked entry from one whose dependencies may have changed.

Treat a flagged link as a review prompt, not proof of identification or exposure. The evidence supports possible correlation; it does not show that an observer collected and matched the records. Name the repeated item and its contexts without claiming a stronger outcome.

Limits: this is an architecture reference, not a vault verdict

This page supports a bounded compartment-index model, but it does not establish a required vault schema, validate a product, promise anonymity, or decide where excluded material should be stored.

The evidence scope is RFC 6973's treatment of correlation, identification, pseudonymity, and persistent identifiers. The proposed fields and outside-the-index boundary are editorial applications, not RFC instructions.

• No required schema: RFC 6973 does not prescribe this seven-field vault index.
• No vendor verdict: the evidence does not establish that a named vault prevents linkage, limits breach impact, or fits a threat model.
• No automatic safety from external placement: the page does not establish where excluded material should go or whether another location is safer.
• No anonymity or breach-resistance guarantee: reducing linkage does not establish that every observer is unable to connect or compromise compartments.

A useful index remains intentionally incomplete: it supports maintenance without becoming the authoritative story of every identity and recovery path. That boundary does not mean the omitted relationships ceased to exist.

Frequently asked questions

Related research

• Compartmentalization and pseudonymous identifiersThe definitions and linkage limits that underlie the compartment-index model.
• Passkeys and Second-Factor LocationCredential location, synchronization, biometric processing, and user-verification limits behind the index's second-factor pointer.
• The Household Attack SurfaceExpands the index's identifier and recovery pointers into a source-bounded map of systems, authorities, actors, and limits.
• Lawful Access vs. Public Exposure in BOI and KYCDistinguishes a possible cross-context linkage from evidence that information is publicly displayed, searchable, indexed, or reused.
• Why one email address creates cross-context linkageExplains how a repeated recovery address can connect intended compartments without proving identity or account ownership.
• A finance mailbox that is never an aliasIt applies the repeated-recovery-address review to a bounded finance-mailbox-versus-alias decision.
• TOTP in a separate applicationIt applies the separate-factor boundary to TOTP application location without turning it into a security verdict.
• New signups versus migrationsIt separates new signups from migrations while leaving provider retention and inherited recovery behavior unresolved.