Let agents act within limits you approve in advance.
EMILIA Gate puts a decision point before configured consequential actions. Local policy decides whether the required exact-action authority is present; the open protocol makes the supporting evidence portable and independently verifiable.
The canonical four-document adoption path
The product is designed to control a configured execution path. These four individual Internet-Drafts define the evidence path beneath that decision: create the approval artifact, attach it to the action record, establish scoped authority, then evaluate the resulting evidence bundle.
What action-bound organizational approval evidence was produced under the receipt profile?
One approval-evidence profile and extension seam; it does not establish scoped authority or evidence satisfaction by itself.
How is named-human authorization evidence bound into an adjacent host record?
Host-agnostic by-value or by-reference binding; it does not redefine the authorization artifact or host format.
Under the relying party's trust roots, did the verified key have authority for this scope?
Trust-root introduction and scoped authority; signature verification alone does not create authority.
Does the natively verified, action-matched bundle satisfy the relying party's evidence requirement?
Returns SATISFIED or UNSATISFIED; it never returns a universal authorization verdict.
This is EMILIA’s reader-facing implementation sequence. It is not a claim of working-group adoption, endorsement, production deployment, or consolidation of the wider draft portfolio. Verification, evidence satisfaction, local authorization, and observed execution remain separate decisions.
Three interfaces with adjacent standards
Authentication can trigger the flow, machine evidence can sit beside it, and a transparency service can log it. These are composition points, not claims that another standard or working group has adopted EMILIA.
Step-Up can require a stronger authentication event for a sensitive action. An EMILIA integration can request separate, durable approval evidence after that trigger; the receipt proves only its own signed fields and bindings.
Machine attestation and workload identity describe the platform or workload. EMILIA authorization evidence remains a distinct input: it records an approval claim bound to the action and is evaluated under relying-party-pinned enrollment and authority roots.
A SCITT receipt is transparency or inclusion evidence: it shows that a statement was registered. An EMILIA authorization receipt can be carried as a SCITT Signed Statement, while SCITT returns the separate proof that it was logged.
Published standards to compose with
These are published or widely deployed standards and projects. EMILIA’s specifications define possible complement relationships; they do not imply integration or adoption by those communities.
| Standard | Status | How EMILIA complements it |
|---|---|---|
| OAuth 2.0 / OIDC - RFC 6749 | Published - ubiquitous | Grants access. EMILIA can add separate, exact-action approval evidence evaluated against the relying party's pinned trust inputs. |
| Step-Up Authentication - RFC 9470 | Proposed Standard | Can trigger stronger authentication. An EMILIA receipt is a separate artifact and does not prove a Step-Up event unless the integration explicitly binds the two. |
| Rich Authorization Requests (RAR) - RFC 9396 | Proposed Standard | An EMILIA profile can bind approval evidence to the same authorization_details under an explicit action mapping. |
| RATS - RFC 9334 + EAT - RFC 9711 | Published | Supplies platform or workload attestation. EMILIA authorization evidence stays separate, with its own native verifier and trust inputs. |
| HTTP Message Signatures - RFC 9421 | Proposed Standard | An authorization receipt can accompany a signed request; the message signature does not itself create authority. |
| JWS - RFC 7515 / COSE - RFC 9052 / CWT - RFC 8392 | Published | Serialization options in which EMILIA receipt claims can be expressed. |
| Token Exchange - RFC 8693 | Proposed Standard | Delegates authority between services. Exact-action approval evidence remains a separate input at the consequence boundary. |
| SPIFFE / SPIRE | CNCF graduated | Identifies a workload. EMILIA adds separately verified evidence about the approval and action, not proof of a natural person. |
| Trusted timestamp - RFC 3161 - Evidence Record Syntax (ERS) - RFC 4998 - JCS - RFC 8785 | Published | RFC 3161 can supply trusted time, RFC 4998 informs long-term renewal, and JCS is the EMILIA canonical base. |
Where EMILIA positions for what’s standardizing
These efforts are still moving through the IETF. EMILIA tracks them as complements; the relationship is a composition story, not a claim of adoption by those working groups.
| Standard | Status | How EMILIA complements it |
|---|---|---|
| SCITT - architecture + SCRAPI + COSE Receipts | Active drafts | EMILIA authorization receipts can be registered as Signed Statements; SCITT can return a distinct transparency receipt. |
| OAuth Transaction Tokens (Txn-Tokens) | Active draft | Carries short-lived call-chain context. EMILIA supplies separate exact-action authorization evidence, not a transport token. |
| WIMSE (Workload Identity in Multi-System Environments) | Active drafts | Supplies workload identity. EMILIA authorization evidence remains an independently verified input above that trust root. |
| SD-JWT-VC / EUDI | Active drafts | Selective-disclosure credentials can be carried or referenced as native evidence without being treated as authorization by default. |
Interop: one canonical base, three serializations
EMILIA keeps JCS (RFC 8785) as its canonical base and offers receipts as JWS (RFC 7515) for universal web reach and COSE_Sign1 / CWT (RFC 9052 / RFC 8392) CBOR-native form for SCITT interop. The same receipt claims can travel across all three — no lock-in to a wire format.
How the evidence can sit beside RATS and inside SCITT
These are narrow composition mappings, not adoption claims. Machine attestation and EMILIA authorization evidence remain orthogonal inputs that can meet at the relying party.
The EMILIA receipt is not RATS Evidence. RATS can attest the platform or workload; EMILIA verifies an authorization artifact and its action binding under relying-party-pinned trust inputs. A named-human claim is only as strong as its independent enrollment and authority evidence; EMILIA does not prove a natural person.
Keep the two “receipts” distinct: authorization receipt (EMILIA — authorization evidence bound to an action) vs transparency / inclusion receipt (SCITT — proof it was logged). An EMILIA profile can supply the lineage link and authorization evidence; SCITT can supply the tamper-evident log.
Honest framing. The four-document path above is the repository’s canonical reader-facing surface, not a Datatracker consolidation or external adoption claim. The repository tracks 22 active Datatracker records as of August 3, 2026. The latest six filings are AEB -03, AEC -05, Model-to-Matter -03, Reliance Agreement -00, Bounded Capability Receipts -01, and Bounded Execution Program -00. They are licensed Apache-2.0 where applicable, are not IETF standards, and do not imply endorsement by any working group. The relationships above are complement relationships — how EMILIA composes with these standards — not claims of adoption by the OAuth, RATS, SCITT, WIMSE, or any other WG.