| Internet-Draft | SEAT Architecture | July 2026 |
| Ritz, et al. | Expires 5 January 2027 | [Page] |
This document defines an architectural framework for composing Remote ATtestation procedureS (RATS) with Secure Evidence and Attestation Transport (SEAT). The document establishes normalized terminology for SEAT, aligns RATS roles to transport endpoints, outlines topological patterns for attestation delivery timing, characterizes the abstract cryptographic pattern by which Evidence is bound to a given transport connection.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://tls-attestation.github.io/seat-architecture/draft-seat-architecture.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-many-seat-architecture/.¶
Source for this draft and an issue tracker can be found at https://github.com/tls-attestation/seat-architecture.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 5 January 2027.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
"Cryptography without system integrity is like investing in an armored car to carry money between a customer living in a cardboard box and a person doing business on a park bench."¶
— Gene Spafford¶
Traditional secure channel protocols, such as Transport Layer Security (TLS), primarily establish trust in a peer's identity. This is typically achieved through mechanisms like a Public Key Infrastructure (PKI), where a trusted Certification Authority (CA) vouches for the binding between a public key and an identifier (e.g., a hostname).¶
However, this model has a core limitation: identity authentication provides no assurance about the peer's internal state or the integrity of its software stack. A compromised server, for instance, can still present a valid X.509 certificate and be considered "trusted" by a client. This gap allows compromised endpoints to maintain network access and the trust of their peers, posing a significant security risk in many environments.¶
Remote Attestation (RA), as described in the RATS architecture [RFC9334], is a mechanism designed to fill this gap. RA allows an entity (the "Attester") to produce verifiable "Evidence" about its current runtime state. This Evidence covers the Attester's TCB, and can thus include measurements of its firmware, operating system, and application code, as well as the configuration of its hardware and software security features (e.g., secure boot status, memory isolation). A "Relying Party" can then use this Evidence, often with the help of a trusted "Verifier", to appraise the Attester's trustworthiness.¶
By integrating RA into a secure channel establishment protocol, a second dimension of trust—trustworthiness—is added to complement regular peer authentication. This allows a peer to make authorization decisions based not just on who the other party is, but also on what it is (e.g., an AMD SEV-SNP-based server running in some known datacenter) and whether its state is acceptable.¶
This document is intended as an input to the design of protocol solutions within the SEAT working group. A key goal is to define requirements for a solution that is agnostic to any specific attestation technology (e.g., Trusted Platform Modules (TPMs), Intel TDX, AMD SEV, Arm CCA, etc.).¶
For the scope of this architecture, the term "transport" is used interchangeably with "secure transport" to refer to secure channel establishment protocols.¶
The use cases motivating this architecture are defined in [I-D.mihalcea-seat-use-cases]. Readers are directed there for the full enumeration of deployment scenarios, requirements, and properties that protocol work in the SEAT working group is expected to satisfy.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document. Terms defined in [RFC9334] are used with the meanings established there; the definitions below extend or specialize those terms for the transport context.¶
This document adopts terms of art such as intra- and post-
as coined by [NIEME2021].¶
tbK):An asymmetric key pair whose private key is generated
and maintained exclusively within the Target Environment
(e.g., a TEE). The tbK is used to authenticate the Attester’s
transport endpoint (for example, signing the TLS CertificateVerify
message). Evidence produced by the Attesting Environment
MUST include a binding to the tbK.¶
hbK):A long‑lived asymmetric key pair whose private key resides
outside the Target Environment, typically in a Hardware Security
Module (HSM) or similar hardened service. The hbK’s certificate
provides the conventional identity (e.g., a WebPKI domain
validation) to the Relying Party. In deployments where a
short‑lived tbK is used, the hbK MAY authorise the tbK.¶
aeK):The asymmetric key used by the Attesting Environment
to sign Evidence. The Verifier trusts the aeK through an
Endorsement chain that typically roots in a hardware manufacturer
or a device‑specific CA. The aeK is used solely for attestation
and is distinct from any key used for transport authentication.¶
arK):The asymmetric key used by a Verifier to sign
Attestation Results. The Relying Party must possess the
corresponding trust anchor for the arK so that it can verify
the integrity and authenticity of received Attestation Results.¶
The attestation payload conveyed by the Attester to the Relying Party across the transport connection. Depending on the RATS conveyance model in use, this payload consists of either Evidence (Background-Check Model) or an Attestation Result (Passport Model). Where a statement applies specifically to one but not the other, this document uses the more specific term.¶
While Evidence is exclusively generated by the Attester and Attestation Results are generated by a Verifier, in the SEAT transport context, the Attestation Credential is always presented by the Attester directly to the Relying Party over the secure channel.¶
A transport session in which at least one endpoint has produced Evidence that has been appraised, and in which that Evidence is cryptographically bound to the session such that the appraisal cannot be replayed to a different session or transferred to a different endpoint.¶
The temporal relationship between Evidence conveyance and connection establishment time. This document defines two timing models: Intra-Handshake Attestation and Post- Handshake Attestation. See Section 5.¶
The point at which an Attester's Claims are signed to produce Evidence. Depending on the internal workings of the Attester, the Evidence reflects the reported state at the time the underlying Claims were collected and may not represent a snapshot of state at the exact moment of signing the evidence. In all cases, it makes no representation about the Attester's state at any later time.¶
The point at which a transport handshake completes and the session becomes usable for application data exchange.¶
The period from Connection Establishment Time until the session is torn down. Post-handshake re- attestation operates during the Lifetime of Connection, allowing Evidence to reflect the Attester's current state rather than its state at Connection Establishment Time.¶
The production and appraisal of fresh Evidence during an established session's Lifetime of Connection.¶
The interval during transport connection establishment in which Evidence is conveyed within the handshake messages themselves, prior to the transition to application data exchange.¶
The interval following connection establishment in which Evidence is conveyed to the Relying Party using post-handshake protocol mechanisms (e.g., Exported Authenticators or application-layer exchanges).¶
A value, uniquely determined by a specific transport session, from which Attestation Binders are derived. A Session Binding Value may be public or secret depending on the topology; what is required is that it cannot be known before the session is initiated. See Section 7.¶
A cryptographic value derived from a Session Binding Value and committed to by the Attesting Environment into its Evidence payload. This value binds the Evidence to a specific session guaranteed under typical cryptographic assumptions.¶
The point in the protocol at which an Attestation Binder is included in a protocol message. A binder may be computed and transmitted before peer authentication is complete.¶
The protocol mechanism by which the integrity of a transmitted Attestation Binder is established. Depending on the Attestation Timing Model, this may be achieved via a MAC that authenticates the handshake transcript (e.g., the TLS Finished message), or through post-handshake cryptographic binding (e.g., Exported Authenticators).¶
A deployment in which the Attesting Environment and the transport stack reside in different execution contexts. The transport stack is in the Target Environment; the Attesting Environment (e.g., a TEE) must receive the attestation binder input — typically a handshake transcript hash or exported key — from the transport stack via a trusted interface.¶
The SEAT architecture maps the roles defined in [RFC9334] to standard transport protocol entities. The subsections below describe each role and its specific character in the transport context.¶
The overarching SEAT goal is to establish an Attested Channel between two entities. Figure 1 shows the TLS and RATS roles that are involved in achieving this goal, and how they interact.¶
The Attester produces Evidence about its current state for consumption by a Verifier. In the transport context, the Attester is a network endpoint — either the Client or the Server — that possesses an Attesting Environment (such as a Trusted Execution Environment) capable of securely collecting Claims and signing them with an attestation key.¶
The Attester's transport stack provides the attestation binder input to the Attesting Environment so that Evidence can be bound to the specific session. In a Split Deployment, the transport stack is in the Target Environment and the interface between the transport stack and the Attesting Environment is a security-critical boundary. See Section 10.¶
In mutual attestation deployments, both the Client and the Server simultaneously act as Attesters. Each endpoint's Attesting Environment independently generates Evidence bound to the session.¶
The Relying Party consumes an Attestation Result and uses it to make authorization decisions about the transport connection. In the transport context, the Relying Party is typically the endpoint opposite the Attester — the Server when the Client attests, or the Client when the Server attests.¶
The Verifier appraises the validity of Evidence and produces Attestation Results, as defined in Section 4 of [RFC9334].¶
The appraisal is driven by an Appraisal Policy for Evidence, a set of rules that determines which Endorsements and Reference Values are required, which Claims must be present, and under what conditions Evidence is considered acceptable.¶
The Appraisal Policy may be configured as part of the Verifier’s trust anchors or supplied by a Relying Party in a deployment-specific manner. When Attestation Results are produced, they reflect the outcome of applying that policy.¶
How Evidence reaches the Verifier follows one of the two RATS conveyance models (Section 5 of [RFC9334]):¶
The Relying Party conveys the Attester's Evidence to the Verifier and receives Attestation Results in return. The Verifier may be co-located with the Relying Party, appraising Evidence inline, for example during an intra-handshake exchange that requires a real-time result before the connection is finalized or operated as a remote service.¶
The Attester conveys its Evidence to a remote Verifier, obtains Attestation Results, and presents those Results to the Relying Party.¶
Verifier location is an independent deployment choice: a co-located Verifier operates under the Background-Check Model, whereas a remote Verifier may operate under either model.¶
Figure 2 illustrates how Evidence and Attestation Results flow under the two conveyance models.¶
This section describes the trust relationships required to establish an Attested Channel. The general trust model of [RFC9334] Section 7 applies; the subsections below specialise it for the transport context.¶
The Relying Party must trust that the Attestation Credential it receives accurately reflects the Attester's state, which depends on its trust in the Verifier and in the Endorsement chain for the Attesting Environment.¶
The Relying Party must additionally satisfy itself that the Attestation Credential is bound to the current session — that it has not been replayed from a different session or transferred from a different endpoint. This assurance is provided by the session binding mechanism described in Section 7; the check may be performed by the Relying Party itself or delegated to the Verifier, but it cannot be pre-computed independently of the session.¶
For an Attesting Environment to be trustworthy to a Verifier, the Verifier must be able to establish trust in the signing key the Attesting Environment uses to produce Evidence. This is accomplished via an Endorsement chain from a hardware manufacturer or certificate authority that attests to the Attesting Environment's properties and the provenance of its attestation key. In the transport context, Endorsements may be conveyed alongside Evidence in the same transport message, or fetched out-of-band by the Verifier prior to or during appraisal.¶
The Relying Party must have a trust relationship with the Verifier commensurate with the sensitivity of the authorization decision. In the co-located Verifier deployment, this relationship is implicit: the Verifier's logic is part of the Relying Party's own implementation. In the remote Verifier deployment, the Relying Party must authenticate the Verifier and confirm that the Verifier's Appraisal Policy for Evidence is consistent with the Relying Party's own requirements before accepting any Attestation Credentials.¶
The timing and conveyance of Attestation Credentials relative to the transport handshake define the two Attestation Timing Models used in this architecture.¶
Depending on the approach, an Attestation Credential may be conveyed during Intra-Handshake Window or conveyed at the application layer in the Post-Handshake Window.¶
If the credential is Evidence, the Relying Party acts as or forwards it to a Verifier to appraise the Evidence. If the credential is an Attestation Result, the Relying Party evaluates it against its own Appraisal Policy for Attestation Results.¶
In both cases, an authorization decision must be made before the transport state machine permits application data to flow.¶
An Attestation Credential is conveyed by the Attester during the transport connection establishment to the Relying Party within the handshake messages themselves, prior to the transition to application data exchange. Upon receipt, the Relying Party processes the Attestation Credential.¶
The Relying Party, which may be deployed with a co-located Verifier, appraises the Evidence in real time and makes an authorization decision before the transport state machine permits application data to flow.¶
An Attestation Credential is conveyed by the Attester after transport connection establishment to the Relying Party following the transition to application data exchange.¶
The Attestation Binder is derived after handshake completion, tying the Attestation Credential to the completed session.¶
This deployment can be localized with the sidecar pattern, which withholds application data until the attestation procedure completes, decoupling the attestation protocol from application logic.¶
The two timing models may also be used together and their combination is the natural architecture for deployments requiring both immediate trust establishment and durable session integrity over long-lived connections.¶
In this composition, intra-handshake attestation establishes baseline trust before the session becomes usable: the Relying Party's Verifier must accept the Attester's Attestation Credential before application data can flow. The combined model suits constrained device and IoT deployments where a single attestation protocol handles both initial session trust and ongoing periodic re-attestion, avoiding separate code paths for onboarding and normal operation.¶
Protocol specifications building on this architecture MAY support one or both timing models.¶
When remote attestation occurs within the Intra-Handshake Window, the transport handshake withholds progression to application data exchange until the Attestation Result is available: application data exchange has not yet begun. A Verifier rejection, or a Relying Party policy rejection of an otherwise valid Attestation Result, MUST result in a fatal error consistent with the transport protocol's existing handshake-failure handling.¶
It is RECOMMENDED that the failure mode be interpretable by the application as a remote-attestation-related fault. Remote attestation specificity provides greater flexibility to apply application-layer policies, and assists in auditing and general debugging.¶
When attestation occurs within the Post-Handshake Window, or when Re-attestation fails during the Lifetime of Connection, the transport session already exists and application data may already be flowing. [RFC9334] expects a failed Attester appraisal to result in reduced access or privileges rather than outright rejection. In the event of failures occurring within the Post-Handshake Window, this behaviour is to be handled at the transport layer.¶
As the Relying Party's enforcement point sits outside the transport handshake, operating on already-established application-layer traffic, the Appraisal Policy determines whether the connection is torn down, or restricted to a subset of application-layer functionality. Failure handling of Post-Handshake Attestation does not retroactively protect application data already exchanged prior to the failed appraisal; it bounds further exposure going forward.¶
Regardless of which timing model is used or which transport protocol is in use, a correctly bound attested channel requires that three conditions hold in sequence.¶
The first condition is Session Binding Value establishment. The endpoints must derive or obtain a shared, session-specific Session Binding Value from which Attestation Binders can be derived. The Session Binding Value is bound to the specific session instance by construction, and may be public (for example, a handshake transcript) or secret (for example, an exporter-derived value).¶
The second condition is directional Binder derivation. From the Session Binding Value, the protocol derives distinct Attestation Binders for the initiator and the responder. The binders are directional: the initiator's binder cannot be substituted for the responder's and vice versa. This ensures that Evidence produced by one endpoint cannot satisfy the verification requirement for the opposite endpoint, even within the same session.¶
The third condition is channel binding to an Attestation Credential. The Attesting Environment signs its directional Attestation Binder into its Evidence payload, committing that Evidence to this specific session.¶
For this condition to hold when using the Passport model, the Verifier must propagate this binding into the resulting Attestation Result, ensuring the final Attestation Credential presented to the Relying Party remains committed to the specific transport session.¶
The first is replay across sessions. Because the Session Binding Value is unique to the session, an Attestation Credential committed to a binder derived from it cannot be presented in a different session. Where the Session Binding Value is secret, only the session participants can derive it. Where it is public, for example, a handshake transcript, its uniqueness follows from the ephemeral keying material that the transport establishes per session, so the transcript, and hence the binder, cannot recur across sessions.¶
The second is a Key Substitution Attack: a valid Attestation Credential produced by a genuine attested execution environment is presented while the Subject Key used for authentication was not generated or protected within that environment. Session binding alone does not bind the Subject Key to the attested environment; this is handled at the RATS layer, as discussed under Key Non-exportability in Section 10.¶
The Attestation Credential itself plays a critical role in verifying that these three session binding conditions have been successfully achieved. Beyond the cryptographic inclusion of the Attestation Binder, strict requirements for the internal structure and the application of logical safeguards protecting the Attestation Credential are necessary to provide assurance that the Attestation Credential could not have been generated through alternative means such as side-channel exploits.¶
When all three conditions are met, the channel-binding check may be performed either by the Relying Party itself or by the Verifier. As a session participant, the Relying Party holds the Session Binding Value and can compute the binder locally and MAY send it to the Verifier which compares it with the binder in the Evidence, avoiding the need requiring that the Relying Party decode the Evidence first.¶
If the Relying Party is directly consuming Evidence (Background-Check model), it rejects Evidence whose binder does not match. If the Relying Party is consuming an Attestation Result (Passport model) and expects per-session freshness (see Section 8.1), it MUST reject the Attestation Result if it cannot affirmatively evaluate that the Verifier explicitly tied the Attestation Result to the current session's Attestation Binder.¶
The freshness of Evidence is critical to its value as a trustworthiness signal. In the transport context, freshness has several distinct scopes that must be addressed separately.¶
Per-session freshness ensures that Evidence is bound to the specific session being evaluated and cannot be replayed from a prior session. This property is addressed directly by the session binding mechanism of Section 7. The Session Binding Value is specific to the session and cannot be known before the session is initiated, providing nonce-style freshness in the sense of [RFC9334] Section 10. Evidence committed to an Attestation Binder derived from the Session Binding Value is therefore intrinsically fresh with respect to the session: a replay from a different session will carry an Attestation Binder derived from a different Session Binding Value, and appraisal will fail.¶
Session resumption introduces a specific freshness consideration. When a transport session is resumed, a previously obtained Attestation Credential may no longer reflect the Attester's current state.¶
Initial attestation at Connection Establishment Time addresses the architectural invariants the Relying Party's policy requires before application data may flow. Re-attestation addresses the dynamic reality that established sessions may outlast the validity of a single trust assessment. Protocol specifications building on this architecture SHOULD treat these as distinct concerns.¶
Per-session freshness ensures Evidence cannot be replayed across sessions but does not address changes in the Attester's state during the Lifetime of Connection. A Relying Party MAY require Re-attestation before continuing to transmit sensitive data to a peer whose trust assessment has expired or whose deployment environment may have changed in ways material to its policy.¶
Re-attestation does not retroactively protect data transmitted before a state change occurred. It bounds further exposure by conditioning continued sensitive data transmission on a current trust assessment. Whether to terminate a session upon re-attestation failure or continue with reduced privilege is a matter of Relying Party policy; see Section 6.¶
The Evidence payload carries Claims about the Attester's state and is the most privacy-sensitive artifact in the protocol. It is RECOMMENDED that Evidence payloads be encrypted to a key held exclusively by the intended recipient (typically the Verifier), so that the Evidence content is disclosed only to that recipient and not to the Relying Party or to other parties on the path.¶
The complementary control for the Relying Party surface is minimization: the Attestation Results returned to the Relying Party SHOULD NOT re-expose sensitive Claims that were protected in any encrypted Evidence. A framework for consistent handling of sensitive Evidence across RATS roles, including claim classification, Trusted Verifier management, and Attestation Credential minimization, is provided in [I-D.ounsworth-rats-privacy-framework].¶
The transport connection discloses metadata — IP addresses, server name indications, and connection timing — that is visible to passive network observers. This disclosure is inherent to the transport protocol and is not specific to the attestation layer.¶
When the same attestation signing key is used across multiple sessions, any party with access to Evidence from more than one of those sessions can correlate the sessions to the same Attesting Environment. This linkability consideration is particularly relevant for client Attesters where privacy of individual connections is a concern.¶
The SEAT architecture supports deployments where a client Attester attests to the trustworthiness of its Attesting Environment without presenting a TLS client identity certificate, enabling anonymous client attestation. In this deployment, the Relying Party's appraisal policy applies to the client's hardware and software state rather than to a disclosed identity.¶
The IAB has issued a statement cautioning that using client attestation as a barrier to access for otherwise open protocols and services risks undermining Internet openness [IAB-Attestation-Risks]. The statement distinguishes services with intentionally restricted access — for which client attestation is recognized as a valuable security measure — from openly accessible services, for which imposing hardware or software requirements on participating implementations is inappropriate. SEAT is scoped to the former category: the use cases motivating this work involve confidential workloads, enterprise-controlled environments, and TEE-backed services where access is explicitly conditioned on verified platform state.¶
The IAB statement further identifies the disclosure of vendor- specific hardware and software information as a distinct risk: attestation evidence that reveals which specific implementations are in use can restrict access and enable tracking in ways that undermine the open internet. Protocol designs building on this architecture should minimize vendor-specific claim disclosure consistent with the Attestation Credential minimization controls described in this section and in [I-D.ounsworth-rats-privacy-framework].¶
This section enumerates the security properties and considerations of the SEAT architecture. Security goals state outcomes the architecture is designed to achieve; they carry no normative mandates. Security properties state technical characteristics the protocol is expected to exhibit and may carry normative requirements. Implementations MUST also consider the Security Considerations of [RFC9334] and of any protocol specification that instantiates this architecture.¶
Cryptographic Session Binding and Relay Prevention. An Attestation Credential presented on a session MUST be cryptographically bound to that session and to the endpoint role in which it is presented. This is achieved by binding the Attestation Credential to an Attestation Binder derived from a Session Binding Value that is specific to the session and cannot be known before the session is initiated. Consequently, a valid Attestation Credential from one session cannot satisfy a Verifier or Relying Party on a different session or from a different endpoint; a replay carries a Binder derived from a different Session Binding Value and MUST be rejected. See Section 7.¶
Split-Deployments. Because a compromised host could attempt to use the Attesting Environment as a signing oracle by substituting the attestation binder input, the architecture relies on cryptographic binding rather than continuous state monitoring. The Attesting Environment MUST bind the Attestation Credential to the private identity key it holds to authenticate a connection (for example, by including a hash of the associated public key in the signed payload).¶
The Relying Party then verifies that this claim matches the identity key presented in the transport handshake, preventing an untrusted host from successfully substituting the binder.¶
Key Non-exportability (informative). The specific concern of demonstrating that the Subject Key used for transport authentication is physically confined within the attested execution environment is addressed at the RATS layer by [I-D.reddy-rats-key-binding] and is not re-specified here.¶
Evidence Freshness. Evidence reflects the Attester's state at or near the Evidence Generation Time for the session in which it is presented. Per-session freshness ensures Evidence from a prior session cannot be replayed against a new one. When re-attestation occurs during a session's Lifetime of Connection, the re-attestation Evidence reflects the Attester's state at the time of re-attestation, not at Connection Establishment Time.¶
Evidence Confidentiality. Evidence payloads SHOULD be protected by object-level encryption to a key held exclusively by the intended recipient. See [I-D.ounsworth-rats-privacy-framework].¶
Session Resumption. When a transport session is resumed, previously obtained Attestation Credential may no longer reflect the Attester's current state. Attestation from a prior session does not carry over to a resumed session.¶
Directional Endpoint Binding. Distinct Attestation Binders MUST be derived for the initiator and the responder from the same Session Binding Value using distinct inputs. Evidence produced by one endpoint MUST NOT satisfy the verification requirement for the opposite endpoint. See Section 7.¶
Transmission and Verification Anchor Soundness. An Attestation Binder may be included in a transport message before peer authentication is complete (the Transmission Anchor). Implementations MUST ensure the transport protocol's integrity guarantee covers the message carrying the Attestation Binder; for example, the TLS 1.3 handshake MAC (the Verification Anchor) retroactively guarantees the Binder's integrity at handshake completion.¶
Downgrade Prevention. Two endpoints that both support attestation cannot be caused by an active adversary to negotiate a connection without it. The negotiation of attestation capabilities is protected against suppression.¶
Dynamic Verification Code Integrity. When client-side attestation verification logic is dynamically delivered by the endpoint under appraisal (such as browser-based JavaScript), a circular trust dependency exists. Unless the client's execution environment enforces an independent, orthogonal guarantee of code integrity and binary transparency, Application-layer attestation cannot provide security assurance, as the Attester may serve malicious code that bypasses cryptographic validation.¶
This document has no IANA actions.¶
The Timing Models of Section 5 describe when an Attestation Credential is conveyed relative to connection establishment. This section describes two structural implementation examples by which a transport protocol conveys an Attestation Credential to the Relying Party without requiring the transport specification itself to encode RATS semantics.¶
Depending on the conveyance model, the Relying Party either forwards Evidence to a Verifier to receive an authorization decision (Background-Check Model) or validates an Attestation Result directly (Passport Model).¶
In this pattern, the transport protocol's existing identity or authentication structures (such as an X.509 certificate extension, or a comparable protocol-specific extension point) are reused to carry an Attestation Credential. The transport stack itself remains unaware of [RFC9334] semantics: it recognizes only that an extension it is configured to process is present, and delegates interpretation of the extension's contents to an external callback.¶
The transport state machine suspends progress at the point the extension is processed, invokes the callback with the extension payload, and resumes or aborts the handshake based on the callback's return value. The callback interface is transport-external: it need not be specified by the transport protocol itself, only supported by it as an extension point.¶
In this pattern, the transport protocol defines a dedicated, opaque field for authorization-related data as part of its handshake or key-exchange messages, distinct from the identity structures used for peer authentication. The Attestation Credential, and any associated attestation-specific protocol elements, are carried within this field.¶
The transport stack extracts the field's contents and passes them to an adjacent component responsible for [RFC9334] semantics, without needing to parse or understand the contents itself. As in Extension-Based Conveyance, the transport state machine halts pending the outcome of this processing. The distinction between the two patterns is where the extension point is anchored: an existing identity structure being overloaded (Extension-Based Conveyance) versus a field purpose-defined by the transport protocol for authorization data (Structured Payload Conveyance).¶
Both patterns satisfy the requirement that an Attestation Credential be conveyed prior to the transition to application data exchange; the choice between them depends on the target transport protocol's extension model and is otherwise architecturally equivalent from an [RFC9334] perspective.¶
The authors wish to thank all SEAT WG participants for their thoughtful input and contributions that have helped influence this document.¶