Individual Submission A. Okutomi Internet-Draft Individual Intended status: Informational 24 June 2026 Expires: 26 December 2026 A Profile for Session-Bound Agent Identity draft-okutomi-session-bound-agent-identity-01 Abstract This document defines a verifier-side profile for accepting agent identity. A verifier accepts an Agent only when an authority statement, holder-of-key proof, accepted TLS session, freshness state, any required attestation result, and verifier-local policy all describe the same intended interaction. The profile does not define a TLS extension, attestation evidence format, identity provider, wallet format, registry, control plane, gateway, or application protocol. It composes existing mechanisms and defines the fail-closed acceptance rule between them. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Okutomi Expires 26 December 2026 [Page 1] Internet-Draft Session-Bound Agent Identity June 2026 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4 4. Internet Applicability and Deployment Assumptions . . . . . . 5 5. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acceptance Model . . . . . . . . . . . . . . . . . . . . . . 6 7. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Authority and Key Separation . . . . . . . . . . . . . . . . 7 9. Encoding Profiles . . . . . . . . . . . . . . . . . . . . . . 8 10. Relationship to Existing Mechanisms . . . . . . . . . . . . . 8 11. Grant and Authority Material . . . . . . . . . . . . . . . . 9 12. Session Proof Material . . . . . . . . . . . . . . . . . . . 9 13. Direct Session Binding Construction . . . . . . . . . . . . . 10 14. Verification Procedure . . . . . . . . . . . . . . . . . . . 13 15. Freshness, Replay, Rotation, and Revocation . . . . . . . . . 14 16. Canonical Policy Values . . . . . . . . . . . . . . . . . . . 15 17. Deployment Topologies . . . . . . . . . . . . . . . . . . . . 15 17.1. Direct-Agent Mode . . . . . . . . . . . . . . . . . . . 15 17.2. Gateway-Routed Mode . . . . . . . . . . . . . . . . . . 16 18. Privacy, Caching, and Diagnostics . . . . . . . . . . . . . . 16 19. Security Considerations . . . . . . . . . . . . . . . . . . . 16 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 21. Normative References . . . . . . . . . . . . . . . . . . . . 17 22. Informative References . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Automated agents often combine transport authentication, signed authorization material, platform attestation, and local policy. Each component can verify successfully while the composition is still wrong. For example, a valid grant can be replayed on another TLS session, a valid endpoint can be used for the wrong task, or a valid platform can be accepted for the wrong agent. This document defines a session-bound agent identity profile. The verifier accepts a peer only when the authenticated identity, session binding, freshness state, attestation state when required, and local policy describe the same intended session, platform, service, agent, task, and authority boundary. Okutomi Expires 26 December 2026 [Page 2] Internet-Draft Session-Bound Agent Identity June 2026 The profile is an application-profile acceptance gate. It does not change TLS [RFC8446], exported authenticators [RFC9261], remote attestation roles [RFC9334], JWT/JWS, CWT/COSE, OAuth, or HTTP. It defines the composition rules needed to fail closed across those mechanisms. This document does not define a mandatory Agent control plane, rendezvous service, registry, gateway, transparency log, action log, media relay, or policy distribution service. Deployments can use such components, but they are not required by this profile. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent The workload, process, service component, or automated actor whose identity is being accepted by the verifier. Principal A person or organization on whose behalf an Agent acts. Verifier The party that authenticates the grant, checks the session binding, evaluates freshness and replay state, and compares the result with local policy before returning an accepted identity to the application. Policy authority A locally trusted issuer of authority statements. Some deployments call this role a Manager. Grant material A signed or MACed authority statement issued by a policy authority. It authorizes upper-layer identity, task, and authorization values. It does not prove that the authorized Agent is present on the current TLS session. Session proof A holder-of-key proof that binds one verified authority grant to one accepted TLS or exported-authenticator session. It proves possession and session binding. It does not authorize service, tenant, task, scope, resource, or capability values. Expected value A verifier-local policy input. Observed value A value extracted from authenticated grants, session- Okutomi Expires 26 December 2026 [Page 3] Internet-Draft Session-Bound Agent Identity June 2026 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. Wrong-context acceptance Accepting cryptographically valid material for a different service, tenant, Agent, task, delegation, or authority boundary than the verifier intended. This document uses "context diversion" as a short failure description; it is not a new wire mechanism. Intermediary A gateway, relay, proxy, broker, service on the communication path, or component that terminates transport security for either side. Wallet A holder-side presentation component; this profile does not define wallet behavior or make wallets trust roots. Acceptance decision Returning a peer identity or authorization result to the application as profile-authenticated. For one-shot bindings, replay state is committed before this decision is returned. 3. Scope and Non-Goals This profile defines verifier behavior before an application treats an accepted TLS peer as the intended platform, service, Agent, task, or authorized actor. It binds three classes of facts: * accepted TLS and post-handshake attestation facts; * authenticated identity and authorization material; * verifier-local expected policy. The profile does not select an identity provider, define a new wire- token format, change attestation evidence, change TLS, define wallet behavior, define discovery or rendezvous, or provide a complete authorization framework. A requirement belongs in this profile when omitting it could lead to accepting the wrong live session, wrong service or tenant, wrong Agent, wrong task, stale or replayed state, peer-selected metadata as policy, or a security result reused outside the request for which it was produced. Okutomi Expires 26 December 2026 [Page 4] Internet-Draft Session-Bound Agent Identity June 2026 4. Internet Applicability and Deployment Assumptions This profile is intended to be usable in both open Internet and enterprise deployments. Closed-world provisioning is one deployment model, not a protocol requirement. A prior bilateral relationship between the Agent operator and the Verifier is not required. A Verifier does require a local trust path to the issuer, attestation result, trust framework, or other authority used to evaluate the presented material. If no acceptable trust path exists, acceptance fails closed. This profile does not require a single globally trusted authority, mandatory registry, rendezvous service, gateway, online authority, transparency log, or control plane. Deployments MAY use those components, but they are deployment choices and are not required for protocol interoperability. Intermediaries are not trusted by default. A gateway or relay that terminates transport security is a separate relying party and sees only the claims and payloads disclosed to it. This profile does not require intermediaries to observe, approve, log, or gate Agent actions. When an Agent acts on behalf of a Principal, deployment profiles SHOULD support audience-scoped disclosure, short-lived grants, selective disclosure or reference tokens where available, and Principal-selected authorities and disclosure modes where practical. Claims required for security should be distinguished from claims requested for application convenience. These assumptions are intended to preserve strong cryptographic protection, avoid standardizing wiretapping or pervasive monitoring functions, keep privacy analysis explicit, favor end-user interests, and avoid unnecessary centralization of Internet functions [RFC1984] [RFC2804] [RFC7258] [RFC6973] [RFC8890] [RFC9518]. 5. Conformance This document defines conformance for Direct-Agent mode. A conforming implementation completes all grant verification, holder- of-key verification, session-binding verification, required attestation checks, freshness checks, replay checks, and local-policy comparisons before returning a profile-authenticated identity or authorization result to the application. Okutomi Expires 26 December 2026 [Page 5] Internet-Draft Session-Bound Agent Identity June 2026 A conforming implementation MUST fail closed. It MUST NOT report a profile-authenticated identity from only a verified authority grant, only a session proof, only a TLS endpoint identity, only an attestation result, or only peer-supplied metadata. 6. Acceptance Model The labels D0 through D6 are acceptance dimensions used for policy separation and diagnostics. They are not OSI layers, encapsulation layers, wire-format layers, or trust hierarchy levels. The numbering is only a stable diagnostic order. It does not imply that D6 is above D5 or that every deployment evaluates all dimensions. +===========+==========================+=========================+ | Dimension | Verification target | Main failure class | +===========+==========================+=========================+ | D0 | Live TLS or exported- | MITM or session | | | authenticator session | confusion | +-----------+--------------------------+-------------------------+ | D1 | Attested platform | Fake, malformed, stale, | | | validity, when required | or untrusted evidence | +-----------+--------------------------+-------------------------+ | D2 | Attestation or | Relay, replay, or | | | authenticator-to-session | borrowed evidence | | | binding | | +-----------+--------------------------+-------------------------+ | D3 | Service, tenant, | Wrong service or | | | deployment, or | tenant; context | | | environment | diversion | +-----------+--------------------------+-------------------------+ | D4 | Workload, process, or | Same-host wrong-Agent | | | Agent | confusion | +-----------+--------------------------+-------------------------+ | D5 | Task, thread, context, | Wrong task or | | | or delegation | delegation; context | | | | diversion | +-----------+--------------------------+-------------------------+ | D6 | Authorization or | Confused deputy or | | | capability policy | privilege escalation | +-----------+--------------------------+-------------------------+ Table 1 D0 through D2 are authentication and binding dimensions. D3 through D6 are verifier-local policy dimensions. Peer-provided metadata can be observed input; it is not expected policy. Okutomi Expires 26 December 2026 [Page 6] Internet-Draft Session-Bound Agent Identity June 2026 7. Threat Model The attacker can observe, replay, reorder, relay, and substitute network or application messages. The attacker can supply malicious peer metadata and can run another Agent on the same host or in the same deployment environment. The profile assumes that TLS 1.3, exported-authenticator validation, and evidence appraisal are implemented correctly by the underlying mechanisms. It defines what must be bound to those facts before an application accepts the peer as the intended actor. Out of scope are a fully compromised verifier process, a malicious trusted policy authority, compromise of all local secret storage, denial of service, and side channels outside the identity-binding path. The main threats are relay, replay, token substitution, stale key use, same-host wrong- Agent confusion, peer-metadata injection, context diversion, confused deputy behavior, cache confusion, and gateway route confusion. 8. Authority and Key Separation The profile keeps three key roles separate. +==================+========================================+ | Key role | Purpose | +==================+========================================+ | TLS endpoint key | Proves possession for the accepted TLS | | | or exported-authenticator endpoint. | +------------------+----------------------------------------+ | Agent binding | Signs the session proof. | | key | | +------------------+----------------------------------------+ | Policy-authority | Signs authority grants. | | key | | +------------------+----------------------------------------+ Table 2 These keys can be related by deployment policy, but they are not interchangeable by default. 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 keys are valid for session binding only when the verified grant or local policy explicitly authorizes that use and the endpoint credential or local endpoint-key lifetime remains valid. Okutomi Expires 26 December 2026 [Page 7] Internet-Draft Session-Bound Agent Identity June 2026 The protected-header kid is only a key-selection hint. Acceptance also depends on issuer, audience, algorithm allow-list, key type, key use, key status, profile version, token type, time validity, revocation state, and local policy. The none algorithm is forbidden. 9. Encoding Profiles This core profile does not require HTTP, OAuth [RFC6749], a specific JWT [RFC7519] claim set, JWS [RFC7515] serialization, or a specific CWT label set. An encoding profile fixes the exact wire representation, including token type, claim names or labels, protected-header rules, canonicalization, grant_hash input bytes, request-context binding, and diagnostic format. OAuth deployments can use the JWT access-token profile [RFC9068], token revocation and introspection [RFC7009] [RFC7662], mutual-TLS certificate-bound tokens [RFC8705], resource indicators [RFC8707], and rich authorization requests [RFC9396] where they fit. Sender- constrained HTTP/OAuth proofs can use DPoP [RFC9449], but DPoP alone does not provide this profile's TLS-exporter or attestation-to- session binding. HTTP bindings can use HTTP Message Signatures [RFC9421], Digest Fields [RFC9530], Structured Fields [RFC9651], and Problem Details [RFC9457] instead of defining new HTTP signing, digest, header, or error formats. Tokenized attestation claims can use EAT [RFC9711] within the RATS model. 10. Relationship to Existing Mechanisms Encoding profiles should reuse existing Internet mechanisms rather than define parallel wire formats. In OAuth deployments, authority grants can be OAuth JWT access tokens [RFC9068], token status and early invalidation can use token revocation or introspection [RFC7009] [RFC7662], and sender constraining can use mutual-TLS certificate-bound tokens or DPoP when those models fit [RFC8705] [RFC9449]. Resource selection and fine-grained authorization can use Resource Indicators and Rich Authorization Requests [RFC8707] [RFC9396]. HTTP profiles can use HTTP Message Signatures, Digest Fields, Structured Field Values, and Problem Details instead of defining new HTTP- specific syntax or error formats [RFC9421] [RFC9530] [RFC9651] [RFC9457]. Attestation token profiles can use EAT with the RATS roles already referenced by this document [RFC9711] [RFC9334]. Okutomi Expires 26 December 2026 [Page 8] Internet-Draft Session-Bound Agent Identity June 2026 These mechanisms do not by themselves provide this document's fail- closed cross-mechanism acceptance rule. This profile only specifies when the verified grant, session proof, accepted TLS session, freshness state, required attestation result, and verifier-local policy are accepted as the same intended interaction. 11. Grant and Authority Material An authority grant authorizes application semantics. It is signed or MACed by a policy authority and identifies the Agent confirmation key, usually through a confirmation-key claim such as cnf.kid for JWT [RFC7800] or the corresponding CWT confirmation method [RFC8747]. This 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 D6 fields such as service, tenant, deployment, workload, Agent, task, delegation, 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, session 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. 12. Session Proof Material A session proof proves that the holder of the confirmation key bound the verified grant to the accepted TLS or exported-authenticator session. It contains at least the abstract profile fields below. An encoding 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; * aud, jti or cti, iat, and exp; * grant_hash over the exact verified grant bytes; * leaf_public_key_sha256; * tls_exporter_sha256; Okutomi Expires 26 December 2026 [Page 9] Internet-Draft Session-Bound Agent Identity June 2026 * request_context_sha256; * nonce; * attestation_binder_sha256 when local policy requires attestation or when accepted attestation-to-session evidence is used. For the initial compact JWS and CWT/COSE encodings, grant_hash is computed over the exact verified grant bytes: grant_hash = SHA-256("sbaip.identity-grant.jwt.v1" || NUL || exact-compact-jws-grant-bytes) grant_hash = SHA-256("sbaip.identity-grant.cwt.v1" || NUL || exact-cose-sign1-or-mac0-grant-bytes) 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. The initial JWT encoding does not define grant_hash for JWS JSON Serialization; a future encoding profile that uses it MUST define the exact hash input. exact-cose-sign1-or-mac0-grant-bytes is the exact byte sequence of the signed or MACed COSE 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 encoding profile normatively fixes the deterministic encoding rules [RFC8392] [RFC8949] [RFC9052]. Domain-separation strings beginning with sbaip or SBAIP are fixed constants for this profile version. They are not external registry names. The session proof does not authorize service, tenant, task, scope, resource, or capability values. Those values come from the verified grant and local policy. 13. Direct Session 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, or reserialized semantic metadata. Inputs: * tls_connection: the accepted TLS 1.3 connection; Okutomi Expires 26 December 2026 [Page 10] Internet-Draft Session-Bound Agent Identity June 2026 * exporter_label: an application- or deployment-profile-selected TLS exporter label. This document does not define that label; * leaf_spki: DER SubjectPublicKeyInfo of the accepted endpoint public key [RFC5280]; * role, protocol_id, aud, grant_hash, task_context, and verifier_nonce_or_attempt_id from verifier-local state. The exporter label is selected by the application or deployment profile, not by the peer. A verifier MUST NOT accept a peer-selected exporter label. Local experiments can use private-use labels, such as labels beginning with EXPERIMENTAL, as described by [RFC5705]. A generally applicable label can be defined later by another specification and registered according to the TLS Exporter Labels registry procedures updated by [RFC9847]. The context bytes are sbaip_context_v1: field(name, value) = u16be(len(name)) || name || u32be(len(value)) || value context = "SBAIP-CONTEXT-v1" || NUL || field("role", role) || field("protocol_id", protocol_id) || field("aud", aud) || field("grant_hash", raw_32_byte_grant_hash) || field("task_context", task_context) || field("verifier_nonce_or_attempt_id", verifier_nonce_or_attempt_id) 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 is itself length- delimited when it contains multiple values. Construction: Okutomi Expires 26 December 2026 [Page 11] Internet-Draft Session-Bound Agent Identity June 2026 EKM = TLS-Exporter(tls_connection, label = exporter_label, context = context, length = 32) attestation_binding_input = "SBAIP-ATTESTATION-BINDING-v1" || NUL || field("leaf_spki", leaf_spki) || field("ekm", EKM) leaf_public_key_sha256 = SHA-256(leaf_spki) tls_exporter_sha256 = SHA-256(EKM) request_context_sha256 = SHA-256(context) attestation_binder_sha256 = SHA-256(attestation_binding_input) The session proof carries the SHA-256 values [RFC6234]. A common serialization is lowercase hexadecimal without a sha256: prefix, but the encoding profile fixes the exact representation. leaf_public_key_sha256 confirms the endpoint key, but it is not session unique. The primary session binding is the TLS exporter under the accepted profile context, plus the grant hash, audience, nonce, attestation binder when present, and replay state. This construction uses the TLS exporter interface [RFC8446] to provide the channel-binding property described by [RFC5056] in a profile-specific form; it is not the bare tls-exporter channel-binding value defined by [RFC9266]. Attestation evidence or attestation results must be appraised against the same attestation_binding_input. For evidence formats that expose report data or nonce, the attestation adapter derives profile- specific values such as: report_data = SHA-512(attestation_binding_input) evidence_nonce = SHA-256("SBAIP-EVIDENCE-NONCE-v1" || NUL || EKM) If local policy requires attestation, absence of an accepted attestation result, attestation-to-session 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 verifier compares tls_exporter_sha256 and request_context_sha256 with its own accepted values. Missing or mismatched mandatory fields fail closed. Okutomi Expires 26 December 2026 [Page 12] Internet-Draft Session-Bound Agent Identity June 2026 14. 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 guard, algorithm, key status, iat, exp, grant ID, and required authorization fields. 3. Verify the session proof under the Agent confirmation key or an explicitly authorized endpoint key. 4. Check that the binding signer is authorized by the verified grant or by local policy. 5. Check endpoint credential or endpoint-key validity under local TLS, PKIX, and key-status policy. 6. Recompute grant_hash over the exact verified grant bytes. 7. Recompute the accepted context and exporter-derived values. 8. Compare aud, endpoint-key hash, TLS exporter hash, request- context hash, attestation binder when required or present, and nonce. 9. 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 D6 value with local expected policy. 4. Enforce D6 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. Okutomi Expires 26 December 2026 [Page 13] Internet-Draft Session-Bound Agent Identity June 2026 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; * failed authentication or policy attempts do not consume a one-shot value unless deployment policy deliberately chooses that anti- probing behavior. Neither an authority grant alone nor a session proof alone is enough. Sender-constraining proves possession and freshness; it does not authorize surplus scopes, resources, capabilities, or authorization details. 15. 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, attestation-result exp, evidence challenge lifetime, attestation collateral or TCB lifetime, endpoint credential validity, replay-cache TTL, local policy maximum TTL 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 creates a new accepted TLS connection for this profile. A resumed connection MUST NOT reuse a session proof or replay-cache entry from the original connection. Profile- authenticated identity MUST NOT be returned for TLS 0-RTT data. When multiple tasks share one TLS connection, each accepted task binding MUST include a task-specific task_context and verifier_nonce_or_attempt_id. Reusing the same context and nonce across tasks fails closed. Replay protection is keyed at least over: Okutomi Expires 26 December 2026 [Page 14] Internet-Draft Session-Bound Agent Identity June 2026 grant_hash || aud || tls_exporter_sha256 || request_context_sha256 || nonce When available, the key also includes the binding statement ID, task- binding value, evidence nonce, verifier challenge, or attestation- result identifier. Key lookup and key caches MUST be scoped by the equivalent of: profile_version || token_type || issuer || audience || key_use || alg || kty || kid || key_status || public_key_thumbprint kid is never a global key name. Unknown, revoked, retired, stale, wrong-use, or ambiguous keys fail closed. Deployments that need early invalidation must support grant revocation, policy-authority- key revocation, and Agent-binding-key revocation separately. 16. Canonical Policy Values Decision-sensitive semantic values must be canonical before acceptance. Common examples are ontology_id, intent_ref, and capability_ref. 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. 17. Deployment Topologies 17.1. Direct-Agent Mode In Direct-Agent mode, the Agent terminates TLS and signs the session proof with the confirmation key named by the verified authority grant, or with an endpoint key explicitly authorized by the grant or local policy. Okutomi Expires 26 December 2026 [Page 15] Internet-Draft Session-Bound Agent Identity June 2026 17.2. Gateway-Routed Mode Gateway-routed mode is a separate profile and is not the default Internet deployment model. Gateway session binding proves the gateway endpoint, not the final Agent process. A relying party accepts the final Agent only after a route assertion passes local route policy, freshness, replay, and any required final-Agent holder- of-key check. A gateway, route service, transparency log, or action log is a deployment choice, not a protocol requirement. The route assertion binds the gateway identity, relying-party audience, route, tenant or authority partition, target Agent, request context, nonce, and expiry. Missing, stale, replayed, wrong-route, wrong-tenant, wrong-task, or wrong-Agent assertions fail closed. Gateway deployments that exchange tokens can use OAuth 2.0 Token Exchange [RFC8693] when applicable. 18. Privacy, Caching, and Diagnostics 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, binding statements, key fingerprints, attestation evidence, tenant IDs, task IDs, and capability references should not be logged unless needed for security audit. Intermediaries SHOULD receive only the claims and payloads needed for their role. Response caching and security-state caching are different. Verified grants, session proofs, attestation evidence, authorization decisions, and verification results MUST NOT be cached as acceptance evidence for a later session or request. The default for profile- sensitive HTTP responses is no-store [RFC9111]. Vary is not enough when the decision depends on non-header security state. Diagnostics should preserve the acceptance dimension, field, and error class, but should not echo raw peer values. 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. 19. Security Considerations The security of this profile depends on the verifier applying all acceptance checks before returning a profile-authenticated identity to the application. Partial verification is not enough. Okutomi Expires 26 December 2026 [Page 16] Internet-Draft Session-Bound Agent Identity June 2026 Implementations need fail-closed parsing for token type, algorithm, key, audience, duplicate claim names, malformed base64url, unsupported nesting, unexpected crit, and typ/cty ambiguity [RFC8725]. A parser that silently accepts duplicate JSON member names or unsupported critical headers is not suitable for this profile. Before acceptance, a conforming implementation verifies at least: separated authority grant and session proof authorities; exact verified grant bytes in grant_hash; the locally selected exporter label and exact sbaip_context_v1 bytes; endpoint key, exporter, context, nonce, and required attestation binder values; TLS endpoint credential validity; atomic replay commit; verifier-local D3 through D6 policy; canonical semantic references; and the earliest applicable expiry. Gateway mode, when used, also authenticates the gateway endpoint and gateway-to-Agent route separately. Implementations should evaluate relay, borrowed attestation, token substitution, multiple tasks on one TLS connection, HTTP/2 or gRPC connection reuse, TLS resumption, 0-RTT behavior, distributed replay- cache races, gateway route confusion, malformed JWT/CWT/COSE inputs, duplicate JSON members, Unicode edge cases, and the invariant that a grant is accepted only with the intended binding, session, and local policy. Deployment profiles should evaluate mandatory intermediaries or registries, what is exposed to them, gatekeeping or monitoring risk, and whether Principals can choose trusted authorities and disclosed claims. 20. IANA Considerations This document makes no IANA requests. This profile does not define a new TLS exporter label. Protocols using this profile are expected to define or select an appropriate application-specific exporter label. Any future generally applicable label is expected to follow the registration procedures for the "TLS Exporter Labels" registry, as updated by [RFC9847]. 21. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Okutomi Expires 26 December 2026 [Page 17] Internet-Draft Session-Bound Agent Identity June 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . Okutomi Expires 26 December 2026 [Page 18] Internet-Draft Session-Bound Agent Identity June 2026 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . 22. Informative References [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, . [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, May 2000, . [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . Okutomi Expires 26 December 2026 [Page 19] Internet-Draft Session-Bound Agent Identity June 2026 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266, DOI 10.17487/RFC9266, July 2022, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . Okutomi Expires 26 December 2026 [Page 20] Internet-Draft Session-Bound Agent Identity June 2026 [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9518] Nottingham, M., "Centralization, Decentralization, and Internet Standards", RFC 9518, DOI 10.17487/RFC9518, December 2023, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, . Author's Address Akira Okutomi Individual Email: okutomi+ietf@pm.me Okutomi Expires 26 December 2026 [Page 21]