AAuth Bootstrap

1.1. In Scope

• Self-hosted agents (including self-hosted CLI), where the agent and agent server are co-located under a domain the user controls. Binding to a PS is optional.¶
• Web apps (agent runs in the user's browser; agent server runs separately on the network).¶
• Mobile agents (agent runs on the user's device with platform attestation; agent server runs separately on the network).¶

B2B SaaS deployments use the same web app or mobile profile; what differs is which PS the agent talks to and which account hints it passes (see Section 15).¶

1.2. Out of Scope

The following deployment shapes are not specified by this document and are deferred to future revisions. Each is described briefly so implementers can recognize the pattern and understand why it is treated separately.¶

3.1. Terms Reused From AAuth Protocol

The following terms are defined in [I-D.hardt-aauth-protocol] and are used in this document with the same meaning. Summaries are provided for convenience; the referenced specification is authoritative.¶

• Person: The user or organization on whose behalf an agent acts. Referred to in this document as "the user".¶
• Agent: An HTTP client acting on behalf of a person, identified by an agent identifier URI of the form aauth:local@domain defined in [I-D.hardt-aauth-protocol].¶
• Agent Server: A server that manages agent identity and issues agent tokens. In the self-hosted profile the agent server is co-located with the agent under a domain the user controls; in the web app and mobile profiles it runs separately on the network. Identified by an HTTPS URL.¶
• Person Server (PS): A server that represents the person to the rest of the protocol. In the context of this document, the PS vouches for the user to the agent server during bootstrap. Identified by an HTTPS URL.¶
• Resource: A server that protects access to its APIs. Not involved in bootstrap.¶
• Agent Token: A JWT issued by an agent server to establish the agent's identity, defined in [I-D.hardt-aauth-protocol].¶
• Auth Token: A JWT issued by a PS or AS granting an agent access to a resource, defined in [I-D.hardt-aauth-protocol]. Not issued during bootstrap.¶
• Interaction: User authentication or consent at an interaction endpoint, triggered when a server returns 202 Accepted with requirement=interaction. Defined in [I-D.hardt-aauth-protocol].¶

3.2. Terms Reused From HTTP Signature Keys

The following signature schemes are defined in [I-D.hardt-httpbis-signature-key] and used in this document without modification:¶

• hwk scheme: Conveys a public key inline in the Signature-Key header.¶
• jkt-jwt scheme: Chains a JWT signed by one key (e.g., a durable enclave key) to authorize a second key (e.g., an ephemeral HTTP signing key).¶
• jwt scheme: Conveys a JWT (e.g., an agent token) that names the signing key.¶

3.3. Terms Defined in This Document

• Bootstrap: The PS-mediated ceremony defined in this document by which an agent becomes bound to a person at that person's PS. For self-hosted agents bootstrap is optional; for web app and mobile agents it is the way to obtain an initial agent token.¶
• Ephemeral Key: An HTTP signing key generated by the agent whose lifetime is bounded by the agent token. Typically hours to a day, not per-request.¶
• Durable Key: A platform-protected key whose lifetime is bounded by the application install (or, for self-hosted agents, by the install of the agent on the user's machine). Typically months to years. Examples include the iOS Secure Enclave, Android StrongBox, the macOS Keychain (Secure Enclave on supported hardware), Windows TPM, and Linux Secret Service. A durable key is identified by a JWK thumbprint (urn:jkt).¶
• bootstrap_token: A short-lived JWT issued by the PS, directed at an agent server, and bound to an agent's ephemeral key via a cnf claim. Defined in Section 8.4.¶
• Binding: The one-to-one association (ps_url, user_sub) -> aauth:local@<agent-server-domain> recorded by the agent server at the end of bootstrap, together with the device credentials associated with it.¶
• Device Credential: A credential held by the agent server and associated with a binding, used to authenticate renewal requests without re-involving the PS. A WebAuthn credential ID for web apps or an enclave-key thumbprint (urn:jkt:sha-256:<thumbprint>) for mobile.¶

7.1. Request

The agent issues a GET request with the ceremony type as a query parameter:¶

GET /webauthn?type=create HTTP/1.1
Host: agent-server.example

or¶

GET /webauthn?type=get HTTP/1.1
Host: agent-server.example

Query parameters:¶

• type (REQUIRED). Either create (for bootstrap registration) or get (for refresh assertion).¶

The request is unsigned. The agent MUST NOT include user identifiers on the challenge request.¶

7.2. Response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "challenge": "<base64url random bytes>",
  "creation_options": {
    "rp": { "id": "agent-server.example", "name": "Example AI Assistant" },
    "pubKeyCredParams": [{ "type": "public-key", "alg": -7 }, ...],
    "authenticatorSelection": { ... },
    "attestation": "none"
  }
}

Response members:¶

• challenge (REQUIRED). Server-generated random value of at least 16 bytes, base64url-encoded without padding. The agent server MUST store the challenge in a single-use, time-limited registry. The challenge SHOULD expire within 5 minutes.¶
• creation_options (REQUIRED when type=create). The non-user portions of a WebAuthn PublicKeyCredentialCreationOptions object ([WebAuthn]): rp, pubKeyCredParams, authenticatorSelection, attestation, timeout, and related server-decided fields. The agent fills in the challenge field from this response and fills in the user field from the bootstrap_token, deriving user.id from bootstrap_token.sub. WebAuthn ([WebAuthn], Section 5.4.3) limits user.id to 64 bytes and requires that it not contain personally identifying information; the agent MUST encode bootstrap_token.sub accordingly (typically the raw 32-byte SHA-256 of sub, since sub is already a pairwise opaque identifier). MUST be absent when type=get.¶

The response MUST NOT include user-identifying information. The agent server MUST NOT bind the challenge to a particular user in its issuing state; user context enters only when the ceremony result is submitted.¶

8.1. Key Generation

The agent generates an ephemeral signing key.¶

On mobile platforms, the agent also has (or generates on first install) a durable enclave-protected key with a stable JWK thumbprint of the form urn:jkt:sha-256:<thumbprint>.¶

In the web app profile, only the ephemeral key exists. (The self-hosted profile uses a JWKS-published hardware-bound key in place of these; see Section 14.)¶

8.2. Request to PS /bootstrap

The agent sends an HTTP request to the PS's /bootstrap endpoint signed under the hwk scheme ([I-D.hardt-httpbis-signature-key]) using the ephemeral key:¶

POST /bootstrap HTTP/1.1
Host: ps.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=hwk;kty="OKP";crv="Ed25519";x="<ephemeral-pubkey>"
Content-Type: application/json

{
  "agent_server": "https://agent-server.example"
}

The request body is a JSON object with the following members:¶

• agent_server (REQUIRED). The HTTPS URL identifying the agent server that will mint the agent identity. This value is placed in the aud claim of the issued bootstrap_token.¶
• tenant, domain_hint, login_hint (OPTIONAL account hints). See Section 15 for semantics and selection guidance.¶

8.3. Interaction Response

The PS responds with an interaction requirement using the requirement-response and polling pattern defined in [I-D.hardt-aauth-protocol]:¶

HTTP/1.1 202 Accepted
Location: https://ps.example/bootstrap/pending/abc123
Retry-After: 0
Cache-Control: no-store
AAuth-Requirement: requirement=interaction;
    url="https://ps.example/interaction"; code="A1B2-C3D4"
Content-Type: application/json

{
  "status": "pending"
}

The agent constructs the user-facing URL from the url and code parameters and directs the user to it per the methods defined in [I-D.hardt-aauth-protocol] (browser redirect, QR code, or display code). The PS authenticates the user and presents a consent screen asking the user to allow the agent server to establish an account bound to the user at this PS. No identity claims are released at this step; claims flow through the standard three-party flow defined in [I-D.hardt-aauth-protocol] after bootstrap completes.¶

The consent screen SHOULD display the agent server's display name and logo as retrieved from the agent server's /.well-known/aauth-agent.json metadata document, alongside the agent server's host. The user approves or denies the request.¶

The agent polls the Location URL until the interaction completes, following the polling rules in [I-D.hardt-aauth-protocol]. While the interaction is pending the PS returns the same 202 envelope; on completion it returns the response defined in Section 8.4.¶

8.4. bootstrap_token Issuance

On successful user approval, a poll of the pending URL returns the bootstrap_token:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "bootstrap_token": "eyJhbGc..."
}

The bootstrap_token is a signed JWT [RFC7519] with the following structure.¶

8.5. Request to Agent Server /bootstrap

This step is omitted for self-hosted agents Section 14, where the agent and agent server are co-located and the agent self-issues the agent token instead of POSTing to a remote bootstrap_endpoint. The remainder of this section applies to web app and mobile profiles.¶

Before calling bootstrap_endpoint, the agent performs the attestation ceremony appropriate to its platform. See Section 9 for the ceremony details and for the logic by which the platform is chosen. The attestation result is carried in the POST body.¶

The agent sends a single POST to bootstrap_endpoint:¶

POST /bootstrap HTTP/1.1
Host: agent-server.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=<scheme>
Content-Type: application/json

{
  "bootstrap_token": "<jwt>",
  "attestation": {
    "type": "<attestation type>",
    ...
  }
}

The HTTP Message Signature scheme is determined by the platform:¶

• Web app clients use hwk with the agent's ephemeral key.¶
• Mobile clients use jkt-jwt ([I-D.hardt-httpbis-signature-key]), where the JWT header references the enclave key and the JWT payload's cnf.jwk is the ephemeral public key. The ephemeral key signs the HTTP message.¶

Request body members:¶

• bootstrap_token (REQUIRED). The JWT received from the PS.¶
• attestation (REQUIRED). The attestation result, whose shape is defined by the ceremony described in Section 9. The type field identifies the ceremony (e.g., webauthn, app-attest, play-integrity) and MUST match the scheme implied by the HTTP signature.¶

On receiving the request, the agent server MUST:¶

1. Verify the HTTP Message Signature per [RFC9421] and [I-D.hardt-httpbis-signature-key].¶
2. Resolve and validate the bootstrap_token signature per [RFC7515] and [RFC7519] by fetching the PS's JWKS using iss and dwk.¶
3. Apply local policy on whether bootstrap_token.iss is an acceptable PS for this agent server. By default, consumer-profile agent servers SHOULD accept any PS that publishes valid metadata; B2B-profile agent servers SHOULD restrict acceptance to an explicit allowlist. Reject with 403 Forbidden if policy denies.¶
4. Verify that bootstrap_token.aud equals the agent server's own URL.¶
5. Verify that bootstrap_token.cnf.jwk matches the ephemeral public key used to sign the HTTP request.¶
6. Verify iat is not in the future and exp is in the future per [RFC7519]; reject replays by jti.¶
7. Verify the attestation per the rules of the indicated ceremony in Section 9, including that any ceremony challenge or nonce matches one issued by the agent server and has not expired or been consumed. Mark the ceremony challenge as consumed.¶
8. Create or look up the binding Section 8.6.¶
9. Store the device credential derived from the attestation (a WebAuthn credential ID for web apps, or the enclave key thumbprint for mobile) on the binding.¶
10. Issue the agent token Section 8.7.¶

If bootstrap_token verification fails, the agent server MUST respond 400 Bad Request. If issuer policy denies, the agent server MUST respond 403 Forbidden. If attestation verification fails, the agent server MUST respond 401 Unauthorized.¶

8.6. Binding Creation

The agent server looks up or creates a binding keyed by (bootstrap_token.iss, bootstrap_token.sub):¶

(ps_url, user_sub) -> aauth:local@<agent-server-domain>

The binding is one-to-one: the same user at the same PS at the same agent server MUST map to the same aauth:local@domain identity, regardless of device.¶

The agent server stores the device credential obtained during attestation (a WebAuthn credential ID, or a urn:jkt:sha-256:<enclave> thumbprint) against the binding. Multiple device credentials MAY be associated with a single binding.¶

8.7. Token Response

The agent server returns an agent token:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "agent_token": "eyJhbGc..."
}

The agent_token is a JWT [RFC7519] as defined in [I-D.hardt-aauth-protocol] with:¶

• typ: aa-agent+jwt.¶
• iss: The agent server URL.¶
• dwk: aauth-agent.json.¶
• sub: The aauth:local@<agent-server-host> identity from the binding.¶
• ps: The PS URL (from bootstrap_token.iss).¶
• cnf.jwk: The agent's ephemeral public key.¶

The agent server does not issue a resource token at bootstrap. If the agent server needs identity claims about the user (e.g., to populate a profile page), it follows the standard three-party flow defined in [I-D.hardt-aauth-protocol] after bootstrap completes.¶

8.8. Bootstrap Completion

Once the agent holds the agent_token, it SHOULD announce its new agent identity to the PS so the PS can bind the identity to the user within the PS's bootstrap record. The agent SHOULD perform this announcement immediately upon receiving the agent_token and in any case before bootstrap_token.exp, because the PS correlates the announcement to the bootstrap record by the ephemeral key's thumbprint and MAY discard records after expiry. The agent MUST perform the announcement before rotating its ephemeral key (that is, before any call to refresh_endpoint).¶

POST /bootstrap HTTP/1.1
Host: ps.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=jwt;jwt="<agent_token>"
Content-Length: 0

9.1. Ceremony Selection

The agent selects the ceremony from its runtime platform. The agent server determines which ceremony to expect from the HTTP signature scheme on the bootstrap_endpoint or refresh_endpoint POST.¶

An agent server that accepts web app clients MUST publish webauthn_endpoint in its metadata Section 6.¶

For mobile clients, the agent server MUST nominate the nonce consumed by the platform attestation; the nonce MUST be at least 16 bytes of cryptographically random data, single-use, and MUST expire within 5 minutes of issuance. The transport by which the agent obtains the nonce is application-defined: most mobile agents already share an authenticated channel with their server and can carry the nonce on an existing endpoint. No metadata field for this transport is defined here. Section 9.3.3 gives a non-normative example shape for implementations that do not have an existing channel.¶

Self-hosted agents do not use bootstrap_endpoint or refresh_endpoint and therefore do not perform a ceremony at the agent server step; the trust anchor is the hardware-bound JWKS key described in Section 14.¶

9.2. Web App: WebAuthn

Web app clients use the same webauthn_endpoint Section 7 for both bootstrap (type=create) and renewal (type=get). The ceremony result is carried in the POST body to bootstrap_endpoint or refresh_endpoint.¶

GET /webauthn?type=create HTTP/1.1
Host: agent-server.example

HTTP/1.1 200 OK
Content-Type: application/json

{
  "challenge": "<base64url random bytes>",
  "creation_options": {
    "rp": { "id": "agent-server.example", "name": "Example AI Assistant" },
    "pubKeyCredParams": [
      { "type": "public-key", "alg": -7 },
      { "type": "public-key", "alg": -257 }
    ],
    "authenticatorSelection": {
      "residentKey": "required",
      "userVerification": "preferred"
    },
    "attestation": "none"
  }
}

POST /bootstrap HTTP/1.1
Host: agent-server.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=hwk;kty="OKP";crv="Ed25519";x="<ephemeral-pubkey>"
Content-Type: application/json

{
  "bootstrap_token": "<jwt>",
  "attestation": {
    "type": "webauthn",
    "credential": {
      "id": "<base64url credential id>",
      "rawId": "<base64url>",
      "response": {
        "clientDataJSON": "<base64url>",
        "attestationObject": "<base64url>"
      },
      "type": "public-key"
    }
  }
}

GET /webauthn?type=get HTTP/1.1
Host: agent-server.example

HTTP/1.1 200 OK
Content-Type: application/json

{
  "challenge": "<base64url random bytes>"
}

POST /refresh HTTP/1.1
Host: agent-server.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=hwk;kty="OKP";crv="Ed25519";x="<new-ephemeral-pubkey>"
Content-Type: application/json

{
  "attestation": {
    "type": "webauthn",
    "credential": {
      "id": "<base64url credential id>",
      "rawId": "<base64url>",
      "response": {
        "clientDataJSON": "<base64url>",
        "authenticatorData": "<base64url>",
        "signature": "<base64url>",
        "userHandle": "<base64url>"
      },
      "type": "public-key"
    }
  }
}

9.3. Mobile: Platform Attestation and Enclave Proof

Mobile clients use App Attest ([AppAttest]) on iOS or Play Integrity ([PlayIntegrity]) on Android at bootstrap to enroll the enclave key as the device credential. At renewal, the enclave key signature in the jkt-jwt HTTP Message Signature is itself sufficient proof; no additional ceremony is required.¶

POST /bootstrap HTTP/1.1
Host: agent-server.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=jkt-jwt;jwt="<jkt-jwt-token>"
Content-Type: application/json

{
  "bootstrap_token": "<jwt>",
  "attestation": {
    "type": "app-attest",
    "key_id": "<base64url>",
    "attestation_object": "<base64url>",
    "client_data_hash": "<base64url>"
  }
}

{
  "type": "play-integrity",
  "integrity_token": "<JWS-encoded attestation>"
}

POST /refresh HTTP/1.1
Host: agent-server.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=jkt-jwt;jwt="<jkt-jwt-token>"

GET /attestation/nonce HTTP/1.1
Host: agent-server.example

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "nonce": "<base64url random bytes>"
}

11.1. Renewal Flow

Before calling refresh_endpoint, the agent performs the renewal attestation ceremony appropriate to its platform. See Section 9 for the ceremony details. The ceremony result, if any, is carried in the POST body.¶

POST /refresh HTTP/1.1
Host: agent-server.example
Signature-Input: sig=...
Signature: sig=...
Signature-Key: sig=<scheme>
Content-Type: application/json

{
  "attestation": {
    "type": "<attestation type>",
    ...
  }
}

The HTTP Message Signature scheme is determined by the platform:¶

• Web app clients use hwk with a newly generated ephemeral key.¶
• Mobile clients use jkt-jwt ([I-D.hardt-httpbis-signature-key]), where the enclave key signs a jkt-jwt binding a newly generated ephemeral key; the ephemeral key signs the HTTP message. For mobile, the request body MAY be empty because the jkt-jwt signature itself proves possession of the device credential.¶

Request body members:¶

• attestation (REQUIRED for web app clients; omitted for mobile clients). The assertion result defined by the renewal ceremony in Section 9.¶

On receiving the request, the agent server MUST:¶

1. Verify the HTTP Message Signature per [RFC9421] and [I-D.hardt-httpbis-signature-key].¶

2. Look up the binding:¶

   • For web app clients, by the credential ID (rawId) in the WebAuthn assertion.¶
   • For mobile clients, by the enclave key thumbprint (urn:jkt:sha-256:<thumbprint>) derived from the jkt-jwt header.¶
3. Verify the renewal attestation per the rules of the indicated ceremony in Section 9, including that any ceremony challenge matches one it issued and has not expired or been consumed. Mark the challenge as consumed.¶
4. Issue a fresh agent token bound to the new ephemeral key.¶

11.2. Refresh Response

On success, the agent server returns:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "agent_token": "eyJhbGc..."
}

The agent_token has the same structure as in Section 8.7 but bound to the new ephemeral key.¶

11.3. Renewal Failure

Renewal MUST fail in the following conditions. The agent MUST then repeat the full PS-mediated bootstrap flow from Section 8. The agent server distinguishes the failure mode by status code:¶

• 404 Not Found when no binding matches the credential identifier presented (e.g., the enclave key has been regenerated after mobile reinstall and the urn:jkt is unknown; the WebAuthn rawId is unknown; or the binding has been revoked at the agent server and removed from storage).¶
• 401 Unauthorized when a binding is found but the proof fails (e.g., a WebAuthn assertion does not verify, the jkt-jwt signature does not verify, or the ceremony challenge has expired or been consumed).¶

Independently, the PS MAY have stopped vouching for the user (for example, account closure or organizational deprovisioning). The agent server has no direct signal of this; it surfaces only through a subsequent PS /bootstrap call that fails at the interaction step. The agent will then be unable to re-establish the binding.¶

14.1. Without a PS

The agent self-issues an agent_token with no ps claim. The agent does not call the PS /bootstrap endpoint and does not call the agent server /bootstrap endpoint (it would be calling itself). The agent uses its self-issued agent_token directly with resources that support identity-based or resource-managed access per [I-D.hardt-aauth-protocol]. Resources requiring PS-issued auth tokens are not reachable in this mode.¶

14.2. With a PS

The agent calls the PS /bootstrap endpoint to establish a (user, agent) binding at the PS, then self-issues an agent_token carrying a ps claim that names the bound PS. The PS-side flow is unchanged from Section 8:¶

1. The agent generates an ephemeral key and POSTs to the PS /bootstrap endpoint signed under the hwk scheme, with agent_server set to the agent server's URL (the user's domain rooted at https://).¶
2. The PS authenticates the user, collects consent, and returns a bootstrap_token with aud set to the agent server's URL and sub set to a directed user identifier per Section 8.4.¶
3. The agent does not POST to its own bootstrap_endpoint. Instead, the agent self-issues an agent_token per Section 8.7 with iss set to the agent server's URL, cnf.jwk set to the same ephemeral key bound in bootstrap_token.cnf.jwk, and ps set to the PS URL from bootstrap_token.iss. The aauth:local@<agent-server-host> sub of the agent_token is chosen by the agent under its own host.¶
4. The agent performs the bootstrap completion announcement to the PS per Section 8.8. The PS verifies the self-issued agent_token by resolving the agent server's JWKS at agent_token.iss, exactly as it would for an agent server operated separately from the agent.¶

After the announcement, the PS holds the (user, agent) binding. When a resource later requires a PS-issued auth token and the PS needs the user's consent, the PS MAY prompt the user out of band over a channel established at first bootstrap Section 13 instead of requiring an in-app interaction.¶

16.1. bootstrap_token Replay

The bootstrap_token carries a cnf claim binding it to the agent's ephemeral public key. Possession of the token alone is insufficient; the holder MUST also control the corresponding private key. Agent servers MUST reject bootstrap_tokens that are not accompanied by an HTTP request signed with the key named in cnf.jwk, and MUST reject replay by jti.¶

16.2. Consent Phishing

The user sees the agent server's domain, name, and logo at the PS consent screen. This relies on user recognition of the agent server. The PS SHOULD retrieve the agent server's display metadata from its /.well-known/aauth-agent.json document and present it at the consent screen.¶

16.3. Key-to-User Binding Without Attestation

For the web app and mobile profiles, the bootstrap flow relies on platform attestation at the agent server step. Environments without a platform attestation mechanism cannot safely use this flow because a remote process may impersonate a local user by relaying ephemeral keys through them. This is the reason vendor-operated command-line tools are out of scope; self-hosted agents Section 14 avoid the problem because the trust anchor is a hardware-bound JWKS-published key controlled by the user.¶

16.4. Enclave Key Compromise

On mobile, compromise of the enclave key breaks the chain of delegated ephemeral keys. Implementations SHOULD use the shortest practical jkt-jwt lifetimes.¶

16.5. Agent Server Compromise

Compromise of an agent server breaks all agent identities minted by that server. Bootstrap does not introduce this risk, but centralizes it at the agent server.¶

16.6. PS Compromise

The PS is already a high-value target in [I-D.hardt-aauth-protocol]. Bootstrap does not change the risk profile, but makes the PS load-bearing for agent identity creation.¶

16.7. Bootstrap Completion Announcement

The announcement POST to the PS Section 8.8 is bound to possession of the agent's ephemeral key plus a signed agent_token issued to that key. An attacker would need both the ephemeral private key and a valid agent_token for the target aauth identifier. These are the same credentials that protect the rest of bootstrap; the announcement introduces no new attack surface.¶

16.8. Resource Exhaustion at Unauthenticated Endpoints

Three endpoints accept unauthenticated requests and allocate server-side state:¶

• The PS /bootstrap endpoint creates a pending bootstrap record and an interaction code.¶
• The agent server webauthn_endpoint issues a single-use challenge.¶
• The non-normative mobile nonce endpoint of Section 9.3.3, if exposed, issues a single-use nonce.¶

An attacker can flood any of these to exhaust storage or CPU. Implementations MUST rate-limit these endpoints (per source IP and globally), keep the issued state small (an opaque random value plus expiry), and apply short TTLs (≤5 minutes is RECOMMENDED) so that orphaned state is reclaimed quickly. Implementations SHOULD also apply rate limiting to bootstrap_endpoint and refresh_endpoint even though those are signed, since signature verification is itself non-trivial work.¶

17.1. Directed User Identifiers

The bootstrap_token.sub claim MUST be a pairwise user identifier directed at the agent server. This prevents cross-vendor correlation of users across different agent servers.¶

17.2. Mobile Enclave Identity

The PS sees only the ephemeral hwk key. The agent server sees the jkt-jwt carrying the enclave identity. The PS therefore cannot track a device across bootstraps at different agent servers.¶

17.3. Out-of-Band Consent Channel

The user communication channel held by the PS after first bootstrap is privacy-sensitive. PS implementations SHOULD document their user communication practices.¶

17.4. Agent Identifier Registry at the PS

After bootstrap completion Section 8.8, the PS knows the aauth:local@domain identifier of each agent the user has bootstrapped. This supports user-facing features such as a dashboard of connected agents and targeted revocation ("disconnect from agent X"). PS implementations SHOULD make this list visible to the user.¶

17.5. Announcement Metadata Exposure

The bootstrap completion announcement Section 8.8 is sent over TLS, but its fact-of-existence and timing reveal the (PS, agent_server, agent_id) triple to any on-path observer that can correlate the connection's destination with the agent_token carried in Signature-Key. Operators of either side SHOULD treat the announcement timing with the same care as any other consent-related event, and SHOULD avoid logging the agent_token value in shared infrastructure.¶

18.1. Media Type Registrations

This specification registers the following media type in the IANA Media Types registry:¶

18.2. JWT Type Registrations

This specification registers the following JWT typ header parameter value in the "JSON Web Token Types" sub-registry:¶

18.3. JWT Claims

This document defines no new JWT claims. The bootstrap_token uses claims registered in the IANA "JSON Web Token Claims" registry ([RFC7519], [RFC7800]) together with dwk, which is registered by [I-D.hardt-aauth-protocol].¶

18.4. AAuth Agent Server Metadata Registration

This document registers the following parameters in the AAuth Agent Server Metadata registry established by [I-D.hardt-aauth-protocol]:¶