[Acme] Re: WG Last Call: draft-ietf-acme-authority-token-jwtclaimcon-03 (Ends 2026-07-25)

[Mike Ounsworth <[e-mail]>]

Sorry sorry more:

RFC8725 -- ""JSON Web Token Best Current Practices", BCP 225" is currently
listed as a Normative dependency. Should it be Informative?

I am not well-versed enough in the STIR ecosystem to know for sure, but
given that this is an ACME spec and the Authority Token thing is for
reference only and not to be parsed by the ACME components, I suspect that
a bunch of the STIR references should also be Informative.

On Wed, 9 Sept 2026 at 09:11, Mike Ounsworth <[e-mail]>
wrote:

> Sorry Chris,
>
> More WGLC review.
>
> I asked Claude to review the JSON blobs against RFC 8555. Some findings
> that need looking into:
>
> These are verbatim from Claude.
>
> 1. draft:936-939 — the order object in Section 7 is not valid JSON.
> "identifiers": [
>   "type": "JWTClaimConstraints",
>   "value": "F83n2a...avn27DN3"
> ],
> A JSON array cannot contain name: value pairs. Must be [{"type": ...,
> "value": ...}], as done correctly at lines 219, 246, 296-299 and 773-777.
> This is inherited verbatim from RFC 9448 §7 (a known defect there) — don't
> copy the bug forward.
>
> [MikeO]: I don't see any errata filed on RFC 9448, so I can't confirm or
> reject this finding.
>
>
>
> 2. draft:354-361 — the challenge object omits the required status field.
>
> RFC 8555 §8: challenge objects have type (required), url (required),
> status (required), validated (optional). The example needs "status":
> "pending". Again inherited from RFC 9448 §4.
>
> [MikeO]: That seems right.
>
>
> 3. draft:357 vs draft:400-406 — host mismatch between the challenge URL
> and the POST.
>
> The authz object returns "url": "
> https://boulder.example.com/acme/chall/prV_B7yEyA4", but the client then
> posts to Host: example.com
>
> [MikeO]: That seems right.
>
>
> 4. No "ACME Validation Methods" registration — this one is normatively
> required.
>
> RFC 9447 §3 states plainly:
>
> ▎ "in order to use the 'tkauth-01' Validation Method with an ACME
> Identifier Type other than 'TNAuthList', that identifier type would need to
> be listed in a new registration in the ACME Validation Methods registry
> maintained by IANA."
>
> Section 9 registers only the identifier type. It also needs (RFC 8555
> §9.7.8 template):
>
> ┌───────────┬─────────────────────┬──────┬───────────┐
> │   Label   │   Identifier Type   │ ACME │ Reference │
> ├───────────┼─────────────────────┼──────┼───────────┤
> │ tkauth-01 │ JWTClaimConstraints │ Y    │ RFCThis   │
> └───────────┴─────────────────────┴──────┴───────────┘
>
> Without this, tkauth-01 is not authorized for use with this identifier
> type.
>
> [MikeO]: Cannot confirm or deny.
>
> On Tue, 8 Sept 2026 at 23:46, Mike Ounsworth <[e-mail]>
> wrote:
>
>> Oh, I spoke too soon.
>>
>> It needs to pick the status level within "Standards Track": Proposed
>> Standard, I guess?
>>
>> And this needs a Shepherd Writeup, which is gonna be blocked on me again
>> for a few days (unless someone else wants to write one)
>>
>> On Tue, 8 Sept 2026 at 23:43, Mike Ounsworth <[e-mail]>
>> wrote:
>>
>>> Hi Chris,
>>>
>>> -06 looks good to me. Thanks for working through my (rather large)
>>> review!
>>>
>>> I will advance this past WGLC.
>>>
>>> On Mon, 7 Sept 2026 at 13:44, Chris Wendt <[e-mail]> wrote:
>>>
>>>>
>>>> Darn :)
>>>>
>>>> Submitted -06 to fix it in two places actually.  the step 2 fix you
>>>> suggested and in Section 7 there was a similar certificate mis-reference i
>>>> fixed as well.
>>>>
>>>> Thanks Russ.
>>>>
>>>>
>>>> On Sep 6, 2026, at 1:02 PM, Russ Housley <[e-mail]> wrote:
>>>>
>>>> Chris:
>>>>
>>>> The document says: he Authority Token MUST be signed by a certificate...
>>>>
>>>> Private keys are used to sign objects.  The public key in a certificate
>>>> is used to validate a signature on an object.
>>>>
>>>> Please reword.
>>>>
>>>> Russ
>>>>
>>>>
>>>> On Sep 5, 2026, at 8:14 AM, Chris Wendt <[e-mail]> wrote:
>>>>
>>>> Hi Mike,
>>>>
>>>> Thank you very much for the very comprehensive review.  I’ve created a
>>>> new -05 and corresponding responses inline:
>>>>
>>>> On Sep 2, 2026, at 2:19 PM, Mike Ounsworth <[e-mail]>
>>>> wrote:
>>>>
>>>> [Chair hat on]
>>>> Russ gave a WGLC review from a STIR perspective, and that's great.
>>>> I have been waiting for someone to provide a technical review of the
>>>> implementability from an ACME Client / ACME Server perspective. Since
>>>> nobody has, and it is high-time that we advance this document, I have done
>>>> a review myself. Please take this as you would any other WGLC comments. If
>>>> you feel that these comments do not need to be acted on, then ok.
>>>>
>>>>
>>>> [Chair hat off]
>>>>
>>>>
>>>> GENERAL:
>>>>
>>>> I find the intro is well-written and nicely frames what parts of this
>>>> document are ACME and what are STIR. Well done.
>>>>
>>>> I find that the ACME json payloads are well specified.
>>>>
>>>>
>>>> [cw] Thanks!
>>>>
>>>>
>>>> I find that the target audience of the document is unclear, which makes
>>>> it a bit hard to read because I'm never sure which sections would apply to
>>>> an implementer of an ACME Client / Server, or to an implementer of a Token
>>>> Authority, or both. As an ACME WG document, I expect that the target
>>>> audience is limited to implementers of ACME Clients and Servers, but then
>>>> you do things like explain the token structure in great detail, and then
>>>> say "But ACME Clients and Servers MUST treat this as an opaque byte string,
>>>> MUST NOT parse it, and MUST perform an octet-by-octet match against
>>>> new-order". Ok, so then what was the point of explaining the structure? I
>>>> found that this (apparent) excess of information made the document
>>>> confusing to read from the perspective of an ACME implementer.
>>>> I suggest that the target audience be clearly stated, and the document
>>>> reviewed to remove content not relevant to that audience.
>>>>
>>>>
>>>> [cw] Agreed the document never said who each part is for. -05 adds a
>>>> paragraph at the end of the Introduction. The normative requirements are
>>>> for ACME client and server implementers (the identifier type, the challenge
>>>> and token exchange, the token structure, and the Section 6 validation
>>>> rules), and to the ACME client and server the JWTClaimConstraints value is
>>>> an opaque octet string, transported, compared octet-by-octet, and never
>>>> parsed.
>>>> The paragraph marks the internal structure of that value (Section 5.4,
>>>> the appendix) as informative background for Token Authority implementers.
>>>> That material is in the document because Russ asked for it from the STIR
>>>> side; the audience paragraph is there so an ACME implementer can skip it. I
>>>> kept it for that reason rather than cutting it.
>>>>
>>>>
>>>> Section 6 is the actual good stuff: those are the rules for correctly
>>>> implementing an ACME Server. Really, this and the JSON blobs are the only
>>>> normative parts of the document. The whole security model of the document
>>>> rests on Section 6, so I took a detailed pass and am pointing out a number
>>>> of places that these rules could use tightening up.
>>>>
>>>>
>>>> [cw] Agreed, and that's where most of the -05 changes are.
>>>>
>>>>
>>>> I did not read the appendices.
>>>>
>>>>
>>>> [cw] For reference, the appendix examples were corrected in -04
>>>> following Russ's review (the ASN.1 encodings had bugs); no ACME-implementer
>>>> content there.
>>>>
>>>>
>>>> ISSUES:
>>>>
>>>>
>>>> §6
>>>>
>>>> Error handling: you say at the bottom of this section:
>>>> "If any step of the validation process fails, the "status" in the
>>>> challenge object MUST be set to "invalid".
>>>> And I guess that does specify error handling, but it feels incomplete.
>>>> Is the Server supposed to communicate anything back to the Client (if so,
>>>> which error code?), or fail silently? Is it communicating the same thing
>>>> for all 7 types of failures, or do you want to specify more specific error
>>>> codes? Is the client supposed to take any action(s) based on these error
>>>> codes?
>>>>
>>>>
>>>> [cw] -05 changes the failure sentence. The server sets status to
>>>> "invalid" and SHOULD include an "error" field with an ACME problem document
>>>> (RFC 8555 Section 6.7), unauthorized being the generally-appropriate type,
>>>> and the client handles the failed authorization per RFC 8555. I did not
>>>> give each of the seven failures its own code; they all reduce to "this
>>>> token does not authorize this order."
>>>>
>>>>
>>>>
>>>> 2a. I expected this to say that if a "token-authority" was included in
>>>> the challenge, then this MUST also match". ... otherwise what's the point
>>>> of the "token-authority"? The fact that "token-authority" is not mentioned
>>>> anywhere in §6 is a bit confusing. What's it for then?
>>>>
>>>>
>>>> [cw] "token-authority" (Section 4) is the optional URL the ACME server
>>>> points the client at to fetch the token. It's a client-side hint used
>>>> during token acquisition, not a validation input. In practice the returned
>>>> token is signed by a certificate whose root corresponds to that
>>>> token-authority, so the acquisition URL and the trust anchor line up, and
>>>> §6 establishes trust through that issuer certificate in x5u/x5c (step 2)
>>>> rather than by matching token-authority, which is why 9447 left the
>>>> parameter optional.
>>>>
>>>>
>>>> 2b. I think "trusted issuer" is carrying a lot of weight in this
>>>> sentence, and that should be made explicit. I think it's implied that the
>>>> ACME Server needs to be pre-configured with some trust relationship to that
>>>> Token Authority (name, pub key, root of the x5c chain, something). I think
>>>> that should be called out explicitly here. Also, presumably not just any
>>>> random X.509 cert will do; presumably the signer of the Authority Token
>>>> needs to have all the right EKUs, extensions, whatever to actually be a
>>>> valid Token Authority. Presumably the ACME server needs to check this, or
>>>> the whole security model falls apart? I suggest a sentence of the form
>>>> "This certificate needs to represent a valid Token Authority as per
>>>> {{Section Y of RFCXXXX}}"..
>>>>
>>>>
>>>> [cw]  Agreed. RFC 9447 assumes a preexisting CA<–>Token Authority trust
>>>> relationship and specifies no mechanism; RFC 9448 uses the same "trusted
>>>> issuer for the ecosystem" wording. -05 rewrites step 2: the token MUST be
>>>> signed by a certificate the ACME server is configured to trust as an
>>>> Authority Token issuer for the ecosystem, with the trust anchors and any
>>>> certificate requirements coming from the deploying ecosystem (STIR
>>>> governance), out of scope here.
>>>>
>>>> On the EKU: I think it's a reasonable suggestion, however it doesn't
>>>> belong in this profile alone. Every Authority Token profile, TNAuthList
>>>> (RFC 9448), this one, and future ones, sign tokens with a Token Authority
>>>> certificate, so defining it here would only cover JWTClaimConstraints only
>>>> and diverge from deployed 9448.  We can consider it as an extension to 9447
>>>> perhaps in the future, but would prefer to not force it here.
>>>>
>>>>
>>>> 2c. You have If "x5u" ... Else if "x5c". I think you need an Else
>>>> (neither): fail.
>>>>
>>>>
>>>> [cw] Fixed. Step 2 now fails if neither is present or the certificate
>>>> is not trusted.
>>>>
>>>>
>>>> 6. "(e.g., verify that the token has not expired using the "exp" claim)"
>>>> Remember that section 5 is only the data model and contains no
>>>> validation rules, so I'm not comfortable with a security check that this
>>>> document's whole security model hing on being specified as a "do all the
>>>> things, you know what they are". I think that all of the checks that the
>>>> ACME Server MUST do need to be laid out explicitly here.
>>>>
>>>> This is the first time in the document that you are mentioning that the
>>>> ACME Server needs to check the "exp" claim against its local system clock.
>>>> Is there extra specification required here, like ensuring that the ACME
>>>> server has an accurate clock, or accounting for clock skew? That seems like
>>>> a pretty important thing to be introducing for the first time in a
>>>> non-normative "e.g." block.
>>>>
>>>> What else is covered by that "e.g."? Those need to be listed out
>>>> explicitly, with concrete verification rules.
>>>>
>>>>
>>>> [cw]  Agreed the "e.g." was too loose for a security-critical check.
>>>> -05 makes it more explicit, verify exp is present and not expired against
>>>> the server's current time, MAY allow small clock skew per local policy,
>>>> verify jti is present, and fail on absent/expired exp or absent jti. Those
>>>> are the only "remaining claims" in the profile.
>>>>
>>>>
>>>>
>>>> §7 If I'm understanding this correctly, then in might be worth adding
>>>> "The CA MUST ensure that this x5u URL remains live until the expiry of the
>>>> certificate". I'm not a great expert in the JWT x5u claim, but if there are
>>>> any other requirements in order for the JWT parser to be able to use that
>>>> x5c successfully, then those might be worth dragging in here too.
>>>>
>>>>
>>>>
>>>> [cw] Added, as a SHOULD, the CA SHOULD keep the URL retrievable as long
>>>> as relying parties may need it, at least until the certificate expires.
>>>>
>>>>
>>>> NITS:
>>>>
>>>> Section 1:
>>>>
>>>> "This profile facilitates proper delegation and authorization for
>>>> entities requesting certificates under ACME and similar frameworks."
>>>> This is maybe more of a curiosity question, but what is mean by "...
>>>> and similar frameworks"? Are there other (non-ACME) protocols that you
>>>> expect to normatively reference this draft?
>>>>
>>>>
>>>> [cw]  Removed. "and similar frameworks" the intent was that US STIR
>>>> implementations don't have a MUST to support ACME, but they do rely on
>>>> Authority Tokens even when certificates are issued by alternative protocols
>>>> or methods, so "and similar frameworks" was acknowledging that the
>>>> Authority Token authorization defined here can be used outside ACME. This
>>>> document only specifies the ACME profile, so those cases are out of scope
>>>> for it, which is why I removed the phrase. Separately, other STIR documents
>>>> such as Vesper will normatively reference this one and consume the
>>>> authorization it defines.
>>>>
>>>>
>>>> You could consider adding a glossary, but not necessary.
>>>>
>>>>
>>>> [cw] skipped for now
>>>>
>>>>
>>>> Section 4:
>>>> "If the "token-authority" parameter is not present, the ACME client
>>>> MUST identify the Token Authority based on locally configured information
>>>> or local policies."
>>>> I'm not sure that MUST is doing anything. As a test, if you deleted
>>>> that sentence and left it unspecified, would anything change in terms of
>>>> interop?
>>>> Maybe instead:
>>>> "If the "token-authority" parameter is not present, then this assumes
>>>> that the ACME client has been configured out-of-band with this information."
>>>>
>>>>
>>>> [cw] Reworded to your version and dropped the MUST. Also added a
>>>> sentence that the parameter is advisory to the client and the server
>>>> doesn't use it (the 2a point).
>>>>
>>>>
>>>> § 5.1 -- you might put a note that this section contains the data
>>>> model, while the validation rules follow in §6.
>>>>
>>>>
>>>> [cw] Added — Section 5 is the data model, validation is Section 6.
>>>>
>>>>
>>>> §5.5:
>>>> "a base64url-encoded DER representation of a JWTClaimConstraints or
>>>> EnhancedJWTClaimConstraints ASN.1 object as defined in [RFC8226] and
>>>> [RFC9118]. From the ACME server's perspective this value is opaque:
>>>> validation step 5 in Section 6 requires only that the value in the token is
>>>> octet-by-octet identical to the value in the order. The semantic content of
>>>> the extension — which claims are permitted or excluded, and for which
>>>> telephone numbers — is a STIR ecosystem concern governed by [RFC8226] and
>>>> [RFC9118], and is validated by the Token Authority prior to token issuance
>>>> (see Section 5.3). In particular, the ACME server does not parse or
>>>> cross-check the JWTClaimConstraints and TNAuthList extensions for mutual
>>>> consistency:"
>>>>
>>>> This paragraph is basically the core of the draft. This parahraph could
>>>> be way higher up, like this paragraph could be almost the entirety of the
>>>> Intro.
>>>>
>>>>
>>>> [cw] Took the core of it into the Introduction (the audience paragraph
>>>> with opaque octet string, octet-by-octet, never parsed). Left the fuller
>>>> version in 5.5 where the TNAuthList interaction should have it.
>>>>
>>>>
>>>> §5.4 defines quite nicely what is meant by "a subset of its own
>>>> authority". I was expecting that section to end with the rules for
>>>> determining when a set of {mustInclude, permittedValues, mustExclude} are a
>>>> subset of another, so that the ACME server can enforce that. But instead I
>>>> found:
>>>> "The ACME server then compares the token value to the new-order
>>>> identifier value octet-by-octet (Section 6, step 5) and does not parse or
>>>> interpret the ASN.1 content."
>>>> So then, what's the point of including this detail in this ACME
>>>> document if neither the ACME Client or Server needs to process it (and, in
>>>> fact is forbidden from doing so)?
>>>>
>>>>
>>>> [cw] Same answer as the target-audience point, it's there for the Token
>>>> Authority implementer and based on Russ's review, and the audience
>>>> paragraph now says the ACME server doesn't process it. Kept, labeled
>>>> informative.
>>>>
>>>>
>>>> §5.5
>>>> "The ACME new-order request may include multiple identifiers"
>>>> "a certificate order may require two Authority Token identifier types"
>>>> "Other Authority Token types may be introduced in future Authority
>>>> Token profile specifications"
>>>> I suggest either "MAY" or "can".
>>>>
>>>>
>>>> [cw] Changed the three lowercase "may"s to "can".
>>>>
>>>>
>>>> "The TNAuthList Authority Token authorizes the token holder to obtain
>>>> certificates containing a TNAuthList extension whose scope is less than or
>>>> equal to the scope of the TNAuthList identifier in the token."
>>>> Almost a curiosity question, but is checking and enforcing that the job
>>>> of the Token Authority, or the ACME Server? That sortof goes back to my
>>>> confusion about why §5.4 contains so much detail to then end with
>>>> "octet-by-octet match against the new-order". If this is out-of-scope for
>>>> ACME Clients and Servers, then maybe you could remove this without
>>>> materially changing the document?
>>>>
>>>>
>>>> [cw] It's the Token Authority's job, not the ACME server's meant to be
>>>> informative context. The audience note now frames it that way, so I left it
>>>> in.
>>>>
>>>>
>>>> §5.5.1 -- example of a new-order with both a "TNAuthList" and a
>>>> "JWTClaimConstraints". But can you have more than one of each? Is that
>>>> specifically forbidden somewhere in this doc? Is that forbidden by RFC8555?
>>>> That's probably worth mentioning either way.
>>>>
>>>>
>>>> [cw] -05 adds that a new-order request contains at most one
>>>> JWTClaimConstraints identifier and at most one TNAuthList identifier.
>>>>
>>>>
>>>> 7. "matches the account key of the client"
>>>> Just to be super clear, I could say "ACME account key as defined in
>>>> {{Section 8.2 of RFC8555}}". I honestly got this far in the document
>>>> thinking that this was a fingerprint that needed to match the CSR (though,
>>>> going back, I see that §5.1.4 was clear about this, I just skimmed over it).
>>>>
>>>>
>>>> [cw] Added a reference to the ACME account key in RFC 8555. One note:
>>>> Section 8.2 is "Retrying Challenges”, the account key is the account object
>>>> (Section 7.1.2). I referenced 8555 generally.
>>>>
>>>>
>>>> §6
>>>> "Steps 1 through 3 and steps 6 through 8 are general ACME authority
>>>> token validation steps applicable to any Authority Token profile."
>>>> Just to be clear, that applicable to any STIR Authority Token profile,
>>>> still not generic ACME behaviour? I would throw the word STIR or something
>>>> into that sentence.
>>>>
>>>>
>>>> [cw] Changed to "any STIR Authority Token profile," and noted it
>>>> mirrors the TNAuthList validation in RFC 9448.
>>>>
>>>>
>>>>
>>>> §8
>>>> "The creation, transport, and any storage of this token MUST follow the
>>>> strictest of security best practices"
>>>> That is a completely empty MUST in that it doesn't tell me anything
>>>> actionable as an implementer. Like, a MUST should generally be something
>>>> that I could write tests for and easily check if an implementation is in
>>>> compliance or not. Do you have a BCP or RFC that you can point at? "MUST
>>>> ... best practices according to [Thing]"? If not, I would remove the
>>>> normative MUST from this sentence.
>>>>
>>>>
>>>> [cw] Reworded. Dropped "strictest of security best practices," pointed
>>>> at RFC 8725 (JWT BCP) and the RFC 9447 security considerations, and kept
>>>> the MUST only on the encrypted transport already required by the document.
>>>>
>>>>
>>>> I love the reference to [RFC6943]. That's great.
>>>>
>>>>
>>>> [cw] Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, 2 Sept 2026 at 07:49, Chris Wendt <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi ACME chairs,
>>>>>
>>>>> Just wanted to check in to see if we have satisfied the WG Last Call
>>>>> review and can proceed forward?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -Chris
>>>>>
>>>>> On Jul 26, 2026, at 3:20 AM, Russ Housley <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> My comments are resolved.
>>>>>
>>>>> Russ
>>>>>
>>>>> On Jul 25, 2026, at 10:13 AM, Chris Wendt <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I've posted -04.
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-jwtclaimcon-04
>>>>>
>>>>> Summary of the changes:
>>>>>
>>>>> Addressing Russ Housley's review of Section 5.4:
>>>>>
>>>>> Expanded "Scope of the JWTClaimConstraints" to describe the constraint
>>>>> components
>>>>>
>>>>> - mustInclude (claim names that MUST be present)
>>>>> - permittedValues (the values a given claim is permitted to take)
>>>>> - mustExclude (claim names that MUST NOT appear, available only in
>>>>> EnhancedJWTClaimConstraints per RFC 9118)
>>>>>
>>>>> and noted that the enhanced form with mustExclude is only needed when
>>>>> the optional ("extended") claims must be constrained.
>>>>>
>>>>> Based on my discussion with Russ I also made the sure the model is
>>>>> explicit that the Token Authority validates the requested
>>>>> JWTClaimConstraints value against what the requester is authorized to
>>>>> include, explicitly equal or a subset of that (not a superset) and places
>>>>> that validated ASN.1 value in the token. Then it’s clear that the ACME
>>>>> server then only compares the token value to the new-order identifier
>>>>> octet-by-octet and never need to evaluate or parse the ASN.1.
>>>>>
>>>>> Two bonus updates:
>>>>>
>>>>> Example 3: added a clearer description of constraining the "orig"
>>>>> claim to a specific set of telephone numbers, along with a note in Section
>>>>> 5.5 on why the CA does not need to cross-check the JWTClaimConstraints
>>>>> against the TNAuthList: an inconsistent pair simply fails PASSporT
>>>>> verification for all calls, so authority and accountability stay with the
>>>>> CSR requester to make sure they apply both Authority Tokens correctly as a
>>>>> pair.
>>>>>
>>>>> I rechecked and fixed the appendix example values to conform to the
>>>>> RFC 9118 ASN.1: mustExclude values are now wrapped in the required
>>>>> SEQUENCE, and permittedValues entries covering more than one claim are now
>>>>> encoded as one JWTClaimValues per claim.
>>>>> The DER hex, base64url, and byte counts were regenerated based on that.
>>>>>
>>>>> Comments welcome, but hopefully that satisfies the WGLC end date today.
>>>>>
>>>>> Thanks and good to see everyone this past week.
>>>>>
>>>>> -Chris
>>>>>
>>>>> On Jul 23, 2026, at 10:11 AM, Chris Wendt <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> Thanks Russ for the review.
>>>>>
>>>>> I agree with that comment and will address it.
>>>>>
>>>>> -Chris
>>>>>
>>>>> On Jul 23, 2026, at 2:52 PM, Russ Housley <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> I have read the document, and I support publication, but I think a
>>>>> shortcoming needs to be addressed before it is passed to the IESG.
>>>>>
>>>>> Section 5.4 says:
>>>>>
>>>>> Because this specification involves the JWTClaimConstraints and
>>>>> EnhancedJWTClaimConstraints extensions, the client MAY request an Authority
>>>>> Token with some subset of its own authority as the JWTClaimConstraints
>>>>> provided in the "tkvalue" element of the "atc" JSON object.
>>>>> JWTClaimConstraints can be constructed to define a limited scope of claims
>>>>> and claim values the client has authority over.
>>>>>
>>>>>
>>>>> This is correct, but I think a few more details are needed.
>>>>>
>>>>> JWTClaimConstraints specifies claim names that must be included
>>>>> (mustInclude) and it specifies values that are allowed in particular claims
>>>>> (permittedValues). All of the mustInclude need to be in the token.  Each
>>>>> value in the token need to be in the pmittedValues. In this way, the token
>>>>> satisfies the constraints, and a particular certificate can be issued that
>>>>> is a subset of those authorizations.
>>>>>
>>>>> The structure for EnhancedJWTClaimConstraints is a bit more complex.
>>>>> It also has claim names that MUST NOT appear (mustExclude). I would expect
>>>>> all of these to be in the token.
>>>>>
>>>>> Russ
>>>>>
>>>>> On Jul 2, 2026, at 6:03 PM, Mike Ounsworth via Datatracker <
>>>>> [e-mail]> wrote:
>>>>>
>>>>> This message starts a WG Last Call for:
>>>>> draft-ietf-acme-authority-token-jwtclaimcon-03
>>>>>
>>>>> This Working Group Last Call ends on 2026-07-25
>>>>>
>>>>> Abstract:
>>>>> This document defines an authority token profile for the validation
>>>>> of JWTClaimConstraints and EnhancedJWTClaimConstraints certificate
>>>>> extensions within the Automated Certificate Management Environment
>>>>> (ACME) protocol.  This profile is based on the Authority Token
>>>>> framework and establishes the specific ACME identifier type,
>>>>> challenge mechanism, and token format necessary to authorize a client
>>>>> to request a certificate containing these constraints.
>>>>>
>>>>> File can be retrieved from:
>>>>>
>>>>> https://www.ietf.org/archive/id/draft-ietf-acme-authority-token-jwtclaimcon-03.txt
>>>>>
>>>>> Please review and indicate your support or objection to proceed with
>>>>> the
>>>>> publication of this document by replying to this email keeping
>>>>> [e-mail]
>>>>> in copy. Objections should be explained and suggestions to resolve
>>>>> them are
>>>>> highly appreciated.
>>>>>
>>>>> Authors, and WG participants in general, are reminded of the
>>>>> Intellectual
>>>>> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
>>>>> Appropriate IPR disclosures required for full conformance with the
>>>>> provisions
>>>>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
>>>>> Sanctions available for application to violators of IETF IPR Policy
>>>>> can be
>>>>> found at [3].
>>>>>
>>>>> Thank you.
>>>>>
>>>>> [1] https://datatracker.ietf.org/doc/bcp78/
>>>>> [2] https://datatracker.ietf.org/doc/bcp79/
>>>>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>>>>
>>>>> The IETF datatracker status page for this Internet-Draft is:
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-jwtclaimcon/
>>>>>
>>>>> There is also an HTMLized version available at:
>>>>>
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-jwtclaimcon-03
>>>>>
>>>>> A diff from the previous version is available at:
>>>>>
>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-authority-token-jwtclaimcon-03
>>>>>
>>>>> _______________________________________________
>>>>> Acme mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Acme mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Acme mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>
>>>> _______________________________________________
>>>> Acme mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>> _______________________________________________
>>>> Acme mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>>