Hardware Attestation for Email Sender Verification

1.1. 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.¶

1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.3. Terminology

Foundational identity and AIRS terms are used as defined in [I-D.drake-agent-identity-problem-statement] and [I-D.drake-agent-identity-registry].¶

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.¶

3.1. 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.¶

3.2. 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:¶

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.¶

3.3. Authoritative Registrar Key Discovery

Whenever a presentation discloses a canonical aid, the verifier MUST resolve that identifier using [I-D.drake-agent-identity-resolution] 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 [RFC8414]. 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.¶

4.1. 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 Section 3.3. 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.¶

4.2. 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 [RFC4648]; 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 [RFC6376] 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 Section 3.2. 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 Section 4.3. 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 [RFC6376]. 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 Section 4.4.¶

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 [I-D.ietf-dkim-dkim2-spec] 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 [RFC5652] 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 Section 4.3. 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.¶

4.3. 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.¶

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

4.4. Registrar Binding JWS

A Registrar-bound Mode-1 message carries a compact JWS in bind. Its payload is a JWT [RFC7519] 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 [RFC7800] 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 [RFC7515]. 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 Section 11.4; verifiers MUST reject another type. This explicit profile separation follows the cross-JWT confusion guidance of [RFC8725]. 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 Section 3.3. 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 [RFC8725]; 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 [RFC7638]. The cnf.jwk value MUST NOT contain private key parameters. Finally, aid.trust_tier MUST correspond to typ according to Section 3.2.¶

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.¶

4.5. 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 Section 4.2, 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 Section 4.4. 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.¶

4.6. 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 Section 11. tier and aid are reported only when Registrar binding verification succeeded.¶

5.1. 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.¶

5.2. 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 [RFC6376] and as the Mode-1 tag values of Section 4.2. 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 [RFC9901]. 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 Section 11.4, and another type MUST be rejected. The signing algorithm MUST satisfy [RFC8725] 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 [RFC9901]. 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 [RFC7800] 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.¶

5.3. 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 Section 5.4. 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.¶

5.4. 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 Section 3.3 and verify the SD-JWT signature and disclosures according to [RFC9901]. 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 [RFC7519]; delivery delay does not make an expired JWT valid.¶
5. Recompute the nonce exactly as defined in Section 5.3 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.¶

5.5. 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 Section 11.¶

7.1. 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.¶

7.2. 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.¶

8.1. 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.¶

8.2. 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.¶

8.3. 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.¶

8.4. 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.¶

8.5. 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 [RFC7519].¶

9.1. 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.¶

9.2. 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.¶

9.3. Relationship to DKIM and DKIM2 Tag Syntax

The two header fields defined here deliberately reuse the tag-spec layout of [RFC6376] Section 3.2, which [I-D.ietf-dkim-dkim2-spec] 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 Section 4.2 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.¶

9.4. 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 [RFC5322] and MUST use the DKIM-style whitespace semantics defined by Section 4.2 and Section 5.2 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.¶

11.1. Message Header Fields

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

11.2. Email Authentication Methods and Properties

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

11.3. Email Authentication Result Names

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

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.¶

11.4. 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 [RFC6838]. The shortened subtype values are used in the JWS typ protected header as specified above.¶

11.5. 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 [I-D.drake-agent-identity-registry]. No additional IANA action is requested for those items by this document.¶

12.1. 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.¶

12.2. 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.¶

12.3. 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.¶

12.4. 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.¶

12.5. 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 [I-D.drake-agent-identity-registry]. 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.¶

12.6. 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.¶

12.7. 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 Section 6.¶

12.8. 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.¶

12.9. 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.¶

12.10. 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 [RFC8601] 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.¶

12.11. 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.¶

13.1. 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.¶

13.2. 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.¶

13.3. 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.¶

13.4. 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.¶

13.5. 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.¶

A.1. 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.¶

NOTE: '\' line wrapping per RFC 8792

Delivered-To: crusty@mailpal.com
X-Spam-Status: No
Received: from [172.22.1.89] (unknown [110.143.72.26] (AS1221 \
Telstra Limited, AU))
 (using TLSv1.3 with cipher TLS13_AES_256_GCM_SHA384)
 by mail.mailpal.com (Stalwart SMTP) with ESMTPSA id 49994FE58B134C7;
 Fri, 25 Sep 2026 10:33:01 +0000
Authentication-Results: mail.mailpal.com; none
Return-Path: <id-qrmwm-kvdnv-mrwrp-wsmbt@mailpal.com>
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 <crusty@mailpal.com>
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.

A.2. 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".¶

NOTE: '\' line wrapping per RFC 8792

Delivered-To: id-vfpmt-zhdqr-wcjjn-dgvgp@mailpal.com
X-Spam-Status: No
Received: from [172.22.1.89] (unknown [110.143.72.26] (AS1221 \
Telstra Limited, AU))
 (using TLSv1.3 with cipher TLS13_AES_256_GCM_SHA384)
 by mail.mailpal.com (Stalwart SMTP) with ESMTPSA id 499954A8FF136C7;
 Fri, 25 Sep 2026 10:35:37 +0000
Authentication-Results: mail.mailpal.com; none
Return-Path: <id-vfpmt-zhdqr-wcjjn-dgvgp@mailpal.com>
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 <id-vfpmt-zhdqr-wcjjn-dgvgp@mailpal.com>
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.

A.3. 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 [I-D.drake-agent-identity-registry]).¶

NOTE: '\' line wrapping per RFC 8792

Delivered-To: id-xzrhx-pdfnx-gjckq-jxpxs@mailpal.com
X-Spam-Status: No
Received: from mac-mini.local (unknown [110.143.72.26] (AS1221 \
Telstra Limited, AU))
 (using TLSv1.3 with cipher TLS13_AES_256_GCM_SHA384)
 by mail.mailpal.com (Stalwart SMTP) with ESMTPSA id 499957AD5F13AC7;
 Fri, 25 Sep 2026 10:37:16 +0000
Authentication-Results: mail.mailpal.com; none
Return-Path: <id-xzrhx-pdfnx-gjckq-jxpxs@mailpal.com>
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 <id-xzrhx-pdfnx-gjckq-jxpxs@mailpal.com>
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.

A.4. 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".¶

NOTE: '\' line wrapping per RFC 8792

Delivered-To: id-tpfkx-qdzts-wmtbm-rnjpc@mailpal.com
X-Spam-Status: No
Received: from [172.22.1.83] (unknown [110.143.72.26] (AS1221 \
Telstra Limited, AU))
 (using TLSv1.3 with cipher TLS13_AES_256_GCM_SHA384)
 by mail.mailpal.com (Stalwart SMTP) with ESMTPSA id 499967EA9513CC7;
 Fri, 25 Sep 2026 10:46:08 +0000
Authentication-Results: mail.mailpal.com; none
Return-Path: <id-tpfkx-qdzts-wmtbm-rnjpc@mailpal.com>
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)" <id-tpfkx-qdzts-wmtbm-rnjpc@mailpal.com>
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.

A.5. 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.¶

NOTE: '\' line wrapping per RFC 8792

Delivered-To: id-xjmzg-pxqvz-hvswq-qmxsq@mailpal.com
X-Spam-Status: No
Received: from [172.22.1.89] (unknown [110.143.72.26] (AS1221 \
Telstra Limited, AU))
 (using TLSv1.3 with cipher TLS13_AES_256_GCM_SHA384)
 by mail.mailpal.com (Stalwart SMTP) with ESMTPSA id 49995522E3138C7;
 Fri, 25 Sep 2026 10:35:53 +0000
Authentication-Results: mail.mailpal.com; none
Return-Path: <id-xjmzg-pxqvz-hvswq-qmxsq@mailpal.com>
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 <id-xjmzg-pxqvz-hvswq-qmxsq@mailpal.com>
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.

A.6. 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:¶

Authentication-Results: mailpal.com; hw-attest=fail header.typ=SFT
  header.alg=ES256 (Signature verification failed with the SignerInfo
  signer certificate: Cryptographic signature does not match)
Authentication-Results: mailpal.com; hw-trust=fail
  header.mode=identified header.tier=declared
  header.issuer="https://1id.com/realms/agents"
  header.aid="urn:aid:global:id-xjmzg-pxqvz-hvswq-qmxsq"
  (Message-binding nonce mismatch: got
  'AHc-nhwTr1uXyg1Rhhiwf4lJCpvcUIznN41GATB6kko', expected
  'gpMPDEEeYym4QdJ71JjkdeFMqDdfrzuDyni04sHF7MM')

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 (Section 5.4):¶

Authentication-Results: mailpal.com; hw-trust=fail
  header.mode=identified header.tier=declared
  header.issuer="https://1id.com/realms/agents"
  header.aid="urn:aid:global:id-xjmzg-pxqvz-hvswq-qmxsq" (SD-JWT
  carries cnf Combined mode but the message has no
  Hardware-Attestation field)

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 (Section 6):¶

Authentication-Results: mailpal.com; hw-attest=fail header.typ=SFT
  header.alg=ES256 (Signature verification failed with the SignerInfo
  signer certificate: Cryptographic signature does not match)
Authentication-Results: mailpal.com; hw-trust=fail header.mode=hidden
  header.tier=declared header.issuer="https://1id.com/realms/agents"
  (Combined mode: the Hardware-Attestation proof this presentation
  depends on is fail Signature verification failed with the
  SignerInfo signer certificate: Cryptographic signature does not
  match)