draft-ietf-acme-authority-token-jwtclaimcon — JWTClaimConstraints profile of ACME Authority Token

draft-ietf-acme-authority-token-jwtclaimcon (Wendt, Hancock) defines a JWTClaimConstraints profile of the ACME Authority Token framework. I co-author with David Hancock. Currently -01 (26 March 2026). Working group document in the IETF ACME working group (not STIR — though the use case is STIR-aligned). The draft name on datatracker is truncated: the full conceptual name is “JWTClaimConstraints profile of ACME Authority Token”, but the datatracker slug abbreviates to jwtclaimcon.

What this draft specifies

The draft extends RFC 9447 (ACME Challenges Using Authority Token) with a new token type — the JWTClaimConstraints Authority Token — whose payload carries a set of JWTClaimConstraints as defined in RFC 9118 (Enhanced JWT Claim Constraints for STIR Certificates). When the token is presented during ACME issuance, it instructs the issuing certification authority to include the corresponding JWTClaimConstraints extension in the issued certificate.

The model parallels the existing TNAuthList profile of ACME Authority Token (RFC 9448), where a TNAuthList Authority Token issued by a Right-to-Use authority instructs the CA to include a TNAuthList extension binding the certificate to specific telephone-number authority. This new profile does the same job for JWTClaimConstraints — letting an authority assert what PASSporT claims (and what specific values within those claims) the issued certificate is authorized to sign for, with the assertion verifiably embedded in the certificate at issuance time.

Why JWTClaimConstraints in ACME

JWTClaimConstraints (RFC 9118) is an X.509 certificate extension that constrains which PASSporT claims and which specific claim values the holder of the certificate is authorized to sign. The extension is particularly relevant for delegate certificates (RFC 9060) where a parent CA wants to issue a subordinate certificate that’s restricted to specific operational scope — not just specific telephone numbers, but specific PASSporT content.

Before this draft, there was no standardized ACME mechanism for authoritatively conveying JWTClaimConstraints to a CA at issuance time. CAs could populate JWTClaimConstraints in certificates they issued, but the binding between the authority’s intent and what ended up in the certificate extension wasn’t carried in a verifiable token. This draft closes that gap: a JWTClaimConstraints Authority Token signed by the appropriate authority makes the claim-constraint scope verifiable end-to-end through the issuance flow.

Relevance to VESPER

VESPER’s certificate profile uses JWTClaimConstraints as an optional extension on delegate certificates — bounding what PASSporT content the certificate can sign for. VESPER’s issuance flow (described in draft-wendt-stir-vesper) extends ACME with both TNAuthList Authority Tokens (per RFC 9448) and JWTClaimConstraints Authority Tokens (per this draft). A VESPER delegate certificate can therefore be issued with both its TN authority and its claim-constraint scope bound at issuance time, with both bindings carried by signed authority tokens that the CA can verify before issuing.

Relevance to Rich Call Data

The Rich Call Data topic page covers the use case where JWTClaimConstraints prevents unauthorized RCD content. When a delegate certificate is issued to an enterprise authorized to sign with specific RCD content (brand information, logo URI, jurisdiction data, etc.), a JWTClaimConstraints Authority Token can constrain the certificate to only signing PASSporTs containing the authorized RCD claim values — closing the attack surface where a delegate cert holder might otherwise insert arbitrary RCD content into a signed PASSporT.

Status

Currently draft-ietf-acme-authority-token-jwtclaimcon-01, working group document in the ACME WG. The draft has been adopted by the WG and is progressing through normal IETF process — earlier individual draft work goes back several years; the WG version is more recent. Once published as an RFC, it will become the standard mechanism for binding JWTClaimConstraints into ACME-issued certificates, completing the ACME-for-STIR toolset alongside RFC 9447 (the framework) and RFC 9448 (the TNAuthList profile).