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

workspace/drafts/new-drafts/draft-e-apae-assurance-profiles-01.md

@@ -0,0 +1,695 @@
+---
+title: "Assurance Profiles for Agent Ecosystems (APAE)"
+abbrev: "APAE"
+category: info
+docname: draft-apae-assurance-profiles-01
+submissiontype: IETF
+number:
+date:
+v: 3
+area: "SEC"
+workgroup: "Security Dispatch"
+keyword:
+  - dynamic trust
+  - assurance
+  - behavior verification
+  - data provenance
+  - quarantine
+
+author:
+  -
+    fullname: TBD
+    organization: Independent
+    email: placeholder@example.com
+
+normative:
+  RFC2119:
+  RFC8174:
+  RFC7519:
+  RFC7518:
+  RFC9110:
+  I-D.nennemann-wimse-ect:
+    title: "Execution Context Tokens for Distributed Agentic Workflows"
+    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
+  I-D.nennemann-agent-dag-hitl-safety:
+    title: "Agent Context Policy Token: DAG Delegation with Human Override"
+    target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
+
+informative:
+  RFC9334:
+
+--- abstract
+
+This document defines Assurance Profiles for Agent Ecosystems
+(APAE): dynamic trust scoring, behavior verification, data
+provenance, cross-domain trust, and graduated assurance profiles
+that allow the same agent ecosystem to operate in relaxed
+(dev/K8s) and regulated (healthcare, finance) environments.
+Trust events are derived from ECT outcomes.  Trust assertions are
+ECTs.  Behavior verification references ECT claims.  Provenance
+chains are implicit in the ECT DAG.  Assurance profiles select
+which combination of these mechanisms is required for a given
+deployment, mapping to ECT assurance levels L1/L2/L3.  Agents
+whose trust falls below a floor are quarantined via a protocol
+defined here.
+
+--- middle
+
+# Introduction
+
+Identity verifies who an agent is.  ECT records what an agent did.
+But neither answers: should I rely on this agent?  Is it doing what
+it promised?  Can I trace where this data came from?
+
+APAE adds four capabilities to the ecosystem:
+
+1. **Dynamic trust scoring** — behavioral reputation that adjusts
+   based on interaction outcomes (AIMD model).
+2. **Behavior verification** — checking agent actions against
+   declared specifications.
+3. **Data provenance** — tracing data lineage through the DAG.
+4. **Cross-domain trust** — federating trust across administrative
+   domains.
+
+These capabilities are bundled into assurance profiles
+(Relaxed, Standard, Regulated) that map to ECT assurance levels,
+so the same ecosystem works from a dev cluster to a hospital.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+Trust Score:
+: A floating-point value in \[0.0, 1.0\] representing one agent's
+  assessed reliability of another.
+
+Trust Event:
+: An interaction outcome that causes a trust score adjustment.
+  Derived from ECTs.
+
+Trust Domain:
+: An administrative boundary within which a single trust anchor
+  (CA or JWK set) governs agent identity.
+
+Behavior Specification:
+: A machine-readable declaration of permitted agent actions and
+  constraints.
+
+Provenance Chain:
+: The sequence of ECT nodes recording how a piece of data was
+  produced, transformed, and consumed.
+
+Assurance Profile:
+: A named configuration selecting which trust, verification, and
+  provenance mechanisms are required.
+
+Quarantine:
+: A state in which an agent's trust score has dropped below a
+  configured floor; the agent is prohibited from accepting new
+  delegations.
+
+# Dynamic Trust Scoring {#trust}
+
+## Trust Score Model
+
+Each agent maintains a trust table: peer agent IDs mapped to
+trust scores.  Initial trust for unknown agents is deployment-
+configured (RECOMMENDED: 0.5; zero-trust deployments: 0.1).
+
+Scores update using additive-increase, multiplicative-decrease
+(AIMD):
+
+- Positive event: `score = min(1.0, score + alpha)`
+- Negative event: `score = max(0.0, score * beta)`
+
+Defaults: `alpha = 0.01`, `beta = 0.8`.
+
+Trust builds slowly (100 successes: 0.5 → ~1.0) and drops fast
+(one failure: 0.82 → 0.66).
+
+## Trust Events from ECT {#trust-events}
+
+Trust events are derived from ECTs rather than agent-local
+counters, making trust computation auditable:
+
+| ECT condition | Event | Adjustment |
+|--------------|-------|------------|
+| Completed, no error follows | `task_success` | +1x alpha |
+| Completed, partial result | `task_partial` | +0.5x alpha |
+| `atd:error` referencing agent | `task_failure` | 1x beta |
+| No response within threshold | `task_timeout` | 1x beta |
+| `atd:error` with `constraint_violation` | `policy_violation` | beta^2 |
+| ECT signature verification fails | `attestation_invalid` | beta^2 |
+| `atd:rollback_request` targeting agent | `rollback_triggered` | 1x beta |
+{: #fig-events title="Trust Events from ECT"}
+
+## Trust Decay
+
+If no interaction occurs for a configurable period (default:
+7 days): `score = max(initial_default, score - 0.01/day)`.
+
+## Trust Assertions as ECT {#trust-assertions}
+
+Agent A shares its trust assessment via a trust assertion ECT:
+
+- `exec_act`: `"apae:trust_assertion"`
+
+~~~json
+{
+  "exec_act": "apae:trust_assertion",
+  "ext": {
+    "apae.subject": "spiffe://example.com/agent/b",
+    "apae.trust_score": 0.82,
+    "apae.interactions": 147,
+    "apae.confidence": "high",
+    "apae.hops": 0
+  }
+}
+~~~
+{: #fig-assertion title="Trust Assertion ECT"}
+
+Confidence: `low` (<10 interactions), `medium` (10-99),
+`high` (100+).
+
+Trust assertion ECTs MUST be signed at L2/L3.
+
+## Trust Propagation
+
+When Agent C receives A's assertion about B:
+
+~~~
+c_score_for_b = max(c_score_for_b,
+                    a_score * trust_of_a * attenuation)
+~~~
+
+Default `attenuation`: 0.5.  Direct observations always take
+precedence.  `apae.hops` tracks propagation depth; agents MUST NOT
+propagate beyond their configured maximum (default: 1).
+
+## Trust Thresholds as Policy
+
+Trust thresholds are ACP-DAG-HITL node constraints:
+
+~~~json
+{
+  "constraints": {
+    "apae.min_trust": 0.7,
+    "apae.min_confidence": "medium"
+  }
+}
+~~~
+{: #fig-threshold title="Trust Threshold as Node Constraint"}
+
+Requests from agents below threshold MUST be denied with HTTP 403.
+The `apae.peer_trust_score` is a runtime context value derived
+from the trusting agent's trust table for the requesting peer;
+it is not an ECT claim itself.
+
+Low trust can trigger HITL escalation:
+
+~~~json
+{
+  "id": "r-low-trust",
+  "trigger": {
+    "kind": "confidence_below",
+    "op": "lt",
+    "value": 0.5,
+    "input_ref": "apae.peer_trust_score"
+  },
+  "required_role": "operator:security",
+  "action": "escalate",
+  "allow_override": true,
+  "override_action": "continue"
+}
+~~~
+{: #fig-trust-hitl title="HITL Rule for Low Trust"}
+
+## Automatic Revocation
+
+When trust drops below a floor (default: 0.2), the trusting agent
+SHOULD revoke delegations and emit:
+`exec_act: "apae:trust_revoke"`.
+
+# Quarantine Protocol {#quarantine}
+
+When a trust score drops below the configured quarantine floor
+(default: 0.15), the agent enters quarantine.
+
+## Quarantine Entry
+
+The detecting agent MUST emit a quarantine ECT:
+
+~~~json
+{
+  "exec_act": "apae:quarantine",
+  "ext": {
+    "apae.subject": "spiffe://example.com/agent/b",
+    "apae.score": 0.12,
+    "apae.threshold": 0.15,
+    "apae.quarantine_until": "2026-03-02T12:00:00Z",
+    "apae.reason": "Repeated policy_violation events (3 in 1 hour)"
+  }
+}
+~~~
+{: #fig-quarantine title="Quarantine ECT"}
+
+The quarantine ECT MUST be broadcast to all agents that have
+received trust assertions about the quarantined agent
+(via `apae:trust_assertion` with matching `apae.subject`).
+
+## Quarantined Agent Behavior
+
+While quarantined, a subject agent:
+
+- MUST NOT accept new delegations.  New delegation requests MUST
+  return HTTP 503 with `Retry-After` set to `apae.quarantine_until`.
+- MUST complete in-progress workflows (drain behavior per AEPB).
+- MAY accept direct operator commands (HITL Level 4 is unaffected).
+
+Agents receiving the quarantine notification MUST update their
+trust table and MUST NOT delegate new tasks to the quarantined
+agent until the quarantine expires or is lifted.
+
+## Quarantine Duration
+
+The default quarantine duration is 1 hour, doubling on each
+successive quarantine entry:
+
+| Quarantine count | Duration |
+|-----------------|---------|
+| 1 | 1 hour |
+| 2 | 2 hours |
+| 3 | 4 hours |
+| n | 2^(n-1) hours (max 168 hours / 7 days) |
+{: #fig-quarantine-duration title="Quarantine Duration Escalation"}
+
+## Quarantine Expiry and Recovery
+
+When the quarantine period expires:
+
+1. The agent's trust score is reset to the initial default
+   (deployment-configured; RECOMMENDED: 0.5 for recovery).
+2. The agent transitions back to active status per AEPB lifecycle.
+3. A recovery ECT MAY be emitted: `exec_act: "apae:quarantine"` with
+   `apae.to_state: "active"`.
+
+An operator MAY lift a quarantine early by issuing a HITL override
+(Level 1 or higher) with scope `apae:quarantine_lift` for the
+subject agent.
+
+# Behavior Verification {#behavior}
+
+## Behavior Specifications
+
+A behavior specification declares what an agent is permitted to do.
+Specifications are JSON documents referencing ECT claims:
+
+~~~json
+{
+  "spec_version": "1.0",
+  "agent_id": "spiffe://example.com/agent/firewall",
+  "allowed_actions": ["update_rules", "read_config", "report"],
+  "constraints": {
+    "max_actions_per_minute": 60,
+    "forbidden_targets": ["core-router-*"],
+    "require_checkpoint_before": ["update_rules"]
+  },
+  "verification_frequency": "continuous"
+}
+~~~
+{: #fig-spec title="Behavior Specification"}
+
+Behavior specifications SHOULD be signed and versioned.  Changes
+MUST be recorded as ECTs.
+
+## Verification Against ECT Stream
+
+A verifier monitors the agent's ECT stream and checks:
+
+1. `exec_act` values are in `allowed_actions`.
+2. Action rate does not exceed `max_actions_per_minute` (computed
+   from `iat` timestamps).
+3. `atd:checkpoint` ECTs precede `update_rules` ECTs (from
+   `require_checkpoint_before`).
+4. Targets in `ext` claims do not match `forbidden_targets`.
+
+Verification results are ECTs:
+
+- `exec_act`: `"apae:compliance_check"`
+
+~~~json
+{
+  "exec_act": "apae:compliance_check",
+  "par": ["latest-agent-ect-uuid"],
+  "ext": {
+    "apae.compliance_status": "passing",
+    "apae.violations": [],
+    "apae.spec_version": "1.0",
+    "apae.window": "2026-03-01T12:00:00Z/PT1H"
+  }
+}
+~~~
+{: #fig-compliance title="Compliance Check ECT"}
+
+Violations trigger trust score decreases (`policy_violation` event)
+and MAY trigger HITL escalation.
+
+A violation compliance check ECT looks like:
+
+~~~json
+{
+  "exec_act": "apae:compliance_check",
+  "par": ["offending-ect-uuid"],
+  "ext": {
+    "apae.compliance_status": "failing",
+    "apae.violations": [
+      {
+        "rule": "require_checkpoint_before",
+        "action": "update_rules",
+        "ect": "offending-ect-uuid",
+        "description": "update_rules at 12:03:15 has no preceding atd:checkpoint within 10s"
+      }
+    ],
+    "apae.spec_version": "1.0",
+    "apae.window": "2026-03-01T12:00:00Z/PT1H"
+  }
+}
+~~~
+{: #fig-violation title="Compliance Violation ECT"}
+
+# Data Provenance {#provenance}
+
+## DAG as Provenance Chain
+
+The ECT DAG already encodes data provenance: each ECT's `par`
+references show which prior tasks produced its inputs.  The
+`inp_hash` and `out_hash` claims prove what was processed without
+revealing the data.
+
+For deployments requiring explicit provenance metadata, agents
+MAY include:
+
+~~~json
+{
+  "ext": {
+    "apae.data_source": "database:patients",
+    "apae.data_classification": "pii",
+    "apae.retention_days": 365,
+    "apae.transformations": ["anonymize", "aggregate"]
+  }
+}
+~~~
+{: #fig-provenance title="Provenance Extension Claims"}
+
+At Regulated assurance level, all data-transforming ECT nodes
+MUST include provenance claims.
+
+## Provenance Queries
+
+At L3, the audit ledger enables provenance queries:
+
+- "Which agents touched this data?" → walk `par` chain from
+  final ECT to roots.
+- "Was this data transformed?" → check `apae.transformations`
+  along the chain.
+- "Is provenance complete?" → verify all `par` references
+  resolve to ledger entries.
+
+# Cross-Domain Trust {#cross-domain}
+
+## Trust Domain Basics
+
+A trust domain is an administrative boundary within which a
+single trust anchor (CA certificate or JWK set) governs agent
+identity.  Trust scores are local to a trust domain by default.
+
+## Trust Domain Registration
+
+Each trust domain MUST publish a trust anchor at a well-known URI:
+
+~~~
+GET /.well-known/apae/trust-anchor HTTP/1.1
+~~~
+
+The response MUST be a JSON object containing:
+
+~~~json
+{
+  "domain": "example.com",
+  "trust_anchor_type": "jwks",
+  "trust_anchor_uri": "https://example.com/.well-known/jwks.json",
+  "contact": "trust-admin@example.com"
+}
+~~~
+{: #fig-trust-anchor title="Trust Anchor Document"}
+
+## Cross-Domain Delegation
+
+When Agent A (domain X) delegates to Agent B (domain Y):
+
+1. A MUST verify that its ACP-DAG-HITL policy permits cross-domain
+   delegation to domain Y (bilateral trust agreement).
+2. A fetches B's trust anchor document to verify B's identity.
+3. A creates an `apae:cross_domain_assertion` ECT linking the
+   two domains.
+4. Both A and B include their domain in ECT `iss` claims.
+
+~~~json
+{
+  "exec_act": "apae:cross_domain_assertion",
+  "ext": {
+    "apae.source_domain": "example.com",
+    "apae.dest_domain": "hospital.example",
+    "apae.bilateral_agreement_ref": "agreement-id-2026-001",
+    "apae.min_assurance": "L2"
+  }
+}
+~~~
+{: #fig-cross-domain title="Cross-Domain Assertion ECT"}
+
+The ASCII diagram below illustrates a cross-domain delegation:
+
+~~~
+Domain: example.com         Domain: hospital.example
+┌──────────────────┐        ┌──────────────────────┐
+│  Agent A         │  AEPB  │  Agent B             │
+│  (orchestrator)  ├───────►│  (treatment planner) │
+│  ECT: L2         │        │  ECT: L3             │
+└──────────────────┘        └──────────────────────┘
+         │                           │
+         └─── cross_domain_assertion ECT ──┘
+              (bilateral agreement verified)
+~~~
+{: #fig-cross-domain-diag title="Cross-Domain Delegation"}
+
+## Cross-Domain Trust Scores
+
+Trust scores do not transfer across domain boundaries by default.
+When Agent A in domain X has no prior interactions with Agent B
+in domain Y:
+
+- If a bilateral trust agreement exists: initial trust is set to
+  the agreement's `default_trust` value (negotiated out of band).
+- If no agreement exists: delegation MUST be rejected (zero-trust
+  default).
+
+Cross-domain trust scores are isolated from intra-domain scores
+and are stored separately in the trust table.
+
+# Assurance Profiles {#profiles}
+
+## Profile Definitions
+
+An assurance profile is a named configuration that selects which
+mechanisms are required.  Profiles MUST be declared in ACP-DAG-HITL
+workflow policy and announced in the AEPB capability document.
+
+| Mechanism | Relaxed | Standard | Regulated |
+|-----------|---------|----------|-----------|
+| **ECT level** | L1 | L2 | L3 |
+| **Trust scoring** | Optional | RECOMMENDED | REQUIRED |
+| **Trust threshold enforcement** | Optional | RECOMMENDED | REQUIRED |
+| **Behavior verification** | Off | Periodic | Continuous |
+| **HITL approval gates** | Optional | Critical paths | Mandatory |
+| **Data provenance claims** | Off | Optional | REQUIRED |
+| **Checkpoint before consequential** | RECOMMENDED | REQUIRED | REQUIRED |
+| **Audit ledger** | Optional | Optional | REQUIRED |
+| **Quarantine protocol** | Optional | RECOMMENDED | REQUIRED |
+| **Cross-domain trust agreements** | Optional | Required if cross-domain | Required if cross-domain |
+{: #fig-profiles title="Assurance Profile Requirements"}
+
+Relaxed:
+: Internal dev/staging.  L1 ECTs.  Trust and verification
+  optional.  Useful for debugging and observability without
+  cryptographic overhead.
+
+Standard:
+: Production cross-org.  L2 ECTs.  Trust scoring and thresholds
+  recommended.  Periodic behavior verification.  HITL on critical
+  paths.
+
+Regulated:
+: Healthcare, finance, EU AI Act.  L3 ECTs with audit ledger.
+  Continuous behavior verification.  All trust mechanisms
+  required.  Full provenance chain.  Mandatory HITL gates.
+
+Profiles are declared in ACP-DAG-HITL node constraints:
+
+~~~json
+{
+  "constraints": {
+    "apae.assurance_profile": "regulated"
+  }
+}
+~~~
+{: #fig-profile-policy title="Profile as Node Constraint"}
+
+A single deployment MAY use different profiles for different
+workflows.
+
+## Profile Selection Guidance
+
+Operators SHOULD select profiles using the following decision
+table:
+
+| Deployment context | Recommended profile |
+|-------------------|--------------------|
+| Unit tests, local development | Relaxed |
+| Internal production (single org) | Standard |
+| Cross-organization production | Standard (with trust agreements) |
+| Financial services, EU AI Act critical | Regulated |
+| Healthcare (HIPAA, clinical trials) | Regulated |
+| Critical infrastructure (NIS2) | Regulated |
+{: #fig-profile-selection title="Profile Selection Guidance"}
+
+## Upgrade Path Between Profiles
+
+Operators MUST NOT downgrade assurance profile during an active
+workflow.
+
+Relaxed → Standard:
+: (1) Add ECT signing keys (WIMSE WIT or X.509). (2) Update ECT
+  emission to sign tokens. (3) Configure trust scoring
+  (alpha/beta, initial trust, thresholds). (4) Define behavior
+  specifications for critical agents. (5) Add HITL approval gates
+  on critical DAG paths.
+
+Standard → Regulated:
+: (1) Configure audit ledger endpoint. (2) Update ECT emission
+  to commit each ECT to ledger. (3) Enable continuous behavior
+  verification (change `verification_frequency` from `periodic`
+  to `continuous`). (4) Enable provenance claims on all
+  data-transforming ECTs. (5) Add mandatory HITL gates on all
+  consequential actions. (6) Enable quarantine protocol.
+
+# Security Considerations
+
+## Trust Score Sensitivity
+
+Trust scores are sensitive metadata.  Agents MUST NOT expose
+full trust tables.  Only pairwise assertions SHOULD be shared,
+and only in response to explicit authenticated requests.
+
+## Score Inflation (Adversarial Trust Building)
+
+An adversary performs many small successful interactions to
+inflate trust, then executes a malicious action.  Mitigation:
+
+- Apply double penalty (`beta^2`) for `policy_violation` events.
+- Enforce high trust thresholds for high-risk actions.
+- Rate-limit trust score increases: an agent MUST NOT increase
+  trust by more than 0.1 per day toward any single peer.
+- Use behavior verification continuously at Standard+.
+
+## Attestation Freshness
+
+Stale compliance check ECTs MUST be rejected.  The verifier MUST
+check that `apae:compliance_check` ECTs have `iat` within the
+configured verification window (default: 1 hour for Standard,
+5 minutes for Regulated).
+
+## Provenance Chain Forgery
+
+Each provenance hop must be signed (L2+) to prevent injection
+of false provenance records.  Agents MUST verify the signature
+on all `par`-linked ECTs before accepting provenance claims.
+
+## Sybil Attack on Trust
+
+Fake agents inflate trust for each other to gain influence.
+Mitigation:
+
+- Trust propagation attenuation (default 0.5) limits the impact
+  of second-hand assertions.
+- Maximum hop count of 1 for trust propagation.
+- Require agents to be registered in a trusted directory before
+  initial trust is assigned above the floor value.
+
+## Cross-Domain Trust Downgrade
+
+An attacker forces delegation through an untrusted domain by
+presenting a forged bilateral agreement.  Mitigation:
+
+- Bilateral trust agreements MUST be signed by operators of
+  both domains.
+- Agents MUST verify the agreement signature before accepting
+  cross-domain delegations.
+- Cross-domain ECTs MUST use L2+ assurance.
+
+## Quarantine Evasion
+
+An agent subject to quarantine re-registers under a different
+identity to escape the quarantine.  Mitigation:
+
+- Quarantine ECTs are broadcast; receiving agents record the
+  quarantine by both agent ID and by behavioral fingerprint.
+- Agents SHOULD require re-onboarding with operator approval
+  before accepting new identities from known-quarantined domains.
+
+# IANA Considerations
+
+## Assurance Profile Registry
+
+This document requests the creation of the "APAE Assurance Profile
+Registry" under IANA.  Registration policy: Specification Required.
+
+Initial entries:
+
+| Profile Name | Profile URI | Description | Reference |
+|-------------|------------|-------------|-----------|
+| Relaxed | `urn:ietf:params:apae:profile:relaxed` | Dev/test, L1 ECTs | This document |
+| Standard | `urn:ietf:params:apae:profile:standard` | Production, L2 ECTs | This document |
+| Regulated | `urn:ietf:params:apae:profile:regulated` | Regulated, L3 ECTs | This document |
+{: #fig-profile-registry title="Assurance Profile Registry"}
+
+## `exec_act` Values
+
+This document requests registration in the AEM Ecosystem
+Extension Registry:
+
+| Value | Description | Reference |
+|-------|-------------|-----------|
+| `apae:trust_assertion` | Sharing trust score for a peer | This document |
+| `apae:trust_revoke` | Revoking delegations due to low trust | This document |
+| `apae:compliance_check` | Behavior verification result | This document |
+| `apae:quarantine` | Agent quarantine entry or exit | This document |
+| `apae:cross_domain_assertion` | Cross-domain delegation evidence | This document |
+{: #fig-iana-actions title="APAE exec_act Registrations"}
+
+## Well-Known URI
+
+This document requests registration of `apae/trust-anchor` as a
+well-known URI suffix per RFC 8615 for trust domain anchor
+publication.
+
+--- back
+
+# Acknowledgments
+{:numbered="false"}
+
+APAE builds on ECT {{I-D.nennemann-wimse-ect}} for interaction
+evidence and audit, and ACP-DAG-HITL
+{{I-D.nennemann-agent-dag-hitl-safety}} for trust threshold and
+assurance profile policy enforcement.  The AIMD trust model is
+adapted from TCP congestion control (RFC 5681).  Behavior
+verification is informed by RATS architecture {{RFC9334}}.