From f9a7ceabb7b254c0fc2bbc6520ebdfd19192ea52 Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Sun, 26 Jul 2026 22:06:23 -0700 Subject: [PATCH] docs(spec): map Agent Manifest onto SCITT terms (section 10.5) "Agent-layer profile of SCITT" was a slogan with nothing behind it. This maps every structural piece of the spec to its RFC 9943 term: the agent is the Artifact, agent_id the Subject, the manifest the Statement, the signed manifest the Signed Statement, transparency_log_entry the Receipt, and a manifest with that field populated the Transparent Statement. The spec already mandates reaching that last state for production, so the correspondence is real rather than aspirational. The point of stating it is to tell an implementer which parts of this document are agent-specific (3.2 through 3.5, what it takes to describe an agent completely) and which are inherited and should be read as SCITT. Also names what the spec deliberately does not restate: OpenSSF Model Signing for the model artifact, SLSA and in-toto for build provenance, SCITT and Sigstore for transparency. Adds an OMS row to 10.4 and a v0.2 line item for an explicit OMS bundle reference in model_identity, so a verifier can follow the chain from agent to model publisher rather than trusting an operator-asserted hash. Co-Authored-By: Claude Opus 5 (1M context) --- CHANGELOG.md | 2 ++ spec/agent-manifest-spec-v0.1.md | 33 +++++++++++++++++++++++++++++++- 2 files changed, 34 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index d4b8e45..25661db 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -10,6 +10,8 @@ All notable changes to Agent Manifest are documented here. Format follows [Keep ### Documentation +**[SPEC]** New **section 10.5, SCITT profile mapping**. Maps every structural piece of this specification to its RFC 9943 term (Artifact, Subject, Statement, Issuer, Signed Statement, Transparency Service, Receipt, Transparent Statement, Registration Policy, Auditor), which turns "agent-layer profile of SCITT" into a checkable claim and tells an implementer which parts are agent-specific (sections 3.2 to 3.5) and which are inherited. The section also states what the spec deliberately does not restate: OpenSSF Model Signing for the model artifact, SLSA and in-toto for build provenance, SCITT and Sigstore for transparency. Section 10.4 gains an OMS row, and v0.2 gains a line item for an explicit OMS bundle reference in `model_identity` so a verifier can follow the chain from agent to model publisher instead of trusting an operator-asserted hash. + **[SPEC]** **ADR-0011 accepted: the manifest envelope moves to COSE_Sign1** in spec v0.2, aligning with SCITT. The post-quantum profile is not a blocker, which was the main technical risk: [RFC 9964](https://www.rfc-editor.org/rfc/rfc9964.html) (Standards Track, May 2026) gives ML-DSA final IANA code points in COSE (ML-DSA-65 = `alg` -49, AKP key type 7). Migration is sequenced in five phases in the ADR and gated on manifest `version`, so v0.1 records keep verifying unchanged. Hybrid is the one construction COSE has no single answer for and is deferred to the v0.2 spec work. **[SPEC]** New **ADR-0011: the manifest is a signed document, not a JWT/JOSE profile**. Answers the recurring "why not just a JWT extension?" question on precedent rather than on capability, steelmanning EAT ([RFC 9711](https://www.rfc-editor.org/rfc/rfc9711.html)) rather than dismissing it, and setting against it the choice every comparable multi-artifact provenance standard made: SCITT ([RFC 9943](https://www.rfc-editor.org/rfc/rfc9943.html)) mandates COSE_Sign1, DSSE rejected a JWS profile in writing, C2PA signs with `COSE_Sign1_Tagged`. The ADR also records a decision this project had never actually made: the envelope is neither JOSE nor COSE but a bespoke canonical-JSON detached signature. Migrating to COSE_Sign1 is recommended; Section 3.6 is unchanged until that is signed off. diff --git a/spec/agent-manifest-spec-v0.1.md b/spec/agent-manifest-spec-v0.1.md index c4c9aff..95b786d 100644 --- a/spec/agent-manifest-spec-v0.1.md +++ b/spec/agent-manifest-spec-v0.1.md @@ -1574,6 +1574,7 @@ The Art. 13 row in section 9.1 cross-references `operational_lifecycle.expected_ Targets: Q3 2026. Driven by community and early adopter feedback collected during the CC Summit period (June to September 2026). - COSE_Sign1 signature envelope, replacing the v0.1 canonical-JSON detached signature and aligning with RFC 9943 (SCITT). Gated on the `version` field: v0.1 manifests continue to verify unchanged. See ADR-0011 +- `model_identity` reference to an OpenSSF Model Signing (OMS) signature bundle, so a verifier can follow the chain from the agent to the model publisher's signature instead of trusting an operator-asserted hash. See section 10.5 - Memory baseline protocol for stateful agents (v0.1 defines the binding; v0.2 defines the checkpoint protocol) - RAG corpus incremental update protocol - how to bind a delta without re-hashing the full corpus - Multi-model manifest - binding for agents that use different models for different subtasks @@ -1613,9 +1614,39 @@ Target: Q1 2027. Submission to AAIF alongside the AGT donation. | RFC 9162 (Certificate Transparency v2) | Merkle tree construction and transparency log structures follow RFC 9162. | | RFC 9334 (RATS Architecture) | The attestation service plays the RATS Verifier role. Platform-native attestation reports are normalized to EAT (RFC 9711) for third-party verification. | | RFC 9711 (EAT) | EAT is the attestation-token format for evidence about a running environment. Agent Manifest consumes an EAT as an input to the `attestation` block; it does not compete with it. The manifest itself is a signed document, not a token. See ADR-0011. | -| RFC 9943 (SCITT) | The closest analog to Agent Manifest: signed statements plus a transparency log with receipts. Agent Manifest is intended as the agent-layer profile of this model, and the envelope alignment question is tracked in ADR-0011. | +| RFC 9943 (SCITT) | The closest analog to Agent Manifest: signed statements plus a transparency log with receipts. Agent Manifest is the agent-layer profile of this model; see section 10.5 for the term-by-term mapping. The envelope moves to COSE_Sign1 in v0.2 per ADR-0011. | +| OpenSSF Model Signing (OMS) | OMS signs the model as an artifact: a detached signature bundle in Sigstore Bundle Format listing every model file by digest. Agent Manifest binds `model_identity` to the deployed model and does not re-specify model signing. Where a model ships with an OMS bundle, `model_hash` should be the digest that bundle binds, so the two agree by construction rather than by coincidence. See section 10.5. | | RFC 9562 (UUID v7) | All UUID fields in the manifest use UUID v7 per RFC 9562. | +### 10.5 SCITT Profile Mapping + +Agent Manifest is not a new transparency architecture. It is the agent-layer profile of the one the IETF standardized in RFC 9943 (SCITT), and every structural piece of this specification already has a SCITT name. Stating the correspondence explicitly is what makes "profile of SCITT" a claim rather than a slogan, and it tells an implementer which parts of this document are agent-specific and which are inherited. + +| SCITT term (RFC 9943) | Agent Manifest equivalent | +|---|---| +| Artifact | The deployed agent, as configured at a point in time | +| Subject | `agent_id`, a SPIFFE URI (section 3.1) | +| Statement | The manifest document: the ten artifact bindings plus identity, lifetime, and issuer metadata | +| Issuer | `issuer`, the SPIFFE URI of the signing authority (section 3.1) | +| Signed Statement | The signed manifest (section 3.6). COSE_Sign1 from v0.2 per ADR-0011, which is what RFC 9943 requires of a Signed Statement | +| Transparency Service | The Rekor or consortium log the manifest is submitted to (section 3.6) | +| Receipt | The inclusion proof carried in `transparency_log_entry` | +| Transparent Statement | A signed manifest whose `transparency_log_entry` is populated. This specification already requires production deployments to reach this state: a signature alone is explicitly declared insufficient for regulatory purposes (section 3.6) | +| Registration Policy | What a Transparency Service checks before registering a manifest, for example the declared conformance level (section 8.1) and whether the signing key is authorized for the claimed issuer (section 5.3) | +| Auditor | Any third party reconstructing an agent's history from the log without trusting the operator, which is the premise of section 1.1 and the threat model of section 7 | + +The agent-specific contribution is the Statement payload: what it means to describe an *agent* completely enough that a third party can tell whether the one running is the one approved. That is sections 3.2 through 3.5. Everything around it (signing, registration, receipts, auditing) is SCITT, and should be read as such rather than as a parallel invention. + +#### What this specification deliberately does not restate + +Composition is the point. Three adjacent efforts already solve problems that Agent Manifest binds rather than re-solves: + +- **The model artifact: OpenSSF Model Signing (OMS).** OMS produces a detached signature bundle, in Sigstore Bundle Format, listing every file of a model by digest, covering weights, configuration, and tokenizer as one unit. Agent Manifest does not define a competing model-signing scheme. `model_identity.model_hash` (section 3.2.4) binds the model a specific agent is approved to run; where the model publisher ships an OMS bundle, that hash should be the digest OMS binds, and a future revision will add an explicit field for the bundle reference so a verifier can follow the chain from agent to model publisher without an out-of-band lookup. +- **Build provenance: SLSA and in-toto.** `supply_chain` references SLSA attestations (section 3.2.8) rather than re-encoding build steps. +- **Transparency: SCITT and Sigstore.** The log, its receipts, and the auditing model are SCITT's, as mapped above. + +The consequence for implementers is that an Agent Manifest deployment inherits the tooling and the review history of these efforts, and the gap Agent Manifest fills is the one none of them addresses: no existing standard binds a system prompt, a policy bundle, a tool catalog, a memory baseline, a delegation chain, and a human approval into a single artifact that hardware can attest to. + ## 11. Appendix ### A. Glossary