chore: unify bold syntax to single asterisk in .org files and update legacy memex-amero references
This commit is contained in:
@@ -18,16 +18,16 @@ The Master Key, often referred to as "Psyche" (Latin for soul or animating princ
|
||||
- The system MUST allow a single Master Key seed to generate an infinite number of unique, unlinkable personas, providing unparalleled flexibility for different digital roles.
|
||||
- Each Persona MUST possess its own distinct Ed25519 keypair for cryptographic signing and an X25519 keypair for robust encryption.
|
||||
- The system MUST enable the revocation and rotation of individual Persona keys without compromising the integrity of the Master Key or affecting other derived Personas, offering granular control and enhanced security.
|
||||
- The identity lifecycle MUST be managed via **KERI (Key Event Receipt Infrastructure)**, ensuring identities remain persistent regardless of key rotations.
|
||||
- All key rotations and membership changes MUST be recorded in an append-only, verifiable **Key Event Log (KEL)**.
|
||||
- The identity lifecycle MUST be managed via *KERI (Key Event Receipt Infrastructure)*, ensuring identities remain persistent regardless of key rotations.
|
||||
- All key rotations and membership changes MUST be recorded in an append-only, verifiable *Key Event Log (KEL)*.
|
||||
|
||||
*** Master Key Interaction Protocol: Derivation vs. Action
|
||||
|
||||
It is critical to distinguish between the Master Key's role in *Persona derivation* and a Persona's role in *network actions*.
|
||||
|
||||
- **Master Key for Derivation (Creation of New Identities):** The Master Key is the sole cryptographic origin for generating new Accounts and Personas. Any creation of a new Persona (or Account) in your identity tree requires interaction with the Master Key. This ensures a clear, auditable, and cryptographically sound chain of custody from your single root to every Persona. While this might occasionally require accessing a hardware wallet for a new Persona setup, it safeguards the integrity of your entire identity graph.
|
||||
- *Master Key for Derivation (Creation of New Identities):* The Master Key is the sole cryptographic origin for generating new Accounts and Personas. Any creation of a new Persona (or Account) in your identity tree requires interaction with the Master Key. This ensures a clear, auditable, and cryptographically sound chain of custody from your single root to every Persona. While this might occasionally require accessing a hardware wallet for a new Persona setup, it safeguards the integrity of your entire identity graph.
|
||||
|
||||
- **Persona Keys for Actions (Interacting with the Network):** Once a Persona is created, it becomes a fully independent, active agent in the Agora network. All subsequent actions—signing messages, publishing content, entering into contracts (including Foundation Contracts), acting as a guardian for social recovery, or joining an organization—are performed using the Persona's own distinct keypairs. **The Master Key is explicitly *not* needed for these daily operational activities.** This design minimizes the Master Key's exposure, keeping it safely offline and dramatically reducing the frequency of hardware wallet interactions for routine tasks.
|
||||
- *Persona Keys for Actions (Interacting with the Network):* Once a Persona is created, it becomes a fully independent, active agent in the Agora network. All subsequent actions—signing messages, publishing content, entering into contracts (including Foundation Contracts), acting as a guardian for social recovery, or joining an organization—are performed using the Persona's own distinct keypairs. *The Master Key is explicitly *not* needed for these daily operational activities.* This design minimizes the Master Key's exposure, keeping it safely offline and dramatically reducing the frequency of hardware wallet interactions for routine tasks.
|
||||
|
||||
This clear separation ensures that your Master Key functions as a secure, infrequent-use root for identity creation and recovery, while your Personas are empowered to execute all network interactions autonomously.
|
||||
|
||||
@@ -166,13 +166,13 @@ async function recoverShard(
|
||||
|
||||
*** Decoupled Key Provisioning & Watch-Only Master
|
||||
To minimize the exposure of the Master Seed, client applications MUST support decoupled key strategies:
|
||||
- **Subkey Injection:** The client MUST allow importing a standalone extended private key (xpriv) or raw private key for a specific `persona_index'`. The app operates strictly within the scope of that imported key and cannot derive sibling personas.
|
||||
- **Multi-Device Sync:** Users can securely provision a secondary device (e.g., a mobile phone) by injecting a Persona-level subkey, keeping the Master Seed in a physical hardware vault.
|
||||
- **Watch-Only Master:** The client MAY allow storing the Master Extended Public Key (xpub). This creates an "Auditor View," enabling the device to monitor all derived Personas and balances without possessing the private keys necessary to authorize transactions or sign events.
|
||||
- *Subkey Injection:* The client MUST allow importing a standalone extended private key (xpriv) or raw private key for a specific `persona_index'`. The app operates strictly within the scope of that imported key and cannot derive sibling personas.
|
||||
- *Multi-Device Sync:* Users can securely provision a secondary device (e.g., a mobile phone) by injecting a Persona-level subkey, keeping the Master Seed in a physical hardware vault.
|
||||
- *Watch-Only Master:* The client MAY allow storing the Master Extended Public Key (xpub). This creates an "Auditor View," enabling the device to monitor all derived Personas and balances without possessing the private keys necessary to authorize transactions or sign events.
|
||||
|
||||
*** Cross-Persona Interaction (The "Bridge")
|
||||
The system MUST allow a user to prove relationships between their own Personas without publicly linking them to a single Master Seed.
|
||||
- **Zero-Knowledge Proofs (ZKP):** A user can "Attest" that a specific capability or badge belongs to them across personas. For example, a "Pseudonymous Developer" Persona can use a ZKP to prove it holds a "Verified Citizen" badge issued to its associated "Legal Persona," proving citizenship without revealing *which* citizen they are.
|
||||
- *Zero-Knowledge Proofs (ZKP):* A user can "Attest" that a specific capability or badge belongs to them across personas. For example, a "Pseudonymous Developer" Persona can use a ZKP to prove it holds a "Verified Citizen" badge issued to its associated "Legal Persona," proving citizenship without revealing *which* citizen they are.
|
||||
|
||||
*** Index Management (Gap Limit Protocol)
|
||||
|
||||
@@ -199,8 +199,8 @@ Clients must efficiently discover active personas derived from a Master Seed wit
|
||||
|
||||
**** Comparison to Traditional Systems
|
||||
|
||||
- **Traditional:** Partner leaves → Manually update 50+ passwords, revoke individual access rights across numerous platforms (email, bank, cloud storage, code repos, etc.). High risk of oversight and residual access.
|
||||
- **Agora:** Partner leaves → One managed revocation at the Master Key level (or their specific Persona's access derivation is severed) → Instant, automatic severance of access across all derived keys (company Bitcoin, PGP, SSH, etc.).
|
||||
- *Traditional:* Partner leaves → Manually update 50+ passwords, revoke individual access rights across numerous platforms (email, bank, cloud storage, code repos, etc.). High risk of oversight and residual access.
|
||||
- *Agora:* Partner leaves → One managed revocation at the Master Key level (or their specific Persona's access derivation is severed) → Instant, automatic severance of access across all derived keys (company Bitcoin, PGP, SSH, etc.).
|
||||
|
||||
This mechanism ensures that the collective's assets remain secure and under the control of the remaining authorized members, providing a robust solution for organizational identity management.
|
||||
|
||||
@@ -340,7 +340,7 @@ const encryptionKey = x25519.generateKeyPair(personaNode.privateKey);
|
||||
- If a Persona key is compromised, it can be revoked and rotated without affecting the Master Key or other Personas.
|
||||
|
||||
*** Persona Governance & Operational Recovery
|
||||
While the Master Key is an offline seed, Personas are active network agents governed by their own rules, smart contracts, and DID Documents. Operational recovery, succession, and governance occur at this layer and are defined via **Inception Policies** established at the moment the identity is created.
|
||||
While the Master Key is an offline seed, Personas are active network agents governed by their own rules, smart contracts, and DID Documents. Operational recovery, succession, and governance occur at this layer and are defined via *Inception Policies* established at the moment the identity is created.
|
||||
|
||||
**** Recovery Guardian Dynamics: Natural Persons vs. Collectives
|
||||
|
||||
@@ -348,39 +348,39 @@ Agora distinguishes between the dynamics of recovery for individual "natural per
|
||||
|
||||
***** Natural Person Persona: The "Dictator with Safety Nets"
|
||||
For a human, the design goal is Ultimate Sovereignty. You are the "Root." Even if you have "Recovery Friends," they should have no power over you unless you are incapacitated.
|
||||
- **The Logic:** The Persona's primary operational key holds absolute priority weight (e.g., Weight 100). The "Recovery Friends" group has a collective weight of 100, but their actions are restricted by time-locks.
|
||||
- **Unilateral Action:** A natural person Persona retains the right to change their recovery "friends" (guardians) even if those guardians do not explicitly consent to be "rotated out."
|
||||
- **Mechanism:** Any rotation signed by the primary key is effective immediately. Rotation signed by the Escrow Group (Guardians) requires a 72-hour `Pending State` (Time-Lock) and can be cancelled by the user at any time. This ensures you can "fire" your recovery team instantly without asking for permission, as your weight alone meets the threshold.
|
||||
- *The Logic:* The Persona's primary operational key holds absolute priority weight (e.g., Weight 100). The "Recovery Friends" group has a collective weight of 100, but their actions are restricted by time-locks.
|
||||
- *Unilateral Action:* A natural person Persona retains the right to change their recovery "friends" (guardians) even if those guardians do not explicitly consent to be "rotated out."
|
||||
- *Mechanism:* Any rotation signed by the primary key is effective immediately. Rotation signed by the Escrow Group (Guardians) requires a 72-hour `Pending State` (Time-Lock) and can be cancelled by the user at any time. This ensures you can "fire" your recovery team instantly without asking for permission, as your weight alone meets the threshold.
|
||||
|
||||
***** Collective Persona: The "Protected Quorum"
|
||||
For an LLC or NGO, the goal is Mutual Defense and preventing "hostile takeovers" where one founder kicks out others.
|
||||
- **The Logic (Consensus Required):** All shareholder keys have defined, often equal weights (e.g., 3 shareholders, weight of 33 each).
|
||||
- **The Rotation Rule (Governance Gate):** Thresholds for different actions are defined at inception. For example, a simple majority (51%) might be sufficient for daily operations, but changing the board or quorum requires a supermajority (e.g., 75% or 3-of-3 unanimity).
|
||||
- **Veto Power:** The identity may designate a specific "Founder Key" that possesses Veto Power. This key must be among the required editors for *any* rotation event to be valid, making that individual impossible to remove without their own signature.
|
||||
- **Protection:** This prevents a single member from seizing the company identity. Removing a member requires signatures from the quorum (e.g., 3-of-4), ensuring that "consent" is baked into the math of the threshold.
|
||||
- *The Logic (Consensus Required):* All shareholder keys have defined, often equal weights (e.g., 3 shareholders, weight of 33 each).
|
||||
- *The Rotation Rule (Governance Gate):* Thresholds for different actions are defined at inception. For example, a simple majority (51%) might be sufficient for daily operations, but changing the board or quorum requires a supermajority (e.g., 75% or 3-of-3 unanimity).
|
||||
- *Veto Power:* The identity may designate a specific "Founder Key" that possesses Veto Power. This key must be among the required editors for *any* rotation event to be valid, making that individual impossible to remove without their own signature.
|
||||
- *Protection:* This prevents a single member from seizing the company identity. Removing a member requires signatures from the quorum (e.g., 3-of-4), ensuring that "consent" is baked into the math of the threshold.
|
||||
|
||||
***** Identity Succession & Minors
|
||||
Agora handles the lifecycle of identity across generations.
|
||||
- **Minor Onboarding:** For a minor, a parent or guardian Persona can "Co-sign" the identity inception event.
|
||||
- **Succession Logic:** This link creates a pre-authorized recovery path where the parent holds a dormant weight that can be activated to rotate keys if the minor loses access, transitioning to full independence at a defined maturation date.
|
||||
- *Minor Onboarding:* For a minor, a parent or guardian Persona can "Co-sign" the identity inception event.
|
||||
- *Succession Logic:* This link creates a pre-authorized recovery path where the parent holds a dormant weight that can be activated to rotate keys if the minor loses access, transitioning to full independence at a defined maturation date.
|
||||
|
||||
**** Legal Override & The "Break-Glass" Escrow (For Legal Entities)
|
||||
|
||||
To handle situations like the death of a sole founder, a lost key, or a binding court order without creating a central back door, Agora implements a "Dormant Escrow" pattern specifically designed for Collective Personas or High-Value single Personas.
|
||||
|
||||
- **The Dormant Key:** At inception, the Persona's governance structure includes a "Public Key" belonging to a Neutral Third Party (e.g., a decentralized notary or a legal escrow service). This key is assigned a weight of `0` for daily operations.
|
||||
- **Multi-Party (M-of-N) Escrow:** To prevent a single corrupt entity from hijacking an identity, Agora utilizes a **Recovery Council**. For instance, a rotation might require 2-of-3 signatures from designated entities (e.g., a Notary, a Law Firm, and a Decentralized Oracle).
|
||||
- **The Trigger:** The identity’s governing logic includes a rule: "If a certified Legal Attestation (e.g., signed by the local Court's Public Key) is presented, the Escrow Key's weight jumps to the necessary quorum threshold (e.g., 100) for a single Rotation Event."
|
||||
- **Observer-First Transparency:** Any change to the master key—including a legal override—must be published to the **Key Event Log (KEL)**. This ensures it's impossible for an agent to "quietly" take over an account; every user device and hired "watchdog" service is alerted immediately.
|
||||
- **The Veto Window (Time-Locking):** Any rotation event initiated by an Escrow Key triggers a mandatory 72-hour `Pending State`. If the primary owner still possesses their key (i.e., the agent is acting maliciously), they can sign a **Veto & Revoke** message. Because the Owner Key has absolute priority, this instantly kills the pending rotation and can strip the escrow agent of future rights. If the owner is incapacitated, they won't sign a veto, and after 72 hours, the change becomes final.
|
||||
- **Empowerment through Pre-authorization:** This allows the law to intervene technically—not through "hacking," but via a pre-authorized, transparent mechanism agreed upon during the identity's inception.
|
||||
- *The Dormant Key:* At inception, the Persona's governance structure includes a "Public Key" belonging to a Neutral Third Party (e.g., a decentralized notary or a legal escrow service). This key is assigned a weight of `0` for daily operations.
|
||||
- *Multi-Party (M-of-N) Escrow:* To prevent a single corrupt entity from hijacking an identity, Agora utilizes a *Recovery Council*. For instance, a rotation might require 2-of-3 signatures from designated entities (e.g., a Notary, a Law Firm, and a Decentralized Oracle).
|
||||
- *The Trigger:* The identity’s governing logic includes a rule: "If a certified Legal Attestation (e.g., signed by the local Court's Public Key) is presented, the Escrow Key's weight jumps to the necessary quorum threshold (e.g., 100) for a single Rotation Event."
|
||||
- *Observer-First Transparency:* Any change to the master key—including a legal override—must be published to the *Key Event Log (KEL)*. This ensures it's impossible for an agent to "quietly" take over an account; every user device and hired "watchdog" service is alerted immediately.
|
||||
- *The Veto Window (Time-Locking):* Any rotation event initiated by an Escrow Key triggers a mandatory 72-hour `Pending State`. If the primary owner still possesses their key (i.e., the agent is acting maliciously), they can sign a *Veto & Revoke* message. Because the Owner Key has absolute priority, this instantly kills the pending rotation and can strip the escrow agent of future rights. If the owner is incapacitated, they won't sign a veto, and after 72 hours, the change becomes final.
|
||||
- *Empowerment through Pre-authorization:* This allows the law to intervene technically—not through "hacking," but via a pre-authorized, transparent mechanism agreed upon during the identity's inception.
|
||||
|
||||
**** The "Dead Man's Switch" (Protocol Level Recovery)
|
||||
|
||||
To prevent assets from being "lost forever" if a user disappears unexpectedly:
|
||||
- **The Watcher:** A smart contract or a "Guardian Persona" monitors the user's on-chain and network activity.
|
||||
- **The Trigger:** If the Persona DID has zero "Key Activity" for a defined period (e.g., 12 months), a pre-designated Inheritance Key is authorized to initiate a recovery rotation.
|
||||
- **The Safety:** The user receives a "Warning Notification" (via DIDComm) every month leading up to the trigger. A single "Heartbeat" signature from their active phone resets the 12-month clock.
|
||||
- *The Watcher:* A smart contract or a "Guardian Persona" monitors the user's on-chain and network activity.
|
||||
- *The Trigger:* If the Persona DID has zero "Key Activity" for a defined period (e.g., 12 months), a pre-designated Inheritance Key is authorized to initiate a recovery rotation.
|
||||
- *The Safety:* The user receives a "Warning Notification" (via DIDComm) every month leading up to the trigger. A single "Heartbeat" signature from their active phone resets the 12-month clock.
|
||||
|
||||
***** Against Founder Malice
|
||||
|
||||
@@ -412,32 +412,32 @@ Each Persona in Agora is analogous to a legal person, possessing the inherent ri
|
||||
|
||||
**** Owner DID vs. Editor DID: The Mechanism of Agency
|
||||
Agora distinguishes between the identity that owns the content and the identity that cryptographically signs it. While these are identical in most personal interactions, their separation enables complex organizational and recovery workflows.
|
||||
- **Owner DID:** The source of authority, reputation, and ownership. This is the Persona "speaking" or "publishing." All social weight and historical context accrue to this DID.
|
||||
- **Editor DID:** The cryptographic actor performing the signature, recorded within the Note's `proof` object. This is the entity "signing" the data. The network verifies that the Editor holds a valid Delegation Certificate or is an authorized recovery key for the Owner. If omitted from the `proof`, it defaults to the Owner DID (self-signed).
|
||||
- *Owner DID:* The source of authority, reputation, and ownership. This is the Persona "speaking" or "publishing." All social weight and historical context accrue to this DID.
|
||||
- *Editor DID:* The cryptographic actor performing the signature, recorded within the Note's `proof` object. This is the entity "signing" the data. The network verifies that the Editor holds a valid Delegation Certificate or is an authorized recovery key for the Owner. If omitted from the `proof`, it defaults to the Owner DID (self-signed).
|
||||
|
||||
***** Key Use Cases for Separation
|
||||
1. **Organizational Delegation (The Assistant Model):** An NGO (Owner DID) issues a Delegation Certificate to an employee, Alice (Editor DID). Alice publishes updates using her own keys, but the network attributes them to the NGO.
|
||||
2. **AI Agent Accountability:** A Human (Owner DID) authorizes their personal AI Bot (Editor DID) to act on their behalf. Users can verify that a message is from the human while knowing it was technically generated and signed by their AI agent.
|
||||
3. **Legal Override & Recovery:** When a user loses their keys, a pre-authorized Recovery Council (Editor DID) signs a Key Rotation Event for the Incapacitated User (Owner DID), restoring their digital presence.
|
||||
4. **Guardianship:** A Parent (Editor DID) manages and signs events for a Minor (Owner DID) until a pre-defined maturation date.
|
||||
1. *Organizational Delegation (The Assistant Model):* An NGO (Owner DID) issues a Delegation Certificate to an employee, Alice (Editor DID). Alice publishes updates using her own keys, but the network attributes them to the NGO.
|
||||
2. *AI Agent Accountability:* A Human (Owner DID) authorizes their personal AI Bot (Editor DID) to act on their behalf. Users can verify that a message is from the human while knowing it was technically generated and signed by their AI agent.
|
||||
3. *Legal Override & Recovery:* When a user loses their keys, a pre-authorized Recovery Council (Editor DID) signs a Key Rotation Event for the Incapacitated User (Owner DID), restoring their digital presence.
|
||||
4. *Guardianship:* A Parent (Editor DID) manages and signs events for a Minor (Owner DID) until a pre-defined maturation date.
|
||||
|
||||
***** Technical Benefits
|
||||
- **Accountability:** Provides a transparent audit trail of the physical signers acting on behalf of an identity.
|
||||
- **Granular Revocation:** An Owner can revoke an Editor's access instantly without needing to change their own identity or rotate master keys.
|
||||
- **Reputation Portability:** Content history and social relationships stay with the Owner DID, regardless of which specific human or bot was authorized to sign at the time.
|
||||
- *Accountability:* Provides a transparent audit trail of the physical signers acting on behalf of an identity.
|
||||
- *Granular Revocation:* An Owner can revoke an Editor's access instantly without needing to change their own identity or rotate master keys.
|
||||
- *Reputation Portability:* Content history and social relationships stay with the Owner DID, regardless of which specific human or bot was authorized to sign at the time.
|
||||
|
||||
**** Cryptographic Delegated Signatures
|
||||
To allow multiple individuals (e.g., employees) or autonomous agents to act on behalf of a single Persona (e.g., an LLC or a brand account) without sharing the Master Key, Agora employs Delegated Signatures.
|
||||
- **The Delegation Certificate:** The "Owner" Persona signs a special `Delegation Certificate` granting specific capabilities to a "Delegate" DID for a defined period.
|
||||
- **Example Constraint:** "Delegate X can publish `is_feed: true` Notes on behalf of Owner Y, but cannot sign `contract` Notes."
|
||||
- **The Signature:** When the Delegate acts, they sign the Note with their *own* private key and append the Delegation Certificate. The network validates the certificate against the Owner's public key.
|
||||
- **Instant Revocation:** The Owner can instantly revoke the delegation by publishing a revocation event, cutting off the Delegate without needing to change passwords or rotate the Owner's keys.
|
||||
- *The Delegation Certificate:* The "Owner" Persona signs a special `Delegation Certificate` granting specific capabilities to a "Delegate" DID for a defined period.
|
||||
- *Example Constraint:* "Delegate X can publish `is_feed: true` Notes on behalf of Owner Y, but cannot sign `contract` Notes."
|
||||
- *The Signature:* When the Delegate acts, they sign the Note with their *own* private key and append the Delegation Certificate. The network validates the certificate against the Owner's public key.
|
||||
- *Instant Revocation:* The Owner can instantly revoke the delegation by publishing a revocation event, cutting off the Delegate without needing to change passwords or rotate the Owner's keys.
|
||||
|
||||
**** AI Agent Personas (AAP)
|
||||
Agora treats Artificial Intelligence not as a backend feature, but as a first-class participant.
|
||||
- **Agent DIDs:** An AI Agent is assigned its own derived Persona DID, completely separated from the human's primary identity.
|
||||
- **Capabilities-Based Security:** Using the Delegation mechanism above, the human owner grants the AI Agent restricted capabilities (e.g., "Authorized to spend up to 5000 sats/month" or "Authorized to draft responses but not publish them").
|
||||
- **Verifiable Origins:** Because the AI signs with its own DID, all network participants can instantly and cryptographically verify whether a piece of content was authored by a human or an AI.
|
||||
- *Agent DIDs:* An AI Agent is assigned its own derived Persona DID, completely separated from the human's primary identity.
|
||||
- *Capabilities-Based Security:* Using the Delegation mechanism above, the human owner grants the AI Agent restricted capabilities (e.g., "Authorized to spend up to 5000 sats/month" or "Authorized to draft responses but not publish them").
|
||||
- *Verifiable Origins:* Because the AI signs with its own DID, all network participants can instantly and cryptographically verify whether a piece of content was authored by a human or an AI.
|
||||
|
||||
*** Naming & Registry
|
||||
|
||||
@@ -457,17 +457,17 @@ Agora treats Artificial Intelligence not as a backend feature, but as a first-cl
|
||||
- *Domain-Based Names:* If a user doesn't own a custom domain, their PDS provider (e.g., a community hub) grants them a subdomain.
|
||||
- *Format:* `username.provider.org` (e.g., `alice.aletheia.social`).
|
||||
- *Handle Resolution Protocol:* The system MUST support multiple methods for resolving a human-readable handle to a DID:
|
||||
- **Method A (DNS TXT):** The client queries the DNS for a TXT record at `_atproto.alice.aletheia.social`.
|
||||
- **Method B (HTTPS Well-Known):** The client fetches the DID from `https://alice.aletheia.social/.well-known/atproto-did`.
|
||||
- *Method A (DNS TXT):* The client queries the DNS for a TXT record at `_atproto.alice.aletheia.social`.
|
||||
- *Method B (HTTPS Well-Known):* The client fetches the DID from `https://alice.aletheia.social/.well-known/atproto-did`.
|
||||
- *Cross-Namespace Resolution:* The network's Search Indexers MUST implement a "Resolver Bridge" to handle other ecosystems. For example, if a search matches a `.eth` name, the indexer queries the ENS Smart Contract on Ethereum to find the associated DID.
|
||||
- *Validation:* To prevent "spoofing," the DID document returned by the PDS MUST contain a back-link to the handle.
|
||||
- *Sovereignty:* If you move your PDS to your own custom domain, you take your name with you.
|
||||
|
||||
**** Multi-Persona Naming Convention
|
||||
Because users manage multiple Personas (Legal, Professional, Anonymous) derived from a single Master Seed, clients SHOULD implement a Persona-Suffix convention to distinguish them clearly within the Subdomain Model:
|
||||
- **Primary/Legal:** `name.provider.org` (e.g., `john.aletheia.social`)
|
||||
- **Professional:** `name-pro.provider.org` (e.g., `john-pro.aletheia.social`)
|
||||
- **Anonymous/Alt:** `alias.provider.org` (e.g., `night-owl.aletheia.social`)
|
||||
- *Primary/Legal:* `name.provider.org` (e.g., `john.aletheia.social`)
|
||||
- *Professional:* `name-pro.provider.org` (e.g., `john-pro.aletheia.social`)
|
||||
- *Anonymous/Alt:* `alias.provider.org` (e.g., `night-owl.aletheia.social`)
|
||||
|
||||
**** Web3 Naming Services (e.g., ENS)
|
||||
For users who want a username entirely untethered from a specific PDS provider's domain, Agora supports Decentralized Naming Services like Ethereum Name Service (ENS).
|
||||
@@ -519,16 +519,16 @@ For users who want a username entirely untethered from a specific PDS provider's
|
||||
|
||||
*** Zero-Knowledge Proofs (ZKP) & Selective Disclosure
|
||||
The system allows a user to "Attest" that two Personas belong to the same human (or hold the same credentials) *without revealing the Master Seed or creating a public cryptographic link*.
|
||||
- **The Problem:** Your "Anonymous Developer" Persona wants to prove it has a "Verified Citizen" badge issued to your "Legal Name" Persona.
|
||||
- **The ZKP Solution:** Using a Zero-Knowledge Proof, the user can cryptographically prove they hold the private key for the "Legal Name" DID (which holds the badge) and assert a statement on behalf of the "Anonymous" DID.
|
||||
- **Privacy Preservation:** The resulting proof verifies the credential is valid but explicitly hides *which* specific Legal Name DID generated the proof.
|
||||
- *The Problem:* Your "Anonymous Developer" Persona wants to prove it has a "Verified Citizen" badge issued to your "Legal Name" Persona.
|
||||
- *The ZKP Solution:* Using a Zero-Knowledge Proof, the user can cryptographically prove they hold the private key for the "Legal Name" DID (which holds the badge) and assert a statement on behalf of the "Anonymous" DID.
|
||||
- *Privacy Preservation:* The resulting proof verifies the credential is valid but explicitly hides *which* specific Legal Name DID generated the proof.
|
||||
|
||||
**** Attribute-Based Predicate Proofs
|
||||
Agora extends ZKP capabilities beyond cross-persona linking to support **Selective Disclosure** and **Predicate Proofs** using Verifiable Credentials (VCs) with advanced cryptographic schemas (e.g., BBS+ signatures or AnonCreds). This allows Personas to prove attributes about their physical or financial reality without leaking metadata or underlying identifiers.
|
||||
- **Age/Date Verification:** A Persona can cryptographically prove a predicate like `Age > 18` to access age-restricted content or contracts without revealing their actual date of birth.
|
||||
- **Financial Ability:** A Persona can prove `Wallet Balance > 10,000 sats` or `Monthly Income > X` to serve as collateral or qualify for a service contract without revealing their exact balance or transaction history to the counterparty.
|
||||
- **Citizenship & Residence:** A Persona can prove membership in a specific geographic jurisdiction (e.g., "Resident of New York") for local governance voting or tax-compliant commerce without disclosing their legal name or specific home address.
|
||||
- **Asset Ownership:** A Persona can prove ownership of a specific Physical Asset Link (PAL) or digital token to gain entry to a gated community or guild without linking that high-value asset to their everyday public identity.
|
||||
Agora extends ZKP capabilities beyond cross-persona linking to support *Selective Disclosure* and *Predicate Proofs* using Verifiable Credentials (VCs) with advanced cryptographic schemas (e.g., BBS+ signatures or AnonCreds). This allows Personas to prove attributes about their physical or financial reality without leaking metadata or underlying identifiers.
|
||||
- *Age/Date Verification:* A Persona can cryptographically prove a predicate like `Age > 18` to access age-restricted content or contracts without revealing their actual date of birth.
|
||||
- *Financial Ability:* A Persona can prove `Wallet Balance > 10,000 sats` or `Monthly Income > X` to serve as collateral or qualify for a service contract without revealing their exact balance or transaction history to the counterparty.
|
||||
- *Citizenship & Residence:* A Persona can prove membership in a specific geographic jurisdiction (e.g., "Resident of New York") for local governance voting or tax-compliant commerce without disclosing their legal name or specific home address.
|
||||
- *Asset Ownership:* A Persona can prove ownership of a specific Physical Asset Link (PAL) or digital token to gain entry to a gated community or guild without linking that high-value asset to their everyday public identity.
|
||||
|
||||
**** Verification Object Schema
|
||||
|
||||
@@ -570,19 +570,19 @@ Personas are the functional, active identities through which you engage with the
|
||||
|
||||
*** Key Event Log (KEL): The Observer-First Transparency Log
|
||||
Every Persona in Agora maintains a Key Event Log (KEL). This is a public, append-only ledger of all identity-related events, including:
|
||||
- **Key Events:** Inception, rotation, and revocation.
|
||||
- **Follow Events:** Every time you follow another DID, a signed "Follow Event" is added to the log.
|
||||
- **Transparency:** It is impossible to "quietly" take over an account or manipulate your public history. Any change to the keys or following relationships must be published to the log. Watchdog services can monitor this log and alert the user immediately if an unauthorized event is initiated.
|
||||
- *Key Events:* Inception, rotation, and revocation.
|
||||
- *Follow Events:* Every time you follow another DID, a signed "Follow Event" is added to the log.
|
||||
- *Transparency:* It is impossible to "quietly" take over an account or manipulate your public history. Any change to the keys or following relationships must be published to the log. Watchdog services can monitor this log and alert the user immediately if an unauthorized event is initiated.
|
||||
|
||||
**** Social Graph Reconstruction
|
||||
The "Social Graph" (the list of DIDs you follow and who follows you) is mathematically reconstructible from the KEL.
|
||||
- **The Proof:** Follow Events (Notes) are cryptographically signed by the Persona's authorized keys (or the Master Key).
|
||||
- **The Rebuild:** When initializing a new PDS, the software scans the network and subscribed Relays for any signed Follow Events belonging to the user's DID. It automatically reconstructs the user's entire social graph (e.g., a list of 500 friends) without the user needing to remember a single username or manual backup.
|
||||
- *The Proof:* Follow Events (Notes) are cryptographically signed by the Persona's authorized keys (or the Master Key).
|
||||
- *The Rebuild:* When initializing a new PDS, the software scans the network and subscribed Relays for any signed Follow Events belonging to the user's DID. It automatically reconstructs the user's entire social graph (e.g., a list of 500 friends) without the user needing to remember a single username or manual backup.
|
||||
|
||||
*** Pre-rotation: Quantum-Resistant Continuity
|
||||
Agora utilizes the principle of *Pre-rotation* to ensure forward security as an ultimate fail-safe.
|
||||
- **The Hash Commitment:** When a user creates their current active key, they simultaneously publish a cryptographic hash of their *next* (unborn) public key.
|
||||
- **The Protection:** Even if an attacker breaks the user's current private key (e.g., via a future quantum computer, theft, or even a malicious legal override attempt), they cannot forge a rotation event because they do not know the private key corresponding to the pre-committed hash. Rotation only becomes valid when the user reveals the new key that matches the previous hash, providing true "forward security."
|
||||
- *The Hash Commitment:* When a user creates their current active key, they simultaneously publish a cryptographic hash of their *next* (unborn) public key.
|
||||
- *The Protection:* Even if an attacker breaks the user's current private key (e.g., via a future quantum computer, theft, or even a malicious legal override attempt), they cannot forge a rotation event because they do not know the private key corresponding to the pre-committed hash. Rotation only becomes valid when the user reveals the new key that matches the previous hash, providing true "forward security."
|
||||
|
||||
**** Technical Requirements
|
||||
- *Interface:* Clients MUST support communication via *WebHID* (browser-based) or *USB/HID* (native) using the standard *APDU* (Application Protocol Data Unit) format.
|
||||
@@ -600,10 +600,10 @@ Agora utilizes the principle of *Pre-rotation* to ensure forward security as an
|
||||
The "Vault" is a dedicated application for an offline/hardware device that manages the Master Seed.
|
||||
|
||||
**** Functional Requirements for the Vault Tool:
|
||||
- **Seed Generation:** Must use a high-entropy hardware RNG to generate the BIP-39 mnemonic.
|
||||
- **Persona Derivation:** Must implement a hardened derivation logic where the user can "Export Persona #N."
|
||||
- **Key Rotation Editor:** This is the most important feature. If a phone is lost, the Vault device creates a DID Update Transaction. This is a cryptographically signed message that says: "I am the Master Seed; I hereby revoke Persona Key A and authorize Persona Key B."
|
||||
- **Recovery Seed Export:** The Vault should allow exporting a "Recovery Key"—a special key used specifically for the "Re-Wrapping" process on the PDS during content re-keying.
|
||||
- *Seed Generation:* Must use a high-entropy hardware RNG to generate the BIP-39 mnemonic.
|
||||
- *Persona Derivation:* Must implement a hardened derivation logic where the user can "Export Persona #N."
|
||||
- *Key Rotation Editor:* This is the most important feature. If a phone is lost, the Vault device creates a DID Update Transaction. This is a cryptographically signed message that says: "I am the Master Seed; I hereby revoke Persona Key A and authorize Persona Key B."
|
||||
- *Recovery Seed Export:* The Vault should allow exporting a "Recovery Key"—a special key used specifically for the "Re-Wrapping" process on the PDS during content re-keying.
|
||||
|
||||
*** Hardware Integration: Sphinx for Your Keys
|
||||
**** Technical Requirements
|
||||
|
||||
Reference in New Issue
Block a user