]> Independent

scott@zaita.com

Security ACME Working Group ACME workload identity federation OpenID Connect certificate issuance CI/CD 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.

Introduction

Motivation A certificate issuance system must answer two questions: who is asking, and are they entitled to the identifier they are asking for. ACME 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 signed with a key published at a well-known JWKS endpoint, and permits the relying party to verify it using OpenID Connect 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 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.

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 , which requires the token to carry an "atc" claim containing a fingerprint of the ACME account key (). No general purpose identity provider will emit such a claim, and none can, because the provider has no knowledge of the ACME account key. discusses the relationship in more detail. The obstacle is not that the binding value means anything to the token issuer. 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 . The result requires nothing of the identity provider that it does not already do. 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. discusses the boundary.

Scope This document defines:

• a new ACME challenge type, "wif-01" (), 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 () that ties a WIF token to a specific ACME account key and to a specific authorization;
• the lifetime rule () that keeps a federated authorization from outliving the assertion that produced it;
• the account model () under which an ordinary ACME account, created without External Account Binding, is sufficient; and
• directory metadata () 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 already provides: one validation method, five error types, and one directory metadata field, each entered in the registry established for it; a challenge type, whose object fields are defined with it as anticipates; and a label beneath the "urn:ietf:params:acme" namespace (). It changes no existing request, resource, or state transition.

Relationship to Other Work ACME Authority Token and its TNAuthList profile 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 . 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 or EnhancedJWTClaimConstraints 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 , and so falls under the constraint of exactly as the TNAuthList profile does. Nothing in this document interacts with it, and a CA may implement both. ACME with 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 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 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.

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 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 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 (), not in any ACME account ().

Audience Binding Value:

The value computed per 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 -- account, account key, authorization, challenge, identifier, key authorization, order -- are used as defined there. Terms from and are used as defined there.

Overview

Participants

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.

Protocol Flow The following illustrates the flow in full.

wif-01 challenge flow | | |<-- 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 ------------->| | ]]>

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 .

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 platform-issued token whose value the Workload can influence on every major platform. The binding to the ACME account key therefore travels there; specifies the construction. An identity provider that does not permit the Workload to choose the audience per request cannot be used with this document ().

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 .

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.

The Audience Binding Value

Construction The Audience Binding Value (ABV) is computed as: where "||" denotes concatenation, base64url is base64url encoding without padding , and "context" is an ASCII string determined by the mechanism in use. For the "wif-01" challenge (): where keyAuthorization is exactly the value defined in , that is, the challenge "token" value, a "." (0x2E) separator, and the base64url encoding of the JWK SHA-256 Thumbprint 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. 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 other than the colons in the URN prefix, and is therefore acceptable as an audience value to every identity provider surveyed in .

Rationale Reusing the key authorization of 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 for the relationship between this construction and the ordinary meaning of the "aud" claim.

Binding Requirement The Workload requests a WIF Token whose "aud" claim contains the ABV computed per , and the ACME Server MUST verify its presence (step 7 of ). 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. 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 . 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; describes the supported path on that platform. See .

The "wif-01" Challenge Type

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; later requires the request's names to match the order's identifiers. 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 (), so a CA requiring both proof of control and federated identity MUST NOT express that as two challenges in one authorization.

Challenge Object A "wif-01" challenge object has the fields defined in and the following additional fields:

token (required, string):

A random value that uniquely identifies the challenge, as defined in . 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 (). When present, a client SHOULD select an identity provider from this list. When absent, the full advertised set applies. discusses what narrowing discloses.

A wif-01 challenge object

Client Behaviour To respond to a "wif-01" challenge, the client:

1. Computes the key authorization per from the challenge "token" and its account key.
2. Computes the Audience Binding Value per .
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 . 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 , whose payload is a JSON object with a single field:

The payload of a wif-01 challenge response

The "wifToken" field contains the WIF Token in JWS Compact Serialization . 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 . A client MUST NOT write a WIF Token to persistent storage, and MUST NOT emit one to a log or console. See .

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 .

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 , 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 () 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 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 emits "kid".
5. Verify the JWS signature per .
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" () 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 . 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 (), and a challenge that has left the "pending" state does not return to it (). A server that implements no replay cache is conformant; one that does will catch a client or server defect that violates either property.
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 .
10. Set the challenge status to "valid" and the enclosing authorization status to "valid" per , and set the authorization's "expires" field as required by .

Steps 2 through 8 are protocol requirements and a conforming server MUST implement them as stated. Step 9 is where deployment-specific judgement lives.

Lifetime and Reuse of Federated Authorizations 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" () 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 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. 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 already defines, with the meaning already gives it, and alters nothing in the order or authorization lifecycle. 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 () SHOULD do so. Platform token lifetimes are short -- 300 seconds by default on several of the platforms in -- 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.

Retrieval and Caching of Issuer Keys An ACME Server obtains an issuer's signing keys by retrieving the OpenID Provider Metadata from the issuer identifier, and then the JWK Set 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 . 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.

Error Types This document defines the error types in , to be used in the "error" field of an invalidated challenge and in problem documents returned in response to a challenge. Error types defined by this document

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

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 (). The requester may be unauthenticated (), and the token's own values are the only ones it has already established.

Accounts

External Account Binding Is Not Required defines External Account Binding (EAB) so that a CA can associate a new ACME account with a Subscriber it already knows, and 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 () that the Workload's WIF Token satisfies, and it is established afresh for every authorization. The account presenting the token contributes a key to which the token is bound () and nothing else. It holds no authority of its own, and whatever an authorization lets it obtain lapses when that authorization expires (). EAB therefore has no part in deciding who a Workload is or what it may obtain. A Workload creates an ordinary 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.

Coexisting with External Account Binding "externalAccountRequired" () 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 :

• 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 .

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
• 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.

Directory Metadata A server supporting this document SHOULD advertise the fact in the "meta" field of its directory object (), 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.

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 instead. The directory is retrieved without authentication (), so its contents cannot be varied by requester. See .

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 signed with a digital signature algorithm from or a successor, of at least 128-bit security strength.
2. It publishes OpenID Provider Metadata 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 .
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 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 .

Authorization Policy

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 (). The relation can be read in either direction, and a server may index it either way: 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 ); 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 . 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 () 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 ().

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 (). A server MUST NOT include expected claim values in a challenge object or in a problem document (). 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 ), and what establishes that it was issued for this authorization is the audience binding (). 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.

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 .

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, 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 . 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.

IANA Considerations

ACME Validation Methods IANA is requested to add the following entry to the "ACME Validation Methods" registry: Addition to the ACME Validation Methods registry

Label	Identifier Type	ACME	Reference
wif-01	dns	Y	This document
wif-01	ip	Y	This document

The "wif-01" method is applicable to further identifier types; entries for those are expected to be registered by the documents defining them.

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:": Additions to the ACME Error Types registry

Type	Description	Reference
badWifToken	The WIF Token was malformed, unverifiable, or not currently valid	This document
wifIssuerNotAccepted	The token issuer is not accepted for this authorization	This document
wifAudienceMismatch	The token audience did not contain the expected binding value	This document
wifTokenReplayed	A token with this identifier has already been presented	This document
wifPolicyDenied	Policy does not permit this workload to obtain this identifier	This document

ACME Directory Metadata Fields IANA is requested to add the following entry to the "ACME Directory Metadata Fields" registry: Addition to the ACME Directory Metadata Fields registry

Field Name	Field Type	Reference
wif	object	This document

Challenge Object Fields and URN Label No IANA registry exists for the fields of a challenge object, which leaves to the definition of each challenge type. The "issuers" field is defined in as part of the "wif-01" challenge type and requires no registration. The Audience Binding Value of uses the prefix "urn:ietf:params:acme:wif:" within the "urn:ietf:params:acme" namespace registered by . 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 may share this label. See .

Security Considerations

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 . This protection is what makes the mechanism deployable, and it is why 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 (), or a different platform, not to weaken the binding.

Use of the "aud" Claim The "aud" claim of 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. 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 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 , 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 is load-bearing.

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 (). 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.

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".

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. 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.

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. 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.

Policy Enumeration Where accounts are created without EAB (), 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 (), 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.

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 (). A replay cache, where a server implements one (), 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.

Cryptographic Agility and Algorithm Confusion Step 2 of 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.

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.

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 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 .

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 and become permanent public record.

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 discloses to any unauthenticated party which identity platforms the CA's subscribers use, and for EKS-style issuers may disclose specific cluster identifiers. permits a CA to omit the advertised set. Challenges disclose more, identifier by identifier; see . 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 .

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. excludes them, which today excludes the Azure Instance Metadata Service path (). 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.
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 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 , 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. 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 -- is an open question.
8. The "urn:ietf:params:acme:wif:" prefix. 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.

References Normative References Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required. In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; these certificates are often called "Secure Telephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT. Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Huawei Cryptic Forest Software, Ltd Sandelman Software Works Inc AppViewX, Inc This document describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. Somos Inc. Somos Inc. 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. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. independent ISRG ISRG ISRG The Automatic Certificate Management Environment (ACME) protocol allows server operators to obtain TLS certificates for their websites, based on a demonstration of control over the website's domain via a fully-automated challenge/response protocol. OpenID Federation 1.0 defines how to build a trust infrastructure using a trusted third-party model. It uses a trust evaluation mechanism to attest to the possession of private keys, protocol specific metadata and miscellaneous administrative and technical information related to a specific entity. This document defines how X.509 certificates associated with a given OpenID Federation Entity can be issued by an X.509 Certification Authority through the ACME protocol to the organizations which are part of a federation built on top of OpenID Federation 1.0. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism.

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.

GitHub Actions

Issuer:

"https://token.actions.githubusercontent.com"

Audience control:

Arbitrary string, chosen per request.

Acquisition:

As described in , 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)".

Claims of interest:

"sub" (composite, and customizable by the organization -- see ), "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.

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 (). 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 , 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.

Amazon Web Services

Issuer:

For EKS workloads, the cluster OIDC issuer (). 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 , 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.

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 (). The default 300-second lifetime suits this mechanism well.

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 .

Instance Metadata Service managed identity:

Not usable with this document. As described in , 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 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 ().

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: 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 (). 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: The challenge names the issuer but not the expected claim values. The client has no need of them, since it cannot choose them (). The client computes the key authorization per , 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 (). The order becomes ready and the client finalizes it. No secret was configured in the repository, or anywhere else, at any point.

Comparison with the ACME Authority Token solves an adjacent problem and it is worth being precise about the difference, since the two are easily confused. The ACME Authority Token and this document compared

	Authority Token (RFC 9447)	This document
Token issuer	A Token Authority in a business relationship with the CA	A general-purpose platform IdP with no CA relationship
Issuer awareness of ACME	Required; mints ACME-specific claims	None; issues its ordinary token
Account binding	"atc" claim carrying the account key fingerprint	The "aud" claim carrying a digest of the key authorization
Requires new claims from the issuer	Yes	No
Per-identifier-type profile needed	Yes, one per type	No
Defined profiles	TNAuthList ; JWTClaimConstraints (see )	n/a

The decisive difference is the third and fourth rows. binds the token to the ACME account by placing a fingerprint of the account key inside the token, and 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. An operator who controls their own Token Authority, and whose identifiers have a registered profile, should use . An operator whose workloads are authenticated by a platform they do not control should use this document.

Acknowledgements The authors of gave early advice to keep this work within the extension points ACME already defines and to leave account registration as specifies it. That advice led directly to .