99 lines
3.7 KiB
Markdown
99 lines
3.7 KiB
Markdown
# 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:
|
||
|
||
1. **Agent DAG Token**: a lightweight token container that models agent/task delegation as a DAG.
|
||
2. **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:
|
||
|
||
1. Title, Abstract, Status, Copyright
|
||
2. Introduction (problem statement and why safety needs DAG + HITL)
|
||
3. Conventions and Terminology (BCP14 + terms)
|
||
4. Use Cases (2–3 concise safety-centric examples)
|
||
5. Requirements (minimal normative requirements)
|
||
6. Token Model
|
||
- Minimal claims set (base claims + DAG claims)
|
||
- DAG representation (nodes, edges, constraints)
|
||
- Processing semantics (validation, traversal, delegation checks)
|
||
7. HITL Policy Model
|
||
- Policy object structure (trigger, required human role, action)
|
||
- Runtime behavior (pause/escalate/override/abort/continue)
|
||
- Audit event requirements (minimal decision record)
|
||
8. Interoperability and Deployment Considerations
|
||
9. Security Considerations
|
||
- Safety failure modes
|
||
- Abuse/misuse
|
||
- Why confidentiality is out of scope in base
|
||
10. Privacy Considerations (minimal but explicit)
|
||
11. IANA Considerations (likely none, or minimal if truly needed)
|
||
12. References (normative + informative)
|
||
13. 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:
|
||
|
||
1. **Suggested draft name** (`draft-<author>-<topic>-00`)
|
||
2. **Final full draft Markdown**
|
||
3. **A one-page delta note**: “What this base draft intentionally does NOT include yet (and why)”
|