| Internet-Draft | AAuth-Bootstrap | September 2026 |
| Hardt | Expires 1 April 2027 | [Page] |
This document provides informational guidance for agent providers (APs) on enrolling agents and issuing AAuth agent tokens defined in [I-D.hardt-oauth-aauth-protocol]. It covers per-platform key handling, optional platform attestation, agent identifier strategies, and refresh patterns. The mechanisms described here are not normative protocol — they are common patterns that interoperable AP implementations can adopt or adapt.¶
Note: This section is to be removed before publishing as an RFC.¶
This document is part of the AAuth specification family. Source for this draft and an issue tracker can be found at https://github.com/dickhardt/AAuth.¶
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 1 April 2027.¶
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.¶
The AAuth Protocol [I-D.hardt-oauth-aauth-protocol] establishes that every agent has its own cryptographic identity — an agent identifier of the form aauth:local@domain, bound to a signing key, and attested by an agent token issued by an agent provider (AP). The protocol defines the agent token format and where the agent presents it: always to its person server (PS), which passes it to an access server (AS) when it federates, and to a resource only in agent identity and resource-managed access ([I-D.hardt-oauth-aauth-protocol], Keying Material). It does not specify how an agent comes to hold an agent token in the first place. That step is bootstrap, and it is the subject of this document.¶
Bootstrapping is the AP-side ceremony by which an instance of an agent acquires an agent token. The agent generates a signing key on the device or in the browser where it will run, presents whatever evidence the AP requires (a signed-in account, an attested device, a published JWKS, etc.), and receives an agent token whose cnf.jwk is bound to that key and whose sub is an aauth:local@domain identifier the AP has chosen.¶
After bootstrap the agent can participate in AAuth: it can sign HTTP messages per [I-D.hardt-httpbis-signature-key], identify itself at resources, and present its agent token to a PS so the user can bind the agent to themselves on first interaction.¶
sub claim's local part Section 6.¶
Throughout, when this document refers to "the durable key" and "the ephemeral key" it means the keys defined in Section 4. The ephemeral key's public part appears in agent_token.cnf.jwk and signs HTTP messages from the agent per [I-D.hardt-httpbis-signature-key]; the durable key serves as the AP's stable enrollment anchor and signs only at refresh. APs that use a single durable key for all signatures Section 4 can read references to "the ephemeral key" as referring to that same durable key.¶
This document is informational guidance and uses no BCP 14 keywords. Normative requirements relevant to bootstrap are defined in [I-D.hardt-oauth-aauth-protocol]; this document references them where helpful but uses lowercase "should" / "must" in its own descriptive prose.¶
Terms defined in [I-D.hardt-oauth-aauth-protocol] are used here with the same meaning. In particular:¶
sub to the key in cnf.jwk. It carries ps when the agent has a person server ([I-D.hardt-oauth-aauth-protocol], Agent Token Structure).¶
This document additionally uses:¶
agent_token.cnf.jwk. The agent uses it to sign HTTP messages for the agent token's lifetime, then discards it on the next refresh.¶
On web, mobile, and desktop, APs should use a two-key pattern: a durable key that serves as the AP's stable enrollment anchor and is presented only to the AP at refresh, plus an ephemeral key generated fresh per agent-token issuance whose public part appears in agent_token.cnf.jwk and which signs HTTP messages for the agent token's lifetime. Refresh chains the new ephemeral key to the durable key via the jkt-jwt scheme [I-D.hardt-httpbis-signature-key]; see Section 8.¶
This pattern bounds the blast radius of an ephemeral-key leak to one agent token's lifetime, narrows the durable key's attack surface to the AP refresh path (it never signs requests to PSes, resources, or ASes), and accommodates hardware-backed durable keys on platforms that have them today and on platforms that may expose them in the future without protocol change. APs may use a single durable key for all signatures where simplicity outweighs these properties — receivers cannot distinguish the two patterns, since they only verify cnf.jwk against the HTTP signature.¶
A self-hosted deployment running one agent uses a single key — the JWKS-published key serves as both the AP signing key and the agent's signing key, since there is no separate AP to refresh against Section 4.3. One running several agents keeps the JWKS-published key as the AP key and gives each agent a key of its own Section 4.3.1.¶
The durable key is a non-extractable [WebCryptoAPI] key generated with extractable: false and stored in IndexedDB scoped to the AP's origin. The ephemeral key is also a non-extractable WebCrypto key, regenerated on each refresh and discarded when the next refresh produces its replacement.¶
Properties of the durable key:¶
Both keys are software-protected (browser sandbox) rather than hardware-protected. The two-key pattern still applies: the durable key signs only the periodic refresh (once per agent-token lifetime), while the ephemeral key signs every HTTP request and rotates on each refresh. APs that want the additional assurance of a WebAuthn ceremony at enrollment time can layer one on top; see Section 5. If browsers later expose hardware-backed credentials suitable for use as the durable key, the pattern accommodates them with no protocol change.¶
The durable key is generated and stored in the platform's hardware-backed keystore: the Secure Enclave on iOS or StrongBox on Android (or the Android Keystore where StrongBox is unavailable). The ephemeral key is a software key in app memory, regenerated on each refresh.¶
Properties of the durable key:¶
The AP typically also requires an attestation ceremony at enrollment to confirm the durable key is real keystore-bound material rather than software-generated. See Section 5. Because the durable key signs only at refresh, any per-op cost (keystore round-trip, optional user verification) is incurred at most once per agent-token lifetime, not on every request.¶
A self-hosted agent runs under a domain the user controls. The agent publishes its AP metadata document at /.well-known/aauth-agent.json per [I-D.hardt-oauth-aauth-protocol]; the JWKS itself is hosted at any HTTPS URL referenced by the metadata's jwks_uri. The corresponding private key should be hardware-bound where the platform supports it: macOS Keychain (Secure Enclave on supported hardware), Windows TPM, or Linux Secret Service.¶
Self-hosted agents act as their own AP — they self-issue agent tokens signed by the JWKS-published key. There is no separate AP to refresh against, so the two-key pattern does not apply: the JWKS-published key serves both as the AP signing key (signing self-issued agent tokens) and as the key whose public part appears in agent_token.cnf.jwk (signing HTTP messages). Because the trust anchor is a key the user controls and publishes, no platform attestation step exists. Other parties verify the agent token signature against the published JWKS, exactly as they would for any other AP.¶
A resource that calls downstream resources for its callers is self-hosted in this sense. The protocol requires it to be its own AP: it publishes /.well-known/aauth-agent.json on its own origin with the same issuer as its resource metadata, and signs downstream requests with an agent token it issued to itself ([I-D.hardt-oauth-aauth-protocol], Intermediary Agent Identity). That agent token acts for every person whose requests the resource serves, so it is not bound to one person.¶
The single-key description above assumes one agent per domain. The common self-hosted shape is one operator running several distinct agents under one domain — a planner, a researcher, one agent per lane of work — each with its own identity and its own signing key. The layout is:¶
jwks_uri holds the AP signing key, and only it. It signs every agent token the domain issues.¶
sub and its own cnf key. The AP self-issues a token for each agent, naming it aauth:planner@ops.example, aauth:research@ops.example, and so on, and binding each to a key generated where that agent runs.¶
cnf.jwk of its agent token. Nothing about an agent key goes in the JWKS, and no party ever fetches an agent key; verifiers take it from the token, as they do for every AP. A reading of "each agent holds a signing key published at a well-known URL" is the one-agent case misapplied.¶
This is the two-key pattern of Section 4 in another shape. The AP key is the domain's durable key: it signs agent tokens and the revocations the AP sends to a PS under the jwks_uri scheme ([I-D.hardt-oauth-aauth-protocol], Keying Material), never an agent's request. Each agent key is that agent's ephemeral key, and it can be rotated as often as the operator likes, because rotating it costs one self-issued token.¶
Custody follows the blast radius. The AP key belongs in hardware (Secure Enclave, TPM, StrongBox) or a keystore that only the token-issuing process can reach; compromise of it mints identities for the whole domain. An agent key belongs with the agent — in a per-lane signing proxy that signs on the agent process's behalf, in a per-process keystore, or in the process's own memory when the token is short-lived — and compromise of it is contained to that one sub for the token's lifetime. An operator that keeps every agent key in one place has collapsed the layout back to a single key and should treat that place as it would treat the AP key.¶
TBD. Future revisions will cover key handling for native desktop applications, where the durable key would live in a hardware-backed store (macOS Keychain with Secure Enclave on supported hardware, Windows TPM via CNG, Linux Secret Service / TPM2) and the ephemeral key in process memory, following the same pattern as mobile.¶
Platform attestation gives the AP cryptographic evidence about the runtime context in which the durable key was generated. It is optional — the AAuth Protocol does not require it. APs choose whether to require attestation based on their threat model.¶
Common reasons an AP might require attestation:¶
Common reasons an AP might not require attestation:¶
[WebAuthn] provides user-verification and a hardware-rooted credential on web. APs that require it perform a registration ceremony at enrollment and an assertion ceremony at later sensitive operations. The credential is stored in the user's authenticator (TPM, Secure Enclave, security key, or platform syncing fabric).¶
Tradeoffs:¶
[AppAttest] attests to two things: that the durable key was generated in the device's Secure Enclave, and that the request originates from the AP's published app on a genuine Apple device. The AP receives an attestation object at enrollment which it verifies against Apple's attestation root, then accepts subsequent assertions signed by the same enclave key.¶
[PlayIntegrity] provides a device, app, and account integrity verdict signed by Google. The AP nominates a nonce, the agent invokes the Play Integrity API, and the AP verifies the resulting integrity token. Subsequent assertions can be signed by an Android Keystore (or StrongBox) key that the AP enrolled at the same time.¶
A practical rule of thumb:¶
The agent token's sub is an aauth:local@domain identifier. The domain part is the AP. The local part identifies the agent install at the AP — it must be stable for the lifetime of the install so PSes and other parties can recognize a returning agent.¶
APs are free to choose any opaque scheme for the local part: a random string assigned at enrollment, a deterministic derivation from the durable key's thumbprint, a sequential identifier, or a human-readable handle. When deriving from a thumbprint, use the durable key's thumbprint — the ephemeral key rotates on each refresh and is not a stable identifier. Whatever the scheme, the local part must meet the protocol's character and length rules, which allow uppercase letters and reserve + for sub-agents ([I-D.hardt-oauth-aauth-protocol], Agent Identifiers); a base64url-encoded thumbprint meets them as it stands. Receivers treat the identifier as opaque and compare it exactly, without case-folding.¶
Each install's durable key is the basis for one agent identity. A returning user on a new device is a new agent. The AP may know which of its accounts enrolled an install, but it issues each install its own identifier and does not join installs into one agent.¶
Multi-device users will see multiple agent entries in their PS dashboard. Grouping or merging those entries belongs at the PS, which already authenticates the user and is the correct layer for cross-device correlation. Rotation of the durable key produces a new agent identity; rotation of the ephemeral key (on every refresh) does not — the agent's sub is stable across ephemeral rotations. PS-side regrouping is the recovery path for durable-key changes.¶
A typical agent token issued by an AP, illustrating the claims described in [I-D.hardt-oauth-aauth-protocol] and the identifier strategies in Section 6.¶
JWT header:¶
{ "alg": "Ed25519", "typ": "aa-agent+jwt", "kid": "..." }
¶
JWT payload:¶
{
"iss": "https://ap.example",
"dwk": "aauth-agent.json",
"sub": "aauth:k7q3p9n2@ap.example",
"ps": "https://ps.example",
"cnf": { "jwk": { "kty": "OKP", "crv": "Ed25519",
"x": "...", "alg": "Ed25519" } },
"iat": 1746316800,
"exp": 1746320400,
"jti": "..."
}
¶
Agent token lifetime is the AP's policy re-evaluation cadence — every refresh is the AP's chance to re-check device posture, attestation freshness, and account status before issuing a new token. A typical lifetime is 1 hour, matching common practice for proof-of-possession-bound access tokens. APs may use shorter lifetimes (e.g., 15–30 minutes) for higher-assurance deployments where attestation must be refreshed often, or longer lifetimes up to the 24 hours the AAuth Protocol recommends as the maximum, for low-policy-churn deployments where refresh chattiness is undesirable.¶
The agent refreshes its agent token when fewer than five minutes remain, then the person tokens and auth tokens it obtained with it, which expire no later than the agent token ([I-D.hardt-oauth-aauth-protocol], Expiry and the Refresh Margin). A lifetime has to leave room for that margin: an agent token of five minutes or less is inside it when issued.¶
On web, mobile, and desktop, refresh chains the new ephemeral key to the durable key via the jkt-jwt scheme [I-D.hardt-httpbis-signature-key]:¶
Signature-Key header under the jkt-jwt scheme.¶
cnf.jwk is the ephemeral public key.¶
Example refresh request:¶
POST /refresh HTTP/1.1
Host: ap.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
"content-type" "content-digest"
"signature-key");created=1746316800
Signature: sig=:...ephemeral-key signature bytes...:
Signature-Key: sig=jkt-jwt;jwt="eyJhbGc..."
{}
¶
A request with a body to an AP endpoint — enrollment, refresh, or sub-agent issuance — should cover content-digest and content-type, as the protocol requires of a request with a body to a PS or AS ([I-D.hardt-oauth-aauth-protocol], Covered Components). A refresh body can carry attestation evidence, and an enrollment or sub-agent request carries a public key the AP binds into a token.¶
The jwt parameter value is a JWT signed by the durable key, carrying the ephemeral public key in cnf.jwk along with the other claims the jkt-jwt scheme requires [I-D.hardt-httpbis-signature-key], and a jti for replay protection. The HTTP signature is produced by the ephemeral key. The AP correlates the two keys via the naming JWT's payload.¶
APs that opt for the single-durable pattern Section 4 sign the refresh request directly with the durable key under the hwk scheme [I-D.hardt-httpbis-signature-key]. The AP verifies the signature, looks up the enrollment by the key's thumbprint, and issues a fresh agent token with a new exp. The same cnf.jwk is carried through; the agent's key is unchanged.¶
APs that required platform attestation at enrollment typically do not re-attest on every refresh — the durable-key signature on the naming JWT (or the durable-key HTTP signature in the single-key pattern) is sufficient proof that the same enclave-resident key is making the request. APs that want periodic re-attestation can require a fresh App Attest assertion or Play Integrity verdict on a schedule (e.g., every 30 days) by including a server nonce in the refresh challenge.¶
Self-hosted agents self-issue agent tokens. There is no separate refresh ceremony — the agent generates a new agent token signed by its JWKS-published key whenever needed. The two-key pattern does not apply Section 4.3. Where one operator runs several agents Section 4.3.1, the token-issuing process re-issues each agent's token against that agent's current key; an agent key can change at every issuance without any ceremony, because the AP key that signs the token is the only key anyone verifies against a published document.¶
Refresh issues a new agent token bound to a fresh ephemeral key (or, in the single-key pattern, to the same durable key). The agent replaces its person tokens and auth tokens after every refresh in either pattern Section 8, so the new ephemeral key adds no work. Durable key rotation generates a new durable key and is a separate, rare event. Under the per-install identity model Section 6.1, a new durable key is a new agent — the PS treats it as new on first interaction, and any cross-device or cross-rotation continuity is handled at the PS by the user.¶
The AAuth Protocol represents a sub-agent as an agent whose token carries a parent_agent claim naming its parent, with a local part formed from the parent's followed by + and a discriminator, its own cnf key, the same iss as its parent's token, and no sub-agents of its own; a PS rejects token requests signed by a sub-agent, and the parent obtains person tokens and auth tokens on its behalf ([I-D.hardt-oauth-aauth-protocol], Sub-Agents). The protocol leaves how a sub-agent comes to hold that token to this document. Two cases.¶
The operator's self-hosted AP is the parent's AP, and it issues the sub-agent token exactly as it issues the parent's: the sub-agent generates a key where it runs, and the token-issuing process self-issues a token signed by the JWKS-published key. The only differences are in the claims.¶
{
"iss": "https://ops.example",
"dwk": "aauth-agent.json",
"sub": "aauth:planner+search1@ops.example",
"parent_agent": "aauth:planner@ops.example",
"ps": "https://ps.example",
"cnf": { "jwk": { "kty": "OKP", "crv": "Ed25519",
"x": "...", "alg": "Ed25519" } },
"iat": 1746316800,
"exp": 1746320400,
"jti": "..."
}
¶
sub is the parent's local part, +, and a discriminator the operator chooses — a lane name, a spawn counter, a short random string. It must be unique among that parent's sub-agents for as long as any party might hold a token naming it.¶
parent_agent is the parent's identifier. The protocol requires that it name a top-level agent; the issuing process checks that the parent's own token carries no parent_agent.¶
ps is copied from the parent's token. A sub-agent's person is its parent's person.¶
exp should not exceed the parent's current agent token exp. A sub-agent that outlives its parent's token has nothing to be a sub-agent of; issue for the task's expected duration, and re-issue through the same process if the task runs longer.¶
The parent plays no protocol role in issuance here. The operator spawns the sub-agent, and the process that holds the AP key mints its token. What the parent does afterwards — obtain a person token for the sub-agent with subagent_token, pass it to the sub-agent, and later exchange the resource token the sub-agent receives for an auth token — is defined by the protocol ([I-D.hardt-oauth-aauth-protocol], Parent-Mediated Authorization).¶
When the parent's tokens come from an AP the operator does not run, the parent requests the sub-agent's token from that AP; no other AP can issue it, since a PS rejects a sub-agent token whose iss differs from its parent's ([I-D.hardt-oauth-aauth-protocol], Sub-Agent Identity). This document defines no endpoint for it; the shape below is what any AP offering sub-agent issuance needs to cover, and an AP publishes how it does so in its own documentation.¶
jwt scheme ([I-D.hardt-httpbis-signature-key]). The body carries the sub-agent's public key and, if the parent wants to name it, a discriminator. The signature covers content-digest and content-type, as recommended in Section 8.1, which binds that key to the parent's signature.¶
parent_agent (a sub-agent may not have sub-agents), and applies its policy: how many sub-agents this parent may have live, what lifetime they get, whether this parent may spawn at all.¶
iss the same as in the parent's token, sub formed from the parent's local part and the discriminator (its own if the parent offered none, or if the parent's collides), parent_agent naming the parent, ps copied from the parent's token, cnf.jwk the sub-agent's public key, exp no later than the parent's token. The AP returns it to the parent, which passes it to the sub-agent.¶
Example sub-agent request, with the parent's agent token in Signature-Key and the sub-agent's public key in the body. The path and member names are illustrative; each AP defines its own.¶
POST /subagent HTTP/1.1
Host: ap.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
"content-type" "content-digest"
"signature-key");created=1746316800
Signature: sig=:...parent ephemeral-key signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."
{
"jwk": { "kty": "OKP", "crv": "Ed25519",
"x": "...", "alg": "Ed25519" },
"discriminator": "search1"
}
¶
The parent's durable key is not involved. Sub-agent issuance is a request the parent makes with its current ephemeral key and token, the same credentials it uses for every other signed request, and it needs nothing from the enrollment ceremony. Sub-agent tokens are not refreshed by the sub-agent: a sub-agent has no enrollment with the AP and no durable key. A sub-agent that needs a fresh token gets one through the parent, by the same request.¶
Two things the AP should record. Which parent requested each sub-agent token, since the parent_agent claim is the AP's assertion and a PS relies on it. And how many sub-agent tokens are live per parent, because a parent that spawns without bound is either misbehaving or compromised, and the AP is the only party positioned to notice before the PS does.¶
This section sketches a typical end-to-end enrollment for each platform. The sketches are illustrative; APs are free to vary them.¶
hwk scheme).¶
(ap_user, durable_jkt) and is now ready to issue agent tokens.¶
jkt-jwt chaining the durable key to the ephemeral key Section 8. The AP returns an agent token with sub derived per the AP's identifier strategy Section 6 (using the durable key's thumbprint when derivation is used), ps set to the agent's configured person server (an agent has exactly one PS and one person), cnf.jwk = the ephemeral public key, and any AP-attested claims.¶
(ap_user, durable_jkt, attestation) and is ready to issue agent tokens.¶
jkt-jwt.¶
/.well-known/aauth-agent.json per [I-D.hardt-oauth-aauth-protocol], with jwks_uri pointing to a JWKS containing the public part of that key.¶
There is no separate enrollment step — publication of the JWKS is the enrollment.¶
With several agents under the domain Section 4.3.1, step 1 produces the AP key, and each agent additionally generates a key where it runs; step 3 issues one token per agent, binding each to its own key. Sub-agents are issued the same way Section 9.¶
Every AP-attested claim in the agent token is only as trustworthy as the AP that signed the token. Receivers should apply policy proportional to their trust in the AP. The receivers are the PS and, when the PS federates, the AS; a resource reads the agent token only in agent identity and resource-managed access ([I-D.hardt-oauth-aauth-protocol], Why No Agent Identifier Reaches a Resource). An unfamiliar AP making strong attestation claims may warrant additional caution at the PS consent screen.¶
An ephemeral-key leak — via memory disclosure, in-page attacker, side channel, or similar — exposes only the signatures the agent makes during the current agent token's lifetime. At the recommended 1-hour lifetime, the blast radius is bounded to roughly that window before natural expiry forces replacement. The bound holds for the person tokens and auth tokens obtained with the key, since none expires later than the agent token Section 8. Agents that detect compromise can decline to refresh, aging out the ephemeral key without explicit revocation. This bounding is the primary security argument for the two-key pattern Section 4.¶
Compromise of the durable key compromises the install's agent identity for the durable key's lifetime. The durable key signs only at refresh and is presented only to the AP, so its attack surface is much narrower than the ephemeral key's — but a successful compromise lets the attacker mint refresh requests indefinitely until the AP revokes the enrollment. APs should detect anomalous refresh patterns and provide a way for users to revoke a durable enrollment.¶
Revoking the enrollment stops further agent tokens but not the current one. The AP ends the current one by revoking it at the agent's PS, which then revokes every person token and auth token it issued to the agent's sub ([I-D.hardt-oauth-aauth-protocol], Token Revocation). A resource that accepted the agent token directly receives no revocation and honors the token until its exp.¶
A non-extractable WebCrypto durable key cannot be exfiltrated by page-level attackers, but it can be used by them while they hold execution in the page. APs should pair WebCrypto-only enrollment with normal web hygiene (CSP, subresource integrity, dependency review) and should not treat the non-extractable property as a substitute for keeping the page's JavaScript clean. A hardware-backed durable key (Secure Enclave, StrongBox, TPM) cannot be exfiltrated at all, only used in-place — narrowing the threat to malicious code running in the agent application itself.¶
Platform attestation results (App Attest, Play Integrity, WebAuthn ceremonies) should be bound to a server-nominated nonce that is single-use and short-lived (5 minutes is a reasonable upper bound). The AP should verify that the attestation includes the nonce it issued; without this binding, a captured attestation can be replayed across enrollments.¶
Compromise of the self-hosted JWKS key allows the attacker to mint agent tokens for that user's domain. Users running self-hosted agents should use hardware-backed keys (Secure Enclave / TPM / StrongBox) and rotate the published JWKS if compromise is suspected.¶
Where the domain runs several agents Section 4.3.1, the two kinds of key have different blast radii. Compromise of one agent's key lets the attacker sign as that one sub until its token expires, and nothing else: the key appears in no published document and cannot mint tokens. Compromise of the AP key mints identities for every agent the domain runs, and for agents it does not run. The layout is only as strong as that separation; an operator who stores agent keys where the AP key lives has given each of them the AP key's reach.¶
An agent's sub is not a pairwise identifier. It is the same value at every party the agent token reaches: the agent's PS, any AS the PS federates with, and any resource the agent calls in agent identity or resource-managed access. A stable sub lets the PS reliably re-identify the agent across sessions — that is the intended property — but because an agent acts for one person, it is also a pseudonym for that person which any two of those resources can correlate. In the modes where the agent presents a person token, a resource sees a per-resource identifier instead ([I-D.hardt-oauth-aauth-protocol], Directed Identifiers). Under per-install identity Section 6.1, durable-key rotation produces a new sub, giving users a natural "fresh start" capability.¶
The AP that issued an agent token does not see the agent's subsequent traffic to PSes, resources, or ASes (they verify against the AP's published JWKS, not by calling the AP). The AP's view is limited to the requests made to it, such as enrollment, refresh, and sub-agent issuance. When the AP revokes an agent token, the PS reports nothing of what it revoked downstream ([I-D.hardt-oauth-aauth-protocol], Why a PS Reports Nothing to the Agent Provider). APs should document their data retention practices for those events.¶
This document is informational and registers no new media types, JWT claim names, or metadata fields.¶
Note: This section is to be removed before publishing as an RFC.¶
This section records the status of known implementations of the patterns described in this document at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.¶
TBD¶
Note: This section is to be removed before publishing as an RFC.¶
draft-hardt-aauth-bootstrap-02¶
ps. The agent-token lifetime bound is the protocol's recommended maximum, not a ceiling. Scheme names are given as prose.¶
sub and cnf key, agent keys never published, custody by blast radius. The single-key description assumed one agent per domain, and a deployment read it as "each agent holds a key published at a well-known URL". Refresh, enrollment, and Security Considerations gained the several-agent case.¶
parent_agent, a + discriminator, the parent's ps, and a fresh cnf key; and the hosted-AP case, where the parent requests it with its own ephemeral key and token, and the AP checks the parent is top-level, applies policy, and returns the token. The protocol deferred acquisition here and nothing covered it.¶
Ed25519 rather than the deprecated polymorphic EdDSA; the cnf.jwk example carries the alg member now required of every conveyed key.¶
sub correlation concern is at resources, not across PSes.¶
ps whenever the agent has a person server.¶
jwks_uri scheme.¶
jkt-jwt naming JWT carries the ephemeral key in cnf.jwk, which the scheme requires.¶
iss equals its parent's, so only the parent's AP can issue it.¶
sub. The ephemeral-key bound covers the person tokens and auth tokens obtained with the key. The PS reports nothing of a revocation back to the AP.¶
content-digest and content-type, as the protocol requires at a PS or AS. The refresh example shows it, and a new example shows the hosted sub-agent request, whose body carries the sub-agent's public key.¶
draft-hardt-aauth-bootstrap-01¶
/bootstrap endpoint, bootstrap_token, bootstrap announcement, agent server [now Agent Provider] bootstrap_endpoint / refresh_endpoint / webauthn_endpoint) has been removed. PS-side binding to a person now happens lazily on the agent's first interaction with the PS per the AAuth Protocol; the bootstrap document covers AP-side enrollment patterns only.¶
platform and device parameters are defined and described in the AAuth Protocol.¶
draft-hardt-aauth-bootstrap-00¶
The author thanks Abay Aubakirov (Regent Protocol) for feedback from a production sub-agent deployment.¶