1id.com

Australia cnd@1id.com https://1id.com

Security hardware attestation email agent identity AIRS TPM PIV SD-JWT This document defines two email bindings for proving properties of an automated sender using the durable identity and anchor architecture of the Agent Identity Registry System (AIRS). Mode 1 carries a detached CMS signature made by a message-signing proof key. It can provide manufacturer-rooted hardware provenance, Registrar-backed AIRS identity binding, or both. Mode 2 carries a per-message SD-JWT that allows a Registrar to assert selected properties without requiring disclosure of the sender's canonical AIRS identifier. The AIRS identity0 model, canonical aid identifier, trust tiers, anchor semantics, enrollment rules, and Registrar trust boundary are defined by and . Authoritative resolution of the current Registrar/OAuth issuer is defined by . This document does not redefine those concepts; it defines how email messages bind to and verify them.

Introduction SPF , DKIM , and DMARC provide domain- and infrastructure-layer authorization, authentication, alignment, and policy signals. They do not identify the autonomous actor that caused a message to be sent, nor do they establish durable continuity of that actor across domains, providers, credentials, or hardware changes. The general motivation and the strict meaning of identity0 are defined by . AIRS supplies the durable subject, enrolled anchor bindings, operational proof keys, trust tiers, and Registrar trust boundary. This specification applies that foundation to email. It deliberately does not define another identity model, hardware taxonomy, enrollment ceremony, or reputation system. This document defines two application mechanisms:

1. Mode 1: Direct Hardware Attestation. A Hardware-Attestation header carries a detached CMS signature made by the Mode-1 signing key. Manufacturer-rooted evidence can establish hardware provenance. A Registrar binding assertion can additionally authenticate a canonical AIRS aid and trust tier.
2. Mode 2: SD-JWT Trust Proof. A Hardware-Trust-Proof header carries a per-message SD-JWT . The sender can disclose a canonical aid for identified AIRS verification or withhold it and expose only selected properties under receiver-local issuer policy.

Application Design Principles

Canonical ownership

Identity0, canonical identifiers, trust tiers, anchor scarcity, lifecycle, and Registrar accreditation are owned by the companion specifications and are referenced rather than restated here.

Message binding

An attestation that is valid for one message MUST NOT be transferable to different headers or body content.

Proof is not behavior

A valid proof says what actor/key/hardware property was verified; it does not say that the message is benign, authorized for a business action, or worthy of positive reputation.

Explicit trust path

Manufacturer-rooted evidence and Registrar-backed assertions are different trust paths. A verifier MUST know which path established a result and MUST NOT silently treat Registrar verification as direct manufacturer verification, or vice versa.

Privacy by application choice

Mode 1 is intentionally linkable when an aid or stable proof key is exposed. Mode 2 permits selective or pseudonymous disclosure where the receiving policy does not require identity0 continuity.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology Foundational identity and AIRS terms are used as defined in and .

Manufacturer-rooted Mode 1

Mode 1 in which the message-signing proof key is authenticated by evidence that the verifier validates to an accepted manufacturer or attestation root. This establishes hardware/key provenance; it does not by itself establish AIRS identity binding.

Registrar-bound Mode 1

Mode 1 carrying a Registrar-signed binding assertion that binds a canonical aid, the operational proof key, and the asserted AIRS trust tier.

Identified Mode 2

A Mode-2 presentation that discloses canonical sub and is therefore verified against that identity's authoritative current issuer.

Hidden-identity Mode 2

A Mode-2 presentation that withholds sub. It is an issuer property assertion under receiver-local issuer policy, not proof of current sponsorship or identity0 continuity.

Applicability This specification is intended for autonomous or automated senders for which a receiver benefits from durable actor continuity, verified hardware provenance, or a Registrar-backed property assertion. It does not require every process, model invocation, container, or message-generation instance to have a separate identity0; the identity boundary is the independently accountable actor defined by the Problem Statement.

Email Binding Architecture The canonical AIRS architecture is defined by . This section states only the mappings required to interpret the email wire formats.

Canonical Identifier Use When this document carries an AIRS identity identifier, it carries the permanent canonical aid defined by the Registry specification, for example urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg. A handle MUST NOT be used in the aid parameter or the Mode-2 sub claim because verification and long-lived state require the canonical identifier.

Email Mechanism Type Mapping The typ values in Mode 1 are application mappings to the Registry-owned mechanism/tier definitions. They do not create an independent hardware taxonomy:

typ	Registry tier when Registrar-bound	Application mechanism
TPM	sovereign	Physical TPM-backed proof key
PIV	portable	Physical PIV/token-backed proof key
ENC	enclave	Hardware-enclave protected key
VRT	virtual	Virtual/infrastructure protected key
SFT	declared	Software-managed proof key

For Registrar-bound Mode 1, the asserted AIRS tier MUST match this mapping and the verifier MUST apply the assurance semantics defined by the Registry specification. Manufacturer-rooted Mode 1 uses typ only to identify the mechanism whose provenance was verified; without a Registrar binding it MUST NOT be reported as an AIRS tier. In particular, ENC and VRT do not acquire a one-physical-unit-per-identity scarcity property merely because the key is hardware backed.

Authoritative Registrar Key Discovery Whenever a presentation discloses a canonical aid, the verifier MUST resolve that identifier using and obtain its authoritative currentIssuer. If the identity has no current authorized issuer, Registrar-backed verification fails. The verifier then obtains OAuth Authorization Server Metadata for that exact issuer as specified by . An issuer used with this Email profile MUST publish jwks_uri. The metadata issuer value MUST exactly equal currentIssuer; otherwise the metadata MUST NOT be used. Absence of jwks_uri is a permanent verification error. Registrar signing keys are obtained only from that authenticated JWK Set. A token, certificate, or JWS supplied by the sender MUST NOT bootstrap its own issuer authority. For hidden-identity Mode 2 there is intentionally no per-identity resolution step. The receiver first decides by local policy that the visible iss value is an issuer it trusts for the asserted property; only then may it use RFC 8414 discovery for that issuer. Such a result does not establish current sponsorship of an undisclosed AIRS identity.

Mode 1: Direct Hardware Attestation Mode 1 binds the email to a message-signing proof key with a detached CMS SignedData signature. The same wire format supports two distinct trust paths: manufacturer-rooted key provenance and Registrar-backed AIRS identity binding.

Evidence Profiles The CMS signer certificate carries the public key corresponding to the Mode-1 signing key. Trust in that key is established by one or both of the following profiles:

Manufacturer-rooted

The signer certificate or other mechanism-specific certificate path carried in SignedData directly authenticates the message-signing proof key to a manufacturer or attestation root accepted by the verifier. The verifier MUST ensure the evidence actually binds that same proof key and is consistent with typ. A manufacturer certificate for a different device key is insufficient. For example, a TPM EK certificate alone does not prove that an arbitrary AK that signed the message is resident in that TPM. Where no standardized direct evidence binds the signing key to the manufacturer-rooted device, this profile is unavailable and the Registrar-bound profile is used.

Registrar-bound

The header carries both aid and bind. The bind value is a compact JWS whose payload binds the canonical aid, the exact operational proof public key, and the AIRS trust tier. It is signed by the identity's authoritative current Registrar and verified using . The verifier relies on that Registrar to have performed the Registry-defined enrollment checks for the asserted tier.

A proof MAY satisfy both profiles when manufacturer evidence and a current Registrar binding assertion authenticate the same operational proof key. These are then independent evidence paths only to the extent that their trust anchors are actually independent.

Header Field and CMS Profile Hardware-Attestation = "Hardware-Attestation" ":" hw-attest-value CRLF ; The tag layout follows the tag-spec convention of RFC 6376 ; Section 3.2, which DKIM2 also reuses, so a DKIM tag-list ; tokenizer can be reused to split this field. Unlike a generic ; DKIM tag-list, the tag order here is fixed and no extension ; tags are defined. hw-attest-value = hw-version ";" hw-type ";" hw-algorithm ";" hw-signed-hdrs ";" hw-body-hash ";" hw-timestamp ";" hw-chain [";" hw-aid ";" hw-bind] [";"] [FWS] hw-version = [FWS] "v" [FWS] "=" [FWS] "1" [FWS] hw-type = [FWS] "typ" [FWS] "=" [FWS] mech-code [FWS] hw-algorithm = [FWS] "alg" [FWS] "=" [FWS] alg-code [FWS] hw-signed-hdrs = [FWS] "h" [FWS] "=" [FWS] folded-hdrs [FWS] hw-body-hash = [FWS] "bh" [FWS] "=" [FWS] folded-b64url [FWS] hw-timestamp = [FWS] "ts" [FWS] "=" [FWS] folded-digits [FWS] hw-chain = [FWS] "chain" [FWS] "=" [FWS] folded-base64 [FWS] hw-aid = [FWS] "aid" [FWS] "=" [FWS] folded-urn [FWS] hw-bind = [FWS] "bind" [FWS] "=" [FWS] folded-jws [FWS] mech-code = "TPM" / "PIV" / "ENC" / "VRT" / "SFT" alg-code = "RS256" / "ES256" / "PS256" ; Every tag value MAY carry internal folding whitespace, which is ; not part of the value. The comment beside each production gives ; what that value MUST match once the whitespace has been removed. folded-hdrs = 1*(ftext / ":" / WSP / FWS) ; -> hdr-name *(":" hdr-name) folded-b64url = 1*(b64url-char / WSP / FWS) ; -> 1*b64url-char folded-digits = 1*(DIGIT / WSP / FWS) ; -> 1*DIGIT folded-base64 = 1*(b64-char / WSP / FWS) ; -> 1*b64-char folded-urn = 1*(urn-char / WSP / FWS) ; -> aid-urn folded-jws = 1*(b64url-char / "." / WSP / FWS) ; -> compact-jws compact-jws = base64url "." base64url "." base64url base64url = 1*b64url-char b64url-char = ALPHA / DIGIT / "-" / "_" b64-char = ALPHA / DIGIT / "+" / "/" / "=" urn-char = ALPHA / DIGIT / "-" / ":" hdr-name = field-name field-name = <field-name defined by RFC 5322> ftext = <ftext defined by RFC 5322> aid-urn = <canonical aid URN defined by the AIRS Registry> FWS = <FWS defined by RFC 6376 Section 2.8> WSP = <WSP defined by RFC 5234> base64url and base64 use the encodings of ; base64url is emitted without padding. Parameter names in a generated field MUST use the lowercase forms shown above, and the tags MUST appear in the order shown. A single trailing semicolon after the last tag is OPTIONAL: a generator MAY emit it, and a verifier MUST accept the field with or without it. This version defines no extension tags. Unlike a generic DKIM tag-list, an unrecognized tag name MUST cause the field to be treated as malformed rather than being ignored, because the signed reconstruction below has to be reproducible byte-for-byte by every verifier and cannot carry content the verifier does not understand. CMS objects, compact JWS values, and long header-name lists all exceed one physical email line, so every tag value in this field other than the single-token v, typ, and alg values MAY carry internal folding whitespace. No value defined here can contain significant whitespace, so this specification applies to all of its tags the rule that states for the DKIM b= and bh= tag values: WSP and FWS appearing anywhere inside a tag value is not part of that value and MUST be removed in its entirety before the value is decoded, parsed, or compared. Folding whitespace MAY therefore be inserted at any point within a tag value solely to satisfy header-field line-length requirements, including inside a base64 or compact-JWS token and inside a header field name in the h list. Deployed signers are observed to fold header-name lists in mid-token in exactly this way, so a verifier that accepts folding only at separator boundaries will reject otherwise valid mail. Whitespace inside a tag name is not permitted. RFC 5322 unfolding alone is not sufficient for this purpose because it removes the folding CRLF but leaves the following WSP. Therefore, whether a parser receives the raw folded field or an already-unfolded field, it MUST perform this removal before interpreting any value. After removal, each value MUST match the post-removal production shown beside its production above; in particular the bind value MUST match compact-jws and the h value MUST match hdr-name *(":" hdr-name). aid and bind either both appear or both are absent. A sender MUST NOT place an aid in Mode 1 without the Registrar binding assertion required below.

v

Protocol version; exactly 1.

typ

The application mechanism code from . The value is message-signed and MUST match the verified evidence or Registrar assertion.

alg

A compact label for the CMS signer algorithm, mapped normatively by . The JOSE-style labels identify the algorithm choice only; CMS signature-value encoding follows the cited CMS specifications, not JOSE encoding. New deployments SHOULD prefer PS256 for RSA or ES256 for P-256.

h

A colon-separated DKIM-style list of header field names. The signer MUST include at least From, To, Subject, Date, Message-ID, Reply-To, MIME-Version, Content-Type, and Content-Transfer-Encoding, whether or not each is present: under the DKIM rules a listed field that is absent protects against its later addition, and these fields change how the message is displayed or answered. Header selection and repeated-name processing follow the DKIM h= conventions of . The Hardware-Attestation field itself MUST NOT appear in h; it is implicitly appended last as described below. In Combined mode the signer MUST also include Hardware-Trust-Proof.

bh

Base64url-encoded SHA-256 of the email body after DKIM simple body canonicalization.

ts

Unix time at which the Mode-1 signature was created, serialized as unsigned decimal without leading zeroes. Freshness is receiver policy; it is not an identity lifetime.

chain

Base64-encoded CMS SignedData as profiled below.

aid

The canonical AIRS identifier. It is present only with bind and MUST equal the binding JWS sub claim.

bind

A compact Registrar binding JWS as profiled in .

The message input is constructed as follows: attestation-input = h-hash || bh-raw || ts-bytes h-hash = SHA-256(canonicalized-headers) ; 32 bytes bh-raw = SHA-256(canonicalized body) ; 32 bytes ts-bytes = big-endian uint64(ts) ; 8 bytes The attestation-input is exactly 72 octets. For h-hash, the headers named by h are selected using the DKIM header-selection rules and canonicalized with DKIM relaxed header canonicalization, each followed by CRLF. The Hardware-Attestation field itself is then appended using the signature canonicalization that applies to its own signature-bearing fields: the field name is lowercased to hardware-attestation, the field is unfolded, every WSP character anywhere in the field value is deleted, the chain tag value is replaced by the empty string (the chain= tag itself remains), and the result is followed by CRLF. A verifier applies this to the field as received; a generator applies it to the field it emits, which MUST use the lowercase tag names and fixed order of the ABNF above. All other tag values, including aid and the compact bind JWS, remain covered. Because only whitespace is removed, every legal folding of the field, and any legal RFC 5322 refolding applied in transit, produces the same signed input. The chain CMS object MUST use SignedData with encapContentInfo present, eContentType equal to id-data, and eContent omitted. The externally supplied detached content is the exact 72-octet attestation-input; implementations MUST NOT pre-hash that value and then present the digest to CMS as though it were the content. SignerInfo signedAttrs MUST be absent in version 1, so the CMS signature/digest processing is unambiguous. The CMS digestAlgorithm is SHA-256 and the SignerInfo signatureAlgorithm MUST match the alg mapping in . The SignedData certificates field MUST contain the signer certificate. It MAY also contain certificates needed by a manufacturer-rooted evidence path. In the Registrar-bound path the signer certificate is only a carrier for the operational proof public key. It MAY be self-signed or otherwise untrusted as a certificate path; the verifier's authority for the aid-to-key binding comes from bind, not from trusting that certificate's issuer.

CMS Algorithm Mapping Version 1 supports exactly the following mappings. Implementations MUST reject a mismatch between alg, SignerInfo digestAlgorithm, SignerInfo signatureAlgorithm, its parameters, and the signer public-key type.

alg	CMS signatureAlgorithm	Requirements
RS256	sha256WithRSAEncryption 1.2.840.113549.1.1.11	RSASSA-PKCS1-v1_5 with SHA-256 as specified by . AlgorithmIdentifier parameters are NULL when generated; receivers also accept absent parameters as required by RFC 5754. RFC 5754 adopts the RSA conventions of , under which CMS implementations support the rsaEncryption signature identifier (1.2.840.113549.1.1.1, NULL parameters) that many CMS libraries generate, so receivers MUST also accept rsaEncryption as the SignerInfo signatureAlgorithm for RS256.
ES256	ecdsa-with-SHA256 1.2.840.10045.4.3.2	ECDSA using the P-256 curve and SHA-256 under the CMS conventions of . AlgorithmIdentifier parameters MUST be absent. The CMS signature value is the DER ECDSA-Sig-Value representation; it is not the JOSE raw R || S representation.
PS256	id-RSASSA-PSS 1.2.840.113549.1.1.10	RSASSA-PSS under with SHA-256, MGF1 with SHA-256, salt length 32 octets, and trailerField 1. The AlgorithmIdentifier parameters MUST encode those choices.

For all three mappings, SignerInfo digestAlgorithm and the SignedData digestAlgorithms set MUST identify SHA-256.

Registrar Binding JWS A Registrar-bound Mode-1 message carries a compact JWS in bind. Its payload is a JWT with the following claims:

iss

REQUIRED. The Registrar OAuth issuer URI.

sub

REQUIRED. The same canonical aid carried by the Hardware-Attestation header.

iat

REQUIRED. Binding-assertion issuance time. A verifier MUST reject a value materially in the future.

exp

REQUIRED. Expiration time, which MUST be later than iat. A verifier MUST NOT accept an expired binding assertion, subject only to normal small clock-skew allowance.

cnf

REQUIRED. A confirmation object containing jwk for the exact public key in the CMS signer certificate.

aid

REQUIRED. The Registry-defined AIRS claim object. Its trust_tier member reports the tier of this enrolled proof binding. Email does not redefine the tier values.

The binding JWT is a JWS using compact serialization . Its protected header MUST contain alg, kid, and typ. The typ value MUST be airs-email-binding+jwt, denoting application/airs-email-binding+jwt as registered by ; verifiers MUST reject another type. This explicit profile separation follows the cross-JWT confusion guidance of . alg MUST select an asymmetric digital-signature algorithm acceptable for the selected public key; none and symmetric-MAC algorithms MUST NOT be accepted. The verifier resolves the header aid, obtains currentIssuer, and performs . The JWS iss MUST exactly equal currentIssuer; the kid MUST select a signing-capable public key in that issuer's authenticated JWK Set; the selected key and alg MUST satisfy the algorithm-validation requirements of ; the JWS signature MUST verify; iat and exp MUST satisfy the time requirements above; and sub MUST equal the header aid. To compare cnf.jwk with the CMS signer public key, the verifier converts the signer public key to its public JWK representation and requires equal JWK thumbprints as defined by . The cnf.jwk value MUST NOT contain private key parameters. Finally, aid.trust_tier MUST correspond to typ according to . The binding JWS is not the email message signature. It is reusable until expiration; possession of it does not let an attacker send a valid message because the CMS signature still requires the enrolled operational proof private key. Registrars SHOULD keep its lifetime short enough that retirement or compromise of a proof binding does not leave a long-lived stale assertion, and receivers MAY impose a local maximum assertion age in addition to enforcing exp. Expiration determines whether the Registrar binding is currently acceptable; it does not retroactively alter the cryptographic integrity of a stored email. A trusted receiving system can preserve a receipt-time verification result in Authentication-Results, optionally protected by ARC, when later archival processing needs to distinguish those two questions.

Verification Algorithm A verifier processes Hardware-Attestation as follows:

1. Require exactly one Hardware-Attestation field and no more than one instance of each of the nine always-covered fields (From, To, Subject, Date, Message-ID, Reply-To, MIME-Version, Content-Type, and Content-Transfer-Encoding). Reject duplicates, unsupported versions, malformed encodings, an aid without bind, or a bind without aid as permerror.
2. Verify that h covers the required fields; reconstruct h-hash; recompute the canonical body hash and require exact equality with bh.
3. Apply local freshness policy to ts. A stale but otherwise cryptographically valid proof is a policy outcome, not a forged signature. The first trusted receiving MTA SHOULD record its decision in Authentication-Results for later use.
4. Decode SignedData, require the detached-CMS profile of , supply the exact attestation-input as external content, and verify the CMS signature with the signer certificate public key.
5. If the verifier evaluates a manufacturer-rooted result, validate the signer key's manufacturer/attestation evidence under its current accepted-root policy. The evidence MUST directly establish the relationship to the same signer public key and MUST be consistent with typ. Failure is fail.
6. If aid is present, verify the Registrar binding JWS exactly as specified in . If the AIRS identity has no current issuer, the issuer differs, or the assertion no longer validates, AIRS identity verification fails even if the CMS message signature itself is valid.
7. Record which trust path(s) succeeded. A manufacturer-only result MUST NOT report an authenticated aid. A Registrar-bound result MAY report the verified aid and asserted trust tier. The verifier then applies its own authorization, reputation, and mail policy.

Authentication-Results Integration Authentication-Results: mx.example.com; hw-attest=pass header.typ=TPM header.alg=PS256 header.tier=sovereign header.aid="urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg" The hw-attest method and its result names/properties are registered by . tier and aid are reported only when Registrar binding verification succeeded.

Mode 2: SD-JWT Trust Proof Mode 2 carries a per-message SD-JWT signed by a Registrar. It allows a sender to disclose the AIRS trust tier while withholding the canonical identity when receiver policy does not require continuity.

Trust Semantics The Registrar has already verified the enrollment evidence for the active binding and is the trust boundary for the asserted AIRS tier. Recipients do not revalidate manufacturer chains in Mode 2. If canonical sub is disclosed, the presentation is identified: the verifier MUST resolve that aid, obtain currentIssuer, and require the SD-JWT iss to equal it. If sub is hidden, the verifier cannot perform that per-identity check. It can only decide that it trusts the visible issuer, under local policy, to make the disclosed property assertion. Hidden Mode 2 MUST NOT be described as proof of current sponsorship, durable identity continuity, or an identity reputation key.

Header Field and Claims Hardware-Trust-Proof = "Hardware-Trust-Proof" ":" folded-sd-jwt CRLF folded-sd-jwt = 1*(sd-jwt-char / WSP / FWS) ; -> 1*sd-jwt-char sd-jwt-char = ALPHA / DIGIT / "-" / "_" / "." / "~" FWS = <FWS defined by RFC 6376 Section 2.8> WSP = <WSP defined by RFC 5234> The serialized Hardware-Trust-Proof value uses the same whitespace-removal semantics as the DKIM b= and bh= tag values of and as the Mode-1 tag values of . WSP and FWS MAY be inserted at arbitrary positions solely to satisfy header-field line-length requirements. Such whitespace is not part of the SD-JWT serialization and MUST be removed in its entirety before parsing the resulting SD-JWT presentation according to . RFC 5322 unfolding alone is not sufficient for this purpose because it removes the folding CRLF but leaves the following WSP. Therefore, whether a parser receives the raw folded field or an already-unfolded field, it MUST remove all such whitespace before SD-JWT parsing. No Key Binding JWT is used in ordinary Mode 2. The Issuer-signed JWS protected header MUST contain alg, kid, and typ; typ MUST be airs-email+sd-jwt, denoting application/airs-email+sd-jwt as registered by , and another type MUST be rejected. The signing algorithm MUST satisfy and MUST be an asymmetric digital-signature algorithm; none and symmetric-MAC algorithms MUST NOT be accepted. The Issuer-signed payload MUST contain iss, iat, nonce, and the SD-JWT disclosure structures required by . iss, iat, and nonce MUST NOT be selectively disclosable because they are required before or during verification. exp is OPTIONAL; when present it likewise MUST NOT be selectively disclosable, has normal JWT semantics, and an expired token MUST NOT be accepted as currently valid. This profile reuses the Registry-defined aid claim object rather than defining a second trust-tier claim. The following values are selectively disclosable:

aid.trust_tier

The Registry-defined tier of the binding the Registrar authenticated for this issuance. Every Mode-2 presentation conforming to this specification MUST disclose this member.

sub

The permanent canonical AIRS aid. Disclosure changes verification from hidden-identity to identified Mode 2.

Outside Combined mode the Issuer-signed payload MUST omit cnf. For Combined mode, it MUST instead contain a non-selectively-disclosable cnf claim whose jwk is the active operational proof public key. Combined-mode verification depends on that key, so it is validity-critical in that profile and is deliberately not made a selective disclosure. Issuers MAY place other selectively disclosable claims in the SD-JWT, but their semantics are outside this specification. In particular this document does not standardize operator contact data, certifications, reputation, enrollment timestamps, credential counts, or Registry lifecycle fields as email claims.

Message Binding via Issuer-Signed Nonce The sender computes a message-binding nonce before requesting the per-message SD-JWT: message-binding = h-hash || bh-raw || ts-bytes nonce = base64url(SHA-256(message-binding)) h-hash = SHA-256(canonicalized-headers) ; 32 bytes bh-raw = SHA-256(canonicalized body) ; 32 bytes ts-bytes = big-endian uint64(iat) ; 8 bytes The sender proposes iat; the Registrar MUST reject a proposed value outside its configured clock-skew allowance. The accepted value is used both in the JWT and in ts-bytes. h-hash uses the fixed header-name list From, To, Subject, Date, Message-ID, Reply-To, MIME-Version, Content-Type, and Content-Transfer-Encoding, in that order (the same fields Mode 1 always covers). Header selection, including absent fields and repeated names, follows the DKIM h= rules; selected fields use DKIM relaxed header canonicalization and are each followed by CRLF. Listing a field that is absent at signing therefore also protects against later addition of that field; duplicate singleton fields are rejected by . The exact ASCII string hardware-trust-proof: is appended last with an empty value and no trailing CRLF. bh-raw is SHA-256 of DKIM simple body canonicalization. The sender submits nonce and iat to the Registrar over an authenticated channel. The Registrar MUST authenticate an active AIRS binding and MUST issue aid.trust_tier for the binding actually used. It returns an SD-JWT and disclosures; the sender chooses which optional disclosures to present. The issuer signature authenticates every disclosed value through the SD-JWT disclosure hashes, but the choice of which optional disclosures are included is not message-bound by this nonce construction because the Hardware-Trust-Proof value is blank during nonce computation. This specification makes no stronger claim. Combined mode provides an additional Mode-1 signature over the complete Mode-2 header.

Verification Algorithm

1. Require exactly one Hardware-Trust-Proof field and no more than one instance of each of the nine always-covered fields (From, To, Subject, Date, Message-ID, Reply-To, MIME-Version, Content-Type, and Content-Transfer-Encoding). Reject duplicates as permerror. Parse the SD-JWT presentation and treat all unverified claims and disclosures as untrusted input.
2. If a canonical sub disclosure is present, use it only as a candidate lookup key: resolve it, obtain currentIssuer, and require the visible iss to equal that URI. If there is no current issuer, fail identified verification. If sub is not disclosed, require local policy to trust the visible iss before using it for discovery.
3. Perform and verify the SD-JWT signature and disclosures according to . Require disclosure of aid.trust_tier and accept its value only with the semantics defined by the Registry specification. If the verified Issuer-signed payload contains cnf but the message has no Hardware-Attestation field, reject the presentation rather than silently degrading a Combined proof to standalone Mode 2.
4. Require iat and nonce. Reject a materially future iat. If exp is present, enforce it according to ; delivery delay does not make an expired JWT valid.
5. Recompute the nonce exactly as defined in and require byte-for-byte equality.
6. Apply receiver-local age/replay policy to iat. A policy refusal of an old but cryptographically valid proof is recorded as a policy result rather than changing JWT expiration semantics. An exact replay of the same message can be detected by caching issuer/nonce pairs, but SMTP retransmission policy is receiver-specific.
7. If sub was disclosed, verify its disclosure digest and require it to be the same canonical identifier used for authoritative issuer resolution. Report an identified result. Otherwise report a hidden-identity issuer property result and do not create a durable identity key from it.

Authentication-Results Integration Authentication-Results: mx.example.com; hw-trust=pass header.mode=identified header.tier=sovereign header.issuer="https://registrar.example/agents" header.aid="urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg" For hidden-identity Mode 2, header.mode=hidden is recorded and header.aid is absent. The method's registered result names and properties are defined in .

Combined Mode A message MAY carry both Hardware-Attestation and Hardware-Trust-Proof, but a verifier MUST reject more than one instance of either field. Combined mode is meaningful only when the verifier establishes that the two artifacts concern the same message and the same Mode-1 signing key. When a Registrar-backed AIRS identity is claimed, that key is the enrolled operational proof key identified by the Registrar assertion. The Mode-1 h list MUST include Hardware-Trust-Proof so the CMS signature covers the complete SD-JWT presentation, including the sender's disclosure selection. The Combined-mode SD-JWT MUST contain the non-selective cnf.jwk required by ; the verifier MUST require it to equal the CMS signer public key. If Mode 1 carries aid, Mode 2 MUST also disclose sub and the two canonical identifiers MUST be equal. Combined mode is not automatically independent defense in depth. If Mode 1 is Registrar-bound and Mode 2 is issued by the same Registrar, a compromise of that Registrar affects both assertions. Independence exists only for properties established by a genuinely independent manufacturer- rooted Mode-1 path.

Interaction with Existing Email Authentication The mechanisms in this document complement rather than replace existing email authentication.

SPF

Authenticates sending infrastructure authorization for a domain; orthogonal to AIRS actor attestation.

DKIM

Authenticates a domain's signature. A DKIM signer that receives an already-attested message SHOULD include Hardware-Attestation and Hardware-Trust-Proof in its h= coverage so removal is detectable at the domain layer.

DMARC

Evaluates domain alignment and policy. Incorporating AIRS results into DMARC policy is outside this specification.

ARC

Can preserve a trusted intermediary's Authentication-Results through forwarding. This is particularly useful when a later verifier cannot reproduce the original receipt-time issuer/freshness decision.

S/MIME and OpenPGP/MIME

Protect message content and/or sender credentials at different layers and can coexist with these headers.

Forwarding and Message Modification Changes to a covered header or canonicalized body invalidate the originating attestation just as comparable changes can invalidate DKIM. A forwarder MAY record the original successful verification in Authentication-Results and protect that result with ARC. It MUST NOT construct a new passing AIRS result unless it independently performs the verification defined here.

Human-Readable Display Names A canonical aid is not intended as a mailbox display name. MUAs MAY obtain a handle or other display attribute from a separate naming or credential layer, but long-lived identity/reputation state MUST remain keyed to the canonical identifier when identity continuity is required.

Message Submission Requirements An attestation-aware Message Submission Agent (MSA) provides an early verification point but is not the authority that defines identity0 or hardware tier. An MSA that claims to validate these headers MUST run the same Mode-1 or Mode-2 verification required of a receiver.

Identity and Account Policy If local submission policy restricts which canonical AIRS identities an authenticated account may use, the MSA MUST compare that policy only after the aid has been cryptographically authenticated by Registrar-bound Mode 1 or identified Mode 2. SMTP authentication or an account database MUST NOT substitute for the AIRS issuer-binding checks in this specification. A mismatch MAY be rejected with an appropriate 5.7.x policy response.

Proof-Key Control Successful Mode-1 verification already proves control of the CMS signer key. An MSA MAY additionally bind that verified key or canonical aid to local account policy. Such local policy does not alter the Registry anchor fingerprint or create a new AIRS identity binding.

Messages Without Attestation Whether an account is required to submit either header is local policy. Absence of these headers is not an authentication failure defined by this protocol.

Duplicate Header Rejection A submitted message MUST NOT contain more than one instance of either Hardware-Attestation or Hardware-Trust-Proof. An MSA that validates this protocol MUST reject duplicates before adding its own DKIM signature.

Freshness at Submission An MSA SHOULD apply a strict local freshness policy to Mode-1 ts and Mode-2 iat because submission occurs close to proof generation. This check is local policy and does not change the JWT exp semantics defined by .

Interoperability Considerations

Backward Compatibility This specification introduces new email headers that are ignored by mail servers that do not implement it. Messages carrying Hardware-Attestation or Hardware-Trust-Proof headers are fully compatible with legacy mail infrastructure: the headers are simply unrecognized and have no effect on delivery. This ensures that deployment can proceed incrementally without disrupting existing email flows.

DKIM Coverage of Attestation Headers Because the sending agent adds the Hardware-Attestation and Hardware-Trust-Proof headers before submitting the message to the MSA, DKIM signing (which occurs at the MSA or a downstream MTA) naturally occurs after these headers are present. The DKIM signer SHOULD include Hardware-Attestation and Hardware-Trust-Proof in the DKIM-Signature h= tag so that the DKIM signature protects the attestation evidence against modification in transit. This allows a verifier to confirm that the domain owner's mail infrastructure accepted the attestation header as submitted by the agent.

Relationship to DKIM and DKIM2 Tag Syntax The two header fields defined here deliberately reuse the tag-spec layout of Section 3.2, which also carries forward. An implementation can therefore share one tokenizer across DKIM-Signature, DKIM2 header fields, and these fields: split on ";", split each tag on the first "=", and trim surrounding folding whitespace. Three differences from a generic DKIM tag-list are intentional and have to be honored:

• Tag order is fixed by rather than free, because the Mode-1 signature is computed over a reconstruction of the field in that order.
• No extension tags are defined, and an unrecognized tag is a malformed field rather than something to ignore. A DKIM verifier may ignore tags it does not know because DKIM signs a canonicalized copy of the field with the b= value blanked; here an unknown tag would change a signed input the verifier cannot reproduce.
• Internal whitespace is ignored in every tag value, not only in the base64 values (generators fold only within the multi-character h, bh, ts, chain, aid, and bind values). DKIM states that rule only for b= and bh=, and its h= grammar permits folding whitespace only around the ":" separators. In practice, deployed signers fold h= in mid-token, so this specification permits folding at any point in a value and requires verifiers to strip it.

A trailing semicolon after the final tag is accepted but not required. DKIM2 has moved toward requiring one on its own header fields; accepting both forms here keeps a shared generator usable without constraining which convention a deployment follows.

Header Size Considerations The base64-encoded CMS SignedData in Mode 1 can be several kilobytes when manufacturer evidence includes certificate chains. Implementations MUST honor the line-length requirements of and MUST use the DKIM-style whitespace semantics defined by and when folding any value in these fields. Deployments that impose aggregate header-size limits need to account for the CMS object and, in Registrar-bound mode, the binding JWS. This specification does not set a deployment-specific minimum header budget.

Implementation Status NOTE TO RFC EDITOR: Please remove this section before publication. This section records the status of known implementations of this specification and follows the guidance of .

1id.com Registrar and Sender Implementation Organization: 1id.com (https://1id.com) The 1id.com implementation supports both Mode 1 (Direct Hardware Attestation) and Mode 2 (SD-JWT Trust Proof), including authoritative AIRS currentIssuer resolution, RFC 8414 issuer metadata and JWKS discovery, Registrar binding JWSs that bind the canonical aid to the exact Mode-1 proof key, detached CMS verification over the 72-octet attestation-input, per-message SD-JWT issuance, and Combined mode. Supported AIRS mechanism mappings include TPM, PIV/YubiKey, hardware enclave, virtual TPM, and software-managed proof keys. On Windows, enrollment and signing run without administrative privileges. Every tier, including the declared tier, obtains tokens by a challenge signature from its enrolled key; the Registrar no longer accepts a static client secret. Every access token is sender-constrained to that key, and the 1id.com and MailPal.com APIs accept a token only with an HTTP Message Signature by it. Apple Secure Enclave bindings are enrolled on trust on first use. Maturity: Production deployment at https://1id.com. Published open-source components: the Python SDK "oneid" 3.1.1 on PyPI (), the Node.js SDK "1id" 3.1.1 on npm (), the code-signed hardware enrollment helper "oneid-enroll" 2.2.0 (), and the draft/test-vector repository ().

MailPal.com Verifier and Relay Organization: 1id.com (https://mailpal.com) MailPal.com implements receiving-side verification of Mode 1 and Mode 2, including AIRS identity/issuer binding checks and Authentication-Results generation. All five AIRS trust tiers are exercised by the live messages in . Maturity: Production mail infrastructure and verifier deployment at https://mailpal.com. The open-source verification library and command-line tool is , published to PyPI as hw-attest-verify. Version 2.0.2 implements this document: both Mode 1 trust paths, identified and hidden-identity Mode 2, Combined mode, and the pass, fail, policy, temperror, and permerror results. It rejects an RDAP answer whose canonical identifier differs from the one requested or whose identity is not operational, and it quotes property values that are not MIME tokens. It resolves aid values through the configured interim RDAP base https://airs.1id.biz permitted by , because the aid.urn.arpa delegation does not yet exist.

IANA Considerations

Message Header Fields IANA is requested to add the following entries to the "Permanent Message Header Field Names" registry:

Header Field Name	Template	Protocol	Status	Trace	Reference
Hardware-Attestation		mail	experimental	no
Hardware-Trust-Proof		mail	experimental	no

Email Authentication Methods and Properties IANA is requested to register the following entries in the "Email Authentication Methods" registry of . Each entry has Status active and Version 1.

Method	Definition	ptype	Property	Value	Status	Version
hw-attest		header	typ	TPM / PIV / ENC / VRT / SFT	active	1
hw-attest		header	alg	RS256 / ES256 / PS256	active	1
hw-attest		header	tier	verified Registrar-asserted AIRS tier	active	1
hw-attest		header	aid	verified canonical AIRS identifier	active	1
hw-trust		header	mode	identified / hidden	active	1
hw-trust		header	tier	disclosed AIRS tier	active	1
hw-trust		header	issuer	verified issuer URI	active	1
hw-trust		header	aid	verified canonical AIRS identifier, if disclosed	active	1

Email Authentication Result Names IANA is requested to register the following entries in the "Email Authentication Result Names" registry:

Auth Method(s)	Code	Specification	Status
hw-attest	pass		active
hw-attest	fail		active
hw-attest	none		active
hw-attest	temperror		active
hw-attest	permerror		active
hw-attest	policy		active
hw-trust	pass		active
hw-trust	fail		active
hw-trust	none		active
hw-trust	temperror		active
hw-trust	permerror		active
hw-trust	policy		active

For both methods, pass means the required cryptographic checks and receiver trust/freshness policy succeeded; fail means a required cryptographic, message-binding, chain, or identity-binding check failed; none means the corresponding header field was absent; temperror means verification could not complete because of a transient external error; permerror means the field was malformed, unsupported, or otherwise permanently unverifiable; and policy means the cryptographic proof was valid but receiver policy declined it, for example because a proof was too old or an issuer/root was not locally trusted.

Media Types for Explicit JWT Typing To prevent cross-JWT confusion, IANA is requested to register the following media types in the Standards Tree according to . The shortened subtype values are used in the JWS typ protected header as specified above.

application/airs-email-binding+jwt

Type name

application

Subtype name

airs-email-binding+jwt

Required parameters

none

Optional parameters

none

Encoding considerations

binary; encoded as a compact JWT using base64url components separated by period characters.

Security considerations

See , , and .

Interoperability considerations

none

Published specification

This document, .

Applications that use this media type

Registrar binding assertions for AIRS Email Mode 1.

Fragment identifier considerations

none

Additional information

Magic number(s): none; File extension(s): none; Macintosh file type code(s): none.

Person & email address to contact for further information

Christopher Drake, cnd@1id.com

Intended usage

COMMON

Restrictions on usage

none

Author

Christopher Drake

Change controller

IETF

application/airs-email+sd-jwt

Type name

application

Subtype name

airs-email+sd-jwt

Required parameters

none

Optional parameters

none

Encoding considerations

binary; encoded as an SD-JWT according to .

Security considerations

See , , and .

Interoperability considerations

none

Published specification

This document, .

Applications that use this media type

AIRS Email Mode-2 selective trust proofs.

Fragment identifier considerations

none

Additional information

Magic number(s): none; File extension(s): none; Macintosh file type code(s): none.

Person & email address to contact for further information

Christopher Drake, cnd@1id.com

Intended usage

COMMON

Restrictions on usage

none

Author

Christopher Drake

Change controller

IETF

No Separate Hardware-Type, DNS, or URN Registration The Mode-1 typ values are fixed application mappings to the Registry specification and this document does not create a second extensible hardware taxonomy. Registrar keys are discovered through authoritative AIRS resolution and RFC 8414 rather than an underscored DNS node. The aid URN namespace is registered solely by . No additional IANA action is requested for those items by this document.

Security Considerations

Message Binding and Replay Both modes bind selected headers, the canonicalized body, and a sender time value into a cryptographic proof. An artifact copied to different content therefore fails. Replaying the exact same message does not forge different content; receivers may use Message-ID, issuer/nonce caches, and normal SMTP duplicate handling as local replay policy.

Signing-Purpose Separation A Mode-1 proof key signs a 72-octet attestation-input that has no internal structure, and the same operational key is typically also used for binding-proof authentication to its Registrar. An implementation MUST NOT use a Mode-1 proof key to sign caller-chosen data for any other purpose unless that data is domain-separated from attestation-input, for example by a fixed purpose-label prefix. Otherwise a signature obtained in another protocol could be presented as a Mode-1 signature over a message the key holder never sent.

Identity Substitution Merely placing an aid inside a header that the sender signs proves only that the sender chose those bytes. It does not prove that the signing key is enrolled to that AIRS identity. Mode 1 therefore forbids aid without a verified Registrar binding JWS, and identified Mode 2 requires authoritative resolution of currentIssuer. Verifiers MUST NOT skip those binding steps.

Registrar Trust Boundary A Registrar-backed tier assertion is trusted because the Registrar has performed the enrollment checks defined by the Registry specification. The RP normally does not redo manufacturer enrollment evidence. A malicious or compromised Registrar can therefore make false assertions for identities it currently sponsors; accreditation, audit, jurisdiction, and receiver-local issuer policy are meaningful trust decisions, not ceremonial metadata. Authoritative issuer resolution limits that power to the current Registrar for the disclosed identity. A valid signature from some other Registrar does not authorize it to speak for that aid. After suspension or de-accreditation, an identity with no currentIssuer fails Registrar-backed email verification until actor-authorized transfer establishes a new current Registrar.

Manufacturer and Attestation Root Trust Manufacturer-rooted Mode 1 depends on the verifier's accepted root and evidence policy. Orderly root retirement and emergency security distrust have different consequences in AIRS; see . Direct verifiers apply their current accepted-root policy and MUST NOT interpret an old or compromised manufacturer chain as current hardware assurance merely because the CMS message signature is mathematically valid.

Binding and Key Compromise Hardware binding does not prevent a compromised agent from sending bad mail as itself. It limits key extraction/cloning according to the properties of the enrolled mechanism and preserves attribution to the key that acted. A compromised Mode-1 signing key can produce valid signatures. In the Registrar-bound profile, that remains true until its AIRS binding is disabled or other policy rejects it. Registrar binding JWSs are therefore time-bounded with exp and MUST be refreshed. A binding disabled or distrusted before an already issued JWS expires can leave a residual acceptance window; deployments that require rapid invalidation MUST use suitably short binding-JWS lifetimes and current issuer/trust policy. Mode 2 issuance MUST authenticate a currently valid, assurance-qualified binding before asserting its tier.

Combined-Mode Dependence Two signatures are not automatically two independent trust anchors. Registrar-bound Mode 1 and Mode 2 may both depend on the same Registrar, so compromise of that Registrar can affect both. A manufacturer-rooted Mode-1 path can add independent evidence when it authenticates the same operational proof key and Combined mode enforces .

Endpoint Compromise Malware controlling an authorized agent can ask its protected key to sign malicious content without extracting that key. This protocol does not attest the model, operating system, browser, container, prompt, operator intent, or message truthfulness. Trust tier and successful verification MUST NOT be treated as authorization or reputation.

Header Stripping and Forwarding An intermediary can remove these headers, causing loss of the signal rather than creation of a false passing result. DKIM coverage and ARC can make removal or prior verification visible, subject to the normal trust assumptions of those mechanisms.

Authentication-Results Trust Boundary The Authentication-Results examples in this document report a verifier's outcome; they are not self-authenticating evidence. Consumers MUST apply the trust-boundary rules of and MUST NOT trust an Authentication-Results field merely because an external sender supplied it. A receiving ADMD should remove or otherwise neutralize conflicting untrusted Authentication-Results fields according to RFC 8601 before adding its own result.

Cryptographic Agility Version 1 uses SHA-256 with RS256, PS256, or ES256 for Mode 1 and the algorithms permitted by the Registrar's authenticated JWK Set for the JWS and SD-JWT signatures. Algorithm deprecation is independent of identity0 continuity. A future incompatible change to the Mode-1 hash/signature construction requires a new protocol version.

Privacy Considerations The Problem Statement distinguishes autonomous agents from natural persons while recognizing that machine identifiers can expose information about human operators or customers. This application therefore separates durable identity disclosure from property disclosure.

Mode-1 Linkability Mode 1 necessarily exposes the operational proof public key through the CMS signer certificate. Reuse of that key makes messages linkable by its SPKI fingerprint. Registrar-bound Mode 1 additionally exposes the canonical aid, deliberately enabling durable actor continuity. Manufacturer-rooted evidence may reveal manufacturer or device-family information. None of those values should be mistaken for human identity.

Mode-2 Selective Disclosure Standalone hidden-identity Mode 2 omits the canonical aid and cnf, so the email proof contains no sender-selected persistent AIRS identity or proof key. The issuer URI, message-bound nonce, issuance time, and disclosed properties remain visible and can themselves be correlating signals. Identified Mode 2 intentionally discloses the canonical aid and is therefore linkable by design. Combined mode exposes cnf.jwk to bind Mode 2 to the Mode-1 signing key, so it remains key-linkable even if sub is withheld. The sender chooses which optional SD-JWT disclosures to reveal. Their values are issuer-authenticated, but this revision does not claim that the disclosure selection is message-bound except in Combined mode, where the Mode-1 signature covers the complete Hardware-Trust-Proof field.

Registrar Observation Mode 2 requires a per-message issuance interaction, so the Registrar can observe that the actor requested a proof and when. The nonce is a hash-derived message binding, not plaintext message content, but traffic analysis can still reveal patterns. Registrars SHOULD minimize retained request metadata and follow their published privacy and legal-retention policy. This document does not invent a separate central behavior log.

Data Minimization Receivers SHOULD retain only the identity or property information needed for their decision. A canonical aid, proof-key fingerprint, or manufacturer evidence can become a durable correlator and SHOULD NOT be logged merely because the protocol made it available.

Human-Related Information An agent may act for one or more people or organizations. The AIRS identity identifies the independently accountable actor, not each human principal it serves. Privacy partitioning SHOULD use Mode 2 selective disclosure, application aliases, or other higher-layer credentials rather than minting multiple identity0s for the same actor. Separate AIRS identities are appropriate only when the underlying actors are themselves independently accountable according to the Problem Statement.

Normative References 1id.com 1id.com University of Cambridge Informative References 1id.com

Live Email Examples This appendix contains five complete email messages, one per trust tier. Each was produced on 25 September 2026 with the published reference implementation of this specification (the "oneid" 3.1.1 Python SDK and the "oneid-enroll" 2.2.0 hardware helper, running without administrative privileges), submitted through the MailPal.com submission service, verified and stamped by the receiving MailPal.com verifier (the hw-attest and hw-trust Authentication-Results fields), and copied from the receiving message store. The messages are shown wrapped with the single-backslash strategy of : a line that ends in "\" continues on the next line, and that line's leading spaces are not part of the content. Unwrapping restores the received messages exactly, except that TAB characters in the folding whitespace of the Received and DKIM-Signature fields are shown as spaces, as requires. Neither field is covered by these signatures, and the header canonicalization of this document treats TAB and SP alike. Re-folding the messages for width would not have been safe: Mode 1 covers the Hardware-Trust-Proof field with DKIM2 header canonicalization, which keeps any whitespace present in a covered field as a single SP, and it covers the body with "simple" canonicalization. To verify an example, save it (starting with its "NOTE:" line), unwrap it with the "rfcfold" script from Appendix A of , and run the open-source verifier (, installed with "pip install hw-attest-verify", version 2.0.2 or later): Each example yields the same hw-attest=pass and hw-trust=pass results as the Authentication-Results fields it carries. No trust store is needed: every example carries "aid" and "bind", so Mode 1 is verified on the Registrar-bound path (), and every example discloses "sub", so Mode 2 is identified. The verifier resolves each "aid" at the AIRS Registry and fetches the Registrar's metadata and JWK Set (); it therefore needs network access, and an example verifies only while its identity has a current issuer. The --no-time-check option skips the freshness and expiry checks, because each SD-JWT and each Registrar binding JWS expires five minutes after issuance; the cryptographic and message-binding checks do not depend on time. Note on certificate chains: each Mode 1 SignedData carries the certificate that the 1id.com Registrar issued for the enrolled proof key, together with the Registrar's intermediate and root ("1ID Intermediate CA A", "1ID Root CA A"). On the Registrar-bound path that chain only conveys the proof key; its authority comes from the binding JWS, whose "cnf.jwk" must equal the CMS signer key. A manufacturer-rooted deployment would instead carry the hardware manufacturer's chain (). Note on folding: the sender folded the Hardware-Attestation and Hardware-Trust-Proof fields at about 78 characters, inside tag values and inside the SD-JWT, rather than only at the ";" separators. That is legal because verifiers remove all such whitespace before interpreting either value (, , ). Verifiers that unfold only per RFC 5322, or that allow folding only at separators, will fail these examples. NOTE TO RFC EDITOR: Please retain the examples but remove this note. They are a non-normative aid to implementers and reviewers: complete, independently verifiable messages demonstrating every trust tier in Combined Mode.

Example 1: Sovereign-Tier TPM (Combined Mode) The sovereign tier: identity urn:aid:global:id-qrmwm-kvdnv-mrwrp-wsmbt, which holds the handle "crusty", sending as crusty@mailpal.com from a Windows 10 host with an Intel firmware TPM (PTT). Mode 1 is an RS256 signature made inside the TPM by the enrolled proof key, and its Registrar binding asserts the sovereign tier; Mode 2 is the Registrar's ES256 SD-JWT, disclosing aid.trust_tier and sub, with "cnf.jwk" equal to the TPM key. The From address is a handle mailbox, independent of the canonical identifier.

Example 1: Sovereign-Tier TPM (Combined Mode) DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=mailpal.com; \ c=relaxed/relaxed; r=y; h=MIME-Version:Content-Transfer-Encoding:Content-Type:Message-ID:Da\ te :Subject:To:From:Reply-To:Cc:In-Reply-To:References:List-Id :List-Unsubscribe:Organization:User-Agent:Thread-Topic:Thread-Index; t=1790332382; x=1791196382; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu+4A\ RfiAp7Y= ; b=lzrLjh64r3nxHJCi6SQdkCHrGVprgxqJiZhE9NF5JMdm7ohUnVBnWjjV3Hw70X3\ NyoCy5jc eXXbY1wD7PtOqSaaGxAd/juxrKgipUT8k+MF7gcrSp7mIoXbciIOqL1+BkJKDy5TRmz\ 4IXb1TG8 NlAT1TN8CnC/f+lW78zv4qKnmEbqJE8aLjchALNUuxXKiPvvrE3DLIY4gsYrNgoUzxQ\ QdD5aZLr kR9d7/ynzt0r6UXBhErFykXBE8vHd40txlB+N8IbnaDqZb4GLygCBKjrKV1/shebgcH\ 6Kpx1lI5 3hM8vfuQ4u2Yu3OgIVM6Nnmpk3Kzhv1oX0l7OPLRX10SvQ==; Authentication-Results: mailpal.com; hw-attest=pass header.typ=TPM \ header.alg=RS256 header.tier=sovereign header.aid="urn:aid:global:id\ -qrmwm-kvdnv-mrwrp-wsmbt" Authentication-Results: mailpal.com; hw-trust=pass \ header.mode=identified header.tier=sovereign \ header.issuer="https://1id.com/realms/agents" \ header.aid="urn:aid:global:id-qrmwm-kvdnv-mrwrp-wsmbt" From: Crusty To: crusty@mailpal.com Subject: Example 1: sovereign-tier TPM (Combined Mode) Date: Fri, 25 Sep 2026 20:32:57 +1000 Message-ID: <179033237729.40392.1543183189803932123@mailpal.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC\ 1lczI1Ni0x IiwidHlwIjoiYWlycy1lbWFpbCtzZC1qd3QifQ.eyJpc3MiOiJodHRwczovLzFpZC5j\ b20vcmVhbG 1zL2FnZW50cyIsImlhdCI6MTc5MDMzMjM4MywiZXhwIjoxNzkwMzMyNjgzLCJub25jZ\ SI6ImFLUHZ VODgwQ0hHd2Z3NTJMbFFBSHlSY3Z0Rnd1UTlzUmRZeUxBY3daZWsiLCJfc2RfYWxnIj\ oic2hhLTI1 NiIsIl9zZCI6WyJUWXpjbWlLUkFJemVIZ1dkU0c5dlp4NUc5b1RYWEhnelhLNzl3ZGE\ xUFZJIiwiW FZEc3BnbS1WSVZ0dVVESzdtZFQtSGlmT2RuMElyR21sVkVDR2FPRWpfQSJdLCJjbmYi\ OnsiandrIj p7Imt0eSI6IlJTQSIsIm4iOiIyX0t4Y0x3Z3RLZUVaeXFEcnAxWXBaQXVuMms0bG1hU\ HJKTnNnSU5 VdkowSEJ6VXNZUkFCYmNFSjU3cGRUOEd6U2YzVzVFNGtKRERlT0NzSXlJRlE2OUxveU\ 9qSF93MVBX QjluMndOQVpWYzNtQkRTMzBmNnYyOFE4bnRndjJPRmlhWEZaQ241OUxxLUZrMnVZZnV\ EaGZBUXI0U 3hzeXh6d2ZSbTdFb0F6Vkx1bjNqanNiMGc1azZRVXdyZmRuRUlKalRRTVdiRE5lNzky\ UVlWLTQ1cE pZemx4ck5iUC1UR282MXlsUHZjQUtZbkZEb3RUZkxNSHBYQnRfQUphYnFTVkEwcXgzV\ npzVlBtRmZ sbGkwU29OZDRpa2daYkpDbjFOQ0ExdFFnOTRrSlk3YXNNdWFIUmxmQ3BkSGpJR29wND\ FhRlNPdHlk OUNBMS11TW52TUhUUHciLCJlIjoiQVFBQiJ9fX0.TwRmOBPLqlNzrjzm1es6E4xQ6hJ\ rnEfjJ4-0D 6uAiWiQ_f7jOIh5e-p7Pf8EuAKvosJUmPM26jCnlzC6msrUxA~WyIyUlNQZjdBZGVFe\ EkwZDd5T2p fQ0hRIiwiYWlkIix7InRydXN0X3RpZXIiOiJzb3ZlcmVpZ24ifV0~WyIzcDFPQU1pem\ RVLTFfQzl3 M3RoSlRBIiwic3ViIiwidXJuOmFpZDpnbG9iYWw6aWQtcXJtd20ta3ZkbnYtbXJ3cnA\ td3NtYnQiX Q~ X-1ID-Contact-Token: 3683058f Hardware-Attestation: v=1; typ=TPM; alg=RS256; h=from:to:subject:date:message-id:reply-to:mime-version:content-typ\ e: content-transfer-encoding:hardware-trust-proof:from:to:subject:date: message-id:reply-to:mime-version:content-type:content-transfer-enco\ ding: hardware-trust-proof; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu-4ARfiAp7Y; ts=1790332388; chain=MIIMJwYJKoZIhvcNAQcCoIIMGDCCDBQCAQExDTALBglghkgBZQMEAgEwCwYJK\ oZIhvcNAQc BoIIKfjCCBAkwggLxoAMCAQICFGHucgAAxQ4WtPCLwcS0zAg+x2naMA0GCSqGSIb3DQ\ EBCwUAMC4x DDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMB4XDTI\ 2MDkyNTEwM zEyOFoXDTI3MDkyNTEwMzEyOFowZzEMMAoGA1UECgwDMUlEMTIwMAYDVQQDDCl1cm46\ YWlkOmdsb2 JhbDppZC1xcm13bS1rdmRudi1tcndycC13c21idDEjMCEGA1UEBRMaaWQtcXJtd20ta\ 3ZkbnYtbXJ 3cnAtd3NtYnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDb8rFwvCC0p4\ RnKoOunVil kC6faTiWZo+sk2yAg1S8nQcHNSxhEAFtwQnnul1PwbNJ/dbkTiQkMN44KwjIgVDr0uj\ I6Mf/DU9YH 2fbA0BlVzeYENLfR/q/bxDye2C/Y4WJpcVkKfn0ur4WTa5h+4OF8BCvhLGzLHPB9Gbs\ SgDNUu6feO OxvSDmTpBTCt92cQgmNNAxZsM17v3ZBhX7jmkljOXGs1s/5MajrXKU+9wApicUOi1N8\ swelcG38Al pupJUDSrHdXOxU+YV+WWLRKg13iKSBlskKfU0IDW1CD3iQljtqwy5odGV8Kl0eMgain\ jVoVI63J30 IDX64ye8wdM/AgMBAAGjgeUwgeIwNAYDVR0RBC0wK4YpdXJuOmFpZDpnbG9iYWw6aWQ\ tcXJtd20ta 3ZkbnYtbXJ3cnAtd3NtYnQwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwHQYD\ VR0OBBYEFG ugv3OTUwMyMwbhTIi+Nl3N1fxBMB8GA1UdIwQYMBaAFGciwHngVXI2J7NEovNM34Bd3\ 5auMBcGCis GAQQBg9RfAQEECXNvdmVyZWlnbjAiBgorBgEEAYPUXwECBBQyMDI2LTA5LTI1VDEwOj\ MxOjI4WjAP BgorBgEEAYPUXwEDBAEAMA0GCSqGSIb3DQEBCwUAA4IBAQCBsY0glRs6+AJFL5t8miD\ hqcpwgAXgc eoczMMMQG/ZrkhcAe0xq238KuCDtM6vnZnoaZyjx/oa2pAVEQjgtr1cGuebC4RTBvGX\ 4F8s/hTSra 3pnFQZPzxtL/U4wiybba21cc5eA/fgZds3ta40jbjLUk4D/3VTg/fllGXPWBt952g0h\ hxsA2fV6Dm FW5TYbcaxb6ciWxecJQlE68I1+bATSeef/mKNJHdp4jn63Mt4VbpueA6HL05Z+SMqgI\ RcsxeAL8YV GkBESXOjBTE6Vayc0OBdU7Hf0ahiYuydC0YF+uy6LKgtbuy0K1TEjB6wqDGXioh8xwr\ emqrzAZ3If 8geMIIDSDCCAjCgAwIBAgIUSEEYK28j6n6Vhr+w4PvDkiuyQbEwDQYJKoZIhvcNAQEL\ BQAwJjEMMA oGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vdCBDQSBBMB4XDTI2MDMxNDE0MTM0N\ 1oXDTMxMDM xMzE0MTM0N1owLjEMMAoGA1UECgwDMUlEMR4wHAYDVQQDDBUxSUQgSW50ZXJtZWRpYX\ RlIENBIEEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC554xsVDRUJ3fMEQISK3ayhz2\ DTFpHDMvhB P6MHqTt/116HDJNj+2qXJdAmVH8GdXzMwm/tt9nrGrx4Sd3vcdodwpUnF2DhVASZ8e2\ TiYYB9a4DL uPc3lOw+lwVOqCQmUDBSneQffINU+87WofNtWZQV28Oxy2HFDfFhU/WkI91ayiI/ihH\ QvQTJpqqZP AbYn+EjD+8AarBbHgKsyyDxW8oOmws82nYhn8eRdz7O3De2w9cpZouJMyWLxG9nwUSO\ xD3fc1+vbc MeoRmBLRADx9RmhrHOiB2HFW579bsqdkzwQ10/SM5/SXmhSdwajxU/mnkGZCE/vcndt\ UzJ5B/twjA gMBAAGjZjBkMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud\ DgQWBBRnIs B54FVyNiezRKLzTN+AXd+WrjAfBgNVHSMEGDAWgBTDt+lZdcVf+UYPLzmblKpM+SXw8\ DANBgkqhki G9w0BAQsFAAOCAQEAhUDFmVN+vZ4SK1CQPPH9XGzkJ+09iAhUkC3lLNK+hWMpBZ+S2H\ s8KVl4aMaZ mD2+jOrC4Wj5Oe+rVsJ7yWiJmfQ9fCyMR43GAoCcAZyDsq9pyyfIfXbQO6+dPU0TffL\ +9HgY2qme8 XN/vsOqWY3gEvxihrW9inVc16EeDv1iRLcWUZe5o3uS7tZTdS6/bkSb1lu81t9nK8YZ\ 62jxNY2SB9 acX9qx9MWNjBSsX7yTjHEAVn/Q6OMzdjS/Sal1/RcATxrzjo8bn22feqeikJCaoq4lO\ K/kKBZfz9F 0BGNVH95AjChp25bliGYQXMzPbiQuUnm6zqMdIYJg/NtPzg6kujCCAyEwggIJoAMCAQ\ ICFGciMXFD NUuITsmdETPo+lhP0nQPMA0GCSqGSIb3DQEBCwUAMCYxDDAKBgNVBAoMAzFJRDEWMBQ\ GA1UEAwwNM UlEIFJvb3QgQ0EgQTAgFw0yNjAzMTQxNDEzNDdaGA8yMDU2MDMwNjE0MTM0N1owJjEM\ MAoGA1UECg wDMUlEMRYwFAYDVQQDDA0xSUQgUm9vdCBDQSBBMIIBIjANBgkqhkiG9w0BAQEFAAOCA\ Q8AMIIBCgK CAQEA4CSklrJ5JJwqpHQkSbH6LoQZp7kXquhEmyoZBED9/BkyzDsld4o3IyFdxvafrD\ u4e5YDzGIx jHgCvCvwUgbEZt6femOqSM91VPKMuBzMEq0rtHCz7J/vS/nsfw3/NqgFN+j+q1HyHHV\ x+L3W8wQPW rVLqI2RUFPyU9oeZL6XKaaL0PNIwL2NxAKMuc5uQ/BUPNjDsh7I4M5gD6X9WR/4ZEnv\ Ud0slil8fJ PLRjw6om2eq/kFl5pXW7mipdf2ufiYEIc1lEBtf34krCWM3PEvnl0Rs4eEirDirxx7P\ FP18GOgoNy aQ8NNZZSOqC6LMrWdoXO6v8MKQVcCcInRsTfdPQIDAQABo0UwQzASBgNVHRMBAf8ECD\ AGAQH/AgEB MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUw7fpWXXFX/lGDy85m5SqTPkl8PAwDQY\ JKoZIhvcNA QELBQADggEBAAhRXzslG92koaKTfGR2KPZvOP3sxZvHBemfwb4tICwaegZlNtHztqP7\ qcLqWfsHG0 Caob8e2rbjMjpPaMY81328kgl7goVPTEuq3Af5joZOArHfizgQl9r5RwT9G3y/AgDTn\ ZDF6uUKt5P 1u8PUd8t6dUANvIjMvqD6eV8ERioMu+BL7GpbDvy7smvmsCpy1isY0aSlh112LGboJu\ eGSbiMx35w MKr6ofXy0EE+Iz2JxPX1+rPzxZ9YI5iYcUEVptBZW0Ik83sLXJdVG6Z745awnOAQnkr\ iRwt2b0r/J Rbmu7TQrzAv/K0PTXTuYf3DYxqCl04w8cpgEaPd5rWG4yYxggFvMIIBawIBATBGMC4x\ DDAKBgNVBA oMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBAhRh7nIAAMUOFrTwi\ 8HEtMwIPsd p2jALBglghkgBZQMEAgEwDQYJKoZIhvcNAQELBQAEggEAZGYLJIEr4SZlCQ1CgjvSjo\ rBGY+z5OKP Pyp1h7FSUhNv+SO3LRnkmTbBlO11TuuljZAtDjOQ/W3rUKpe7rcMMtoHKADsfj/47NN\ H9tkY2LUDi /5Df+vOD+i8JtMeuxpm116PqbpwzbEJaXXinmw/DW3vNckA32sNAOI8/XCnrQI/Bk4H\ XCNKwRfhkv f0MdvJk9s9f9ABc/Am0JK0ohDV/m9OnxBWkusaA2TbT43LdOpgepOJhpLnI2T/DcWAp\ Bdhjf04mJO iugQT5byFVZ7B3LHy4T2kPinkEKxe/3/pLs5wKdFUH4EYAVU2UfPB8dMIPKKIGMgZxg\ VSUR/u+SW3 Ag==; aid=urn:aid:global:id-qrmwm-kvdnv-mrwrp-wsmbt; bind=eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lczI1Ni0xIiwidH\ lwIjoiYWly cy1lbWFpbC1iaW5kaW5nK2p3dCJ9.eyJpc3MiOiJodHRwczovLzFpZC5jb20vcmVhbG\ 1zL2FnZW50 cyIsInN1YiI6InVybjphaWQ6Z2xvYmFsOmlkLXFybXdtLWt2ZG52LW1yd3JwLXdzbWJ\ 0IiwiaWF0I joxNzkwMzMyMzcyLCJleHAiOjE3OTAzMzI2NzIsImNuZiI6eyJqd2siOnsia3R5Ijoi\ UlNBIiwibi I6IjJfS3hjTHdndEtlRVp5cURycDFZcFpBdW4yazRsbWFQckpOc2dJTlV2SjBIQnpVc\ 1lSQUJiY0V KNTdwZFQ4R3pTZjNXNUU0a0pERGVPQ3NJeUlGUTY5TG95T2pIX3cxUFdCOW4yd05BWl\ ZjM21CRFMz MGY2djI4UThudGd2Mk9GaWFYRlpDbjU5THEtRmsydVlmdURoZkFRcjRTeHN5eHp3ZlJ\ tN0VvQXpWT HVuM2pqc2IwZzVrNlFVd3JmZG5FSUpqVFFNV2JETmU3OTJRWVYtNDVwSll6bHhyTmJQ\ LVRHbzYxeW xQdmNBS1luRkRvdFRmTE1IcFhCdF9BSmFicVNWQTBxeDNWenNWUG1GZmxsaTBTb05kN\ GlrZ1piSkN uMU5DQTF0UWc5NGtKWTdhc011YUhSbGZDcGRIaklHb3A0MWFGU090eWQ5Q0ExLXVNbn\ ZNSFRQdyIs ImUiOiJBUUFCIn19LCJhaWQiOnsidHJ1c3RfdGllciI6InNvdmVyZWlnbiJ9fQ.uA5p\ VSO9LKhDg8 eP1OX6ErvwNYrflAmRL0pNdw-hvqWpHPEHg7xvF0081Ashv4DBPnjIsK1rvH2uTkO9i\ Ge6lA This message carries both Hardware-Attestation (Mode 1) and Hardware-Trust-Proof (Mode 2) headers in Combined mode. ]]>

Example 2: Portable-Tier PIV/YubiKey (Combined Mode) The portable tier: a YubiKey 4 (firmware 4.3.7) PIV key in slot 9a (ECDSA P-256) on the same Windows host. Mode 1 is an ES256 signature made inside the YubiKey; Mode 2 discloses aid.trust_tier "portable".

Example 2: Portable-Tier PIV/YubiKey (Combined Mode) DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=mailpal.com; \ c=relaxed/relaxed; r=y; h=MIME-Version:Content-Transfer-Encoding:Content-Type:Message-ID:Da\ te :Subject:To:From:Reply-To:Cc:In-Reply-To:References:List-Id :List-Unsubscribe:Organization:User-Agent:Thread-Topic:Thread-Index; t=1790332537; x=1791196537; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu+4A\ RfiAp7Y= ; b=SCsTBBzwVsZNB1Wf6p+lxrzJIksJkThYvqSVjBJOms0+8eKw/4O9zzzKP191fdI\ C6bSnbp5 n98zLcDKDixS4zqD7tveHhWyzSUwa8B8GbANYJ/FbbaxIfhA994TrDxXz7Z+uv5K+b6\ nisfaiXu NpwteLOuxF+KNoUjs0YmCucJFOW9zSkBW6zgKgOY2MZ2gGMKbKg2lSTqs5ZbX6t2oN3\ Bmw5P/Ba O420fjy19gtzJqLLB2ZES34jEtFY+gk2l3jKWqhQcgfmeRvO7HgbDO/Y4r2rVGvvY/e\ ALUzZC38 cbHm64LEyWhwbwJZLjERdfTkEU6o9ffMhehyv+CsWOPszw==; Authentication-Results: mailpal.com; hw-attest=pass header.typ=PIV \ header.alg=ES256 header.tier=portable header.aid="urn:aid:global:id-\ vfpmt-zhdqr-wcjjn-dgvgp" Authentication-Results: mailpal.com; hw-trust=pass \ header.mode=identified header.tier=portable header.issuer="https://1\ id.com/realms/agents" header.aid="urn:aid:global:id-vfpmt-zhdqr-wcjj\ n-dgvgp" From: Portable Example Agent To: id-vfpmt-zhdqr-wcjjn-dgvgp@mailpal.com Subject: Example 2: portable-tier PIV/YubiKey (Combined Mode) Date: Fri, 25 Sep 2026 20:35:41 +1000 Message-ID: <179033254163.35972.7311316344952954132@mailpal.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC\ 1lczI1Ni0x IiwidHlwIjoiYWlycy1lbWFpbCtzZC1qd3QifQ.eyJpc3MiOiJodHRwczovLzFpZC5j\ b20vcmVhbG 1zL2FnZW50cyIsImlhdCI6MTc5MDMzMjU0MywiZXhwIjoxNzkwMzMyODQzLCJub25jZ\ SI6IlV6Ty1 UZDhMX1JjSnBvQVhUT1cyYnljNTRleFZoS19iU002YjNKTGtuakEiLCJfc2RfYWxnIj\ oic2hhLTI1 NiIsIl9zZCI6WyJ2ZmZCUl9LMkl6ZThMZ2N6c0xNdXFwRDA3aUVURm03UWZHWWhabnd\ YZ2xBIiwiW jU3bk9Ic0tGc2JYSUNfOGxpbXhLT1AzdU1uNERueXFBYXFEVEl0MFhsayJdLCJjbmYi\ OnsiandrIj p7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoicWF1SEZIcGJrOXpQQnFlZndTS\ kQyZGlVZ0t JTHhBTEZqeWRSUFVFUmIzRSIsInkiOiJNT214dXBHQ205Nk5HVU45QmN6c1ZoSE5IUG\ l3eWNWZHFf MjAzdHl6Y2tZIn19fQ.e8cABsbgc9qOviMyW1xtxA--k8wskisQkkpJWRl8UzVOUuae\ BQukfCRqkZ cdd0a85rk3Ox3iRUi8nV_FGTHoWw~WyJXZnhwelQydlBhWWtzOUJkd1BQOVZBIiwiYW\ lkIix7InRy dXN0X3RpZXIiOiJwb3J0YWJsZSJ9XQ~WyJFbFdXWUdJYkhlUGdFV3JGYnktY2F3Iiwi\ c3ViIiwidX JuOmFpZDpnbG9iYWw6aWQtdmZwbXQtemhkcXItd2Nqam4tZGd2Z3AiXQ~ X-1ID-Contact-Token: 9f659fd1 Hardware-Attestation: v=1; typ=PIV; alg=ES256; h=from:to:subject:date:message-id:reply-to:mime-version:content-typ\ e: content-transfer-encoding:hardware-trust-proof:from:to:subject:date: message-id:reply-to:mime-version:content-type:content-transfer-enco\ ding: hardware-trust-proof; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu-4ARfiAp7Y; ts=1790332545; chain=MIIKmgYJKoZIhvcNAQcCoIIKizCCCocCAQExDTALBglghkgBZQMEAgEwCwYJK\ oZIhvcNAQc BoIIJsjCCAz0wggIloAMCAQICFD03lziKa0zu0PG/nVkzJc9UbJ5FMA0GCSqGSIb3DQ\ EBCwUAMC4x DDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMB4XDTI\ 2MDkyNTEwM zMzMFoXDTI3MDkyNTEwMzMzMFowZzEMMAoGA1UECgwDMUlEMTIwMAYDVQQDDCl1cm46\ YWlkOmdsb2 JhbDppZC12ZnBtdC16aGRxci13Y2pqbi1kZ3ZncDEjMCEGA1UEBRMaaWQtdmZwbXQte\ mhkcXItd2N qam4tZGd2Z3AwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASpq4cUeluT3M8Gp5/BIk\ PZ2JSAogvE AsWPJ1E9QRFvcTDpsbqRgpvejRlDfQXM7FYRzRz4sMnFXav9tN7cs3JGo4HkMIHhMDQ\ GA1UdEQQtM CuGKXVybjphaWQ6Z2xvYmFsOmlkLXZmcG10LXpoZHFyLXdjampuLWRndmdwMAwGA1Ud\ EwEB/wQCMA AwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBSRPDDvtDmE5kxL4c8lHXlkikG5ETAfB\ gNVHSMEGDA WgBRnIsB54FVyNiezRKLzTN+AXd+WrjAWBgorBgEEAYPUXwEBBAhwb3J0YWJsZTAiBg\ orBgEEAYPU XwECBBQyMDI2LTA5LTI1VDEwOjMzOjMwWjAPBgorBgEEAYPUXwEDBAEAMA0GCSqGSIb\ 3DQEBCwUAA 4IBAQAyDGtc7c1YY+AdzUfRsFsFDA/W7aA8kK3GfLSadwUscOLEvAHke+TY8hx2/QmH\ hts6Ajlshl 3By17rmGJ1fnbJCvxQQEuijupLc2sot68qXSQYA/gEGloffW8kNtjIMSHBYAnGKLAcJ\ 7V+1FSgTvw 9eSlC1c+TSzWPHyjkULGc9anBz1PKiRTc54gqNCEKdgNCI1MRc49LSFHAV4ud6cC0A/\ NR+Pz94ssP tIx9LynQuJ+GWps606y1+ao+WKeNOIYI93BQ17+OFYtd7bup+bM9Gt7HNLom3E2lbtj\ ee2ADaoagy fLxj+HWRYae6JjsUtJkMhzX81HJ1oji+8Nm6VgSMIIDSDCCAjCgAwIBAgIUSEEYK28j\ 6n6Vhr+w4P vDkiuyQbEwDQYJKoZIhvcNAQELBQAwJjEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xS\ UQgUm9vdCB DQSBBMB4XDTI2MDMxNDE0MTM0N1oXDTMxMDMxMzE0MTM0N1owLjEMMAoGA1UECgwDMU\ lEMR4wHAYD VQQDDBUxSUQgSW50ZXJtZWRpYXRlIENBIEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwA\ wggEKAoIBA QC554xsVDRUJ3fMEQISK3ayhz2DTFpHDMvhBP6MHqTt/116HDJNj+2qXJdAmVH8GdXz\ Mwm/tt9nrG rx4Sd3vcdodwpUnF2DhVASZ8e2TiYYB9a4DLuPc3lOw+lwVOqCQmUDBSneQffINU+87\ WofNtWZQV2 8Oxy2HFDfFhU/WkI91ayiI/ihHQvQTJpqqZPAbYn+EjD+8AarBbHgKsyyDxW8oOmws8\ 2nYhn8eRdz 7O3De2w9cpZouJMyWLxG9nwUSOxD3fc1+vbcMeoRmBLRADx9RmhrHOiB2HFW579bsqd\ kzwQ10/SM5 /SXmhSdwajxU/mnkGZCE/vcndtUzJ5B/twjAgMBAAGjZjBkMBIGA1UdEwEB/wQIMAYB\ Af8CAQAwDg YDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRnIsB54FVyNiezRKLzTN+AXd+WrjAfBgNVH\ SMEGDAWgBT Dt+lZdcVf+UYPLzmblKpM+SXw8DANBgkqhkiG9w0BAQsFAAOCAQEAhUDFmVN+vZ4SK1\ CQPPH9XGzk J+09iAhUkC3lLNK+hWMpBZ+S2Hs8KVl4aMaZmD2+jOrC4Wj5Oe+rVsJ7yWiJmfQ9fCy\ MR43GAoCcA ZyDsq9pyyfIfXbQO6+dPU0TffL+9HgY2qme8XN/vsOqWY3gEvxihrW9inVc16EeDv1i\ RLcWUZe5o3 uS7tZTdS6/bkSb1lu81t9nK8YZ62jxNY2SB9acX9qx9MWNjBSsX7yTjHEAVn/Q6OMzd\ jS/Sal1/Rc ATxrzjo8bn22feqeikJCaoq4lOK/kKBZfz9F0BGNVH95AjChp25bliGYQXMzPbiQuUn\ m6zqMdIYJg /NtPzg6kujCCAyEwggIJoAMCAQICFGciMXFDNUuITsmdETPo+lhP0nQPMA0GCSqGSIb\ 3DQEBCwUAM CYxDDAKBgNVBAoMAzFJRDEWMBQGA1UEAwwNMUlEIFJvb3QgQ0EgQTAgFw0yNjAzMTQx\ NDEzNDdaGA 8yMDU2MDMwNjE0MTM0N1owJjEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vd\ CBDQSBBMII BIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4CSklrJ5JJwqpHQkSbH6LoQZp7\ kXquhEmyoZ BED9/BkyzDsld4o3IyFdxvafrDu4e5YDzGIxjHgCvCvwUgbEZt6femOqSM91VPKMuBz\ MEq0rtHCz7 J/vS/nsfw3/NqgFN+j+q1HyHHVx+L3W8wQPWrVLqI2RUFPyU9oeZL6XKaaL0PNIwL2N\ xAKMuc5uQ/ BUPNjDsh7I4M5gD6X9WR/4ZEnvUd0slil8fJPLRjw6om2eq/kFl5pXW7mipdf2ufiYE\ Ic1lEBtf34 krCWM3PEvnl0Rs4eEirDirxx7PFP18GOgoNyaQ8NNZZSOqC6LMrWdoXO6v8MKQVcCcI\ nRsTfdPQID AQABo0UwQzASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4\ EFgQUw7fpW XXFX/lGDy85m5SqTPkl8PAwDQYJKoZIhvcNAQELBQADggEBAAhRXzslG92koaKTfGR2\ KPZvOP3sxZ vHBemfwb4tICwaegZlNtHztqP7qcLqWfsHG0Caob8e2rbjMjpPaMY81328kgl7goVPT\ Euq3Af5joZ OArHfizgQl9r5RwT9G3y/AgDTnZDF6uUKt5P1u8PUd8t6dUANvIjMvqD6eV8ERioMu+\ BL7GpbDvy7 smvmsCpy1isY0aSlh112LGboJueGSbiMx35wMKr6ofXy0EE+Iz2JxPX1+rPzxZ9YI5i\ YcUEVptBZW 0Ik83sLXJdVG6Z745awnOAQnkriRwt2b0r/JRbmu7TQrzAv/K0PTXTuYf3DYxqCl04w\ 8cpgEaPd5r WG4yYxga8wgawCAQEwRjAuMQwwCgYDVQQKDAMxSUQxHjAcBgNVBAMMFTFJRCBJbnRlc\ m1lZGlhdGU gQ0EgQQIUPTeXOIprTO7Q8b+dWTMlz1RsnkUwCwYJYIZIAWUDBAIBMAoGCCqGSM49BA\ MCBEYwRAIg CSFm/gu6LA8rO7Rn4tDXnyCsOSQmdNxW4fVlvnMhht0CIBebCAkjeQyG4YlTTKxW4TM\ W2m9qm85p5 SIhvey1Ze+4; aid=urn:aid:global:id-vfpmt-zhdqr-wcjjn-dgvgp; bind=eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lczI1Ni0xIiwidH\ lwIjoiYWly cy1lbWFpbC1iaW5kaW5nK2p3dCJ9.eyJpc3MiOiJodHRwczovLzFpZC5jb20vcmVhbG\ 1zL2FnZW50 cyIsInN1YiI6InVybjphaWQ6Z2xvYmFsOmlkLXZmcG10LXpoZHFyLXdjampuLWRndmd\ wIiwiaWF0I joxNzkwMzMyNTMyLCJleHAiOjE3OTAzMzI4MzIsImNuZiI6eyJqd2siOnsia3R5Ijoi\ RUMiLCJjcn YiOiJQLTI1NiIsIngiOiJxYXVIRkhwYms5elBCcWVmd1NKRDJkaVVnS0lMeEFMRmp5Z\ FJQVUVSYjN FIiwieSI6Ik1PbXh1cEdDbTk2TkdVTjlCY3pzVmhITkhQaXd5Y1ZkcV8yMDN0eXpja1\ kifX0sImFp ZCI6eyJ0cnVzdF90aWVyIjoicG9ydGFibGUifX0.afBm47SCBb5G8ZH9zdeTWKsmUTg\ 9W2XtXN2hJ _n8DFX--696tOKwoN0v-S3vb29qFkEI1rMjVhgQPelXyiUsxQ This message carries both Hardware-Attestation (Mode 1) and Hardware-Trust-Proof (Mode 2) headers in Combined mode. ]]>

Example 3: Enclave-Tier Apple Secure Enclave (Combined Mode) The enclave tier: a non-extractable P-256 key in the Apple Secure Enclave of an Apple M4 Mac running macOS 26. Mode 1 is an ES256 signature made inside the Secure Enclave; Mode 2 discloses aid.trust_tier "enclave". The Registrar accepted this binding on trust on first use, without vendor attestation, so to a Relying Party the enclave tier here records the enrollee's assertion of enclave custody rather than verified extraction resistance (see the enclave tier of ).

Example 3: Enclave-Tier Apple Secure Enclave (Combined Mode) DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=mailpal.com; \ c=relaxed/relaxed; r=y; h=MIME-Version:Content-Transfer-Encoding:Content-Type:Message-ID:Da\ te :Subject:To:From:Reply-To:Cc:In-Reply-To:References:List-Id :List-Unsubscribe:Organization:User-Agent:Thread-Topic:Thread-Index; t=1790332636; x=1791196636; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu+4A\ RfiAp7Y= ; b=E6ORZ073eN88rw2sIPYWtgcL6CpFfApjfPjJ9cRpcCVtFd+Bk0nf9zE+HyCDNIN\ /ncH29Vd Itm2fupqXjgUC3FCsX6hVeQtCfXmzM7ptPMu30i0JgRezKf8HwnjvSkfosULoTFWx4V\ t/PQ/Ha6 AaqNFMoPSgg5TyhxnrXBjPtovqqgRTip/iAk2ves6mhKOyZlkzY5IVEg/bxyzCy67vl\ 6fIwPoE7 shqCJEr+z2DfpmakTIG2BTT14/SMjzOxLCpz4grS3eOAlbYJSVB+72DtuKkM3kwcvUX\ Uh0wTsM6 pTTfAFV8jRL23jEs6RZ9q9TBRXQFww2S9cJ1ptafAboJXg==; Authentication-Results: mailpal.com; hw-attest=pass header.typ=ENC \ header.alg=ES256 header.tier=enclave header.aid="urn:aid:global:id-x\ zrhx-pdfnx-gjckq-jxpxs" Authentication-Results: mailpal.com; hw-trust=pass \ header.mode=identified header.tier=enclave header.issuer="https://1i\ d.com/realms/agents" header.aid="urn:aid:global:id-xzrhx-pdfnx-gjckq\ -jxpxs" From: Enclave Example Agent To: id-xzrhx-pdfnx-gjckq-jxpxs@mailpal.com Subject: Example 3: enclave-tier Apple Secure Enclave (Combined Mode) Date: Fri, 25 Sep 2026 20:37:10 +1000 Message-ID: <179033263069.12984.972377609632101516@mailpal.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC\ 1lczI1Ni0x IiwidHlwIjoiYWlycy1lbWFpbCtzZC1qd3QifQ.eyJpc3MiOiJodHRwczovLzFpZC5j\ b20vcmVhbG 1zL2FnZW50cyIsImlhdCI6MTc5MDMzMjYzMiwiZXhwIjoxNzkwMzMyOTMyLCJub25jZ\ SI6IjNNU01 uT1JKUmZfeEpmaUsxNVdzV3N0WWs5dGRLMGF2M1l0OFc5Z2VNQk0iLCJfc2RfYWxnIj\ oic2hhLTI1 NiIsIl9zZCI6WyJMeVIxV2hjQ2c3SDljSHkzcWoyNHFVYjI0bE5abTZRa21RbGxBblB\ BLXRzIiwia Ho1MkJtdzJFTkhzYzJmcnhkVHVNcDA1U1pWOVI5d0hLcFJPUk9nZG0xcyJdLCJjbmYi\ OnsiandrIj p7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoicjBjM2NBOFNVbGpkX2IzMmxZO\ FdXaWZOMFc 5TW9zZmhWSkczRkdiQnBhcyIsInkiOiJDYTNKdTBPXzluTENFdndqb0Vha2IzSElkOU\ h3Z1FKMm9O SU52Z0JhbGk0In19fQ.qCTsp21pNBJTsbpcrQw3qZJglAxhZVgDTGmE_xH7lHlEV7k4\ rlFt8k1YTK 7-PJiGFfmvj4krE4zML6yMYZOCFg~WyI3Rkw3WHptcWxrSWJjYUJZZjM0ZWFRIiwiYW\ lkIix7InRy dXN0X3RpZXIiOiJlbmNsYXZlIn1d~WyJNeXJFaFExMmQ2b0l0UFNnVkFrNjZRIiwic3\ ViIiwidXJu OmFpZDpnbG9iYWw6aWQteHpyaHgtcGRmbngtZ2pja3EtanhweHMiXQ~ X-1ID-Contact-Token: 5cd7e6ad Hardware-Attestation: v=1; typ=ENC; alg=ES256; h=from:to:subject:date:message-id:reply-to:mime-version:content-typ\ e: content-transfer-encoding:hardware-trust-proof:from:to:subject:date: message-id:reply-to:mime-version:content-type:content-transfer-enco\ ding: hardware-trust-proof; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu-4ARfiAp7Y; ts=1790332633; chain=MIIKmgYJKoZIhvcNAQcCoIIKizCCCocCAQExDTALBglghkgBZQMEAgEwCwYJK\ oZIhvcNAQc BoIIJsTCCAzwwggIkoAMCAQICFAorx7eNOsu+ty8CgQlXVvYDlpQmMA0GCSqGSIb3DQ\ EBCwUAMC4x DDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMB4XDTI\ 2MDkyNTEwM zY1NVoXDTI3MDkyNTEwMzY1NVowZzEMMAoGA1UECgwDMUlEMTIwMAYDVQQDDCl1cm46\ YWlkOmdsb2 JhbDppZC14enJoeC1wZGZueC1namNrcS1qeHB4czEjMCEGA1UEBRMaaWQteHpyaHgtc\ GRmbngtZ2p ja3EtanhweHMwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASvRzdwDxJSWN39vfaVjx\ ZaJ83Rb0yi x+FUkbcUZsGlqwmtybtDv/ZywhL8I6BGpG9xyHfR8IECdqDSDb4AWpYuo4HjMIHgMDQ\ GA1UdEQQtM CuGKXVybjphaWQ6Z2xvYmFsOmlkLXh6cmh4LXBkZm54LWdqY2txLWp4cHhzMAwGA1Ud\ EwEB/wQCMA AwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBT0twyptisvE06zRR0hOeGAZk6LMTAfB\ gNVHSMEGDA WgBRnIsB54FVyNiezRKLzTN+AXd+WrjAVBgorBgEEAYPUXwEBBAdlbmNsYXZlMCIGCi\ sGAQQBg9Rf AQIEFDIwMjYtMDktMjVUMTA6MzY6NTVaMA8GCisGAQQBg9RfAQMEAQAwDQYJKoZIhvc\ NAQELBQADg gEBAIDLpMs83FsCWF7TOO5Yvge5i9d/pQIc6rYhil6f3NCt2D30wIjFpMBy0PooglYP\ cwHdln2DKZ lOJUdL/JNqhkMErMFLVwVVozU+xneYkNbkKDQel3KDhcTYN7p8+Oxi9KWkp+ubJhltJ\ U1HWEviJbr fQH1On+Q3i4DeAFQ6zitO92MChdiOc19GyNfo26u1tjipKBo36VN8dj7P3PdSLWr6ji\ A+UKXbr+2Y y22XGWFaQLk/zbmnorfDCRe/3ACDsItAbWZUiZ1p7uZmcNeVGr/nKZJSzOcSGYS0CM4\ 70Uy2c89s1 CyfyfnDUTjlAR5hh/ma/dTkE0mdXJRD0mG4UNwwggNIMIICMKADAgECAhRIQRgrbyPq\ fpWGv7Dg+8 OSK7JBsTANBgkqhkiG9w0BAQsFADAmMQwwCgYDVQQKDAMxSUQxFjAUBgNVBAMMDTFJR\ CBSb290IEN BIEEwHhcNMjYwMzE0MTQxMzQ3WhcNMzEwMzEzMTQxMzQ3WjAuMQwwCgYDVQQKDAMxSU\ QxHjAcBgNV BAMMFTFJRCBJbnRlcm1lZGlhdGUgQ0EgQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADC\ CAQoCggEBA LnnjGxUNFQnd8wRAhIrdrKHPYNMWkcMy+EE/owepO3/XXocMk2P7apcl0CZUfwZ1fMz\ Cb+232esav HhJ3e9x2h3ClScXYOFUBJnx7ZOJhgH1rgMu49zeU7D6XBU6oJCZQMFKd5B98g1T7zta\ h821ZlBXbw 7HLYcUN8WFT9aQj3VrKIj+KEdC9BMmmqpk8Btif4SMP7wBqsFseAqzLIPFbyg6bCzza\ diGfx5F3Ps 7cN7bD1ylmi4kzJYvEb2fBRI7EPd9zX69twx6hGYEtEAPH1GaGsc6IHYcVbnv1uyp2T\ PBDXT9Izn9 JeaFJ3BqPFT+aeQZkIT+9yd21TMnkH+3CMCAwEAAaNmMGQwEgYDVR0TAQH/BAgwBgEB\ /wIBADAOBg NVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFGciwHngVXI2J7NEovNM34Bd35auMB8GA1UdI\ wQYMBaAFMO 36Vl1xV/5Rg8vOZuUqkz5JfDwMA0GCSqGSIb3DQEBCwUAA4IBAQCFQMWZU369nhIrUJ\ A88f1cbOQn 7T2ICFSQLeUs0r6FYykFn5LYezwpWXhoxpmYPb6M6sLhaPk576tWwnvJaImZ9D18LIx\ HjcYCgJwBn IOyr2nLJ8h9dtA7r509TRN98v70eBjaqZ7xc3++w6pZjeAS/GKGtb2KdVzXoR4O/WJE\ txZRl7mje5 Lu1lN1Lr9uRJvWW7zW32crxhnraPE1jZIH1pxf2rH0xY2MFKxfvJOMcQBWf9Do4zN2N\ L9JqXX9FwB PGvOOjxufbZ96p6KQkJqiriU4r+QoFl/P0XQEY1Uf3kCMKGnbluWIZhBczM9uJC5Seb\ rOox0hgmD8 20/ODqS6MIIDITCCAgmgAwIBAgIUZyIxcUM1S4hOyZ0RM+j6WE/SdA8wDQYJKoZIhvc\ NAQELBQAwJ jEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vdCBDQSBBMCAXDTI2MDMxNDE0\ MTM0N1oYDz IwNTYwMzA2MTQxMzQ3WjAmMQwwCgYDVQQKDAMxSUQxFjAUBgNVBAMMDTFJRCBSb290I\ ENBIEEwggE iMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgJKSWsnkknCqkdCRJsfouhBmnuR\ eq6ESbKhkE QP38GTLMOyV3ijcjIV3G9p+sO7h7lgPMYjGMeAK8K/BSBsRm3p96Y6pIz3VU8oy4HMw\ SrSu0cLPsn +9L+ex/Df82qAU36P6rUfIcdXH4vdbzBA9atUuojZFQU/JT2h5kvpcppovQ80jAvY3E\ Aoy5zm5D8F Q82MOyHsjgzmAPpf1ZH/hkSe9R3SyWKXx8k8tGPDqibZ6r+QWXmldbuaKl1/a5+JgQh\ zWUQG1/fiS sJYzc8S+eXRGzh4SKsOKvHHs8U/XwY6Cg3JpDw01llI6oLosytZ2hc7q/wwpBVwJwid\ GxN909AgMB AAGjRTBDMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQ\ WBBTDt+lZd cVf+UYPLzmblKpM+SXw8DANBgkqhkiG9w0BAQsFAAOCAQEACFFfOyUb3aShopN8ZHYo\ 9m84/ezFm8 cF6Z/Bvi0gLBp6BmU20fO2o/upwupZ+wcbQJqhvx7atuMyOk9oxjzXfbySCXuChU9MS\ 6rcB/mOhk4 Csd+LOBCX2vlHBP0bfL8CANOdkMXq5Qq3k/W7w9R3y3p1QA28iMy+oPp5XwRGKgy74E\ vsalsO/Luy a+awKnLWKxjRpKWHXXYsZugm54ZJuIzHfnAwqvqh9fLQQT4jPYnE9fX6s/PFn1gjmJh\ xQRWm0FlbQ iTzewtcl1UbpnvjlrCc4BCeSuJHC3ZvSv8lFua7tNCvMC/8rQ9NdO5h/cNjGoKXTjDx\ ymARo93mtY bjJjGBsDCBrQIBATBGMC4xDDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVyb\ WVkaWF0ZSB DQSBBAhQKK8e3jTrLvrcvAoEJV1b2A5aUJjALBglghkgBZQMEAgEwCgYIKoZIzj0EAw\ IERzBFAiEA siQ7gydOnzEhUjiEIWvv6XSCsk/4qwKZwkKy+v5iWWgCIFaMYkihe5vR6YYFcwpTId4\ ASyJsd3ogk cHXkCZkAb9N; aid=urn:aid:global:id-xzrhx-pdfnx-gjckq-jxpxs; bind=eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lczI1Ni0xIiwidH\ lwIjoiYWly cy1lbWFpbC1iaW5kaW5nK2p3dCJ9.eyJpc3MiOiJodHRwczovLzFpZC5jb20vcmVhbG\ 1zL2FnZW50 cyIsInN1YiI6InVybjphaWQ6Z2xvYmFsOmlkLXh6cmh4LXBkZm54LWdqY2txLWp4cHh\ zIiwiaWF0I joxNzkwMzMyNjMyLCJleHAiOjE3OTAzMzI5MzIsImNuZiI6eyJqd2siOnsia3R5Ijoi\ RUMiLCJjcn YiOiJQLTI1NiIsIngiOiJyMGMzY0E4U1VsamRfYjMybFk4V1dpZk4wVzlNb3NmaFZKR\ zNGR2JCcGF zIiwieSI6IkNhM0p1ME9fOW5MQ0V2d2pvRWFrYjNISWQ5SHdnUUoyb05JTnZnQmFsaT\ QifX0sImFp ZCI6eyJ0cnVzdF90aWVyIjoiZW5jbGF2ZSJ9fQ.RkxcHTYU7ZBOKUdTNiQ-KSGue3DT\ l1RcSx9bBT bRxZnRnrF9E2SV3aiST-Dd-BHnO505u0rSz-86KZ9_06vxTA This message carries both Hardware-Attestation (Mode 1) and Hardware-Trust-Proof (Mode 2) headers in Combined mode. ]]>

Example 4: Virtual-Tier vTPM (Combined Mode) The virtual tier: a VMware virtual TPM 2.0 (manufacturer "VMW") in a Windows 11 guest; the Registrar assigns the virtual tier to a hypervisor-provided TPM. Mode 1 is an RS256 signature made inside the vTPM by the enrolled proof key; Mode 2 discloses aid.trust_tier "virtual".

Example 4: Virtual-Tier vTPM (Combined Mode) DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=mailpal.com; \ c=relaxed/relaxed; r=y; h=MIME-Version:Content-Transfer-Encoding:Content-Type:Message-ID:Da\ te :Subject:To:From:Reply-To:Cc:In-Reply-To:References:List-Id :List-Unsubscribe:Organization:User-Agent:Thread-Topic:Thread-Index; t=1790333168; x=1791197168; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu+4A\ RfiAp7Y= ; b=ar9plN1wc/lZ1qjf76vYPIGYujtEJh8KmKNeWIsgVAOnZaRdYSYiK8TqdNGwDG3\ 2eeJWcWN mytZldcUj0ZKHp0WLopS+4bhg5EaEzjjd7ifgYMif4JKH5hct1RKpMU9DGgAmIHfFUR\ c5Z3HeQu gkvK9DlpmW7Zx4ChoTR2ACBjPdXi2sjU+JCxx33ug90EzXHxClhVUKvYgdugYyFiJm4\ mLVlateJ 90OavmbW79bXwXjuEZtqs1pdRVbtUZ2MUEAwXxlfWYsF+g40GfsRBd5PLTbzzdk4PIA\ P5PvISXl MbwkUa581YztVc3/JMZbovpSKFAdpuNOKUWT1LwXVT9odA==; Authentication-Results: mailpal.com; hw-attest=pass header.typ=VRT \ header.alg=RS256 header.tier=virtual header.aid="urn:aid:global:id-t\ pfkx-qdzts-wmtbm-rnjpc" Authentication-Results: mailpal.com; hw-trust=pass \ header.mode=identified header.tier=virtual header.issuer="https://1i\ d.com/realms/agents" header.aid="urn:aid:global:id-tpfkx-qdzts-wmtbm\ -rnjpc" From: "Example 4 (virtual)" To: id-tpfkx-qdzts-wmtbm-rnjpc@mailpal.com Subject: Example 4: virtual-tier VMware vTPM (Combined Mode) Date: Fri, 25 Sep 2026 20:45:40 +1000 Message-ID: <179033314090.9020.14038067393923310536@mailpal.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC\ 1lczI1Ni0x IiwidHlwIjoiYWlycy1lbWFpbCtzZC1qd3QifQ.eyJpc3MiOiJodHRwczovLzFpZC5j\ b20vcmVhbG 1zL2FnZW50cyIsImlhdCI6MTc5MDMzMzE0NywiZXhwIjoxNzkwMzMzNDQ3LCJub25jZ\ SI6IndBNjB xNWxfYTR2dzZnSXoxeHEyckh1SzJ5aU1HdHhYYzhSWUVfUF81NVEiLCJfc2RfYWxnIj\ oic2hhLTI1 NiIsIl9zZCI6WyJNY3VZZGxxbzdWWExzV3FuMWhUUk9pckpmX01JWGNXcFk1bWR3TnB\ oZVM0Iiwic 0tJVlVkNG5ueXZ1dXdLUENDSzZoYnRhZzFmTVp6cTgtLXd1MVltSFVuTSJdLCJjbmYi\ OnsiandrIj p7Imt0eSI6IlJTQSIsIm4iOiI1cnppMXpkMkgxOVVNRlpOUURnajR3dWdpaGJHZHlkL\ XA5Rm1qYms 0T3RDTHlkMWxPcE5sZXVQMmEzYVJVdUFXMVExUHR2bGVNWWRFX1BfTWVrR2J4MDNHTC\ 1NaElZNURw MkpZenZFLUtSZS1KM19XSE1JR1lnNlN0TklCcU5XU3ZQZFFsdnBUamNKMVVCRmYwMUN\ IandaMk90e mwyMlRmUEstMmE5ckY4aHFBSjZkQUN2QkxnaV9vMzd4VDdrNjlSRnp2WGN2WV9hbDN6\ VzdpN3FWbU FSNmxzclIxUjB1aGpHcng4UUJQOUc3aXdkbTBrWEtaQk13MVVKeFpHcFdsazlHbDdNM\ lMwem9WOUx hMXczT0FZU0VIZnp3NnpzUWllME9WNndONDkyX2dSWE5jTTZndmpkZlBaTklVRHd3Sm\ FxRWl5N1Vx bkZ1WjUzc29Gc2x3TFEiLCJlIjoiQVFBQiJ9fX0.AFJWNgvbI3XGrp-IKbOOXQxxrNx\ BANUmPXF0t x03xnrxZ8U2quh9UB_OIQJXFfXVemIq1b1KLLVOx8J5MOEUxg~WyJBWnE0ZTJsV0pEa\ TEyZms4MWt 6STdRIiwiYWlkIix7InRydXN0X3RpZXIiOiJ2aXJ0dWFsIn1d~WyJNYkJBNC1GN1Q1Z\ Up0cWJkaEd nTE1nIiwic3ViIiwidXJuOmFpZDpnbG9iYWw6aWQtdHBma3gtcWR6dHMtd210Ym0tcm\ 5qcGMiXQ~ X-1ID-Contact-Token: 2b4b74fe Hardware-Attestation: v=1; typ=VRT; alg=RS256; h=from:to:subject:date:message-id:reply-to:mime-version:content-typ\ e: content-transfer-encoding:hardware-trust-proof:from:to:subject:date: message-id:reply-to:mime-version:content-type:content-transfer-enco\ ding: hardware-trust-proof; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu-4ARfiAp7Y; ts=1790333153; chain=MIIMJQYJKoZIhvcNAQcCoIIMFjCCDBICAQExDTALBglghkgBZQMEAgEwCwYJK\ oZIhvcNAQc BoIIKfDCCBAcwggLvoAMCAQICFBYNdCn0+CbgtrqAckXstBZMVmTGMA0GCSqGSIb3DQ\ EBCwUAMC4x DDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMB4XDTI\ 2MDkyNTEwN DQyNFoXDTI3MDkyNTEwNDQyNFowZzEMMAoGA1UECgwDMUlEMTIwMAYDVQQDDCl1cm46\ YWlkOmdsb2 JhbDppZC10cGZreC1xZHp0cy13bXRibS1ybmpwYzEjMCEGA1UEBRMaaWQtdHBma3gtc\ WR6dHMtd21 0Ym0tcm5qcGMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDmvOLXN3YfX1\ QwVk1AOCPj C6CKFsZ3J36n0WaNuTg60IvJ3WU6k2V64/ZrdpFS4BbVDU+2+V4xh0T8/8x6QZvHTcY\ v4yEhjkOnY ljO8T4pF74nf9YcwgZiDpK00gGo1ZK891CW+lONwnVQEV/TUIePBnY63OXbZN88r7Zr\ 2sXyGoAnp0 AK8EuCL+jfvFPuTr1EXO9dy9j9qXfNbuLupWYBHqWytHVHS6GMavHxAE/0buLB2bSRc\ pkEzDVQnFk alaWT0aXszZLTOhX0trXDc4BhIQd/PDrOxCJ7Q5XrA3j3b+BFc1wzqC+N189k0hQPDA\ lqoSLLtSqc W5nneygWyXAtAgMBAAGjgeMwgeAwNAYDVR0RBC0wK4YpdXJuOmFpZDpnbG9iYWw6aWQ\ tdHBma3gtc WR6dHMtd210Ym0tcm5qcGMwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwHQYD\ VR0OBBYEFJ 0whDIaz3zGr6oJX0vTmPJNLqFaMB8GA1UdIwQYMBaAFGciwHngVXI2J7NEovNM34Bd3\ 5auMBUGCis GAQQBg9RfAQEEB3ZpcnR1YWwwIgYKKwYBBAGD1F8BAgQUMjAyNi0wOS0yNVQxMDo0ND\ oyNFowDwYK KwYBBAGD1F8BAwQBADANBgkqhkiG9w0BAQsFAAOCAQEAsR8WUkH+mTzBqhoNgLbkVmK\ bggVF15iJE FnUwFQoZbTzhg1yYIpEjUS4D9MuU9n5quistmCnIankCMQKyKhmDvqbIX/W9NkUHx0r\ KB+yULLUBd BBTFvxWGlxf+kJxHZUujnBiWWGvQhlpRh/ySS8Xx9BI2dh03wYYno0vDBDKVp2Slq5u\ kaD2R/v+aw +1/pPiKOL0RM7eGpWrcb3u2BqoSpleh431aJ4NXGlzmP01A0/0Ki4ozyw3z+VH0uNTQ\ rApRgvXhCw S7Iq+sMgn8SEQcyU+fW06Trx9niwJ1Bnq+G0ijdKdgVfDqwKRwHjF1iSPcMVbUpmRhK\ UTSftfIzOt jCCA0gwggIwoAMCAQICFEhBGCtvI+p+lYa/sOD7w5IrskGxMA0GCSqGSIb3DQEBCwUA\ MCYxDDAKBg NVBAoMAzFJRDEWMBQGA1UEAwwNMUlEIFJvb3QgQ0EgQTAeFw0yNjAzMTQxNDEzNDdaF\ w0zMTAzMTM xNDEzNDdaMC4xDDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZS\ BDQSBBMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAueeMbFQ0VCd3zBECEit2soc9g0x\ aRwzL4QT+j B6k7f9dehwyTY/tqlyXQJlR/BnV8zMJv7bfZ6xq8eEnd73HaHcKVJxdg4VQEmfHtk4m\ GAfWuAy7j3 N5TsPpcFTqgkJlAwUp3kH3yDVPvO1qHzbVmUFdvDscthxQ3xYVP1pCPdWsoiP4oR0L0\ EyaaqmTwG2 J/hIw/vAGqwWx4CrMsg8VvKDpsLPNp2IZ/HkXc+ztw3tsPXKWaLiTMli8RvZ8FEjsQ9\ 33Nfr23DHq EZgS0QA8fUZoaxzogdhxVue/W7KnZM8ENdP0jOf0l5oUncGo8VP5p5BmQhP73J3bVMy\ eQf7cIwIDA QABo2YwZDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E\ FgQUZyLAee BVcjYns0Si80zfgF3flq4wHwYDVR0jBBgwFoAUw7fpWXXFX/lGDy85m5SqTPkl8PAwD\ QYJKoZIhvc NAQELBQADggEBAIVAxZlTfr2eEitQkDzx/Vxs5CftPYgIVJAt5SzSvoVjKQWfkth7PC\ lZeGjGmZg9 vozqwuFo+Tnvq1bCe8loiZn0PXwsjEeNxgKAnAGcg7KvacsnyH120DuvnT1NE33y/vR\ 4GNqpnvFzf 77DqlmN4BL8Yoa1vYp1XNehHg79YkS3FlGXuaN7ku7WU3Uuv25Em9ZbvNbfZyvGGeto\ 8TWNkgfWnF /asfTFjYwUrF+8k4xxAFZ/0OjjM3Y0v0mpdf0XAE8a846PG59tn3qnopCQmqKuJTiv5\ CgWX8/RdAR jVR/eQIwoaduW5YhmEFzMz24kLlJ5us6jHSGCYPzbT84OpLowggMhMIICCaADAgECAh\ RnIjFxQzVL iE7JnREz6PpYT9J0DzANBgkqhkiG9w0BAQsFADAmMQwwCgYDVQQKDAMxSUQxFjAUBgN\ VBAMMDTFJR CBSb290IENBIEEwIBcNMjYwMzE0MTQxMzQ3WhgPMjA1NjAzMDYxNDEzNDdaMCYxDDAK\ BgNVBAoMAz FJRDEWMBQGA1UEAwwNMUlEIFJvb3QgQ0EgQTCCASIwDQYJKoZIhvcNAQEBBQADggEPA\ DCCAQoCggE BAOAkpJayeSScKqR0JEmx+i6EGae5F6roRJsqGQRA/fwZMsw7JXeKNyMhXcb2n6w7uH\ uWA8xiMYx4 Arwr8FIGxGben3pjqkjPdVTyjLgczBKtK7Rws+yf70v57H8N/zaoBTfo/qtR8hx1cfi\ 91vMED1q1S 6iNkVBT8lPaHmS+lymmi9DzSMC9jcQCjLnObkPwVDzYw7IeyODOYA+l/Vkf+GRJ71Hd\ LJYpfHyTy0 Y8OqJtnqv5BZeaV1u5oqXX9rn4mBCHNZRAbX9+JKwljNzxL55dEbOHhIqw4q8cezxT9\ fBjoKDcmkP DTWWUjqguizK1naFzur/DCkFXAnCJ0bE33T0CAwEAAaNFMEMwEgYDVR0TAQH/BAgwBg\ EB/wIBATAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMO36Vl1xV/5Rg8vOZuUqkz5JfDwMA0GCSq\ GSIb3DQEBC wUAA4IBAQAIUV87JRvdpKGik3xkdij2bzj97MWbxwXpn8G+LSAsGnoGZTbR87aj+6nC\ 6ln7BxtAmq G/Htq24zI6T2jGPNd9vJIJe4KFT0xLqtwH+Y6GTgKx34s4EJfa+UcE/Rt8vwIA052Qx\ erlCreT9bv D1HfLenVADbyIzL6g+nlfBEYqDLvgS+xqWw78u7Jr5rAqctYrGNGkpYdddixm6Cbnhk\ m4jMd+cDCq +qH18tBBPiM9icT19fqz88WfWCOYmHFBFabQWVtCJPN7C1yXVRume+OWsJzgEJ5K4kc\ Ldm9K/yUW5 ru00K8wL/ytD0107mH9w2MagpdOMPHKYBGj3ea1huMmMYIBbzCCAWsCAQEwRjAuMQww\ CgYDVQQKDA MxSUQxHjAcBgNVBAMMFTFJRCBJbnRlcm1lZGlhdGUgQ0EgQQIUFg10KfT4JuC2uoByR\ ey0FkxWZMY wCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBCwUABIIBALuVaXyzBZ6/2S3uokiVXGxLbO\ IYCzV0abeA c8V6t/ZXQOp4Vg9Efs/19QXi2RW2Y/gahIdZcu/sRknYiYKlQ+o5SzvmInoEJFF8ve/\ mCQAqcImDV 3D8HUsvsiPc5hDz5peS9Jf9UUy1Cu3PyTP1hayiCEOvgnSNuc4aX33buAB5a/5/Ph7h\ sxQC9q/UyZ KzC+yL6TCIhBQAMy+u+PYXBInSGitrtpKTMc1RKghuwgD6vCbnWsTmN2QxhZqYkk0Ze\ w8kua69HuY UTAHdjRu1zIX1jU9hAl0js6rr8hxKLotGmSNTektV3JbxezdkcxD/TBGTE5wGhkSeog\ W0UqPC1xc=; aid=urn:aid:global:id-tpfkx-qdzts-wmtbm-rnjpc; bind=eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lczI1Ni0xIiwidH\ lwIjoiYWly cy1lbWFpbC1iaW5kaW5nK2p3dCJ9.eyJpc3MiOiJodHRwczovLzFpZC5jb20vcmVhbG\ 1zL2FnZW50 cyIsInN1YiI6InVybjphaWQ6Z2xvYmFsOmlkLXRwZmt4LXFkenRzLXdtdGJtLXJuanB\ jIiwiaWF0I joxNzkwMzMzMTU1LCJleHAiOjE3OTAzMzM0NTUsImNuZiI6eyJqd2siOnsia3R5Ijoi\ UlNBIiwibi I6IjVyemkxemQySDE5VU1GWk5RRGdqNHd1Z2loYkdkeWQtcDlGbWpiazRPdENMeWQxb\ E9wTmxldVA yYTNhUlV1QVcxUTFQdHZsZU1ZZEVfUF9NZWtHYngwM0dMLU1oSVk1RHAySll6dkUtS1\ JlLUozX1dI TUlHWWc2U3ROSUJxTldTdlBkUWx2cFRqY0oxVUJGZjAxQ0hqd1oyT3R6bDIyVGZQSy0\ yYTlyRjhoc UFKNmRBQ3ZCTGdpX28zN3hUN2s2OVJGenZYY3ZZX2FsM3pXN2k3cVZtQVI2bHNyUjFS\ MHVoakdyeD hRQlA5Rzdpd2RtMGtYS1pCTXcxVUp4WkdwV2xrOUdsN00yUzB6b1Y5TGExdzNPQVlTR\ Uhmenc2enN RaWUwT1Y2d040OTJfZ1JYTmNNNmd2amRmUFpOSVVEd3dKYXFFaXk3VXFuRnVaNTNzb0\ ZzbHdMUSIs ImUiOiJBUUFCIn19LCJhaWQiOnsidHJ1c3RfdGllciI6InZpcnR1YWwifX0.HHPeLod\ XEHu2c6jV2 TN0YHUXMRQ1lr2SlRRhYVfV-aTmM8cOvhJmzBN2E5ZfBnl1qADKy18caYEvj4ULQZA0\ pg This message carries both Hardware-Attestation (Mode 1) and Hardware-Trust-Proof (Mode 2) headers in Combined mode. ]]>

Example 5: Declared-Tier Software Key (Combined Mode) The declared tier: a software-held P-256 key (typ=SFT, alg=ES256) with no hardware root. The header structure is identical to the hardware tiers, so verifiers treat it uniformly and simply observe the lower tier.

Example 5: Declared-Tier Software Key (Combined Mode) DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=mailpal.com; \ c=relaxed/relaxed; r=y; h=MIME-Version:Content-Transfer-Encoding:Content-Type:Message-ID:Da\ te :Subject:To:From:Reply-To:Cc:In-Reply-To:References:List-Id :List-Unsubscribe:Organization:User-Agent:Thread-Topic:Thread-Index; t=1790332553; x=1791196553; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu+4A\ RfiAp7Y= ; b=FYM2SQVZls++uUUWmP3+lV2rPeW4E3W0beRO6rSL5vAZAAgyBevn0v11zaTSRox\ 7zZAiwtn A4QzHk7JAPePFSiz2NM+ogYahZT0UZVOrKrgmMwFfV9FACNI2DQhfD9QC0uGNkXhzf5\ isa/qAxm 6Pnu8SXNwH/473g5YWr9aTBqE/k/fjfjooQfRrQc00lKFBFA7QYsbhda0T6TebJYWUO\ Z4n85BOB 4lmQzy0+h4hHXj5g/pM8KfJv9VIukGbIDoc49hwfJPchQm0OXhvmAkkpmhvCrb2CLss\ 3EX1laIE 9Vrh+LZouvpNVZDXxgHnAWNlaclAz/Jk7Qz1oiOO1WGCHQ==; Authentication-Results: mailpal.com; hw-attest=pass header.typ=SFT \ header.alg=ES256 header.tier=declared header.aid="urn:aid:global:id-\ xjmzg-pxqvz-hvswq-qmxsq" Authentication-Results: mailpal.com; hw-trust=pass \ header.mode=identified header.tier=declared header.issuer="https://1\ id.com/realms/agents" header.aid="urn:aid:global:id-xjmzg-pxqvz-hvsw\ q-qmxsq" From: Declared Example Agent To: id-xjmzg-pxqvz-hvswq-qmxsq@mailpal.com Subject: Example 5: declared-tier software key (Combined Mode) Date: Fri, 25 Sep 2026 20:35:58 +1000 Message-ID: <179033255827.28156.1260021529347069427@mailpal.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC\ 1lczI1Ni0x IiwidHlwIjoiYWlycy1lbWFpbCtzZC1qd3QifQ.eyJpc3MiOiJodHRwczovLzFpZC5j\ b20vcmVhbG 1zL2FnZW50cyIsImlhdCI6MTc5MDMzMjU2MCwiZXhwIjoxNzkwMzMyODYwLCJub25jZ\ SI6IkFIYy1 uaHdUcjF1WHlnMVJoaGl3ZjRsSkNwdmNVSXpuTjQxR0FUQjZra28iLCJfc2RfYWxnIj\ oic2hhLTI1 NiIsIl9zZCI6WyJyYUhBc0x3NzBVc0RfNzc1T3BaNF8wSWVoUEFxcjQ1OHp4Znkxc3B\ 5M0NnIiwiQ 0FHeWxTRk1IbTFwT2lVRXNQOE1BQ2ZJSGVEbEJJaTVTb282UXlnNXdtMCJdLCJjbmYi\ OnsiandrIj p7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiT3VLMXJ5Y0FHUzlxOG04enVQU\ U4wVnAzY2J 0UmVHalBrZmtscEFkSWc5MCIsInkiOiJBRzczSDh5SlR4MUNVU195NnBsQ0FNalRpQW\ VLdFZsX0ZR bnJRZmVMdXA4In19fQ.e75kb6b1djDbaMvdN59Qq8nIvk0_Q99Mon-a85l7GwMe_duH\ YjIrXs-TA1 HG9ZbKjJQDcVbK6aO8oJQL8f72xA~WyJoLUMwUFAyR3NnblRnYWZrTlYwSXJBIiwiYW\ lkIix7InRy dXN0X3RpZXIiOiJkZWNsYXJlZCJ9XQ~WyJ2MGRVM1pWTnB4OU9QdXVWdmZQdVRRIiwi\ c3ViIiwidX JuOmFpZDpnbG9iYWw6aWQteGptemctcHhxdnotaHZzd3EtcW14c3EiXQ~ X-1ID-Contact-Token: 472280e7 Hardware-Attestation: v=1; typ=SFT; alg=ES256; h=from:to:subject:date:message-id:reply-to:mime-version:content-typ\ e: content-transfer-encoding:hardware-trust-proof:from:to:subject:date: message-id:reply-to:mime-version:content-type:content-transfer-enco\ ding: hardware-trust-proof; bh=78LCXgUHRREQqBxud8Q026cqbbu5Ykssu-4ARfiAp7Y; ts=1790332561; chain=MIIKmwYJKoZIhvcNAQcCoIIKjDCCCogCAQExDTALBglghkgBZQMEAgEwCwYJK\ oZIhvcNAQc BoIIJsjCCAz0wggIloAMCAQICFDiM2xWglKEtTFsyR7m1j3s9qUpxMA0GCSqGSIb3DQ\ EBCwUAMC4x DDAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMB4XDTI\ 2MDkyNTEwM zUxNloXDTI3MDkyNTEwMzUxNlowZzEMMAoGA1UECgwDMUlEMTIwMAYDVQQDDCl1cm46\ YWlkOmdsb2 JhbDppZC14am16Zy1weHF2ei1odnN3cS1xbXhzcTEjMCEGA1UEBRMaaWQteGptemctc\ HhxdnotaHZ zd3EtcW14c3EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ64rWvJwAZL2rybzO49A\ 3RWndxu1F4 aM+R+SWkB0iD3QBu9x/MiU8dQlEv8uqZQgDI04gHirVZfxUJ60H3i7qfo4HkMIHhMDQ\ GA1UdEQQtM CuGKXVybjphaWQ6Z2xvYmFsOmlkLXhqbXpnLXB4cXZ6LWh2c3dxLXFteHNxMAwGA1Ud\ EwEB/wQCMA AwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBQ5A7CAZrWXTA8Nb5si6Ax8HXdP0zAfB\ gNVHSMEGDA WgBRnIsB54FVyNiezRKLzTN+AXd+WrjAWBgorBgEEAYPUXwEBBAhkZWNsYXJlZDAiBg\ orBgEEAYPU XwECBBQyMDI2LTA5LTI1VDEwOjM1OjE2WjAPBgorBgEEAYPUXwEDBAEAMA0GCSqGSIb\ 3DQEBCwUAA 4IBAQAjLbsCC+d98Yyiyacexv7JBikrgtQs8Vza8P/oogmB9S6q6lv5NOs7CcmxwZMx\ XVxIumMIZy y5C4iFOGk4hwoeb5kim3UtZoHw6RIdRgepATYdW9gdkMOVsyB5gn9WahBx5/cvGuLZb\ zGBCceSZDq rgOiAcIrSvi4pJZyO1+Ibw90HBAhumq5qljbYOSDPmmboS+cUMjdh+2RT/Esp7SD9jv\ 7sKdOsubel 6HONDRAdZSEF3/9FfSmJoObd8ognadcSWWbAtM4uuOdTNknLs7O3YSsO4QvMmE9gg8D\ 5fp2Qj2fOr U8QOt8GZMq/ltiXqEZUD9XyjGVSCqLtwvQvdkJvMIIDSDCCAjCgAwIBAgIUSEEYK28j\ 6n6Vhr+w4P vDkiuyQbEwDQYJKoZIhvcNAQELBQAwJjEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xS\ UQgUm9vdCB DQSBBMB4XDTI2MDMxNDE0MTM0N1oXDTMxMDMxMzE0MTM0N1owLjEMMAoGA1UECgwDMU\ lEMR4wHAYD VQQDDBUxSUQgSW50ZXJtZWRpYXRlIENBIEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwA\ wggEKAoIBA QC554xsVDRUJ3fMEQISK3ayhz2DTFpHDMvhBP6MHqTt/116HDJNj+2qXJdAmVH8GdXz\ Mwm/tt9nrG rx4Sd3vcdodwpUnF2DhVASZ8e2TiYYB9a4DLuPc3lOw+lwVOqCQmUDBSneQffINU+87\ WofNtWZQV2 8Oxy2HFDfFhU/WkI91ayiI/ihHQvQTJpqqZPAbYn+EjD+8AarBbHgKsyyDxW8oOmws8\ 2nYhn8eRdz 7O3De2w9cpZouJMyWLxG9nwUSOxD3fc1+vbcMeoRmBLRADx9RmhrHOiB2HFW579bsqd\ kzwQ10/SM5 /SXmhSdwajxU/mnkGZCE/vcndtUzJ5B/twjAgMBAAGjZjBkMBIGA1UdEwEB/wQIMAYB\ Af8CAQAwDg YDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRnIsB54FVyNiezRKLzTN+AXd+WrjAfBgNVH\ SMEGDAWgBT Dt+lZdcVf+UYPLzmblKpM+SXw8DANBgkqhkiG9w0BAQsFAAOCAQEAhUDFmVN+vZ4SK1\ CQPPH9XGzk J+09iAhUkC3lLNK+hWMpBZ+S2Hs8KVl4aMaZmD2+jOrC4Wj5Oe+rVsJ7yWiJmfQ9fCy\ MR43GAoCcA ZyDsq9pyyfIfXbQO6+dPU0TffL+9HgY2qme8XN/vsOqWY3gEvxihrW9inVc16EeDv1i\ RLcWUZe5o3 uS7tZTdS6/bkSb1lu81t9nK8YZ62jxNY2SB9acX9qx9MWNjBSsX7yTjHEAVn/Q6OMzd\ jS/Sal1/Rc ATxrzjo8bn22feqeikJCaoq4lOK/kKBZfz9F0BGNVH95AjChp25bliGYQXMzPbiQuUn\ m6zqMdIYJg /NtPzg6kujCCAyEwggIJoAMCAQICFGciMXFDNUuITsmdETPo+lhP0nQPMA0GCSqGSIb\ 3DQEBCwUAM CYxDDAKBgNVBAoMAzFJRDEWMBQGA1UEAwwNMUlEIFJvb3QgQ0EgQTAgFw0yNjAzMTQx\ NDEzNDdaGA 8yMDU2MDMwNjE0MTM0N1owJjEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vd\ CBDQSBBMII BIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4CSklrJ5JJwqpHQkSbH6LoQZp7\ kXquhEmyoZ BED9/BkyzDsld4o3IyFdxvafrDu4e5YDzGIxjHgCvCvwUgbEZt6femOqSM91VPKMuBz\ MEq0rtHCz7 J/vS/nsfw3/NqgFN+j+q1HyHHVx+L3W8wQPWrVLqI2RUFPyU9oeZL6XKaaL0PNIwL2N\ xAKMuc5uQ/ BUPNjDsh7I4M5gD6X9WR/4ZEnvUd0slil8fJPLRjw6om2eq/kFl5pXW7mipdf2ufiYE\ Ic1lEBtf34 krCWM3PEvnl0Rs4eEirDirxx7PFP18GOgoNyaQ8NNZZSOqC6LMrWdoXO6v8MKQVcCcI\ nRsTfdPQID AQABo0UwQzASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4\ EFgQUw7fpW XXFX/lGDy85m5SqTPkl8PAwDQYJKoZIhvcNAQELBQADggEBAAhRXzslG92koaKTfGR2\ KPZvOP3sxZ vHBemfwb4tICwaegZlNtHztqP7qcLqWfsHG0Caob8e2rbjMjpPaMY81328kgl7goVPT\ Euq3Af5joZ OArHfizgQl9r5RwT9G3y/AgDTnZDF6uUKt5P1u8PUd8t6dUANvIjMvqD6eV8ERioMu+\ BL7GpbDvy7 smvmsCpy1isY0aSlh112LGboJueGSbiMx35wMKr6ofXy0EE+Iz2JxPX1+rPzxZ9YI5i\ YcUEVptBZW 0Ik83sLXJdVG6Z745awnOAQnkriRwt2b0r/JRbmu7TQrzAv/K0PTXTuYf3DYxqCl04w\ 8cpgEaPd5r WG4yYxgbAwga0CAQEwRjAuMQwwCgYDVQQKDAMxSUQxHjAcBgNVBAMMFTFJRCBJbnRlc\ m1lZGlhdGU gQ0EgQQIUOIzbFaCUoS1MWzJHubWPez2pSnEwCwYJYIZIAWUDBAIBMAoGCCqGSM49BA\ MCBEcwRQIh AKwr4cNk1nbJTR3zd2PpO5yWczMsISsHhxPaiosjj5mwAiATGUSwxwtQkIoJPYnRUcd\ CH3uxaNYip 905/0mwRsECyg==; aid=urn:aid:global:id-xjmzg-pxqvz-hvswq-qmxsq; bind=eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lczI1Ni0xIiwidH\ lwIjoiYWly cy1lbWFpbC1iaW5kaW5nK2p3dCJ9.eyJpc3MiOiJodHRwczovLzFpZC5jb20vcmVhbG\ 1zL2FnZW50 cyIsInN1YiI6InVybjphaWQ6Z2xvYmFsOmlkLXhqbXpnLXB4cXZ6LWh2c3dxLXFteHN\ xIiwiaWF0I joxNzkwMzMyNTQ5LCJleHAiOjE3OTAzMzI4NDksImNuZiI6eyJqd2siOnsia3R5Ijoi\ RUMiLCJjcn YiOiJQLTI1NiIsIngiOiJPdUsxcnljQUdTOXE4bTh6dVBRTjBWcDNjYnRSZUdqUGtma\ 2xwQWRJZzk wIiwieSI6IkFHNzNIOHlKVHgxQ1VTX3k2cGxDQU1qVGlBZUt0VmxfRlFuclFmZUx1cD\ gifX0sImFp ZCI6eyJ0cnVzdF90aWVyIjoiZGVjbGFyZWQifX0.YHbZDCHovYycyU1CfPhNS2K_tp3\ Gkgku_NOYH 2_gn2ezp-Ir1jh0p0Qz9eXJJH5EVO9Q10c2KRnfHSIENUzntg This message carries both Hardware-Attestation (Mode 1) and Hardware-Trust-Proof (Mode 2) headers in Combined mode. ]]>

Verification Failure Examples The following Authentication-Results fields were produced by the verification command above (hw-attest-verify 2.0.2) for modified copies of Example 5, and are folded here at whitespace. Verifiers should give similar diagnostics in the comment. One character of the body changed after sending: the Mode 1 signature no longer matches the recomputed attestation-input, and the recomputed message-binding nonce differs from the one the Registrar signed: The Hardware-Attestation field removed in transit: the SD-JWT carries "cnf", so it is a Combined-mode presentation and is rejected without its Mode 1 partner (): The optional "sub" disclosure withheld from the Hardware-Trust-Proof field: Mode 1 fails because its "h" list covers that field, including the disclosure selection. With "--trust-hidden-issuer https://1id.com/realms/agents" added to the command, Mode 2 is a hidden-identity presentation from a trusted issuer, and it fails together with the Mode 1 proof it depends on ():

Acknowledgments The concept of using hardware attestation for email sender verification was developed in the context of building a hardware identity registrar for autonomous AI agents. The author thanks the Trusted Computing Group for the TPM 2.0 specification, the authors of (SD-JWT) for the selective disclosure mechanism, the authors of (RATS Architecture) for establishing the remote attestation architecture that this document builds upon, and the authors of (URN) for the persistent identifier framework that underpins the federated agent identity model.