ACME Working Group S. Rasmussen Internet-Draft Independent Intended status: Standards Track 6 October 2026 Expires: 9 April 2027 A Federated Workload Identity Challenge for the Automated Certificate Management Environment (ACME) draft-rasmussen-acme-wif-00 Abstract The Automated Certificate Management Environment (ACME, RFC 8555) establishes that a requester has authority over an identifier by means of a challenge that demonstrates control of that identifier, such as publishing a DNS record or serving an HTTP resource. It authenticates the requester by means of an account key whose provenance is outside the protocol's scope. Neither mechanism is a good fit for automated workloads running in continuous-integration systems, container orchestrators, and cloud compute platforms. Such workloads typically possess no long-lived secret and no ability to publish DNS records, but they do possess a short-lived, cryptographically verifiable identity assertion issued by their execution platform. This document defines a new ACME challenge type, "wif-01", by which an ACME server authorizes issuance for an identifier on the basis of a platform-issued identity token. The token is bound to the ACME account key, and to the specific authorization it satisfies, using the token's audience claim. The mechanism therefore requires no new claims, no new endpoints, and no changes of any kind to existing identity providers. Because the workload's identity is established for each authorization, the mechanism also removes any need for External Account Binding: an ordinary ACME account, created by the workload with no pre-shared secret, suffices. The mechanism uses only extension points that ACME already defines. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Rasmussen Expires 9 April 2027 [Page 1] Internet-Draft ACME Workload Identity Challenge October 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Design Constraints . . . . . . . . . . . . . . . . . . . 5 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Relationship to Other Work . . . . . . . . . . . . . . . 7 1.5. Conventions and Definitions . . . . . . . . . . . . . . . 8 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Participants . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Design Principles . . . . . . . . . . . . . . . . . . . . 10 3. The Audience Binding Value . . . . . . . . . . . . . . . . . 11 3.1. Construction . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Binding Requirement . . . . . . . . . . . . . . . . . . . 12 4. The "wif-01" Challenge Type . . . . . . . . . . . . . . . . . 13 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Challenge Object . . . . . . . . . . . . . . . . . . . . 14 4.3. Client Behaviour . . . . . . . . . . . . . . . . . . . . 14 4.4. Server Validation . . . . . . . . . . . . . . . . . . . . 15 4.5. Lifetime and Reuse of Federated Authorizations . . . . . 17 Rasmussen Expires 9 April 2027 [Page 2] Internet-Draft ACME Workload Identity Challenge October 2026 4.6. Retrieval and Caching of Issuer Keys . . . . . . . . . . 18 4.7. Error Types . . . . . . . . . . . . . . . . . . . . . . . 18 5. Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. External Account Binding Is Not Required . . . . . . . . 19 5.2. Coexisting with External Account Binding . . . . . . . . 20 5.3. Ephemeral Accounts . . . . . . . . . . . . . . . . . . . 20 6. Directory Metadata . . . . . . . . . . . . . . . . . . . . . 21 7. Identity Provider Requirements . . . . . . . . . . . . . . . 22 8. Authorization Policy . . . . . . . . . . . . . . . . . . . . 23 8.1. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Policy Is Not Disclosed, and Is Not Secret . . . . . . . 24 8.3. Recommendations for Policy Authors . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9.1. ACME Validation Methods . . . . . . . . . . . . . . . . . 25 9.2. ACME Error Types . . . . . . . . . . . . . . . . . . . . 25 9.3. ACME Directory Metadata Fields . . . . . . . . . . . . . 26 9.4. Challenge Object Fields and URN Label . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10.1. The Audience Binding Is Load-Bearing . . . . . . . . . . 27 10.2. Use of the "aud" Claim . . . . . . . . . . . . . . . . . 27 10.3. Issuer Allowlisting Is Not Authorization . . . . . . . . 28 10.4. Mutable and Reassignable Claims . . . . . . . . . . . . 29 10.5. Execution Context . . . . . . . . . . . . . . . . . . . 29 10.6. Server-Side Request Forgery and Issuer Metadata . . . . 30 10.7. Policy Enumeration . . . . . . . . . . . . . . . . . . . 30 10.8. Denial of Service . . . . . . . . . . . . . . . . . . . 31 10.9. Cryptographic Agility and Algorithm Confusion . . . . . 31 10.10. Token Handling by Clients . . . . . . . . . . . . . . . 32 10.11. Relationship to Proof of Control . . . . . . . . . . . . 32 10.12. Claims in Certificates . . . . . . . . . . . . . . . . . 32 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Provider Profiles . . . . . . . . . . . . . . . . . 38 A.1. GitHub Actions . . . . . . . . . . . . . . . . . . . . . 38 A.2. Kubernetes and SPIFFE . . . . . . . . . . . . . . . . . . 39 A.3. Amazon Web Services . . . . . . . . . . . . . . . . . . . 39 A.4. Microsoft Azure . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Worked Example . . . . . . . . . . . . . . . . . . . 40 Appendix C. Comparison with the ACME Authority Token . . . . . . 42 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 Rasmussen Expires 9 April 2027 [Page 3] Internet-Draft ACME Workload Identity Challenge October 2026 1. Introduction 1.1. Motivation A certificate issuance system must answer two questions: who is asking, and are they entitled to the identifier they are asking for. ACME [RFC8555] answers the second question with challenges that demonstrate practical control over the identifier -- the ability to publish a DNS TXT record under the name, or to serve a resource at the name over HTTP. It largely declines to answer the first: an ACME account is identified by a key pair the client generates for itself, and RFC 8555 places no requirement on where that key came from. Where a Certification Authority (CA) does need to know who its subscriber is, RFC 8555 Section 7.3.4 provides External Account Binding (EAB), in which the CA issues the subscriber a key identifier and a MAC key out of band. Both answers assume a deployment shape that has become less common. A workload running in a CI/CD pipeline or a container orchestrator is typically: * ephemeral, with no persistent filesystem across executions and therefore nowhere to keep an ACME account key between runs; * unable to publish DNS records or serve HTTP on the name it needs a certificate for, because the name belongs to a service the workload is building or deploying rather than one it is running; * explicitly designed to hold no long-lived secrets, because secret distribution to ephemeral compute is the problem its operators are trying to eliminate; and * already in possession of a short-lived, asymmetrically signed identity assertion, issued automatically by the execution platform, that names the workload with considerable precision. That last property is the opportunity. Every major compute and CI platform now issues such an assertion, in the form of a JSON Web Token [RFC7519] signed with a key published at a well-known JWKS endpoint, and permits the relying party to verify it using OpenID Connect Discovery [OIDC-DISCOVERY]. The industry term for consuming such an assertion is "workload identity federation", abbreviated in this document as WIF. Operators currently bridge the gap between a WIF token and an ACME client by running a private broker: a service that verifies the platform token and hands back an EAB key identifier and MAC key, or Rasmussen Expires 9 April 2027 [Page 4] Internet-Draft ACME Workload Identity Challenge October 2026 that issues a certificate directly through a non-ACME interface. Every such broker is a bespoke, unaudited reimplementation of the same token-validation and policy-mapping logic, and the resulting deployments are not interoperable with each other or with off-the- shelf ACME clients. This document specifies that bridge once, and without the EAB credential the broker exists to mint: the Workload's identity is checked at the point where each identifier is authorized, so the account needs no binding at all. 1.2. Design Constraints The central design constraint is that identity providers cannot be changed. GitHub, Amazon Web Services, Microsoft Azure, Google Cloud, and Kubernetes each issue tokens with a claim set they control. A specification that requires a new claim, a new endpoint, or a new token type from those providers will not be deployable, regardless of its technical merits. This rules out the obvious approach of reusing the ACME Authority Token [RFC9447], which requires the token to carry an "atc" claim containing a fingerprint of the ACME account key (Section 3.3 of [RFC9447]). No general purpose identity provider will emit such a claim, and none can, because the provider has no knowledge of the ACME account key. Appendix C discusses the relationship in more detail. The obstacle is not that the binding value means anything to the token issuer. [I-D.ietf-acme-authority-token-jwtclaimcon] is explicit that it does not: the fingerprint "is not meant to be verified by the Token Authority", but only signed as part of the token, so that the ACME server can establish that the party which requested the token is the party presenting it. The obstacle is that an opaque value must still be accepted by the issuer as an input and emitted as a claim, and a general-purpose identity provider does neither. Its claim set is fixed and its inputs are few. What every provider does permit is control over the token's audience: the workload requests a token for a specific relying party, and the provider places that value in the "aud" claim. This document therefore carries the binding to the ACME account key in the audience, using a value derived from the existing key authorization construction of Section 8.1 of [RFC8555]. The result requires nothing of the identity provider that it does not already do. Rasmussen Expires 9 April 2027 [Page 5] Internet-Draft ACME Workload Identity Challenge October 2026 A secondary constraint is that authorization policy -- which workload may obtain a certificate for which identifier -- is a CA configuration matter and varies enormously between deployments. This document specifies the mechanism by which a token is validated and bound, and the abstract model by which claims are mapped to permitted identifiers, but deliberately does not specify the policy language. Section 8 discusses the boundary. 1.3. Scope This document defines: * a new ACME challenge type, "wif-01" (Section 4), by which an ACME server may mark an authorization valid on the basis of a WIF token rather than a demonstration of identifier control; * the audience binding construction (Section 3) that ties a WIF token to a specific ACME account key and to a specific authorization; * the lifetime rule (Section 4.5) that keeps a federated authorization from outliving the assertion that produced it; * the account model (Section 5) under which an ordinary ACME account, created without External Account Binding, is sufficient; and * directory metadata (Section 6) by which a server advertises which identity providers it accepts and under what conditions. This document does not define a policy language, a certificate profile, or a mechanism for provisioning trust in an identity provider. It does not replace proof-of-control challenges; a CA may reasonably require both. Everything this document adds to ACME uses an extension point that [RFC8555] already provides: one validation method, five error types, and one directory metadata field, each entered in the registry Section 9.7 of [RFC8555] established for it; a challenge type, whose object fields are defined with it as Section 8 of [RFC8555] anticipates; and a label beneath the "urn:ietf:params:acme" namespace (Section 9.6 of [RFC8555]). It changes no existing request, resource, or state transition. Rasmussen Expires 9 April 2027 [Page 6] Internet-Draft ACME Workload Identity Challenge October 2026 1.4. Relationship to Other Work ACME Authority Token [RFC9447] and its TNAuthList profile [RFC9448] define a challenge in which a Token Authority, in a pre-existing business relationship with the CA, issues a purpose-built JWT authorizing a specific ACME account to obtain a specific identifier. The present document addresses the case where the token issuer is a general-purpose identity provider that has no relationship with the CA, no knowledge of ACME, and no ability to emit ACME-specific claims. See Appendix C. [I-D.ietf-acme-authority-token-jwtclaimcon] is a second profile of that challenge, and is easily mistaken for the present work because it also has an ACME server act on a JWT minted elsewhere. It is a different mechanism for a different purpose. What it authorizes is a certificate extension rather than a name: the ACME identifier is the base64url DER encoding of a requested JWTClaimConstraints [RFC8226] or EnhancedJWTClaimConstraints [RFC9118] extension, a Token Authority in the Secure Telephone Identity ecosystem attests that the requester may assert those constraints, and the constraints appear in the issued certificate. It carries the "atc" fingerprint binding of [RFC9447], and so falls under the constraint of Section 1.2 exactly as the TNAuthList profile does. Nothing in this document interacts with it, and a CA may implement both. ACME with OpenID Federation [I-D.ietf-acme-openid-federation] shares a word with this document and little else. It establishes trust in a requester through OpenID Federation 1.0: entity statements, trust chains resolved to a trust anchor, and metadata published by the requesting organization about itself. The present document uses no federation metadata and no trust chains. It accepts an ordinary OpenID Connect-style identity token that a compute platform issues to a workload, verified against a key set the CA operator has chosen to trust directly. The two address different deployments and do not interact. ACME Remote Attestation [I-D.ietf-acme-rats] defines a challenge carrying RATS evidence in a Conceptual Message Wrapper. That mechanism attests to the properties of a platform, typically rooted in hardware; this one conveys an administratively assigned identity. The two are complementary, and a CA concerned with both platform integrity and workload identity might require both. WIMSE Workload Credentials [I-D.ietf-wimse-workload-creds] defines the Workload Identity Token and Workload Identity Certificate formats but places the protocol for obtaining them explicitly out of scope. This document may be read as one such protocol. Rasmussen Expires 9 April 2027 [Page 7] Internet-Draft ACME Workload Identity Challenge October 2026 1.5. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are used: Workload: A unit of executing software that requires a certificate. Examples include a job in a CI/CD pipeline, a container in an orchestrated cluster, and a virtual machine instance. Identity Provider (IdP): The service that issues an identity assertion to the Workload on the basis of the Workload's execution context. The IdP is operated by the compute or CI platform, not by the CA and not necessarily by the subscriber. WIF Token: A JWT [RFC7519] issued by an Identity Provider to a Workload, signed using a digital signature algorithm, and verifiable using a key published by the IdP. Subscriber: The entity that has an administrative relationship with the CA and on whose behalf certificates are issued. The Subscriber configures the CA's authorization policy. The Subscriber and the Workload operator are usually, but not necessarily, the same organization. Under this document the relationship is recorded in the policy entries the Subscriber configures (Section 8), not in any ACME account (Section 5). Audience Binding Value: The value computed per Section 3 that a Workload places in the "aud" claim of the WIF Token in order to bind it to a particular ACME account key. Terms from [RFC8555] -- account, account key, authorization, challenge, identifier, key authorization, order -- are used as defined there. Terms from [RFC7515] and [RFC7519] are used as defined there. 2. Overview 2.1. Participants Rasmussen Expires 9 April 2027 [Page 8] Internet-Draft ACME Workload Identity Challenge October 2026 +------------+ +---------------+ | Identity | | ACME Server | | Provider |<----- (4) JWKS retrieval -----| (CA) | +------------+ +---------------+ ^ ^ | | (2) token request (3) ACME requests (aud = binding) (JWS, account key) | | +-------------------------------------------------+ | | Workload |--+ | +-------------------------------------------+ | | | ACME Client | | | | (1) generates ephemeral account key | | | +-------------------------------------------+ | +-------------------------------------------------+ Figure 1: Participants in a federated workload identity issuance The Identity Provider and the ACME Server need not have any relationship beyond the ACME Server's operator having configured the Identity Provider's issuer identifier as acceptable. In particular the Identity Provider is not aware that ACME is in use. 2.2. Protocol Flow The following illustrates the flow in full. Rasmussen Expires 9 April 2027 [Page 9] Internet-Draft ACME Workload Identity Challenge October 2026 Client ACME Server IdP | | | |-- POST /newOrder ------------->| | |<-- 201 order, authz URLs ------| | | | | |-- POST-as-GET /authz/1 ------->| | |<-- 200 { challenges: [ | | | { type: "wif-01", | | | token: "...", | | | issuers: [...] } ] } ---| | | | | | compute keyAuthorization | | | compute Audience Binding Value | | | | | |-- request token (aud = ABV) ------------------------------->| |<-- WIF Token -----------------------------------------------| | | | |-- POST /chall/1 -------------->| | | JWS(account key){ | | | "wifToken": "eyJ..." } | | | |-- GET /.well-known/ | | | openid-configuration --->| | |<-- jwks_uri ---------------| | |-- GET jwks_uri ----------->| | |<-- JWKS -------------------| | | | | | verify signature, | | | exp, aud, jti, | | | apply policy | |<-- 200 { status: "valid" } ----| | | | | |-- POST /finalize ------------->| | Figure 2: wif-01 challenge flow Note that the ACME Server's retrieval of the IdP's metadata and JWKS is ordinarily satisfied from cache and does not occur on every validation. See Section 4.6. 2.3. Design Principles No changes to identity providers: Every value the Workload must place in the token is one that existing providers already permit the Workload to control. No new claim is required. Binding in the audience: The "aud" claim is the only field of a Rasmussen Expires 9 April 2027 [Page 10] Internet-Draft ACME Workload Identity Challenge October 2026 platform-issued token whose value the Workload can influence on every major platform. The binding to the ACME account key therefore travels there; Section 3 specifies the construction. An identity provider that does not permit the Workload to choose the audience per request cannot be used with this document (Section 7). Issuer allowlisting, not discovery: An ACME Server MUST NOT be led to trust an identity provider by the contents of a token. Acceptable issuers are configured out of band, and the "iss" claim selects among them rather than introducing them. See Section 10.6. Policy is configuration: Validating that a token is authentic, fresh, and bound is a protocol matter and is specified here in full. Deciding which authenticated workload may receive which identifier is a CA policy matter and is not. 3. The Audience Binding Value 3.1. Construction The Audience Binding Value (ABV) is computed as: ABV = "urn:ietf:params:acme:wif:" || base64url(SHA-256(ASCII(context))) where "||" denotes concatenation, base64url is base64url encoding without padding [RFC4648], and "context" is an ASCII string determined by the mechanism in use. For the "wif-01" challenge (Section 4): context = keyAuthorization where keyAuthorization is exactly the value defined in Section 8.1 of [RFC8555], that is, the challenge "token" value, a "." (0x2E) separator, and the base64url encoding of the JWK SHA-256 Thumbprint [RFC7638] of the account key. A specification that reuses this construction for another purpose MUST define its own context string, and MUST define it so that it cannot equal the keyAuthorization of any challenge. A server validating a "wif-01" challenge MUST compute the expected ABV from the challenge's keyAuthorization alone, and MUST NOT accept an ABV computed from a context defined by any other specification. Accepting a token minted for one context against a mechanism expecting another would let a token obtained for one purpose stand in for another. Rasmussen Expires 9 April 2027 [Page 11] Internet-Draft ACME Workload Identity Challenge October 2026 The resulting ABV is 68 ASCII characters: a 25-character prefix and a 43-character base64url-encoded digest. It contains no characters outside the unreserved set of [RFC3986] other than the colons in the URN prefix, and is therefore acceptable as an audience value to every identity provider surveyed in Appendix A. 3.2. Rationale Reusing the key authorization of Section 8.1 of [RFC8555] is deliberate. That construction already combines two properties this mechanism needs: * The challenge "token", chosen by the server with at least 128 bits of entropy and never reused, supplies freshness. A WIF Token bound to one challenge cannot be presented against another. * The account key thumbprint supplies account binding. A WIF Token that leaks -- into a build log, an artifact, an error report -- cannot be used by an attacker who does not also hold the account key it was bound to. Hashing the context, rather than placing the key authorization in the audience directly, yields a fixed 68-character value regardless of the server's token length, keeps the value within the audience length limits of every surveyed provider, and avoids disclosing the challenge token to the identity provider, which has no need for it. The "urn:ietf:params:acme:wif:" prefix ensures that a value constructed for this purpose cannot be mistaken for an audience value belonging to some other relying party, and allows an identity provider's administrators to recognize what a configured audience is for. It carries no security weight of its own; see Section 10.2 for the relationship between this construction and the ordinary meaning of the "aud" claim. 3.3. Binding Requirement The Workload requests a WIF Token whose "aud" claim contains the ABV computed per Section 3, and the ACME Server MUST verify its presence (step 7 of Section 4.4). There is no weaker mode. A server MUST NOT mark a "wif-01" challenge valid on the basis of a token whose audience it did not recompute from the challenge "token" and the thumbprint of the account key that signed the request it received. Rasmussen Expires 9 April 2027 [Page 12] Internet-Draft ACME Workload Identity Challenge October 2026 This requires an identity provider that lets the Workload supply an arbitrary audience string on each request. That includes GitHub Actions, Kubernetes service account tokens obtained through the TokenRequest API (and therefore Amazon EKS and Azure Kubernetes Service), Amazon Web Services outbound identity federation, SPIFFE JWT-SVIDs, and Google Cloud identity tokens. See Appendix A. Providers that constrain the audience to a value pre-registered with the provider, and so cannot vary it per request, cannot meet this requirement. A weaker mode for such providers -- in which the audience is a stable URI naming the ACME Server and the token is therefore not bound to the account key -- was considered and rejected. Such a token is a usable bearer credential for its full lifetime, and the compensating controls needed to make that tolerable include requiring that the presenting account have been associated with the issuer and subject by prior administrative action: an out- of-band bootstrap step, which is the condition this mechanism exists to remove. The Azure Instance Metadata Service is the notable provider in this position; Appendix A.4 describes the supported path on that platform. See Section 12. 4. The "wif-01" Challenge Type 4.1. Applicability The "wif-01" challenge MAY be offered for any ACME identifier type. Unlike proof-of-control challenges, nothing in the mechanism is specific to the DNS, and a CA issuing certificates for "ip", "permanent-identifier", or a private identifier type may offer it on the same terms. A server offers "wif-01" in an authorization when its policy has an entry for the identifier in that authorization. The lookup happens when the authorization is created and is keyed on the identifier the client placed in its order, not on the names in a certificate signing request, which does not yet exist; Section 7.4 of [RFC8555] later requires the request's names to match the order's identifiers. Section 8 describes the lookup. Whether a server offers "wif-01" alongside proof-of-control challenges, or instead of them, is a policy matter. Where both are offered, a client satisfying either one satisfies the authorization (Section 7.5.1 of [RFC8555]), so a CA requiring both proof of control and federated identity MUST NOT express that as two challenges in one authorization. Rasmussen Expires 9 April 2027 [Page 13] Internet-Draft ACME Workload Identity Challenge October 2026 4.2. Challenge Object A "wif-01" challenge object has the fields defined in Section 8 of [RFC8555] and the following additional fields: token (required, string): A random value that uniquely identifies the challenge, as defined in Section 8.3 of [RFC8555]. It MUST contain at least 128 bits of entropy, MUST be encoded in base64url with no padding, and MUST NOT be reused. issuers (optional, array of string): The issuer identifiers this server will accept for this authorization, narrowed from the set advertised in the directory metadata -- ordinarily to the issuers named by the policy entries for the authorization's identifier (Section 8). When present, a client SHOULD select an identity provider from this list. When absent, the full advertised set applies. Section 10.7 discusses what narrowing discloses. { "type": "wif-01", "url": "https://example.com/acme/chall/Rg5dV14Gh1Q", "status": "pending", "token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0", "issuers": [ "https://token.actions.githubusercontent.com" ] } Figure 3: A wif-01 challenge object 4.3. Client Behaviour To respond to a "wif-01" challenge, the client: 1. Computes the key authorization per Section 8.1 of [RFC8555] from the challenge "token" and its account key. 2. Computes the Audience Binding Value per Section 3. 3. Requests a WIF Token from its identity provider, specifying the ABV as the audience. The means of making this request is platform specific; see Appendix A. The client MUST request the shortest token lifetime the platform permits that is sufficient to complete the exchange. 4. POSTs to the challenge URL a JWS signed by its account key, as required by Section 6.2 of [RFC8555], whose payload is a JSON object with a single field: Rasmussen Expires 9 April 2027 [Page 14] Internet-Draft ACME Workload Identity Challenge October 2026 { "wifToken": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFGMkFCM..." } Figure 4: The payload of a wif-01 challenge response The "wifToken" field contains the WIF Token in JWS Compact Serialization [RFC7515]. A client MUST obtain a separate WIF Token for each challenge it answers, because the ABV commits to that challenge's "token" value. An order over n identifiers therefore costs n token requests. Identity provider token endpoints are rate limited, and a client that retries aggressively against a throttled endpoint will not recover faster; clients SHOULD spread a large certificate requirement over several orders rather than retry. See Section 10.8. A client MUST NOT write a WIF Token to persistent storage, and MUST NOT emit one to a log or console. See Section 10.10. 4.4. Server Validation On receiving a response to a "wif-01" challenge, the ACME Server MUST perform the following steps. A failure at any step means the challenge is not satisfied; the server sets the challenge status to "invalid" and populates the "error" field per Section 4.7. 1. Parse the "wifToken" as a JWS in Compact Serialization. Reject if it is not well formed or does not contain exactly three parts. 2. Examine the "alg" header parameter. The server MUST reject the token unless "alg" identifies a digital signature algorithm the server accepts. The server MUST reject "none" and MUST reject any MAC algorithm. The server MUST NOT select the verification algorithm from the token; it MUST verify that the algorithm is one permitted for the issuer selected in step 3. 3. Extract the "iss" claim. Reject unless "iss" exactly matches, by the string comparison rules of Section 6.2.1 of [RFC3986], an issuer identifier in the server's configured set of acceptable issuers, further narrowed by the challenge object's "issuers" field if present. The comparison MUST NOT accept a prefix, suffix, or subdomain match. 4. Retrieve the issuer's signing keys (Section 4.6) and select the key indicated by the "kid" header parameter. A server MUST reject a token whose "kid" does not identify a key in the Rasmussen Expires 9 April 2027 [Page 15] Internet-Draft ACME Workload Identity Challenge October 2026 retrieved set. A server SHOULD reject a token carrying no "kid"; where it accepts one, it MUST confine verification to keys whose "use" and "alg" are consistent with the header examined in step 2, and MUST NOT attempt verification against each key in the set in turn. Every identity provider surveyed in Appendix A emits "kid". 5. Verify the JWS signature per [RFC7515]. 6. Verify that "exp" is present and in the future, and that "nbf" and "iat", if present, are not in the future, in each case allowing for a clock skew no greater than 60 seconds. Reject if the token's remaining validity exceeds the server's configured maximum for the issuer. The skew allowance and the configured maximum compose. A server whose configured maximum is 300 seconds and which allows 60 seconds of skew will in the worst case accept a token 360 seconds old. A server for which the maximum is a hard bound MUST configure a value low enough that the sum respects it, and MUST NOT treat the value it advertises in "maxTokenLifetime" (Section 6) as the bound actually enforced. 7. Compute the expected Audience Binding Value from the challenge "token" and the thumbprint of the account key that signed the outer ACME request, per Section 3. Verify that the "aud" claim contains that value. Where "aud" is a JSON string it MUST equal the expected value; where it is an array of strings it MUST contain the expected value as a member. The comparison MUST be a case-sensitive, octet-for-octet comparison. 8. If a "jti" claim is present, check it against a replay cache scoped to the issuer and reject on a hit; otherwise record it for at least the remaining validity of the token. A replay cache is defence in depth here, not the primary control. A token presented against a "wif-01" challenge is already single-use in effect: its audience commits to one challenge's "token", that value is never reused (Section 4), and a challenge that has left the "pending" state does not return to it (Section 7.1.6 of [RFC8555]). A server that implements no replay cache is conformant; one that does will catch a client or server defect that violates either property. Rasmussen Expires 9 April 2027 [Page 16] Internet-Draft ACME Workload Identity Challenge October 2026 9. Apply the authorization policy configured for the issuer to the token's claims, yielding the set of identifiers that this Workload is permitted to be authorized for. Reject unless the identifier of the authorization containing this challenge is a member of that set. See Section 8. 10. Set the challenge status to "valid" and the enclosing authorization status to "valid" per Section 7.1.6 of [RFC8555], and set the authorization's "expires" field as required by Section 4.5. Steps 2 through 8 are protocol requirements and a conforming server MUST implement them as stated. Step 9 is where deployment-specific judgement lives. 4.5. Lifetime and Reuse of Federated Authorizations Section 7.1.3 of [RFC8555] contemplates a CA that "allows multiple orders to be fulfilled based on a single authorization transaction", and deployed ACME servers retain valid authorizations for reuse by later orders for periods measured in days or weeks. Carried over unchanged, that practice would defeat the property this mechanism exists to provide. The freshness supplied by the challenge "token" (Section 3) binds one token to one challenge. It says nothing about how long the resulting authorization remains spendable. A Workload that answers a "wif-01" challenge once, from an execution context its policy permits, would otherwise leave behind an authorization that any request signed by that account key can spend for the authorization's whole lifetime, with no further token presented and no policy consulted. The branch, environment, namespace and cluster constrained under Section 8 would be constrained once per authorization rather than once per certificate, and the value of constraining them would be largely lost. Therefore a server MUST set the "expires" field of an authorization validated by "wif-01" to a time no later than the "exp" of the WIF Token that validated it, and MUST NOT subsequently extend it. No further rule is needed. Section 7.1.4 of [RFC8555] defines "expires" as "the timestamp after which the server will consider this authorization invalid", so an authorization constrained this way cannot satisfy an order placed after its token has expired. The requirement constrains the value of a field that [RFC8555] already defines, with the meaning [RFC8555] already gives it, and alters nothing in the order or authorization lifecycle. Rasmussen Expires 9 April 2027 [Page 17] Internet-Draft ACME Workload Identity Challenge October 2026 A server MAY impose a shorter lifetime. A server whose policy for an identifier depends on claims that the Subscriber's own administrators can change (Section 10.4) SHOULD do so. Platform token lifetimes are short -- 300 seconds by default on several of the platforms in Appendix A -- so the practical effect is that a federated authorization serves the order that produced it and no other. This is deliberate. Clients MUST NOT assume an authorization validated this way will still be available to a later order, and MUST be prepared to answer a fresh challenge on every order. 4.6. Retrieval and Caching of Issuer Keys An ACME Server obtains an issuer's signing keys by retrieving the OpenID Provider Metadata [OIDC-DISCOVERY] from the issuer identifier, and then the JWK Set [RFC7517] from the "jwks_uri" member of that metadata. A server MUST derive the metadata URL from its own configured issuer identifier and MUST NOT derive it from the "iss" claim of a token presented to it, even after that claim has been matched against the configured set. This constraint exists to make the retrieval independent of attacker-supplied input under all conditions; see Section 10.6. A server SHOULD cache metadata and key sets and honour HTTP caching directives, subject to a minimum refresh interval of its own choosing. A server SHOULD refresh a key set on encountering an unknown "kid", rate-limited so that a stream of tokens bearing unknown "kid" values cannot be used to drive requests at the issuer. A server MAY be configured with an issuer's keys directly, bypassing retrieval. This is appropriate for issuers reachable only from within a private network. 4.7. Error Types This document defines the error types in Table 1, to be used in the "error" field of an invalidated challenge and in problem documents returned in response to a challenge. Rasmussen Expires 9 April 2027 [Page 18] Internet-Draft ACME Workload Identity Challenge October 2026 +======================+===================================+ | Type | Description | +======================+===================================+ | badWifToken | The WIF Token was malformed, its | | | signature did not verify, or it | | | was expired or not yet valid | +----------------------+-----------------------------------+ | wifIssuerNotAccepted | The token's issuer is not among | | | those the server accepts for this | | | authorization | +----------------------+-----------------------------------+ | wifAudienceMismatch | The "aud" claim did not contain | | | the expected Audience Binding | | | Value | +----------------------+-----------------------------------+ | wifTokenReplayed | A token bearing this "jti" has | | | already been presented | +----------------------+-----------------------------------+ | wifPolicyDenied | The token was valid, but policy | | | does not permit this Workload to | | | be authorized for this identifier | +----------------------+-----------------------------------+ Table 1: Error types defined by this document A server returning "wifPolicyDenied" SHOULD include in the problem document's "detail" field enough information for an operator to correct the policy or the Workload, and in particular SHOULD name the claims that were evaluated and give the values the presented token carried for them. It MUST NOT include the values the policy expected (Section 8.2). The requester may be unauthenticated (Section 5), and the token's own values are the only ones it has already established. 5. Accounts 5.1. External Account Binding Is Not Required Section 7.3.4 of [RFC8555] defines External Account Binding (EAB) so that a CA can associate a new ACME account with a Subscriber it already knows, and Section 7.1.3 of [RFC8555] recognizes that a CA may then treat identifiers as already authorized "based on an external account". A CA using EAB that way places the Subscriber relationship on the account, and the account key carries the Subscriber's authority from then on. This document places the relationship elsewhere. The association between a Workload and a Subscriber is established by the policy entry (Section 8) that the Workload's WIF Token satisfies, and it is Rasmussen Expires 9 April 2027 [Page 19] Internet-Draft ACME Workload Identity Challenge October 2026 established afresh for every authorization. The account presenting the token contributes a key to which the token is bound (Section 3) and nothing else. It holds no authority of its own, and whatever an authorization lets it obtain lapses when that authorization expires (Section 4.5). EAB therefore has no part in deciding who a Workload is or what it may obtain. A Workload creates an ordinary [RFC8555] account from a freshly generated key, with no "externalAccountBinding" field, and holds no pre-shared secret of any kind at any point. This is the property that makes the mechanism usable by ephemeral compute: there is no credential to provision. 5.2. Coexisting with External Account Binding "externalAccountRequired" (Section 7.1.1 of [RFC8555]) applies to every newAccount request made to a directory. A CA that must continue to require EAB of some clients can accommodate Workloads using "wif-01" in either of two ways, both entirely within [RFC8555]: * Set "externalAccountRequired" to false. Clients that supply EAB continue to receive whatever pre-authorization the CA grants them. An account created without EAB receives none, and can obtain a certificate only by satisfying a challenge; admitting such accounts grants no authority on its own. * Publish a separate directory for Workloads using "wif-01", with "externalAccountRequired" false or absent, and leave the existing directory unchanged. A CA may require EAB for reasons unrelated to authorization, such as billing or a contractual relationship with each account holder. Those reasons are outside the scope of this document; see Section 12. 5.3. Ephemeral Accounts A Workload with nowhere to persist a key will generate a fresh account key and create a fresh account on every execution. A server supporting this document SHOULD therefore: * accept account creation at a rate consistent with the volume of executions it serves; * apply rate limits keyed on the requested identifier and, once a token has been validated, on the policy entry it satisfied or on its issuer and subject -- not on the account alone, which changes on every execution, so that a limit keyed only on it limits nothing; and Rasmussen Expires 9 April 2027 [Page 20] Internet-Draft ACME Workload Identity Challenge October 2026 * deactivate or discard accounts that have held no pending or valid authorization for longer than the plausible interval between executions. Clients SHOULD NOT create an account per order where one account per execution will serve. A long-running client that can persist its account key has no reason to create an account per execution, and SHOULD NOT do so. 6. Directory Metadata A server supporting this document SHOULD advertise the fact in the "meta" field of its directory object (Section 7.1.1 of [RFC8555]), using a "wif" member whose value is an object with the following fields: issuers (required, array of string): The issuer identifiers the server accepts. A client uses this to determine which of its available identities to present. maxTokenLifetime (optional, number): The maximum remaining validity, in seconds, that the server will accept in a presented token. A client SHOULD request a token lifetime no greater than this. { "newNonce": "https://example.com/acme/new-nonce", "newAccount": "https://example.com/acme/new-account", "newOrder": "https://example.com/acme/new-order", "meta": { "termsOfService": "https://example.com/acme/terms/2026-09", "wif": { "issuers": [ "https://token.actions.githubusercontent.com", "https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE539D4633" ], "maxTokenLifetime": 300 } } } Figure 5: Directory metadata advertising federated workload identity Future specifications may define further members of the "wif" object. A client MUST ignore members it does not recognize. Advertising an issuer in the directory discloses which platforms the CA's subscribers use. A CA for which this is sensitive MAY omit the "issuers" field and rely on the per-challenge "issuers" field Rasmussen Expires 9 April 2027 [Page 21] Internet-Draft ACME Workload Identity Challenge October 2026 instead. The directory is retrieved without authentication (Section 7.1.1 of [RFC8555]), so its contents cannot be varied by requester. See Section 11. 7. Identity Provider Requirements An identity provider is suitable for use with this document if it meets all of the following. Compliance is a property of the provider, assessed by the CA operator at configuration time; nothing in the protocol verifies it. 1. It issues JWTs [RFC7519] signed with a digital signature algorithm from [RFC7518] or a successor, of at least 128-bit security strength. 2. It publishes OpenID Provider Metadata [OIDC-DISCOVERY] at the issuer identifier, or the CA operator can otherwise obtain its keys through a trustworthy channel. 3. It permits the Workload to determine the "aud" claim of the issued token, as an arbitrary string chosen per request. A provider that requires the audience to be a value pre-registered with the provider, and cannot vary it per request, does not meet this requirement and MUST NOT be configured as an acceptable issuer. See Section 3.3. 4. It includes an "exp" claim, and permits or defaults to a lifetime short enough for the CA's configured maximum. 5. It issues tokens whose "sub" claim, or some combination of claims, identifies the Workload with sufficient precision and stability for the CA's policy to act on. See Section 10.4 for the stability requirement, which is frequently underestimated. 6. It does not issue tokens for a given "sub" to any party other than the Workload that "sub" denotes. Requirement 6 deserves emphasis. An identity provider shared among mutually untrusting tenants -- which describes every public CI platform -- satisfies it only in the sense that it will not issue a token for tenant A to tenant B. It does not and cannot prevent tenant B from obtaining a token for tenant B. An issuer identifier is therefore never sufficient authorization on its own; see Section 10.3. Rasmussen Expires 9 April 2027 [Page 22] Internet-Draft ACME Workload Identity Challenge October 2026 8. Authorization Policy 8.1. Model This document does not define a policy language. It defines the relation a policy expresses: a set of entries, each associating an identifier with an acceptable issuer and a matching rule over that issuer's claims. A Subscriber configures its entries out of band, before any request arrives, and it is the entry -- not the ACME account -- that records which Subscriber a Workload belongs to (Section 5). The relation can be read in either direction, and a server may index it either way: permit: (issuer, claims) -> set of identifiers expect: identifier -> set of (issuer, rule over claims) step 9: identifier is in permit(iss, claims) i.e. some (issuer, rule) in expect(identifier) has issuer == iss and rule(claims) holds A server ordinarily uses the second reading twice. When it creates an authorization, it looks up the entries for the authorization's identifier. If there are none, it does not offer "wif-01" (but see Section 10.7); if there are, it may narrow the challenge's "issuers" field to the issuers they name, and it holds their matching rules for step 9 of Section 4.4. When it validates a response, step 9 asks whether the verified token satisfies one of those rules. The authorization's identifier type, value, and wildcard status (Section 7.1.4 of [RFC8555]) together form the lookup key. Whether entries match identifiers exactly or by pattern is a property of the policy language; servers SHOULD prefer exact matching, since a pattern that matches more names than its author intended grants every one of them. Each identifier in an order has its own authorization and is looked up independently. An order whose identifiers have entries naming different Workloads cannot be completed by any one of them. That is the intended result: a Workload cannot obtain a certificate that also names another Workload's identifiers. A policy MUST be expressed in terms of an explicit allowlist of issuers and, for each, an explicit matching rule over claims. A policy MUST NOT be expressible as "any token from a configured issuer", because on a shared identity provider that admits every tenant of that provider (Section 10.3). Rasmussen Expires 9 April 2027 [Page 23] Internet-Draft ACME Workload Identity Challenge October 2026 8.2. Policy Is Not Disclosed, and Is Not Secret A server does not tell the client which claim values an identifier's policy entry expects. Nothing in the challenge object carries them, and the client has no use for them: a Workload cannot choose the claims its identity provider puts in its token, so knowing the expected values would not help it produce them. The client needs to know only which issuer to ask for a token, which the "issuers" field supplies, and the ABV, which it computes. Withholding the expected values is worthwhile. They describe the Subscriber's internal structure -- repositories, branches, clusters, namespaces, cloud accounts, deployment environments -- and the requester may be unauthenticated (Section 5). A server MUST NOT include expected claim values in a challenge object or in a problem document (Section 4.7). The expected values are nonetheless not a secret, and the security of this mechanism MUST NOT depend on their confidentiality. Many are guessable or public. A GitHub Actions subject is assembled from the repository and branch names; repository and owner identifiers are returned by the provider's public API; a Kubernetes subject names a namespace and a service account. What establishes that a token bearing a given subject was issued to the Workload that subject denotes is the identity provider (requirement 6 of Section 7), and what establishes that it was issued for this authorization is the audience binding (Section 3.3). An attacker who knows every value in a policy entry is no closer to satisfying it. A deployment that regards its policy values as secret, and relaxes its matching rules on that basis -- matching a subject alone, say, on the theory that nobody else knows it -- has no protection once those values are learned. 8.3. Recommendations for Policy Authors Match on immutable claims: Where a provider exposes both a human- readable name and a stable numeric identifier for the same entity, match the numeric identifier. See Section 10.4. Match on complete values: Prefix and suffix matching over "sub" invites errors when the provider changes its subject format, which providers do. Where a provider exposes the components of "sub" as individual claims, match those. Constrain execution context: Where the provider exposes the branch, Rasmussen Expires 9 April 2027 [Page 24] Internet-Draft ACME Workload Identity Challenge October 2026 tag, environment, or namespace in which the Workload ran, policy for a production identifier SHOULD require a specific value rather than accepting any. Scope identifiers narrowly: Grant a Workload the narrowest set of identifiers that lets it do its job. Wildcard grants over a whole zone should be exceptional and deliberate. Interaction with CAA: A domain holder may constrain which accounts and methods may be used for a name using [RFC8657]. A CA implementing this document MUST honour a "validationmethods" parameter naming "wif-01", and MUST NOT treat a federated authorization as exempt from CAA processing. 9. IANA Considerations 9.1. ACME Validation Methods IANA is requested to add the following entry to the "ACME Validation Methods" registry: +========+=================+======+===============+ | Label | Identifier Type | ACME | Reference | +========+=================+======+===============+ | wif-01 | dns | Y | This document | +--------+-----------------+------+---------------+ | wif-01 | ip | Y | This document | +--------+-----------------+------+---------------+ Table 2: Addition to the ACME Validation Methods registry The "wif-01" method is applicable to further identifier types; entries for those are expected to be registered by the documents defining them. 9.2. ACME Error Types IANA is requested to add the following entries to the "ACME Error Types" registry, each with the prefix "urn:ietf:params:acme:error:": Rasmussen Expires 9 April 2027 [Page 25] Internet-Draft ACME Workload Identity Challenge October 2026 +======================+==========================+===========+ | Type | Description | Reference | +======================+==========================+===========+ | badWifToken | The WIF Token was | This | | | malformed, unverifiable, | document | | | or not currently valid | | +----------------------+--------------------------+-----------+ | wifIssuerNotAccepted | The token issuer is not | This | | | accepted for this | document | | | authorization | | +----------------------+--------------------------+-----------+ | wifAudienceMismatch | The token audience did | This | | | not contain the expected | document | | | binding value | | +----------------------+--------------------------+-----------+ | wifTokenReplayed | A token with this | This | | | identifier has already | document | | | been presented | | +----------------------+--------------------------+-----------+ | wifPolicyDenied | Policy does not permit | This | | | this workload to obtain | document | | | this identifier | | +----------------------+--------------------------+-----------+ Table 3: Additions to the ACME Error Types registry 9.3. ACME Directory Metadata Fields IANA is requested to add the following entry to the "ACME Directory Metadata Fields" registry: +============+============+===============+ | Field Name | Field Type | Reference | +============+============+===============+ | wif | object | This document | +------------+------------+---------------+ Table 4: Addition to the ACME Directory Metadata Fields registry 9.4. Challenge Object Fields and URN Label No IANA registry exists for the fields of a challenge object, which Section 8 of [RFC8555] leaves to the definition of each challenge type. The "issuers" field is defined in Section 4 as part of the "wif-01" challenge type and requires no registration. Rasmussen Expires 9 April 2027 [Page 26] Internet-Draft ACME Workload Identity Challenge October 2026 The Audience Binding Value of Section 3 uses the prefix "urn:ietf:params:acme:wif:" within the "urn:ietf:params:acme" namespace registered by Section 9.6 of [RFC8555]. No IANA registry exists for labels within that namespace, and this document requests no IANA action for the "wif" label. Values following the prefix are computed, not registered. Other specifications reusing the construction of Section 3 may share this label. See Section 12. 10. Security Considerations 10.1. The Audience Binding Is Load-Bearing A WIF Token is a bearer credential. It travels through a CI runner's process environment, is handled by client code of varying quality, and in practice sometimes reaches build logs, crash dumps, and artifact archives. The mechanism in this document is safe to deploy on that assumption only because the token is bound to an ACME account key that never leaves the Workload. An attacker who obtains a strictly bound token before it expires cannot use it. The token's audience commits to the thumbprint of a specific account key and to a specific challenge token; the ACME Server recomputes the expected audience from the account key that signed the request it actually received. Presenting the token under any other account key fails step 7 of Section 4.4. This protection is what makes the mechanism deployable, and it is why Section 3.3 admits no weaker mode. A token whose audience names the ACME Server as a stable value, rather than committing to the account key, is a usable bearer credential for its full lifetime, and no combination of short lifetimes and replay caches recovers the property that a leaked token is inert. Where a platform offers only such a path, the correct response is to use a different path on that platform (Appendix A.4), or a different platform, not to weaken the binding. 10.2. Use of the "aud" Claim The "aud" claim of Section 4.1.3 of [RFC7519] identifies the recipients a JWT is intended for, and a recipient is expected to reject a token that does not identify it. The ABV is not a recipient identifier in that sense. It is a value that changes with every challenge, names no party, and is recognized not by comparison against a configured name but by recomputation from state the server already holds. Rasmussen Expires 9 April 2027 [Page 27] Internet-Draft ACME Workload Identity Challenge October 2026 The construction is nonetheless faithful to the claim's purpose, and in one respect stricter than the usual reading: a server accepts only an audience it can itself derive, which is a narrower rule than matching a configured identifier. No other relying party will accept a token bearing the "urn:ietf:params:acme:wif:" prefix unless it has deliberately configured that value, and Section 3 makes the prefix legible so that an administrator encountering it can tell what it is for. Two consequences deserve statement. First, the audience cannot be allowlisted at the identity provider. Where a provider, or a tenant administrator, restricts which audiences a Workload may request -- a control some deployments rely on -- that restriction cannot be expressed over a value that differs on every challenge. Deployments must obtain the equivalent assurance from the provider's controls over which Workloads may obtain tokens at all, and from the policy of Section 8, rather than from audience restriction. Second, a server MUST NOT treat the presence of the "urn:ietf:params:acme:wif:" prefix as carrying any security weight on its own. It is a collision-avoidance and legibility device. Only the recomputation in step 7 of Section 4.4 is load-bearing. 10.3. Issuer Allowlisting Is Not Authorization The most likely deployment error is to configure an issuer and stop. Every repository on GitHub receives tokens from the issuer "https://token.actions.githubusercontent.com". Every EKS cluster in an AWS region shares an issuer hostname, though not a path. A policy that accepts any token from such an issuer accepts a token from any tenant of that platform, including one created by an attacker minutes earlier for the purpose. The attacker need not compromise anything: they need only sign up. Policy MUST therefore pin the subject as well as the issuer, and MUST do so on claims that identify the Subscriber's own workloads specifically. An implementation SHOULD refuse to load a policy whose matching rule for an issuer is unconstrained, and SHOULD warn on a rule that constrains only mutable claims (Section 10.4). This failure mode is well documented in the operational literature on cloud identity federation and has produced real compromises. It is repeated here because the ACME context is new and the mistake will be made again. Rasmussen Expires 9 April 2027 [Page 28] Internet-Draft ACME Workload Identity Challenge October 2026 10.4. Mutable and Reassignable Claims Several providers expose claims that look like stable identifiers but are not. A GitHub repository's "repository" and "repository_owner" claims change when the repository is renamed or transferred, and the freed name may be claimed by another account. The "repository_id" and "repository_owner_id" claims are numeric and are not reassigned. Policy that matches "example-corp/service-a" will follow the name to whoever holds it next; policy that matches the owner and repository identifiers will not. A Kubernetes service account name may be deleted and recreated in the same namespace by anyone with authority there; the "kubernetes.io/ serviceaccount/ service-account.uid" claim, where present, distinguishes the incarnations. An AWS IAM role ARN may be deleted and recreated with the same name and different trust policy. Where a provider offers both forms, policy MUST prefer the non- reassignable one. Where it does not, the CA operator should understand that the authorization follows the name. A related hazard: some providers permit the tenant administrator to change the format of the "sub" claim. GitHub's subject claim customization is an example. Policy expressed as a match against a whole "sub" string can therefore be invalidated, or subtly widened, by a configuration change made elsewhere. Matching individual claims is more robust than parsing "sub". 10.5. Execution Context A token proves which Workload identity ran, not that the code it ran was the code its operators intended. A CI platform's identity token is issued to a workflow, and a party who can modify that workflow -- by pushing to a branch, opening a pull request that triggers a privileged workflow, or compromising a dependency the workflow executes -- can cause a token to be issued for that identity and exfiltrated or used. Policy for identifiers of consequence SHOULD constrain the execution context: the branch or tag, the deployment environment, the cluster and namespace. Where the platform offers a gated environment with required approvals, requiring it in policy converts certificate issuance into a reviewed action. Rasmussen Expires 9 April 2027 [Page 29] Internet-Draft ACME Workload Identity Challenge October 2026 Deployments should be aware that workflows triggered by contributions from outside the trust boundary are a recurring source of identity confusion on CI platforms, and should consult their platform's current guidance rather than assuming a given trigger is safe. 10.6. Server-Side Request Forgery and Issuer Metadata An ACME Server implementing this document makes outbound HTTP requests to retrieve issuer metadata and keys. If the URL of those requests could be influenced by a presented token, an attacker could use the CA as a probe against its internal network or against third parties. Section 4.6 therefore requires the server to derive metadata URLs from its own configuration, never from the "iss" claim, even after that claim has been matched against the configured set. Matching then deriving is not equivalent to deriving from configuration: a matching bug, a normalization difference, or a future relaxation of the comparison rule turns the former into an SSRF primitive, and the latter into nothing. Implementations SHOULD additionally apply the usual protections to these requests: resolve and pin addresses, refuse non-global addresses unless configured for a private issuer, cap response size, cap redirect depth, and time out aggressively. 10.7. Policy Enumeration Where accounts are created without EAB (Section 5), anyone may place an order for any identifier. Whether the server then offers "wif- 01", and which issuers it names in the challenge, tells an unauthenticated requester that the identifier's Subscriber uses federated identity and which platform it uses. Repeated across many names, this maps a Subscriber's deployment without any credential. It does not expose expected claim values (Section 8.2), and it confers no ability to obtain a certificate. A CA for which the disclosure matters MAY: * omit the "issuers" field, or give the full advertised set, rather than narrowing it per identifier; * offer "wif-01" for identifiers that have no policy entry, failing such challenges with "wifPolicyDenied" exactly as it would fail a policy mismatch; and * rate limit order and authorization creation per requester, independently of the account. Rasmussen Expires 9 April 2027 [Page 30] Internet-Draft ACME Workload Identity Challenge October 2026 10.8. Denial of Service Validating a "wif-01" challenge costs the server more than validating a proof-of-control challenge, and the cost is incurred before the token is known to be good. Servers SHOULD reject obviously malformed tokens before performing signature verification, SHOULD cap the accepted token size, and SHOULD rate-limit challenge responses per account, per requested identifier, and per policy entry (Section 5.3). A replay cache, where a server implements one (Section 4.4), is an unbounded-growth hazard if the accepted token lifetime is long. A server implementing one MUST bound retention by the maximum token lifetime it accepts for the issuer, and MUST reject a token whose remaining validity exceeds that maximum, so that the cache is bounded by arrival rate rather than by token lifetime. Because each challenge requires its own token, an order over n identifiers produces n requests to the identity provider's token endpoint. Those endpoints are rate limited by the platform, and the limit is the Subscriber's, not the CA's: a CA cannot relieve it. Servers SHOULD bound the number of identifiers in an order for which they will offer "wif-01", and SHOULD state that bound in their documentation. An identity provider outage prevents key retrieval and therefore prevents issuance. Servers SHOULD serve stale key sets for a bounded period rather than failing closed immediately, balancing availability against the window in which a revoked key remains accepted. 10.9. Cryptographic Agility and Algorithm Confusion Step 2 of Section 4.4 requires the server to reject MAC algorithms and "none", and to verify that the algorithm is one permitted for the selected issuer rather than selecting it from the token. Both are necessary. The historical JWT vulnerabilities in this area arose from implementations that treated the token's own header as authoritative for verification parameters. Servers MUST maintain per-issuer lists of acceptable algorithms and SHOULD constrain them to those the issuer actually uses. An issuer that publishes only RSA keys should not have ECDSA accepted on its behalf. Rasmussen Expires 9 April 2027 [Page 31] Internet-Draft ACME Workload Identity Challenge October 2026 10.10. Token Handling by Clients Clients MUST NOT persist WIF Tokens and MUST NOT log them. Where the CI platform provides a secret-masking facility, clients SHOULD register the token with it. Clients SHOULD request the shortest lifetime the platform permits. Clients SHOULD pass the token to the ACME server over a TLS connection whose certificate they verify, and MUST NOT send a WIF Token to any URL other than one obtained from the ACME server's directory or from a resource within it. Because the ABV commits to the account key, a client MUST use the same account key for the request carrying the token as it used when computing the ABV. A client that regenerates its key between those steps will produce a token that cannot validate. 10.11. Relationship to Proof of Control A federated authorization asserts that a workload identity is entitled, by CA policy, to a certificate for an identifier. It does not assert that anyone demonstrated control of that identifier at issuance time. For a publicly trusted CA issuing for public DNS names this is a material difference, and such a CA is unlikely to accept "wif-01" in place of proof of control; CAA [RFC8657] gives domain holders a means of saying so. The mechanism is aimed at private and enterprise CAs, where the CA's policy is itself the authoritative statement of who may hold which name within the organization's namespace, and at identifier types for which proof of control is not meaningful. A CA wishing to require both proof of control and federated identity must express that as two authorizations, not two challenges within one; see Section 4. 10.12. Claims in Certificates An ACME Server MUST NOT copy claims from a WIF Token into an issued certificate unless its profile explicitly provides for it. Claims routinely contain internal repository names, cluster names, namespaces, and numeric account identifiers. For a publicly trusted certificate these would be published to Certificate Transparency logs [RFC6962] and become permanent public record. Rasmussen Expires 9 April 2027 [Page 32] Internet-Draft ACME Workload Identity Challenge October 2026 11. Privacy Considerations The WIF Token discloses to the CA the identity of the Workload and, through its claims, a quantity of internal structure: repository and organization names, cluster and namespace names, branch names, deployment environment names, platform account identifiers. This is more than an ACME server learns from a proof-of-control challenge, and it is retained in the CA's validation records. CA operators SHOULD retain only the claims their policy and audit obligations require, SHOULD state what they retain and for how long, and SHOULD NOT retain the token itself beyond the replay window. The directory metadata of Section 6 discloses to any unauthenticated party which identity platforms the CA's subscribers use, and for EKS- style issuers may disclose specific cluster identifiers. Section 6 permits a CA to omit the advertised set. Challenges disclose more, identifier by identifier; see Section 10.7. The identity provider learns that the Workload requested a token for an audience beginning "urn:ietf:params:acme:wif:", and therefore that certificate issuance is occurring, but learns nothing about the CA, the identifier, or the account, because the remainder of the ABV is a digest. This is a deliberate property of the construction in Section 3. 12. Open Issues This section is to be removed before publication. 1. Challenge type name. "wif-01" borrows a term popularized by cloud vendors. Alternatives considered: "federated-01", "idtoken-01", "oidc-01". The working group may prefer a name that does not presuppose OpenID Connect, since the mechanism needs only a signed JWT with a discoverable key set. 2. Providers that cannot vary the audience per request. Section 3.3 excludes them, which today excludes the Azure Instance Metadata Service path (Appendix A.4). The exclusion is deliberate and its reasoning is given there. If the working group judges it too strict, what is needed is a control that binds the token to the account without reintroducing an out-of-band secret; the authors did not find one. 3. Whether the challenge object should carry the expected ABV explicitly rather than requiring the client to compute it. Explicit transmission is friendlier to thin clients but introduces a value the client must not blindly trust. Rasmussen Expires 9 April 2027 [Page 33] Internet-Draft ACME Workload Identity Challenge October 2026 4. Whether this document should define a minimal interoperable policy expression, or whether leaving policy wholly to implementations will produce the same non-interoperability the document set out to fix. 5. The lifetime rule of Section 4.5 makes a federated authorization effectively single-use, which departs from common ACME server behaviour and costs clients that batch orders. The working group should confirm the trade. A middle position -- permitting reuse within a short fixed window independent of the token's "exp" -- was considered and seems harder to reason about rather than easier. 6. Interaction with [I-D.ietf-acme-pop], which allows issuance without a CSR. A workload holding no private key material at all until issuance time is a plausible combination worth examining. 7. External Account Binding required for reasons other than authorization. Section 5 shows that EAB plays no part in authorization under this document. A CA that nonetheless requires it -- for billing, or to maintain a contractual relationship with each account holder -- still cannot associate an account with a Subscriber without a pre-shared secret. A "wifToken" field of the newAccount request was considered for that purpose and set aside, to keep this document within the extension points ACME already defines. Whether the working group wants that gap addressed, and if so whether inside ACME or outside it -- for instance by exchanging a WIF Token for EAB credentials using OAuth 2.0 Token Exchange [RFC8693] -- is an open question. 8. The "urn:ietf:params:acme:wif:" prefix. [RFC8555] registers the "urn:ietf:params:acme" namespace but creates no registry for labels within it, so nothing records that "wif" is taken. The working group may prefer to create such a registry, or to use a prefix outside that namespace. 13. References 13.1. Normative References [OIDC-DISCOVERY] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", 15 December 2023, . Rasmussen Expires 9 April 2027 [Page 34] Internet-Draft ACME Workload Identity Challenge October 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . 13.2. Informative References Rasmussen Expires 9 April 2027 [Page 35] Internet-Draft ACME Workload Identity Challenge October 2026 [AWS-GWIT] "GetWebIdentityToken, AWS Security Token Service API Reference", 2026, . [AZURE-IMDS] "Azure Instance Metadata Service token acquisition", 2026, . [GITHUB-OIDC] "OpenID Connect reference (GitHub Actions)", 2026, . [I-D.ietf-acme-authority-token-jwtclaimcon] Wendt, C. and D. Hancock, "JWTClaimConstraints profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-jwtclaimcon-07, 11 September 2026, . [I-D.ietf-acme-openid-federation] De Marco, G., Pitman, B., Geoghegan, T., Cook, D., and J. Jones, "Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0", Work in Progress, Internet-Draft, draft-ietf-acme-openid-federation-00, 16 December 2025, . [I-D.ietf-acme-pop] Geng, F., Wu, P., Xia, L., and X. Chen, "Automated Certificate Management Environment (ACME) Extension for Proof-of-Possession", Work in Progress, Internet-Draft, draft-ietf-acme-pop-00, 1 September 2026, . [I-D.ietf-acme-rats] Liu, P. C., Ounsworth, M., Richardson, M., and G. Mallaya, "Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type", Work in Progress, Internet-Draft, draft-ietf-acme-rats-02, 10 September 2026, . Rasmussen Expires 9 April 2027 [Page 36] Internet-Draft ACME Workload Identity Challenge October 2026 [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-02, 2 July 2026, . [K8S-PROJECTED] "Managing Service Accounts: bound service account tokens", 2026, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . [RFC8657] Landau, H., "Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding", RFC 8657, DOI 10.17487/RFC8657, November 2019, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates", RFC 9118, DOI 10.17487/RFC9118, August 2021, . [RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "Automated Certificate Management Environment (ACME) Challenges Using an Authority Token", RFC 9447, DOI 10.17487/RFC9447, September 2023, . Rasmussen Expires 9 April 2027 [Page 37] Internet-Draft ACME Workload Identity Challenge October 2026 [RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token", RFC 9448, DOI 10.17487/RFC9448, September 2023, . [SPIFFE-ID] "SPIFFE ID and JWT-SVID specification", 2024, . Appendix A. Provider Profiles This appendix is informative. It records, for each surveyed platform, how a Workload obtains a token with a chosen audience, what the token's issuer and subject look like, and whether the audience can be chosen per request. Platform details change; implementers should verify against current documentation. A.1. GitHub Actions Issuer: "https://token.actions.githubusercontent.com" Audience control: Arbitrary string, chosen per request. Acquisition: As described in [GITHUB-OIDC], the workflow job must be granted the "id-token: write" permission. The runner exposes "ACTIONS_ID_TOKEN_REQUEST_URL" and "ACTIONS_ID_TOKEN_REQUEST_TOKEN" in the environment; a GET to the former with an "audience" query parameter and the latter as a bearer token returns the JWT. The official toolkit exposes this as "core.getIDToken(audience)". curl -sS -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \ "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=$ABV" | jq -r .value Claims of interest: "sub" (composite, and customizable by the organization -- see Section 10.4), "repository", "repository_id", "repository_owner", "repository_owner_id", "ref", "environment", "job_workflow_ref", "runner_environment". Organization and enterprise administrators may additionally surface repository custom properties as claims prefixed "repo_property_". Policy note: Match "repository_owner_id" and "repository_id", not "repository_owner" and "repository". Constrain "ref" or "environment" for production identifiers. Rasmussen Expires 9 April 2027 [Page 38] Internet-Draft ACME Workload Identity Challenge October 2026 A.2. Kubernetes and SPIFFE Issuer: Cluster specific, published in the cluster's OIDC discovery document. For EKS, obtainable with "aws eks describe-cluster --query cluster.identity.oidc.issuer"; for AKS, from the cluster's OIDC issuer URL. For SPIFFE, the trust domain's configured JWT issuer. Audience control: Arbitrary string, chosen per request. Acquisition: The TokenRequest API, which takes the audience as a parameter ([K8S-PROJECTED]). A projected service account token volume is not usable here: it fixes the audience at pod creation and so cannot carry a value that varies per challenge. SPIFFE workloads use the Workload API's JWT-SVID endpoint [SPIFFE-ID], which likewise takes the audience as a parameter. Claims of interest: "sub" of the form "system:serviceaccount:NAMESPACE:NAME"; where bound tokens are in use, a "kubernetes.io" claim object carrying namespace, service account name and UID, and pod name and UID. For JWT-SVIDs, "sub" is the SPIFFE ID. Policy note: Match the namespace and service account name, and the service account UID where available. Cluster identity comes from the issuer, which for EKS and AKS is unique per cluster. A.3. Amazon Web Services Issuer: For EKS workloads, the cluster OIDC issuer (Appendix A.2). For other workloads, the account-specific issuer returned when outbound identity federation is enabled for the account. Audience control: Arbitrary strings, one to ten of them, up to 1000 characters each, chosen per request. Acquisition: The STS "GetWebIdentityToken" action [AWS-GWIT], which takes an Audience list, a SigningAlgorithm ("RS256" or "ES384"), and an optional DurationSeconds between 60 and 3600 with a default of 300. It is not available on the STS global endpoint; a regional endpoint must be used. aws sts get-web-identity-token \ --audience "$ABV" \ --signing-algorithm ES384 \ --duration-seconds 300 \ --query WebIdentityToken --output text Rasmussen Expires 9 April 2027 [Page 39] Internet-Draft ACME Workload Identity Challenge October 2026 Claims of interest: "sub" carrying the calling IAM principal's ARN; optional custom claims supplied as Tags at token request time. Note that Tags are chosen by the caller and MUST NOT be treated by policy as authoritative. Policy note: Match the role ARN, and be aware that an ARN may be deleted and recreated with a different trust policy (Section 10.4). The default 300-second lifetime suits this mechanism well. A.4. Microsoft Azure Two paths exist and they differ in the property that matters most here. AKS workload identity: The token is issued by the cluster's OIDC issuer as a projected service account token, and the audience is an arbitrary string chosen per request. Treat as Appendix A.2. Instance Metadata Service managed identity: Not usable with this document. As described in [AZURE-IMDS], a GET to "http://169.254.169.254/metadata/identity/oauth2/token" with "api- version" and a "resource" parameter, and the "Metadata: true" header, returns a token whose "aud" is the "resource" value. That value must be the Application ID URI of an application registered in the Entra tenant, typically of the form "api://APPLICATION- CLIENT-ID", and cannot be varied per request. The audience therefore cannot carry the ABV, and requirement 3 of Section 7 is not met. For reference, the issuer is of the form "https://login.microsoftonline.com/TENANT-ID/v2.0", and "sub" for a managed identity corresponds to the identity's object ID. Policy note: Use the AKS path. A virtual machine workload not running on AKS, with only IMDS available, cannot use "wif-01": either obtain a token from another provider available in that environment whose audience is per-request, or run the issuing step somewhere that can. Registering a dedicated Application ID URI does not help, because the resulting token remains a bearer credential (Section 3.3). Appendix B. Worked Example A GitHub Actions workflow in repository "example-corp/gateway" obtains a certificate for "gateway.internal.example.com" from a private CA. Example Corp, the Subscriber, configured one policy entry with the CA in advance: Rasmussen Expires 9 April 2027 [Page 40] Internet-Draft ACME Workload Identity Challenge October 2026 identifier dns:gateway.internal.example.com issuer https://token.actions.githubusercontent.com require repository_owner_id = 1234567 require repository_id = 89012345 require ref = refs/heads/main The CA's directory does not set "externalAccountRequired". The workflow holds no credential for the CA of any kind. The client generates a fresh account key and POSTs newAccount with no "externalAccountBinding" field. The account is created. It carries no authority: the CA knows nothing about the client yet, and would authorize nothing for it (Section 5). The client POSTs newOrder for "gateway.internal.example.com". Creating the authorization, the CA looks up the entry above, finds the GitHub issuer, and offers: { "type": "wif-01", "url": "https://ca.example.com/acme/chall/Rg5dV14Gh1Q", "status": "pending", "token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0", "issuers": ["https://token.actions.githubusercontent.com"] } The challenge names the issuer but not the expected claim values. The client has no need of them, since it cannot choose them (Section 8.2). The client computes the key authorization per Section 8.1 of [RFC8555], computes the ABV from it, requests a token with that audience, and POSTs it to the challenge URL inside a JWS signed by the account key. The CA verifies the signature against GitHub's published keys, confirms "exp" is within 300 seconds, recomputes the ABV from the challenge token and the thumbprint of the account key that signed the request, and confirms it appears in "aud". It then applies the entry's rule: the token's "repository_owner_id", "repository_id", and "ref" all match. The challenge becomes valid and the CA sets the authorization's "expires" to the token's "exp", so a later order will have to answer a fresh challenge (Section 4.5). The order becomes ready and the client finalizes it. No secret was configured in the repository, or anywhere else, at any point. Rasmussen Expires 9 April 2027 [Page 41] Internet-Draft ACME Workload Identity Challenge October 2026 Appendix C. Comparison with the ACME Authority Token [RFC9447] solves an adjacent problem and it is worth being precise about the difference, since the two are easily confused. +=====================+========================+====================+ | | Authority Token (RFC | This document | | | 9447) | | +=====================+========================+====================+ | Token issuer | A Token Authority in a | A general-purpose | | | business relationship | platform IdP with | | | with the CA | no CA | | | | relationship | +---------------------+------------------------+--------------------+ | Issuer awareness of | Required; mints ACME- | None; issues its | | ACME | specific claims | ordinary token | +---------------------+------------------------+--------------------+ | Account binding | "atc" claim carrying | The "aud" claim | | | the account key | carrying a digest | | | fingerprint | of the key | | | | authorization | +---------------------+------------------------+--------------------+ | Requires new claims | Yes | No | | from the issuer | | | +---------------------+------------------------+--------------------+ | Per-identifier-type | Yes, one per type | No | | profile needed | | | +---------------------+------------------------+--------------------+ | Defined profiles | TNAuthList [RFC9448]; | n/a | | | JWTClaimConstraints | | | | (see Section 1.4) | | +---------------------+------------------------+--------------------+ Table 5: The ACME Authority Token and this document compared The decisive difference is the third and fourth rows. Section 3.3 of [RFC9447] binds the token to the ACME account by placing a fingerprint of the account key inside the token, and Section 5.4 of [RFC9448] makes the ACME server verify it. That requires the token issuer to accept the fingerprint as an input and emit it as a claim. A Token Authority operated for this purpose can do so. GitHub, Azure, AWS and Kubernetes cannot and will not. This document's contribution is the observation that the audience claim is a sufficient channel for that binding, and is one every provider already offers. Everything else follows from it. Rasmussen Expires 9 April 2027 [Page 42] Internet-Draft ACME Workload Identity Challenge October 2026 An operator who controls their own Token Authority, and whose identifiers have a registered profile, should use [RFC9447]. An operator whose workloads are authenticated by a platform they do not control should use this document. Acknowledgements The authors of [I-D.ietf-acme-openid-federation] gave early advice to keep this work within the extension points ACME already defines and to leave account registration as [RFC8555] specifies it. That advice led directly to Section 5. Author's Address Scott Rasmussen Independent Email: scott@zaita.com Rasmussen Expires 9 April 2027 [Page 43]