Catalog.ID: A Privacy‑Preserving Identity and Claim Verification Framework

Last updated: 2026-05-08
Author: Roberto Bourgonjen
Copyright: © 2026 Roberto Bourgonjen. All rights reserved.

Abstract

Catalog.ID is a federated, privacy‑centric identity system that enables individuals to manage, share, and validate personal information (“claims”) without revealing this information to any server. The system is operated by a network of independent Operators — foundations and licensed corporations — each running a full Catalog.ID node under an opaque Operator ID (e.g., b4np.catalog.id). By combining end‑to‑end encryption, user‑controlled key management, cryptographic attestations, a physically separated Validator Black Box per node, and cross‑node identity synchronization, the system provides strong guarantees of data confidentiality, authenticity, sovereignty, and operational resilience. This whitepaper outlines the user model, technical architecture, trust relationships, privacy model, federation model, and validation mechanisms underpinning Catalog.ID.

1. Introduction

Modern digital identity systems routinely aggregate, correlate, and expose personal data far beyond what is necessary for authentication or service access. Catalog.ID challenges this model by providing a high‑integrity identity layer that prioritizes privacy and user agency.

A Catalog.ID identity consists of:

• A compact, unique username (e.g., khu3758iop).
• A randomly generated password.
• A client‑generated public/private key pair.

Users attach personal claims—such as email, address, telephone, or preferred attributes—while maintaining cryptographic ownership and control over them. Catalog.ID stores only encrypted claims and can never access or decrypt them.

Catalog.ID enables privacy‑preserving login, decentralized trust formation, secure data sharing, and formally verifiable claim validation.

Catalog.ID is one module of Catalog, an integrated suite of applications for creatives and other intellectual-property producers — operating alongside Asset Registry (provenance and claims registry), Bitcash (payments), mail, chat, metadata management, digital rights management, and file storage and delivery — but it can also be used on its own. Catalog was created by Roberto Bourgonjen, who brings over twenty years of professional experience as an application developer for major institutional archives in the Netherlands, including the Municipality of Amsterdam's Archive Bank and WatWasWaar, a geographic search system for historical data across all Dutch archives. Catalog was engineered from the ground up — after his retirement from business, as a private undertaking — for massive, global scale, built on archival practice proven at national scale, while its usability and feature set were shaped around the founder's own needs as an active photographer, musician, and software developer managing a lifetime of work.

2. System Overview

Catalog.ID consists of three interacting components:

1. Client Application (Browser)

   • Generates identity keys and encrypts all claims locally.
   • Manages claim sharing and decryption.
   • Validates signatures from trusted users and validators.

2. Catalog.ID Node (Core Server)

   • Operated by an independent Operator (foundation or licensed corporation) under an opaque Operator ID (e.g., b4np.catalog.id).
   • Stores encrypted claims and, optionally, member‑published public claims (§4.5).
   • Maintains user accounts and permission structures.
   • Receives and stores validation certificates.
   • Synchronizes identity records with peer nodes so that every node holds a complete replica of all accounts across the network (§15).
   • Never has access to plaintext private claim data. Public claims are stored in cleartext by the member's explicit choice.

3. Validator Black Box

   • A physically and logically isolated verification service.
   • Decrypts claims only when users explicitly request validation.
   • Executes validation flows (email/SMS/postal/bank/domain).
   • Issues cryptographically signed attestations to Catalog.ID.

This separation ensures that no single component (including any core server) can compromise user data. The network of nodes provides operational resilience — no single Operator failure can disrupt the system.

The system supports four kinds of identity: personal identities for natural persons, organization identities for entities such as studios, labels, and foundations, delegate identities for natural persons acting in the capacity of an organization, and agent identities for autonomous or semi‑autonomous entities — AI systems, automation scripts, or human operators — acting on behalf of a personal or delegate identity. Personal, organization, and delegate identities share the same cryptographic architecture — key bags, claims, sharing, and validation — and the same credential model: each has its own username, password, supersecret, and key bag. They differ in username format, lifecycle control, and legal framework. Agent identities share the username and identity table infrastructure and have their own public keys (attr_encrypt, msg_encrypt, Asset Registry signing key) registered on their account — making them structurally identical to other identity types for claim operations, sharing, and messaging — but have no independent key custody: all private keys are generated by and stored in the principal's key bag (the personal or delegate identity that created them). Personal identities are network members; organization identities are administered by the person or persons who hold the organization's credentials, with daily operational access distributed to delegate identities through wrapped key copies; delegate identities are created by organizations for their employees; agent identities are created by personal or delegate identities for their autonomous agents. See §3 for personal identities, §3a for organization identities, §3b for delegate identities, and §3c for agent identities.

3. Identity Model

A Catalog.ID identity is generated within the user’s browser, with the exception of the username, which is assigned by the Catalog.ID service:

• Username: A 10‑character alphanumeric string in the format abc1234efg, deterministically encoded from an internal sequence number. The namespace comprises 26⁶ × 10⁴ ≈ 3.09 trillion possible identifiers. The encoding is a compact bijection from integer to string — the member does not choose the username.
• Password: A locally generated 12‑character Base64 secret, used with the username to authenticate to the service. The password can be stored in the browser’s built‑in password manager. It provides access to basic account functions and — crucially — to the PIN‑based key exchange endpoint that returns the deviceEncryptionKey (§3.4.5). The password alone does not grant access to any private key material.
• Supersecret: A locally generated credential in the extended format defined in the Recovery Kit Addendum §2.5: four lines of twelve characters (11 random + 1 per‑line checksum), drawn from the non‑confusing base57 alphabet ([a–z A–Z 2–9] excluding i, l, O), providing ~256 bits of entropy. Used to encrypt the member’s key bag for backup and cross‑device restore. The supersecret is strictly separate from the login password — it is never sent to the server and is never stored in a browser password manager.
• Key Bag: A set of independently generated cryptographic key pairs, each serving a distinct purpose (§3.4). Each private key is encrypted individually with the same supersecret‑derived AES‑256‑GCM key and stored as a separate entry on the server. The key bag is the logical collection of these entries — not a single encrypted blob.

Authentication is layered:

1. Username + password — authenticates the session. Grants access to basic account operations (viewing public profiles, managing account settings) and to the PIN exchange endpoint.
2. PIN (per device) — exchanges for the deviceEncryptionKey via the authenticated session. Unlocks the private keys stored in this browser’s localStorage (§3.4.5).
3. Supersecret — decrypts the full key bag from the server. Required for first‑time device setup, adding keys to a device, and PIN changes (§3.4.4).

The server never receives any private key in plaintext. All trust begins with the user’s local cryptographic anchor.

3.1 Username Ownership and Nature

3.1.1 The Developer and the namespace

"The Developer" throughout this whitepaper refers to Roberto Bourgonjen, the natural person who designed and created the Catalog.ID system, including the username namespace.

A Catalog.ID username is a service identifier whose namespace is the intellectual property of the Developer. The namespace — the set of all possible Catalog.ID usernames, the format in which they are expressed, and the algorithm that generates them — is a creative work authored by the Developer.

3.1.2 The namespace as a creative work

Catalog.ID usernames are not arbitrary strings or bare sequence numbers. Each username is produced by a deterministic encoding algorithm that maps an internal sequence number to a 10-character string in the format abc1234efg (three lowercase letters, four digits, three lowercase letters). The Developer designed this encoding — the character-class pattern, the interleaving of alphabetic and numeric segments, the bijective mapping, and the namespace size of 26⁶ × 10⁴ ≈ 3.09 trillion identifiers — as a unified creative work.

The design choices are expressive, not dictated by function:

• The specific interleaved format was chosen for human readability, visual distinctiveness, and instant recognizability as a Catalog.ID.
• Countless alternative encodings (hex strings, UUIDs, sequential integers, pronounceable tokens, etc.) would serve the same functional purpose; the Developer selected this particular design.
• The encoding algorithm itself is original software authored by the Developer.

3.1.3 Intellectual property basis

The Developer’s intellectual property in the namespace rests on multiple, overlapping legal bases:

1. Copyright (Berne Convention, EU Directive 2001/29/EC): The encoding algorithm is original software. The namespace format — the [a-z]{3}\d{4}[a-z]{3} pattern and its mapping rules — is a creative design choice that meets the originality threshold for copyright protection.
2. Database right (EU Directive 96/9/EC, sui generis right): The complete namespace mapping constitutes a database produced through substantial investment in design, implementation, and verification. The sui generis right protects against unauthorized extraction or reutilization of a substantial part of the namespace.
3. Contractual protection: The Catalog.ID Membership Agreement establishes that usernames are Developer property licensed through the Operator to the member. This contractual layer is enforceable regardless of which statutory IP rights apply in a given jurisdiction.

3.1.4 Licensing chain

The namespace is licensed in a two-step chain:

1. Developer → Operator: The Developer licenses the namespace to each Operator (currently Stichting Outpapier) under the terms of the operator license agreement.
2. Operator → Member: The Operator sublicenses individual usernames to members for the duration of their membership, subject to the Catalog.ID Membership Agreement.

The member does not own the username; they hold a sublicense to use it. After account termination, the username is permanently retired — it is never reassigned to another member. This is analogous to a telephone number assigned by a telecommunications carrier: the carrier (and ultimately the numbering authority) owns the number; the subscriber holds a right to use it.

3.1.5 Relevance to data protection

This distinction is material for data protection purposes (see §9a). The username itself is infrastructure — an element of the Developer’s namespace, operated by the Operator. The association between a username and a natural person is a separate datum that exists only within the encrypted Catalog.ID identity layer and under the member’s own control. The infrastructure-ownership framing does not alter the data protection classification: when the username is identifying (whether through public claims or external disclosure), it is personal data for the purposes of any system that processes it alongside the resolution path (see §9a.2).

3.2 Key Custody and Loss

The private key is generated in the user’s browser and never transmitted to the server. This is a foundational security guarantee: no server compromise, rogue Operator, or court order can extract a member’s private key, because the server does not possess it.

The consequence is that key loss without a backup is irrecoverable by design. If a member loses their private key and has no backup:

• They cannot decrypt their own encrypted claims.
• They cannot share claims with new recipients.
• They cannot sign new attestations or validation requests.
• The identity is cryptographically dead.

This is an intentional property of the system, not an oversight. A recovery mechanism that allows a third party to restore a private key would necessarily mean that third party could also access the key — which would break the zero‑knowledge guarantee that underpins the entire trust model.

Backup responsibility. The member is solely responsible for maintaining secure backups of their private key and password. The system provides key export during registration (§10) and on demand thereafter. The system does not store, escrow, or replicate the private key.

Key loss recovery path. A member who has lost their key but can prove their identity through alternative means (validated email, phone, document verification, or Operator‑assisted identity confirmation) may re‑register with a new identity and request that the Operator treat the key loss as an account recovery event:

1. The member creates a new Catalog.ID identity with fresh keys.
2. The member proves their identity to the Operator through available validation channels.
3. The Operator terminates the old account (per §9a.3).
4. The Operator transfers the old account’s public profile (§4.5) to the new identity.
5. The member re‑creates and re‑validates their claims on the new identity.

Existing Asset Registry provenance claims remain in the immutable record under the old identity. New Asset Registry claims are submitted under the new identity.

What survives key loss:

• Public claims (§4.5), which are stored in cleartext and signed by the Operator — these transfer to the new identity.
• Asset Registry provenance claims, which are immutable records — these remain in the registry under the old identity.
• Claims previously shared with other members — those members retain access through their own keys.

What is permanently lost:

• Encrypted claims that were not shared with anyone. The server holds only ciphertext; without the private key, these are unrecoverable.
• Validation certificates for the old identity. The member must re‑validate claims on the new identity.

3.3 Key Compromise

Key compromise is a distinct scenario from key loss: the member still possesses the private key, but an unauthorized party has also obtained it. Because the member retains the key, all data can be migrated in place through key rotation — no new account is needed.

Step 1: Immediate lockdown. Any holder of the compromised key can submit an authenticated lockdown request. The server immediately halts all API access for the account: no claim decryption, no sharing, no Asset Registry claim submissions, no validation requests. Lockdown is a one‑way action that does not require operator verification — it is always safe to freeze the account. If the attacker triggers the lockdown before the member does, the effect is the same: the account is protected from further exploitation.

Step 2: Identity verification. The member contacts the Operator and proves their identity through at least one validated channel independent of the compromised key — for example, a verification code sent to the member's validated email address or phone number, or document‑based verification. The Operator must be satisfied that the person requesting key rotation is the legitimate account holder.

Step 3: Key rotation. Once identity is verified:

1. The member generates a new key pair and submits the new public key to the server.
2. The server wraps every encrypted symmetric key associated with the account in an additional encryption envelope using the new public key. This includes the member's own claims as well as claims shared by other members (which were encrypted with the member's compromised public key). The operation is performed entirely server‑side — no client download or re‑upload is needed. No plaintext key material is exposed; the inner layer is never decrypted.
3. The new key is added to the account's key chain. The compromised key is retained in the chain but marked as revoked.
4. Decryption of existing claims now requires walking the key chain: the new private key unwraps the outer envelope, then the compromised private key decrypts the inner layer to obtain the symmetric claim key. The compromised key alone is no longer sufficient.
5. New claims created after rotation are encrypted directly with the new public key — no chain walking is needed for them.

Step 4: Account unlock. The Operator unlocks the account. The member resumes access using the new key.

If the key is compromised again in the future, the process repeats: lockdown, verify, generate a new key, wrap existing encrypted keys with an additional layer, unlock. The chain grows by one link with each rotation.

What is preserved:

• The member's username and account — no change of identity.
• All encrypted claims — re‑wrapped in place without exposing plaintext.
• Public claims — unaffected (stored in cleartext, signed by the Operator).
• Validation certificates — unaffected (they attest to claim content, not to the encryption key).
• Asset Registry provenance — unaffected. Existing Asset Registry claims remain signed with the per‑machine Asset Registry signing keys. Asset Registry signing keys are machine‑local (§3.4.1a) and not stored in the key bag, so identity key compromise does not directly compromise Asset Registry signing keys. If a machine's Asset Registry signing key is independently compromised, the member revokes that key's registry_signing_key claim and generates a new key on the same or a replacement machine. New Asset Registry claims are signed with the new key under the same username.

Exposure window. Between the moment of compromise and lockdown, the attacker can decrypt any claims encrypted with the compromised key, and potentially submit Asset Registry claims or share claims using the compromised key. The member should trigger lockdown as quickly as possible to minimize this window. Claims shared with other members are not directly exposed — those sharing relationships used the recipient's public key, not the compromised one.

3.4 Key Bag and Device Access

A Catalog.ID identity uses multiple cryptographic key pairs, each generated independently for a distinct purpose. These keys are collectively managed as a key bag — a set of individually encrypted entries stored on the server. Each entry contains a single private key encrypted with the same supersecret‑derived AES‑256‑GCM key (§3.4.3), identified by a key ID string and key index. The entry‑based design enables independent addition, revocation, and synchronization of individual keys without affecting other entries in the bag.

3.4.1 Key Types

The key bag contains identity-level keys — keys that define the member's cryptographic identity and need to be portable across devices:

Additional identity-level key types may be added as the system evolves. Each key bag entry is identified by a key ID string and key index (supporting key rotation — the same key ID may have multiple versions), and includes the algorithm identifier, encrypted private key material, and a unique AES‑256‑GCM nonce.

3.4.1a Per‑Machine Asset Registry Signing Keys

Asset Registry signing keys are not stored in the key bag. Instead, each machine on which the Catalog software is installed generates its own independent ML‑DSA‑65 keypair locally. The private key never leaves the machine on which it was generated and is never distributed through the key bag or any other mechanism.

When a machine generates a Asset Registry signing key, it registers the public key with the member's Catalog.ID account by creating a registry_signing_key claim — an encrypted claim like any other (§4.4.1). The private key remains machine‑local.

This per‑machine model provides:

• Containment. Compromise or loss of one machine's key does not affect other machines. The member revokes the compromised key and generates a new one on the replacement machine.
• Independent revocation. Each key can be revoked individually without disrupting other devices.
• No supersecret exposure. Because the private key is not in the key bag, compromise of the supersecret does not expose Asset Registry signing keys.

Each registered Asset Registry signing key carries the following metadata:

Once revoked_at is set, the key is permanently dead — Asset Registry nodes reject any new claims signed by it. Existing claims signed before revoked_at remain valid.

Each machine has exactly one Asset Registry signing key. A member may have multiple keys across different machines, but not multiple keys on the same machine. This avoids user confusion about which key to use and prevents trivial correlation between keys on the same machine (which would defeat the purpose of anonymity if one key is public and the other is anonymous).

Public vs. anonymous keys. A Asset Registry signing key is anonymous by default: the registry_signing_key claim is encrypted, and the public key is not publicly linkable to the member's username. To make a key public — enabling it to sign attribution claims — the member publishes the registry_signing_key claim through the standard public claims flow (§4.5). The public/anonymous distinction is not a type flag on the key; it is simply whether the corresponding claim has been published. A member can change a key's visibility at any time: publishing an anonymous key makes it public; unpublishing a public key makes it anonymous again (with the caveat that observers who already saw the published key know the association).

Privacy notice. An anonymous registration provides unlinkability only if the claimant does not subsequently create or receive public attributions on the same asset. Public attributions create a correlation path that may allow observers to infer the identity behind the anonymous registration. Members who require anonymity for a registration should not attribute that asset through their public identity.

Arbitration use case. A member who registered files anonymously can later prove ownership to arbitrators by sharing the encrypted registry_signing_key claim with them via the standard sharing protocol (§4.2). The arbitrators decrypt the claim, match the public key against the anonymous Asset Registry registration, and confirm the member's authorship — without exposing the key publicly.

Key loss. If a machine is lost or destroyed (not compromised), the private key is gone. The member revokes the key and generates a new one on the replacement machine. Existing claims signed with the old key remain valid — they were signed while the key was active. The encrypted registry_signing_key claim (containing the public key) remains on the account for historical reference and can still be shared for verification of past claims.

3.4.2 Split Storage Model

No single location holds enough information to access a private key. The key bag is protected by a split‑storage design:

• Server stores each key bag entry individually encrypted with a key derived from the member's supersecret (AES‑256‑GCM, key derived via Argon2id). Each entry has its own unique nonce. The server cannot decrypt any entry because it does not know the supersecret.
• Browser localStorage stores individual private keys (only those the member chose to import) encrypted with a random 32‑byte deviceEncryptionKey (AES‑256‑GCM). The browser cannot decrypt these keys because it does not hold the deviceEncryptionKey.
• Server stores the deviceEncryptionKey and returns it only after the member provides a valid PIN for that device.

This three‑way split ensures that compromise of the server database alone, or theft of the browser storage alone, does not expose any private key.

3.4.3 Supersecret

The supersecret is generated client‑side during registration in the extended format defined in the Recovery Kit Addendum §2.5: four lines of twelve characters each (11 random + 1 per‑line checksum), drawn from the non‑confusing base57 alphabet ([a–z A–Z 2–9] excluding i, l, O). Total random entropy: 44 × log₂(57) ≈ 256 bits. The per‑line checksums enable line‑specific error detection during manual entry; they are not part of the cryptographic strength. It serves two purposes:

1. Key bag encryption. The 44 random characters of the supersecret (excluding checksums, dashes, and line breaks) are the input to Argon2id (64 MB memory, 3 iterations, 4 parallelism) with a random salt to derive an AES‑256‑GCM key. This derived key encrypts each key bag entry individually — one AES‑256‑GCM encryption per entry, each with its own unique nonce. The Argon2id salt is shared across all entries and stored on the server alongside the account.
2. Device restore authority. Entering the supersecret is the only way to decrypt the key bag entries on a new device. The server cannot perform this decryption.

The supersecret is presented to the member during registration for export (print, download, or secure copy). It is never stored on the server in plaintext or hashed form — the server holds only the individually encrypted key bag entries and the shared Argon2id salt. If the member loses the supersecret and has no device with imported keys, the identity is cryptographically dead (§3.2).

3.4.4 PIN as a Per‑Device Convenience Credential

After restoring the key bag on a device, the member chooses a PIN to protect quick access on that device. The PIN is not generated during registration and is not part of the supersecret backup.

PIN length is the member's choice: 4, 6, or 8 digits, or no PIN at all. The member also chooses the device storage mode:

• PIN (4/6/8 digits): Keys are stored in localStorage, protected by the split‑storage model. The PIN is required each session to retrieve the deviceEncryptionKey from the server.
• No PIN: Keys are stored in localStorage, and the server returns the deviceEncryptionKey to any authenticated session with the matching device token. The login password is the only protection. Appropriate for personal devices.
• No local storage: No keys are persisted in localStorage. The member enters the supersecret each session to decrypt the key bag directly from the server. Maximum security, no convenience — suitable for shared or untrusted devices.

Each device has its own independent PIN and storage mode. A member may use a 4‑digit PIN on a personal phone, no PIN on a home workstation, and no local storage on a shared computer. Settings can be changed at any time by re‑entering the supersecret.

Device setup flow (after supersecret restore):

1. The member enters the supersecret. The client derives the AES key via Argon2id, decrypts the key bag, and holds all private keys in memory.
2. The member selects which keys to import to this device (e.g., only attr_encrypt on a phone, all keys on a primary workstation). If the member chooses no local storage, this step is skipped.
3. The member chooses a PIN length and enters a PIN, chooses no PIN, or chooses no local storage.
4. For PIN or no‑PIN modes: the client generates a random 32‑byte deviceEncryptionKey, encrypts each selected private key with it via AES‑256‑GCM, stores the results in localStorage under {accountID}-key-{keyID}, and sends the deviceEncryptionKey (and PIN, if any) to the server associated with a device token.
5. Private keys not selected for import are discarded from memory.

PIN/mode change: The member re‑enters the supersecret (proving authority), picks a new mode, the client generates a new deviceEncryptionKey (or clears localStorage for no‑local‑storage mode), and sends the updated record to the server. The old device record is replaced.

3.4.5 Daily Use

With PIN:

1. The member enters their PIN on the shuffled numeric keypad.
2. The client sends the PIN + device token to the server.
3. The server verifies the PIN and returns the deviceEncryptionKey.
4. The client decrypts each imported key from localStorage using the deviceEncryptionKey.
5. Decrypted keys are held in memory for the session.

Without PIN:

1. The client sends the device token to the server as part of session authentication.
2. The server returns the deviceEncryptionKey automatically.
3. The client decrypts each imported key from localStorage.

Without local storage:

1. The member enters the supersecret.
2. The client derives the AES key via Argon2id and decrypts the key bag from the server.
3. Decrypted keys are held in memory for the session only — nothing is written to localStorage.

3.4.6 Brute Force Protection

The server serializes PIN attempts per device using a database row lock (FOR UPDATE), preventing parallel guessing.

On a wrong PIN:

• The error counter increments.
• After a threshold of consecutive errors (scaled by PIN length: 2 for 4‑digit, 3 for 6‑digit, 4 for 8‑digit), the device record is locked.
• A locked device record requires re‑entering the supersecret to unlock — which also allows the member to choose a new PIN.

The lockout is per‑device, not per‑account. A locked phone does not affect a workstation that has a different PIN.

3.4.7 Selective Key Import

Not all devices need all keys. The member controls which private keys are imported to each device at restore time:

Note: Asset Registry signing keys are not part of the key bag and are not imported through this mechanism. Each machine generates its own Asset Registry signing key locally (§3.4.1a).

The server does not know which keys were imported where. The device token identifies the device for PIN exchange; the key selection is purely a client‑side decision reflected only in which localStorage entries exist.

Keys can be removed from a device at any time by deleting the corresponding localStorage entry. Adding a key that was not initially imported requires re‑entering the supersecret to decrypt it from the key bag.

3.4.8 Key Bag Updates

When a new key is generated (e.g., adding an XRPL key after registration, or key rotation per §3.3), the member must re‑enter the supersecret to:

1. Derive the AES‑256‑GCM key from the supersecret via Argon2id.
2. Encrypt the new private key as a new key bag entry with a unique nonce.
3. Upload the new entry to the server.
4. Optionally import the new key to the current device's localStorage.

For key rotation, the old entry is marked as revoked (not deleted — it remains available for chain‑walking decryption of historical data). Because each key is a separate entry, adding a key does not require downloading or re‑encrypting existing entries. This ensures the server‑stored key bag always contains the complete, current set of private keys and supports concurrent key additions from different devices or nodes without conflict (§15.3.4).

3a. Organization Identities

3a.1 Overview

Catalog.ID supports four kinds of identity: personal identities for natural persons, organization identities for studios, labels, foundations, companies, and other entities, delegate identities for natural persons acting in the capacity of an organization (§3b), and agent identities for autonomous entities acting on behalf of a personal or delegate identity (§3c). Personal, organization, and delegate identities share the same underlying data model — a single identity table with a type discriminator (natural_person, organization, delegate, or agent) — and the same cryptographic machinery: key bag, claims, sharing, validation certificates, and key chain. Agent identities share the identity table and have their own public keys registered on their account, but have no independent key custody — all private keys are held in the principal's key bag (§3c.4). The differences are behavioral, not structural.

An organization identity is a full Catalog.ID identity with its own username, keypair, key bag, claims, and public profile. It can receive shared claims, sign Asset Registry provenance claims, hold an XRPL wallet, and publish a public profile — the same capabilities as a personal identity.

Where the two kinds diverge:

• Membership. Personal identities are members of the network — they accept the Catalog.ID Membership Agreement, participate in the trust graph, and have standing in the dispute resolution system. Organization identities are not members. They operate under a separate Organization Identity Agreement (§3a.10) and are governed through their delegate identities (§3b).
• Username format. Personal usernames are assigned in the abc1234efg format (§3). Organization usernames follow the complementary 123abcd456 format (§3a.2) — digits on the outside, letters in the middle — making the two instantly distinguishable.
• Key custody. A personal identity's keys are held by the member through the supersecret and PIN mechanism (§3.4). An organization identity uses the same supersecret and key bag model (§3a.3), with the organization's credentials managed by the person or persons responsible for the organization. For daily operations, organization keys are distributed to delegate identities as wrapped copies (§3a.3, §3b).
• Retirement. Personal usernames are permanently retired on termination (§3.1.4). Organization usernames are also permanently retired on termination (§3a.7) — the same provenance‑preservation rationale applies.

3a.2 Sequence‑Based Username

An organization's username is a 10‑character alphanumeric string in the format 123abcd456 (three digits, four lowercase letters, three digits), deterministically encoded from an internal sequence number — the same bijective encoding approach used for personal usernames (§3), with the character classes rearranged. The namespace comprises 10⁶ × 26⁴ ≈ 457 billion possible identifiers.

The organization does not choose its username. The domain name associated with the organization is stored as a validated claim (a domain claim, §3a.6), not as the username itself. This decouples the organization's stable identity from its potentially mutable domain.

The format provides:

• Instant namespace separation. Personal usernames begin with a letter (abc1234efg); organization usernames begin with a digit (123abcd456). No format flags or type prefixes are needed — the username itself communicates whether the identity is a person or an organization.
• Visual complementarity. The organization format is the structural inverse of the personal format: digits on the outside, letters in the middle. The symmetry is intentional and makes both formats instantly recognizable as Catalog.ID identifiers.
• Stable identity. Because the username is a system‑assigned sequence identifier, it never changes — even if the organization rebrands, changes its domain, or merges. Historical Asset Registry provenance records, shared claims, and signatures remain unambiguously attributed to the same identity.
• Adequate namespace. 457 billion identifiers is orders of magnitude more than the number of organizations that will ever exist, while remaining clearly smaller than the personal namespace (3.09 trillion), reflecting that organizations are less numerous than individuals.

3a.2.1 Namespace Intellectual Property

The organization username namespace — the set of all possible organization usernames, the \d{3}[a-z]{4}\d{3} format, and the encoding algorithm — is a creative work authored by the Developer, subject to the same intellectual property protections as the personal username namespace (§3.1). The same licensing chain applies: the Developer licenses the namespace to the Operator, and the Operator sub‑licenses individual usernames to organizations under the Organization Identity Agreement (§3a.10). Organization usernames are Developer property, not organizational property — the organization receives a revocable, non‑transferable license to use its assigned username within the Catalog.ID system.

3a.3 Key Custody and Delegate Model

An organization identity has its own ML‑KEM‑1024 keypair and key bag, generated during registration (§10a). Like personal identities, the organization identity has its own password, supersecret, and key bag, following the same credential model described in §3:

• Password — authenticates the organization's session. Used for administrative operations (key bag management, key rotation, delegate onboarding).
• Supersecret — encrypts the organization's key bag entries for backup and restore. The supersecret is the authoritative access credential for the organization's full key chain.
• Key bag — the organization's private keys, including historical keys from past rotations, stored as individually encrypted entries on the server (§3.4).

The system does not prescribe how the organization's credentials are managed after registration. The founding person receives the organization's password and supersecret during registration (§10a) and is solely responsible for their safekeeping — whether that means storing them in a corporate vault, sharing them with co‑owners, or keeping them personally. This is no different from a personal identity's credential management: the system provides the credentials; the holder decides how to protect them.

Daily operations use delegate identities, not the organization account. The organization account is intended for administrative tasks — key rotation, key chain management, delegate onboarding — not for routine work. Daily operational access to organization keys is distributed to delegate identities (§3b) through wrapped key copies.

Every delegate identity has its own independent key bag and can act under its own username (§3b). Access to the organization's keys is separate and role‑based: only delegate identities whose role requires it (§3a.4) receive wrapped copies of specific organization keys. A delegate identity that only needs to act as itself — for example, signing Asset Registry claims under the delegate username — does not need any organization keys at all.

For delegate identities that do hold organization keys, the wrapped key is encrypted to the delegate identity's public key and stored on the server. To use an organization key, the delegate identity's client:

1. Retrieves the wrapped organization key.
2. Decrypts it using the delegate identity's own private key (unlocked through the normal PIN/supersecret flow on the employee's device).
3. Holds the organization key in memory for the session.

Access to organization keys through delegate identities is gated by the employee's own security — their PIN, their supersecret, their device. The organization never holds the employee's private keys (§3b.4), and the employee never holds organization keys in plaintext outside of an active session.

Relationship between the organization key bag and wrapped copies. The organization's supersecret‑encrypted key bag entries are the authoritative store for the full key chain. Wrapped copies on delegate identities are a distribution mechanism for daily use. When the organization's keys are rotated (§3a.5), a new key bag entry is added and new wrapped copies are distributed to remaining delegate identities. When a new delegate identity is onboarded after one or more rotations, the person performing the onboarding can access the full key chain from the organization's key bag entries and wrap the complete chain for the new delegate identity — ensuring that all delegate identities can walk the chain to decrypt historical data.

3a.3.1 Organization‑Wide Claim Sharing

Because every delegate identity receives the organization's attr_encrypt key regardless of role (§3a.4), the standard claim sharing mechanism (§4.2) naturally supports organization‑wide sharing: any claim — whether belonging to the organization, a delegate identity, or an external identity — can be shared with the organization by encrypting the claim's symmetric key with the organization's public key. Every delegate identity that holds the attr_encrypt key can then decrypt it. No separate group key is needed.

The same claim can simultaneously be shared org‑wide (via the organization's public key), with individual recipients (via their personal public keys), and/or published as a public claim — these are independent sharing envelopes.

Examples:

• The organization shares its display_name, email, and phone claims with itself — all delegate identities can see the organization's contact details, but no outsiders can.
• A delegate identity shares their own email or phone claim with the organization — making it visible to all colleagues without publishing it.
• An external partner shares a claim with the organization — all delegate identities can read it without individual sharing.

Revocation on departure. Because every delegate identity holds the attr_encrypt key, every departure triggers the key rotation mechanism described in §3a.5: the organization's keypair is rotated, the server re‑envelopes all encrypted claim keys server‑side (no plaintext exposed), and the departed employee's wrapped copy of the old private key is deleted. The departed employee cannot unwrap the new outer layer — cryptographically guaranteeing that they lose access to all org‑shared data, including data from their tenure.

Chain flattening. Each key rotation adds a layer to the encryption chain. To decrypt data shared under an old key, a delegate identity walks the chain — one decryption per layer. While each step is fast, the chain grows with departures. To keep access efficient, the holder of the organization's supersecret can periodically flatten the chain: decrypt the organization's key bag to access the full key chain, re‑encrypt old claim keys directly with the current key, and collapse the chain to depth 1. Flattening is performed lazily during low activity. Because the organization's key bag is the authoritative store for the full key chain, flattening does not depend on any particular delegate identity being present — it only requires the organization's supersecret.

3a.4 Delegate Roles

Each delegate identity (§3b) associated with an organization holds one or more roles that determine what the delegate identity can do on behalf of the organization:

A delegate identity may hold multiple roles simultaneously — for example, admin + treasurer for an employee who manages both delegate identities and financial transactions without requiring full owner access. The owner role implicitly includes all capabilities of the other roles; assigning additional roles alongside owner is redundant but harmless.

The role set is stored on the delegate identity's record alongside the immutable organization link and any wrapped organization keys.

Selective key distribution. The server enforces role‑based key distribution: a delegate identity receives the union of organization keys required by all of its assigned roles. Every delegate identity receives at minimum the attr_encrypt key — this is what enables organization‑wide claim sharing (§3a.3.1). Additional keys are distributed based on the role set.

When a delegate identity's role set changes, the server updates which wrapped keys are available. Adding a role may add keys; removing a role removes wrapped copies for key types no longer needed by any remaining role, and may trigger key rotation for those key types if the security policy requires it.

The delegate identity's obligations under the Organization Identity Agreement (§3a.10) — including the employee terms accepted at activation — apply in full to actions taken through the organization identity. The organization's owner delegate identities are the accountable parties for the organization's use of the system.

3a.5 Key Rotation on Delegate Removal

When a delegate identity is removed from the organization, the organization's encryption keys must be rotated — because every delegate identity holds at minimum the attr_encrypt key (§3a.4), every departure requires rotation to revoke access to org‑shared data (§3a.3.1). If the departing delegate identity held additional keys (e.g., xrpl_master, msg_encrypt), those are rotated as well. The rotation follows the same pattern as personal key compromise rotation (§3.3):

1. An owner or admin delegate identity initiates the removal (or the employee requests voluntary termination).
2. The person performing the rotation generates a new ML‑KEM‑1024 keypair for the organization on their client. This may be done through the organization account (using the organization's supersecret to access the key bag entries) or through a delegate identity that holds the relevant organization keys.
3. The client submits the new public key to the server. The server wraps every encrypted symmetric key associated with the organization identity in an additional encryption envelope using the new public key. This is performed entirely server‑side — no plaintext is exposed. The inner layer encrypted with the old key is not decrypted.
4. The new organization private key is wrapped to each remaining delegate identity's public key (respecting role‑based key distribution per §3a.4) and uploaded to the server.
5. The organization's key bag is updated: the new key is added as a new entry and the old entry is marked as rotated. Because key bag entries are individual (§3.4), this requires encrypting only the new key — not re‑encrypting the entire bag.
6. The removed delegate identity's wrapped copy of the old key is deleted.

After rotation, decryption of existing claims requires walking the key chain: the new private key unwraps the outer envelope, then the old private key (accessible through the key chain in the organization's key bag) decrypts the inner layer. The removed delegate identity, who only possessed a wrapped copy of the old key (now deleted), cannot unwrap the new outer envelope. New claims shared with the organization after rotation are encrypted directly to the new public key — no chain walking is needed.

In addition to encryption key rotation, removal of a delegate identity that held published Asset Registry signing keys (§3a.8) triggers action on those keys. Two distinct actions are available:

• Revocation — the key is marked as revoked (revoked_at is set). The departing delegate identity can no longer sign Asset Registry claims with this key on behalf of the organization. Historical claims signed before revoked_at remain valid and visible. This is the typical action on departure.
• Removal (unpublication) — the key is removed from publication. The system can no longer distinguish this key as belonging to the organization — it is treated like any other anonymous key. The delegate identity retains the private key and can still sign with it, but new signatures are treated as anonymous. All historical attribution claims signed with this key are muted by Asset Registry nodes (see §4.4.2 and Asset Registry Whitepaper §7.6.5), the same mechanism as when a personal member unpublishes their Asset Registry signing key.

Encryption key rotation and Asset Registry signing key action are separate mechanisms — rotation ensures the departing delegate identity cannot decrypt claims shared with the organization, while revocation/removal controls the Asset Registry signing key's status.

3a.6 Domain Claim and Revalidation

Every organization identity must have a validated domain claim — an encrypted claim containing the organization's domain name, validated through the standard domain ownership flow (§7.5): the delegate places a verification token at .well-known/catalogid.txt and the Validator Black Box confirms domain control. The domain claim is mandatory at registration (§10a) and serves as the verifiable link between the organization identity and its real‑world web presence.

The domain claim is subject to mandatory periodic revalidation. The domain validation certificate (§8.1) expires after 1 year. If the organization does not revalidate domain ownership before expiry:

1. The organization identity is frozen: no new claims can be shared with it, no transactions can be signed, no public claims can be published or updated.
2. Existing claims shared with the organization remain accessible to current delegate identities that hold the relevant keys.
3. The organization has a grace period of 90 days to revalidate. During this period, the identity remains frozen but is not terminated.
4. If revalidation does not occur within the grace period, the Operator may terminate the organization identity.

Domain changes. If an organization changes its domain, a delegate identity with the owner or admin role updates the domain claim with the new domain name and initiates a new domain validation flow. Once validated, the new domain replaces the old one. The organization's username, key bag, claims, Asset Registry history, and all other identity data remain unchanged — only the domain attribute is updated. This is the key advantage of decoupling the domain from the username: organizational identity survives domain changes without any loss of continuity or provenance history.

3a.7 Retirement

Organization identity usernames follow the same permanent retirement policy as personal usernames:

• Personal usernames are permanently retired on account termination — never reassigned (§3.1.4). This prevents identity confusion in provenance records.
• Organization usernames are also permanently retired on termination — never reassigned. The same provenance‑preservation rationale applies: historical Asset Registry claims, shared claims, and cryptographic signatures are permanently attributed to the retired username.

Because the organization's domain is a claim (§3a.6), not the username, domain reuse is not an issue. A different organization that happens to use the same domain can register a new organization identity with its own unique username — there is no collision or ambiguity.

3a.8 Organization Asset Registry Participation

Organization identities do not have their own Asset Registry signing keys. Instead, an organization participates in Asset Registry through the Asset Registry signing keys of its delegate identities (§3b).

Delegate identities have their own per‑machine Asset Registry signing keys, following the same model as personal identities (§3.4.1a): each key is an independent ML‑DSA‑65 keypair generated locally on the machine, anonymous by default, and optionally published at the employee's discretion. There is no fundamental difference between a delegate identity's Asset Registry signing keys and a personal identity's Asset Registry signing keys.

Organization attribution is a display layer. When a Asset Registry claim is signed by a delegate identity whose signing key is published, any system that resolves the signing key can look up the delegate identity, follow the immutable organization link, and display the organization's username alongside the claim. The claim is signed by the delegate identity — the organization attribution is derived from the lookup, not from a separate cryptographic mechanism.

This means:

• Anonymous file claims are possible. A delegate identity can register file claims anonymously, exactly like a personal identity. If the signing key is not published, the claim cannot be traced to the delegate identity or the organization.
• Published attribution claims are traceable. When a delegate identity publishes its signing key, both the delegate identity and its organization become discoverable. A verifier can determine that the claim was signed by delegate e3k7m2p9a1, who belongs to organization 482mxvt719.
• No separate organization signing key infrastructure is needed. The delegate identity's own Asset Registry signing key model provides both anonymous and attributed signing without any special organizational key type.

Publication cannot be enforced by the system. An organization that wants all employee work attributed to the organization may want to require that its delegate identities publish their Asset Registry signing keys. However, the system cannot enforce this: Asset Registry signing keys are generated on the employee's machine, stored as encrypted claims under the employee's own attr_encrypt key (§3b.4), and published only through the employee's voluntary action (§4.5.3). The organization has no cryptographic access to the delegate identity's encrypted claims and therefore cannot publish the key on the employee's behalf. Enforcement of publication requirements is an organizational matter — addressed through the employment relationship and the Organization Identity Agreement's employee terms (§3a.10) — not a system mechanism.

3a.8.1 Revocation on Delegate Identity Departure

When a delegate identity is removed from the organization, the organization's owner or admin should take action on the departing delegate identity's published Asset Registry signing keys. Two options are available (see also §3a.5):

• Revoke the key (revoked_at is set, revoked_reason: delegate_departed). The key is permanently dead — no new Asset Registry claims can be signed with it. Historical claims signed before revoked_at remain valid. This is the typical action on departure.
• Remove (unpublish) the key. The key is no longer publicly associated with the delegate identity or the organization. The employee retains the private key and can still sign with it, but new signatures are treated as anonymous. All historical attribution claims signed with this key are muted by Asset Registry nodes (same mechanism as personal key unpublication — see §4.4.2 and Asset Registry Whitepaper §7.6.5).

Revocation preserves the historical attribution record while preventing further signing. Removal disassociates the organization from all claims signed by the departing delegate identity.

3a.8.2 Audit Trail

Because every delegate identity has an immutable organization link, the organization's owner and admin delegate identities can audit Asset Registry signing activity across the organization:

• Which delegate identity signed a given Asset Registry claim → resolve the published signing key to the delegate identity.
• Which machine was used → the signing key's machine_label (encrypted, accessible to owner and admin).
• When the signing occurred → the Asset Registry claim's timestamp.
• Whether the delegate identity was authorized at the time → compare the claim timestamp against the signing key's registered_at and revoked_at.

This audit trail requires no separate log — it is derived from the delegate identity's published key records and the immutable organization link.

3a.9 Organization XRPL Wallet

An organization identity may hold its own xrpl_master key in its key bag, giving the organization an independent XRPL wallet. Delegate identities with the treasurer role (or owner) receive the wrapped xrpl_master key (§3a.4) and can sign XRPL transactions on behalf of the organization. The key is managed through the same key bag mechanism as personal XRPL keys, with the same key rotation and wrapping model.

3a.10 Legal Framework

Organization identities and their delegate identities operate under a separate Organization Identity Agreement — not the Catalog.ID Membership Agreement (which governs personal membership). This agreement:

• Defines the organization identity as a non‑member identity with its own credentials (password, supersecret, key bag), administered by the person or persons who hold those credentials and operated day‑to‑day through delegate identities (§3b).
• Requires at least one delegate identity with the owner role at all times — the owner(s) are accountable for the organization's use of the system.
• Specifies that disputes involving an organization identity are disputes with its owner delegate identities.
• Covers credential custody (the organization's password and supersecret), delegate identity management, domain revalidation, and termination conditions. The system does not prescribe how the organization's credentials are managed — that is the organization's responsibility.
• Includes employee terms accepted by each delegate identity at activation (§3b.3).
• Addresses what happens when the sole remaining owner delegate identity is terminated or becomes inaccessible (e.g., mandatory transition period, operator intervention).

If a delegate identity's employee also holds a personal Catalog.ID identity (§3b.5), the personal identity is governed by the Catalog.ID Membership Agreement separately. The two legal frameworks do not interact — actions taken under the delegate identity are governed by the Organization Identity Agreement, and actions taken under the personal identity are governed by the Catalog.ID Membership Agreement.

3b. Delegate Identities

3b.1 Overview

Catalog.ID supports a third kind of identity: delegate identities for natural persons acting in the capacity of an organization. A delegate identity represents "person X acting for organization Y" as a single, first‑class identity in the system.

Delegate identities exist to solve three problems that personal and organization identities cannot address individually:

1. The createdby problem. External systems that integrate with Catalog.ID (content management systems, DAMs, publishing platforms) store a Catalog.ID username in their database columns. A personal username tells you who but not in what capacity. An organization username tells you which organization but not who. A delegate username tells you both — this specific person, acting for this specific organization — in a single identifier.
2. Mass onboarding. An organization with hundreds or thousands of employees needs to give each one a Catalog.ID identity without requiring each employee to first create a personal account. Delegate identities are created by the organization for the employee.
3. Context switching. A person may act sometimes as themselves and sometimes as an employee. The login flow allows switching between personal and delegate identities without re‑authentication.

A delegate identity is stored in the same identity table as personal and organization identities, with a type discriminator value of delegate. It shares the same cryptographic architecture: key bag, claims, sharing, validation certificates, and key chain. The differences are in lifecycle control (the organization manages the account) and the immutable organizational link.

Delegate identities are also the mechanism through which organizations exercise key custody and act on the system (§3a.3–§3a.4). A delegate identity with the appropriate role receives wrapped copies of organization keys, enabling it to sign transactions, manage claims, or perform other actions on behalf of the organization. This unifies the concepts of "employee account" and "organization key holder" into a single identity type.

Where delegate identities diverge from personal and organization identities:

• Created by the organization. A delegate identity is created by an owner or admin of an organization identity — not self‑registered like a personal identity.
• Username format. Delegate usernames follow the ab12cd34fg format (§3b.2) — alternating letter‑pair and digit‑pair — making them instantly distinguishable from both personal and organization usernames.
• Immutable organization link. Every delegate identity is permanently linked to exactly one organization identity. This link is set at creation and cannot be changed.
• Organization‑controlled lifecycle. The organization can freeze or terminate the delegate identity. The employee cannot prevent termination.
• Employee‑controlled keys. The employee generates and holds their own keys via the standard supersecret/PIN mechanism (§3.4). The organization never holds the employee's private keys and cannot decrypt the employee's claims.
• Not a member. Like organization identities, delegate identities are not network members. They operate under the Organization Identity Agreement (§3a.10), not the Catalog.ID Membership Agreement.
• Retirement. Delegate usernames are permanently retired on termination (§3b.9) — same policy as personal and organization usernames.

3b.2 Sequence‑Based Username

A delegate identity's username is a 10‑character alphanumeric string in the format ab12cd34fg (pairs of lowercase letters alternating with pairs of digits: LL DD LL DD LL), deterministically encoded from an internal sequence number — the same bijective encoding approach used for personal (§3) and organization (§3a.2) usernames. The namespace comprises 26⁶ × 10⁴ ≈ 3.09 trillion possible identifiers.

The format provides:

• Instant namespace separation. Personal usernames begin with a letter cluster (abc...); organization usernames begin with a digit cluster (123...); delegate usernames begin with a letter pair followed by a digit pair (ab12...). The three patterns are visually distinct at a glance — no format flags or type prefixes are needed.
• Structural uniqueness. The paired‑alternating pattern (LL DD LL DD LL) has a distinctive rhythm that is visually unmistakable as a delegate identity even in database columns, log files, or attribution records.
• Adequate namespace. 3.09 trillion identifiers — matching the personal namespace (3.09 trillion) and exceeding the organization namespace (457 billion) — is more than sufficient for the total number of organizational employees that will ever exist in the system.

3b.2.1 Namespace Intellectual Property

The delegate username namespace — the set of all possible delegate usernames, the [a-z]{2}\d{2}[a-z]{2}\d{2}[a-z]{2} format, and the encoding algorithm — is a creative work authored by the Developer, subject to the same intellectual property protections as the personal and organization username namespaces (§3.1, §3a.2.1). The same licensing chain applies: the Developer licenses the namespace to the Operator, and the Operator sub‑licenses individual usernames to organizations (which assign them to employees) under the Organization Identity Agreement (§3a.10).

3b.3 Creation and Lifecycle

A delegate identity is created by the organization, not by the employee:

1. An owner or admin delegate identity of the organization initiates delegate identity creation.
2. The system assigns the next available delegate username in the ab12cd34fg format.
3. The organization specifies a role label for the employee (e.g., "Studio Manager", "Content Editor") — stored as a professional_role claim on the delegate identity.
4. The system generates an invitation token — a single‑use, time‑limited credential that the organization provides to the employee (via email, internal messaging, or in person).
5. The employee opens the invitation, and the client generates the password, supersecret, and key bag locally — the same client‑side key generation as personal registration (§10 steps 3–6). The organization never sees the employee's private keys, password, or supersecret.
6. The delegate identity is activated with the immutable link to the organization.

The full registration flow is described in §10b.

Organization control over the lifecycle:

• Freeze. An owner or admin can freeze a delegate identity at any time, halting all API access — same mechanism as lockdown (§3.3 step 1). The employee cannot unfreeze their own delegate identity; only the organization can.
• Terminate. An owner or admin can terminate a delegate identity, triggering the standard account termination protocol (§9a.3). Termination is permanent — the username is retired and the identity cannot be restored.
• Role changes. The organization can update the employee's role set (§3a.4) and other organizational metadata. Adding a role may grant additional wrapped organization keys; removing a role may revoke them (§3a.4).

Employee control over the identity:

• Key custody. The employee holds their own supersecret, PIN, and private keys — the full personal key custody model (§3.4).
• Claims. The employee creates, manages, and shares their own claims. The organization cannot access encrypted claims on the delegate identity.

Termination. A delegate identity is terminated when the employment relationship ends:

• The organization terminates the delegate identity when the employee departs — this is the normal case. The owner or admin initiates termination, triggering the standard account termination protocol (§9a.3). Termination is permanent — the username is permanently retired and the identity cannot be restored.
• The employee cannot unilaterally terminate their delegate identity while still employed. The delegate identity is the organization's work account, created and governed by the Organization Identity Agreement. While the employment relationship is active, the organization has a legitimate interest in maintaining the account.
• When the employment relationship ends, the employee may request termination if the organization has not already done so. The right to erasure (GDPR Article 17) applies once the legitimate basis for processing (the employment relationship) has ceased.

3b.4 Key Custody

A delegate identity holds two independent sets of keys:

1. Employee's own keys. Generated by the employee during activation (§3b.3), held via the standard supersecret/PIN mechanism (§3.4). The organization never sees these keys and cannot decrypt claims encrypted with them. This is the same zero‑knowledge key custody model as personal identities. Claims created on the delegate identity are encrypted with the employee's own attr_encrypt key — not the organization's attr_encrypt key. This is the cryptographic basis for the guarantee that the organization cannot access the employee's encrypted claims.

2. Organization keys (role‑dependent). If the delegate identity's role set (§3a.4) includes roles that require organization key access, the delegate identity receives wrapped copies of the relevant organization keys. These are encrypted to the delegate identity's public key and stored on the server. The employee unwraps them using their own private key when needed. The organization's attr_encrypt key is used only for decrypting claims shared with the organization (§3a.3.1) — it is never used to encrypt the delegate identity's own claims.

The organization controls the existence of the delegate identity and the distribution of organization keys, but not the employee's own cryptographic contents. An owner can terminate a delegate identity or revoke its organization keys (by changing its role set), but cannot read the employee's encrypted claims.

3b.5 Optional Personal Identity Link

An employee who also has a personal Catalog.ID identity can link the two identities, enabling seamless context switching:

• Linking. The employee initiates the link from their personal identity's authenticated session by providing the delegate identity's credentials. The link is stored as a bidirectional relation — both identities are aware of the association.
• Context switching. Once linked, the employee can switch between personal and delegate identity contexts within the same authenticated session, without re‑entering credentials. The UI presents an identity picker showing all linked identities.
• Unlinking. The employee can unlink the identities at any time. Unlinking does not affect either identity's data — they simply become independent again.
• No key merger. Linking does not merge key bags, share claims, or create any cryptographic relationship between the identities. Each identity retains its own independent key bag, supersecret, and claims. The link is purely a convenience layer for session management.
• Not required. Delegate identities function independently. An employee without a personal Catalog.ID accesses the delegate identity with its own username/password/supersecret — no personal identity is needed.

3b.6 Asset Registry Signing Keys

Delegate identities have their own per‑machine Asset Registry signing keys, following the same model as personal identities (§3.4.1a). Each key is an independent ML‑DSA‑65 keypair generated locally on the machine. Keys are anonymous by default and may be published at the employee's discretion through the standard public claims flow (§4.5).

When a delegate identity publishes a Asset Registry signing key, the immutable organization link makes both the delegate identity and its organization discoverable. A verifier resolving the signing key can determine which delegate identity signed the claim and, through the organization link, which organization the delegate identity belongs to. Organization Asset Registry participation is therefore a display layer derived from the delegate identity's published keys and organization link — no separate organization signing key infrastructure is needed (§3a.8).

3b.7 Organization Termination Cascade

When an organization identity is terminated (§3a.7), all delegate identities linked to that organization are also terminated. The cascade follows the standard account termination protocol (§9a.3) for each delegate identity:

• Encrypted claims and keys are destroyed.
• Each delegate username is permanently retired.
• Employees are notified of the termination.
• If an employee has a linked personal identity, the personal identity is unaffected — only the delegate identity is terminated.

3b.8 Retirement

Delegate identity usernames follow the same permanent retirement policy as personal and organization usernames: on termination, the username is permanently retired and never reassigned. Historical Asset Registry claims, shared claims, and cryptographic signatures remain attributed to the retired username.

The immutable organization link persists in the retired record — verifiers can always determine which organization the delegate identity belonged to, even after retirement.

3b.9 Legal Framework

Delegate identities operate under the Organization Identity Agreement (§3a.10), not the personal Membership Agreement. The organization is the responsible party:

• The organization's owner delegate identities are accountable for the delegate identity's use of the system.
• Disputes involving a delegate identity are disputes with the organization's owner delegate identities.
• The employee's acceptance of the Organization Identity Agreement's employee terms is recorded during delegate identity activation.

If the employee also has a linked personal identity, their personal Membership Agreement governs their personal identity separately. The two legal frameworks do not interact — actions taken under the delegate identity are governed by the Organization Identity Agreement, and actions taken under the personal identity are governed by the Catalog.ID Membership Agreement.

3c. Agent Identities

3c.1 Overview

Catalog.ID supports a fourth kind of identity: agent identities for autonomous or semi‑autonomous entities — AI systems, automation scripts, or human operators — acting on behalf of a personal or delegate identity. An agent identity represents "entity X acting under the authority of principal Y" as a first‑class identity in the system.

Agent identities exist to solve the attribution problem for non‑principal actors. When a principal uses an AI assistant, a batch processing script, or a human contractor to perform work within Catalog systems, that work creates objects — Asset Registry claims, uploaded files, metadata entries, database records. Without an agent identity, these objects are attributed to the principal, making it impossible to distinguish principal actions from agent actions. The agent username provides a single, system‑wide identifier that fits in any created_by or modified_by column, log entry, or audit record — the same createdby problem that motivated delegate identities (§3b.1), applied to non‑human and non‑employee actors.

An agent identity is stored in the same identity table as personal, organization, and delegate identities, with a type discriminator value of agent. It shares the identity table's common fields — username, creation timestamp, termination status, immutable link. An agent identity has its own public keys (attr_encrypt, msg_encrypt, and optionally a Asset Registry signing key) registered on its account — making it structurally identical to other identity types for claim operations, sharing, and key lookups. However, the agent has no password, no supersecret, and no key bag — all private keys are generated by and stored in the principal's key bag. The agent never independently holds or persists key material; all cryptographic authority flows from the principal.

Where agent identities diverge from all other identity types:

• No independent key custody. The agent has no key bag, supersecret, or password. Its keys (attr_encrypt, msg_encrypt, Asset Registry signing key) are generated by the principal, stored in the principal's key bag, and provided to the agent's runtime (§3c.5) for the duration of an authorized session or via encrypted local storage in persistent mode (§3c.5.4). The public halves are registered on the agent's account. The agent never independently generates, manages, or persists key material.
• Created by the principal. An agent identity is created by a personal or delegate identity — the principal. The principal is permanently linked to the agent.
• Username format. Agent usernames follow the abcdefghij format (§3c.2) — ten lowercase letters, no digits — making them instantly distinguishable from personal, organization, and delegate usernames, all of which contain digits.
• Immutable principal link. Every agent identity is permanently linked to exactly one principal identity (personal or delegate). This link is set at creation and cannot be changed.
• Principal‑controlled lifecycle. The principal creates, authorizes sessions for, and terminates the agent identity. The agent cannot self‑register, self‑terminate, or modify its own identity.
• Not a member. Agent identities are not network members. They operate under the principal's legal framework — the Catalog.ID Membership Agreement (if the principal is a personal identity) or the Organization Identity Agreement (if the principal is a delegate identity).
• Retirement. Agent usernames are permanently retired on termination (§3c.9) — same policy as all other identity types.

3c.2 Sequence‑Based Username

An agent identity's username is a 10‑character alphabetic string consisting entirely of lowercase letters (e.g., abcdefghij), deterministically encoded from an internal sequence number — the same bijective encoding approach used for personal (§3), organization (§3a.2), and delegate (§3b.2) usernames. The namespace comprises 26¹⁰ ≈ 141 trillion possible identifiers.

The format provides:

• Instant namespace separation. Personal, organization, and delegate usernames all contain digits. Agent usernames contain no digits at all — ten lowercase letters only. This makes agents immediately identifiable in any context: database columns, log files, attribution records, or visual inspection. No format flags or type prefixes are needed.
• Adequate namespace. 141 trillion identifiers is the largest of all four namespaces (personal: 3.09 trillion; organization: 457 billion; delegate: 3.09 trillion). The large namespace reflects that each principal may create multiple agent identities — one per AI model, automation script, or human operator — and that agent identities are expected to be the most numerous identity type over time.

3c.2.1 Namespace Intellectual Property

The agent username namespace — the set of all possible agent usernames, the [a-z]{10} format, and the encoding algorithm — is a creative work authored by the Developer, subject to the same intellectual property protections as the personal, organization, and delegate username namespaces (§3.1, §3a.2.1, §3b.2.1). The same licensing chain applies: the Developer licenses the namespace to the Operator, and the Operator sub‑licenses individual usernames to principals under the applicable agreement (Membership Agreement for personal principals, Organization Identity Agreement for delegate principals).

3c.3 Creation and Lifecycle

An agent identity is created by the principal:

1. The principal (a personal or delegate identity) initiates agent identity creation from an authenticated session.
2. The system assigns the next available agent username in the abcdefghij format.
3. The principal specifies a label for the agent (e.g., "Claude — batch registration", "Nightly sync script", "Photo editor assistant").
4. The principal specifies the agent type: ai_model, automation, or human_operator.
5. The agent identity is activated with the immutable link to the principal.
6. The principal generates a Asset Registry signing key for the agent (§3c.6) — or may do so later.

No invitation token, no employee activation, no credential generation. The agent identity is immediately active because there are no credentials to set up — the principal already holds everything.

Principal control over the lifecycle:

• Session authorization. The principal starts and stops agent sessions (§3c.5). No session can start without the principal's explicit action.
• Terminate. The principal can terminate the agent identity at any time. Termination is permanent — the username is retired and the identity cannot be restored.
• Revoke signing key. The principal can revoke the agent's Asset Registry signing key at any time, preventing further signing.

What the agent cannot do:

• Self‑register, self‑terminate, or create other agent identities.
• Generate, access, or persist its own key material.
• Modify its own identity record, label, type, or principal link.
• Escalate its own session scope (§3c.5).

3c.4 No Independent Key Custody

This is the defining characteristic of agent identities and the fundamental difference from all other identity types.

An agent identity has:

• No password — the agent does not authenticate to Catalog.ID. Sessions are obtained via the agent_delegation grant (§3c.5.5).
• No supersecret — there is no key bag to encrypt.
• No key bag — the agent's private keys are stored in the principal's key bag, not in a separate encrypted container on the server.
• No PIN — there is no interactive device to protect. Persistent‑mode runtimes use the no‑PIN device model (§3c.5.4).
• Own public keys — attr_encrypt, msg_encrypt, and optionally a Asset Registry signing key are registered on the agent's account, making the agent structurally identical to other identity types for claim operations, sharing, and messaging.

The agent's keys — attr_encrypt (§3c.6b), msg_encrypt (§3c.6a), and a Asset Registry signing key (§3c.6) — are generated by the principal, stored in the principal's key bag (tagged with the agent's username), and made available to the agent only through the agent runtime (§3c.5) — either in‑memory for a session (session mode, §3c.5.3) or as encrypted local storage (persistent mode, §3c.5.4). The public halves of these keys are registered on the agent's account, so other identities can share claims with the agent, encrypt messages to the agent, and verify the agent's signing key through the standard lookup mechanisms — the same uniform flow as any other identity type.

3c.5 Agent Runtime and Sessions

3c.5.1 The Agent Runtime

An agent runtime is a locally executing process on the principal's machine that mediates between the agent and the principal's key material. The reference implementation is a Catalog MCP server — a Model Context Protocol server that exposes signing operations as tools — but the architecture supports any local process that satisfies the following properties:

1. Local execution. The runtime runs on the principal's machine or within the principal's trust boundary. Key material is passed to the runtime through a local IPC channel (standard input, Unix domain socket, or equivalent) — never over a network.
2. In‑memory key holding. The runtime holds the agent's private keys (signing key, msg_encrypt key, and any provisioned organization keys) in process memory for the duration of the session. Keys are never written to disk, localStorage, or any persistent store by the runtime in session mode. (Persistent mode stores keys encrypted on disk — see §3c.5.4.)
3. Operation exposure, not key exposure. The runtime exposes signing operations (sign_registration, sign_attribution) to the agent. It never exposes the private key itself. The agent calls a signing function and receives a signed manifest — it never sees or handles key material.
4. Scope enforcement. The runtime enforces the session scope configured by the principal (§3c.5.2). Out‑of‑scope requests are rejected by the runtime, regardless of what the agent requests.
5. Controlled lifetime. In session mode (§3c.5.3), the runtime destroys key material and terminates when the session ends. In persistent mode (§3c.5.4), the runtime runs continuously and key material is stored encrypted on disk, recoverable at restart through the no‑PIN device model (§3.4.4). In both modes, the principal can revoke the runtime at any time.

MCP server example. In the Claude integration use case, the Catalog MCP server exposes tools such as:

• catalog_registry_sign_registration({ asset_digest, asset_metadata }) → { signed_claim_manifest } — signs a registration claim with the agent's key.
• catalog_registry_sign_attribution({ asset_id, party_username, role }) → { signed_attribution_claim } — signs an attribution claim (only if the agent's key is published and the session scope permits it).
• catalog_agent_session_info() → { agent_username, principal_username, scopes, expires_at } — returns the current session's identity and constraints.

The agent (Claude) calls these tools through the standard MCP protocol. The signing happens inside the MCP server process. Claude never sees, requests, or receives private key material.

3c.5.2 Session Scope

Each agent session — whether session‑mode or persistent‑mode (§3c.5.4) — is configured by the principal with:

Available scopes:

The runtime enforces these constraints independently of the agent. A compromised or misbehaving agent cannot escalate its own permissions — the runtime checks every request against the session scope before executing.

3c.5.3 Session Mode

Session mode is the default operating mode for agent runtimes. The principal is present, starts the runtime for a specific task, and the runtime dies when the task is complete. This is the typical mode for interactive use — for example, a Claude Code session where the agent signs Asset Registry claims as part of a conversation.

1. PRINCIPAL authenticates to Catalog client (PIN / supersecret)
   └─ Client decrypts key bag, agent's signing key available in memory

2. PRINCIPAL starts agent session
   ├─ Client spawns agent runtime process (e.g., Catalog MCP server)
   ├─ Passes agent's private signing key via local IPC (stdin / Unix socket)
   ├─ Passes session config: { agent_username, scopes, expires_at, asset_filter }
   └─ Runtime holds key in memory, begins accepting tool calls

3. AGENT connects to runtime
   ├─ Calls session_info → learns its identity and scopes
   ├─ Calls signing operations → receives signed manifests
   └─ Never sees, requests, or receives private key material

4. SESSION ENDS (any of):
   ├─ expires_at reached → runtime self‑terminates
   ├─ Principal manually stops → runtime process killed
   ├─ Parent process exits → runtime dies with it
   └─ Key material: zeroed from process memory, gone

No key material survives between sessions. Each new session requires the principal to authenticate and explicitly start the runtime.

3c.5.4 Persistent Mode

Persistent mode is for agent runtimes that run continuously — at boot, as a system service, or as a long‑running daemon — responding to events without the principal being present. Use cases include:

• Chat participation. The agent maintains a WebSocket connection to the Catalog chat server, receives messages, generates responses through the principal's AI provider, and sends replies. The agent's username appears in chat like any other participant.
• Key management automation. The agent monitors delegate departures and automatically performs organization key rotation and chain flattening (§3a.5, §3a.3.1).
• Scheduled Asset Registry registration. The agent watches a directory for new files and registers them in Asset Registry on a schedule.
• File processing. The agent monitors upload queues and processes files (metadata extraction, format conversion, thumbnail generation).

Why persistent mode is needed. Session mode requires the principal to authenticate and start the runtime. A chat message may arrive at 3am. A delegate may leave the organization while the owner is offline. A file may be uploaded to a monitored folder overnight. These events require an agent runtime that is already running and authenticated, without waiting for the principal to interact.

Credential storage. A persistent‑mode runtime cannot prompt for a PIN or supersecret at startup. Instead, it combines the no‑PIN device model (§3.4.4) with a long‑lived refresh token obtained via the agent_delegation grant (§3c.5.5). The agent's keys are stored encrypted on disk using a deviceEncryptionKey held on the server; the refresh token is stored in plaintext alongside them. At startup, the runtime exchanges the refresh token for an access token (creating an authenticated session), then uses the session to retrieve the deviceEncryptionKey via the standard no‑PIN device unlock, and decrypts the keys into memory. This ensures that if the machine is compromised after the principal has revoked the refresh token, the attacker cannot obtain the deviceEncryptionKey and the encrypted keys on disk are inert.

The setup flow:

1. PRINCIPAL authenticates to Catalog client (PIN / supersecret)
   └─ Client decrypts key bag, all relevant keys available in memory
       (including agent keys stored in principal's key bag)

2. PRINCIPAL configures persistent agent
   ├─ Selects the agent identity to run in persistent mode
   ├─ Selects scopes and key material the agent needs
   ├─ Selects the machine where the runtime will run
   ├─ Obtains agent token via agent_delegation grant (§3c.5.5 path 1)
   │   └─ Catalog.ID issues agent access token + long‑lived refresh token
   └─ Client performs device setup for the runtime:
       ├─ Registers a device on the agent's account (no‑PIN mode)
       ├─ Generates a deviceEncryptionKey for the agent runtime
       ├─ Encrypts each required key (agent attr_encrypt, agent msg_encrypt,
       │   agent signing key, org keys — depending on scopes) with the deviceEncryptionKey
       ├─ Stores encrypted keys in the runtime's local storage
       │   (a dedicated directory on the target machine)
       ├─ Stores the refresh token in plaintext in the runtime's local storage
       ├─ Stores the device token in the runtime's local config
       └─ Sends the deviceEncryptionKey to the server, associated
           with the device token on the agent's account (no‑PIN mode)

3. RUNTIME STARTS (at boot, manually, or via service manager)
   ├─ Reads refresh token + device token from local storage
   ├─ Exchanges refresh token → fresh access token (authenticated session)
   ├─ Calls device unlock (no‑PIN) with device token
   │   └─ Server returns deviceEncryptionKey
   ├─ Runtime decrypts keys from local storage into memory
   ├─ Establishes connections:
   │   ├─ WebSocket to chat server (if chat scope)
   │   ├─ Event listeners for delegate changes (if org_key_rotation scope)
   │   └─ File system watchers (if file_upload scope)
   └─ Runtime is now active, responding to events

4. RUNTIME OPERATES (indefinitely)
   ├─ Chat: receives message → calls AI provider API → sends response
   ├─ Key rotation: delegate removed event → rotates org keys → distributes
   ├─ File registration: new file detected → signs Asset Registry claim → submits
   ├─ All actions logged under the agent's username
   └─ Runtime refreshes access token autonomously via refresh token grant

5. RUNTIME STOPS (any of):
   ├─ Principal manually stops the runtime
   ├─ Machine shuts down → runtime process dies
   ├─ expires_at reached (if configured) → runtime self‑terminates
   └─ Key material: zeroed from process memory
       (encrypted keys + refresh token remain in local storage for next start)

AI provider configuration. For agent runtimes that use AI capabilities (chat, intelligent file processing), the AI provider is configured by the principal — not by Catalog. The principal holds their own contract with one or more AI providers (e.g., Anthropic, OpenAI) and configures the runtime with the provider's API endpoint and credentials. The Catalog server is not involved in AI inference: it provides the chat transport (WebSocket), the event stream, and the identity layer; the runtime bridges these to the external AI provider on the principal's infrastructure.

Catalog chat server ◄──WebSocket──► Agent runtime (principal's machine)
                                         │
                                         ├── AI provider API (principal's contract)
                                         ├── Encrypted agent keys (local storage)
                                         ├── Refresh token (local storage)
                                         ├── Device token (local config)
                                         └── Session scope enforcement

Chat participation model. When a persistent‑mode agent participates in chat, it connects to the Catalog chat server via WebSocket using Authorization: Bearer {token}, the same mechanism as the desktop client (§3.4.5). The agent's username (qxmtbravkl) appears in the chat participant list and in message attribution. Other participants can see — from the all‑alphabetic username format — that they are interacting with an agent, and can look up the agent's principal through the immutable link. If chat messages are encrypted with msg_encrypt (§3.4.1), the runtime holds the agent's own msg_encrypt key (§3c.6a) to decrypt incoming messages and encrypt outgoing messages. Other participants encrypt messages to the agent using the agent's msg_encrypt public key — the same standard flow as messaging any other identity.

Group chat. An agent can participate in group chats the same way any other identity does. The principal (or an organization admin, if the principal is a delegate) adds the agent's username to the group. Messages sent by the agent are attributed to the agent's username. The agent's participation in a group is visible to all group members.

Security posture. A persistent‑mode runtime is a higher‑trust configuration than session mode. In session mode, key material exists in memory only while the principal is actively using the agent. In persistent mode, keys are stored encrypted on disk (protected by a deviceEncryptionKey held on the server) and a refresh token is stored in plaintext. The security boundary has two layers: the refresh token controls access to the deviceEncryptionKey, and the deviceEncryptionKey protects the keys at rest. If the machine is compromised while the refresh token is valid, the attacker can obtain the keys. If the refresh token has already been revoked, the encrypted keys on disk are inert. The security of the agent's key material depends on the security of the machine where the runtime runs, combined with the principal's ability to revoke the refresh token promptly if compromise is suspected. This is comparable to the no‑PIN device mode for personal identities (§3.4.4) — appropriate for machines under the principal's physical control.

Elevated trust: organization key material. For scopes that require organization key material (org_key_rotation, org_key_flattening), the persistent runtime holds wrapped copies of the organization's key chain — the same keys that a delegate with the owner role receives (§3a.4). Compromise of the machine means compromise of the organization's encryption keys. This is equivalent to the security exposure of an owner delegate's no‑PIN workstation. The principal must evaluate whether the operational benefit of automated key management justifies this trust level. The Organization Identity Agreement (§3a.10) should address the organization's policy on automated key management and the conditions under which persistent‑mode agents may hold organization keys.

Revocation. The principal has two independent kill switches for a persistent‑mode runtime: revoking the refresh token or deleting the device record. Either action is sufficient — without a valid refresh token the runtime cannot obtain an access token, and without an access token it cannot call device unlock to retrieve the deviceEncryptionKey. The encrypted keys on disk become inert. Both actions can be taken simultaneously for immediate, comprehensive revocation. In either case, the next time the runtime attempts to start or refresh, it fails and enters a degraded state.

3c.5.5 Authentication

An agent identity has no password and cannot authenticate through the standard username/password flow (§10). Instead, Catalog.ID provides three authentication paths for agents, each suited to a different deployment model. All three produce the same result: a standard Catalog.ID JWT with the agent's identity as the subject. Any service that accepts Catalog.ID authentication — catalog.org services, third‑party websites, or any other relying party — can accept agent tokens without modification.

Token model. Catalog.ID issues JWTs that carry the authenticated identity's username, permissions, and service routing information. Agent tokens follow the same structure as all other Catalog.ID tokens, with the agent's Catalog.ID as the subject and additional fields:

The Catalog.ID username is the primary identifier — the system uses usernames as primary keys, since they are system‑assigned, immutable, and never reassigned. No separate numeric ID is needed.

Any service that receives this token and checks CatalogID — whether for chat messages, file uploads, Asset Registry submissions, database modified_by fields, or any other operation — sees the agent's identity, not the principal's. The principal link is embedded in the token for audit and authorization purposes but does not replace the agent's identity in attribution. A relying service can inspect the IsHuman flag and PrincipalCatalogID to apply agent‑specific policies if it chooses, but is not required to — an agent token is a valid Catalog.ID token that identifies a valid Catalog.ID identity.

Authentication path 1: Delegation grant (session mode). For session‑mode runtimes (§3c.5.3) where the principal is present and starts the runtime interactively.

1. The principal authenticates normally (username/password → JWT).
2. The principal's client calls the Catalog.ID /token endpoint with grant type agent_delegation.
3. The request includes: the principal's valid access token (proving principal identity), the agent's Catalog.ID (identifying which agent), and the requested scopes.
4. Catalog.ID verifies:
   • The principal's token is valid.
   • The agent identity exists and is linked to this principal.
   • The requested scopes do not exceed the agent's configured permissions.
5. Catalog.ID issues a scoped JWT with the agent's Catalog.ID as the subject, the principal's Catalog.ID as the delegation source, and the approved scopes.
6. The client passes this agent token to the runtime via local IPC alongside the key material.
7. The runtime uses the agent token for all service connections — WebSocket, REST API, or any other protocol supported by the relying service.

The agent token has its own access token TTL and a refresh token. The runtime refreshes the token autonomously using the standard refresh token grant — no principal interaction is needed for token renewal during the session.

Authentication path 2: Stored refresh token (persistent mode). For persistent‑mode runtimes (§3c.5.4) that run on the principal's own infrastructure without the principal being present.

1. The principal authenticates and requests an agent token via the agent_delegation grant (same as path 1, steps 1–5).
2. Catalog.ID issues an agent access token and a long‑lived refresh token for the agent.
3. The principal's client stores the refresh token in plaintext in the runtime's local storage. The agent's keys are stored separately, encrypted with the deviceEncryptionKey (see §3c.5.4 setup flow). The refresh token is not encrypted — it is the bootstrap credential that the runtime uses to obtain an authenticated session, which is then used to retrieve the deviceEncryptionKey and decrypt the keys.
4. At runtime startup, the runtime exchanges the refresh token for a fresh access token via the standard refresh token grant. With the authenticated session, it calls device unlock (no‑PIN) to retrieve the deviceEncryptionKey, then decrypts the agent's keys from local storage into memory.
5. The runtime continues refreshing autonomously for as long as the refresh token remains valid.

The principal can revoke the persistent‑mode runtime through two independent mechanisms: revoking the refresh token (preventing new access tokens) or deleting the device record (preventing deviceEncryptionKey retrieval). Either action renders the encrypted keys on disk inert. See §3c.5.4 for the full security analysis.

Authentication path 3: API key (remote services). For third‑party services that run on external infrastructure — not the principal's machine — and need a standing credential to perform limited operations on the principal's behalf. This is analogous to exchange API keys (e.g., Kraken): a scoped key+secret pair that grants specific permissions without exposing the principal's credentials.

The principal creates an API key through the Catalog.ID account management interface:

1. The principal creates an agent identity for the service (if one does not already exist).
2. The principal generates a scoped API key pair for that agent:
   • Key: a public identifier (e.g., catalog_ak_7f3a9b2c4e...) — safe to store in configuration files and logs.
   • Secret: a private credential (e.g., catalog_sk_9d1e8f4a2b...) — displayed once at creation and never shown again. The principal must copy it immediately.
3. The principal selects the permissions for this key from the available scopes (§3c.5.2). Each permission can be individually enabled or disabled:
   • Read profile
   • Upload files
   • Sign Asset Registry registrations
   • Sign Asset Registry attributions
   • Send chat messages
   • Read chat messages
   • Key management
   • (additional scopes as the system evolves)
4. The principal optionally sets restrictions:
   • IP allowlist — the key can only be used from specified IP addresses or CIDR ranges.
   • Expiry — the key automatically becomes invalid after a specified date.
   • Rate limit — maximum operations per time period, independent of any server‑side rate limits.
5. The principal gives the key and secret to the third‑party service.

The service authenticates directly against Catalog.ID:

POST /token
grant_type=api_key
key=catalog_ak_7f3a9b2c4e...
secret=catalog_sk_9d1e8f4a2b...

Catalog.ID verifies the key and secret, checks IP allowlist and expiry if configured, and issues a standard agent JWT — the same token structure as paths 1 and 2. The service uses this token for all subsequent API calls until it expires, then authenticates again with the key and secret to obtain a new token.

API key management. The principal manages API keys through the Catalog.ID account management interface:

• Multiple keys per agent. A single agent identity can have multiple API keys — for example, one key for a production service and one for a staging environment, with different IP allowlists. Each key has independent permissions, restrictions, and revocation status.
• Multiple agents per service. A principal may create separate agent identities for different services, each with its own API key and scoped permissions. This provides per‑service attribution in modified_by fields.
• Revocation. The principal can revoke any API key at any time. Revocation is immediate — the next authentication attempt with the revoked key fails. Tokens already issued from the revoked key remain valid until their TTL expires (short‑lived by design), or the principal can force‑revoke all active tokens for an agent.
• Key rotation. The principal can generate a new key+secret pair for the same agent without revoking the old key, allowing a graceful migration period where both keys are valid. Once the service has been updated, the old key is revoked.
• Audit log. Every authentication and operation performed with an API key is logged against the agent's Catalog.ID. The principal can review the agent's activity history.

Comparison of authentication paths:

Note that API keys provide authentication and authorization but not access to cryptographic key material. A third‑party service authenticated via API key can perform operations permitted by its scopes (upload files, send chat messages, read profiles), but cannot sign Asset Registry claims directly — signing requires the agent's private key, which is held in the principal's key bag and is only available through the runtime (paths 1 and 2). If a third‑party service needs to submit signed Asset Registry claims, the principal must either run a persistent‑mode runtime that performs the signing locally and submits the signed manifests through the API, or provision the agent's signing key to the service through a secure out‑of‑band channel — accepting the risk that the key material now resides on external infrastructure.

Token refresh cycle. In all three paths, token lifecycle follows the same pattern:

Service/runtime starts
 └─ Has access token, refresh token, or API key
     └─ Access token valid → use for service calls
     └─ Access token expired or near expiry →
         ├─ Paths 1–2: exchange refresh token → new access token
         ├─ Path 3: re‑authenticate with API key+secret → new access token
         └─ Authentication fails → cannot proceed
             ├─ Session mode: session ends, principal must restart
             ├─ Persistent mode: runtime enters degraded state
             └─ API key: service reports auth failure to its operator

Relying service compatibility. Any service that accepts Catalog.ID authentication works with agent tokens without modification, regardless of which authentication path produced the token. The token is a standard Catalog.ID JWT — the service validates the signature, extracts the identity, and proceeds. The agent's all‑alphabetic username format (§3c.2) allows a relying service to recognize agent identities at a glance, but this is a convenience — the IsHuman flag in the token is the authoritative indicator. Services may choose to:

• Treat agent tokens identically to human tokens (simplest — works by default).
• Apply agent‑specific rate limits or content policies based on the IsHuman flag.
• Display the principal's identity alongside the agent's in UI (using PrincipalCatalogID).
• Restrict certain operations to human‑only tokens (e.g., administrative actions).

These are policy decisions for each relying service, not requirements imposed by Catalog.ID.

3c.6 Asset Registry Signing Key

An agent identity has a single Asset Registry signing key, following the same cryptographic model as personal and delegate identities (§3.4.1a) but with principal‑custodied storage:

Why the agent's key is in the principal's key bag. Personal and delegate Asset Registry signing keys are machine‑local because the identity holder has a machine — a persistent device with storage. An agent has no independent machine or key custody. In session mode (§3c.5.3), the runtime holds the key in memory only during a session. In persistent mode (§3c.5.4), the key is stored encrypted in the runtime's local storage, decryptable only with the deviceEncryptionKey held by the server. In both cases, the authoritative store for the agent's key is the principal's key bag — the principal is the custodian of the agent's cryptographic identity, and the runtime's copy is a distribution mechanism, analogous to how wrapped organization keys on delegate identities are a distribution mechanism for daily use (§3a.3).

Key generation. The principal generates the agent's ML‑DSA‑65 keypair on their own machine. The private key is added to the principal's key bag as an agent_signing_key entry (tagged with the agent's username). The public key is registered as a registry_signing_key claim on the agent identity, following the standard claim creation flow (§4.1) — encrypted with the agent's own attr_encrypt key (§3c.6b). This follows the same pattern as all other identity types: claims are encrypted with the account owner's attr_encrypt key. The principal can decrypt because they hold the agent's attr_encrypt private key in their key bag.

Public vs. anonymous. The same model as §3.4.1a applies. The agent's registry_signing_key claim is anonymous by default (encrypted, not publicly linkable to the agent's username). To make it public — enabling the agent to sign attribution claims — the principal publishes the claim through the standard public claims flow (§4.5). The principal decides whether the agent's key is public or anonymous; the agent cannot change this.

Resolution chain. When an agent's Asset Registry signing key is published, a verifier resolving the key can determine:

1. The signing key belongs to agent qxmtbravkl.
2. Agent qxmtbravkl is linked to principal khu3758iop (personal) or ab12cd34fg (delegate).
3. If the principal is a delegate, the delegate is linked to organization 123abcd456.

This provides full attribution traceability: signing key → agent → principal → (organization).

Revocation. The principal can revoke the agent's registry_signing_key claim at any time. Revocation sets revoked_at on the claim; Asset Registry nodes reject any new claims signed by the revoked key after that time. Historical claims signed before revoked_at remain valid. The principal generates a new keypair if the agent needs to resume signing.

Unpublication and auto‑muting. If the principal unpublishes the agent's Asset Registry signing key, the same auto‑muting mechanism applies as for personal and delegate keys (§4.4.2): all Asset Registry attribution claims signed by the agent's key are automatically muted by Asset Registry nodes. Republishing reverses the muting.

3c.6a Agent msg_encrypt Key

An agent identity has its own msg_encrypt keypair (ML‑KEM‑1024), following the same principal‑custodied model as the Asset Registry signing key (§3c.6):

• Generated by the principal, on the principal's machine.
• Private key stored in the principal's key bag, as an agent_msg_encrypt entry tagged with the agent's username.
• Public key registered on the agent's account in accountpublickey, so that other identities can encrypt messages to the agent using the standard protocol.

This gives the agent its own messaging identity. When another identity sends an encrypted message to the agent, they encrypt with the agent's msg_encrypt public key — not the principal's. The principal (or the agent runtime) decrypts using the agent's private key from the principal's key bag.

Without a dedicated msg_encrypt key, senders would need to know that messages addressed to an agent should be encrypted with the principal's key — breaking the uniform "look up the recipient's public key and encrypt" model that every other identity type follows. The agent's own msg_encrypt key eliminates this special case.

The msg_encrypt key is specifically for external messaging systems that integrate with Catalog.ID — the same purpose it serves for personal and delegate identities (§3.4.1).

3c.6b Agent attr_encrypt Key

An agent identity has its own attr_encrypt keypair (ML‑KEM‑1024), following the same principal‑custodied model as the Asset Registry signing key (§3c.6) and msg_encrypt key (§3c.6a):

• Generated by the principal, on the principal's machine, during agent identity creation.
• Private key stored in the principal's key bag, as an agent_attr_encrypt entry tagged with the agent's username.
• Public key registered on the agent's account in accountpublickey, so that the standard claim model works uniformly.

This gives the agent full compatibility with the standard claim lifecycle (§4):

• Claim creation. Claims on the agent identity are encrypted with the agent's own attr_encrypt key — the same flow as any other identity. The claimkey row with recipienttype = 'self' points to the agent's account with the agent's key. No special case.
• Claim sharing. Other identities can share claims with the agent by encrypting the claim's symmetric key with the agent's attr_encrypt public key — the standard sharing protocol (§4.2). The principal decrypts using the agent's private key from their key bag.
• Key lookup uniformity. Every identity type has attr_encrypt in accountpublickey. Sharing flows, validator integration, and operator claim review all use the same code path regardless of identity type.

Together, the three keys — attr_encrypt, msg_encrypt, and registry_signing_key — make the agent structurally identical to other identity types for all key lookups, claim operations, and sharing flows. The agent differs only in key custody (principal‑held, no key bag on the server) and lifecycle control (principal‑managed, no self‑registration).

3c.7 Claims on Agent Identities

Agent identities have a minimal set of claims, all encrypted with the agent's own attr_encrypt key (§3c.6b). The private key is held in the principal's key bag — the principal is the sole party that can decrypt and manage the agent's claims:

• registry_signing_key — the agent's Asset Registry signing public key (§3c.6). Encrypted by default; publishable at the principal's discretion.
• label — human‑readable name (e.g., "Claude — overnight batch registration"). Stored as an encrypted claim; may be published.
• agent_type — ai_model, automation, or human_operator. Stored as an encrypted claim; may be published.

The principal manages all claims on the agent identity through the standard claim lifecycle (§4), using the agent's attr_encrypt key for encryption (the principal holds the private key in their key bag). The agent cannot create, modify, or share claims.

Public claims. The following claim types are eligible for public publication on agent identities:

• label — the agent's public‑facing name
• agent_type — the agent's type (ai_model, automation, human_operator)
• registry_signing_key — the agent's Asset Registry signing public key (enables direct key‑to‑agent‑username resolution)

Publication follows the standard flow (§4.5.3), initiated by the principal.

3c.8 Agent Identities and Delegate Principals

When the principal is a delegate identity, the agent identity is transitively associated with the delegate's organization:

• Creation. A delegate identity with any role can create agent identities under its own username. The agent is linked to the delegate, not directly to the organization.
• Resolution. The chain is: agent → delegate → organization. A verifier can determine the full organizational context.
• Departure. When a delegate identity is terminated (§3b.3), all agent identities linked to that delegate are also terminated. Agent usernames are permanently retired. The delegate's departure triggers key rotation for organization keys (§3a.5) as usual — agent identities do not hold organization keys, so they are not affected by the rotation itself, only by the cascade termination of their principal.
• Organization audit. An organization's owner or admin can audit agent activity by tracing: agent signing key → agent username → delegate username → organization. The same audit trail mechanism as §3a.8.2 applies, extended by one link.

3c.9 Retirement

Agent identity usernames follow the same permanent retirement policy as personal, organization, and delegate usernames: on termination, the username is permanently retired and never reassigned. Historical Asset Registry claims, modified_by records, and cryptographic signatures remain attributed to the retired username.

The immutable principal link persists in the retired record — verifiers can always determine which principal the agent belonged to, even after retirement.

3c.10 Legal Framework

Agent identities do not independently accept any legal agreement. The principal's acceptance of the applicable terms covers the agent's actions:

• Personal principal. If the principal is a personal identity, the Catalog.ID Membership Agreement governs the agent's actions. The member is responsible for all claims submitted by their agent identities.
• Delegate principal. If the principal is a delegate identity, the Organization Identity Agreement governs the agent's actions. The delegate identity (and through it, the organization's owner delegate identities) is responsible for all claims submitted by the agent.

Asset Registry Terms. Claims submitted to Asset Registry by an agent identity are submitted under the authority of the agent's principal. The principal is responsible for all representations and warranties in the Asset Registry Terms (§5.3) with respect to agent‑submitted claims. The agent identity does not independently satisfy the eligibility requirements of §5 — the principal's eligibility and acceptance cover the agent's use of the Service.

Disputes. Disputes involving an agent identity are disputes with its principal. If the principal is a delegate, disputes escalate to the organization's owner delegate identities (same as §3b.9).

No separate agreement. Unlike organization identities (which have the Organization Identity Agreement) and delegate identities (which accept employee terms at activation), agent identities require no separate legal instrument. The principal creates the agent within the scope of their existing agreement, and the principal's responsibilities extend to the agent's actions automatically.

4. Claim Lifecycle

4.1 Claim Creation

A claim is any attribute the user wishes to add to their identity. Examples:

• Email address
• Telephone number
• Postal address
• Real name / date of birth
• Bank account details
• Freeform information

For each new claim:

1. The browser generates a random symmetric key.
2. Encrypts the claim locally with this key.
3. Destroys the plaintext.
4. Encrypts the symmetric key with the user’s own attr_encrypt public key.
5. Uploads the encrypted claim and encrypted key to the server.

This ensures that even the server cannot decrypt user claims.

4.2 Claim Sharing

Users may choose to securely share claims with trusted contacts:

1. The encrypted claim‑key is downloaded.
2. The user decrypts it locally.
3. Re‑encrypts it using the recipient’s attr_encrypt public key.
4. Uploads the re‑encrypted key for the recipient.

Catalog.ID acts as a storage and forwarding layer only; it cannot see or modify the data.

4.3 Claim Validation

Certain claims (email, phone, address, domain, bank account) can be validated. To validate a claim, the user chooses to share the claim’s key with the Validator Black Box. Only then can validation occur.

4.4 Asset Registry Integration Claims

4.4.1 Asset Registry Signing Key Claims

A member may have multiple registry_signing_key claims — one per machine on which the Catalog software is installed (see §3.4.1a). Each claim stores the public key of a per‑machine Asset Registry signing keypair. Like all claims, the key is encrypted end‑to‑end and stored as ciphertext on the core server. The private key remains machine‑local and is never uploaded.

Each registry_signing_key claim carries a user‑configurable label (e.g., "Studio workstation") and system‑assigned metadata including registration time and revocation status (see §3.4.1a for the full metadata table).

Anonymous keys (default). An unpublished registry_signing_key claim is anonymous: the public key is encrypted and not linkable to the member's username by anyone who has not been granted access to the claim. When a member shares an anonymous registry_signing_key claim with another member via the standard key‑sharing protocol, the recipient can match that key against Asset Registry provenance claims — linking an otherwise anonymous Asset Registry record to a known identity. This enables privacy‑preserving provenance verification without public exposure.

Public keys. A member who wants their Asset Registry signing key to be publicly linkable to their username — enabling the key to sign attribution claims — publishes the registry_signing_key claim through the standard public claims flow (§4.5). Publication is validated through key ownership proof (§7.6). The public/anonymous distinction is not a type flag; it is simply whether the claim has been published. If a member unpublishes a previously public key, all Asset Registry attribution claims signed by that key are automatically muted by Asset Registry nodes (see Asset Registry Whitepaper §7.6.5). Republishing the key reverses the muting.

Revocation. A member can revoke any registry_signing_key claim at any time (e.g., if the machine is lost or compromised). Revocation sets a revoked_at timestamp on the claim; Asset Registry nodes reject any new claims signed by the revoked key after that time. If the claim was published, the public profile reflects the revocation. The encrypted claim remains on the account for historical verification of past Asset Registry claims.

4.4.2 Public Attribution via Asset Registry Attribution Claims

Asset Registry attribution claims identify parties by their Catalog.ID usernames with industry‑specific roles. Each attribution is a separate signed claim referencing an asset. This provides public, autonomous attribution: anyone who looks up a Asset Registry record can see which Catalog.ID usernames are associated with a work and in what capacity.

Attribution claims must be signed with a published (non‑anonymous) Asset Registry signing key. The Asset Registry node verifies at submission time that the signing key matches a published, non‑revoked registry_signing_key claim on the claimant's Catalog.ID account. This ensures that every attribution is cryptographically linked to a verifiable Catalog.ID username.

An attribution claim must include both the party username (the person being attributed) and is signed by the claimant (whose username is resolved from the signing key's published claim). The Asset Registry node verifies that the signing key belongs to the claimant.

Unpublication and auto‑muting. A member may unpublish their Asset Registry signing key at any time, returning it to anonymous status. When a key is unpublished, Asset Registry nodes automatically mute all attribution claims signed by that key (see Asset Registry Whitepaper §7.6.5). Republishing the key reverses the muting. This provides a non‑destructive way to temporarily suppress attributions without revoking the key.

Registration claims do not require identity verification. Any key — whether linked to a Catalog.ID account or not — may sign a registration claim, as long as the submitter makes the required BIT payment (see Bitcash Whitepaper). This makes Asset Registry accessible to non‑Catalog.ID users and allows anonymous file registration.

The Catalog.ID username (e.g. khu3758iop) is a pseudonymous identifier — it does not reveal personal information by itself. A member who wants to reveal the personal identity behind their username can do so through the standard encrypted sharing protocol, at their own discretion.

This model serves two complementary paths:

• Public attribution: Catalog.ID usernames are identified as parties in Asset Registry attribution claims, signed by published keys. Anyone can see that username khu3758iop is the photographer of a registered work. No cooperation from the member is needed at lookup time.
• Private identity verification: A member shares an anonymous registry_signing_key claim to prove they control the key that signed specific Asset Registry claims. This adds selective private disclosure on top of public attribution.

4.4.3 Two‑Sided Attribution

When a member is identified as a party in a Asset Registry attribution claim, they can submit their own attribution claim confirming or adjusting their roles — using any of their own published Asset Registry signing keys. When both the original claimant and the party have submitted matching attributions, the result is a mutual attribution — the strongest form of agreed participation. The binding between a Asset Registry signing key and a Catalog.ID username is verifiable because the key is published as a public claim on the member's profile, validated through key ownership proof (§7.6).

4.5 Public Claims

4.5.1 Purpose

By default, all Catalog.ID claims are encrypted end‑to‑end — the core server never sees plaintext. This guarantees privacy but means that a Catalog.ID username is opaque to the outside world: no one can resolve it to a name, role, or professional identity without the member's active cooperation.

For members who want public attribution — particularly creative professionals whose work is registered in Asset Registry — this opacity is a limitation. They want the world to know that username khu3758iop is "John Doe, Photographer" without relying on external websites that may disappear over decades.

Public claims address this by allowing a member to publish selected attributes through an Operator‑validated process, creating a durable, system‑hosted public profile attached to their username.

4.5.2 Design Principles

1. Derived from encrypted claims: A public claim is always derived from an existing encrypted claim. The member shares the encrypted claim with the Operator through the standard sharing protocol (§4.2), then requests publication. The encrypted original remains untouched.
2. Operator‑validated: No public claim is published without validation by the Catalog.ID Operator. The Operator exercises editorial discretion — reviewing the shared claim data, applying the validation procedure appropriate for the claim type, and deciding whether to approve publication. Depending on the claim type and Operator policy, vouching from established members may be required (§4.5.5).
3. Signed by the Operator: The published version is signed by the Operator, attesting that the claim was reviewed and validated. The publication is an Operator act — analogous to a professional directory publisher accepting an entry — not a raw member upload.
4. Mutable: Public claims can be updated or deleted at any time by the member. Updates follow the same validation process. Deletion is immediate.
5. Separate from the encrypted claim: The public claim is an independent object. Publishing does not decrypt, expose, or modify the underlying encrypted claim.

4.5.3 Publication Flow

The publication flow applies to both personal and organization identities. For organization identities, a delegate with admin or owner role initiates the flow on behalf of the organization.

1. The identity has an existing encrypted claim (e.g., a display_name claim containing "John Doe" for a personal identity, or "Acme Studios" for an organization identity).
2. The claim is shared with the Catalog.ID Operator using the standard encrypted sharing protocol (§4.2). The Operator's client decrypts the claim.
3. A publication request is submitted for this claim.
4. The Operator reviews the claim content and applies the validation procedure appropriate for the claim type (§4.5.6).
5. If the Operator's policy requires vouching (§4.5.5), the claim is shared with the required number of vouching members, who submit signed vouching statements to the Operator.
6. Upon sufficient validation, the Operator publishes the claim: creating a plaintext public record signed by the Operator and associated with the identity's username.
7. The public claim becomes visible to anyone who queries the identity's public profile.

If the Operator rejects the publication request, the requestor is notified with the reason and may resubmit. The encrypted original claim is unaffected regardless of the outcome.

4.5.4 Public Claim Types

Personal identities — the following claim types are eligible for public publication:

• display_name — the member's public‑facing name or professional pseudonym
• professional_role — professional role or title (e.g., "photographer", "composer")
• organization — affiliated organization, studio, or label
• website — personal or professional URL
• location — general location (city, country — not a full postal address)
• registry_signing_key — the member's Asset Registry signing public key (enables direct key‑to‑username resolution without the encrypted sharing protocol)
• email — professional or public contact email
• phone — professional or public contact telephone
• biography — a short professional biography (structured text, max 500 characters)

The following claim types are not eligible for public publication on personal identities and must remain private (encrypted):

• postal_address — use the encrypted sharing protocol
• bank_account — use the encrypted sharing protocol
• date_of_birth — use the encrypted sharing protocol

This restriction protects natural persons from publishing sensitive financial or location information in a publicly queryable store.

Organization identities — the following claim types are eligible for public publication:

• display_name — the organization's public‑facing name (e.g., "Acme Studios")
• description — a short organizational description (structured text, max 500 characters)
• domain — the organization's validated domain name (§3a.6). Publication is mandatory — the domain claim must be public so that the organization's web presence is discoverable from its username.
• website — additional organizational URL (e.g., a sub‑site, landing page, or social presence distinct from the primary domain)
• location — general location (city, country)
• email — organizational contact email
• phone — organizational contact telephone
• postal_address — organizational business address
  Unlike personal identities, organizations may — and in some jurisdictions are legally required to — publish contact information. The Operator may require publication of certain claims (e.g., postal_address, email) as a condition of maintaining an active organization identity, depending on the applicable legal framework.

The following claim types are not eligible for public publication on organization identities:

• bank_account — use the encrypted sharing protocol

Delegate identities — the following claim types are eligible for public publication:

• display_name — the employee's public‑facing name or professional pseudonym
• professional_role — the employee's role within the organization (e.g., "Studio Manager", "Content Editor")
• organization_name — the organization's public‑facing name (derived from the immutable organization link)
• website — professional URL
• location — general location (city, country)
• email — professional contact email
• phone — professional contact telephone
• registry_signing_key — the delegate identity's Asset Registry signing public key. Anonymous by default, published at the employee's discretion. When published, the organization is also discoverable through the immutable organization link (§3a.8).
• biography — a short professional biography (structured text, max 500 characters)

The following claim types are not eligible for public publication on delegate identities:

• postal_address — use the encrypted sharing protocol
• bank_account — use the encrypted sharing protocol
• date_of_birth — use the encrypted sharing protocol

4.5.5 Vouching by Established Members

The Operator may require that one or more existing members with validated public profiles vouch for the accuracy of a new publication request. This creates a web‑of‑trust model for public claims:

• Established members are members who already have at least one validated public claim. Their own public profile has been through the validation process, giving them standing to vouch for others.
• The Operator determines the number of vouchers required (e.g., one, two, or three) based on the claim type and the Operator's current policy.
• To vouch, the member requesting publication shares the encrypted claim with each vouching member using the standard sharing protocol. Each voucher reviews the claim content and, if satisfied, submits a signed vouching statement to the Operator.
• The Operator verifies the vouching statements and, together with its own review, decides whether to approve publication.

The vouching requirement:

• Distributes the validation workload — established members share responsibility for maintaining profile quality.
• Creates social accountability — vouchers stake their reputation on the accuracy of the claims they endorse.
• Bootstraps naturally — the first members are validated by the Operator alone. As the community grows, the Operator can require vouching for new publications, building an organic trust network.
• Is optional per policy — the Operator may waive vouching for claim types that are verifiable through purely technical means (e.g., registry_signing_key via key ownership proof, website via domain verification).

4.5.6 Validation by Claim Type

Personal identity claims:

• display_name: The Operator verifies the name against the member's identity evidence. The Validator Black Box may be involved: the member shares their name claim with the validator, which confirms it matches a verified identity document. Vouching is typically required.
• professional_role: Self‑declared by the member. The Operator reviews for plausibility and policy compliance. Vouching may be required.
• organization: The Operator may request evidence of affiliation (e.g., a domain‑based email, a letter from the organization, or vouching from another Catalog.ID member representing the organization).
• website: Validated through the existing domain ownership flow (§7.5) — the member places a verification token at .well-known/catalogid.txt. Vouching is typically not required.
• location: Self‑declared by the member. The Operator reviews for plausibility. The Validator Black Box postal validation flow (§7.3) may be used for stronger verification.
• email: Validated through the standard email validation flow (§7.1).
• phone: Validated through the standard SMS validation flow (§7.2).
• registry_signing_key: Validated through the existing key ownership proof (§7.6) — a purely cryptographic challenge‑response flow. Vouching is not required.
• biography: Reviewed by the Operator for policy compliance. Vouching may be required.

Organization identity claims:

• display_name: The Operator verifies the organization name against public records, registration documents, or other evidence provided by the founding delegate identity. Vouching from established members may be required.
• description: Reviewed by the Operator for policy compliance and plausibility.
• location: The Operator may verify the address through the Validator Black Box postal validation flow (§7.3) or against public business registration records. In jurisdictions that require organizations to publish a business address, the Operator may require this claim to be published as a condition of maintaining an active organization identity.
• domain: Validated through the standard domain ownership flow (§7.5) — see §3a.6. Publication is mandatory.
• website: Validated through the domain ownership flow (§7.5), same as for personal identities.
• email: Validated through the standard email validation flow (§7.1). The Operator verifies that the email domain matches or is associated with the organization's validated domain claim.
• phone: Validated through the standard SMS validation flow (§7.2).
• postal_address: Validated through the Validator Black Box postal validation flow (§7.3) or against public business registration records.

Delegate identity claims:

• display_name: The Operator verifies the name against the employee's identity evidence, same as personal identities.
• professional_role: Self‑declared by the employee or set by the organization. The Operator reviews for plausibility.
• organization_name: Derived from the immutable organization link — no separate validation is needed.
• website: Validated through the domain ownership flow (§7.5), same as for personal identities.
• location: Self‑declared by the employee. The Operator reviews for plausibility.
• email: Validated through the standard email validation flow (§7.1).
• phone: Validated through the standard SMS validation flow (§7.2).
• registry_signing_key: Validated through key ownership proof (§7.6), same as for personal identities.
• biography: Reviewed by the Operator for policy compliance.

The Operator may adjust validation requirements over time as the community and its needs evolve.

4.5.7 Public Profile Resolution

Anyone may query a Catalog.ID username and receive the member's public profile — the set of all validated public claims. This provides a durable resolution path:

Personal identity example:

1. A Asset Registry attribution claim identifies username khu3758iop as a party.
2. A verifier queries Catalog.ID for the public profile of khu3758iop.
3. The response includes: display name "John Doe", role "Photographer", website "johndoe.com" — all validated and signed by the Operator.

Organization identity example:

1. A Asset Registry attribution claim identifies username 482mxvt719 as a party.
2. A verifier queries Catalog.ID for the public profile of 482mxvt719.
3. The response includes: display name "Acme Studios", domain "acmestudios.com", location "Amsterdam, Netherlands", contact email — all validated and signed by the Operator.

Delegate identity example:

1. A Asset Registry attribution claim identifies username e3k7m2p9a1 as a party.
2. A verifier queries Catalog.ID for the public profile of e3k7m2p9a1.
3. The response includes: display name "Jane Smith", role "Studio Manager", organization "Acme Studios" (derived from the immutable organization link to 482mxvt719) — all validated and signed by the Operator.
4. The verifier can follow the organization link to resolve the full organization profile if needed.

Each public claim in the response carries the Operator's signature, allowing the verifier to confirm that the attribute has been validated. This resolution works without cooperation from the identity holder at query time, providing the same convenience as voluntary de‑anonymization on external websites but with the durability, cryptographic authenticity, and Operator validation of the Catalog.ID system.

5. Trust and Verification Model

Claims are not treated as facts but as assertions. Trust in a claim increases when:

• Another user confirms it.
• A user you trust confirms it.
• The Validator Black Box cryptographically verifies it.

Catalog.ID establishes a decentralized trust graph:

• Users may express positive trust.
• Users may express negative trust.
• Each client independently resolves trust relationships.
• Verified claims display checkmarks according to the viewer’s own trust graph.
• Validation certificates that have expired (§8.1) are not counted as active verifications.

No central authority dictates truth—verification and trust are user‑driven.

6. Validator Black Box

The Validator Black Box is the only subsystem permitted to view plaintext claims, and only after receiving encrypted claim access from the user.

6.1 Isolation

It runs on a dedicated machine or virtual instance:

• Separate storage
• Separate network interface
• Minimal exposed attack surface (HTTPS + SMTP only)
• Strict key isolation

6.2 Responsibilities

1. Decrypting claims shared directly with it.

2. Sending validation messages:

   • Email (with verification link)
   • SMS
   • Postal letter
   • Bank micro‑transaction
   • Domain fetch

3. Hosting verification endpoints.

4. Issuing signed validation certificates.

5. Maintaining no persistent plaintext data.

6.3 Privacy Guarantee

Even if the Catalog.ID core server is compromised, the attacker:

• Cannot read claims
• Cannot validate claims
• Cannot forge validation certificates
• Cannot associate accounts with email addresses or phone numbers

7. Validation Flows

7.1 Email Validation

1. Claim is encrypted and stored on Catalog.ID.
2. User requests email validation.
3. Validator Box receives encrypted claim materials.
4. Validator decrypts the email.
5. Sends a verification link via authenticated SMTP.
6. User clicks the link.
7. Validator issues a signed certificate confirming control.

7.2 SMS Validation

Similar to email, except via numeric code sent via SMS provider.

7.3 Postal Address Validation

Validator generates a physical letter with a code.

7.4 Bank Account Validation

Validator sends a micro‑payment with a verification code.

7.5 Domain Ownership

Validator fetches .well-known/catalogid.txt.

7.6 Asset Registry Key Ownership Validation

A member may request validation of any of their registry_signing_key claims to prove they control the corresponding private key. Because Asset Registry signing keys are machine‑local (§3.4.1a), the validation challenge must be signed on the machine that holds the private key:

1. User requests key ownership validation for a specific registry_signing_key claim.
2. Validator Box receives the encrypted claim materials.
3. Validator decrypts the Asset Registry public key.
4. Validator generates a random challenge.
5. Challenge is sent to the user's client (via the core server proxy).
6. Client signs the challenge with the machine‑local Asset Registry private key.
7. Validator verifies the signature against the decrypted public key.
8. Validator issues a signed certificate confirming key ownership for that specific claim.
9. Validator purges the decrypted key material.

This flow is purely cryptographic — no external communication (email, SMS, etc.) is required. The validator never learns what Asset Registry claims the key has been used for. Each registry_signing_key claim is validated independently; validating one key does not validate another.

All successful validations result in signed certificates.

8. Cryptographic Certificates

Each verified claim is accompanied by a certificate:

{
  account_id: ...,
  claim_id: ...,
  validator_id: ...,
  method: "email" | "sms" | ...,
  timestamp: ...,
  expires_at: ...,
  signature: <validator_private_key_signature>
}

Users’ browsers verify certificates using the validator’s public key.
The server cannot forge certificates.

8.1 Certificate Expiry

Validation certificates carry an expires_at timestamp. Once expired, the certificate is no longer treated as active — the claim reverts to an unvalidated state until the member completes revalidation.

Expiry exists because control over external resources changes over time: email addresses change hands, phone numbers are reassigned by carriers, domains transfer ownership, and bank accounts close. A certificate that never expires would permanently attest to control that may no longer exist.

Validity periods are set per claim type:

Asset Registry key ownership certificates do not expire because they attest to control of a cryptographic private key, which does not change hands through external administrative processes. If a member loses control of their key, they can revoke the associated claim.

The Operator may adjust these periods over time as the member community and its needs evolve.

8.2 Revalidation

The client application checks certificate expiry dates locally and surfaces a revalidation prompt within the UI when a certificate is approaching or has passed its expiry. The member may then initiate revalidation through the same flow used for initial validation (§7). Revalidation produces a new certificate with a fresh timestamp and expires_at.

Expired certificates are retained for historical record but are clearly marked as inactive. Relying parties (including the trust graph) must treat expired certificates as absent when evaluating current claim status.

9. Security Properties

9.1 Confidentiality

• Claims are encrypted end‑to‑end.
• Only users and explicit recipients can decrypt.
• Validator Box sees plaintext only when necessary.

9.2 Integrity

• Validation certificates are cryptographically signed.
• Malicious servers cannot impersonate validators.

9.3 Privacy

• Catalog.ID cannot read user attributes.
• Catalog.ID cannot correlate identities with private data.
• Attackers gain no sensitive data even if catalog.ID is breached.

9.4 User Sovereignty

• Users decide what to share, with whom, and for how long.
• Claims can be revoked at any moment.
• Trust is decentralized and user‑determined.

9a. Data Protection and the Right to Erasure

9a.1 Usernames and GDPR classification

A Catalog.ID username is a pseudonymous identifier by design (GDPR Article 4(5)):

1. Sequentially assigned, deterministically encoded: Usernames are compact encodings of internal sequence numbers with no semantic link to the person. The member does not choose the username — it is derived from the next available integer in the sequence.
2. No re-identification from private claims: The Catalog.ID core server itself cannot decrypt member claims. The mapping from username to personal data is encrypted end-to-end and exists only in the member's own client.
3. Active cooperation required for private claims: Re-identification from private claims requires the member to actively share them through the encrypted sharing protocol.

However, the pseudonymity analysis changes when a member activates public claims (§4.5). Public claims are stored in cleartext and queryable by anyone who looks up the username. When a member has published a display name, professional role, or other identifying attributes, the username is directly identifying — it can be resolved to a named person through a public API without any cooperation from the member at query time.

The data protection classification of a username therefore depends on the member's choices:

• No public claims: The username is pseudonymous. Re-identification requires the member's active cooperation or access to external sources outside Catalog.ID's control.
• Public claims active: The username is directly identifying via Catalog.ID's own public profile resolution. It constitutes personal data in the full sense of GDPR Article 4(1).
• After account termination: Encrypted claims are destroyed. If the member deleted their public claims before or during termination, the username resolves to nothing and is effectively de-identified. If public claims were not deleted, they persist under the perpetual publication license granted by the member (see Catalog.ID Membership Agreement §9.12) and the username remains identifying. A living ex-member may still request deletion of their public claims at any time (§9.13). (See §9a.3.)

9a.2 Voluntary de-anonymization

A member may make their username identifying through two paths:

1. Public claims (system-internal): The member publishes public claims through Catalog.ID (§4.5), creating an Operator-validated public profile. This is a deliberate act: the member initiates the publication flow, the Operator exercises editorial discretion in validating and signing the claim, and the result is a cleartext record served by Catalog.ID's own API. The Operator acts as an independent controller (publisher) for the publication — see §9a.5 for the full data protection analysis.
2. External disclosure: The member publishes "khu3758iop is John Doe" on a personal website, social media, or professional portfolio. Catalog.ID did not create, store, or publish this link — the member's own voluntary action outside the system created it.

In both cases, the member initiated the de-anonymization. The distinction matters because:

• In the public claims case, Catalog.ID hosts the resolution path. The username is personal data within Catalog.ID's own processing. Catalog.ID's data protection obligations are clear: the member consents to publication, the Operator publishes under its own legitimate interest in maintaining a trustworthy directory (see §9a.5), the member can delete the public claim at any time, and the member can delete the public claim at any time during their lifetime, including after account termination (see Catalog.ID Membership Agreement §9.13).
• In the external disclosure case, the resolution path is outside Catalog.ID's control. Catalog.ID is not the controller of the external publication. The username remains pseudonymous within Catalog.ID's own systems (assuming no public claims are active).

The username remains the Developer's infrastructure regardless of de-anonymization (see §3.1). It is sublicensed to the Operator and member, and is permanently retired after account termination. The infrastructure-ownership framing does not alter the data protection classification: when the username is identifying (whether through public claims or external disclosure), it is personal data for the purposes of any system that processes it alongside the resolution path.

9a.3 Account termination and the right to erasure

When a member exercises their right to erasure (GDPR Article 17), or when an account is terminated for any reason, the following protocol applies:

1. Encrypted claims are destroyed: All encrypted claim data, encrypted keys, and validation certificates associated with the account are permanently deleted from the core server. Public claims (§4.5) are not destroyed by account termination — they persist under the perpetual publication license granted by the member (see Catalog.ID Membership Agreement §9.12). A living ex-member may request deletion of their public claims at any time (§9.13). After the member's death, public claims persist for archival and attribution purposes.
2. The username-to-person mapping ceases to exist: Since the mapping existed only in the encrypted identity layer (and in the member's own client), destroying the server-side encrypted data eliminates the last system-controlled link.
3. The username becomes a dead identifier: External systems (such as Asset Registry) that reference the username now reference an identifier that resolves to nothing. It is functionally equivalent to a disconnected telephone number — it may appear in historical records, but it no longer identifies anyone.
4. The username is permanently retired: The username is never reassigned to another member. This eliminates any ambiguity about whether provenance claims or attribution claims associated with the username could be inherited by a future account holder (see Asset Registry Whitepaper §7.4).

The username in Asset Registry records becomes a dead service identifier that no longer resolves to any identity (see Asset Registry Whitepaper §7.4).

This protocol satisfies the right to erasure with respect to Catalog.ID's own processing. External systems that independently stored the username (such as the member's own public postings) are outside Catalog.ID's controllership and must be addressed by the member directly.

9a.4 What Catalog.ID does not erase

• The username itself: As a service identifier within the Developer's namespace (see §3.1), the username persists in infrastructure systems (such as Asset Registry's immutable records) after account termination. If the member deleted their public claims before or during termination, Catalog.ID ensures the username is effectively de-identified by destroying the encrypted identity layer — the username becomes a dead identifier that no longer resolves to any person. If public claims were not deleted, they persist under the perpetual publication license and the username remains resolvable.
• External references: Asset Registry records, third-party databases, or public postings that contain the username are not within Catalog.ID's control. These systems must independently determine their GDPR obligations with respect to the username, considering that after account termination the username no longer resolves to any identity within Catalog.ID. For Asset Registry's specific data protection analysis, see Asset Registry Whitepaper §7.2–7.3.

9a.5 Public claims and data protection

Public claims (§4.5) introduce a controlled exception to Catalog.ID's encrypted‑by‑default model. Their data protection posture is as follows:

1. Lawful basis — member: The member's lawful basis for initiating publication is consent (GDPR Article 6(1)(a)), expressed through the deliberate act of requesting publication. The member may withdraw consent at any time by deleting the public claim.
2. Lawful basis — Operator: The Operator's lawful basis for publishing is legitimate interest (GDPR Article 6(1)(f)): maintaining a trustworthy, validated public directory of professional identities. The balancing test is met because the member voluntarily submitted the data for publication, only non-sensitive claim types are eligible (§4.5.4), and the member can delete the public claim at any time.
3. Operator as publisher: The Catalog.ID Operator acts as an independent controller for the publication of public claims — analogous to a professional directory publisher. The member initiates publication by sharing claim data and submitting a request. The Operator independently reviews, validates, and decides whether to publish, exercising editorial discretion (§4.5.2). The Operator did not collect or solicit the data — the member initiated the publication flow — but the Operator's decisions about whether, how, and under what conditions to publish are its own.
4. Data minimization: Public claims are limited to a defined set of eligible claim types (§4.5.4). Sensitive categories (postal address, financial data, date of birth) cannot be made public.
5. Right to erasure: Public claims can be deleted by the member at any time during their lifetime — including after account termination — taking effect immediately. Public claims that are not deleted by the member persist under the perpetual publication license (see Catalog.ID Membership Agreement §9.12). After the member's death, GDPR does not apply to the personal data of deceased persons (Recital 27), and public claims persist for archival and attribution purposes.
6. Right to rectification: Public claims can be updated at any time through the standard publication flow (requiring renewed operator validation).

9a.5.1 Interaction with Asset Registry provenance records

When a member has active public claims and is also identified as a party in Asset Registry attribution claims, the combined effect is that Asset Registry stores the username in its immutable layer and Catalog.ID resolves that username to a named person via a public API. The username is personal data in this combined context.

This interaction is addressed as follows:

• Catalog.ID's responsibility: Catalog.ID controls the resolution path. When the member deletes their public claims, the resolution path is destroyed and the username in Asset Registry records becomes a dead identifier — effectively de-identified. If public claims persist after account termination (because the member did not delete them), the resolution path remains active under the perpetual publication license. A living ex-member may still request deletion at any time (Catalog.ID Membership Agreement §9.13).
• Asset Registry's responsibility: Asset Registry processes the username in its immutable layer under its own lawful basis (legitimate interest, consent, and the archiving exception — see Asset Registry Whitepaper §7.2.3). Asset Registry does not modify immutable records, but relies on the destruction of the resolution path for effective de-identification (see Asset Registry Whitepaper §7.3.3).
• Joint controller considerations: Asset Registry and Catalog.ID are complementary systems operated by related Operators. A data protection authority may apply a joint controller analysis (GDPR Article 26). The project's data protection posture does not depend on avoiding this classification — the lawful bases and erasure mechanisms are sufficient under either independent or joint controllership. See Asset Registry Whitepaper §7.3.2 for the full analysis.
• Key isolation: Each per‑machine Asset Registry signing key pair (§3.4.1a) is generated exclusively for Asset Registry use and must not be reused in other cryptographic systems. This prevents the public key embedded in Asset Registry's immutable claims from becoming a cross-reference vector through external key directories or certificate transparency logs after account termination. See Asset Registry Whitepaper §7.3.5 for the full rationale.

9a.6 Organization identities and data protection

Organization identities (§3a) have a fundamentally different data protection posture from personal identities:

1. Not personal data by default. An organization identity's username is a system‑assigned sequence identifier (§3a.2) — an opaque identifier for a legal entity, not a natural person. GDPR applies to the personal data of natural persons (Article 1(1)); organizational data is outside its scope unless it contains or leads to personal data about natural persons.
2. Delegate identity data is personal data. Delegate identities (§3b) are accounts for natural persons. Their claims, keys, role set, and the immutable organization link constitute personal data. This data is processed by Catalog.ID under the Operator's legitimate interest in maintaining the delegate identity model (GDPR Article 6(1)(f)).
3. No pseudonymity analysis for the organization. Unlike personal usernames (§9a.1), organization usernames are identifiers for legal entities, not natural persons. There is no personal pseudonymity to protect — the username identifies an organization, and the organization's real‑world identity is disclosed through its mandatory public claims (display name, domain).
4. Delegate identity pseudonymity. Delegate identity usernames are pseudonymous identifiers for natural persons — the same GDPR classification as personal usernames (§9a.1). The pseudonymity analysis depends on whether the delegate identity has active public claims. Without public claims, the delegate username is pseudonymous; with public claims, it is directly identifying.
5. Termination. When an organization identity is terminated, encrypted claims and keys are destroyed (same protocol as §9a.3). The organization username is permanently retired (§3a.7). All delegate identities linked to the organization are also terminated (§3b.7) — each delegate username is permanently retired.
6. Delegate identity termination. When a delegate identity is terminated individually (employee departure), the same termination protocol applies: encrypted claims and keys are destroyed, the username is permanently retired (§3b.8), and organization key rotation is triggered (§3a.5). The right to erasure applies once the employment relationship has ended (§3b.3). While employed, the organization has a legitimate basis for maintaining the delegate identity.
7. Public claims. Organization public claims (§4.5.4) are organizational data, not personal data. They are published under the Organization Identity Agreement, not under a personal consent basis. Delegate identity public claims follow the same data protection posture as personal identity public claims (§9a.5) — they are personal data published with the employee's consent.

Where an organization's public claims happen to contain information about natural persons (e.g., a contact person's name in the display_name field), the Operator must ensure that the relevant data protection requirements are met for those individuals. The Organization Identity Agreement addresses this obligation.

10. Registration Flow (User Perspective)

1. Accept terms.
2. Pay one‑time registration fee.
3. The server assigns a username. The client generates the password, supersecret, and initial key pairs locally (at minimum msg_encrypt and attr_encrypt; additional identity keys such as xrpl_master may be added later). The browser's password manager prompts to save the username and password.
4. Supersecret export. The system presents the supersecret for the member to export — by printing, downloading, or copying to a secure store. This is the member's primary opportunity to back up their access credential. The printed document contains the supersecret and the username; no private key material and no login password appear in the export. If the member loses the supersecret and has no device with imported keys, the identity is cryptographically dead (see §3.2).
5. Key bag upload. The client derives the AES‑256‑GCM key from the supersecret via Argon2id (§3.4.3), encrypts each private key as a separate key bag entry with a unique nonce, and uploads the entries to the server.
6. Device setup. The member chooses a PIN for this device and selects which keys to import (§3.4.4). This is the first device, so importing all keys is typical.
7. Email validation completes activation.

The user begins with a minimal identity and may add claims as desired. Additional identity key pairs (e.g., XRPL) can be generated and added as new key bag entries at any time (§3.4.8). Asset Registry signing keys are generated per‑machine when the Catalog software is installed, not during registration — see §3.4.1a. The supersecret export function remains available after registration.

10a. Organization Registration Flow

An organization identity is created by an existing natural person member or delegate identity holder. The flow creates two identities in a single transaction: the organization identity and its first delegate identity with the owner role.

1. Accept terms. The founding person accepts the Organization Identity Agreement (§3a.10) on behalf of the organization, including the employee terms for the first delegate identity.
2. Domain claim and verification. The founding person enters the organization's domain name (e.g., example.com). The system creates an encrypted domain claim and initiates domain ownership verification via the standard flow (§7.5): the person places a verification token at example.com/.well-known/catalogid.txt. The system fetches the token and confirms domain control.
3. Pay registration fee. The founding person pays the organization registration processing fee.
4. Organization username assignment. The server assigns the next available organization username in the 123abcd456 format (§3a.2).
5. Delegate identity username assignment. The server assigns the next available delegate username in the ab12cd34fg format (§3b.2). This delegate identity is permanently linked to the organization.
6. Organization credential generation. The client generates the organization's credentials locally, following the same procedure as personal registration (§10 steps 3–5): a password, a supersecret, and key pairs (at minimum msg_encrypt and attr_encrypt). Each private key is encrypted as a separate key bag entry via Argon2id + AES‑256‑GCM (§3.4.3) and uploaded to the server.
7. Organization supersecret export. The system presents the organization's supersecret for the founding person to export — by printing, downloading, or copying to a secure store. The founding person is responsible for the safekeeping of the organization's credentials. The system does not prescribe how these credentials are managed after registration.
8. Delegate identity key generation. The client generates the founding delegate identity's own key pairs, password, and supersecret — the same client‑side key generation as personal registration (§10 steps 3–5). The organization never sees these keys.
9. Key wrapping. The client wraps the organization's private keys to the founding delegate identity's public key (all keys, since the founding delegate identity has the owner role). The wrapped keys are uploaded to the server. This provides the founding delegate identity with daily operational access to organization keys without needing to enter the organization's supersecret.
10. Activation. Upon successful domain verification and payment, both identities are activated atomically. The validated domain claim is published immediately (mandatory — see §3a.6 and §4.5.4). The founding delegate identity can immediately begin adding claims, publishing a public profile, and creating additional delegate identities.

Organization credential custody. The organization's password and supersecret follow the same model as personal credentials — the holder is solely responsible for their safekeeping. If the organization's supersecret is lost and no delegate identity holds a wrapped copy of the current key chain, the organization's key bag entries are irrecoverable (same consequence as personal supersecret loss — §3.2). The Organization Identity Agreement addresses credential custody responsibilities (§3a.10).

10b. Delegate Identity Registration Flow

After the organization is created, additional delegate identities are created through the invitation flow described in §3b.3:

1. An owner or admin delegate identity initiates delegate identity creation.
2. The server assigns the next available delegate username in the ab12cd34fg format (§3b.2).
3. The organization specifies the employee's role set (§3a.4) and an optional role label (stored as a professional_role claim).
4. The system generates an invitation token — a single‑use, time‑limited credential that the organization provides to the employee.
5. The employee opens the invitation. The client generates the password, supersecret, and key bag locally — the same client‑side key generation as personal registration (§10 steps 3–6). The organization never sees the employee's private keys, password, or supersecret. After this step, the delegate identity enters a partially activated state: the employee can log in and manage their own key bag and claims, but cannot access organization keys or act on behalf of the organization until step 6 is completed.
6. An owner or admin delegate identity (not necessarily the person who initiated step 1) completes the onboarding by wrapping the organization's keys (including the full key chain from past rotations, if any) to the new delegate identity's public key, respecting role‑based key distribution per §3a.4, and uploading the wrapped keys. The key chain may be obtained either from the organization's key bag (using the organization's supersecret) or from the onboarding person's own wrapped copies if they already hold the full chain. Steps 5 and 6 are independent — the employee and the onboarding person do not need to be online simultaneously. The onboarding person can complete step 6 at any later point.
7. Upon completion of step 6, the delegate identity is fully activated with the immutable link to the organization, the assigned role set, and access to the organization's keys.

If the employee also has a personal Catalog.ID identity, they may optionally link the two identities (§3b.5) after activation.

11. Third‑Party Authentication

Catalog.ID enables privacy‑preserving authentication on third‑party websites, other catalog.org services, and any system that accepts federated identity. This section specifies the protocol by which a personal, organization, or delegate identity holder authenticates to an external relying party (RP) — a website or service that offers "Log in with Catalog.ID." Agent authentication is specified separately in §3c.5.5; the tokens produced by the flows below and by the agent flows are structurally identical, and any RP that accepts one accepts the other without modification.

11.1 Design Goals

1. Standard compatibility. The protocol is built on OpenID Connect (OIDC) so that any web framework with an OIDC library can integrate Catalog.ID as an identity provider within hours — not months.
2. Privacy by default. No claim data is released to the RP without the member's explicit, per‑claim consent at authentication time. The RP learns the member's Catalog.ID username and nothing else unless the member chooses to disclose additional attributes.
3. Selective disclosure. When the member does consent to share attributes, the system uses SD‑JWT (Selective Disclosure JWT, IETF draft‑ietf‑oauth‑selective‑disclosure‑jwt) so that individual claims are disclosed independently. The RP receives cryptographic proof that the disclosed attributes are authentic and validated, but cannot see attributes the member did not select.
4. No server‑side plaintext. The Catalog.ID core server never sees the plaintext of private claims during the authentication flow. Claim disclosure is performed client‑side: the member's device decrypts the relevant claims locally and constructs the SD‑JWT presentation. The server facilitates the OIDC redirect and token exchange but does not handle claim content.
5. Unified token model. The resulting ID token is a standard Catalog.ID JWT — the same token structure used throughout the system (§3c.5.5). RPs do not need separate integration paths for personal, delegate, organization, or agent identities.

11.2 Protocol Overview

Catalog.ID acts as an OpenID Provider (OP). The authentication flow follows the standard OIDC Authorization Code Flow with PKCE:

Member's browser              Catalog.ID (OP)              Relying Party (RP)
       │                            │                            │
       │  1. Click "Log in with Catalog.ID"                      │
       │◄────────────────────────────────────────────────────────│
       │                            │                            │
       │  2. Authorization request (redirect)                    │
       │───────────────────────────►│                            │
       │                            │                            │
       │  3. Authenticate (username/password + PIN)              │
       │◄──────────────────────────►│                            │
       │                            │                            │
       │  4. Consent screen (claim selection)                    │
       │◄──────────────────────────►│                            │
       │                            │                            │
       │  5. Authorization code (redirect back)                  │
       │◄───────────────────────────│                            │
       │────────────────────────────────────────────────────────►│
       │                            │                            │
       │                            │  6. Token exchange         │
       │                            │◄───────────────────────────│
       │                            │───────────────────────────►│
       │                            │                            │
       │  7. Authenticated session                               │
       │◄────────────────────────────────────────────────────────│

11.3 Discovery

Catalog.ID publishes an OpenID Provider Configuration Document at:

https://catalog.id/.well-known/openid-configuration

This document advertises the authorization endpoint, token endpoint, JWKS URI, supported scopes, supported response types, and SD‑JWT support. RPs use this document for automatic configuration — standard OIDC client libraries handle this without custom code.

11.4 RP Registration

Before a third‑party website can offer "Log in with Catalog.ID," it registers as a relying party:

1. The RP operator registers a client application through the Catalog.ID developer portal.
2. The RP provides: a client_id (chosen by the RP or assigned), one or more redirect_uri values, and a display name shown to members on the consent screen.
3. Catalog.ID issues a client_secret for confidential clients (server‑side applications). Public clients (SPAs, mobile apps) use PKCE without a client secret.
4. The RP specifies which claim types it will request. This does not grant automatic access — each member must still consent at authentication time — but it allows Catalog.ID to display a clear, stable consent screen.

Catalog.org's own services (portal, dashboard, inventory, publisher, etc.) are pre‑registered RPs with elevated trust — they may request additional scopes not available to external RPs (e.g., key management operations). The authentication flow is otherwise identical.

11.5 Authentication Flow

11.5.1 Step 1: Authorization Request

The RP redirects the member's browser to the Catalog.ID authorization endpoint:

GET https://catalog.id/authorize
  ?response_type=code
  &client_id={rp_client_id}
  &redirect_uri={rp_callback_url}
  &scope=openid profile claims
  &claims={requested_claim_types}
  &code_challenge={pkce_challenge}
  &code_challenge_method=S256
  &state={csrf_token}
  &nonce={replay_prevention}

The scope parameter follows OIDC conventions:

The claims parameter is a JSON object specifying which claim types the RP wants:

{
  "id_token": {
    "email": { "essential": true },
    "display_name": null,
    "location": null
  }
}

This follows the OIDC Claims Request syntax. essential: true means the RP requires this claim — if the member declines, authentication fails. Claims without essential are optional — the member may decline them and authentication still succeeds.

11.5.2 Step 2: Member Authentication

If the member does not have an active session with Catalog.ID, the authorization endpoint presents the standard login flow:

1. The member enters their Catalog.ID username and password.
2. The server authenticates the credential and returns a session.
3. If the member's device requires a PIN (§3.4.4), the client prompts for the PIN to unlock the device key bag. This step is necessary only if private claims were requested — public‑only authentication does not require key material.

If the member already has an active session, this step is skipped.

11.5.3 Step 3: Consent and Claim Selection

The authorization endpoint presents a consent screen showing:

• The RP's registered display name and domain.
• The requested claim types, grouped into:
  • Always shared — the Catalog.ID username (always included in the sub claim).
  • Public claims — attributes already published via §4.5. These are shown for transparency but do not require additional consent.
  • Private claims — each requested private claim type is listed with a checkbox. The member selects which to disclose. Essential claims are pre‑checked with a note that declining them will cancel authentication.
• A clear statement that the RP will receive the selected information.

The member approves or cancels. If the member cancels, the browser is redirected back to the RP with an access_denied error — standard OIDC behavior.

11.5.4 Step 4: Client‑Side Claim Preparation

When the member approves, the client (browser) prepares the claim disclosures locally:

1. For each consented private claim, the client decrypts the claim using the member's attr_encrypt private key (already unlocked via PIN in step 2).
2. The client constructs an SD‑JWT containing all approved claims as selectively disclosable fields. Each claim value is salted and hashed in the JWT body; the actual values are appended as separate disclosures.
3. The client signs the SD‑JWT preparation data and submits it to the Catalog.ID server along with the authorization approval.

The server never sees the plaintext of private claims. The SD‑JWT disclosures are constructed client‑side. The server receives only the member's authorization decision and the pre‑built disclosure package.

11.5.5 Step 5: Authorization Code

Catalog.ID issues a short‑lived authorization code and redirects the member's browser back to the RP's redirect_uri:

HTTP 302 Location: {redirect_uri}
  ?code={authorization_code}
  &state={csrf_token}

11.5.6 Step 6: Token Exchange

The RP's backend exchanges the authorization code for tokens:

POST https://catalog.id/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code={authorization_code}
&redirect_uri={rp_callback_url}
&client_id={rp_client_id}
&client_secret={rp_client_secret}
&code_verifier={pkce_verifier}

Catalog.ID responds with:

{
  "access_token": "...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "id_token": "...~disclosure1~disclosure2~...",
  "refresh_token": "..."
}

The id_token is an SD‑JWT. The compact portion (before the first ~) is a standard JWT signed by Catalog.ID's signing key. The disclosures (after the ~ separators) contain the claim values the member consented to share.

11.5.7 ID Token Structure

The ID token JWT payload contains:

For delegate identities, the token additionally includes:

Each selectively disclosed claim (email, display_name, location, etc.) appears as a disclosure appended to the JWT. The RP decodes each disclosure to obtain the claim name, value, and salt. The RP can verify that each disclosure hashes to one of the entries in the _sd array, confirming authenticity.

For claims that have been validated by the Validator Black Box (§6), the disclosure includes a validated flag and the validation certificate's timestamp. The RP can verify validation status without contacting Catalog.ID again.

11.6 Minimal Authentication (Username Only)

An RP that needs only to verify that a visitor holds a valid Catalog.ID — without learning any personal information — requests only the openid scope. The resulting ID token contains only the sub (username) and standard OIDC metadata. No consent screen is shown beyond confirming the RP's identity. This is the privacy‑maximizing configuration: the RP learns that the visitor is a real Catalog.ID member and nothing else.

11.7 Public‑Only Authentication

An RP that requests openid profile receives the member's username and any public claims (§4.5) without a private‑claim consent screen. Since public claims are already published and Operator‑validated, no additional consent is required — the member has already authorized their publication. The RP receives the public profile attributes as standard OIDC claims in the ID token.

This mode is useful for services that want to display the member's public identity (name, role, organization) without requesting access to private data.

11.8 Session Management

Catalog.ID supports OIDC Session Management and Front‑Channel Logout:

• Single sign‑on (SSO): Once a member authenticates with Catalog.ID, subsequent authorization requests from other RPs within the same browser session skip the login step (§11.5.2) and proceed directly to the consent screen. The member authenticates once and can log into multiple services.
• Single logout: When the member logs out of Catalog.ID, all RP sessions established through the current Catalog.ID session are notified via front‑channel logout. RPs that support OIDC logout will terminate their local sessions.
• Session duration: The Catalog.ID session follows the same TTL and refresh model as standard Catalog.ID sessions. The member can configure session duration in their account settings.

11.9 Token Refresh

RPs that need ongoing access (e.g., to periodically re‑verify the member's claims) can use the refresh token returned in the token exchange. The refresh token follows the same model as other Catalog.ID refresh tokens — it is tied to the member's consent and can be revoked by the member at any time through their Catalog.ID account settings.

Refreshed tokens include only the claims the member originally consented to. If the member has revoked consent for a specific claim since the original authentication, the refreshed token omits that claim. If all essential claims have been revoked, the refresh fails.

11.10 Consent Management

Members can review and manage their RP authorizations through the Catalog.ID account interface:

• Active authorizations: A list of all RPs the member has authenticated with, showing which claims were shared, when, and the last token refresh time.
• Revoke access: The member can revoke any RP's authorization at any time. This invalidates the RP's refresh token immediately. The RP's existing access token remains valid until it expires (standard OIDC behavior), but no new tokens can be obtained.
• Modify claims: The member can adjust which claims are shared with a specific RP. The change takes effect at the next token refresh or re‑authentication.

11.11 RP Verification of Tokens

An RP verifies ID tokens using standard OIDC procedures:

1. Retrieve Catalog.ID's public signing keys from the JWKS endpoint (https://catalog.id/.well-known/jwks.json).
2. Verify the JWT signature against the published keys.
3. Validate standard claims: iss, aud, exp, nonce.
4. For selectively disclosed claims: decode each ~‑separated disclosure, hash it with the _sd_alg, and confirm the hash appears in the _sd array.
5. Optionally check identity_type and IsHuman to apply identity‑type‑specific policies.

No Catalog.ID‑specific SDK is required. Any OIDC‑compliant library that supports SD‑JWT can verify the tokens. Libraries that do not yet support SD‑JWT can still verify the base JWT and use the sub (username) claim — they simply cannot access the selectively disclosed attributes.

11.12 Security Considerations

Phishing resistance. The authorization endpoint is always https://catalog.id/authorize. RPs cannot customize the login page. The member always authenticates directly with Catalog.ID, never with the RP.

Token binding. ID tokens are bound to the requesting RP via the aud claim. A token issued to one RP cannot be replayed against another.

Claim freshness. Selectively disclosed claims reflect the member's claim state at authentication time. If the member updates or revokes a claim after authentication, the previously issued token still contains the old value. RPs that need guaranteed freshness should use short token TTLs and require re‑authentication.

No claim accumulation. Catalog.ID does not allow RPs to silently request additional claims after the initial consent. Any change in requested claims triggers a new consent screen.

Rate limiting. The authorization and token endpoints are rate‑limited per RP and per member to prevent abuse.

12. Applications and Use Cases

• Privacy‑preserving login for websites
• Decentralized personal data vault
• Secure attribute exchange
• Verified identity claims without exposure
• Social trust networks
• Private address books
• End‑to‑end encrypted profiles
• Privacy-preserving provenance identity via Asset Registry signing key claims
• Public attribution of creative works via Asset Registry attribution claims
• Two-sided attribution for creative collaborations
• Durable public profiles with Operator‑validated professional attribution
• Long‑term identity resolution for archival provenance via public claims
• Organization identities with sequence‑based usernames for studios, labels, and other entities
• Delegate identities for employees acting in organizational capacity — solving the createdby problem
• Mass employee onboarding without requiring personal accounts
• Context switching between personal and delegate identities
• Role‑based organizational key custody via delegate identities
• Organization‑wide claim sharing via the attr_encrypt key with cryptographic revocation on departure
• Organizational Asset Registry participation through delegate identity signing keys
• XRPL wallet management through delegate identities with the treasurer role

13. Claim Timestamping via Asset Registry

Catalog.ID claim operations (creates, updates, shares, revocations, certificate issuances) are encrypted and opaque to the core server. To provide independent proof that a set of operations existed at a specific time, Catalog.ID periodically anchors its operation history to Asset Registry.

13.1 How it works

At regular intervals (e.g., every hour), the core server:

1. Collects digests of all claim operations since the last anchoring interval.
2. Builds a Merkle tree over these digests.
3. Submits the Merkle root to Asset Registry as a registry_anchor claim.

Asset Registry includes the anchor in a block, which is then anchored to XRPL. This creates a layered timestamping chain:

Catalog.ID operations → Merkle root → Asset Registry claim → Asset Registry block → XRPL

13.2 What this proves

• A specific set of encrypted claim operations existed at or before the Asset Registry block anchor time.
• No operations within an anchored interval have been retroactively inserted or removed.
• The sequence of anchoring intervals is contiguous (using Asset Registry per-claimant claim chaining).

13.3 What this does not reveal

• The content of any claim (all operations are digests of encrypted data).
• Which members performed which operations.
• The number or type of operations (only the Merkle root and operation count are published).

13.4 Per-operation provability

Any individual operation can be proven to have been included in a specific anchoring interval by presenting its Merkle inclusion proof against the published root. This allows a member to independently verify that their operation was captured.

14. Cryptographic Standards

Catalog.ID uses NIST post-quantum cryptographic standards:

• Key encapsulation: ML-KEM-1024 (FIPS 203) for claim encryption and key sharing
• Digital signatures: ML-DSA-65 (FIPS 204) for validation certificates, trust graph signatures, and Asset Registry provenance signing
• Symmetric encryption: AES-256-GCM for claim data encryption, key bag entry encryption, and device localStorage encryption
• Key derivation: Argon2id (64 MB memory, 3 iterations, 4 parallelism) for deriving AES keys from the supersecret. AES-256 provides 128-bit post-quantum security (Grover's algorithm halves symmetric key strength), well above any practical attack threshold.

These algorithms align with Asset Registry's cryptographic profile, enabling cross-system verification compatibility. The system is crypto-agile: algorithm choices can be upgraded as standards evolve.

15. Federation Model

Catalog.ID is operated by a federated network of independent Operators. Each Operator runs a full Catalog.ID node — core server, database, and Validator Black Box — and provides identity services under a unique Operator prefix.

15.1 Operators and Addressing

Each Operator is assigned a 4-character opaque Operator ID from a reduced charset excluding visually confusing characters (0/O, 1/I/l) that prefixes the catalog.id domain. Operator IDs are generated from sequential integers using a two-stage permutation that hides sequential structure (see Asset Registry Whitepaper §8.1.2). The identifier carries no semantic content about the Operator's identity, jurisdiction, or sequence of registration. For the first Operator — Stichting Outpapier — the assigned Operator ID places its identity services at b4np.catalog.id. The 923 thousand-entry namespace ensures the identifier system scales far beyond foreseeable network growth.

Operators may be foundations or licensed corporations. The Developer licenses the Catalog.ID software and namespace to each Operator under an operator license agreement. Corporations may apply to run the software to extend the network's global coverage across major jurisdictions. Operator admission is governed by the network's governance framework (§15.6).

Currently, the first Operator (Stichting Outpapier) is the sole Operator. All accounts — regardless of the member's geographic location — are registered at this node until additional Operators join the network.

15.2 Account Origin

Every Catalog.ID account has a single origin node — the Operator at which the account was created. The origin node is recorded in the account's identity record and is immutable for the lifetime of the account (unless migrated after permanent node loss — see §15.5).

Members freely choose which Operator to register with. The choice may be influenced by geographic proximity, jurisdictional preference, or trust in the operating entity, but is not constrained — a member in any country may register at any Operator.

The relationship between a member and their origin node is primarily legal: the member accepts the Catalog.ID Membership Agreement with the origin node's Operator, and the Operator sublicenses the username to the member (§3.1.4). The origin Operator is the member's contractual counterpart for membership terms, data protection obligations, dispute resolution, and account termination. Because all data is fully replicated (§15.3), the origin node is not the exclusive custodian of the member's data — but it is the entity with which the member has a legal relationship. This distinction matters when the member exercises rights under data protection law (e.g., GDPR Art. 15–17): the request is directed to the origin Operator.

Because all account data is fully replicated across all nodes (§15.3), a member can authenticate and perform most operations at any node, not only the origin. The origin node retains authority for a limited set of administrative operations that require serialization:

• Account‑level operations. Lockdown, account termination, key rotation (§3.3), and organization/delegate management (delegate creation, role changes, org termination) are performed at the origin node. These operations are infrequent, affect account‑wide state, and must be serialized to prevent conflicts.
• Validation. Validation requests (§7) are processed by the node where the member is currently authenticated. Each Operator maintains its own physically separated Validator Black Box; validation certificates are issued by the local node's validator and synchronized to all peers.

The following operations can be performed at any node:

• Authentication. Members can log in at any node — the password hash and key bag entries are replicated. The first login at a new node's domain requires the supersecret to set up a device in that browser (the same flow as setting up a new device — see §3.4.4). Subsequent logins at the same node use the normal PIN flow.
• Claim operations. Claim creation, updates, deletion, sharing, and public claim publication can be performed at any node. Conflicts from concurrent writes at different nodes are resolved by last‑writer‑wins (§15.3.4).
• Read operations. Public profile lookups, public claim queries, public key retrieval, and trust graph queries are served locally from the full replica.

15.3 Identity Synchronization

All account data is synchronized across all nodes in the network. Every node maintains a complete replica of every account — including encrypted claims and key bag entries — regardless of origin. This ensures that:

• Any node can resolve any username to a public profile.
• Any node can serve public claim queries and public key lookups for any account.
• Members can authenticate and perform claim operations at any node.
• Asset Registry nodes and other integrated services can query any Catalog.ID node for signing key verification, without needing to know the account's origin.
• The network is resilient to the temporary or permanent loss of any single node — all identity data, including encrypted private data, survives on all peers.

15.3.1 Synchronization Protocol

Nodes synchronize identity records through persistent connections with real‑time push. Each node maintains a sequential operation log of all mutations performed at that node — account creations, claim updates, public claim publications, key rotations, certificate issuances, account terminations, and other changes. Each entry in the log is assigned a monotonically increasing sequence number and is signed by the node's operator key.

Primary mechanism — real‑time push:

1. Each pair of peer nodes maintains a persistent connection (e.g., WebSocket or long‑lived HTTP/2 stream).
2. When a node commits a mutation to its operation log, it immediately pushes the entry to all connected peers.
3. The receiving peer:
   • Verifies the origin node's operator signature on the entry.
   • Applies the change to its local replica.
   • Advances its replication cursor for that origin node.
4. Under normal operation, changes propagate to all peers within seconds of being committed at the origin.

Fallback mechanism — pull‑based catch‑up:

If a persistent connection is interrupted (network partition, node restart, maintenance), the reconnecting peer falls back to a pull‑based protocol to close the gap:

1. The peer sends its last known sequence number for the source node.
2. The source node streams all entries since that sequence number.
3. The peer processes entries in order, verifying signatures and applying changes.
4. Once caught up, the connection transitions back to real‑time push.

This dual approach ensures low‑latency propagation during normal operation while guaranteeing eventual consistency even after extended outages. No distributed consensus protocol is required — conflict resolution uses last‑writer‑wins (§15.3.4), and the origin node serializes the small set of administrative operations that require strict ordering.

15.3.2 What is Synchronized

Every node maintains a full replica of all account data. The synchronized replica includes:

• Account metadata: username, account type, origin node, status, password hash, creation timestamp, Argon2id salt, and all account‑level state.
• Key bag entries: all individually encrypted private key entries (§3.4). Each entry is an opaque encrypted blob — the receiving node cannot decrypt it (only the member, with the supersecret, can). Replicating key bag entries ensures that the member can restore their keys at any node, and that no single node failure causes irrecoverable key loss.
• Encrypted claims: the full claim table — encrypted claim values, nonces, labels, and metadata. Like key bag entries, these are opaque ciphertext that peer nodes cannot decrypt. Replication provides data resilience and enables claim operations at any node.
• Claim keys: all sharing relationships — the encrypted symmetric keys that allow claim owners and recipients to decrypt claims.
• Public claims: published claims stored in cleartext, visible to anyone who queries the account's public profile.
• Public keys: the member's current public encryption key and any published Asset Registry signing keys.
• Validation certificates: signed attestations from Validator Black Boxes, so that any node can present validated claims with their certificates.
• Key chain metadata: the sequence of public keys (current and rotated), with revocation status.
• Trust data: trust expressions and pre‑trusted peers (inputs to the trust graph). Trust scores and Merkle snapshots are derived data computed locally by each node.
• Organizational data: delegate roles, identity links, and wrapped organization keys.
• Claim endorsements: endorsement signatures for the vouching system.

15.3.3 What is NOT Synchronized

• Session state. Login sessions are local to the node where the member authenticated. Sessions are ephemeral — when a member logs in at a different node, a new session is created there.
• Device records. Device tokens, PIN hashes, deviceEncryptionKey values, and brute force counters are local to the node where the device was set up. A device record is bound to the browser's localStorage for that node's domain — the PIN‑protected deviceEncryptionKey decrypts keys stored in localStorage, which is per‑domain and does not exist at other nodes. When a member logs in at a new node for the first time, they set up a new, independent device at that node (§3.4.4). Account lockdown (§3.3) — which is synchronized via account status — revokes all sessions and locks all devices at all nodes, providing the cross‑node emergency revocation mechanism.
• Validator Black Box state. Pending validation requests, verification tokens, and in‑progress validation flows remain at the node's validator. Completed validation certificates are synchronized.
• OIDC state. Authorization codes, consent records, and OIDC refresh tokens are local to the node that issued them. Relying parties must be registered on each node independently.
• Invitation tokens. Delegate invitation tokens are created and consumed at the origin node — delegate creation and activation are origin‑only operations. Syncing them to peers provides no benefit and would expose token hashes unnecessarily. If the origin node is down, delegate activation cannot proceed regardless.
• Agent API keys and refresh tokens. These are local to the node that issued them. After node loss, agents must be re‑provisioned.
• Username pool. Each node maintains its own pre‑allocated pool of unassigned usernames (§15.7).
• Derived data. Trust scores and Merkle snapshots are computed locally by each node from the synchronized trust expressions.

Privacy note. Encrypted claims and key bag entries are replicated as opaque ciphertext — peer nodes store them but cannot decrypt them. The encryption key is derived from the member's supersecret, which is never transmitted to or stored on any server. A node compromise exposes ciphertext only; the plaintext remains protected by the member's supersecret and by post‑quantum encryption (ML‑KEM‑1024 / AES‑256‑GCM).

15.3.4 Conflict Resolution

Because members can perform claim operations at any node (§15.2), two nodes may concurrently process writes to the same account. The system uses last‑writer‑wins conflict resolution based on timestamps.

Each operation log entry carries a wall‑clock timestamp. When a receiving node applies an incoming entry that affects an entity it has already modified locally, it compares timestamps: the entry with the later timestamp prevails. This is safe because:

• Most operations are non‑conflicting. Claim creation generates a globally unique UUID — two nodes creating claims for the same account produce different entities. Claim sharing appends a new key record per recipient. Key bag entries are individually encrypted records identified by key ID and index — adding different keys at different nodes produces independent entries (§3.4.8).
• Same‑entity conflicts are rare. Two nodes updating the same claim simultaneously requires the same member to edit the same claim on two devices at two different nodes at the same moment. In practice, this is vanishingly unlikely.
• Account‑level operations are origin‑only. The operations most sensitive to ordering — lockdown, termination, key rotation, and organizational management — are restricted to the origin node, where they are serialized by the database.

No distributed consensus protocol is required. The system guarantees eventual consistency: all nodes converge to the same state once all operation log entries have been exchanged.

15.4 Authentication at Any Node

Because all account data — including password hashes and key bag entries — is replicated to every node, a member can authenticate at any node in the network:

1. Login. The member enters their username and password at any node. The node verifies the password against the replicated hash and creates a local session.
2. Device setup. If this is the member's first login at this node's domain, the browser's localStorage does not contain encrypted keys for this origin. The member enters their supersecret to decrypt the key bag entries (replicated to this node) and sets up a new device — the same flow as setting up any new device (§3.4.4). The new device record is created locally at this node. Subsequent logins at this node use the normal PIN flow.
3. Operations. Once authenticated, the member can read all data locally, create and manage claims, share claims, and perform trust operations. Account‑level administrative operations (lockdown, termination, key rotation, org/delegate management) redirect to the origin node.

OIDC integration. When a relying party (§11) sends a user to a Catalog.ID node for authentication, the node can process the OIDC flow directly if the member can authenticate there. If the relying party provides a login_hint with the member's username, the authorize endpoint may redirect to the member's preferred node (typically the origin, where an active device exists). Relying parties must be registered on each node independently.

Brute force protection. Device records — including PIN attempt counters and lockout state — are local to each node (§15.3.3). PIN brute force attempts at one node do not affect devices at other nodes, and there is no cross‑node amplification of PIN attempts. Each node independently enforces its lockout thresholds (§3.4.6).

15.5 Resilience and Node Loss

Because every node holds a full replica of all account data — including encrypted claims and key bag entries — the network provides strong resilience against node failure:

• Any node temporarily down. Members who normally use the down node can log in at any other node and continue working. If the member has not previously set up a device at the other node, they enter the supersecret once (same as a new device). All claims, sharing relationships, and key material are available from the local replica. Origin‑only operations (lockdown, termination, key rotation) are deferred until the node returns. All other operations continue normally.

• Origin node permanently lost. If an Operator permanently ceases operation, the network governance (or a governance‑level process) migrates affected accounts by updating the origin node identifier to a surviving node. Because the full replica includes all encrypted claims, key bag entries, and organizational data, this migration requires no user action — the member's next login at the surviving node works exactly as before (setting up a new device if they have not previously logged in at that node). No data is lost; no claims need to be re‑created; no keys need to be re‑generated.

• Non‑origin node permanently lost. No impact on any member. The remaining nodes hold complete replicas and continue to serve all queries and synchronize among themselves. Members who had set up devices at the lost node lose only the device‑specific localStorage in their browser — they re‑enter the supersecret at a remaining node to set up a new device.

This full‑replication model ensures that federation provides genuine resilience for all data, not only public metadata. The encryption guarantees (§3.4) ensure that replication does not weaken privacy: every node stores only ciphertext it cannot decrypt.

15.6 Governance

The federation serves purposes analogous to the Asset Registry federation (see Asset Registry Whitepaper §14.4):

• Operational resilience — no single point of failure.
• Jurisdictional coverage — Operators in different jurisdictions can serve members subject to local legal requirements.
• Governance transparency — multiple independent Operators prevent unilateral control over the identity network.
• Preservation — identity records survive the failure of any single Operator through replication.

Operator admission, the operator license agreement, replication protocol versioning, and coordinated policy changes (such as cryptographic algorithm migration) are governed by the network governance framework — a shared agreement among all Operators. The governance framework is outside the scope of this whitepaper.

15.7 Username Allocation and Distribution

Because multiple Operators can accept registrations, the system must guarantee that every username — personal, organization, delegate, or agent — is assigned exactly once across the entire network. Catalog.ID achieves this through a batch allocation model controlled by the Developer (Licensor).

15.7.1 Batch Allocation

Each Operator receives usernames in pre‑allocated batches rather than drawing from a shared counter. The flow is:

1. Request. The Operator requests a new batch of usernames from the Developer.
2. Generation and delivery. The Developer generates the next sequential batch from the master namespace and delivers it to the Operator through a secure, authenticated channel. Each batch contains a contiguous range of sequence numbers and their corresponding encoded usernames for each identity type (personal, organization, delegate, and agent).
3. Local assignment. The Operator assigns usernames from its local pool on a first‑come, first‑served basis during registration. The Operator may only assign usernames from batches it has received; it cannot generate usernames independently.
4. Replenishment. When the Operator's remaining stock of unassigned usernames in any identity type falls below a configurable threshold, the Operator requests a new batch.

Batches are sized in multiples of 1,000 usernames per identity type. The exact batch size is determined in the operator license agreement (Catalog Server and Client Software License Agreement) between the Developer and the Operator.

15.7.2 Uniqueness Guarantee

Because the Developer is the sole authority that issues batches, and each batch contains a non‑overlapping range of sequence numbers, no two Operators can ever receive the same username. The guarantee is structural — it requires no distributed consensus, no shared database lock, and no real‑time coordination between Operators. Each Operator holds an exclusive allocation of sequence numbers, and the master namespace maintained by the Developer is the single source of truth for which ranges have been issued.

15.7.3 Synchronization Interaction

When an Operator assigns a username and creates an account, the account creation event is propagated to all peer nodes through the identity synchronization protocol (§15.3). Peer nodes add the new account to their local replicas. Because allocations are non‑overlapping, a peer node will never encounter a conflict between a remotely synchronized account and a locally assigned username.

15.7.4 Pricing

For foundational Operators — foundations operating Catalog.ID nodes for the public interest — username batches are provided without charge. The Developer's costs for namespace management are absorbed as part of the Developer's mission to establish and grow the Catalog ecosystem.

For corporate Operators — commercial entities licensed to operate Catalog.ID nodes — a per‑username price may be determined by the Developer and specified in the operator license agreement. No corporate Operators exist at the time of writing.

16. Account Termination upon Death

When the Operator is notified of a member's death — by family, legal heirs, an executor, or otherwise — the Operator verifies the death through appropriate evidence and terminates the account per §9a.3. All encrypted claims, keys, and certificates are destroyed. Public claims (§4.5) persist under the perpetual publication license granted by the member (see Catalog.ID Membership Agreement §9.12), so that public attribution remains resolvable for archival and historical purposes. GDPR does not apply to the personal data of deceased persons (Recital 27).

Asset Registry provenance claims remain in the immutable record under the deceased member's identity. These are historical records that are not modified or transferred.

17. Future Extensions

• Multi‑validator certificate consensus (cross‑operator validation acceptance)
• Cross‑operator account migration tooling
• Anonymous or zero‑knowledge proof claims
• Institutional validators (universities, banks, agencies)

Conclusion

Catalog.ID introduces a modern identity framework rooted in privacy, user control, and cryptographic trust. By separating identity storage, validation authority, and claim sharing into distinct, purpose‑built components — especially through the isolated Validator Black Box — and distributing the system across a federated network of independent Operators with real‑time identity synchronization, the system achieves a balance of usability, verifiability, confidentiality, and resilience that surpasses conventional identity solutions.

Catalog.ID is not just a login mechanism; it is a platform for people to manage and share their digital identities with unparalleled control and security.