Summary

  • token-authority is an optional client-discovery hint. It is not the ACME server’s trust anchor; issuer trust comes from configured ecosystem policy and the certificate referenced through x5u or x5c.
  • The server is meant to treat JWTClaimConstraints as an opaque string and compare the order’s value with the token’s tkvalue byte for byte, without decoding, normalising or reconstructing either side.
  • A valid challenge requires separate receipts for the issuer, signature, token type, exact bytes, exp, jti, ACME account key and CSR CA role. Issuance still does not prove later JWS verification or a telephone-call outcome.

A useful URL with no vote on trust

The optional token-authority field looks authoritative because its name contains the word. Its function is narrower. An ACME client may use the URL in a tkauth-01 challenge to find the Token Authority from which it should request a JWTClaimConstraints Authority Token. If the field is absent, the client is expected to have learned that location out of band.

Revision 05 makes the negative rule just as important as the positive one: the ACME server does not use that URL when it validates the challenge response. A location offered to a client is not evidence that the signer at that location belongs inside the server’s trust set.

The trust decision arrives through a different path. The Authority Token must be signed by a certificate that the server is configured to trust as an Authority Token issuer for the relevant ecosystem. The token can point to that certificate with an HTTPS x5u header or carry certificate material in x5c. If neither is present, or if the certificate does not hold the configured issuer role, validation fails. The optional iss claim may identify an issuer, but naming an issuer is not the same operation as trusting its certificate.

This distinction is operationally valuable because discovery and authorization change for different reasons. A client endpoint may move for availability or routing reasons while the trusted issuer set stays fixed. A governance decision may change the issuer set while the discovery URL remains reachable. Joining the two into one configuration field would turn a service-location update into an invisible trust change.

The ACME server carries meaning without interpreting it

The new-order identifier’s value is the unpadded base64url encoding of a DER-encoded JWTClaimConstraints or EnhancedJWTClaimConstraints ASN.1 object. The Authority Token repeats that value in atc.tkvalue and labels the token type as JWTClaimConstraints.

Inside the constraint are STIR-specific claims and limits. Yet revision 05 says the ACME client and server treat the value as opaque. The Token Authority decides whether the requested constraint is consistent with the resources and claims the requester may represent under RFC 8226 and RFC 9118. The ACME server’s job is not to redo that semantic decision. Its job is to prove that the exact value the Token Authority signed is the exact value attached to the original order.

That is a minimum shared specification rather than an absence of validation. The components agree on one canonical carriage form and one equality operation. They leave ecosystem-specific semantic policy with the party that actually has the authorization context.

Equality has one spelling

DER and unpadded base64url together give the draft a canonical octet sequence. The server must compare the two base64url strings directly. It must not decode and re-encode them, normalise them, canonicalise them again or decide that two different encodings are semantically equivalent.

Padding, a character outside the base64url alphabet, embedded whitespace, an alternate alphabet, non-DER BER or any different octet is a failure. Revision 05 also recommends constant-time comparison as a conservative implementation practice even though the compared values are not secret.

The point is not aesthetic purity. Every permissive transformation creates a second authority surface: the code that decides which differences do not matter. Exact comparison keeps that policy out of the ACME verifier. It also makes the evidence legible. An operator can retain the hash and length of both received strings and prove whether the original order and the returned token met at precisely the same value.

Eight checks, not one green lamp

The validation sequence can be read as eight separate receipts. First, atc must be a well-formed object with tktype, tkvalue and fingerprint. Second, the signing certificate must have the configured issuer role and arrive through acceptable x5u or x5c material. Third, the signature must verify. Fourth, the token type must be JWTClaimConstraints. Fifth, the opaque value must match the original order byte for byte.

Sixth, exp must exist and remain current under the server’s clock and local skew policy, while jti must exist. Seventh, the embedded fingerprint must match the ACME account key used by the client making the request. Eighth, the token’s ca value must correspond to the Basic Constraints CA boolean in the certificate signing request.

The fingerprint’s route is especially revealing. The Token Authority is not asked to verify that it proves account control. It signs the fingerprint into the token so the ACME server can later join the token to the party controlling the ACME account key. The semantic authority and the account-control verifier contribute different evidence.

If any check fails, the challenge becomes invalid and the server may return an ACME authorization error. A single “token invalid” counter would preserve the outcome while destroying the mechanism. Operations need to know whether the failure was trust, retrieval, signature, exact identity, time, transaction identity, account binding or certificate role.

Issuance is not the end of the chain

After authorization, certificate issuance remains a separate ACME operation. The draft also allows a CA to put an optional x5u into a successful order response so that the certificate owner can reference the issued certificate in later JWS objects. The CA should keep this URL retrievable while relying parties may need it, typically at least through certificate expiry.

That later x5u is not the same evidence as the issuer-certificate reference used to validate the Authority Token. They belong to different stages, may be operated by different systems and have different retention obligations. A successful issuance record does not prove that a relying party later retrieved the certificate, accepted it or accepted any signed call assertion.

What the revision does not establish

The document is a working-group Internet-Draft posted on 5 September 2026 and expires on 9 March 2027 unless updated. It can change or fail to become an RFC. No public source in this packet proves that a CA or Token Authority has deployed revision 05, that any implementation passes these checks, that certificates have been issued under the profile, or that it reduces fraud.

No client, server, runtime, repository, carrier or call path was tested for this report. RFC text establishes a proposed contract, not its execution. Telephone-number authority, call authentication, PASSporT acceptance and reader-visible verification remain later facts that require their own evidence.

Sources