An ASIL-M Profile for Multi-Root Evidence Synthesis in RATS
draft-yalcinkaya-rats-asil-m-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | ERKAN | ||
| Last updated | 2026-03-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yalcinkaya-rats-asil-m-00
Network Working Group E. Yalcinkaya
Internet-Draft Luminesce Limited
Intended status: Informational March 19, 2026
Expires: September 19, 2026
An ASIL-M Profile for Multi-Root Evidence Synthesis in RATS
draft-yalcinkaya-rats-asil-m-00
Abstract
This document defines an application profile for Remote ATtestation
procedureS (RATS) deployments in which authorization decisions depend
on evidence from multiple independent trust roots. The profile is
intended for AI inference systems that require explicit cross-root
appraisal before execution is authorized.
The document specifies three related artifacts:
* an Attestation Evidence Synthesis Protocol for combining multiple
evidence sets into one deterministic appraisal outcome;
* the Twin Attestation Policy Language (TAPL), a constrained policy
language for deterministic multi-root appraisal; and
* the Canonical Attestation Record (CAR), an audit-oriented envelope
that binds evidence references, appraisal outputs, freshness
information, and replay-verification metadata.
CAR is not a replacement for Evidence or Attestation Results as used
in the RATS architecture. Instead, it is a higher-layer profile for
packaging multi-root appraisal state and application-specific bindings
for replay and audit.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
This Internet-Draft will expire on September 19, 2026.
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.
1. Introduction
Some AI inference systems are intentionally deployed across
heterogeneous trust roots in order to reduce common-mode failure,
implementation monoculture, and correlated compromise. In such
systems, a single attestation-verification outcome is not sufficient
for a Relying Party decision. Instead, the Relying Party requires a
synthesized appraisal over multiple evidence sets and an auditable
binding between that synthesized appraisal and the inference decision
being authorized.
The RATS architecture already defines the relevant roles and message
classes for this environment: Attesters produce Evidence, Verifiers
appraise that Evidence according to policy, and Relying Parties use
Attestation Results as inputs to authorization. What is not defined by
the base architecture is an application profile for deterministic
synthesis across multiple independent evidence sources for one AI
inference authorization event.
This document defines such a profile. It does not introduce new RATS
roles. It defines:
* a deterministic synthesis procedure across multiple evidence sets;
* a constrained appraisal-policy language for multi-root decisions;
and
* an audit-oriented container for binding the resulting appraisal
state to freshness and replay metadata.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this
document are to be interpreted as described in BCP 14.
This document uses the RATS terms "Attester", "Evidence", "Verifier",
"Attestation Results", "Relying Party", and "Appraisal Policy" as
defined by RFC 9334.
This document additionally uses the following profile terms:
* Multi-root evidence set: the collection of Evidence objects that
correspond to the same authorization event but originate from two
or more independent trust roots.
* Synthesized appraisal: the deterministic outcome produced after
individual evidence appraisal and cross-root policy evaluation.
* TAPL: a constrained language for expressing threshold checks,
predicate checks, and decision outputs over a multi-root evidence
set.
* CAR: an audit-oriented envelope that binds evidence references,
synthesized appraisal state, freshness information, and replay
metadata.
* Semantic binding: application-specific metadata that binds the
attested execution context to the inference event that the Relying
Party is authorizing.
* Independence metrics: policy-level attestation-plane measures that
verify the absence of shared vendor, cryptographic stack, or
operational control plane across evidence sources. These are
appraisal-layer predicates and do not depend on graph-theoretic
extensions.
3. Problem Statement
In a conventional single-root deployment, a Relying Party may accept
Attestation Results derived from one Evidence source and authorize
execution accordingly. In a multi-root AI deployment, that is
insufficient for two reasons.
First, the authorization decision may depend on policy predicates that
compare properties across roots rather than within a single root. For
example, the Relying Party may require evidence that two execution
paths are not derived from the same vendor, cryptographic stack, or
operational control plane.
Second, the Relying Party may need a replayable record showing which
combination of evidence, policy version, and freshness context caused
a specific authorization outcome for a specific inference event.
Existing attestation workflows do not define how multiple heterogeneous
evidence sources should be combined into one deterministic appraisal
outcome for a single authorization decision. This profile makes those
synthesis and packaging rules explicit for AI inference deployments.
4. Attestation Evidence Synthesis Protocol
4.1. Overview
The Attestation Evidence Synthesis Protocol defined here is a profile
procedure executed by a Verifier, or by a Verifier-associated policy
service, before a Relying Party authorizes an inference event.
The procedure is:
1. Collect Evidence objects for the same authorization event from two
or more Attesters.
2. Verify each Evidence object according to its applicable Appraisal
Policy for Evidence.
3. Reject stale, incomplete, or mismatched evidence sets before
synthesis begins.
4. Evaluate cross-root predicates and thresholds over the verified
evidence set.
5. Produce one synthesized appraisal outcome.
6. Bind that outcome to freshness context, policy identity, and the
application-specific inference event identifier.
7. Emit Attestation Results and, optionally, a CAR for audit and
replay.
4.2. Inputs
The minimum synthesis inputs are:
* one or more Evidence objects per authorization event;
* a policy identifier and policy digest;
* freshness inputs sufficient to detect replay or mixed-session
reuse; and
* the application event identifier to which the synthesized appraisal
will apply.
4.3. Outputs
The synthesis procedure produces:
* a deterministic decision such as ALLOW, DEGRADE, BLOCK, or
QUARANTINE;
* a list of evaluated predicates or thresholds sufficient for audit;
and
* Attestation Results suitable for use by a Relying Party.
When audit and replay support are needed, the procedure SHOULD also
emit a CAR.
5. TAPL as Constrained Appraisal Policy
5.1. Design Goal
TAPL is a constrained policy language for deterministic multi-root
appraisal. It is intended to express profile-specific Appraisal Policy
logic, not to define a general-purpose policy engine.
TAPL is deliberately limited to:
* threshold checks,
* predicate checks,
* explicit decision outputs, and
* side-effect-free evaluation.
5.2. Example Grammar
PolicyDef ::= "policy" Identifier "{" Directives Rules "}"
Directives ::= Directive*
Directive ::= "enforce_profile" ProfileLevel ";"
| "set_threshold" Identifier "=" FloatLiteral ";"
Rules ::= Rule+
Rule ::= "on" ContextTrigger "{" LogicBlock "}" "->" Decision ";"
ContextTrigger ::= "attestation" | "semantic_binding" | "freshness"
LogicBlock ::= Statement*
Statement ::= "if" Condition "then" Decision ";"
| "require" Condition ";"
Condition ::= Expression
Expression ::= Term (("AND" | "OR") Term)*
Term ::= "NOT" Term | "(" Expression ")" | Predicate | Comparison
Comparison ::= MetricIdentifier Operator NumericLiteral
Operator ::= ">=" | "<=" | "==" | ">" | "<"
Predicate ::= "verify_evidence(" RootIdentifier ")"
| "check_predicate(" PredicateIdentifier ")"
RootIdentifier ::= Identifier
PredicateIdentifier ::= Identifier
MetricIdentifier ::= Identifier
Decision ::= "ALLOW" | "DEGRADE" | "BLOCK" | "QUARANTINE"
ProfileLevel ::= "L0" | "L1" | "L2" | "L3" | "L4"
Identifier ::= Letter (Letter | Digit | "_")*
FloatLiteral ::= Digit+ "." Digit+
NumericLiteral ::= FloatLiteral | Digit+
5.3. TAPL Result Binding
The result of TAPL evaluation MUST be bound to:
* the exact multi-root evidence set being appraised;
* the policy digest used for appraisal;
* the freshness context used to reject replay; and
* the application event identifier.
A TAPL outcome without that binding MUST NOT be reused as if it were
current authorization state.
6. Canonical Attestation Record (CAR)
6.1. Role of CAR
CAR is an audit-oriented envelope for multi-root appraisal. It is not
itself a new RATS role and it does not replace Evidence or
Attestation Results. Its purpose is to bind together:
* references to the Evidence appraised,
* synthesized appraisal outputs,
* policy identity,
* freshness context, and
* replay-verification metadata.
6.2. Conceptual Structure
```json
{
"metadata": {
"car_version": "1.0",
"event_id": "uuid",
"profile_id": "L2",
"issued_at": "2026-03-19T12:00:00Z"
},
"attestation_evidence": [
{
"root_id": "root_a",
"evidence_digest": "sha-384:...",
"evidence_type": "evidence-reference"
},
{
"root_id": "root_b",
"evidence_digest": "sha-384:...",
"evidence_type": "evidence-reference"
}
],
"policy_evaluation": {
"tapl_policy_digest": "sha-384:...",
"synthesized_decision": "ALLOW",
"failing_predicates": []
},
"independence_metrics": {
"vendor_separation": true,
"crypto_stack_separation": true,
"control_plane_separation": true
},
"freshness": {
"nonce": "base64url...",
"evidence_window": "session-epoch-123"
},
"semantic_binding": {
"subject_digest": "sha-384:...",
"binding_type": "application-event"
},
"semantic_consensus": {
"consistency_check": "passed",
"checked_properties": ["model_version", "input_schema"]
},
"cryptographic_binding": {
"car_digest": "sha-384:...",
"timestamp_token_digest": "sha-384:...",
"signer": "verifier.example"
}
}
```
6.3. CAR Processing Rules
A CAR emitted under this profile MUST:
* identify the specific evidence set that was appraised;
* identify the policy digest used to synthesize the result;
* identify freshness inputs sufficient to reject stale reuse;
* identify the application event to which the result applies; and
* include cryptographic binding sufficient to detect tampering after
issuance.
7. Relationship to RFC 9334 and EAT
7.1. Relationship to the RATS Architecture
This profile is designed to fit within the RATS architecture described
by RFC 9334.
In particular:
* Attesters continue to produce Evidence;
* Verifiers continue to appraise Evidence and produce Attestation
Results;
* Relying Parties continue to consume Attestation Results; and
* TAPL is profile-specific Appraisal Policy logic for multi-root
synthesis.
This document does not redefine those roles.
7.2. Relationship to EAT
This profile does not require a new token format. EAT-based claims can
be used where deployments already use EAT to encode Evidence,
Attestation Results, or related claims.
CAR is therefore best understood as a higher-layer audit and replay
envelope. It can carry references to EAT-based artifacts, or to other
evidence and result encodings, together with the policy digest,
freshness context, and application-event binding needed for multi-root
replay.
8. CAR-to-RATS Mapping
| CAR field | RATS / EAT concept | Role primarily responsible | Purpose |
|-----------------------------------------|-------------------------------------------------------|-----------------------------------------|-------------------------------------------------------------------------|
| `attestation_evidence[]` | Evidence or references to Evidence | Attester, Verifier | Identifies the evidence set appraised for the authorization event |
| `policy_evaluation.synthesized_decision`| Attestation Results outcome | Verifier | Captures the deterministic result of multi-root appraisal |
| `policy_evaluation.tapl_policy_digest` | Appraisal Policy identifier or digest | Verifier or policy service | Shows which policy instance produced the result |
| `independence_metrics.*` | Application-specific appraisal predicates | Verifier or policy service | Records whether cross-root separation predicates passed at appraisal time|
| `freshness.*` | Freshness inputs associated with appraisal | Attester, Verifier | Supports replay rejection and same-session binding |
| `semantic_binding.*` | Application-specific claim binding | Verifier or application policy service | Binds the appraisal to the specific inference event being authorized |
| `semantic_consensus.*` | Application-specific consistency checks | Verifier or application policy service | Records whether cross-root semantic consistency checks passed |
| `cryptographic_binding.*` | Integrity protection around evidence references and result package | Verifier | Detects tampering after issuance |
9. Security Considerations
A deployment using this profile MUST ensure that synthesized appraisal
outputs cannot be detached from the specific evidence set, policy
digest, freshness context, and application event to which they apply.
In particular:
* replayed evidence from an earlier authorization event MUST be
rejected;
* mixed-session evidence sets MUST be rejected before synthesis;
* quote or evidence substitution after appraisal MUST be detectable;
* the freshness window for synthesis MUST be explicit;
* policy drift MUST be detectable through policy identity or digest;
and
* any timestamp token used for long-term replay MUST be bound to the
exact CAR digest being archived.
Where the profile carries application-specific semantic bindings, the
binding SHOULD use digests or references rather than raw application
payloads unless disclosure is operationally required.
10. Privacy Considerations
This profile SHOULD minimize disclosure of application-specific data.
A CAR need not contain raw Evidence bytes, raw inference inputs, or
raw model outputs when references or digests are sufficient for replay
and audit.
Deployments using EAT-based claims or equivalent encodings SHOULD
disclose only those claims required by the Relying Party's policy.
11. IANA Considerations
This document has no IANA actions.
12. References
12.1. Normative References
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Tsao, T.,
and W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, January 2023.
12.2. Informative References
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
Author's Address
Erkan Yalcinkaya
Luminesce Limited
United Kingdom
Email: yalcinkaya@luminescelimited.com
URI: https://luminescelimited.com