| Internet-Draft | Session-Bound Agent Identity | June 2026 |
| Okutomi | Expires 25 December 2026 | [Page] |
This document describes a profile for binding agent identity and authorization material to an accepted TLS session and to verifier-accepted attestation or channel-binding facts. The profile separates authority statements, holder-of-key session binding, and verifier-local policy so that a relying party accepts an agent only when the grant, session binding, freshness state, and local policy describe the same intended interaction.¶
The profile does not define a new TLS extension, attestation evidence format, identity provider, wallet format, or application protocol. It profiles the use of existing mechanisms, including TLS exporters, exported authenticators, JWT/CWT-style signed claims, proof-of-possession keys, and remote attestation results.¶
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 25 December 2026.¶
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.¶
Automated agents increasingly act across services, tenants, tasks, and delegation boundaries. A transport connection can authenticate an endpoint, and an authorization token can authenticate an authority statement, but an application still needs to know whether those facts describe the same intended interaction.¶
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, and local policy all describe the same intended session, platform, service, agent, task, and authority boundary.¶
The profile is an application-profile acceptance gate. It does not change TLS, exported authenticators, attestation evidence, JWT, CWT, COSE, or OAuth. AGTP, CoCos, and related prototype code are implementation experience and non-normative references only.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when they appear in all capitals.¶
Session-Bound Agent Identity Profile: an application-profile acceptance gate over TLS 1.3, exported authenticators, attestation or channel-binding facts, signed identity material, and verifier-local policy.¶
Identity Grant: an authority statement issued by a Manager or another locally trusted policy authority. It authorizes upper-layer identity, task, and authorization values. It does not prove presence on the current TLS session.¶
Session Binding Statement: a holder-of-key proof that binds one verified Identity Grant to one accepted TLS or exported-authenticator session. It does not authorize service, tenant, task, scope, resource, or capability values.¶
Acceptance decision: returning a peer identity or authorization result to the application as profile-authenticated. Replay state for one-shot bindings is committed before this decision is returned.¶
Wallet: a holder-side presentation component. It can store credentials, protect holder keys, and create or present session-bound material. It is not a trust root for this profile.¶
This profile covers the checks needed before an application treats an accepted TLS peer as the intended platform, service, agent, task, or authorized actor.¶
Out of scope are selecting a specific identity provider, standardizing a new wire-token format, changing attestation evidence formats, changing TLS, proving a complete end-to-end authorization model, and defining generic OAuth, OIDC, JWT, CWT, COSE, DID, or VC behavior except where this profile relies on them for fail-closed acceptance.¶
The profile separates lower-layer session and attestation binding from upper-layer deployment, agent, task, and authorization policy.¶
L0 is the live TLS channel. L1 is attested platform validity. L2 is attestation or authenticator-to-channel binding. L3 is service, tenant, deployment, or environment. L4 is workload, process, or agent. L5 is task, thread, context, or delegation. L6 is authorization or capability policy.¶
L0 through L2 are transport and attestation questions. L3 through L6 require local expected policy.¶
The attacker can observe, replay, reorder, relay, or substitute network and application messages. The attacker can supply malicious peer metadata and can run another agent on the same host or deployment environment.¶
The lower layers are assumed to validate TLS 1.3, exported authenticators, and platform evidence correctly. This profile defines what must be bound to those facts before the application treats the peer as the intended actor.¶
Out of scope are a fully compromised verifier process or local policy store, a malicious trusted Manager, compromise of all local secret storage, denial of service, and side channels outside the identity-binding path.¶
An Identity Grant authorizes upper-layer semantics. It is signed by a Manager or trusted policy authority and identifies the Agent confirmation key, usually through a confirmation-key claim such as cnf.kid.¶
The grant may carry L3 through L6 fields, including service, tenant, deployment, workload, agent, task, delegation, canonical intent or capability references, scopes, resources, and authorization details.¶
The Agent is not the authority for these values. They are accepted only after grant verification and local policy comparison.¶
The normative token guard names are profile_type and profile_version. Legacy adapters MAY expose agtp_type and agtp_version as compatibility aliases, but a verifier MUST NOT treat AGTP names as the authority model.¶
A Session Binding Statement proves that the holder of the confirmation key bound the verified grant to the accepted TLS or exported-authenticator session.¶
It contains at least profile_type, profile_version, aud, jti, iat, exp, grant_hash, leaf_public_key_sha256, tls_exporter_sha256, request_context_sha256, nonce, and attestation_binder_sha256 when accepted attestation-to-channel evidence is present.¶
A verifier MUST NOT compute grant_hash by reserializing JSON in the acceptance path. Canonical CBOR/COSE is acceptable only when the encoding profile fixes the canonical form.¶
grant_hash = SHA-256("sbaip.identity-grant.jwt.v1" || NUL || exact-signed-grant-bytes)
grant_hash = SHA-256("sbaip.identity-grant.cwt.v1" || NUL || exact-signed-grant-bytes)¶
A wallet can store Identity Grants, verifiable credentials, DID references, reference tokens, and confirmation-key material. It can protect the Agent binding key and create or present a Session Binding Statement after a verifier challenge.¶
A wallet is not a trust root for this profile. Wallet UI labels, display names, card fields, credential nicknames, and peer-supplied metadata are not expected policy.¶
Pre-signed wallet presentations are not session-bound by themselves. A presentation that lacks the current aud, nonce, grant_hash, request_context_sha256, and TLS exporter binding MUST NOT be accepted as proof for the current session.¶
This section fixes the direct-Agent L2 construction. A verifier MUST NOT replace these inputs with peer-selected labels, inferred context, display names, or reserialized semantic metadata.¶
The v1 exporter label is the ASCII string Attestation. New profiles SHOULD use a namespaced exporter label. A peer-selected exporter label is never accepted.¶
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)¶
EKM = TLS-Exporter(tls_connection, label = "Attestation", context = context, length = 32) leaf_public_key_sha256 = SHA-256(leaf_spki) tls_exporter_sha256 = SHA-256(EKM) request_context_sha256 = SHA-256(context) attestation_binding = H(leaf_spki || EKM) attestation_binder_sha256 = SHA-256(attestation_binding)¶
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 context, plus the grant hash, audience, nonce, attestation binder when present, and replay state.¶
Acceptance has an authentication phase and a policy phase.¶
The policy phase loads verifier-local expected values, rejects missing or ambiguous expected values, compares observed L3 through L6 values with local policy, and enforces L6 set semantics. Neither an Identity Grant alone nor a Session Binding Statement alone is enough.¶
Decision-sensitive semantic values must be canonical before acceptance. Examples include 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 Manager, 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.¶
Production identity policy has two modes: disabled and required. In required mode, any missing, expired, replayed, unsupported, revoked, non-canonical, or session-inconsistent input is an authentication failure.¶
Required mode enforces Manager trust, algorithm safety, parser safety, audience safety, key separation, grant lifetime, binding-signer authorization, binding-field comparison, replay, and local policy.¶
Legacy agtp_type and agtp_version aliases MAY be accepted only by an adapter that explicitly maps them to profile_type and profile_version. Mixing legacy and current profile guards in one token is rejected unless a compatibility profile defines an exact precedence rule.¶
The accepted assertion expiry is the earliest applicable expiry among grant expiration, Session Binding Statement expiration, attestation-result expiration, evidence challenge lifetime, attestation collateral or TCB lifetime, replay-cache TTL, and local policy maximum TTL.¶
Replay protection is keyed at least over grant_hash, aud, tls_exporter_sha256, request_context_sha256, and nonce.¶
Replay state is committed after signatures, freshness, session binding, and local policy have succeeded, but before the acceptance decision is returned. If the atomic insert fails because the key already exists, the verifier rejects the attempt.¶
Key lookup and key caches MUST be scoped by profile version, token type, issuer, audience, key use, algorithm, key type, kid, key status, and public-key thumbprint. kid is never a global key name.¶
Response caching and security-state caching are different. Verified grants, Session Binding Statements, 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. A shared cache may store a response only when it is invariant across all identity, policy, attestation, and session-binding inputs. Vary is not enough when the decision depends on non-header security state.¶
Identity-binding data can create correlation. Deployments SHOULD prefer audience-scoped identifiers, short lifetimes, selective disclosure, reference tokens, and minimized logs.¶
Diagnostics should preserve the layer, field, and error class, but should not echo raw peer values.¶
In direct-Agent mode, the Agent terminates TLS and signs the Session Binding Statement with the confirmation key named by the verified Identity Grant, or with an endpoint key explicitly authorized by the grant or local policy.¶
Gateway-routed mode is a separate profile. Gateway session binding proves the gateway endpoint, not the final Agent process. The relying party accepts the final Agent only after a Gateway Route Assertion passes local route policy, freshness, replay, and any required final-Agent holder-of-key check.¶
This section is non-normative.¶
One prototype contains a comparator that compares a session-bound observed assertion with verifier-local expected policy. The comparator does not parse wire tokens, verify signatures, choose keys, rotate keys, check revocation, or own distributed replay storage.¶
The same prototype includes JWT/JWS and CWT/COSE adapters. AGTP-named package paths are historical/reference names.¶
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.¶
An implementation claiming this profile needs to evaluate relay, borrowed attestation, token substitution, multiple tasks on one TLS connection, 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.¶
This document has no IANA actions.¶
The profile was informed by implementation work and design feedback from agent-oriented protocol prototypes, including AGTP- and CoCos-related code paths. Those systems are non-normative for this document.¶