appliedbits
LIBRARY  ·  IETF LIBRARY ENTRY
Last updated 2026-05-06 drafted

RFC 9447 — ACME Challenges Using an Authority Token

RFC 9447 (Peterson, Barnes, Hancock, Wendt — September 2023) is the IETF specification that extends ACME (RFC 8555) with a generic Authority Token Challenge. It defines how an ACME server can require a client to present a signed token from an external authority — rather than performing a DNS or HTTP challenge — as proof that the client is entitled to the certificate it’s requesting. I am a co-author. The document is the generic half of the ACME-for-STIR pair; the companion specification, RFC 9448, profiles it for the TNAuthList identifier type.

Why a different challenge type was needed

ACME was designed for the WebPKI case, where proof of control over a resource is something the ACME client can demonstrate directly to the ACME server — a DNS record under the requested domain, or a file served from a well-known URL. That model breaks for resources where control is established through a relationship the ACME server can’t see — a service provider’s right to issue calls under a Service Provider Code, for instance, or an enterprise’s authorization to use a specific telephone number. Those rights live with an external authority (a regulator, a numbering administrator, a carrier that has delegated authority to its customer), not in any record the ACME server can probe.

The Authority Token Challenge solves that by defining a third party — the Token Authority — that the client first authenticates to using whatever out-of-band mechanism the authority operates. The Token Authority returns a signed JWT that asserts the client’s right to the resource. The client then presents that token in response to the ACME challenge. The ACME server validates the token’s signature, its scope, and its binding to the client’s ACME account, and issues the certificate on the strength of those checks rather than on a direct control-proof.

What it specifies

The mechanism has four moving parts, each defined in the document:

  • A new ACME challenge type — tkauth-01. Registered in the ACME Validation Methods registry. The challenge object contains a tkauth-type field identifying the token subtype expected, and a token-authority field giving a URL where the client can request the token.
  • A new IANA registry — “ACME Authority Token Challenge Types.” Managed under Specification Required. The initial entry is atc for JWT-format Authority Tokens. Other token formats can be registered by future specifications.
  • The Authority Token format — a JWT. Carries a new claim, atc (Authority Token Challenge), with three sub-fields: tktype (the identifier type — TNAuthList, for example), tkvalue (the scope of the authority being asserted), and fingerprint (a SHA-256 of the client’s ACME account key, so the token is bound to the account that requested it). The atc claim is registered in the JWT Claims registry.
  • An acquisition protocol. The client presents an HTTPS request to the Token Authority’s URL, the Token Authority authenticates the client (mechanism out of scope; typically a pre-established credential), and on success returns the signed JWT in a 200 response. TLS is mandatory for both the ACME transactions and the token-acquisition transactions.

The semantics of tkvalue — what the resource looks like, how authority over it is verified — are deliberately left to the profile documents. RFC 9447 specifies the envelope; profile documents specify what goes in it.

Design choices worth knowing

One is the profile-and-payload separation. RFC 9447 doesn’t bind itself to telephone numbers or any other identifier type. The challenge mechanism, the registry, the JWT format, and the binding semantics are all generic. Identifier-specific behavior — what tkvalue looks like for a TNAuthList, what the Token Authority must verify before issuing a token — lives in profile documents. RFC 9448 is the first profile (for STI certificates carrying TNAuthList); others can register their own challenge subtypes against the same generic substrate without renegotiating the ACME-side protocol.

Another is the fingerprint binding. The token is bound to the requesting client’s ACME account key, which means the token can’t be intercepted and replayed by another party. The binding is one-directional — the Token Authority signs the fingerprint into the token without itself verifying that the fingerprint corresponds to a real ACME account, leaving that verification to the ACME server when the token is presented. This keeps the Token Authority’s job narrow: assert authority over the resource, bind the assertion to a specific account-key fingerprint, and let the ACME server compose the two attestations into a certificate-issuance decision.

A third is the short expiry expectation. The document notes that token expiries can be quite short for some applications. In the STI/SHAKEN deployment that motivated this work, tokens are typically minutes-to-hours rather than days-to-weeks. The mechanism is designed for use cases where the client requests certificates frequently, not for long-lived credentials.

Where this document is referenced

  • RFC 9448 is the TNAuthList profile — the document that says what tkvalue looks like for STI certificates and what the Token Authority must verify before issuing the token.
  • draft-ietf-acme-authority-token-jwtclaimcon is an active draft I’m writing that profiles the same Authority Token machinery for certificates carrying JWTClaimConstraints / EnhancedJWTClaimConstraints (the delegation primitives from RFC 8226 and RFC 9118). Same generic substrate, different payload semantics.
  • VESPER, the domain-bound STIR identity extension I’m authoring, recommends both 9448 TNAuthList Authority Tokens and JWTClaimConstraints Authority Tokens as Right-to-Use evidence in delegate-certificate issuance — the 9447 substrate is central to VESPER’s deployment story.
  • For the operational framework these certificates participate in, see SHAKEN.