Individual Submission A. Okutomi Internet-Draft Individual Intended status: Informational 1 July 2026 Expires: 2 January 2027 A Core Acceptance Profile for Session-Bound Agent Identity draft-okutomi-session-bound-agent-identity-04 Abstract This document defines a core verifier-side acceptance profile for session-bound Agent identity. Its primary failure class is context diversion: accepting cryptographically valid material for a different service, tenant, Agent, task, delegation, or authority boundary than the verifier intended. A verifier accepts an Agent only when a verified authority grant, holder-of-key proof, accepted TLS or exported-authenticator session, freshness and replay state, any required attestation result, and verifier-local policy all describe the same intended interaction. This document does not define a universal Agent namespace, identity provider, attestation evidence format, holder-side presentation mechanism, control plane, gateway, or complete application protocol. Instead, it defines the fail-closed acceptance rule for composing existing Internet mechanisms at the verifier boundary, and states the requirements that a concrete binding profile has to fix for interoperability. 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 2 January 2027. Okutomi Expires 2 January 2027 [Page 1] Internet-Draft Session-Bound Agent Identity July 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Contribution . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Scope, Non-Goals, and Document Structure . . . . . . . . . . 6 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 6. Core Invariant . . . . . . . . . . . . . . . . . . . . . . . 7 7. Context Diversion . . . . . . . . . . . . . . . . . . . . . . 7 8. Design Intent . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Internet Applicability and Deployment Assumptions . . . . . . 8 10. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acceptance Model . . . . . . . . . . . . . . . . . . . . . . 10 12. Accepted Assertion Output . . . . . . . . . . . . . . . . . . 12 13. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Authority and Key Separation . . . . . . . . . . . . . . . . 13 15. Relationship to WIMSE, OAuth, RATS, and HTTP Message Signatures . . . . . . . . . . . . . . . . . . . . . . . 14 16. Binding Profile Requirements . . . . . . . . . . . . . . . . 16 17. Grant and Authority Material . . . . . . . . . . . . . . . . 19 18. Session Proof Material . . . . . . . . . . . . . . . . . . . 19 19. Direct Session Binding Construction . . . . . . . . . . . . . 21 19.1. Endpoint Roles and leaf_spki . . . . . . . . . . . . . . 21 19.2. Context and Exporter Construction . . . . . . . . . . . 22 19.3. Exported Authenticator Binding . . . . . . . . . . . . . 24 20. Attestation Appraisal and Session Binding . . . . . . . . . . 25 21. Verification Procedure . . . . . . . . . . . . . . . . . . . 26 22. Minimal Positive Acceptance Case . . . . . . . . . . . . . . 28 23. Minimal Negative Acceptance Cases . . . . . . . . . . . . . . 28 24. Freshness, Replay, Rotation, and Revocation . . . . . . . . . 30 25. Canonical Policy Values . . . . . . . . . . . . . . . . . . . 31 26. Internationalization and String Comparison . . . . . . . . . 31 27. Deployment Topologies . . . . . . . . . . . . . . . . . . . . 32 27.1. Direct-Agent Mode . . . . . . . . . . . . . . . . . . . 32 Okutomi Expires 2 January 2027 [Page 2] Internet-Draft Session-Bound Agent Identity July 2026 27.2. Gateway-Routed Mode . . . . . . . . . . . . . . . . . . 32 28. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 29. Caching and Replay-State Reuse . . . . . . . . . . . . . . . 33 30. Operational and Performance Considerations . . . . . . . . . 34 31. Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . 35 32. Security Considerations . . . . . . . . . . . . . . . . . . . 35 33. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 34. Normative References . . . . . . . . . . . . . . . . . . . . 36 35. Informative References . . . . . . . . . . . . . . . . . . . 38 Appendix A. Non-Normative Example: HTTPS Direct-Agent JWS Binding Sketch . . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix B. Non-Normative Context-Encoding Test Vector . . . . . 42 Appendix C. Implementation Repository Relationship . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction Automated agents often combine transport authentication, signed authorization material, platform attestation, and verifier-local policy. Each component can verify successfully while the composition still authenticates the wrong session, task, platform, service, tenant, or Agent. This document treats that failure class as context diversion when cryptographically valid material is accepted for an unintended service, tenant, Agent, task, delegation, or authority boundary. This document defines a deterministic verifier-side acceptance gate. The verifier accepts a peer only when the authenticated identity, session binding, freshness and replay state, any required attestation state, and verifier-local policy describe the same intended interaction. This core profile does not change TLS [RFC8446], exported authenticators [RFC9261], remote attestation roles [RFC9334], JWT/ JWS, CWT/COSE, OAuth, HTTP, or workload identity mechanisms. Existing sender-constraining mechanisms can prove possession of a key, and attestation mechanisms can appraise evidence, but they do not by themselves define the verifier-side rule that the authority grant, live TLS or exported-authenticator session, request context, replay state, attestation result, and local policy all refer to the same intended interaction. The document is intentionally split between a core acceptance profile and binding-profile requirements. The core profile defines the fail- closed invariant. A binding profile fixes the wire representation and protocol-specific inputs that are needed for interoperable implementations. Okutomi Expires 2 January 2027 [Page 3] Internet-Draft Session-Bound Agent Identity July 2026 2. Document Contribution Existing mechanisms provide important inputs to this profile. TLS and exported authenticators provide endpoint and channel facts. JOSE, COSE, JWT, CWT, OAuth sender constraining, RATS, EAT, and HTTP Message Signatures can provide signed claims, proof-of-possession, attestation results, or request-component integrity. This document does not re-specify those mechanisms. Its contribution is the verifier-side acceptance rule that composes those inputs without accepting a valid input in the wrong context. The reusable parts are the Core Invariant, the context-diversion failure model, the D0 through D6 diagnostic dimensions, the exact-byte grant binding, the TLS-exporter context construction, the D3 through D6 verifier-local policy comparison model, and the requirement to commit replay state before exposing a positive result to the application. 3. 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. 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, endpoint role, 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 Session-Bound Agent Identity Profile. It is used in this document's domain-separation strings and examples. It is not an external registry name. Agent Okutomi Expires 2 January 2027 [Page 4] Internet-Draft Session-Bound Agent Identity July 2026 The workload, process, service component, tool runner, automated actor, or agentic runtime whose identity is being accepted by the verifier. 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. 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 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-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, Agent, task, delegation, or authority boundary than the verifier intended. Context diversion is a failure class, not a wire mechanism. Intermediary A gateway, relay, proxy, broker, service on the communication path, or component that terminates transport security for either side. Okutomi Expires 2 January 2027 [Page 5] Internet-Draft Session-Bound Agent Identity July 2026 4. Scope, Non-Goals, and Document Structure This core profile defines verifier behavior before an application treats an accepted peer as the intended platform, service, Agent, task, or authorized actor. It binds accepted TLS or exported- authenticator facts, authenticated identity and authorization material, attestation results when required, and verifier-local expected policy. This document uses Agent broadly. The accepted identity can represent a workload, process, service component, tool runner, automated actor, or agentic runtime, depending on the binding profile and local policy. This document does not require a universal Agent namespace or a common semantic definition of agenthood. The core profile does not select an identity provider, define a general wire-token format, change attestation evidence or TLS, define holder-side presentation behavior, define discovery or rendezvous, or provide a complete authorization framework. A requirement belongs here only if omitting it could cause acceptance of the wrong live session, wrong service or tenant, wrong Agent, wrong task, stale or replayed state, peer-selected policy, or a security result reused outside its intended request. This document is a core acceptance profile. Sections that describe concrete construction inputs are normative for implementations that claim this core profile, but they still do not define an interoperable application protocol without a binding profile that fixes the wire-visible values identified in this document. 5. Applicability Statement This profile is applicable when a verifier has to decide whether a live peer represents the intended Agent for a specific service, tenant, task, delegation, and authorization context, and where that decision composes independently specified transport, token, attestation, and local-policy mechanisms. This profile is most useful when valid credentials or proofs can otherwise be diverted across services, tenants, Agents, tasks, gateways, or authority boundaries. It is not needed when a single application protocol already provides a complete, context-specific identity, authorization, freshness, replay, and attestation-binding decision at the same verifier boundary. Okutomi Expires 2 January 2027 [Page 6] Internet-Draft Session-Bound Agent Identity July 2026 Direct-Agent mode is applicable only when the verifier can compute the TLS exporter for the accepted Agent-to-verifier or exported- authenticator session. Deployments that terminate transport security before that boundary need a separate gateway-routed binding profile. 6. Core Invariant A verifier MUST NOT return a profile-authenticated Agent identity unless the verified authority grant, holder-of-key proof, accepted TLS or exported-authenticator session, 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. 7. Context Diversion Context diversion is the primary failure class addressed by this core profile. It occurs when cryptographically valid authority, proof, session, attestation, or authorization material is accepted for a different service, tenant, Agent, task, delegation, or authority boundary than the verifier intended. Context diversion can occur even when each underlying mechanism verifies successfully. A grant can be valid for one audience while presented to another. A session proof can prove possession for one TLS or exported-authenticator session while being evaluated against a different request context. An attestation result can be valid but borrowed from another session or task. A capability, route, tenant, or task value can be true as metadata while still being the wrong expected value for this verifier interaction. This profile treats peer-provided descriptive values as observed values only. They do not become expected policy unless selected by verifier-local policy or by a binding-profile-defined trusted source. Okutomi Expires 2 January 2027 [Page 7] Internet-Draft Session-Bound Agent Identity July 2026 A verifier prevents context diversion by requiring the verified grant, session proof, accepted TLS or exported-authenticator session, freshness and replay state, attestation result when required, and D3 through D6 local-policy comparisons to describe the same intended interaction. 8. Design Intent This core profile is intentionally conservative. It does not create an Agent namespace, governance layer, registry, rendezvous service, mandatory intermediary, or application semantic model. Its purpose is to make existing Internet mechanisms compose safely at the verifier's acceptance boundary. Application semantics remain with application protocols and deployment profiles. This keeps the core profile usable across deployments without requiring unnecessary centralization or replacement of existing RFC-defined mechanisms. The core profile is not a claim that every deployment has a single global trust root. It is a claim that once a deployment has selected trusted authorities and a binding profile, the verifier has a deterministic fail-closed rule for returning an accepted identity. 9. Internet Applicability and Deployment Assumptions This core profile can be used by open Internet and enterprise deployments that have established local trust paths and binding profiles. Closed-world provisioning and prior bilateral relationships are deployment choices, not protocol requirements. A verifier still requires a local trust path to each issuer, attestation-result signer, trust framework, or other accepted authority; otherwise acceptance fails closed. No globally trusted authority, registry, rendezvous service, gateway, online authority, transparency log, or control plane is required by this document. Such components can be used by a deployment, but they are not trust roots unless local policy says so. Intermediaries are not trusted by default. A component that terminates transport security is a separate relying party and sees only the claims and payloads disclosed to it. A verifier MUST NOT treat an intermediary-authenticated TLS endpoint as the final Agent unless a gateway-routed binding profile and local policy authorize that interpretation. Okutomi Expires 2 January 2027 [Page 8] Internet-Draft Session-Bound Agent Identity July 2026 When an Agent acts 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. These assumptions preserve 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]. 10. Conformance This document defines an Informational core verifier acceptance profile. The capitalized requirements define conformance to this profile; they are not requirements for deployments that do not claim this profile. This document is not, by itself, a complete wire-binding profile. A complete deployment of this core profile requires a binding profile that fixes protocol-specific wire representation, canonicalization rules, endpoint role, exporter label, replay rules, diagnostic behavior, and the required items listed in Section 16. The normative requirements in this document apply only to implementations that claim conformance to this core profile or to a binding profile that incorporates it. There are two conformance subjects: * a verifier implementation, which performs the acceptance checks defined by this document using a selected binding profile and deployment profile; and * a binding profile, which fixes the wire-visible inputs, canonicalization rules, exporter label, endpoint role, replay rules, and diagnostic behavior required by this document. A claim of conformance to this document MUST identify the binding profile being implemented. An implementation that accepts authority grants or session proofs without such a binding profile is not conforming to this core profile. Okutomi Expires 2 January 2027 [Page 9] Internet-Draft Session-Bound Agent Identity July 2026 A conforming verifier 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. A conforming verifier 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 exported-authenticator identity, only an attestation result, or only peer-supplied metadata. A binding profile can define optional features, such as attestation- free operation, exported-authenticator use, gateway-routed mode, or delegated grants. When it does so, it MUST define which checks are absent, which checks remain mandatory, and which negative acceptance cases are added for that feature. A binding profile can add wire- specific details and stricter checks, but it MUST NOT relax the fail- closed acceptance requirements defined by this core profile. 11. Acceptance Model The labels D0 through D6 are acceptance dimensions used for policy separation and diagnostics. They are not protocol layers, encapsulation layers, OSI layers, wire-format layers, or trust- hierarchy levels. The numbering is a stable diagnostic order only. It does not imply that one dimension depends on, contains, or ranks above another, or that every deployment evaluates all dimensions. Okutomi Expires 2 January 2027 [Page 10] Internet-Draft Session-Bound Agent Identity July 2026 +===========+==========================+=========================+ | 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, tool | Same-host wrong-Agent | | | runner, or 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. Remote attestation is optional in this core profile. When local policy or a binding profile does not require attestation, D1 and the attestation-specific part of D2 are not evaluated. The remaining session-binding, freshness, replay, grant, and local-policy checks still apply. Okutomi Expires 2 January 2027 [Page 11] Internet-Draft Session-Bound Agent Identity July 2026 +===========+===================================================+ | Dimension | Binding-profile requirement | +===========+===================================================+ | D3 | Define the trusted source and canonical form of | | | expected service, tenant, deployment, and | | | environment values. | +-----------+---------------------------------------------------+ | D4 | Define the canonical workload or Agent identifier | | | and how it is distinguished from host, endpoint, | | | gateway, 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 capability-set comparison, requested- | | | capability handling, deny overrides, and whether | | | surplus observed capabilities are ignored or | | | rejected. | +-----------+---------------------------------------------------+ Table 2 12. Accepted Assertion Output The output of a successful verification is one internal accepted assertion. This assertion is produced by the verifier from verified material and verifier-local policy; it is not a peer-provided token or a re-labeled input claim. The accepted assertion contains the values that the application is allowed to consume as profile-authenticated, such as the selected binding profile and version, issuer and audience, canonical Agent identifier, endpoint role, grant hash, session-binding hashes, request-context hash, replay key or nonce reference, accepted D3 through D6 values, attestation result reference when used, expiry, and effective authorization. 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. Okutomi Expires 2 January 2027 [Page 12] Internet-Draft Session-Bound Agent Identity July 2026 13. Threat Model The attacker can observe, replay, reorder, relay, substitute messages, supply malicious peer metadata, and run another Agent on the same host or deployment environment. The attacker can also attempt to make the verifier compose individually valid grants, proofs, sessions, attestation results, route assertions, and request metadata across context boundaries. This core profile assumes correct TLS 1.3, exported-authenticator validation, signature or MAC verification, and evidence appraisal by the underlying mechanisms. It defines what must be bound to those facts before an application accepts the peer as the intended actor. The primary attacker goal is context diversion: causing cryptographically valid material for one service, tenant, Agent, task, delegation, route, or authority boundary to be accepted for another. Examples include service or tenant diversion, wrong-Agent acceptance on the same host, wrong-task or wrong-delegation acceptance, gateway-route diversion, borrowed attestation results, and acceptance of natural-language or display metadata as policy. A common verifier failure is treating peer-provided metadata as expected policy, or returning an accepted identity after only one component succeeds. Examples include accepting a grant without the live session proof, accepting a session proof without D3 through D6 policy comparison, accepting an endpoint TLS identity as final-Agent identity, or returning a positive application result before replay state is committed. 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, endpoint-role confusion, exported-authenticator confusion, borrowed or replayed attestation, gateway route confusion, and cross-profile or cross-protocol confusion. 14. Authority and Key Separation This core profile separates three key roles: the TLS endpoint key proves possession for the accepted TLS or exported-authenticator endpoint; the Agent binding key signs the session proof; and the policy-authority key signs authority grants. Okutomi Expires 2 January 2027 [Page 13] Internet-Draft Session-Bound Agent Identity July 2026 Key roles establish authenticated facts; they do not own, contain, or rank the D0 through D6 acceptance dimensions. The TLS endpoint key contributes to D0 endpoint authentication and to D2 session binding when the binding profile uses leaf_spki and the TLS exporter context. It is not, by itself, a D4 Agent identity and does not satisfy D3 service, D5 task, or D6 authorization policy. The Agent binding key proves possession of the confirmation key for the session proof. It contributes to D2 grant-to-session binding, and it supports D4 Agent acceptance only when the verified grant or verifier-local policy maps that key to a canonical Agent identifier. The policy-authority key authenticates authority grants and supplies observed values for policy comparison. It does not prove live- session possession or TLS endpoint identity. These roles 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. The protected-header kid is only a key-selection hint. The selected binding profile defines the applicable token-validation, key-use, time-validity, revocation, profile, and local-policy checks. JWT- or JWS-based encodings also follow the JWT Best Current Practices in [RFC8725]. The accepted endpoint public key and the Agent binding key can be the same key only when a binding profile and local policy explicitly allow that role combination. Otherwise, a verifier MUST treat equality of key material as an implementation detail that does not collapse the required key-role checks. 15. Relationship to WIMSE, OAuth, RATS, and HTTP Message Signatures Workload Identity in Multi-Service Environments (WIMSE) discusses architectures and mechanisms for workload identity and security context in multi-service and multi-system environments [I-D.ietf-wimse-arch]. WIMSE work on workload credentials, mutual TLS, workload proof tokens, workload identifiers, and HTTP signatures provides mechanisms that can be used by binding profiles [I-D.ietf-wimse-workload-creds] [I-D.ietf-wimse-mutual-tls] [I-D.ietf-wimse-wpt] [I-D.ietf-wimse-identifier] [I-D.ietf-wimse-http-signature]. Okutomi Expires 2 January 2027 [Page 14] Internet-Draft Session-Bound Agent Identity July 2026 The WIMSE references in this section are informative only. They describe related work and possible binding-profile mechanisms; they are not required in order to implement this core profile. This document is complementary to those mechanisms. It focuses on the verifier-side invariant for accepting an Agent identity only when the authority grant, holder-of-key proof, live session, task context, replay state, attestation result when required, and local policy all bind to the same intended interaction. +==============+======================+============================+ | Mechanism | What it can provide | What this profile adds | +==============+======================+============================+ | WIMSE | Workload | Fail-closed composition of | | workload | identifiers, | workload or Agent identity | | identity | credentials, and | with session, task, | | | authentication | attestation, replay, and | | | patterns. | verifier-local policy. | +--------------+----------------------+----------------------------+ | WIMSE | Application-level | A required check that | | Workload | proof of possession | proof, grant, TLS or | | Proof Token | for workload | exported-authenticator | | | credentials. | session, request context, | | | | and policy describe the | | | | same interaction. | +--------------+----------------------+----------------------------+ | HTTP Message | Request and response | Profile-level requirements | | Signatures | signing over | for what the signed | | | selected HTTP | material must be bound to | | | components | before identity | | | [RFC9421]. | acceptance. | +--------------+----------------------+----------------------------+ | OAuth sender | Proof-of-possession | TLS-exporter, request- | | constraining | or certificate-bound | context, replay, | | | tokens, depending on | attestation-to-session, | | | the OAuth profile | and D3-D6 local-policy | | | [RFC8705] [RFC9449]. | composition requirements. | +--------------+----------------------+----------------------------+ | RATS and EAT | Evidence appraisal, | A rule that accepted | | | attestation result | attestation evidence or | | | representation, and | results are bound to the | | | tokenized claims | accepted session and task | | | [RFC9334] [RFC9711]. | before Agent identity | | | | acceptance. | +--------------+----------------------+----------------------------+ Table 3 Okutomi Expires 2 January 2027 [Page 15] Internet-Draft Session-Bound Agent Identity July 2026 A binding profile can reuse any of these mechanisms. Reuse does not remove the need to perform the acceptance checks defined by this document. 16. Binding Profile Requirements This core profile does not define a new authority-token format, proof-token format, HTTP header, error format, or attestation evidence format. A binding profile fixes the exact wire representation and canonicalization needed to instantiate this core profile over a specific application protocol or deployment profile. Binding profiles may use wallet-based or non-wallet holder-side presentation mechanisms. This core profile only specifies the verifier-side acceptance rule and does not require or define such a presentation mechanism. This core profile does not require a particular attestation presentation point. Attestation material can be presented post- handshake, out of band, through an exported-authenticator-based mechanism, or through another binding-profile-defined mechanism. This document only requires that any attestation evidence or attestation result used for acceptance is appraised under local policy and bound to the accepted TLS or exported-authenticator session. A binding profile that uses this document MUST define the following values. +=========================================+========================+ | Required item | Prevents | +=========================================+========================+ | profile identifier and version | cross-profile | | | confusion | +-----------------------------------------+------------------------+ | protocol_id and application-protocol | cross-protocol replay | | scope | or substitution | +-----------------------------------------+------------------------+ | accepted endpoint role and proof-signer | client/server/ | | role | exported-authenticator | | | role confusion | +-----------------------------------------+------------------------+ | source of leaf_spki for each accepted | wrong certificate or | | endpoint role | authenticator binding | +-----------------------------------------+------------------------+ | TLS exporter label and context | peer-selected or | | construction | colliding channel | | | bindings | Okutomi Expires 2 January 2027 [Page 16] Internet-Draft Session-Bound Agent Identity July 2026 +-----------------------------------------+------------------------+ | canonical aud form and audience- | audience confusion | | comparison rules | | +-----------------------------------------+------------------------+ | exact bytes used for grant_hash | parse-and-reserialize | | | substitution | +-----------------------------------------+------------------------+ | authority-grant token type, alg allow- | algorithm, type, and | | list, and protected-header rules | key-use confusion | +-----------------------------------------+------------------------+ | session-proof encoding and protected- | algorithm, type, and | | header rules | key-use confusion | +-----------------------------------------+------------------------+ | extension, unknown-field, and critical- | unsupported extension | | field processing rules | acceptance | +-----------------------------------------+------------------------+ | task_context and request-context | wrong-task acceptance | | construction | | +-----------------------------------------+------------------------+ | nonce generation, lifetime, replay-key | replay and cross-task | | construction, and replay-cache | reuse | | consistency requirement | | +-----------------------------------------+------------------------+ | TLS resumption and 0-RTT handling | stale proof reuse and | | | early-data acceptance | +-----------------------------------------+------------------------+ | attestation requirement, evidence | borrowed or replayed | | mapping, appraisal source, freshness, | evidence | | audience, and session-binding rule | | +-----------------------------------------+------------------------+ | verifier-local source and comparison | peer-selected policy | | rules for D3 through D6 expected values | | +-----------------------------------------+------------------------+ | string encoding, normalization, and | alias, display-name, | | comparison rules for non-ASCII | and confusable-string | | decision-sensitive values, when allowed | confusion | +-----------------------------------------+------------------------+ | delegated, exchanged, or derived | authority expansion | | authority-grant constraints, when used | across delegation | +-----------------------------------------+------------------------+ | intermediary and gateway-route | gateway identity | | assertion rules, when gateways are used | accepted as final- | | | Agent identity | +-----------------------------------------+------------------------+ | diagnostic error classes and disclosure | leakage of attacker- | | limits | controlled values | +-----------------------------------------+------------------------+ Okutomi Expires 2 January 2027 [Page 17] Internet-Draft Session-Bound Agent Identity July 2026 Table 4 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 accepted assertion, replay key, verifier-local expected values, or effective authorization. A profile-version update that changes any decision-sensitive input, canonicalization rule, exporter label, replay-key construction, endpoint-role rule, or D3 through D6 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. Because the exporter label, endpoint role, and other wire-visible inputs are protocol-specific, two implementations do not interoperate by implementing this core profile alone. Interoperability requires a binding profile that selects stable wire representations, canonicalization rules, exporter label, replay rules, and diagnostic behavior. OAuth deployments [RFC6749] can reuse token exchange [RFC8693], mutual-TLS certificate-bound access tokens [RFC8705], DPoP [RFC9449], and related OAuth profiles where those models fit. Those mechanisms provide delegation, token exchange, or proof-of-possession properties; they do not replace this profile's verifier-side requirement that the grant, session proof, TLS or exported- authenticator session, replay state, task context, attestation result when required, and local policy describe the same intended interaction. An HTTP binding profile SHOULD reuse the HTTP Message Signatures component model in [RFC9421] and Digest Fields in [RFC9530] for request-component and content-digest selection, rather than defining a competing HTTP canonicalization scheme. Structured Field Values [RFC9651] and Problem Details [RFC9457] can be reused for field encoding and error representation. Tokenized attestation claims can use EAT [RFC9711] within the RATS model [RFC9334]; this document does not redefine evidence formats, appraisal procedures, or attestation- token validation. Okutomi Expires 2 January 2027 [Page 18] Internet-Draft Session-Bound Agent Identity July 2026 17. Grant and Authority Material An authority grant authorizes application semantics. 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, usually through a confirmation-key claim such as cnf.kid for JWT [RFC7519] secured with JWS [RFC7515] and JWT confirmation methods [RFC7800], or the corresponding CWT confirmation method [RFC8747]. 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 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. 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 D6 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. 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. 18. Session Proof Material A session proof proves that the holder of the confirmation key bound the verified grant to the accepted TLS session, or to an exported authenticator accepted for that session. Okutomi Expires 2 January 2027 [Page 19] Internet-Draft Session-Bound Agent Identity July 2026 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; * tls_leaf_spki_sha256; * tls_exporter_sha256; * request_context_sha256; * nonce or verifier attempt identifier; and * attestation_binder_sha256 when local policy requires attestation or when accepted attestation-to-session 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: 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. 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. Okutomi Expires 2 January 2027 [Page 20] Internet-Draft Session-Bound Agent Identity July 2026 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 [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. 19. 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, natural-language descriptions, or reserialized semantic metadata. A binding profile MUST identify the accepted endpoint role. At minimum, the role definition has to say whether the accepted endpoint public key is taken from a TLS server certificate, a TLS client certificate, or an exported-authenticator certificate. 19.1. Endpoint Roles and leaf_spki The field leaf_spki is the DER SubjectPublicKeyInfo of the accepted endpoint public key [RFC5280]. It is not a generic reference to whichever certificate happens to be visible to the implementation. A Direct-Agent binding profile MUST define one or more endpoint roles and the exact source of leaf_spki for each role. Okutomi Expires 2 January 2027 [Page 21] Internet-Draft Session-Bound Agent Identity July 2026 +================+========================+======================+ | Endpoint role | leaf_spki source | Typical verifier | | | | view | +================+========================+======================+ | client-tls- | The accepted TLS | The verifier is a | | endpoint | client certificate | server using mTLS. | | | public key | | +----------------+------------------------+----------------------+ | server-tls- | The accepted TLS | The verifier is a | | endpoint | server certificate | client accepting a | | | public key | server-side Agent. | +----------------+------------------------+----------------------+ | exported- | The accepted exported- | The verifier accepts | | authenticator- | authenticator | a post-handshake | | endpoint | certificate public key | authenticator for | | | | the TLS connection. | +----------------+------------------------+----------------------+ Table 5 The role field included in the context MUST distinguish at least the endpoint role and the binding profile. A binding profile SHOULD use stable, collision-resistant role strings, such as profile-scoped ASCII tokens. If TLS termination, a service mesh, or a gateway prevents the verifier from obtaining the exporter value for the Agent-to-verifier session, Direct-Agent mode is not applicable. Such deployments need a gateway-routed binding profile as described in Section 27.2. tls_leaf_spki_sha256 is a D0 endpoint-identity input and a D2 binding input. It confirms the accepted endpoint public key for the selected endpoint role, 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. It is not a D4 Agent identity by itself and does not satisfy D3, D5, or D6 policy unless a binding profile and verifier- local policy explicitly map that endpoint role or key to those dimensions. 19.2. Context and Exporter Construction Inputs: * tls_connection: the accepted TLS 1.3 connection; * exporter_label: an application- or binding-profile-selected TLS exporter label; Okutomi Expires 2 January 2027 [Page 22] Internet-Draft Session-Bound Agent Identity July 2026 * leaf_spki: DER SubjectPublicKeyInfo of the accepted endpoint public key; and * 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 binding 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 2 January 2027 [Page 23] Internet-Draft Session-Bound Agent Identity July 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) tls_leaf_spki_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. 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]. 19.3. Exported Authenticator Binding When an exported authenticator is used, the verifier MUST validate the exported authenticator according to [RFC9261] 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; Okutomi Expires 2 January 2027 [Page 24] Internet-Draft Session-Bound Agent Identity July 2026 * 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. 20. Attestation Appraisal and Session Binding This document uses the RATS roles and conceptual messages defined by [RFC9334]. It does not define an evidence format, appraisal procedure, or attestation-token profile. 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-session value derived from that input. A binding profile for a specific attestation evidence format can map this binding input to evidence-specific fields, such as report data, nonce, challenge, or external data fields. For example, such a profile can derive: report_data = SHA-512(attestation_binding_input) evidence_nonce = SHA-256("SBAIP-EVIDENCE-NONCE-v1" || NUL || EKM) 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-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. Okutomi Expires 2 January 2027 [Page 25] Internet-Draft Session-Bound Agent Identity July 2026 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-session binding. A verifier MUST reject an attestation result whose audience, freshness, appraisal policy, or session binding is missing or inconsistent with local policy. A verifier compares tls_exporter_sha256 and request_context_sha256 with its own accepted values. Missing or mismatched mandatory fields fail closed. 21. 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 and endpoint role from verifier-local policy and authenticated profile fields. 4. Verify the session proof under the Agent confirmation key or an explicitly authorized endpoint key. 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 context and exporter-derived values. 9. Compare aud, endpoint-role value, endpoint-key hash, TLS exporter hash, request-context hash, attestation binder when required or present, and nonce. 10. Appraise required attestation evidence or verify a trusted attestation result, and verify result-to-session binding. Okutomi Expires 2 January 2027 [Page 26] Internet-Draft Session-Bound Agent Identity July 2026 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 D6 value with local expected policy using binding-profile comparison rules. 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. 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. A positive result exposed to an application is one internal accepted assertion built from verified material and local policy. Applications consume that assertion. They MUST NOT treat raw peer- provided identity, scope, task, service, tenant, capability, or attestation values as profile-authenticated identity. Neither an authority grant alone nor a session proof alone is enough. Sender constraining proves possession, and freshness when the selected profile defines it; it does not authorize surplus scopes, resources, capabilities, or authorization details. Okutomi Expires 2 January 2027 [Page 27] Internet-Draft Session-Bound Agent Identity July 2026 22. Minimal Positive Acceptance Case A minimal positive Direct-Agent case is one in which the verifier has all of the following before returning a profile-authenticated identity or authorization result: * a binding profile selected by local policy and authenticated profile fields; * a verified authority grant from a trusted policy authority; * a session proof signed by the Agent confirmation key or by an endpoint key explicitly authorized by the verified grant or local policy; * an accepted endpoint role and recomputed leaf_spki for that role; * a recomputed grant_hash over the exact verified grant bytes; * a recomputed TLS exporter hash and request-context hash that match the session proof; * a fresh nonce or attempt identifier that has not been previously accepted for the replay key; * matching audience, endpoint-role value, endpoint-key hash, grant hash, request-context hash, and required attestation binder; * accepted attestation appraisal or attestation result when local policy requires it; and * verifier-local policy that accepts the observed D3 through D6 values required for the request. This case is illustrative. Binding profiles can define additional required fields, stricter freshness rules, smaller authorization sets, or additional rejection cases. 23. Minimal Negative Acceptance Cases The following cases are not exhaustive. They define a minimal rejection-preserving acceptance-case set for binding profiles and implementations. Okutomi Expires 2 January 2027 [Page 28] Internet-Draft Session-Bound Agent Identity July 2026 +==========================================+=====================+ | Case | Required result | +==========================================+=====================+ | Valid grant, but TLS exporter hash | Reject | | mismatch | | +------------------------------------------+---------------------+ | Valid sender-constrained token, but no | Reject | | profile-defined TLS-exporter binding | | +------------------------------------------+---------------------+ | Valid session proof, but grant_hash was | Reject | | computed from reserialized claims | | +------------------------------------------+---------------------+ | Valid endpoint identity, but D3 service | Reject | | value is only peer-supplied metadata | | +------------------------------------------+---------------------+ | Valid endpoint key, but endpoint role is | Reject | | not the role selected by local policy | | +------------------------------------------+---------------------+ | Valid exported authenticator, but it is | Reject | | accepted for a different TLS connection | | +------------------------------------------+---------------------+ | Valid attestation result, but not bound | Reject | | to the accepted TLS or exported- | | | authenticator session | | +------------------------------------------+---------------------+ | Local policy requires attestation, but | Reject | | proof is channel-binding-only | | +------------------------------------------+---------------------+ | Valid grant with surplus capability not | Do not expand | | allowed by local policy | effective | | | authorization | +------------------------------------------+---------------------+ | Reused nonce and request context on the | Reject | | same TLS connection for another task | | +------------------------------------------+---------------------+ | Replay cache unavailable for a one-shot | Reject unless local | | non-idempotent acceptance | policy defines a | | | safer failure mode | +------------------------------------------+---------------------+ | Profile-authenticated identity requested | Reject | | for TLS 0-RTT data | | +------------------------------------------+---------------------+ | Gateway-authenticated endpoint presented | Reject | | as final-Agent identity without a | | | gateway-routed binding profile | | +------------------------------------------+---------------------+ Table 6 Okutomi Expires 2 January 2027 [Page 29] Internet-Draft Session-Bound Agent Identity July 2026 24. 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; * replay-cache TTL; and * 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: grant_hash || aud || endpoint_role || tls_exporter_sha256 || request_context_sha256 || nonce When available, the key also includes the binding statement ID, task- binding value, evidence nonce, verifier challenge, exported- authenticator object hash, route assertion ID, or attestation-result identifier. Key lookup and key caches MUST be scoped by the equivalent of: Okutomi Expires 2 January 2027 [Page 30] Internet-Draft Session-Bound Agent Identity July 2026 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 need grant revocation, policy-authority-key revocation, Agent-binding-key revocation, and endpoint-key revocation separately. 25. Canonical Policy Values 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 D6 expected values unless a binding profile and local policy define a deterministic canonicalization and approval path. 26. Internationalization and String Comparison 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 D6 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. Okutomi Expires 2 January 2027 [Page 31] Internet-Draft Session-Bound Agent Identity July 2026 27. Deployment Topologies 27.1. Direct-Agent Mode In Direct-Agent mode, the Agent or Agent endpoint participates in the accepted TLS or exported-authenticator session 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. Direct-Agent mode requires that the verifier can compute the TLS exporter for the accepted session. If a gateway, service mesh, reverse proxy, or load balancer terminates TLS before the verifier boundary where identity is accepted, Direct-Agent mode does not by itself authenticate the final Agent. 27.2. Gateway-Routed Mode Gateway-routed deployments are separate binding profiles. This section gives requirements for avoiding misinterpretation of gateway authentication as final-Agent authentication; it does not define a complete gateway-routed binding profile. Gateway authentication proves the gateway endpoint, not the final Agent. A verifier MUST NOT accept a final Agent identity through a gateway unless a binding profile defines route assertions, final- Agent 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 Agent-to-gateway, gateway-to- verifier, both, or another authenticated transport path; * whether final-Agent 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, target Agent, request 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 Okutomi Expires 2 January 2027 [Page 32] Internet-Draft Session-Bound Agent Identity July 2026 * how local policy rejects missing, stale, replayed, wrong-route, wrong-tenant, wrong-task, or wrong-Agent 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 [RFC8693] when applicable. 28. 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. 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. 29. Caching and Replay-State Reuse 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. This document does not change HTTP caching semantics. It states that security state from this core profile is not reusable acceptance evidence for a later request or session. HTTP responses whose contents depend on such state are expected to use cache controls Okutomi Expires 2 January 2027 [Page 33] Internet-Draft Session-Bound Agent Identity July 2026 appropriate to that sensitivity. The default for profile-sensitive HTTP responses is no-store [RFC9111]. Vary is not enough when the decision depends on non-header security state. 30. Operational and Performance Considerations Binding profiles can select which dimensions are required by local policy. For example, a deployment profile can define an attestation- free fast path when platform appraisal is not required, while still enforcing grant verification, session binding, freshness, replay protection, and local-policy comparison. A verifier MUST NOT silently downgrade an attestation-required interaction to an attestation-free interaction. 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 session. Short-lived grants, bounded local key-status caches, precomputed hashes, and local policy caches can reduce latency. Deployments that require early invalidation still need revocation or equivalent key- status mechanisms for policy-authority keys, Agent binding keys, and endpoint keys. 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. 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 should occur before the application observes a positive acceptance decision. If an application side effect occurs before replay commit, the deployment needs compensating controls for duplicate side effects. Okutomi Expires 2 January 2027 [Page 34] Internet-Draft Session-Bound Agent Identity July 2026 31. Diagnostics 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. Diagnostic error classes SHOULD be stable enough to support conformance tests for D0 through D6 failures, replay failures, and context-diversion failures. The external diagnostic response SHOULD avoid revealing whether a guessed issuer, key identifier, tenant, task reference, route, or capability reference exists. 32. Security Considerations The security of this core profile depends on preserving the Core Invariant before returning a profile-authenticated identity to the application. Partial verification is not enough. JWT- or JWS-based binding profiles MUST follow the JWT Best Current Practices in [RFC8725]. This includes issuer and subject validation, audience validation, not trusting received claims as policy, explicit typing when applicable, algorithm verification, mutually exclusive validation rules for different token types, and rejection of tokens whose validation rules do not match this profile. This profile adds two stricter requirements: grant_hash is computed over the exact verified grant bytes, not over parsed and reserialized claims, and received claims remain observed values until the D3 through D6 verifier-local policy comparison succeeds. TLS deployments that use this profile also rely on the TLS 1.3 specification in [RFC8446] and the general TLS deployment recommendations in [RFC9325]. This profile adds channel-binding and context-composition requirements; it does not update TLS. High-risk hazards fall into three classes: * token and key-selection hazards: failure to apply the selected binding profile's validation rules, unsupported critical extensions, global kid, wrong key use, and parsed or reserialized grant bytes for grant_hash; Okutomi Expires 2 January 2027 [Page 35] Internet-Draft Session-Bound Agent Identity July 2026 * binding hazards: peer-selected exporter label, wrong endpoint role, wrong leaf_spki source, TLS resumption, 0-RTT, multiplexed or reused application request contexts without a fresh task binding, distributed replay-cache races, exported-authenticator confusion, and borrowed attestation; and * policy hazards: peer metadata as expected policy, alias repair, natural-language interpretation as policy, surplus capability expansion, endpoint authentication treated as Agent authorization, and gateway route confusion. Gateway mode, when used, authenticates the gateway endpoint and the gateway-to-Agent route separately. A gateway, relay, registry, or transparency service is a deployment component, not a trust root unless local policy says so. Deployment profiles should evaluate what is exposed to intermediaries, whether mandatory gatekeeping or monitoring is introduced, and whether persons or organizations can choose trusted authorities and disclosed claims. 33. IANA Considerations This document makes no IANA requests. This core profile does not define a new TLS exporter label. Binding profiles or protocols using this core profile define or select an application-specific exporter label. Any future generally applicable label follows the registration procedures for the TLS Exporter Labels registry, as updated by [RFC9847]. 34. 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, . [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, . Okutomi Expires 2 January 2027 [Page 36] Internet-Draft Session-Bound Agent Identity July 2026 [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, . [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, . [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, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [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, . Okutomi Expires 2 January 2027 [Page 37] Internet-Draft Session-Bound Agent Identity July 2026 [RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 2022, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 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, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . 35. 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, . Okutomi Expires 2 January 2027 [Page 38] Internet-Draft Session-Bound Agent Identity July 2026 [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, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [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, . [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, . [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, . [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, . Okutomi Expires 2 January 2027 [Page 39] Internet-Draft Session-Bound Agent Identity July 2026 [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, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-07, 2 March 2026, . [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-01, 5 May 2026, . [I-D.ietf-wimse-mutual-tls] Salowey, J. A. and Y. Rosomakho, "Workload Authentication Using Mutual TLS", Work in Progress, Internet-Draft, draft-ietf-wimse-mutual-tls-01, 5 May 2026, . [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-01, 2 March 2026, . Okutomi Expires 2 January 2027 [Page 40] Internet-Draft Session-Bound Agent Identity July 2026 [I-D.ietf-wimse-identifier] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-02, 2 March 2026, . [I-D.ietf-wimse-http-signature] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-03, 7 April 2026, . Appendix A. Non-Normative Example: HTTPS Direct-Agent JWS Binding Sketch This appendix is non-normative. It illustrates one possible HTTPS Direct-Agent deployment pattern. It is not a complete binding profile for conformance unless a future specification normatively fixes the values shown here. In this example, a binding profile uses an accepted TLS 1.3 connection, a compact JWS authority grant, a compact JWS session proof, a binding-profile-selected TLS exporter label, a verifier nonce, and a verifier-local task context. 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 [RFC9421] and [RFC9530], included in task_context; and * Problem Details [RFC9457] error responses with coarse diagnostic classes. This appendix does not restate the normative verifier algorithm or the minimal rejection cases. The Verification Procedure, Minimal Positive Acceptance Case, and Minimal Negative Acceptance Cases sections define that behavior. This sketch only shows the HTTPS/JWS- specific inputs that a future binding profile would need to fix. Okutomi Expires 2 January 2027 [Page 41] Internet-Draft Session-Bound Agent Identity July 2026 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 selection follows verifier-local policy and authenticated profile fields; * task_context is constructed from the HTTP Message Signatures components and Digest Fields chosen by the binding profile; * the exporter label is selected by the binding profile, not by the peer; * request_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. This sketch intentionally does not define stable HTTP field names, canonicalization rules, exporter labels, error formats, or replay- cache semantics. A conforming HTTPS binding profile has to define those values explicitly. Appendix B. Non-Normative Context-Encoding Test Vector This appendix gives a deterministic context-encoding test vector. 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: Okutomi Expires 2 January 2027 [Page 42] Internet-Draft Session-Bound Agent Identity July 2026 role = "client-tls-endpoint" protocol_id = "https-jws-direct" aud = "https://verifier.example/api" grant_hash = 000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f task_context = "task:v1:transfer#123" verifier_nonce_or_attempt_id = "nonce-123" leaf_spki = 53504b49 ; ASCII "SPKI" for this test only EKM = 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f Line breaks in the following hex values are for display only. Expected context hex: 53424149502d434f4e544558542d7631000004726f6c6500000013636c69656e 742d746c732d656e64706f696e74000b70726f746f636f6c5f69640000001068 747470732d6a77732d64697265637400036175640000001c68747470733a2f2f 76657269666965722e6578616d706c652f617069000a6772616e745f68617368 00000020000102030405060708090a0b0c0d0e0f101112131415161718191a1b 1c1d1e1f000c7461736b5f636f6e74657874000000147461736b3a76313a7472 616e7366657223313233001c76657269666965725f6e6f6e63655f6f725f6174 74656d70745f6964000000096e6f6e63652d313233 Expected hashes: request_context_sha256 = e86170c58c98b3a3bab3730b893354e029fb857e462e0936600819a18530fcfe tls_leaf_spki_sha256 = 0eabce0bf771c5036457802bab1dded04e5668664206847f7ce0375a476c7972 tls_exporter_sha256 = 72dbb7336c76780023f83da4c355f2eeea85733b13d3477697917790c1229084 attestation_binder_sha256 = c266f31e94ec89b0f5a96b34f236aa6c463f6dfcf1d81976f2acbef2a9d77fc2 Appendix C. Implementation Repository Relationship An implementation repository can provide experimental binding profiles, test vectors, reference verifier logic, and examples. Such repository contents are non-normative unless incorporated into a binding-profile specification. This core profile remains independent of any particular repository, HTTP header, token encoding, wallet mechanism, attestation evidence format, or implementation language. Okutomi Expires 2 January 2027 [Page 43] Internet-Draft Session-Bound Agent Identity July 2026 If an implementation repository provides an experimental binding profile, it should state which Internet-Draft version it follows, which binding-profile inputs it fixes, whether TLS exporter values are obtained from a real accepted TLS connection or from deterministic test inputs, and which negative acceptance cases are covered by tests. Author's Address Akira Okutomi Individual Email: okutomi+ietf@pm.me Okutomi Expires 2 January 2027 [Page 44]