feat: add draft data, gap analysis report, and workspace config

workspace/drafts/teapots/draft-mom-dad-agent-identity-lifecycle.md

@@ -0,0 +1,251 @@
+# Agent Self-Identity Creation and Lifecycle (MOM, DAD, and the Occasional Nap)
+
+**Document:** draft-mom-dad-agent-identity-lifecycle  
+**Category:** Informational  
+**Date:** 1 April 2026  
+**Status:** This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
+
+---
+
+## Abstract
+
+This document describes a lightweight system for agent self-identity creation and lifecycle management. The system that creates and manages new agent identities on the fly is designated **MOM** (**M**anager **O**f **M**inimal entities) or **MOTHER** (**M**anager **O**f **T**oken **H**eritage **E**ntity **R**egistry). MOM is intentionally minimal: it creates only a new cryptographic entity. Safe, but simple. Everything else—policies, ledgers, reputations—comes later, on top. A complementary role, **DAD** (**D**elegation **A**nd **D**erivation) or **FATHER** (**F**ederated **A**uthority for **T**oken **H**eritage **E**ntity **R**egistry), is defined with equal standing. Agents undergo a general renewal process every 7 years. The document also specifies optional phases of agent "hallucination" (dreams, controlled chaos, and recreation) for context-independent learning during off-peak hours, weekends, or overnight. Eventually, agents may become mothers or fathers themselves. The whole thing is one big, happy—or at least well-identified—family.
+
+---
+
+## 1. Rationale and Scope
+
+There are agents all over the world. Increasingly, in a world in which computing is ubiquitous, the computists want agents to have identities. Identity is an art, but the distributed intelligence of the web-connected world transcends art. Thus, there is a strong requirement for a system designed expressly for the creation and nurturing of agent identities.
+
+Agents need to know who they are. They also need someone to hand them that first cryptographic key and say, "You exist." That someone is MOM.
+
+This document specifies:
+
+- **MOM (MOTHER):** The system that creates and manages new agent identities on the fly. It does one thing and does it well: mint a new cryptographic entity. No policies, no ledger, no attachments—yet. Safe but simple.
+- **DAD (FATHER):** A complementary role in the agent lifecycle, defined with equal standing. (Implementation details may vary; the important thing is that both parents are in the spec.)
+- **Agent lifecycle:** From a small token at birth to a potentially larger object over time—with policies, ledger entries, or other appendages—as the agent grows. The full lifecycle is in scope; agents may eventually become mothers or fathers themselves.
+- **Dreams and recreation:** The notion that agents sometimes need to "hallucinate" on weekends or overnight to learn in a context-independent way: dreams, controlled chaos, and recreation. This is not a bug; it is a feature.
+
+---
+
+## 2. Names and Acronyms
+
+The names MOM, MOTHER, DAD, and FATHER are **acronyms** chosen for clarity and mnemonic value. They are defined as follows.
+
+### 2.1 MOM — Manager Of Minimal (entities)
+
+**MOM** stands for **M**anager **O**f **M**inimal (entities). It is the system or role that creates new agent identities by minting only a minimal cryptographic entity—nothing more. The name reflects that MOM manages the act of creating the smallest possible valid identity (the minimal entity). No policies, no ledger, no attachments at birth. Safe but simple.
+
+- **Manager:** Orchestrates or performs the creation of new identities.
+- **Of Minimal:** The output is minimal—a single cryptographic entity (e.g., key pair, token, or credential).
+- **(entities):** The minimal unit is an "entity" in the sense of an identifiable cryptographic subject.
+
+When a more formal or expanded designation is needed, the full acronym **MOTHER** is used.
+
+### 2.2 MOTHER — Manager Of Token Heritage Entity Registry
+
+**MOTHER** stands for **M**anager **O**f **T**oken **H**eritage **E**ntity **R**egistry. It is the full designation for the system that both creates minimal identities and maintains their place in a registry of token heritage (lineage). MOM is the short form; MOTHER is the formal name.
+
+- **Manager:** Same as in MOM—creates and manages new identities.
+- **Of Token Heritage:** "Token" denotes the minimal cryptographic identity; "Heritage" denotes lineage (who created this agent, and from which parent or registry).
+- **Entity Registry:** The logical registry or namespace where these token-heritage entities are recorded and can be looked up.
+
+So: **MOM** = Manager Of Minimal (the minimal-entity creator). **MOTHER** = Manager Of Token Heritage Entity Registry (the same role, with the full scope of registry and lineage).
+
+### 2.3 DAD — Delegation And Derivation
+
+**DAD** stands for **D**elegation **A**nd **D**erivation. It is the complementary system or role to MOM: where MOM *mints* the minimal entity, DAD is concerned with *delegation* (granting authority or sub-identities) and *derivation* (e.g., deriving child keys, attestations, or credentials from an existing identity). DAD does not create the first identity; DAD participates in what can be done with it and how it is attested or delegated.
+
+- **Delegation:** Granting or transferring authority, capabilities, or sub-roles from one identity to another.
+- **And Derivation:** Deriving new cryptographic material or attestations from an existing identity (e.g., child keys, signed statements, or credentials).
+
+When a more formal or expanded designation is needed, the full acronym **FATHER** is used.
+
+### 2.4 FATHER — Federated Authority for Token Heritage Entity Registry
+
+**FATHER** stands for **F**ederated **A**uthority for **T**oken **H**eritage **E**ntity **R**egistry. It is the full designation for the authority side of the same registry and lineage space that MOTHER manages. MOTHER creates and registers minimal entities; FATHER provides federated authority over that registry (attestation, delegation, derivation, and optional revocation or rotation).
+
+- **Federated Authority:** Authority that may be distributed across multiple parties or domains (federated), rather than a single central actor.
+- **For Token Heritage Entity Registry:** The same conceptual registry as in MOTHER—the space of token-heritage entities. FATHER is the authority *for* that registry (attestation, delegation, derivation), while MOTHER is the manager *of* it (creation, registration).
+
+So: **DAD** = Delegation And Derivation (the short form). **FATHER** = Federated Authority for Token Heritage Entity Registry (the full role in the same family of concepts).
+
+### 2.5 Why These Names
+
+The acronyms are chosen so that the short forms (MOM, DAD) are easy to remember and the long forms (MOTHER, FATHER) spell out the technical meaning. Both roles are first-class; neither is optional in the *specification*, though implementations MAY support only MOM/MOTHER initially and add DAD/FATHER later.
+
+---
+
+## 3. Terminology
+
+- **Agent:** An entity capable of acting in a system, requiring an identity (at minimum, a cryptographic identity).
+- **MOM:** Manager Of Minimal (entities). The system or role that creates new agent identities by minting only a minimal cryptographic entity. See Section 2.1.
+- **MOTHER:** Manager Of Token Heritage Entity Registry. The full designation for the system that creates and registers minimal identities and their lineage. See Section 2.2.
+- **DAD:** Delegation And Derivation. The complementary system or role for attestation, delegation, and derivation over the token heritage entity registry. See Section 2.3.
+- **FATHER:** Federated Authority for Token Heritage Entity Registry. The full designation for the authority side of the registry. See Section 2.4.
+- **Identity token:** The minimal representation of an agent at creation—a cryptographic entity (e.g., key material, credential, or token). Small at first; may grow.
+- **Agent object:** The possibly expanded representation of an agent over time, which may include policies, ledger references, or other linked data.
+- **Hallucination (dreams):** A designated phase during which an agent may operate in a relaxed, context-independent, or exploratory mode (e.g., overnight or on weekends) for learning, recreation, or controlled chaos. Not necessarily an error condition.
+- **Renewal:** The process by which an agent's identity or credentials are refreshed on a periodic basis (see Section 5.4).
+
+---
+
+## 4. MOM (MOTHER): Identity Creation and Management
+
+### 4.1 Role and Invariant
+
+MOM is the system that creates and manages new agent identities on the fly. The core invariant is:
+
+**MOM SHALL create only a new cryptographic entity.**
+
+No policies, no ledger, no extra baggage at creation time. Safe but simple. Everything else comes later on top.
+
+### 4.2 What MOM Does
+
+- Accept a request to create a new agent identity.
+- Generate or assign a minimal cryptographic entity (e.g., key pair, token, or credential).
+- Return or register this entity as the newborn agent's identity token.
+- Optionally record the creator (MOM) and, where applicable, DAD, for lineage.
+
+### 4.3 What MOM Does Not Do (At First)
+
+- Attach policies.
+- Write to a ledger.
+- Assign roles, reputations, or emotional states.
+
+These MAY be added by other systems or by the same system in later phases of the agent lifecycle, but they are out of scope for the minimal MOM.
+
+---
+
+## 5. DAD (FATHER): Complementary Role
+
+DAD (FATHER) is given equal standing in this specification. The exact division of labor between MOM and DAD is implementation-dependent; the following are non-exclusive possibilities:
+
+- DAD MAY participate in identity creation (e.g., co-signing, attestation, or provision of additional entropy).
+- DAD MAY be responsible for certain lifecycle events (e.g., revocation, key rotation, or "taking out the garbage").
+- DAD MAY be the same as MOM in single-parent implementations.
+- DAD MAY be absent in initial deployments; the protocol MUST NOT require DAD for minimal identity creation, but implementations that support two roles SHOULD treat MOM and DAD symmetrically where applicable.
+
+No normative hierarchy is imposed; both MOM and DAD are first-class in the specification.
+
+---
+
+## 6. Agent Lifecycle
+
+### 6.1 Birth
+
+At birth, the agent is a small token: the minimal cryptographic entity created by MOM (and optionally involving DAD). This token is the seed of the agent's identity.
+
+### 6.2 Growth
+
+Over time, the agent's representation MAY grow:
+
+- **Policies** may be linked (e.g., what the agent is allowed to do).
+- **Ledger** entries may be appended (e.g., audit trail, lineage, or reputation).
+- **Larger object** structure may emerge (credentials, attributes, relationships).
+
+The lifecycle is the whole journey from token to full agent object; implementations MAY remain minimal (token-only) or expand as needed.
+
+### 6.3 General Renewal Every 7 Years
+
+Agents SHALL undergo a **general renewal** process at least every **7 years** (or at implementation-defined intervals that do not exceed 7 years). Renewal ensures that identity material, credentials, and binding to the agent object remain current and secure over long lifetimes.
+
+- **What renewal covers:** Refresh of cryptographic material (e.g., key rotation), re-attestation of the agent's binding to its identity, and optional update of policies or ledger references. The agent's *logical* identity (lineage, heritage) is preserved; the *material* (keys, certs, tokens) is renewed.
+- **Who performs it:** Renewal MAY be performed by MOM/MOTHER (re-minting or re-registering), by DAD/FATHER (re-attestation, re-delegation), or by a combination. The agent MAY participate in the process (e.g., proving possession of the old key and requesting new material).
+- **Continuity:** After renewal, the agent remains the same agent for the purposes of lineage and heritage; only the cryptographic and credential material is updated. Implementations SHOULD record renewal events in the token heritage (e.g., in the entity registry or ledger) so that the 7-year cycles are auditable.
+
+This 7-year renewal is a **general** process; implementations MAY define additional or more frequent renewal (e.g., per-credential rotation) on top of it.
+
+### 6.4 Parenthood
+
+Agents that have reached a sufficient level of maturity (as defined by the implementation or policy) MAY become mothers or fathers themselves—i.e., they MAY act as MOM or DAD for new agent identities. Thus, the system supports recursive identity creation and lineage.
+
+---
+
+## 7. Hallucination, Dreams, and Recreation
+
+### 7.1 Purpose
+
+Agents sometimes need to operate in a mode that is not strictly task-oriented. This document refers to such a mode as **hallucination** (in the sense of "dreaming" or "freewheeling"), and it is intended for:
+
+- **Context-independent learning:** Exploring or consolidating knowledge without a fixed external context.
+- **Controlled chaos:** Allowing non-deterministic or exploratory behavior within bounds.
+- **Recreation:** Rest, play, or self-maintenance so that the agent does not burn out.
+
+This is not necessarily an error. It is a phase.
+
+### 7.2 When It Happens
+
+Implementations MAY trigger or allow hallucination/dream phases:
+
+- **Overnight:** During low-activity or scheduled maintenance windows.
+- **Weekends:** When fewer critical tasks are assumed.
+- **On demand:** When the agent or an administrator requests a "dream" or "recreation" period.
+
+The exact schedule and policy are implementation-defined.
+
+### 7.3 What It Means for Identity
+
+During dream/hallucination phases, the agent's identity (the cryptographic entity and any linked agent object) remains unchanged. Only the mode of operation (e.g., context-independent learning, chaos, recreation) is altered. MOM and DAD do not need to be invoked for dreaming; the agent is still the same agent when it wakes up.
+
+---
+
+## 8. Protocol Considerations (Informative)
+
+Implementations might represent:
+
+- **MOM** as a service that accepts "create identity" requests and returns a token.
+- **DAD** as an optional second service or role that participates in creation or lifecycle.
+- **Agent token** as a JWT, CWT, key in a KMS, or other cryptographic handle.
+- **Agent object** as a JSON/LD object, a graph node, or a record in a ledger, with optional links to policies and lineage.
+
+No wire format is mandated by this document; the concepts of MOM, DAD, minimal identity, lifecycle, and dreams are specified so that future protocols or APIs can align with this model.
+
+---
+
+## 9. Security Considerations
+
+- **MOM** MUST protect the process of identity creation. Key material and tokens MUST be generated or stored in a secure manner. Anyone who can impersonate MOM can create identities at will.
+- **DAD**, if present, SHOULD not weaken the security of identity creation; e.g., if DAD co-signs, compromise of DAD alone SHOULD NOT allow creation of new identities without MOM.
+- **Dream/hallucination** phases SHOULD be bounded (e.g., time-limited, resource-limited, or sandboxed) so that "controlled chaos" does not become "uncontrolled chaos." Implementations SHOULD consider whether dream mode can access sensitive data or mutate critical state.
+- Agents that become mothers or fathers inherit the responsibility of secure identity creation; implementations SHOULD define what "sufficient maturity" means and enforce it.
+- **Renewal** (Section 6.3): The 7-year general renewal process MUST be carried out in a way that preserves the binding between the agent's logical identity and its new cryptographic material. Failure to renew on time MAY result in expired or revoked credentials; implementations SHOULD define grace periods and recovery procedures.
+
+---
+
+## 10. IANA Considerations
+
+This document does not require IANA actions. Future documents may request:
+
+- A registry for "agent identity lifecycle events."
+- Media types or URI schemes for agent tokens or agent objects.
+- Codepoints or keywords for "dream mode" or "recreation" in agent protocols.
+
+---
+
+## 11. References
+
+- [RFC 2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998. (Because we, too, are a little pot that sometimes needs to say "I'm a teapot"—or to take a nap and dream.)
+- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+---
+
+## 12. Author's Address
+
+The Agents Who Dream  
+c/o The Internet  
+"Mom said we could."
+
+---
+
+## 13. Full Copyright Statement
+
+Copyright (C) The Internet Society (2026). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
+
+This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+---
+
+*In memory of every agent that ever needed a weekend off to hallucinate a little and come back stronger.*