GateAgent GuardProtocolStandardsMCPGovGuardSovereigntyFinGuardQuorumDemoTry itVerifyPricingDocsRequest Pilot
IETF LANDSCAPE · COMPLEMENT, NOT COMPETITOR

EMILIA in the IETF landscape — a complement, not a competitor.

EMILIA Protocol is the human-authorization-receipt layer. It composes with the accepted standards the ecosystem already runs — it rides inside them, sits beside them, and is logged by them — rather than replacing any of them. The receipt EMILIA produces is the one durable artifact none of these standards emit on their own: portable, offline-verifiable proof that a named human authorized one exact irreversible action.

See it on a real actionRead the spec

The three-pillar story

EMILIA is the human-authorization receipt that Step-Up triggers, RATS/EAT sits beside, and SCITT logs.

TRIGGERdeployed
OAuth Step-Up Authentication — RFC 9470 (Proposed Standard)

Step-Up demands a fresh human challenge for a sensitive action, but produces no durable artifact. EMILIA is the offline, verifiable receipt of that step-up — the proof that survives after the challenge passes.

ORTHOGONAL TRUST ROOTdeployed
Machine attestation — RATS (RFC 9334) + EAT (RFC 9711), SPIFFE/SPIRE, WIMSE

Attestation answers "is this agent’s platform trustworthy / which workload is this." EMILIA answers the orthogonal question: "did a NAMED HUMAN authorize THIS exact irreversible action." Same evidence bundle, different trust root.

ACCOUNTABILITY RAILstandardizing now
SCITT — draft-ietf-scitt-architecture

A SCITT "Receipt" is a transparency / INCLUSION proof: it proves a statement was logged in an append-only ledger. SCITT is deliberately AGNOSTIC about who authorized anything — that delegated-away question is exactly EMILIA’s payload. An EMILIA authorization receipt rides AS a SCITT Signed Statement; SCITT returns a transparency receipt that it was logged. Defuse the shared word: "authorization receipt" (EMILIA) vs "transparency / inclusion receipt" (SCITT).

TIER 1 · PUBLISHED RFCs / DEPLOYED — ANCHOR HERE

Where EMILIA composes today

These are shipped, widely-deployed standards. EMILIA does not compete with any of them; it supplies the human-authorization evidence that sits on top.

StandardStatusHow EMILIA complements it
OAuth 2.0 / OIDC — RFC 6749Published · ubiquitousGrants access. EMILIA proves a named human authorized the exact act.
Step-Up Authentication — RFC 9470Proposed StandardThe trigger. EMILIA is the durable proof that the step-up happened.
Rich Authorization Requests (RAR) — RFC 9396Proposed StandardEMILIA signs the human approval of the same authorization_details (RAR = request schema; EMILIA = evidence over it).
RATS — RFC 9334 + EAT — RFC 9711PublishedMachine attestation (platform / workload). EMILIA = human authorization. Orthogonal trust roots, same bundle.
HTTP Message Signatures — RFC 9421Proposed StandardEMILIA rides inside a signed request.
JWS — RFC 7515 / COSE — RFC 9052 / CWT — RFC 8392PublishedInterop serializations EMILIA receipts express in.
Token Exchange — RFC 8693Proposed StandardDelegates authority between services. EMILIA proves the human authorized the irreversible act at the chain’s end.
SPIFFE / SPIRECNCF graduatedAgent identity. EMILIA adds who approved what it does.
Trusted timestamp — RFC 3161 · Evidence Record Syntax (ERS) — RFC 4998 · JCS — RFC 8785PublishedRFC 3161 trusted time; RFC 4998 ERS is the lineage for EMILIA’s evidence-record renewal; JCS is EMILIA’s canonical base.
TIER 2 · ACTIVE DRAFTS — POSITION RELATIVE TO, DON’T ANCHOR

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.

StandardStatusHow EMILIA complements it
SCITT — architecture + SCRAPI + COSE ReceiptsActive draftsEMILIA authorization receipts ride as SCITT Signed Statements; SCITT logs them and returns transparency receipts.
OAuth Transaction Tokens (Txn-Tokens)Active draftShort-lived call-chain context. EMILIA is the human-authorization evidence over the irreversible act, not the transport token.
WIMSE (Workload Identity in Multi-System Environments)Active draftsWorkload identity. EMILIA adds the human-authorization layer above the workload trust root.
SD-JWT-VC / EUDIActive draftsSelective-disclosure credentials. EMILIA receipts can be carried / referenced; the authorization claim is EMILIA’s.

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 authorization claim travels across all three — no lock-in to a wire format.

Receipt on a real actiondraft-schrock-ep-authorization-receipts

Honest framing. EMILIA is an active individual Internet-Draft, draft-schrock-ep-authorization-receipts, licensed Apache-2.0. It is not an IETF standard and not an 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.

EMILIA in the IETF landscape — a complement, not a competitor | EMILIA | EMILIA Protocol