| Internet-Draft | Core Agent Identity | June 2026 |
| Okutomi | Expires 27 December 2026 | [Page] |
This document defines a core verifier-side acceptance profile for session-bound Agent identity. 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 TLS extension, attestation evidence format, identity provider, holder-side presentation format, registry, control plane, gateway, or application protocol. Instead, it defines the fail-closed acceptance rule for composing existing Internet mechanisms at the verifier boundary.¶
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 27 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 often combine transport authentication, signed authorization material, platform attestation, and local policy. Each component can verify successfully while the composition still authenticates the wrong session, task, platform, or Agent.¶
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, or HTTP.¶
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 session, request context, replay state, attestation result, and local policy all refer to the same intended interaction.¶
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.¶
This core profile defines verifier behavior before an application treats an accepted TLS peer as the intended platform, service, Agent, task, or authorized actor. It binds accepted TLS and post-handshake attestation facts, authenticated identity and authorization material, and verifier-local expected policy.¶
This document uses "Agent" broadly. The accepted identity can represent a workload, process, service component, or automated actor, 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 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.¶
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, and diagnostic 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, or reserialized semantic metadata is part of the final acceptance path unless a binding profile and local policy explicitly define it.¶
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.¶
This core profile is usable in open Internet and enterprise deployments. 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, 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. 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.¶
When an Agent acts for a Principal, deployment profiles SHOULD support audience-scoped disclosure, short-lived grants, selective disclosure or reference tokens, and Principal-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].¶
This document defines a core verifier acceptance profile for Direct-Agent mode. It 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, exporter label, replay rules, diagnostic behavior, and the items in Section 11.¶
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.¶
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.¶
For Direct-Agent mode, a conforming implementation completes all grant verification, holder-of-key verification, session-binding verification, required attestation checks, freshness checks, replay checks, and local-policy comparisons before returning a profile-authenticated identity or authorization result to the application.¶
A conforming implementation MUST fail closed. It MUST NOT report a profile-authenticated identity from only a verified authority grant, only a session proof, only a TLS endpoint identity, only an attestation result, or only peer-supplied metadata.¶
The labels D0 through D6 are acceptance dimensions used for policy separation and diagnostics. They are not OSI layers, encapsulation layers, wire-format layers, or trust hierarchy levels. The numbering is only a stable diagnostic order. It does not imply that D6 is above D5 or that every deployment evaluates all dimensions.¶
| Dimension | Verification target | Main failure class |
|---|---|---|
| D0 | Live TLS or exported-authenticator session | MITM or session confusion |
| D1 | Attested platform validity, when required | Fake, malformed, stale, or untrusted evidence |
| D2 | Attestation or authenticator-to-session binding | Relay, replay, or borrowed evidence |
| D3 | Service, tenant, deployment, or environment | Wrong service or tenant; context diversion |
| D4 | Workload, process, or Agent | Same-host wrong-Agent confusion |
| D5 | Task, thread, context, or delegation | Wrong task or delegation; context diversion |
| D6 | Authorization or capability policy | Confused deputy or privilege escalation |
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.¶
The attacker can observe, replay, reorder, relay, substitute messages, supply malicious peer metadata, and run another Agent on the same host or deployment environment.¶
This core profile assumes correct TLS 1.3, exported-authenticator validation, 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.¶
Out of scope are a fully compromised verifier process, a malicious trusted policy authority, compromise of all local secret storage, denial of service, and side channels outside the identity-binding path.¶
The main threats are relay, replay, token substitution, stale key use, same-host wrong-Agent confusion, peer-metadata injection, context diversion, confused deputy behavior, cache confusion, and gateway route confusion.¶
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. It contains at least the abstract profile fields below. A binding profile fixes the exact JWT claim names [RFC7519], CWT claim labels, COSE/JWS protected-header requirements, canonical encoding rules, and collision-avoidance rules used on the wire.¶
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;¶
tls_leaf_spki_sha256;¶
tls_exporter_sha256;¶
request_context_sha256;¶
nonce; 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 [RFC7515] 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 signed or MACed COSE object as received and successfully verified. A verifier MUST NOT compute grant_hash by parsing claims and reserializing JSON, CBOR, or COSE in the acceptance path. Deterministic CBOR/COSE is acceptable only when the 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.¶
This section fixes the Direct-Agent D2 construction. A verifier MUST NOT replace these inputs with peer-selected labels, inferred context, display names, or reserialized semantic metadata.¶
Inputs:¶
tls_connection: the accepted TLS 1.3 connection;¶
exporter_label: an application- or deployment-profile-selected TLS exporter label. This document does not define that label;¶
leaf_spki: DER SubjectPublicKeyInfo of the accepted endpoint public key [RFC5280];¶
role, protocol_id, aud, grant_hash, task_context, and verifier_nonce_or_attempt_id from verifier-local state.¶
The exporter label is selected by the application or deployment profile, not by the peer. A verifier MUST NOT accept a peer-selected exporter label. Local experiments can use private-use labels, such as labels beginning with EXPERIMENTAL, as described by [RFC5705]. A generally applicable label can be defined later by another specification and registered according to the TLS Exporter Labels registry procedures updated by [RFC9847].¶
Because the exporter label 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 a stable exporter label and all other wire-visible inputs.¶
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:¶
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.¶
tls_leaf_spki_sha256 confirms the endpoint key, but it is not session unique. The primary session binding is the TLS exporter under the accepted profile context, plus the grant hash, audience, nonce, attestation binder when present, and replay state. This construction uses the TLS exporter interface [RFC8446] to provide the channel-binding property described by [RFC5056] in a profile-specific form; it is not the bare tls-exporter channel-binding value defined by [RFC9266].¶
Accepted attestation evidence or attestation results MUST be appraised against the same attestation_binding_input.¶
A binding profile for a specific attestation evidence format can map this binding input to evidence-specific fields, such as report data or nonce 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.¶
A verifier compares tls_exporter_sha256 and request_context_sha256 with its own accepted values. Missing or mismatched mandatory fields fail closed.¶
Acceptance has an authentication phase, a policy phase, and a replay-commit step.¶
Authentication phase:¶
iat, exp, grant ID, and required authorization fields.¶
grant_hash over the exact verified grant bytes.¶
aud, endpoint-key hash, TLS exporter hash, request-context hash, attestation binder when required or present, and nonce.¶
Policy phase:¶
Replay commit:¶
An implementation MUST NOT expose a profile-authenticated result to the application until it has constructed an internal accepted assertion from verified material and verifier-local policy. Applications consume that accepted assertion. They MUST NOT treat raw peer-provided identity, scope, task, service, tenant, capability, or attestation-related values as accepted identity.¶
Neither an authority grant alone nor a session proof alone is enough. Sender-constraining proves possession and freshness; it does not authorize surplus scopes, resources, capabilities, or authorization details.¶
A minimal positive Direct-Agent case has all of the following:¶
This is a minimum success pattern, not a complete binding profile.¶
The following cases are not exhaustive. They define a minimal rejection-preserving acceptance-case set for binding profiles and implementations.¶
| Case | Required result |
|---|---|
| Valid grant, but TLS exporter hash mismatch | Reject |
| Valid sender-constrained token, but no profile-defined TLS-exporter binding | Reject |
Valid session proof, but grant_hash was computed from reserialized claims |
Reject |
| Valid endpoint identity, but D3 service value is only peer-supplied metadata | Reject |
| Valid attestation result, but not bound to the accepted TLS session | Reject |
| Valid grant with surplus capability not allowed by local policy | Do not expand effective authorization |
| Reused nonce and request context on the same TLS connection for another task | Reject |
| Profile-authenticated identity requested for TLS 0-RTT data | Reject |
The accepted assertion expiry is the earliest applicable expiry among:¶
grant exp, session proof exp, TLS endpoint credential or endpoint-key lifetime, attestation-result exp, evidence challenge lifetime, attestation collateral or TCB lifetime, replay-cache TTL, local policy maximum TTL¶
A missing required freshness policy value fails closed. Evidence without a trusted timestamp is acceptable only for the current challenge and current authentication attempt.¶
TLS resumption creates a new accepted TLS connection for this core 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 || tls_exporter_sha256 || request_context_sha256 || nonce¶
When available, the key also includes the binding statement ID, task-binding value, evidence nonce, verifier challenge, or attestation-result identifier.¶
Key lookup and key caches MUST be scoped by the equivalent of:¶
profile_version || token_type || issuer || audience || key_use || alg || kty || kid || key_status || public_key_thumbprint¶
kid is never a global key name. Unknown, revoked, retired, stale, wrong-use, or ambiguous keys fail closed. Deployments that need early invalidation must support grant revocation, policy-authority-key revocation, and Agent-binding-key revocation separately.¶
Decision-sensitive semantic values must be canonical before acceptance. Common examples are ontology_id, intent_ref, and capability_ref.¶
Receivers MUST NOT repair peer-provided aliases, display labels, natural language phrases, case variants, URI variants, or model interpretations during the final acceptance path. Alias resolution belongs to the policy authority, trusted registry, or local policy engine before issuance or comparison.¶
An alias is acceptable only when it resolves to exactly one canonical reference under a pinned registry namespace and version. Missing, ambiguous, deprecated, or unsupported registry data fails closed.¶
In Direct-Agent mode, the Agent terminates TLS and signs the session proof with the confirmation key named by the verified authority grant, or with an endpoint key explicitly authorized by the grant or local policy.¶
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 route assertion binds the gateway identity, relying-party audience, route, tenant or authority partition, target Agent, request context, nonce, and expiry. Missing, stale, replayed, wrong-route, wrong-tenant, wrong-task, or wrong-Agent assertions fail closed. 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.¶
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, and capability references should not be logged unless needed for security audit. Intermediaries SHOULD receive only the claims and payloads needed for their role.¶
Response caching and security-state caching are different. 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.¶
Verified grants, session proofs, attestation evidence, authorization decisions, and verification results MUST NOT be cached as acceptance evidence for a later session or request. HTTP responses whose contents depend on such state are expected to use cache controls 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.¶
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.¶
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.¶
Implementations need fail-closed parsing for token type, algorithm, key, audience, duplicate claim names, malformed base64url, unsupported nesting, unexpected crit, and typ/cty ambiguity [RFC8725]. A parser that silently accepts duplicate JSON member names or unsupported critical headers is not suitable for this core profile.¶
High-risk hazards fall into three classes:¶
crit, typ/cty ambiguity, malformed base64url, global kid, wrong key use, and parsed or reserialized grant bytes for grant_hash;¶
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 Principals can choose trusted authorities and disclosed claims.¶
This document makes no IANA requests.¶
This core profile does not define a new TLS exporter label. Binding profiles using it are expected to define or select an appropriate application-specific exporter label. Any future generally applicable label is expected to follow the registration procedures for the "TLS Exporter Labels" registry, as updated by [RFC9847].¶