Human Agency Continuity Protocol (HACP) Core

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 17 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

Companion architecture: [I-D.cassandres-hacp-agency-arch]. Authoritative schemas, canonicalization rules, the boundary matrix, and vectors remain in HACP Specification v1.0.0 [HACP-SPEC-1.0.0] at the immutable release tag and source commit identified in the reference. This draft is the IETF-facing restatement of that frozen Core contract.¶

This document does not upgrade the HACP v1.0.0 canonicalization profile into a new claim of general RFC 8785 conformance. The byte-level contract remains the published v1.0.0 HACP canonicalization profile; [RFC8785] is cited as related canonicalization work.¶

2. Naming and Unrelated HACP Draft

The acronym HACP in this document means Human Agency Continuity Protocol. The separately posted [I-D.sunyi-hacp-protocol] uses the same acronym for Hardware Agent Capability Protocol. The two works are unrelated, and the present author has no affiliation with that document.¶

3. Terminology

Principal

Subject of the envelope; principal_kind is human or system.¶

IntentEnvelope

Signed scope and optional autonomy budget.¶

ProposedAction

Structured description of one intended act.¶

AgencyDecision

ALLOW, DENY, or CHECKPOINT.¶

DecisionToken

Signed binding of ALLOW to action_hash.¶

Policy

Rule set identified by policy_digest.¶

Revocation

Signed invalidation of envelope, token, or key.¶

4. Deployment Assumptions

1. Proposed actions arrive through a schema-constrained interface. Unmediated free-form tool execution is out of scope for Core compliance.¶

2. An enforcement point MUST exist for a deployment to be more than advisory.¶

3. Verifiers MAY apply an explicit bounded clock skew to expiry checks.¶

5. Data Model

All objects MUST match the published JSON Schemas in HACP Specification v1.0.0. All signed objects MUST use the deterministic HACP v1.0.0 canonicalization profile before hashing or signing: sorted keys, rejected duplicate keys, rejected non-finite numbers, and no presentation whitespace in canonical bytes. The profile is described as compatible with RFC 8785 expectations; this draft does not claim additional JCS behavior beyond the frozen v1.0.0 contract.¶

6. evaluate()

evaluate(intent_envelope, proposed_action, context) -> AgencyDecision

The evaluator MUST run in this order:¶

1. Validate envelope schema. Failure -> DENY INVALID_ENVELOPE.¶

2. Resolve signer_key_id; revoked key -> DENY KEY_REVOKED.¶

3. Verify envelope signature. Failure -> DENY SIGNATURE_FAILURE.¶

4. Check envelope and applicable ancestor token revocation. ENVELOPE_REVOKED / TOKEN_REVOKED.¶

5. Envelope expiry -> DENY ENVELOPE_EXPIRED.¶

6. Validate ProposedAction; reject duplicate JSON keys -> DENY INVALID_ACTION.¶

7. Compute action_hash over canonical ProposedAction.¶

8. Evaluate scope and boundaries. Exceeded authority -> MUST NOT ALLOW.¶

9. Unknown security-relevant attribute -> MUST NOT ALLOW UNKNOWN_ATTRIBUTE.¶

10. Evaluate autonomy budget. Exhausted for a system principal -> MUST NOT ALLOW BUDGET_EXHAUSTED.¶

11. Human-required consequence class with non-human principal -> CHECKPOINT HUMAN_REQUIRED, or DENY if policy forbids escalation.¶

12. Otherwise ALLOW and issue a DecisionToken bound to action_hash.¶

evaluate() MUST be deterministic for identical inputs, policy, and revocation state. evaluate() MUST NOT call an LLM.¶

Signer-key revocation MUST be checked before signature verification. Envelope and token revocation MUST be checked only after a successful signature check.¶

7. Scope and Boundaries

ScopeGrant bounds security-relevant attributes, including quantity ceilings and destination allowlists.¶

A meaningful boundary crossing (audience, reversibility, externality, destination allowlist, data_class, and other dimensions defined by the published boundary matrix) MUST NOT yield ALLOW. Return CHECKPOINT if policy allows escalation, otherwise DENY BOUNDARY_CROSSING.¶

Quantity above a granted ceiling is SCOPE_EXCEEDED and is not, solely by that fact, a meaningful boundary crossing.¶

Absent optional security-relevant attributes are ungranted unless the policy explicitly defaults them.¶

The published HACP v1.0.0 boundary matrix governs in case of conflict with this summary.¶

8. Autonomy Budget

Budget consumption for system principals MUST be monotonically non-decreasing per envelope. Exhaustion MUST NOT ALLOW. Human checkpoint paths are not consumed by system budget exhaustion.¶

9. Cryptography

Production signatures MUST use Ed25519 [RFC8032] over HACP canonical bytes. HMAC is permitted only in explicitly marked development profiles. policy_digest MUST be covered by token signatures. SHA-256 is used where this document specifies SHA-256 [RFC6234].¶

10. Provenance

Every evaluate() MUST emit a signed EVALUATED event. ALLOW issuance MUST emit ISSUED. Revocation MUST emit REVOKED. Chain integrity MUST be verifiable through prev_event_hash.¶

11. Invariants

• INV-1 Human Final Decision: human-required consequence class SHALL NOT ALLOW without a human principal or explicit delegation.¶

• INV-2 Boundary Re-Authorization: meaningful boundary crossing SHALL NOT ALLOW without re-authorization.¶

• INV-3 Token Binding: a token is valid only for its action_hash.¶

• INV-4 Traceability: every decision references signed provenance, policy digest, and principal.¶

• INV-5 Cryptographic Integrity: tampered signed payloads MUST fail closed.¶

• INV-7 Bounded Autonomy: exhausted system budget MUST NOT ALLOW.¶

INV-6 is reserved and unused.¶

The executable mapping is the 38-vector core-0.9.2 set pinned by this SHA-256 digest:¶

1e167887106463cf89c81f3898e1f3ae4fd905bc807084959c787287f6575d58

Implementations MUST NOT special-case vector IDs.¶

12. Revocation

• Token target denies that token.¶

• Envelope target denies the envelope, descendant envelopes, and their tokens transitively.¶

• Key target denies every envelope or token with that signer_key_id.¶

13. Out of Scope for This Draft

• Enforcement revision 2 / HC2 request-binding classes as active 1.0 contract.¶

• Exact reason-code 38/38 correspondence (sidecar baseline is 15/38 exact + 23 classified, all decision-correct).¶

• General URI normalization.¶

• New IANA registries.¶

• Wire encoding detail beyond the canonicalization rules above (reserved for a later wire draft).¶

14. Security Considerations

Failures in schema, signature, key state, expiry, scope, budget, or unknown attributes MUST NOT become implicit ALLOW.¶

A DecisionToken replayed against a mutated action MUST DENY.¶

The protocol does not replace host hardening, key custody, transport security, or model-safety work. TEST ONLY conformance keys MUST NOT be deployed.¶

15. IANA Considerations

This document has no IANA actions.¶

Author's Address