Bootstrap
The AP-side ceremony by which an instance of an agent acquires an agent token. The agent generates a signing key, presents whatever evidence the agent provider requires, and receives an aa-agent+jwt whose cnf.jwk is bound to that key and whose sub is an aauth:local@domain identifier the AP has chosen.
Informational — not normative protocol
As of -01, the Bootstrap document is informational guidance for agent provider implementers. The previously-normative PS /bootstrap endpoint, bootstrap_token, aa-bootstrap+jwt type, and PS bootstrap announcement have been removed. PS-side binding of an agent to a person now happens lazily on the agent's first interaction with the PS. The scenarios linked below pre-date this rewrite and are kept here for reference; they depict mechanisms that are no longer part of the spec.
What bootstrap is — and is not
Bootstrap is
- The AP-side ceremony that produces an agent token
- Per-platform key handling (durable + ephemeral)
- Optional platform attestation (WebAuthn, App Attest, Play Integrity)
- Agent identifier strategy at the AP
- Refresh patterns for replacing expired agent tokens
Bootstrap is not
- The user-to-agent binding (the PS does this lazily on first interaction)
- Authorization — bootstrap conveys no scope or resource permission
- An identity-claim flow — claims come later via the standard flows
- A one-size-fits-all ceremony — web, mobile, and self-hosted differ
- Normative protocol — APs may use other approaches
Two-key pattern
Durable key
Lifetime spans the agent install. Hardware-bound where the platform supports it (Secure Enclave, StrongBox, TPM). Presented only to the AP at refresh; never signs requests to PSes, resources, or ASes.
Ephemeral key
Generated fresh per agent-token issuance. Public part appears in agent_token.cnf.jwk. Signs HTTP messages for the agent token's lifetime, then is discarded on next refresh.
This bounds the blast radius of an ephemeral-key leak to one agent token's lifetime and narrows the durable key's attack surface to the AP refresh path. APs may also use a single durable key for all signatures — receivers cannot distinguish the two patterns. Self-hosted agents use a single key (the JWKS-published key serves both roles).
Per-platform enrollment sketches
The same idea adapts to several deployment shapes. The scenarios below were written against the earlier draft — see the banner above.
Web App
Agent runs in the browser. Non-extractable WebCrypto durable key in IndexedDB; ephemeral key rotated per agent-token issuance. WebAuthn is an optional layer.
Mobile (iOS)
Agent runs on iOS with a Secure Enclave durable key. Optional App Attest at enrollment.
Mobile (Android)
Agent runs on Android with a StrongBox / Android Keystore durable key. Optional Play Integrity at enrollment.
Self-Hosted
Agent runs under a user-controlled domain and acts as its own agent provider. Self-issues agent tokens signed by a JWKS-published key.
Desktop apps and headless workloads are marked TBD in the current draft and are not covered here.
Token refresh
Agent tokens are typically 1 hour, up to a 24-hour ceiling. Every refresh is the AP's chance to re-check device posture, attestation freshness, and account status before issuing a new token. The durable key chains a fresh ephemeral key via the jkt-jwt scheme.
Two-Key Refresh (mobile)
Refresh chains a fresh ephemeral key to the durable key via the jkt-jwt scheme. The durable key signs only the naming JWT; the ephemeral key signs HTTP messages.
Two-Key Refresh (web)
Same pattern on web. A WebAuthn assertion can optionally be required at high-assurance refreshes.
Bootstrap produces an agent identity. The PS binds it to a person.
After bootstrap, the PS attaches the agent to a user lazily on first interaction. Resources can then issue resource tokens targeting the agent's PS for identity and consent.