Summary

  • Revision 05 of the JWTClaimConstraints Authority Token profile says ACME clients and servers transport and compare an opaque DER-encoded constraint; they do not interpret its domain-specific meaning.
  • The Token Authority performs that semantic assessment, while the deploying ecosystem decides which Token Authority issuer certificates an ACME server is configured to trust.
  • The optional token-authority URL helps a client find a token source. The ACME server ignores that hint during validation and instead requires a trusted issuer certificate referenced through x5u or x5c.
  • The document remains an Internet-Draft in the ACME Working Group. A valid token proves conformance to listed checks, not the issuer's legal identity, universal entitlement or correctness in every policy context.

The revision assigns three different jobs

The authors announced revision 05 on 5 September 2026 after an ACME chair review asked who the normative requirements addressed and how implementations should treat several fields. Chris Wendt's response and change record says the revision clarifies the audience, issuer trust and the handling of token-authority.

The profile concerns Secure Telephone Identity certification authorities. It uses ACME to validate authority over a JWTClaimConstraints certificate extension, which can limit claims that a credential may assert. RFC 9448 defines that extension; RFC 8226 and RFC 9118 supply the surrounding certificate and claim-constraint rules. The draft is about automating proof during certificate issuance, not about letting ACME invent the policy itself.

Revision 05 separates the work among three actors. An ACME client carries the identifier and obtains a token. The ACME server verifies the challenge response. A Token Authority decides whether the requested constraint makes sense under the relevant domain policy and issues the signed authorization token.

That separation is encoded in the value itself. For the ACME client and server, the DER value inside the identifier is an opaque octet string rendered with base64url. They transport it and compare it exactly, octet by octet. They never parse mustInclude, permittedValues or mustExclude to decide whether the requested combination is appropriate. Domain-specific semantic validation belongs to the Token Authority.

This is a useful refusal of authority. ACME's base protocol automates certificate management, but automation does not turn a general-purpose challenge server into the institution that governs telephone-number claim constraints. Mechanical agreement and policy entitlement are different propositions.

A discovery hint is not a trust root

The distinction becomes sharper around two easily confused fields. The optional token-authority parameter gives the client an advisory location from which it may acquire a token. It is client-side discovery information. Revision 05 says the server does not use that value when validating the challenge response.

Issuer evidence arrives inside the token through x5u or x5c. Neither may be absent. The server retrieves or reads the referenced certificate, verifies the token signature and checks that the certificate is one it has been configured to trust as an Authority Token issuer for this ecosystem. A certificate reference is therefore not self-authorizing. Configuration supplies the trust decision.

Who controls that configuration is outside the draft. The text says trust anchors and any ecosystem-specific requirements for Token Authority certificates are established by the deploying ecosystem, giving STIR governance as an example. It does not identify one global authority or define the process for admission, suspension, revocation or appeal.

That choice matches the predecessor mechanism. RFC 9447, which is already Standards Track, assumes pre-existing relationships between the certification authority and Token Authority and between the client and Token Authority. It says the challenge has no applicability where those relationships cannot be assumed. Revision 05 specifies a new claim-constraint profile over that architecture; it does not remove the institutional premise.

The server proves consistency, freshness and binding

Once a trusted issuer has been configured, the server still has substantial work. It checks the token structure and type, verifies the signature, requires exp and rejects an expired token, requires jti, and confirms that the token is bound to the ACME account key that requested the order. It checks that the ca flag agrees with the type of certificate requested.

It also compares the token's constraint value with the identifier's value exactly. A failed step makes the challenge invalid; the server should return an ACME problem document, generally using unauthorized. These checks prevent one token from being casually replayed for another account, another request shape or another constraint byte string.

What they do not prove is equally important. A current exp says the assertion is fresh enough under the profile. A valid signature says the holder of the corresponding key signed it. Exact bytes say the authorization and order refer to the same encoded constraint. None explains why the ecosystem enrolled the issuer, which policy version defined its remit, or whether the Token Authority's semantic judgment was correct.

The current Datatracker record labels the document active and In WG Last Call, with IESG state I-D Exists. It lists no document shepherd, responsible Area Director or telechat date. The earlier call stated a 25 July closing date; the tracker label should not be read as evidence that comments remain open. Most importantly, revision 05 is not an approved RFC, implementation report or proof of deployment.

The revision makes two further operational choices. A single ACME order may contain at most one JWTClaimConstraints identifier and at most one TNAuthList identifier. For an issued certificate, its x5u URL should remain retrievable while relying parties may need it, normally at least until expiry. That retention instruction helps later verification, but it does not document the governance decision that caused the issuer certificate to be trusted.

The thin missing record is a constraint-authority receipt

The deploying ecosystem needs a joinable record for that decision. It need not expose telephone numbers or the raw private constraint. A constraint-authority receipt could bind the ecosystem policy identifier and version, the Token Authority identity and trusted certificate fingerprint, the admitted constraint family and delegated scope class, and a hash of the ACME order and encoded constraint.

It should also record token issue, decision and expiry times; outcome and a bounded failure class; the trust entry's effective and revocation state; and a correction, incident or appeal contact. A final field should state plainly that successful protocol validation is not a universal verdict on legal identity, caller truth or entitlement beyond the named ecosystem.

This receipt is my proposal, not an IETF requirement. It should be emitted from the real trust-policy system rather than copied into a ceremonial registry. The purpose is modest: let an auditor connect a valid exchange to the policy and authority that made it valid, without publishing the sensitive order contents.