Individual

okutomi+ietf@pm.me

Security Individual Submission agent identity TLS exporter proof of possession remote attestation workload identity This document defines a verifier-side acceptance profile for channel-bound Agent identity and authorization. It addresses context diversion, where cryptographically valid material is accepted for a different service, tenant, actor, task, target, delegation, or authority boundary than the verifier intended. A verifier accepts an actor only when a verified authority grant, holder-of-key proof, accepted channel instance, freshness and replay state, any required attestation result, and verifier-local policy all describe the same intended interaction. Protocol-specific wire formats and deployment choices are left to binding profiles.

Introduction A valid grant and proof of possession can be accepted for the wrong operation. For example, a grant authorizes an Agent to read a task's resource, but the verifier applies it to another target on the same connection. This is context diversion: valid inputs describe a different interaction than the verifier intended. Task and target checks alone do not bind a proof to the receiving TLS connection. If a relay forwards an exporter-bound proof over another connection, the verifier detects the channel mismatch. This document specifies when a verifier may return a scoped accepted assertion. It also defines the grant hash, TLS exporter context, and attestation binder used in that decision. It uses TLS , exported authenticators , and RATS roles without changing their underlying protocols. Binding profiles supply the protocol-specific wire formats.

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

Core profile

The verifier-side acceptance rules defined by this document. The core profile is not a complete wire-binding profile by itself.

Binding profile

A specification that instantiates the core profile for a protocol or deployment by fixing wire representation, canonicalization, exporter-label selection rule, endpoint role, interaction type, replay rules, diagnostic behavior, and other protocol-specific inputs.

Deployment profile

Deployment policy that selects trusted issuers, local expected values, attestation requirements, disclosure policy, operational limits, and accepted binding profiles.

SBAIP

The short identifier for this profile. It is used in domain-separation strings and examples. It is not an external registry name.

Channel instance

One accepted TLS connection or equivalent secure transport instance.

Application session

A logical agent-protocol session that can span multiple channel instances.

Task binding

Security state scoped to one task, invocation, or delegated operation.

Peer endpoint

The endpoint authenticated on the current channel instance.

Actor

The Agent, workload, or runtime exercising authority.

Target

The tool, service, API, resource, operation, or object being invoked or affected.

Agent

An automated software component. When this document discusses acceptance, the more specific terms actor, peer endpoint, target, and intermediary are used where their security roles differ.

Verifier

The party that authenticates the grant, checks the channel binding, evaluates freshness and replay state, and compares the result with local policy before returning an accepted result to the application.

Policy authority

A locally trusted issuer of authority statements.

Authority grant

An authority statement signed by a policy authority or protected with a Message Authentication Code (MAC) under a policy-authority key. It authorizes actor, task, target, and authorization values. It does not prove that the authorized actor is present on the current channel instance.

Session proof

A holder-of-key proof that binds one verified authority grant to one accepted channel instance. It proves possession and channel binding. It does not authorize service, tenant, task, target, scope, resource, or capability values.

Expected value

A verifier-local policy input.

Observed value

A value extracted from authenticated grants, channel-bound statements, attestation results, trusted manifests, or locally derived request state. An observed value does not become an expected value without a trusted local policy decision.

Context diversion

Acceptance of cryptographically valid material for a different service, tenant, actor, task, target, delegation, or authority boundary than the verifier intended. Context diversion is a failure class, not a wire mechanism.

Intermediary

A gateway, broker, proxy, or mediator between an actor and a target.

Scope and Deployment Assumptions This profile addresses context diversion when independently verified mechanisms are combined. It is unnecessary where the application protocol already makes the complete context-specific acceptance decision at the same verifier boundary. Acceptance is scoped to one channel instance and the accepted task binding. Application-session continuity and transport migration are addressed in . This document does not define dialog lifecycle, discovery, an identity provider, or an authorization framework. A binding profile can include an application correlation value in task_context only after defining its authenticated source, scope, parent-child semantics, and comparison rules. The value alone proves neither identity nor authority nor continuity. Discovery identifies candidate endpoints or metadata. It does not establish accepted identity, delegation, task binding, or authorization. If discovery data contributes to expected policy, local policy fixes its trusted source, authentication, namespace, version, and canonicalization. The construction inputs and acceptance rules are normative for implementations claiming this profile. Interoperability requires the binding profile specified in .

Trust Boundaries Open Internet and enterprise deployments need a verifier-local trust path to each accepted authority, including issuers and attestation-result signers. Without that path, acceptance fails closed. No global authority, registry, gateway, online authority, transparency log, or control plane is required. Intermediaries are not trusted by default. A component that terminates transport security is a separate relying party and sees only the disclosed claims and payloads. A verifier MUST NOT treat an intermediary-authenticated endpoint as the final Agent unless a gateway-routed binding profile and local policy authorize that interpretation. Each receiving verifier applies its own trusted-authority set, expected values, binding profile, and acceptance decision. An upstream acceptance or authenticated parent-child relationship does not establish end-to-end trust. For Agents acting for a person or organization, deployment profiles SHOULD support audience-scoped disclosure, short-lived grants, selective disclosure or reference tokens, and person- or organization-selected authorities and disclosure modes where practical. Security-required claims SHOULD be distinguished from application-convenience claims. Deployments need privacy and pervasive-monitoring analysis .

Core Invariant A verifier MUST NOT return a profile-authenticated actor identity or authorization result unless the verified authority grant, holder-of-key proof, accepted channel instance, freshness and replay state, any required attestation result, and verifier-local policy all identify the same intended interaction. The intended interaction is determined by verifier-local expected values and trusted policy inputs, not by peer-provided descriptive metadata. Before this acceptance decision succeeds, all peer-provided identity, task, scope, service, tenant, capability, attestation-related, diagnostic, display-name, and natural-language values are observed values only. They do not define the verifier's expected policy. No inference, alias repair, display-name matching, peer-selected exporter label, prompt interpretation, model interpretation, or reserialized semantic metadata is part of the final acceptance path unless a binding profile and local policy explicitly define it.

Conformance This Informational profile has two conformance subjects: verifiers implementing its acceptance rules with a binding and deployment profile, and binding profiles fixing the wire-visible inputs listed in . Its requirements apply to those subjects, not to implementations of the underlying mechanisms in general. A conformance claim MUST identify the binding profile. The core alone is not a complete wire specification. A verifier MUST fail closed and MUST NOT return profile-authenticated identity or authorization until every applicable check in succeeds. A grant, session proof, endpoint identity, exported authenticator, attestation result, or peer metadata alone is insufficient. For optional features, a binding profile MUST define which checks apply when a feature is absent or required, and the additional negative acceptance cases. It can add stricter checks, but MUST NOT relax the core's fail-closed requirements.

Acceptance Model D0 through D7 are acceptance dimensions for policy separation and diagnostics. The numbering provides a stable order for diagnostics. It does not imply protocol layers, dependencies, or a trust hierarchy. A deployment need not evaluate every dimension.

Dimension	Verification target	Main failure class
D0	Live channel instance and authenticated peer endpoint	MITM or channel confusion
D1	Attested platform validity, when selected	Fake, malformed, stale, or untrusted evidence
D2	Grant, authenticator, or attestation-to-channel binding	Relay, replay, or borrowed evidence
D3	Service, tenant, deployment, or environment	Wrong service or tenant; context diversion
D4	Acting workload, process, or Agent instance	Same-host wrong-actor confusion
D5	Task, invocation, context, or delegation	Wrong task or delegation; context diversion
D6	Tool, target resource, or operation	Wrong-target or wrong-operation diversion
D7	Effective authorization or capability policy	Confused deputy or privilege escalation

D0 through D2 are authentication and binding dimensions. D3 through D7 are verifier-local policy dimensions. Peer-provided metadata can be observed input; it is not expected policy. Remote attestation is optional in this core profile. When neither local policy nor the binding profile selects attestation, D1 and the attestation-specific part of D2 are not evaluated. The remaining channel-binding, freshness, replay, grant, and local-policy checks still apply.

Dimension	Binding-profile requirement
D3	Define the trusted source and canonical form of expected service, tenant, deployment, and environment values.
D4	Define the canonical actor identifier and how it is distinguished from host, peer endpoint, target, intermediary, person, and organization identities.
D5	Define task_context construction, which values are hashed or disclosed, and when a task binding can be reused.
D6	Define target_context construction and canonical target, resource, and operation comparison.
D7	Define capability-set comparison, requested-capability handling, deny overrides, and whether surplus observed capabilities are ignored or rejected.

When a context identifier separates users, tasks, or sessions, the verifier MUST compare an authenticated observed value with a nonempty expected value from trusted local policy or authenticated application state. Missing identifiers MUST fail the comparison; empty values MUST NOT bypass it. The binding profile defines the identifier's scope and canonical comparison.

Accepted Assertion Output On successful verification, the verifier produces one internal accepted assertion with typed accepted sub-results from verified material and local policy. A peer-provided token or relabeled input claim is not an accepted assertion. The binding profile MUST identify the sub-results required for each interaction type. The verifier MUST reject an interaction when a required sub-result is absent. When the verifier consumes an external verification result, the binding profile MUST identify its producer, required prerequisites, and compatible evaluation context. Failed or unresolved required prerequisites, or incompatible policy, profile, interaction, or freshness values, MUST prevent acceptance of any sub-result that depends on it. The assertion MUST contain scope, accepted_profile, accepted_channel, accepted_actor, accepted_authority, accepted_interaction, replay_commit, effective_authorization, and expiry. scope identifies the accepted audience and binding context and applies to every sub-result in the assertion. A sub-result is not independently portable outside that scope. accepted_channel includes the accepted endpoint role and endpoint public-key identifier as well as the channel-instance binding; the endpoint is not thereby accepted as the actor. The assertion MUST contain accepted_delegation and accepted_target when those dimensions are required for the interaction. It contains attestation_result only when attestation was selected by the binding profile or local policy and accepted. Each present sub-result preserves its canonical accepted value. The verifier computes the single assertion expiry as specified in . Source identifiers, source-specific expiry, key identifiers, nonces, replay-store keys, and verifier-basis details can be retained in a separate audit record, but they are not required application fields. Absence means that the verifier did not accept that claim; an application MUST NOT infer an absent claim from another sub-result, raw peer metadata, or a shared identifier. The accepted assertion does not prove action correctness, successful execution, audit completeness, post-execution attribution, or continuity of a long-lived application session. An authenticated intermediary does not by itself prove downstream target identity. Unless creator-isolation evidence was required and accepted, the assertion also does not prove that the actor confirmation key is unavailable to the actor's creator or intermediary. A signed receipt or audit record that merely names an operation does not establish that an authority grant or accepted assertion exists. The verifier still requires the evidence and checks specified by the binding profile. The accepted assertion MAY be represented as an internal data structure, a local handle, or a binding-profile-defined token. Whatever the representation, applications MUST NOT recover profile-authenticated identity or authorization from raw peer-provided claims once the acceptance decision has been made.

Threat Model The attacker can observe, replay, reorder, relay, or substitute messages, supply malicious metadata, and run another Agent on the same host. The attacker can combine individually valid inputs across context boundaries, including borrowed attestation and gateway route assertions. Peer metadata presented as expected policy and acceptance before replay commit are verifier failures within this model. An intermediary can provision a downstream actor while retaining its private key or signing interface. Holder-of-key verification cannot establish creator isolation; the evidence requirements are in . The profile assumes correct TLS 1.3, exported-authenticator validation, signature or MAC verification, and evidence appraisal. A fully compromised verifier, malicious trusted policy authority, compromise of all local secret storage, denial of service, and side channels outside the identity-binding path are out of scope.

Relationship to Existing Mechanisms The following mechanisms supply inputs to acceptance. Their successful validation does not replace the checks in .

Mechanism	Relationship to this profile
Authority introduction	describes authority documents and scoped evidence under relying-party policy. A deployment defines how introduced issuer keys and permitted uses enter local policy; key introduction and historical signatures do not establish current acceptance.
Security principal binding	provides a protocol-neutral claim registry, verifier matrix, and rules for composing verification results. This profile defines acceptance for one channel-bound interaction and does not adopt that registry as its conformance model.
Agent protocol dimensions	describes exchange properties. Its D1 through D7 labels are independent of this profile's acceptance dimensions. Exchange lifecycle, output cadence, state locality, and result addressability remain application-protocol concerns.
WIMSE	Its architecture , credentials , mutual TLS , proof tokens , identifiers , and HTTP signatures can supply workload identity and possession inputs. These references are informative; WIMSE is not required by this core.
ID-JAG and DPoP	A binding profile can use verified ID-JAG for delegated cross-domain authority. Its key binding and DPoP supply possession inputs; they do not replace the session proof or its interaction bindings. Required claim mappings are in .
HTTP Message Signatures	Signs selected HTTP components . A binding profile specifies which signed request material participates in acceptance.
RATS and EAT	Supply evidence appraisal and attestation claims . Accepted evidence or results must bind to the channel and task.

Binding Profile Requirements A binding profile fixes wire representation, canonicalization, and holder-side presentation. It MUST define the following values.

Required item	Prevents
profile identifier and version	cross-profile confusion
protocol_id and application-protocol scope	cross-protocol replay or substitution
accepted endpoint_role, interaction_type, and proof-signer role	endpoint-role and interaction-type confusion
source of leaf_spki for each accepted endpoint role	wrong certificate or authenticator binding
TLS exporter label selection and context construction	peer-selected, request-selected, ad hoc, or colliding channel bindings
canonical aud form and audience-comparison rules	audience confusion
exact bytes used for grant_hash	parse-and-reserialize substitution
authority-grant token type, alg allow-list, and protected-header rules	algorithm, type, and key-use confusion
session-proof encoding and protected-header rules	algorithm, type, and key-use confusion
extension, unknown-field, and critical-field processing rules	unsupported extension acceptance
task_context, target_context, and binding-context construction	wrong-task or wrong-target acceptance
operation identifier, canonical request digest, result-access policy, and distinction between operation retries and authentication attempts, when retry or result recovery is supported	duplicate execution or disclosure of a prior result to an unauthorized caller
verifier_nonce generation, entropy, lifetime, single-use rule, and peer-nonce handling	proof precomputation and replay
attempt_id generation, uniqueness, collision handling, local-state lookup, replay-key construction, and replay-cache consistency requirement	attempt confusion and cross-task reuse
TLS resumption and 0-RTT handling	stale proof reuse and early-data acceptance
attestation requirement, evidence mapping, appraisal source, freshness, audience, and channel-binding rule	borrowed or replayed evidence
confirmation-key-to-evidence binding and creator-isolation claim, when creator isolation is required	creator-accessible downstream key accepted as isolated
verifier-local source and comparison rules for D3 through D7 expected values	peer-selected policy
string encoding, normalization, and comparison rules for non-ASCII decision-sensitive values, when allowed	alias, display-name, and confusable-string confusion
delegated, exchanged, or derived authority-grant constraints, when used	authority expansion across delegation
Human-approval evidence, scope, freshness, and operation binding, when required	actor authentication mistaken for Human approval
intermediary and gateway-route assertion rules, when gateways are used	gateway identity accepted as final-Agent identity
diagnostic error classes and disclosure limits	leakage of attacker-controlled values

A binding profile that uses ID-JAG as its authority-grant input MUST:

• require a cnf claim containing jkt and require the session-proof signer to prove possession of that same key;
• treat client_id as an observed OAuth client identifier and MUST NOT automatically map it to the D4 actor; the profile defines a separate authenticated D4 actor mapping, including processing rules for act when used;
• map resource to observed D6 target input and map scope and authorization_details to observed D7 authorization input, without treating any of those claims as verifier-local expected policy; and
• treat a validated DPoP proof as an inherited proof-of-possession input only and MUST NOT accept it in place of the session proof defined by this document.

A binding profile that requires Human approval MUST define separate evidence and bind it to the operation. Actor-key possession alone does not establish that approval. An accepted association, consent, or standing grant MUST NOT, solely on that basis, be reported as per-operation Human approval. When such approval is optional and absent, the accepted assertion carries no approval claim; the remaining required checks still apply. For example, a specialist at Hospital B can answer a consultation from Hospital A through a gateway acting as the authenticated actor. The response identifies the materials reviewed at version v7. A binding can authenticate the response and protect its reference to v7. If the materials change to v8, the receiving clinical workflow decides whether the response still applies. Acceptance does not itself authorize treatment or transfer clinical responsibility. A binding profile MUST define its extension-processing model. Unknown critical extensions, protected-header parameters, or binding-profile-required fields fail closed. Unknown non-critical fields are ignored or rejected according to the binding profile, but they MUST NOT change the meaning of accepted claims, the replay key, verifier-local expected values, or effective authorization. Ignored fields within a grant remain in its exact-byte hash input, so grant_hash and the binding context can change. A profile-version update that changes any decision-sensitive input, canonicalization rule, exporter-label selection rule, replay-key construction, endpoint-role rule, interaction-type rule, or D3 through D7 comparison rule is a new binding-profile version. Version negotiation is outside this core profile; a verifier accepts only profile versions selected by verifier-local policy. An HTTP binding profile SHOULD reuse the HTTP Message Signatures component model in and Digest Fields in for request-component and content-digest selection, rather than defining a competing HTTP canonicalization scheme. Structured Field Values and Problem Details can be reused for field encoding and error representation. Tokenized attestation claims can use EAT within the RATS model ; this document does not redefine evidence formats, appraisal procedures, or attestation-token validation.

Grant and Authority Material An authority grant states what the actor may do. It is signed by a policy authority or protected with a Message Authentication Code (MAC) under a policy-authority key, and identifies the Agent confirmation key through the confirmation method selected by the binding profile, such as JWT confirmation methods or the corresponding CWT confirmation method . This core profile does not define a new authority grant token format. A grant carries the deployment-specific equivalent of profile type, profile version, issuer, subject, audience, grant identifier, issued-at time, expiration time, and confirmation key. When policy requires it, the grant also carries D3 through D7 fields such as service, tenant, deployment, actor, task, delegation, target, operation, canonical intent or capability references, scopes, resources, and authorization details. The Agent is not the authority for those values. They are accepted only after grant verification, channel binding, freshness checks, replay checks, and local policy comparison. Multi-audience grants are rejected unless local policy explicitly allows the exact audience set and the resulting authority boundary. When a binding profile supports delegated, exchanged, or derived authority grants, it MUST define how the parent authority is identified, verified, and used to constrain the derived grant. A derived grant MUST NOT expand the effective D3 through D7 authority beyond the parent grant and verifier-local policy. Deployment profiles that issue such grants SHOULD enforce the same no-expansion rule at issuance time; this core profile enforces it at the verifier boundary. Task transfer or a new session name does not remove inherited authority conditions. A derived grant MUST retain those conditions. Replacing them requires separate authorization, verified under local policy, from an authority permitted to make that change; it is not a continuation under the old grant. A verifier MUST NOT accept possession of an upstream actor's long-term private credential as evidence that a downstream actor has delegated authority. When accepting a derived grant, the verifier MUST verify that it identifies the downstream confirmation key and constrains the audience and all D3 through D7 values required by local policy. Possession of a parent task reference or application correlation value is not evidence of delegation. If local policy requires the downstream confirmation key to be unavailable to its creator or intermediary, a key identifier and holder-of-key proof are insufficient. The verifier MUST require accepted evidence or an attestation result that binds the key-protection property to the downstream actor key and accepted channel instance. Without that evidence, the accepted assertion MUST NOT claim creator isolation. If a grant authorizes endpoint-key signing, it MUST say which endpoint role and key use are authorized or rely on verifier-local policy that does so. A generic statement that the endpoint was authenticated by TLS is not sufficient to authorize endpoint-key signing for the session proof.

Authority and Key Separation The TLS endpoint key authenticates the accepted TLS or exported-authenticator endpoint. With leaf_spki and the exporter, it contributes to D0 and D2; it does not alone establish the actor or D3 through D7 policy. The Agent binding key signs the session proof and supports D4 only when the verified grant or local policy maps it to a canonical actor. The policy-authority key authenticates grants and supplies observed policy values, without proving live-channel possession. Policy-authority signing keys MUST NOT be accepted as Agent confirmation keys. Agent confirmation keys MUST NOT be accepted as policy-authority signing keys. Endpoint-key use requires explicit authorization by the verified grant or local policy and a valid endpoint credential or local key lifetime. The protected-header kid is only a key-selection hint. The binding profile defines token validation, key use, time validity, revocation, profile, and local-policy checks. The endpoint and Agent binding keys can be equal only when the binding profile and local policy permit the role combination. Otherwise, a verifier MUST preserve the separate key-role checks even if the key material is equal.

Session Proof Material A session proof proves that the holder of the confirmation key bound the verified grant to the accepted channel instance, or to an exported authenticator accepted for that channel instance. It contains at least the abstract profile fields below. A binding profile fixes the exact JWT claim names, CWT claim labels, COSE/JWS protected-header requirements, canonical encoding rules, and collision-avoidance rules used on the wire.

• profile type and profile version;
• audience (aud), proof identifier (jti for JWT-based encodings or cti for CWT/COSE-based encodings), issued-at time (iat), and expiration time (exp);
• grant_hash over the exact verified grant bytes;
• accepted endpoint_role and interaction_type;
• accepted_endpoint_spki_sha256;
• tls_exporter_sha256;
• binding_context_sha256;
• verifier_nonce;
• attempt_id when the binding profile uses one; and
• attestation_binder_sha256 when local policy requires attestation or when accepted attestation-to-channel evidence is used.

For binding profiles that use compact JWS grants or COSE_Sign1/COSE_Mac0 grants, this document fixes the grant_hash input to avoid parser-dependent acceptance behavior: exact-compact-jws-grant-bytes is the exact ASCII byte sequence of the compact JWS as received and successfully verified, including protected header, payload, and signature segments. This document does not define the grant_hash input for JWS JSON Serialization; a binding profile that uses it MUST define the exact hash input. exact-cose-sign1-or-mac0-grant-bytes is the exact byte sequence of the COSE_Sign1 object or Message Authentication Code (MAC)-protected COSE_Mac0 object as received and successfully verified. A verifier MUST NOT compute grant_hash by parsing claims and reserializing JSON, CBOR, or COSE in the acceptance path. Deterministic CBOR/COSE is acceptable only when the binding profile normatively fixes the deterministic encoding rules . Domain-separation strings beginning with sbaip or SBAIP are fixed constants for the construction versions in which they are defined. They are not external registry names.

Direct Channel-Binding Construction This section fixes the Direct-Agent D2 construction. A verifier MUST NOT replace these inputs with peer-selected labels, inferred context, display names, natural-language descriptions, or reserialized semantic metadata.

Endpoint Roles and leaf_spki The field leaf_spki is the DER SubjectPublicKeyInfo of the accepted endpoint public key . It is not a generic reference to whichever certificate happens to be visible to the implementation. A Direct-Agent binding profile MUST identify the accepted endpoint_role and define the exact source of leaf_spki for each supported role, distinguishing TLS server, TLS client, and exported-authenticator certificate keys.

Endpoint role	leaf_spki source	Typical verifier view
client-tls-endpoint	The accepted TLS client certificate public key	The verifier is a server using mTLS.
server-tls-endpoint	The accepted TLS server certificate public key	The verifier is a client accepting a server-side Agent.
exported-authenticator-endpoint	The accepted exported-authenticator certificate public key	The verifier accepts a post-handshake authenticator for the TLS connection.

The endpoint_role field included in the context MUST distinguish the authenticated endpoint role. A binding profile SHOULD use stable, collision-resistant profile-scoped ASCII tokens. The interaction_type field distinguishes application-to-Agent, Agent-to-Agent, Agent-to-tool, Agent-to-mediator, mediator-to-tool, or other profile-defined interactions that can share the same endpoint role. It is selected from verifier-local policy or an authenticated binding-profile field. Unauthenticated peer metadata MUST NOT select it. If TLS termination, a service mesh, or a gateway prevents the verifier from obtaining the exporter value for the Agent-to-verifier channel instance, Direct-Agent mode is not applicable. Such deployments need a gateway-routed binding profile as described in . accepted_endpoint_spki_sha256 identifies the endpoint key, not a unique channel. Channel binding depends on the context-specific exporter and replay state below. Mapping the endpoint role or key to D3 through D7 requires explicit binding-profile and verifier-local policy.

Context and Exporter Construction Inputs:

• tls_connection: the accepted TLS 1.3 connection;
• exporter_label: a TLS exporter label selected by the binding profile, or by verifier-local policy from a set explicitly allowed by that binding profile;
• leaf_spki: DER SubjectPublicKeyInfo of the accepted endpoint public key;
• endpoint_role, interaction_type, protocol_id, aud, grant_hash, task_context, and target_context from authenticated inputs and verifier-local state;
• verifier_nonce: a verifier-generated unpredictable single-use value; and
• attempt_id: an optional verifier-local attempt identifier whose semantics are fixed by the binding profile.

A verifier MUST NOT accept a peer-selected, request-selected, or otherwise ad hoc exporter label. Local experiments can use private-use labels, such as labels beginning with EXPERIMENTAL, as described by . A generally applicable label can be defined later by another specification and registered according to the TLS Exporter Labels registry procedures updated by . The context bytes are sbaip_context_v2: Field names are ASCII. Lengths are unsigned big-endian integers. The field sequence and field names are fixed. grant_hash is the raw 32-byte digest, not a hex string. task_context and target_context are each length-delimited when they contain multiple values. An unused attempt_id is encoded as a zero-length value; it is not omitted. Construction: The session proof carries the SHA-256 values . A common serialization is lowercase hexadecimal without a sha256: prefix, but the encoding profile fixes the exact representation. This construction uses the TLS exporter interface to provide the channel-binding property described by in a profile-specific form; it is not the bare tls-exporter channel-binding value defined by .

Exported Authenticator Binding When an exported authenticator is used, the verifier MUST validate the exported authenticator according to and local certificate, key-use, algorithm, and endpoint-role policy before treating it as an accepted endpoint identity. The TLS exporter is still derived from the accepted underlying TLS connection. The accepted endpoint public key is the exported-authenticator certificate public key only when the binding profile's endpoint role says so. A binding profile that uses exported authenticators MUST define:

• which exported-authenticator object is accepted when multiple authenticators are presented;
• which certificate or public key supplies leaf_spki;
• which party is authorized to sign the session proof;
• how exported-authenticator freshness, certificate validity, and replay protection interact with the session proof;
• whether an exported-authenticator object hash is included in task_context or in a binding-profile extension; and
• how TLS resumption affects exported-authenticator validation and proof reuse.

A verifier MUST NOT accept a session proof that binds to a TLS exporter from one connection and an exported authenticator accepted for another connection.

Attestation Appraisal and Channel Binding The verifier selects the evidence appraiser or attestation-result verifier under local policy. Peer-provided platform names or format identifiers do not by themselves select a trusted verifier or appraisal policy. Any attestation evidence used directly for acceptance MUST be appraised under local policy against the same attestation_binding_input, or against a binding-profile-defined transformation of that input. Any attestation result used for acceptance MUST be verified under a trusted attestation-result signer and local policy, and it MUST carry or cryptographically bind a result-to-channel value derived from that input. If local policy uses attestation to require creator isolation for an Agent confirmation key that differs from leaf_spki, a binding profile MUST bind that confirmation key into the evidence, appraisal input, or an authenticated extension. Binding only leaf_spki and EKM is not evidence that a separate confirmation key is unavailable to the actor's creator or intermediary. A binding profile can present attestation post-handshake, out of band, or through exported authenticators. It maps the binding input to evidence-specific fields. Example transformations are: This example does not define an attestation evidence format and does not replace evidence-format-specific appraisal rules. If local policy requires attestation, absence of an accepted attestation result, attestation-to-channel evidence, or attestation_binder_sha256 is an authentication failure. A verifier MUST NOT silently downgrade an attestation-required interaction to a channel-binding-only interaction. A deployment profile that accepts attestation results from a separate attestation verifier MUST define the attestation-result signer, audience, freshness, nonce or challenge, appraisal policy identifier, and result-to-channel binding. A verifier MUST reject an attestation result whose audience, freshness, appraisal policy, or channel binding is missing or inconsistent with local policy. A verifier compares tls_exporter_sha256 and binding_context_sha256 with its own accepted values. Missing or mismatched mandatory fields fail closed.

Verification Procedure Acceptance has an authentication phase, a policy phase, and a replay-commit step. Authentication phase:

1. Verify the authority grant under a trusted policy-authority key.
2. Check issuer, audience, profile identifier and version, algorithm, key status, iat, exp, grant ID, token type, and required authorization fields.
3. Select the binding profile, endpoint_role, and interaction_type from verifier-local policy and authenticated profile fields.
4. Verify the session proof under the Agent confirmation key or an explicitly authorized endpoint key. Check its type, profile identifier and version, protected headers, required claims, and time validity under the binding profile's rules.
5. Check that the binding signer is authorized by the verified grant or by local policy for the selected endpoint_role.
6. Check endpoint credential or endpoint-key validity under local TLS, PKIX, exported-authenticator, and key-status policy.
7. Recompute grant_hash over the exact verified grant bytes.
8. Recompute the accepted binding context and exporter-derived values.
9. Compare aud, endpoint_role, interaction_type, endpoint-key hash, TLS exporter hash, binding-context hash, attestation binder when required or present, verifier_nonce, and attempt_id when used.
10. Appraise required attestation evidence or verify a trusted attestation result, and verify result-to-channel binding.
11. Build an internal observed assertion only from verified material.

Policy phase:

1. Load verifier-local expected values for required dimensions.
2. Reject missing, ambiguous, non-canonical, or peer-supplied expected values.
3. Compare each observed D3 through D7 value with local expected policy using binding-profile comparison rules.
4. Compare D6 target identity separately from D7 authorization and enforce D7 set semantics.

The effective authorization is the intersection of capabilities authorized by the verified grant, capabilities allowed by verifier-local policy, and capabilities requested for the current task context. A requested capability absent from any of those sets is rejected. Surplus observed capabilities are ignored or rejected according to local policy, but they MUST NOT expand the effective authorization. If an authorization evaluator uses Permit, Deny, Indeterminate, and NotApplicable, only Permit can satisfy a required policy check. Deny rejects the check; Indeterminate means missing information or evaluation failure; NotApplicable means the policy does not apply. A binding profile combining policy results MUST define how they combine and ensure accepted results concern the same actor, request, and context. This profile specifies no wire encoding for these outcomes. Policy Indeterminate does not mean an unknown execution result. A binding profile that permits a reverse request or authorization checkpoint within an existing channel instance MUST bind request_kind, message_direction, parent_invocation_id, parent_task_ref, and authorized_reverse_operation into task_context. An active channel instance alone does not authorize the reverse operation. A callback that opens a new transport association is a separate exchange on a new channel instance. The verifier MUST perform a new acceptance decision for that channel instance and MUST bind the callback to the locally expected parent invocation and task. A callback endpoint, continuation token, parent identifier, or proof accepted on the original channel does not by itself authenticate or authorize the callback exchange. Replay commit:

• before returning the acceptance decision, atomically insert the replay key with an expiry;
• if the insert fails because the key already exists, reject; and
• failed authentication or policy attempts do not consume a one-shot value unless deployment policy deliberately chooses that anti-probing behavior.

The application consumes only the typed accepted assertion defined in .

Positive Acceptance Example For example, after the procedure above succeeds, an assertion can accept actor A to read target T for task Q on channel C until expiry E. Its effective_authorization contains only the read capability allowed by the grant, local policy, and request. If delegation and attestation were not selected, those claims remain absent. The result cannot authorize another task or target. This example leaves the encoding unspecified. The assertion still needs all required fields. A binding profile's positive test vectors SHOULD specify the accepted assertion and its reliance scope, including claims that remain unaccepted. Successful token validation alone does not demonstrate that constrained output.

Minimal Negative Acceptance Cases The following cases are a minimum negative test set for binding profiles and implementations. They are not exhaustive.

Case	Required result
Valid grant, but TLS exporter hash mismatch	Reject
Valid sender-constrained token, but no profile-defined TLS-exporter binding	Reject
Valid session proof, but grant_hash was computed from reserialized claims	Reject
Valid endpoint identity, but D3 service value is only peer-supplied metadata	Reject
Valid endpoint key, but endpoint role is not the role selected by local policy	Reject
Valid endpoint role, but interaction_type is not the type selected by local policy	Reject
Actor identity matches, but the target resource or operation differs from D6 expected policy	Reject
Valid exported authenticator, but it is accepted for a different TLS connection	Reject
Valid attestation result, but not bound to the accepted channel instance	Reject
Local policy requires attestation, but proof is channel-binding-only	Reject
Valid grant with surplus capability not allowed by local policy	Reject, or ignore the surplus capability according to local policy; MUST NOT expand effective authorization
Reused verifier_nonce and binding context on the same channel instance for another task	Reject
Valid session proof and active channel, but a reverse request is not bound to the locally expected parent invocation	Reject
Callback opens a new channel instance but reuses the session proof accepted on the parent channel	Reject
Application-session continuation token presented on a replacement channel without a new channel binding	Reject
Parent task reference matches, but the downstream actor lacks a verified derived grant	Reject
Task transfer omits an inherited condition without verified replacement authorization	Reject
Signed audit record names the operation, but the required authority grant is absent	Reject
External verification result reports success, but a required prerequisite is unresolved	Reject
Actor authentication succeeds, but required Human-approval evidence is absent	Reject
Local policy requires creator-isolated key custody, but the actor supplies only a key identifier and holder-of-key proof	Reject
Replay cache unavailable for a one-shot non-idempotent acceptance	Reject unless local policy defines a safer failure mode
Profile-authenticated identity requested for TLS 0-RTT data	Reject
Gateway-authenticated endpoint presented as final-Agent identity without a gateway-routed binding profile	Reject

Freshness, Replay, Rotation, and Revocation The accepted assertion expiry is the earliest applicable expiry among:

• grant exp;
• session proof exp;
• TLS endpoint credential or endpoint-key lifetime;
• exported-authenticator certificate and validation lifetime;
• attestation-result exp;
• evidence challenge lifetime;
• attestation collateral or TCB lifetime; and
• local policy maximum TTL.

The verifier MUST check the expiry again after any blocking replay commit and before returning the accepted assertion. If expiry is reached after replay was committed, the nonce remains consumed and no accepted assertion is returned. Replay state for an accepted verifier nonce MUST remain protected until no proof using that nonce can be accepted. The retention boundary is at least the latest of the accepted assertion expiry, session-proof expiry, and verifier challenge or nonce expiry. A replay store that cannot retain the reservation for that period fails the acceptance step; a shorter store TTL is not a separate freshness source. A missing required freshness policy value fails closed. Evidence without a trusted timestamp is acceptable only for the current challenge and current authentication attempt. TLS resumption, reconnection, and transport replacement create a new channel instance. The verifier MUST require a new channel binding and MUST NOT reuse the previous session proof or acceptance decision. Profile-authenticated identity MUST NOT be returned for TLS 0-RTT data. A path or address migration can preserve the transport connection. This profile still requires a fresh acceptance decision, verifier_nonce, and session proof bound to the retained channel instance after migration. A binding profile supporting migration MUST define how the verifier detects the event and completes reacceptance before an accepted assertion is used again. Existing nonce reservations remain effective for their full retention period. An application-session continuation token does not prove binding to a replacement channel instance. A continuation profile MUST authenticate the logical application-session state and bind it to the new channel instance before the application consumes a continued accepted result. Continuation also requires a new acceptance decision under current grant validity, key status, and verifier-local policy. Retained task or application-session state does not extend an expired grant or assertion. Credential renewal does not erase that state or, by itself, authorize a change to its task, target, or delegation constraints. verifier_nonce is generated by the verifier. A binding profile MUST define at least 128 bits of unpredictability, single-use handling, and a bounded lifetime. A peer-generated value does not satisfy verifier_nonce. If the replay cache cannot enforce the profile's single-use rule, acceptance fails closed. attempt_id is a verifier-generated identifier for local-state lookup and diagnostics. When used, its uniqueness scope and collision handling are fixed by the binding profile, and a collision fails closed. attempt_id is not a substitute for verifier_nonce. When multiple tasks share one channel instance, each accepted task binding MUST include a task-specific task_context, target_context, verifier_nonce, and attempt_id when used. Reusing the same context and verifier nonce across tasks fails closed. A successful acceptance atomically reserves verifier_nonce within the binding profile's verifier or audience namespace. Changing a binding-statement ID, task, target, channel, attempt ID, or attestation-result ID MUST NOT make the same nonce acceptable again. A binding profile can store a separate composite digest for audit or request correlation, but that digest does not replace the nonce reservation. Key lookup and key caches MUST be scoped by the equivalent of: kid is never a global key name. Unknown, revoked, retired, stale, wrong-use, or ambiguous keys fail closed. Deployments that need early invalidation need grant revocation, policy-authority-key revocation, Agent-binding-key revocation, and endpoint-key revocation separately. This document does not define revocation propagation for a logical application session or task graph. Ending or revoking an application correlation value does not by itself revoke an authority grant or key, and revoking an authority grant or key does not erase application correlation state. A binding profile that couples those operations MUST define the authenticated revocation event, scope, propagation rule, and failure behavior.

Canonical Values and String Comparison Decision-sensitive semantic values need to be canonical before acceptance. Common examples are ontology_id, intent_ref, capability_ref, task_ref, workload_id, and tenant_id. Receivers MUST NOT repair peer-provided aliases, display labels, natural language phrases, case variants, URI variants, or model interpretations during the final acceptance path. Alias resolution belongs to the policy authority, trusted registry, or local policy engine before issuance or comparison. An alias is acceptable only when it resolves to exactly one canonical reference under a pinned registry namespace and version. Missing, ambiguous, deprecated, or unsupported registry data fails closed. When an Agent uses natural language or model-generated plans, the verifier MUST NOT use those strings as D3 through D7 expected values unless a binding profile and local policy define a deterministic canonicalization and approval path. Profile constants, field names, and the domain-separation strings defined by this document are ASCII. Decision-sensitive values are compared only in the canonical form defined by the binding profile and local policy. Binding profiles SHOULD prefer opaque identifiers, URIs, or other canonical references for D3 through D7 values. If a binding profile permits non-ASCII decision-sensitive strings, it MUST define the character encoding, normalization form, comparison rules, case handling, and treatment of visually confusable strings. Display strings and natural-language text MUST NOT be used as policy keys unless that deterministic comparison profile is defined.

Deployment Topologies

Direct-Agent Mode In Direct-Agent mode, the actor or its peer endpoint participates in the accepted channel instance and signs with the grant's confirmation key or an explicitly authorized endpoint key. The exporter-availability condition is specified in .

Gateway-Routed Mode Gateway-routed deployments use separate binding profiles. This section gives their security requirements, not a complete profile. Gateway authentication proves the gateway endpoint, not the downstream actor or target. A verifier MUST NOT accept a downstream actor or target identity through a gateway unless a binding profile defines route assertions, downstream holder-of-key requirements when required by policy, freshness, replay protection, and local route policy. A gateway-routed binding profile MUST define:

• whether the bound channel is actor-to-gateway, gateway-to-verifier, both, or another authenticated transport path;
• whether downstream actor holder-of-key proof is required end-to-end or whether a gateway route assertion is accepted as delegated authority;
• the gateway route assertion signer, audience, expiry, nonce, route, tenant or authority partition, downstream actor, target, interaction type, binding context, and replay key;
• which claims and payloads the gateway is allowed to see, transform, or withhold;
• how route assertions interact with authority grants and which value wins when they disagree; and
• how local policy rejects missing, stale, replayed, wrong-route, wrong-tenant, wrong-task, wrong-actor, or wrong-target assertions.

A gateway, route service, transparency log, or action log is a deployment choice, not a protocol requirement. Gateway deployments that exchange tokens can use OAuth 2.0 Token Exchange when applicable.

Privacy Considerations Identity-binding data can create correlation. Deployments SHOULD prefer audience-scoped or pairwise identifiers, short lifetimes, selective disclosure, reference tokens, and minimized logs. Full grants, session proofs, key fingerprints, attestation evidence, tenant IDs, task IDs, capability references, route assertion IDs, and replay keys SHOULD NOT be logged unless needed for security audit. When logging is required, deployments SHOULD apply retention limits, access controls, and redaction appropriate to the sensitivity of the deployment. Attestation evidence can contain platform-unique or device-unique information. A binding profile that carries attestation evidence or detailed attestation results SHOULD consider pairwise identifiers, audience-scoped attestation results, reference tokens, or selective disclosure to reduce cross-verifier linkability. task_context can reveal user intent, business process state, customer identifiers, or transaction details. Binding profiles SHOULD hash or reference task_context values when the verifier does not need to disclose the full task content to intermediaries or logs. Application correlation values and parent-child relationships can enable cross-domain linkability even when payloads are hidden. Binding profiles SHOULD use audience-scoped values and disclose parent-child relationships only to parties that need them. A stable unsalted hash remains linkable. Intermediaries SHOULD receive only the claims and payloads needed for their role. A gateway-routed binding profile SHOULD state which identity, task, attestation, and capability fields are visible to each intermediary.

Caching, Replay Commit, and Operation Recovery Verified grants, session proofs, attestation evidence, authorization decisions, and verification results MUST NOT be cached as acceptance evidence for a later channel instance or request. HTTP caching semantics are unchanged. The default for profile-sensitive HTTP responses is no-store . Vary is insufficient when the decision depends on non-header security state. Implementations can cache inputs that are not themselves acceptance evidence, such as trusted key sets, key-status metadata, parsed local policy, endpoint public-key hashes, and precomputed grant hashes. Such caches need to be scoped by the same fields used for key lookup, profile version, issuer, audience, key use, algorithm, key status, and local policy. Cached inputs MUST NOT expand the effective authorization and MUST NOT be reused as proof of acceptance for a different request or channel instance. Distributed replay caches are security-critical. For one-shot or non-idempotent interactions, a verifier deployment SHOULD use a strongly consistent replay-commit mechanism across all verifier instances that can accept the same replay key. If the replay cache is unavailable, partitioned, or cannot provide the consistency required by local policy, the verifier MUST fail closed unless local policy defines a narrower safe mode for idempotent requests. Any such mode MUST preserve the profile's nonce single-use requirement. Otherwise, no profile-authenticated assertion is returned. Multi-region deployments SHOULD bound the accepted replay window, identify which region owns the replay key, or use replay-key sharding that prevents an attacker from choosing a less-protected verifier instance. Replay commit MUST occur before the application observes a positive acceptance decision, as required by . An application MUST NOT use this profile to authorize a side effect before that decision. A binding profile that supports retry or result recovery MUST distinguish the logical application operation from each authentication attempt. It defines the operation identifier's namespace and the canonical application-request digest. A retry retains that identifier and digest but uses a fresh verifier nonce and session proof. A change of proof or channel does not create a new application operation. Reusing an operation identifier with a different request digest MUST be rejected. The profile defines which authenticated callers may retry the operation or retrieve its result. For a non-idempotent operation, a deployment can reserve the replay key and a stable operation ID and request digest in one transaction. A replay reservation alone does not establish whether the application committed or executed the operation. After execution may have begun, a lost connection or response does not authorize a blind retry. The receiver returns recorded operation state or marks the result indeterminate until it can reconcile the external effect. Result retrieval requires a fresh acceptance decision for that retrieval under current local policy; the recorded result is application state, not reusable acceptance evidence. A fresh proof does not authorize duplicate execution. An application MUST NOT begin a new operation after the accepted assertion expires. If expiry is reached after the operation is reserved but before the external call, the receiver records that the operation was not run and does not invoke it.

Security Considerations The core invariant in depends on the key-role, construction, policy, and replay checks above. The minimum rejection cases in exercise these boundaries. JWT- or JWS-based binding profiles MUST follow , including issuer and subject validation, audience validation, algorithm verification, explicit typing when applicable, and mutually exclusive validation rules for different token types. Received claims remain observed values until policy comparison succeeds; grant_hash uses the exact verified bytes. TLS deployments rely on and the deployment recommendations in . This profile does not update TLS. A gateway, relay, registry, or transparency service is a trust root only when local policy says so. Deployment profiles SHOULD evaluate disclosure to intermediaries, mandatory gatekeeping or monitoring, and the ability of persons or organizations to choose trusted authorities and disclosed claims.

Diagnostics Diagnostics SHOULD preserve the acceptance dimension, field, and error class, but SHOULD NOT echo raw peer values. Local diagnostics SHOULD distinguish a failed check from unavailable input, an unsupported verifier capability, or a check not attempted. None permits acceptance when the check is required. External responses can combine these reasons under the disclosure policy. Implementations SHOULD reject invalid UTF-8, CRLF, control characters, and HTML delimiter characters in profile fields unless the field profile explicitly permits and canonicalizes them. Diagnostic error classes SHOULD be stable enough to support conformance tests for D0 through D7 failures, replay failures, and context-diversion failures. The external diagnostic response SHOULD avoid revealing whether a guessed issuer, key identifier, tenant, task reference, target, route, or capability reference exists.

IANA Considerations This document makes no IANA requests and defines no TLS exporter label. Label selection, the prohibition on peer-selected or request-selected labels, and registration under are specified in .

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. Informative References The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits. This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK] A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. This document discusses aspects of centralization that relate to Internet standards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. This document updates the changes to the TLS and DTLS IANA registries made in RFC 8447. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. Palo Alto Networks Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-level proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Palo Alto Networks Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT).

Non-Normative Example: HTTPS Direct-Agent JWS Binding Sketch This appendix is non-normative. It illustrates HTTPS/JWS-specific inputs that a future binding profile would need to fix; it does not define conformance by itself. In this example, a binding profile uses an accepted TLS 1.3 channel instance, a compact JWS authority grant, a compact JWS session proof, a binding-profile-authorized TLS exporter label, a verifier nonce, and verifier-local interaction, task, and target contexts. Illustrative wire elements:

• Agent-Authority-Grant: compact JWS authority grant;
• Agent-Session-Proof: compact JWS session proof;
• Agent-Attestation: binding-profile-defined attestation reference or result, when required;
• HTTP request components and selected content digests, preferably using and , included in task_context; and
• Problem Details error responses with coarse diagnostic classes.

defines the normative verifier behavior and includes positive and negative acceptance cases. Illustrative binding-specific input mapping:

• the authority grant is the exact compact JWS byte sequence carried by Agent-Authority-Grant;
• the session proof is the compact JWS carried by Agent-Session-Proof;
• protocol_id is an HTTPS Direct-Agent profile identifier selected by the binding profile;
• endpoint_role and interaction_type selection follow verifier-local policy and authenticated profile fields;
• task_context and target_context are constructed from HTTP Message Signatures components, Digest Fields, and verifier-local request state chosen by the binding profile;
• the exporter label is selected by the binding profile, or by verifier-local policy from a set explicitly allowed by that binding profile; it is not peer-selected or request-selected;
• binding_context_sha256 is computed from the profile context defined by the binding profile; and
• attestation material is either absent or carried as a binding-profile-defined reference or result when local policy requires it.

A conforming HTTPS binding profile defines stable HTTP field names, canonicalization rules, exporter-label rules, error formats, and replay-cache semantics.

Non-Normative Context-Encoding Test Vector This appendix gives a deterministic context-encoding test vector. It uses sample byte strings for TLS-related inputs; it is not a TLS exporter test vector and does not test any signature algorithm. It is intended to help implementations test field ordering, length encoding, grant_hash treatment, and hash representation. Inputs: Line breaks in the following hex values are for display only. Expected context hex: Expected hashes: