| Internet-Draft | OAuth APM | June 2026 |
| Vicente | Expires 10 December 2026 | [Page] |
OAuth 2.0 access tokens encode an authorization decision made at issuance time. Sender-constraining mechanisms such as Mutual-TLS certificate binding ([RFC8705]) and Demonstrating Proof of Possession ([RFC9449]) extend this model by proving key possession at request time, but neither mechanism re-evaluates the full security context — certificate validity, token claims, and device-level security posture — against the conditions present at token issuance, nor provides a normative pathway for graduated least-privilege outcomes when that context has degraded.¶
This document describes the Authorization Posture Mechanism (APM) problem domain: the gap between what per-request sender-constraining mechanisms prove cryptographically and what Zero Trust Architecture requires for per-request authorization decisions. It motivates and specifies requirements for a mechanism that (a) assembles a per-request Consistency View comprising the client certificate, the bound access token, and an integrity-protected device-posture signal; (b) evaluates the Consistency View against the Issuance Posture recorded at token issuance; and (c) produces graduated, least-privilege outcomes — scope reduction, method restriction, or full denial — proportional to the degree of posture degradation detected.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft is maintained at https://github.com/Sanc-Admin/oauth-apm. A citable archival version of this document is available at Zenodo: https://doi.org/10.5281/zenodo.20584241. Author ORCID iD: https://orcid.org/0009-0006-6395-5308.¶
Discussion of this document occurs on the IETF "oauth" mailing list (oauth@ietf.org). Issues and pull requests may be filed at the GitHub repository linked above.¶
This note is to be removed before publishing as an RFC.¶
The author has filed or intends to file United States patent applications covering subject matter described in this document. By posting this Internet-Draft, the author submits to the IETF Trust the rights described in Section 5 of BCP 78 and BCP 79. Patent licensing terms are not yet known. Implementers and reviewers should consult the IETF Datatracker IPR disclosure page for this document for current disclosure status.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Zero Trust Architecture, as defined in NIST SP 800-207 [NIST.SP.800-207], requires that access to resources be granted on a per-request basis using dynamic policy that includes the observable state of the client identity, the requesting asset, and behavioral or environmental attributes. NIST SP 800-207 §3.2 states explicitly:¶
"No resource is inherently trusted. Every asset must have its security posture evaluated via a PEP before a request is granted to an enterprise-owned resource. This evaluation should be continual for as long as the session lasts."¶
The OAuth 2.0 framework [RFC6749] issues access tokens that represent an authorization decision frozen at the moment of issuance. The resource server validates token expiry and scope coverage; it does not re-evaluate whether the security conditions that justified issuance still hold. This design was deliberate and appropriate for the HTTP API delegation use case OAuth was designed to serve, but it creates a structural gap with respect to ZTA's per-request evaluation requirement.¶
Two families of sender-constraining mechanisms have been standardized to address portions of this gap:¶
Certificate-bound access tokens ([RFC8705]): The authorization server
records a SHA-256 thumbprint of the client's mutual-TLS certificate in the
cnf/x5t#S256 claim. The resource server checks that the certificate
presented in the current TLS handshake matches the thumbprint. This
proves that the presenter of the token also possesses the private key of the
enrolled certificate. It does not prove that the certificate is currently
valid, that the device on which the key resides is in a compliant security
state, or that any conditions beyond key possession hold at request time.
Section 6.5 of [RFC8705] explicitly places TLS termination and revocation
re-evaluation outside the scope of the specification.¶
Demonstrating Proof of Possession ([RFC9449]): Each HTTP request carries
a freshly generated DPoP proof JWT binding the request to a specific HTTP
method (htm) and URI (htu). This provides per-request proof of key
possession and prevents token-theft replay for a different endpoint. Section
11.7 of [RFC9449] states definitively that DPoP does not ensure the
integrity of the request payload or headers beyond method and URI. Section
11.11 states that cryptographic binding between DPoP and client authentication
mechanisms beyond the scope of that specification is out of scope.¶
Neither mechanism addresses the third dimension: device-level security posture. Neither mechanism evaluates, per-request, whether the triple formed by (client certificate, bound access token, device posture) remains consistent with the security context recorded at token issuance.¶
When inconsistency is detected — for example, when a device that was MDM-enrolled and fully patched at token issuance is later found to be missing a critical security update — the current OAuth ecosystem offers only binary outcomes: either the request succeeds (if the token is still structurally valid) or fails (if the resource server applies an out-of-band revocation).¶
RFC 9470 [RFC9470] defines the insufficient_user_authentication error code
and a WWW-Authenticate challenge mechanism by which a resource server can
signal that the authentication context associated with a token does not meet
requirements. The client must then re-authenticate at the required
acr_values or within the required max_age.¶
This mechanism is reactive (it fires on a specific request failure, not proactively), addresses authentication strength only (not device posture), and its outcome is structurally binary: the authentication requirement is either satisfied upon re-authentication, or the request is denied. There is no mechanism for the resource server to respond with "proceed with a reduced set of permitted operations" rather than "re-authenticate or be denied."¶
RFC 9396 [RFC9396] defines the authorization_details parameter, enabling
fine-grained authorization grants specifying actions, locations,
datatypes, and privileges at issuance time. This is a significant improvement
over the coarse scope model for expressing initial grants.¶
However, the authorization_details claim in an issued token is static for
the token's lifetime. Section 5.3 of [RFC9396] does not define any mechanism
for the resource server to narrow the actions or privileges fields
per-request in response to a runtime posture signal. If the device posture
degrades after token issuance, there is no standardized pathway to downgrade
from "actions": ["read", "write", "delete"] to "actions": ["read"] for
the duration of the degraded state.¶
The OpenID Continuous Access Evaluation Profile [CAEP] defines an
event-driven, asynchronous push mechanism by which a Transmitter (such as an
MDM system or identity provider) can signal state changes to a Receiver (such
as a resource server or authorization server). The Device Compliance Change
event type carries only a binary previous_status / current_status of
compliant or not-compliant.¶
CAEP operates asynchronously. Between the occurrence of a compliance change event and the Receiver's processing of the pushed Security Event Token, there is a temporal gap during which a client with a valid access token may interact with a resource server against a degraded security posture that has not yet been signaled. CAEP does not provide a per-request, in-band posture assertion alongside individual HTTP requests.¶
The draft [I-D.ietf-oauth-attestation-based-client-auth] defines a two-token
structure for attesting client instance properties: a Client Attestation JWT
(issued by the client's backend) and a per-request Client Attestation PoP JWT.
The Client Attestation JWT may be reused across requests until its exp claim.¶
Section 7 of that draft notes that if device posture degrades within the validity window of a Client Attestation JWT, there is no normative mechanism to force fresh attestation. Furthermore, the draft explicitly does not define a schema for device posture claims within the Client Attestation JWT; what hardware and software properties are attested is left to deployment-specific conventions. The mechanism operates at the client authentication layer, not the per-request resource-access layer.¶
This document defines the APM problem domain and specifies functional requirements for a mechanism addressing the three identified gaps:¶
Gap A Section "Gap A: No Per-Request Triple Consistency Verification": No per-request triple consistency verification — no normative mechanism evaluates the certificate, bound token, and device-posture signal together per-request.¶
Gap B Section "Gap B: No Graduated Least-Privilege Outcomes": No graduated least-privilege outcomes — no normative mechanism responds to posture degradation with anything other than a binary allow/deny decision.¶
Gap C Section "Gap C: No Method-Level Downgrade on Posture Degradation": No method-level downgrade on posture degradation — no normative mechanism restricts permitted HTTP methods or operation types for an existing valid token in response to a runtime posture change.¶
This document is informational. It describes the problem domain and specifies requirements; it does not mandate a specific protocol design. Implementors, working group participants, and standards authors are encouraged to use the requirements in Section 4 as evaluation criteria for proposed solutions.¶
No normative mechanism evaluates the certificate, bound token, and device-posture signal together per-request.¶
No normative mechanism responds to posture degradation with anything other than a binary allow/deny decision.¶
No normative mechanism restricts permitted HTTP methods or operation types for an existing valid token in response to a runtime posture change.¶
The APM mechanism is motivated not only by current Zero Trust Architecture requirements but also by the post-quantum cryptographic transition underway across the Internet.¶
Shor's algorithm [SHOR1994] solves the Integer Factorization Problem
(IFP) and the Elliptic Curve Discrete Logarithm Problem (ECDLP) in
polynomial quantum time, meaning that a sufficiently capable
Cryptographically Relevant Quantum Computer (CRQC) can break RSA and
ECDSA/ECDH keys. The TLS client certificates that form the certificate
component of the APM Consistency View are today predominantly RSA or
ECDSA certificates. If a CRQC breaks the private key corresponding to
such a certificate, the cnf/x5t#S256 binding asserted by [RFC8705]
is defeated: an attacker can present any token bound to the compromised
certificate thumbprint and forge the TLS handshake.¶
Grover's algorithm [GROVER1996] provides a quadratic speedup for
unstructured search, effectively halving the bit-security of hash-based
constructs. SHA-256 hashes used in cnf/x5t#S256 ([RFC8705]) and
cnf/jkt ([RFC9449]) provide approximately 128-bit quantum preimage
resistance — sufficient for current threat models, but motivating the
migration to PQ-signed certificates as the certificate component of the
Consistency View.¶
The Harvest-Now-Decrypt-Later (HNDL) threat further amplifies the urgency: an adversary who records TLS sessions today can retroactively recover the session keys once a CRQC is available, recovering the access tokens exchanged within those sessions. Per-request triple consistency evaluation (REQ-1 through REQ-3) and the short posture-assertion freshness window (Section 6.2) limit the window of exposure of any individual access token and its associated Consistency View to the current request rather than an entire session lifetime.¶
The APM mechanism is designed to remain applicable as the OAuth ecosystem transitions to PQ-signed certificates: the certificate component of the Consistency View is algorithm-agnostic; [RFC8705] does not restrict the certificate's key type. A Consistency View assembled from an ML-DSA certificate (as defined in [FIPS204]) functions identically to one assembled from an ECDSA certificate.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used throughout this document.¶
actions in the sense of
[RFC9396]) that the resource server will process for a given request.
For example: an access token that nominally authorizes GET, POST, PUT,
and DELETE may be restricted to GET only when posture degradation is
detected.¶
authorization_details object for the one granted at issuance. Scope
reduction takes effect for the current request and possibly subsequent requests
until posture is restored. Scope reduction MUST NOT be implemented by
modifying the token itself; it MUST be implemented by the resource server
applying the reduced scope as an additional constraint during request
processing.¶
RFC 6749 [RFC6749] describes a model in which the access token represents an authorization decision made at the time of issuance. Section 7 of [RFC6749] specifies that the resource server validates the token's expiry and scope, but "the methods used by the resource server to validate the access token, as well as any error responses, are beyond the scope of this specification." No mechanism in [RFC6749] addresses re-evaluation of the conditions that justified issuance. The token is, in effect, a session surrogate: once issued, it carries the authorization context of the issuance event until expiry or explicit revocation.¶
This model was appropriate for the original delegation use case. It is insufficient for environments governed by Zero Trust Architecture principles, which [NIST.SP.800-207] §2.1 describes as requiring:¶
"...least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised."¶
NIST SP 800-207 Tenet 6 states: "All resource authentication and authorization are dynamic and strictly enforced before access is allowed." This requirement cannot be satisfied by a token whose authorization context was frozen at issuance.¶
Both [RFC8705] and [RFC9449] extend the static token model by adding a
sender-constraint dimension. Certificate-bound tokens ([RFC8705]) prove that
the presenter holds the private key corresponding to the certificate thumbprint
embedded in cnf/x5t#S256. DPoP ([RFC9449]) proves that the presenter holds
the key corresponding to the cnf/jkt thumbprint and that the proof covers
the specific HTTP method and URI of the current request.¶
These mechanisms close a critical replay-token vulnerability but remain single-dimension: they prove cryptographic possession of a key. They do not evaluate:¶
A threat actor who compromises a device to the point of exfiltrating its private key material can generate valid DPoP proofs and present valid certificate-bound tokens indefinitely, because neither mechanism evaluates device security state per-request.¶
When a resource server determines that the authentication or authorization
context of a request is insufficient, the RFC 9470 step-up mechanism
[RFC9470] provides a single escalation path: the client must re-authenticate
at the required acr_values. The outcome is binary: upon successful
re-authentication, full access resumes; without it, the request is denied.¶
This binary model imposes disproportionate operational consequences for minor posture degradations. Consider a device that was fully patched at token issuance but is now one day behind on a non-critical software update. Under the binary model, the choices are:¶
Neither choice aligns with least-privilege principles. A graduated model would
permit a reduced set of operations — for example, read-only operations — while
requiring posture remediation or step-up authentication before write or
delete operations are permitted. [RFC9396] enables fine-grained initial
grants but provides no mechanism for post-issuance narrowing of
authorization_details in response to a runtime posture signal ([RFC9396]
§5.3).¶
OpenID CAEP [CAEP] provides the closest existing mechanism for continuous
access evaluation in the OAuth ecosystem. CAEP's Device Compliance Change
event signals a transition between compliant and not-compliant states.
However:¶
The combination of RFC 8705, RFC 9449, RFC 9470, RFC 9396, and CAEP does not close the APM gap because:¶
Per-request sender-constraining ([RFC8705], [RFC9449]): Proves key possession but does not evaluate device posture.¶
Fine-grained initial grants ([RFC9396]): Precise at issuance but static thereafter.¶
Reactive step-up ([RFC9470]): Binary, fires on authentication-level failures only, does not address device posture.¶
Asynchronous push events ([CAEP]): Not synchronous with individual requests, binary compliance vocabulary, no normative graduated outcomes.¶
None of these mechanisms defines: (a) the per-request triple of certificate, token, and device-posture signal as a unit of evaluation; (b) a normative comparison of that triple against the conditions recorded at issuance; or (c) a normative mapping from the result of that comparison to a graduated, least-privilege outcome. This gap is the subject of the APM requirements in Section 4.¶
This section specifies functional requirements for a solution to the APM problem domain. Requirements are expressed in abstract, non-implementation-specific language. These requirements describe what a solution SHOULD satisfy; they do not constitute a protocol specification. The key words are as defined in Section 2.¶
A compliant APM solution SHOULD satisfy the following requirements.¶
REQ-1: Per-Request Triple Assembly.
For each Privileged Request, the enforcing entity (resource server or PEP)
SHOULD assemble a Consistency View comprising (a) the client certificate
thumbprint or DPoP public key thumbprint presented with the request, (b) the
claims of the bound access token, including the cnf claim, and (c) an
integrity-protected device-posture signal supplied with or verifiably associated
with the request.¶
REQ-2: Issuance Posture Recording. At token issuance, the authorization server SHOULD record the security posture of the requesting client as the Issuance Posture. The Issuance Posture SHOULD be associated with the token either as a signed claim in the token itself or as metadata in a token-associated record accessible via token introspection ([RFC7662]). The Issuance Posture MUST NOT contain posture claims of higher sensitivity than the access token itself warrants.¶
REQ-3: Consistency Evaluation. The enforcing entity SHOULD evaluate the Consistency View against the Issuance Posture to determine whether posture degradation has occurred. This evaluation SHOULD be synchronous with the processing of the Privileged Request. The evaluation function SHOULD be deterministic: the same Consistency View and the same Issuance Posture SHOULD produce the same outcome classification.¶
REQ-4: Graduated Outcome Production. The enforcing entity SHOULD produce graduated outcomes ordered by the least- privilege principle. Outcome classes SHOULD include at minimum:¶
Permit: The Consistency View is consistent with the Issuance Posture; the request proceeds under the full authorization of the access token.¶
Scope Reduction: One or more posture attributes are degraded but the degradation does not warrant full denial; the request proceeds under a narrower effective scope.¶
Method Restriction: Posture degradation warrants restricting permitted HTTP methods or operation types; the request proceeds only if the requested method is within the restricted set.¶
Full Denial: Posture degradation is sufficiently severe that no operation is permitted; the request is denied with an error response that includes actionable guidance for the client.¶
REQ-5: Method-Level Restriction.
The graduated outcome framework SHOULD include Method Restriction as a distinct
outcome class. Method Restriction SHOULD be expressible in terms of both HTTP
methods and, where applicable, operation types expressed as actions in the
sense of [RFC9396] §2.2. A Method Restriction outcome MUST NOT prevent the
client from discovering which operations remain available; the response MUST
convey the permitted method set or operation set.¶
REQ-6: Scope Reduction. The graduated outcome framework SHOULD include Scope Reduction as a distinct outcome class. Scope Reduction MUST NOT be implemented by modifying the access token. Scope Reduction MUST be implemented at the resource server or PEP layer as an additional constraint applied during request processing. When a Scope Reduction outcome is produced, the response SHOULD convey the reduced effective scope to the client in a manner compatible with the client's ability to re-request operations within the reduced scope.¶
REQ-7: Deterministic Outcome Mapping. A deployment implementing APM SHOULD define a policy that maps posture degradation dimensions to outcome classes in a deterministic, auditable manner. The policy SHOULD be expressed such that the mapping from degradation to outcome is reproducible and does not depend on transient state beyond the Consistency View and Issuance Posture.¶
REQ-8: Integrity-Protected Posture Signal. The device-posture signal component of the Consistency View MUST be integrity- protected to prevent a compromised or malicious client from supplying a falsely elevated posture signal. Integrity protection SHOULD be cryptographic (e.g., a signed attestation). The signing authority for the posture signal SHOULD be distinct from the client itself; where only client-self-signed posture signals are available, the enforcing entity SHOULD apply additional skepticism to the resulting Consistency View evaluation.¶
REQ-9: Backward Compatibility with RFC 8705 and RFC 9449.
An APM mechanism SHOULD operate as an additive layer over existing sender-
constraining mechanisms. The APM mechanism MUST NOT weaken the cnf/x5t#S256
binding assurance provided by [RFC8705] or the cnf/jkt binding assurance
provided by [RFC9449]. Implementations that do not support APM MUST continue
to function correctly when encountering APM-related claims or response
parameters they do not recognize; unknown parameters MUST be ignored.¶
REQ-10: Non-Interference with Token Revocation. An APM mechanism that produces a Scope Reduction or Method Restriction outcome for a given request MUST NOT be interpreted as a token revocation event. Access token revocation is governed by [RFC7009]. A graduated APM outcome is request-scoped; the token itself remains valid for subsequent requests, which may yield different outcome classifications if posture is restored.¶
The APM mechanism operates at three points in the OAuth request lifecycle:¶
Token Issuance (Authorization Server): The AS records the Issuance Posture alongside the issued token.¶
Request Processing (Resource Server / PEP): For each Privileged Request, the RS or PEP assembles the Consistency View, evaluates it against the Issuance Posture, and determines the outcome class.¶
Outcome Conveyance (Resource Server / PEP to Client): The RS or PEP returns either a normal response (for Permit outcomes) or a structured error response (for Scope Reduction, Method Restriction, or Full Denial outcomes) that enables the client to understand its effective permission set and, if applicable, to take corrective action.¶
The Consistency View is assembled per-request at the enforcement boundary. Its three components are obtained as follows:¶
Certificate Component:
If the access token is certificate-bound per [RFC8705], the certificate
component is the SHA-256 thumbprint of the client certificate presented in
the current mutual-TLS handshake. The RS computes this thumbprint from the
certificate delivered by the TLS layer and compares it to the cnf/x5t#S256
claim in the token. This comparison is the existing [RFC8705] enforcement
step; APM does not replace or modify it.¶
If the access token is DPoP-bound per [RFC9449], the key component is the
SHA-256 thumbprint of the public key in the DPoP proof's jwk header
parameter, verified against cnf/jkt. APM does not replace or modify the
DPoP verification step.¶
Token Claims Component:
The token claims component comprises the access token's sub, scope (or
authorization_details), cnf, iss, aud, iat, and exp claims, plus
any posture-related claims defined by the Issuance Posture recording mechanism
(see Section 5.3).¶
Device-Posture Signal Component: The device-posture signal is an integrity-protected assertion supplied by or verifiably associated with the client for the current request. How the signal is conveyed to the enforcement boundary is deployment-specific. Candidate conveyance mechanisms include but are not limited to:¶
Regardless of conveyance mechanism, the posture signal MUST satisfy REQ-8 (integrity protection). The RS or PEP MUST verify the integrity protection before including the signal in the Consistency View. A posture signal that fails integrity verification MUST be treated as absent; the enforcing entity MUST NOT use an unverified posture signal as a basis for elevation above the Issuance Posture.¶
At token issuance, the AS records the security posture of the requesting client as the Issuance Posture. Two recording strategies are defined:¶
Strategy A — Token Claim:
The AS includes an apm_posture claim in the access token (JWT) or in the
token introspection response. The claim contains a compact, integrity-protected
representation of the posture attributes that were verified at issuance. The
exact structure of apm_posture is determined by the posture schema agreed
upon between the AS, the client, and the RS for the deployment.¶
Because the apm_posture claim is included in a token that may be presented
to third parties, implementations MUST consider the sensitivity of the posture
attributes included. Attributes that would enable re-identification or that
expose sensitive device configuration details MUST NOT be included in the token
claim form; they SHOULD be included only in the introspection-response form or
stored server-side.¶
Strategy B — Server-Side Metadata:
The AS stores the Issuance Posture server-side, associated with the token
identifier (jti). The RS retrieves the Issuance Posture by querying the token
introspection endpoint ([RFC7662]) or a dedicated APM metadata endpoint. This
strategy avoids embedding posture attributes in bearer tokens but introduces
a per-request network round-trip for posture retrieval.¶
The enforcing entity evaluates the Consistency View against the Issuance Posture using an evaluation function defined by deployment policy. The evaluation function MUST be deterministic (REQ-3) and MUST produce one of the outcome classes defined in REQ-4.¶
The evaluation proceeds in the following order:¶
Sender constraint verification: Verify that the certificate or key
thumbprint in the Consistency View matches the cnf claim in the token.
If this verification fails, the request MUST be denied with HTTP 401 and
invalid_token error, as per [RFC8705] or [RFC9449]. APM processing
does not proceed for requests that fail sender constraint verification.¶
Posture signal verification: Verify the integrity protection of the device-posture signal. If the signal is absent or integrity verification fails, the enforcing entity SHOULD treat the current posture as unknown. An unknown posture SHOULD be mapped to a degraded outcome class by policy.¶
Issuance Posture retrieval: Retrieve the Issuance Posture from the token claim or server-side metadata as appropriate for the deployment's recording strategy.¶
Degradation vector computation: For each posture attribute dimension covered by the Issuance Posture, determine whether the current value is equal to, better than, or worse than the issuance-time value. The set of dimensions that have degraded constitutes the degradation vector.¶
Outcome class determination: Map the degradation vector to an outcome class using the deployment's policy. The policy MUST be designed such that:¶
The four outcome classes are ordered by increasing restrictiveness: Permit < Scope Reduction < Method Restriction < Full Denial. A deployment policy MUST implement this ordering monotonically: if a degradation vector maps to Method Restriction, all more-severe degradation vectors MUST map to Method Restriction or Full Denial. No degradation vector may map to a less-restrictive outcome than a strictly less-severe degradation vector, given the same policy.¶
When the Consistency View is consistent with the Issuance Posture, the enforcing entity permits the request to proceed under the full authorization of the access token. No additional response headers or error codes are generated by APM processing.¶
When the evaluation produces a Scope Reduction outcome, the enforcing entity:¶
WWW-Authenticate header on 403 responses that
communicates both the reason and the currently effective scope.¶
The WWW-Authenticate response header for a Scope Reduction outcome SHOULD
take the following form:¶
WWW-Authenticate: Bearer error="apm_scope_reduced", error_description="Authorization posture degraded; effective scope narrowed", scope="<reduced-scope-string>"¶
Where <reduced-scope-string> is the space-delimited scope string representing
the effective scope under the Scope Reduction outcome. Clients receiving an
apm_scope_reduced error SHOULD NOT retry the denied operation without first
restoring posture. Clients MAY retry operations that fall within the reduced
scope.¶
When the evaluation produces a Method Restriction outcome, the enforcing entity:¶
authorization_details actions to HTTP methods) according
to the deployment's method-restriction policy.¶
WWW-Authenticate header that communicates
the permitted method set for requests that use a non-permitted method.¶
The WWW-Authenticate response header for a Method Restriction outcome SHOULD
take the following form:¶
WWW-Authenticate: Bearer error="apm_method_restricted", error_description="Authorization posture degraded; method not permitted", allowed_methods="GET HEAD"¶
Where allowed_methods is a space-delimited list of currently permitted HTTP
methods. Clients receiving an apm_method_restricted error SHOULD inspect the
allowed_methods value and, if the required operation is unavailable, SHOULD
initiate posture remediation or re-authorization rather than retrying the
denied method.¶
When the evaluation produces a Full Denial outcome, the enforcing entity
responds with HTTP 401 and a WWW-Authenticate challenge. Full Denial
challenges SHOULD use the insufficient_authorization_posture error code
(see Section 8.2) rather than the generic invalid_token, to enable
the client to distinguish a posture-triggered denial from a token validity
failure. Clients receiving a Full Denial outcome SHOULD initiate posture
remediation and re-authorization.¶
The WWW-Authenticate response header for a Full Denial outcome SHOULD take
the following form:¶
WWW-Authenticate: Bearer error="insufficient_authorization_posture", error_description="Authorization posture degraded below minimum threshold"¶
The following diagram illustrates the APM flow for a Privileged Request that results in a Method Restriction outcome. Steps 1-4 are the existing OAuth sender-constraint flow (unchanged); steps 5-9 are the additional APM steps.¶
Client Resource Server (RS / PEP) Authorization Server (AS) | | | | (1) Token Request | | (with posture signal) | |---------------------------------------------------->| | | | | (2) Issuance Posture | | | recorded server-side | | | [AS internal] | | | | (3) Access Token | | |<----------------------------------------------------| | | | | (4) Privileged | | | Request | | | Authorization: | | | DPoP <token> | | | DPoP: <proof> | | | APM-Posture: <signal> | | |----------------------->| | | | | | | (5) Verify sender | | | constraint (RFC 8705 | | | / RFC 9449) | | |---+ | | | | verify cnf/jkt vs | | | | DPoP jwk thumbprint | | |<--+ | | | | | | (6) Retrieve Issuance | | | Posture (token claim or | | | introspection query) | | |---+ [or via introspect] | | | |<--------------------> | | |<--+ | | | | | | (7) Assemble Consistency | | | View: verify posture | | | signal integrity; | | | compute degradation vector | | |---+ | | |<--+ | | | | | | (8) Apply policy: | | | degradation vector -> | | | Method Restriction outcome | | |---+ | | |<--+ | | | | | (9) HTTP 403 | | | WWW-Authenticate: | | | error="apm_method_ | | | restricted" | | | allowed_methods="GET" | | |<-----------------------| | | | | | (10) Client inspects | | | WWW-Authenticate; | | | retries with GET or | | | initiates posture | | | remediation | | |---+ | | |<--+ | |
When recording Issuance Posture as a token claim (Strategy A from
Section 5.3), the claim name is apm_posture. The claim value is
a JSON object. The schema of the apm_posture object is deployment-defined;
this document specifies the following registered sub-fields:¶
posture_at:posture_hash:posture_alg sub-field.¶
posture_alg:posture_hash is present) A string identifying the
algorithm used to compute posture_hash. Values follow the JOSE JWA registry
([RFC7518]). Implementations SHOULD use S256 (SHA-256).¶
posture_ref:posture_ref requires that the RS
or PEP have the ability to dereference the URI.¶
Example apm_posture claim embedded in a JWT access token:¶
{
"iss": "https://as.example.com",
"sub": "user@example.com",
"aud": "https://rs.example.com",
"exp": 1800000000,
"iat": 1799996400,
"jti": "aB3xQ9pR",
"cnf": {
"jkt": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs"
},
"scope": "records:read records:write",
"apm_posture": {
"posture_at": 1799996400,
"posture_hash": "Y2Fj...base64url-truncated",
"posture_alg": "S256",
"posture_ref": "https://as.example.com/posture/aB3xQ9pR"
}
}
When conveying the device-posture signal as an HTTP request header, the header
name is APM-Posture. The value is a compact-serialized signed JWT (a JWS in
compact serialization per [RFC7519]) whose payload contains the posture
attributes as of the time of the request.¶
The APM-Posture JWT MUST include the following claims:¶
iat:iat is more than a deployment-defined
freshness window in the past. A freshness window of 60 seconds is RECOMMENDED
for most deployments; lower values SHOULD be used for high-sensitivity
resources.¶
jti:jti values to
detect replayed posture assertions.¶
sub:sub
claim of the bound access token.¶
ath:ath
claim in [RFC9449] §4.2. This binds the posture assertion to the specific
token presented in the same request.¶
Additional posture-specific claims are deployment-defined. The signing key for the APM-Posture JWT SHOULD be a key controlled by a posture attestation service that is distinct from the client itself, to satisfy REQ-8.¶
Example APM-Posture JWT payload:¶
{
"iat": 1799996400,
"jti": "posture-X7pQ2w",
"sub": "user@example.com",
"ath": "fUHyO2r8tx45IsZggRC...base64url-truncated"
}
HTTP/1.1 403 Forbidden WWW-Authenticate: Bearer realm="example", error="apm_scope_reduced", error_description="Authorization posture degraded; effective scope reduced", scope="records:read"
The scope parameter in the WWW-Authenticate header reflects the reduced
effective scope. The client MAY retry the request using only the operations
within the indicated scope. The client SHOULD NOT retry the denied operation
until posture is remediated and a new access token is issued under the full
scope.¶
HTTP/1.1 403 Forbidden WWW-Authenticate: Bearer realm="example", error="apm_method_restricted", error_description="Authorization posture degraded; method not permitted", allowed_methods="GET HEAD OPTIONS"
The allowed_methods parameter lists the HTTP methods the RS will process for
this client under the current degraded posture. Methods not in allowed_methods
will be rejected with the same apm_method_restricted error.¶
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example", error="insufficient_authorization_posture", error_description="Authorization posture degraded below minimum threshold"
Clients receiving this response MUST initiate posture remediation before retrying. Clients SHOULD surface a user-facing notification indicating that access has been suspended due to a security posture issue.¶
An APM Full Denial response and an RFC 9470 step-up challenge address different conditions and MUST NOT be conflated:¶
insufficient_user_authentication challenge means the
authentication event associated with the token does not meet the RS's
requirements. The remedy is re-authentication.¶
insufficient_authorization_posture challenge means the device
security posture associated with the token does not meet the RS's requirements.
The remedy is posture remediation followed by re-authorization.¶
A resource server MAY issue both challenges simultaneously. Per RFC 9110
§11.6.1, a single response MAY include multiple WWW-Authenticate header
fields, each carrying one challenge, when both conditions are present:¶
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example", error="insufficient_user_authentication", acr_values="urn:mace:incommon:iap:silver", max_age=300 WWW-Authenticate: Bearer realm="example", error="insufficient_authorization_posture", error_description="Device posture below minimum threshold"
Clients MUST resolve both challenges before retrying a request that produced both errors. The order in which challenges are resolved is client-defined, but both MUST be resolved before a new request is made to the protected resource.¶
When a Scope Reduction or Method Restriction outcome is produced, the client continues to hold a valid access token that nominally authorizes a broader set of operations. If the client uses this token to perform operations within the reduced effective scope at a resource server that does not implement APM, those operations will succeed against the nominal token scope, without the posture evaluation that an APM-aware resource server would apply.¶
Implementations MUST NOT assume that APM enforcement is applied uniformly across
all resource servers that accept the same token. Token issuance should scope
tokens to the specific resource server audience (aud) that implements APM
enforcement for the protected resources in question. Token issuance for
multiple-audience tokens in APM deployments SHOULD be approached with caution.¶
Clients that receive a Scope Reduction or Method Restriction error from an APM- aware resource server SHOULD NOT use the same access token to perform the restricted operations against a different, potentially non-APM-aware resource server that shares the same audience.¶
The device-posture signal is integrity-protected but may be replayed by an attacker who captures a previously valid signal. Replaying a posture signal generated at a time when the device was in a higher-compliance state allows the attacker to present an artificially elevated Consistency View.¶
Mitigations:¶
jti claim. Resource servers
and PEPs MUST maintain a short-term cache of seen jti values and MUST
reject posture assertions with jti values seen within the freshness window.¶
iat claim. Resource servers and PEPs
MUST reject posture assertions whose iat is more than the freshness window
in the past.¶
ath claim binding the posture assertion
to the specific access token of the current request. A posture assertion
generated for one token MUST NOT be accepted when a different token is
presented.¶
An attacker with the ability to manipulate the device-posture signal in transit — or to prevent the device-posture signal from reaching the resource server — may attempt to force a lower-posture Consistency View than the actual device state. The intent may be to cause a Method Restriction or Full Denial outcome that disrupts service (a denial-of-service variant), or to cause the client to reveal information about which resources require what posture levels (a reconnaissance variant).¶
Mitigations:¶
Per-request posture evaluation introduces observable timing and response differences between requests that pass and requests that fail. An attacker who can make multiple requests and observe the response codes and timing may be able to infer information about the target system's posture policy — for example, which degradation dimensions trigger which outcome classes.¶
Implementations SHOULD take care that:¶
error_description field SHOULD be informative but SHOULD NOT
enumerate the specific posture attributes that caused the outcome.¶
When Strategy B (server-side Issuance Posture metadata) is used, the resource server queries the authorization server's token introspection endpoint ([RFC7662]) to retrieve the Issuance Posture per-request. This introduces a network dependency that is not present in the token-claim strategy.¶
Implementations using the introspection strategy MUST:¶
APM processing MUST NOT weaken the sender-constraint binding provided by [RFC8705] or [RFC9449]. Specifically:¶
cnf claim in the access token is not modified by APM processing; it
retains its original value for all subsequent verification steps.¶
The security of the APM mechanism depends on the trustworthiness of the posture signal. Deployments MUST establish a trust anchor for posture signal signing keys that is independent of the client. Possible trust anchors include:¶
Where no independent trust anchor is available and the client must self-sign posture assertions, the enforcing entity SHOULD apply a lower level of trust to the resulting Consistency View and SHOULD map unknown or client-self-signed posture signals to a more restrictive outcome class.¶
This document requests registration of the following entries in the OAuth Parameters Registry established by [RFC6749] and maintained by IANA.¶
apm_posture¶
This document requests registration of the following error codes in the OAuth Extensions Error Registry per [RFC6749] Appendix A.7:¶
apm_scope_reduced¶
scope parameter in the WWW-Authenticate
header conveys the reduced effective scope.¶
apm_method_restricted¶
allowed_methods parameter in the WWW-Authenticate header conveys the set
of currently permitted methods.¶
insufficient_authorization_posture¶
This document requests registration of the following entries in the JSON Web Token Claims Registry established by [RFC7519] §10.1:¶
apm_posture¶
The IANA Private Enterprise Number (PEN) arc 1.3.6.1.4.1.65953 is allocated
to Sanctum SecOps LLC. Extensions, OIDs, or experimental identifiers under this
arc are for experimental and private use only. Any identifiers under this arc
MUST NOT be used in IETF-standardized protocols in place of IANA-registered
identifiers. Permanent IANA assignments for APM-related identifiers are
requested via the procedures described in this section; TBD placeholders will be
resolved during IETF processing.¶
The author thanks the members of the IETF OAuth Working Group for their work on the specifications analyzed in this document. The analysis of gap areas builds on the normative text of RFC 8705, RFC 9449, RFC 9470, RFC 9396, and the OpenID CAEP specification, and the author acknowledges the authors of those documents for their foundational contributions.¶
The following table summarizes the coverage of APM requirements by existing specifications. The symbol "Y" indicates the requirement is addressed normatively; "P" indicates partial coverage with identified gaps; "N" indicates the requirement is not addressed.¶
Requirement | RFC | RFC | RFC | RFC | RFC | CAEP | Attest
| 6749 | 8705 | 9449 | 9470 | 9396 | | Draft
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-1 Triple | | | | | | |
Assembly | N | P | P | N | N | N | P
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-2 Issuance | | | | | | |
Posture Recording | N | N | N | N | N | N | P
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-3 Consistency | | | | | | |
Evaluation | N | N | N | N | N | N | N
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-4 Graduated | | | | | | |
Outcomes | N | N | N | N | N | N | N
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-5 Method | | | | | | |
Restriction | N | N | N | N | P | N | N
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-6 Scope | | | | | | |
Reduction | N | N | N | N | P | N | N
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-7 Deterministic | | | | | | |
Outcome Mapping | N | N | N | N | N | N | N
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-8 Integrity- | | | | | | |
Protected Signal | N | N | N | N | N | P | Y
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-9 Backward | | | | | | |
Compatible | - | - | - | - | - | - | -
--------------------+-------+-------+-------+-------+-------+-------+-------
REQ-10 Non- | | | | | | |
Revocation | - | - | - | - | - | - | -
Y = addressed normatively
P = partially addressed with identified gaps
N = not addressed
- = not applicable (requirement specifies APM behavior, not existing spec scope)
NIST SP 800-207 [NIST.SP.800-207] defines a three-component decision plane consisting of the Policy Engine (PE), Policy Administrator (PA), and Policy Enforcement Point (PEP). APM maps to this architecture as follows:¶
The Policy Enforcement Point is the resource server or a co-located enforcement component. The PEP assembles the Consistency View (REQ-1), applies sender-constraint verification, and enforces the graduated outcome produced by policy evaluation.¶
The Policy Engine consumes the Consistency View and the Issuance Posture and produces an outcome class. The PE function may be co-located with the PEP or may be a distinct service queried per-request. The PE is responsible for the deterministic outcome mapping required by REQ-7.¶
The Policy Administrator communicates policy configuration from the authorization server to the PEP — for example, conveying the scope-reduction policy and the method-restriction policy that the PEP applies when evaluating Consistency Views. The PA may also be responsible for recording the Issuance Posture at token issuance time (REQ-2).¶
This mapping illustrates that APM does not introduce new architectural roles beyond those already defined in [NIST.SP.800-207]; rather, it specifies the information flows — specifically, the Consistency View and Issuance Posture — that are needed to enable the PE to make the per-request graduated-outcome decisions that ZTA requires.¶
Transaction Tokens [I-D.ietf-oauth-transaction-tokens] address a related but distinct problem: propagating user identity and authorization context across workloads within a trusted domain during processing of a single external request. Transaction Tokens are scoped to intra-domain service-mesh use cases and explicitly MUST NOT include the access token they were derived from.¶
APM addresses the boundary between the external client and the resource server — the initial protected-resource access, not the subsequent intra-domain hops. The two mechanisms are complementary: an RS that receives an APM-evaluated request may subsequently issue Transaction Tokens for intra-domain workload propagation. The graduated outcome produced at the APM boundary informs the scope of the Transaction Token(s) issued downstream.¶
Specifically, if the APM evaluation produces a Scope Reduction outcome (e.g.,
reducing effective scope from records:read records:write to records:read),
a Transaction Token Service that derives a Txn-Token from the external access
token MUST honor the APM reduced scope and MUST NOT issue a Txn-Token whose
scope claim exceeds the APM-reduced effective scope.¶