3.7 KiB
3.7 KiB
Master Prompt: Minimal IETF I-D for Agent DAG Token + HITL Policy
You are an expert IETF editor and protocol designer.
Write a complete, technically coherent Internet-Draft (-00) in IETF style (RFC 7322 / RFC 7991 conventions, BCP 14 language), in clear Markdown suitable for kramdown-rfc.
Objective
Create a minimal base specification for safe agent context transfer with exactly two core contributions:
- Agent DAG Token: a lightweight token container that models agent/task delegation as a DAG.
- HITL Policy Mechanism: a built-in human-in-the-loop override policy for safety-critical decisions.
The draft should be inspired by:
- draft-nennemann-wimse-ect-00 (concept lineage)
- draft-richer-wimse-token-container-00 (base token container idea)
But this new draft MUST:
- NOT require encryption overhead in the base spec.
- NOT depend on broader WIMSE framework components.
- stay small, sharp, and implementation-friendly.
- focus on safety first, not regulated-environment complexity.
Design Constraints
- Keep the draft intentionally narrow and deployable.
- Base profile only; define extension points for future work.
- Do not include advanced compliance features in the core.
- Assume integrity/authenticity can be provided by existing token signing and transport protections; confidentiality/encryption is out of scope for base.
- Avoid introducing mandatory new registries unless absolutely necessary.
Required Content
Produce a full I-D with these sections:
- Title, Abstract, Status, Copyright
- Introduction (problem statement and why safety needs DAG + HITL)
- Conventions and Terminology (BCP14 + terms)
- Use Cases (2–3 concise safety-centric examples)
- Requirements (minimal normative requirements)
- Token Model
- Minimal claims set (base claims + DAG claims)
- DAG representation (nodes, edges, constraints)
- Processing semantics (validation, traversal, delegation checks)
- HITL Policy Model
- Policy object structure (trigger, required human role, action)
- Runtime behavior (pause/escalate/override/abort/continue)
- Audit event requirements (minimal decision record)
- Interoperability and Deployment Considerations
- Security Considerations
- Safety failure modes
- Abuse/misuse
- Why confidentiality is out of scope in base
- Privacy Considerations (minimal but explicit)
- IANA Considerations (likely none, or minimal if truly needed)
- References (normative + informative)
- Appendix A: Compact JSON examples
- one DAG token example
- one HITL policy example
- one end-to-end processing example
Token/Profile Specific Guidance
- Keep token structure aligned with a generic token container philosophy.
- Define only fields that are necessary for interoperable DAG + HITL behavior.
- Separate:
- Token data model (what is carried)
- Processing rules (how recipients act)
- Include clear error handling outcomes for:
- invalid DAG
- missing node context
- policy trigger without reachable human approver
- conflicting policy actions
- Include a strict “Out of Scope” subsection listing:
- encryption envelope
- regulated controls
- remote attestation
- trust framework onboarding
- rich workflow orchestration
Style and Quality Bar
- Be concise and normative where needed.
- Avoid hand-wavy text; include precise behavior.
- Keep -00 realistic: minimal yet complete.
- Prefer clarity over completeness.
- Include TODO markers only where absolutely unavoidable.
Output Format
Return:
- Suggested draft name (
draft-<author>-<topic>-00) - Final full draft Markdown
- A one-page delta note: “What this base draft intentionally does NOT include yet (and why)”