]> Your Organization Here

unstable.pseudonym@stabledomain.net

Security Web Authorization Protocol oauth x.509 pki client authentication assertion bearer token This specification defines the use of an X.509 certificate, issued under a Public Key Infrastructure (PKI), as a means for requesting an OAuth 2.0 access token as well as for client authentication, profiling the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants in a manner analogous to the JSON Web Token (JWT) Bearer Token profile and the SAML 2.0 Bearer Assertion profile. It is motivated primarily by workload identity systems, such as SPIFFE/SPIRE and Athenz, that already issue software workloads short-lived X.509 certificates for mutual TLS, and that benefit from using those same certificates directly with OAuth 2.0. Unlike a bare bearer credential, this profile requires that possession of the private key corresponding to the certificate's public key be corroborated as part of every use, so that a copy of the certificate alone -- which is not a secret -- is never sufficient to obtain a grant or authenticate a client. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction JSON Web Token (JWT) and Security Assertion Markup Language (SAML) 2.0 bearer assertion profiles allow a client that already holds a security token, issued by a trusted party, to present that token directly to an OAuth 2.0 authorization server (AS) -- either as an authorization grant or as a client authentication mechanism -- without minting a purpose-built, single-use assertion for every request. This specification is motivated primarily by workload identity systems: infrastructure that automatically issues and rotates short-lived X.509 certificates to software workloads -- services, processes, or automated agents, as distinct from human end users -- as their means of cryptographic identity, typically as part of a service mesh or zero-trust network architecture. SPIFFE and its SPIRE runtime and Athenz are two examples of such systems in current production use; both issue workloads an X.509 certificate carrying a URI Subject Alternative Name (SAN), commonly using the "spiffe://" URI scheme, as the workload's primary identifier (see ). A workload that already holds such a certificate, and that already uses it to authenticate over mutual TLS to its peers, benefits from being able to use that same certificate and trust relationship directly with an OAuth 2.0 authorization server, instead of provisioning and operating a separate JWT issuer solely to obtain OAuth tokens. This specification is not limited to workload identity deployments, but they are its primary motivating use case, and are referenced throughout as running examples. This specification profiles the OAuth Assertion Framework to define an extension grant type that uses an X.509 certificate to request an OAuth 2.0 access token, as well as for use as a client authentication credential. The format and processing rules defined here are intentionally similar, though not identical, to those in and ; the differences arise from the structure and semantics of X.509 certificates, which were designed to bind a public key to a subject identity for use across many contexts and over comparatively long lifetimes, and not to express single-transaction claims such as an intended audience or an issuance time for one specific request. This specification is related to, but distinct from, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" . RFC 8705 authenticates a client using the certificate presented during the TLS handshake with the authorization server itself, and does not define a way to use a certificate as an authorization grant. This specification instead carries a reference to (or, when necessary, a copy of) an X.509 certificate as an assertion value within the token request, which allows the same underlying PKI-issued identity to also be used as an authorization grant, and accommodates deployments in which TLS is terminated in front of the authorization server's application logic (for example, by a load balancer or reverse proxy) and the verified client certificate is forwarded to the token endpoint by a trusted intermediary. Because a certificate, unlike a private key, is not itself a secret, Section 3 of this document requires that proof of possession of the associated private key be corroborated by one of these mechanisms as part of processing every request; see also Section 6 (Security Considerations). Once a grant has been obtained or a client authenticated under this profile, recommends carrying that same proof-of-possession property forward into the issued access token by reusing RFC 8705's certificate-bound access token mechanism, so that PKI possession is required consistently across the whole exchange rather than only at the token endpoint. The process by which the client obtains its X.509 certificate, prior to using it with the authorization server, is out of scope of this document.

Notational Conventions 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. Unless otherwise noted, all the protocol parameter names and values are case sensitive.

Terminology All terms are as defined in the following specifications: "The OAuth 2.0 Authorization Framework" , the OAuth Assertion Framework , and "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" .

X.509 Bearer Certificate:

An X.509 certificate, valid under , used as an assertion per this specification, together with a corroborated proof that the presenting party possesses the private key corresponding to the certificate's public key.

Issuing CA:

The Certification Authority identified in the Issuer field of an X.509 Bearer Certificate.

Workload:

A software workload -- a service, process, or automated agent -- as distinct from a human end user, that acts as an OAuth client, a resource owner, or both, in its own right.

Workload Identity Certificate:

An X.509 Bearer Certificate issued to a Workload by a workload identity control plane (for example, a SPIRE server implementing SPIFFE , or Athenz ), as distinct from a certificate issued to a human end user by a general-purpose enterprise or public PKI. Workload Identity Certificates are typically valid for a short, fixed lifetime, are rotated automatically and frequently by the issuing control plane well before expiry, and identify the Workload using a URI SubjectAltName, commonly one using the "spiffe://" URI scheme, rather than (or in addition to) a Subject distinguished name.

HTTP Parameter Bindings for Transporting X.509 Certificate Assertions The OAuth Assertion Framework defines generic HTTP parameters for transporting assertions (a.k.a. security tokens) during interactions with a token endpoint. This section defines specific parameters and treatments of those parameters for use with X.509 Bearer Certificates.

Using X.509 Certificates as Authorization Grants To use an X.509 Bearer Certificate as an authorization grant, the client uses an access token request as defined in Section 4 of the OAuth Assertion Framework with the following specific parameter values and encodings. The value of the "grant_type" is "urn:ietf:params:oauth:grant-type:x509-bearer". The value of the "assertion" parameter MUST contain a single X.509 certificate, encoded as the base64url -style encoding (unpadded, per the base64url alphabet) of the certificate's DER encoding, or, when the client reaches the token endpoint over a mutually authenticated TLS connection, a thumbprint reference to that same certificate as defined in . The "scope" parameter may be used, as defined in the OAuth Assertion Framework , to indicate the requested scope. Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 , and consequently the "client_id" is only needed when a form of client authentication that relies on the parameter is used. The following example demonstrates an access token request with an X.509 certificate as an authorization grant (with extra line breaks for display purposes only):

Using X.509 Certificates for Client Authentication To use an X.509 Bearer Certificate for client authentication, the client uses the following parameter values and encodings. The value of the "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-type:x509-bearer". The value of the "client_assertion" parameter contains a single X.509 certificate, encoded as described in , or a thumbprint reference as described in . It MUST NOT contain more than one certificate or reference. The following example demonstrates client authentication using an X.509 certificate during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only):

Referencing the Certificate Presented for Mutual TLS When the client reaches the token endpoint over a mutually authenticated TLS connection, the certificate it presented during that TLS handshake is already available to the authorization server, and embedding a full copy of it a second time in the "assertion" or "client_assertion" value is unnecessary. In this case, the client MAY instead send a reference to that certificate, consisting of the literal string "x5t#S256:" followed immediately by the base64url-encoded (unpadded) SHA-256 digest of the certificate's DER encoding -- computed identically to the "x5t#S256" confirmation method value defined in Section 3.1 of . Because neither "#" nor ":" occur in the base64url alphabet, this reference form can never be mistaken for the base64url-encoded certificate encoding described in and . An authorization server that receives an "assertion" or "client_assertion" value in this form MUST independently obtain the actual certificate from a source it trusts for the corroboration required by item 7 of -- either the certificate presented on its own TLS connection with the client, or a certificate or thumbprint forwarded by a trusted intermediary -- and MUST verify that the SHA-256 digest of that certificate's DER encoding matches the referenced thumbprint before proceeding. An authorization server MUST NOT accept a thumbprint reference together with a certificate supplied elsewhere in the client's request as if the two were mutually corroborating; the certificate the thumbprint is checked against MUST come from the TLS layer or a trusted intermediary, never from the request itself. This reference form is only meaningful when proof of possession is otherwise corroborated per item 7 of ; it is a shorthand for avoiding retransmission of a certificate the authorization server already has, not a substitute for that corroboration. The following example shows the client authentication example above expressed as a thumbprint reference instead of a full certificate, using the certificate from the example in , with extra line breaks for display purposes only:

X.509 Certificate Format and Processing Requirements In order to issue an access token response as described in OAuth 2.0 or to rely on an X.509 certificate for client authentication, the authorization server MUST validate the certificate and the request according to the criteria below. Throughout this section, "the certificate" refers to the X.509 certificate conveyed by the "assertion" or "client_assertion" value, whether encoded directly as described in and or identified by a thumbprint reference as described in . Application of additional restrictions and policy are at the discretion of the authorization server.

1. The certificate MUST be well-formed and valid under , MUST chain to a trust anchor configured at the authorization server (either directly or via a configured set of intermediate CA certificates), and MUST NOT be revoked, as determined per the authorization server's configured revocation-checking mechanism (for example, CRLs or OCSP ).
2. The Issuer field of the certificate identifies the Issuing CA, which fills a role equivalent to the "iss" claim in . The authorization server MUST have a pre-established trust relationship with the Issuing CA, and MUST NOT accept certificates from CAs outside its configured set of trust anchors.
3. The Subject field and/or the subjectAltName extension of the certificate identifies the principal that is the subject of the certificate, filling a role equivalent to the "sub" claim in . Two cases need to be differentiated: A. For the authorization grant, the subject typically identifies an authorized accessor for which the access token is being requested (i.e., the resource owner or an authorized delegate). B. For client authentication, the subject, or a specific subjectAltName value designated for this purpose by prior agreement between the client and the authorization server, MUST correspond to the "client_id" of the OAuth client. The authorization server MUST be configured, per Issuing CA, with the rule used to extract the relevant identifier from the Subject field or subjectAltName extension. For a Workload Identity Certificate (), this identifier is typically a URI SAN, commonly one using the "spiffe://" URI scheme as issued by SPIFFE/SPIRE or Athenz ; authorization servers supporting Workload Identity Certificates SHOULD extract the subject identifier from the URI SAN in preference to the Subject field, which such certificates often leave empty or unpopulated.
4. X.509 certificates as defined in have no field with semantics equivalent to the JWT "aud" claim. Audience restriction for this profile is therefore established out of band between the Issuing CA (or its operator) and the authorization server, as part of the same agreement that establishes the trust anchor relationship described in item 2 above; see also . Where the subject identifier is a "spiffe://" URI SAN as described in item 3, the trust domain component of that URI (the authority component immediately following the scheme) MAY additionally be used by the authorization server as an informal, coarse-grained signal for which relying parties a given Issuing CA's certificates are intended for, but doing so is a matter of local policy and does not by itself substitute for the out-of-band trust agreement described above. A future revision of this specification, or a companion specification, MAY define an X.509 certificate extension carrying an explicit, in-band audience restriction for deployments that require it; in the absence of such an extension, the authorization server MUST rely on its out-of-band configuration to determine whether it is an intended relying party for certificates issued by a given Issuing CA.
5. The certificate's notBefore and notAfter validity fields fill roles equivalent to the "nbf" and "exp" claims in . The authorization server MUST reject any certificate that is not currently within its validity period, subject to allowable clock skew between systems. The authorization server MAY reject certificates whose remaining validity period is unreasonably long for use as a bearer assertion under this profile; see .
6. The combination of the Issuer field and the certificate's serialNumber fills a role equivalent to the "jti" claim in as a unique identifier for the token. The authorization server MAY track (Issuer, serialNumber) pairs it has already processed, within a configured window, to detect and reject replayed requests; see .
7. The authorization server MUST corroborate that the party presenting the certificate possesses the private key corresponding to the certificate's public key. This corroboration MUST be established by one of the following means: A. The certificate presented as the "assertion" or "client_assertion" value is the same certificate the client presented during mutual TLS authentication of the connection to the token endpoint, per , thereby directly proving possession as part of the TLS handshake; or B. The certificate was forwarded to the authorization server by a trusted intermediary (for example, a TLS-terminating reverse proxy or load balancer situated directly in front of the authorization server) over a channel the authorization server trusts, together with an attestation from that intermediary that the certificate was successfully used to authenticate a TLS client during the connection now being forwarded. A certificate presented as an "assertion" or "client_assertion" value without either form of corroboration MUST be rejected. See . When the "assertion" or "client_assertion" value is a thumbprint reference per , mechanism (A) is satisfied directly: the authorization server computes the comparison thumbprint from the certificate it obtained via its own TLS handshake with the client, rather than from a certificate encoded in the request itself.
8. The authorization server MUST reject a certificate that is not valid in all other respects per , including but not limited to key usage and extended key usage constraints applicable to this use, where such constraints are configured by the authorization server.

Authorization Grant Processing X.509 Bearer Certificate authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with an X.509 Bearer Certificate authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server. However, if client credentials are present in the request, the authorization server MUST validate them. If the certificate is not valid, or the current time is not within the certificate's valid time window for use, or proof of possession cannot be corroborated as required by item 7 of , the authorization server constructs an error response as defined in OAuth 2.0 . The value of the "error" parameter MUST be the "invalid_grant" error code. The authorization server MAY include additional information regarding the reasons the certificate was considered invalid using the "error_description" or "error_uri" parameters. For example:

Client Authentication Processing If the client's certificate is not valid, the authorization server constructs an error response as defined in OAuth 2.0 . The value of the "error" parameter MUST be the "invalid_client" error code. The authorization server MAY include additional information regarding the reasons the certificate was considered invalid using the "error_description" or "error_uri" parameters.

Certificate-Bound Access Tokens When an authorization server issues an access token as a result of successfully processing an X.509 Bearer Certificate authorization grant (), or after authenticating a client using an X.509 Bearer Certificate under this profile (), the authorization server SHOULD bind the resulting access token to that certificate using the certificate-bound access token mechanism defined in Section 3 of , rather than issuing a plain bearer access token. Doing so carries the proof-of-possession property established when the certificate was corroborated per item 7 of forward to the resource server, using the same "x5t#S256" confirmation method value already reused for the reference form defined in , so that use of the access token also requires possession of the same private key that was required to obtain it. An authorization server MAY instead issue a plain bearer access token when local policy determines that certificate binding is unnecessary for the resource being protected, but doing so discards the proof-of-possession property this profile otherwise provides throughout the request, and SHOULD be a deliberate policy choice rather than a default.

Authorization Grant Example The following example illustrates what a conforming certificate and an access token request would look like. The example shows a Workload Identity Certificate () issued to a "billing" workload by the Issuing CA identified as "CN=Example Workload CA, O=Example Corp, C=US". The subject of the certificate is identified by a "spiffe://" URI SAN, "spiffe://example.org/ns/prod/sa/billing", per , and is valid for one hour, consistent with automatic rotation by the issuing workload identity control plane. The authorization server "https://authz.example.net" has been configured, out of band, to trust certificates issued by this CA, and to treat the trust domain "example.org" as identifying an intended relying party, as described in . The client presents the certificate over a mutually authenticated TLS connection to the authorization server's token endpoint at "https://authz.example.net/token.oauth2". Below is a summary of the relevant fields of the certificate: To present this certificate as part of an access token request, the client -- having already established the connection above via mutual TLS using this same certificate -- might make the following HTTPS request (with extra line breaks for display purposes only):

Interoperability Considerations Agreement between system entities regarding trust anchors, identifiers, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: the set of trust anchors and Issuing CAs recognized by the authorization server, the rule used to map a certificate's Subject field or subjectAltName extension to a resource owner identity or "client_id", which Issuing CAs' certificates the authorization server considers itself an intended relying party for (in lieu of an in-band "aud" equivalent, per item 4 of ), the revocation-checking mechanism to be used, the mechanism by which proof of possession is corroborated (direct mutual TLS to the authorization server versus a trusted forwarding intermediary, per item 7 of ), whether the authorization server accepts the thumbprint reference form of in addition to, or instead of, a fully encoded certificate, and any maximum certificate lifetime the authorization server will accept for use under this profile. The exchange of such information is explicitly out of scope for this specification. Where the Issuing CA is a workload identity control plane, some or all of this agreement may be established and kept current automatically, for example by having the authorization server obtain and refresh its set of trust anchors from a SPIFFE trust bundle endpoint or an equivalent mechanism, rather than through static, manually configured trust anchors; this specification does not define such a mechanism and treats it as an implementation detail of how the out-of-band agreement above is kept up to date. Because certificates issued for general-purpose PKI use are typically valid for periods far longer than is typical for a JWT or SAML bearer assertion, deployments SHOULD either issue certificates intended for use under this profile with comparatively short validity periods, or have the authorization server apply a locally configured maximum acceptable remaining lifetime, or both. Workload Identity Certificates () issued by systems such as SPIFFE/SPIRE or Athenz already follow this practice by design, typically being valid for periods on the order of minutes to hours and rotated automatically well before expiry; deployments using such certificates under this profile satisfy this recommendation without additional configuration, and this is the expected deployment pattern this specification is primarily designed around; see also . RSA with SHA-256, and ECDSA with curve P-256 and SHA-256, are RECOMMENDED baseline certificate signature algorithms for this profile, to maximize interoperability.

Security Considerations The security considerations described within the following specifications are all applicable to this document: "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" , "The OAuth 2.0 Authorization Framework" , and "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" . Unlike a JWT or SAML assertion, whose bearer semantics rely on the issuer's signature over a short-lived, narrowly scoped set of claims, an X.509 certificate is designed to be shared openly: it is routinely sent in the clear during TLS handshakes, may be logged by intermediaries, and, for publicly trusted CAs, may be published in Certificate Transparency logs. A certificate is therefore not a secret, and a copy of one proves nothing about who is presenting it. For this reason, this specification requires, in item 7 of , that possession of the certificate's private key be corroborated for every request, either through the TLS handshake to the authorization server itself or through an attestation from a trusted intermediary. Implementations MUST NOT grant access, and MUST NOT authenticate a client, solely on the basis that a syntactically and cryptographically valid certificate was presented as an "assertion" or "client_assertion" value; doing so would allow trivial impersonation by any party that obtained a copy of the certificate, without needing the associated private key. Authorization servers SHOULD track recently processed (Issuer, serialNumber) pairs, within a window derived from the certificate's validity period or a locally configured limit, to reduce the impact of a request being replayed even when proof of possession corroboration per item 7 of is somehow satisfied more than once (for example, by a compromised or overly permissive forwarding intermediary). For general-purpose, longer-lived certificates, revocation checking is particularly important under this profile, since certificate validity periods can be much longer than the lifetime of a JWT or SAML bearer assertion; a compromised private key can otherwise remain usable under this profile for a much longer window than would be typical of the analogous JWT or SAML bearer profiles. For Workload Identity Certificates (), whose short validity periods and frequent, automatic rotation are themselves the primary mitigation against a compromised private key remaining usable for long, revocation checking is a useful defense-in-depth measure but is less load-bearing than certificate lifetime, and authorization servers deployed against such certificates MAY choose not to perform revocation checking at all, provided the configured maximum acceptable certificate lifetime (see ) is short enough that the risk is otherwise acceptable. Authorization servers configured to trust more than one Issuing CA MUST ensure that identifiers extracted from a certificate issued by one CA are not confused with, or allowed to impersonate, identifiers meant to be asserted only by a different CA. The thumbprint reference form defined in is only as trustworthy as the source the authorization server checks it against. An authorization server MUST compute the comparison thumbprint from a certificate it obtained itself, either from its own TLS stack or from a trusted intermediary via a channel the client cannot influence; it MUST NOT accept a thumbprint together with a client-supplied certificate purporting to match it, since a client able to influence both values could reference an arbitrary certificate it does not hold the private key for.

Privacy Considerations An X.509 certificate typically contains more identifying information than the minimal set of claims a deployment would choose for a JWT or SAML bearer assertion, and, being a long-lived, widely presented credential, can act as a stable identifier that enables correlation of a subject's activity across the multiple relying parties the certificate is presented to. To prevent disclosure of such information to unintended parties, an X.509 Bearer Certificate should only be transmitted over encrypted channels, such as those provided by TLS . Deployments should determine the minimum amount of information necessary in the Subject field and subjectAltName extension to complete the exchange, should consider issuing purpose-specific certificates rather than reusing a single general-purpose certificate across unrelated relying parties, and should consult the guidance in when designing the identifiers a certificate exposes.

IANA Considerations

Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:x509-bearer This section registers the value "grant-type:x509-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" .

• URN: urn:ietf:params:oauth:grant-type:x509-bearer
• Common Name: X.509 Bearer Certificate Grant Type Profile for OAuth 2.0
• Change Controller: IESG
• Specification Document: This document

Sub-Namespace Registration of urn:ietf:params:oauth:client-assertion-type:x509-bearer This section registers the value "client-assertion-type:x509-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" .

• URN: urn:ietf:params:oauth:client-assertion-type:x509-bearer
• Common Name: X.509 Bearer Certificate Profile for OAuth 2.0 Client Authentication
• Change Controller: IESG
• Specification Document: This document

This document does not request assignment of an X.509 certificate extension object identifier. Should a future revision define the optional in-band audience-restriction extension mentioned in item 4 of , that revision will need to make an appropriate IANA request at that time.

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. 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 This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. SPIFFE Project Athenz Project This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]

Acknowledgments This profile follows the pattern established by and , which share a common lineage back to the OAuth Assertion Framework . TODO acknowledge reviewers and contributors.