source
MCEP Specifications (v0.1)
This directory carries the v0.1 specification documents for Ardur's protocol layer, MCEP (Mission-Controlled Execution Protocol). v0.1 is a pre-release series — the specs describe
This directory carries the v0.1 specification documents for Ardur’s protocol layer, MCEP (Mission-Controlled Execution Protocol). v0.1 is a pre-release series — the specs describe the intended protocol shape; the public code that implements them is being curated in phases per docs/public-import-plan.md .
The MCEP acronym was expanded as “Mission-bound Cryptographic Evidence Protocol” in earlier learn-MCEP teaching material; the formal v0.1 specs use “Mission-Controlled Execution Protocol” and that is the canonical expansion going forward. Articles and other public prose follow the spec form.
Public-surface import caveat. The migrated specs were authored in a private context and may reference implementation source paths (e.g. vibap-prototype/vibap/passport.py), private session artifacts (e.g. docs/session-2026-04-XX/...), or internal review trails that have not yet landed in this public repo. Treat such references as pointers to future work — the underlying code lands alongside the Phase 1 import per the public import plan
. Contributors cannot verify those referenced artifacts from the public tree today. Same caveat as the decisions index
.
Migration status
| Spec | Status | Notes |
|---|---|---|
| Conformance Profiles | migrated | Public-import annotated |
| Delegation Grant (DG) Profile of AAT | migrated | Public-import annotated |
| Verifier Contract | migrated | Public-import annotated |
| Mission Declaration (MD) | migrated | Public-import annotated; clean-break protocol rename applied (application/ardur.md+jwt, https://ardur.dev/...) |
| Execution Receipt (ER) | migrated | Public-import annotated; clean-break rename applied (application/ardur.er+jwt) |
| Execution Receipt EAT/CWT Profile | migrated | Public-import annotated; clean-break rename applied |
| IDM Extension Profile | migrated | Public-import annotated; clean-break rename applied (application/ardur.idm+jwt) |
| Revocation Model | migrated | Public-import annotated; clean-break rename applied |
| Mission Declaration schema | migrated | JSON Schema; $id rebased to ardur.dev |
| Execution Receipt schema | migrated | JSON Schema; $id rebased to ardur.dev |
Protocol identifier rename (clean break, applied 2026-04-27)
The v0.1 specs originally embedded a legacy product/project name in their JWT media types (application/<legacy>.er+jwt) and $id URIs (https://<legacy>.io/...). The rename decision: clean break, no dual-type support. New canonical identifiers in this public series:
| Identifier kind | Old | New |
|---|---|---|
| Mission Declaration JWT type | application/<legacy>.md+jwt | application/ardur.md+jwt |
| Execution Receipt JWT type | application/<legacy>.er+jwt | application/ardur.er+jwt |
| IDM Extension JWT type | application/<legacy>.idm+jwt | application/ardur.idm+jwt |
Schema $id URI base | https://<legacy>.io/spec/... | https://ardur.dev/spec/... |
The clean-break rationale: there are no v0.1 receipts, passports, or attestations in third-party hands — all empirical artifacts under this series stay private (the paper, internal benchmarks). Backward-compat dual-type would have added implementation complexity for zero observed callers. If receipts in the wild appear later, a v0.2 with dual-type support is the right answer at that point.
Reading order for first-timers
- Mission Declaration (MD) — the signed scope envelope the agent starts with
- Delegation Grant (DG) Profile — how child agents get strictly narrower authority
- Execution Receipt (ER) — the signed per-tool-call decision record
- Execution Receipt EAT/CWT Profile — RFC 9711 binding for ER carriage
- Verifier Contract — what a conforming verifier must do
- Conformance Profiles — tiered conformance matrix (Delegation-Core, MIC-State, MIC-Evidence, IDM Extension)
- Revocation Model — layered revocation across delegation, session, credential, and transparency-log layers
- IDM Extension Profile — Intent-Declaration-Manifest experimental profile
Relationship to adjacent standards
- AAT (Attenuating Authorization Tokens) — IETF OAuth WG draft; MCEP’s Delegation Grant is an AAT profile.
- EAT (Entity Attestation Token, RFC 9711) — used by the ER EAT/CWT profile to carry Execution Receipts.
- SPIFFE — workload identity substrate; MCEP binds mission credentials to SVIDs.
- Biscuit — first-party-attenuation credential format; the DG profile’s narrowing semantics rely on Biscuit’s append-only block model (see ADR-017 ).
These are real artifacts, not codenames. Their names stay in the specs as technical lineage.
Conventions
- Versioning: v0.1 is the pre-release. The next revision (v0.2 or later) lands after the protocol-level rename decision + one round of adversarial review against the migrated public specs.
- Normative language: MUST / SHOULD / MAY usage follows RFC 2119 / RFC 8174.
- Updates: specs don’t mutate in place; a material change opens a new version file and leaves the prior version immutable for citation stability.