]> Sanctum SecOps LLC

brian@sanctumsecops.io

Security OAUTH oauth mtls device posture continuous access zero trust authorization This document describes the Authorization Posture Mechanism (APM), a method by which an OAuth 2.0 authorization server, or a resource server acting on its behalf, re-evaluates the mutual consistency of three bound factors -- the client certificate, the access token, and the device posture -- on a per-request basis for privileged operations, rather than only at session establishment. When re-evaluated posture degrades relative to the posture under which the token was issued, APM defines deterministic, least-privilege Graduated Outcomes including scope reduction and method restriction, rather than a binary allow or deny.

Introduction OAuth 2.0 and related mechanisms bind tokens to a client at issuance time. Certificate-bound access tokens and Demonstrating Proof of Possession (DPoP) strengthen the binding between a token and a key. Step-up authentication allows a resource server to demand stronger authentication for specific requests. These mechanisms are predominantly evaluated per session or per challenge. Continuous Access Evaluation propagates security-event signals between providers but does not, by itself, define a per-request consistency computation across certificate, token, and posture at the point of enforcement. APM addresses a complementary problem: at the granularity of an individual privileged request, re-computing whether the presented certificate, the presented token, and the current device posture remain mutually consistent with the posture under which the token was issued, and defining what happens when they do not. defines attestation-based client authentication but explicitly leaves device-attestation details out of scope and operates at authentication time. APM occupies the intersection: an issuance-time-anchored, per-request consistency check with deterministic graduated outcomes. APM graduates the authorization policy rather than applying a binary permit or deny: when posture degrades, the mechanism reduces to the most permissive authorization the current posture supports. The specific decision function that maps a degradation to an outcome class is implementation-defined and out of scope of this document; see the Applicability section of the corresponding Sanctum SecOps publication.

Requirements This section specifies functional requirements for an APM solution. Requirements describe what a conforming mechanism SHOULD satisfy; they do not constitute a protocol specification.

REQ-1:

For each Privileged Request, the enforcing entity SHOULD assemble a Consistency View comprising (a) the client certificate or DPoP key thumbprint, (b) the bound access token's claims including cnf, and (c) an integrity-protected device-posture signal associated with the request.

REQ-2:

At token issuance, the authorization server SHOULD record the security posture of the requesting client as the Issuance Posture, associated with the token either as a signed claim or as server-side metadata accessible via token introspection .

REQ-3:

The enforcing entity SHOULD evaluate the Consistency View against the Issuance Posture synchronously with processing of the Privileged Request. The evaluation function SHOULD be deterministic: identical inputs MUST produce the same outcome classification.

REQ-4:

The enforcing entity SHOULD produce Graduated Outcomes ordered by the least-privilege principle: Permit, Scope Reduction, Method Restriction, and Full Denial, applied proportionally to the degree of degradation.

REQ-5:

Method Restriction SHOULD be a distinct outcome class, expressible in terms of HTTP methods or RAR actions per §2.2. The response MUST convey the permitted method or operation set.

REQ-6:

Scope Reduction MUST NOT be implemented by modifying the access token. It MUST be applied by the resource server or APM Enforcement Point as an additional constraint during request processing.

REQ-7:

A deployment SHOULD define a policy that maps posture degradation dimensions to outcome classes in a deterministic, auditable manner independent of transient state beyond the Consistency View and Issuance Posture.

REQ-8:

The device-posture signal MUST be integrity-protected. Integrity protection SHOULD be cryptographic. The signing authority SHOULD be distinct from the client itself.

REQ-9:

An APM mechanism MUST operate as an additive layer over existing sender-constraining mechanisms. It MUST NOT weaken the cnf/x5t#S256 binding of or the cnf/jkt binding of . Implementations that do not recognize APM parameters MUST ignore them.

REQ-10:

A Scope Reduction or Method Restriction outcome MUST NOT be interpreted as a token revocation event. The token remains valid for subsequent requests, which may yield different outcome classifications if posture is restored.

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 throughout this document:

Consistency View:

the tuple of (client certificate, access token and its bound claims, current device-posture signal) assembled for a single privileged request.

Issuance Posture:

the device-posture state recorded at the time the access token was issued.

Posture Degradation:

a determination that the current device-posture signal is materially weaker than the Issuance Posture.

Graduated Outcome:

one of a defined set of deterministic, least-privilege responses to a detected Posture Degradation: scope_reduction, method_restriction, or full_denial.

APM Enforcement Point:

an authorization server or resource server that implements the consistency-view evaluation described in this document.

Mechanism Overview For each privileged request, an APM Enforcement Point executes the following five-step state machine:

FULL_DENIAL v +----------+-----------+ | Step 3: DPoP Key | | Binding Check | +----------+-----------+ | | PASS FAIL -----> FULL_DENIAL v +----------+-----------+ | Step 4: Posture vs. | | Issuance Posture | +----------+-----------+ | | CONSISTENT DEGRADED | | v v 200 OK Step 5: Dispatch Graduated Outcome (scope_red | method_rest | full_deny) ]]>

An endpoint determines which requests are "privileged" by local policy. APM is a defense-in-depth control expected to be applied to a subset of high-value operations. Applying APM to every request increases the side-channel surface described in . When Posture Degradation is detected, an APM Enforcement Point applies one of the following Graduated Outcome classes, ordered from least restrictive to most restrictive: scope_reduction: narrowing the effective authorization per ; method_restriction: limiting the permitted HTTP method; full_denial: refusing the request. Policy authors MUST design graduated outcomes so that every downgrade path leads to a safe, self-consistent authorization state. Each Graduated Outcome MUST correspond to a complete access control policy, not a partial policy derived by removing permissions from the full policy. The pseudocode below specifies the normative evaluation procedure:

Implementations MUST NOT cache introspection responses for tokens where APM is active, or MUST use a freshness window for cached responses shorter than the expected posture-change window.

Wire Format

authorization_details Object APM outcomes MUST be conveyed as typed authorization_details objects per . The type value for APM Graduated Outcomes is:

The following JSON Schema defines the APM outcome object:

", "original_scope": "", "effective_scope": "", "permitted_methods": [""], "reason_code": "", "apm_decision_id": "" } ]]>

Field semantics:

The reason_code field MUST NOT include decision-function parameters, scoring weights, thresholds, or posture metric values. Acceptable enumerated codes include POSTURE_DEGRADED, ATTESTATION_CLASS_CHANGED, and CERT_THUMBPRINT_MISMATCH.

WWW-Authenticate Challenge When a Graduated Outcome is accompanied by an invitation to re-authenticate (step-up per ), the resource server SHOULD return a WWW-Authenticate challenge: For Bearer-bound tokens:

", scope="" ]]>

For DPoP-bound tokens:

" ]]>

HTTP Status Mapping

Posture-Signal Abstraction APM treats the posture signal as an opaque, integrity-protected input. The specific attestation format, measurement protocol, and trust chain for the posture signal are outside the scope of this document. An APM Enforcement Point MUST require that: (1) the posture signal is integrity-protected (signed or MAC'd by a trusted posture authority); (2) the posture signal includes an iat (issued-at) claim for freshness evaluation; (3) the posture signal includes a subject identifier binding it to the device or client instance; (4) the posture signal SHOULD include a unique identifier (jti) for replay detection. While not mandating a specific format, this document recommends the following JWT shape for implementations requiring an interoperable baseline:

This schema MUST NOT include scoring weights, risk-band thresholds, or decision budgets. The fields above expose only the observable posture properties. The attestation_class field is an implementation-defined string (e.g., hardware_tpm, software_tee, none); ordering and thresholds are implementation-defined and out of scope.

Interaction Matrix The following table describes how APM relates to each relevant protocol:

The RECOMMENDED layering for deployments that combine all mechanisms is: Layer A (token validity) per ; Layer B-core (cert binding) per ; Layer C (DPoP) per where applicable; Layer D (APM consistency) per this document.

Relationship to Prior Art The following table enumerates gaps in existing mechanisms and how APM addresses each.

Security Considerations APM is a defense-in-depth mechanism and MUST NOT weaken any binding defined by or . The posture signal is an input to an authorization decision and MUST be integrity-protected; an APM Enforcement Point MUST NOT base a Graduated Outcome on an unauthenticated posture signal. Specific tuning parameters used by implementations of this mechanism are out of scope of this document; see the Applicability section of the corresponding Sanctum SecOps publication.

Replay of Stale Posture Signals A posture signal valid at token-issuance time may be captured and replayed by an adversary to make the resource server believe posture has not degraded. Mitigations: (1) the posture signal MUST include an iat claim; the APM Enforcement Point SHOULD reject signals with an iat older than an implementation-defined freshness window; (2) the resource server MAY include a server-generated nonce in a challenge, providing challenge- response-based replay protection; (3) if the posture signal is bound to the access token via the same DPoP key , replaying it under a different token requires breaking the binding. The formal model for replay resistance in authenticated protocols is established in .

Downgrade-Forcing Attacks An adversary who can manipulate the posture-signal channel can inject a degraded posture signal to obtain a downgraded token -- for example, obtaining a scoped-down token that avoids audit scrutiny, or triggering a method_restriction outcome that permits read access without the write- access audit trail. Mitigations: (1) the posture signal MUST be integrity- protected; (2) policy authors SHOULD design graduated outcomes so that every downgrade path leads to a safe, self-consistent authorization state; an operation that is only safe at full authorization SHOULD map to full_denial rather than scope_reduction when posture degrades.

Confused-Deputy Under Graduated Downgrade The confused-deputy problem arises in APM when a partially-authorized (downgraded) request is processed by a resource server that believes it is acting on behalf of a fully-authorized principal. Each Graduated Outcome MUST correspond to a complete access control policy, not a partial policy derived by removing permissions from the full policy. Policy authors MUST audit every graduated outcome in isolation, not only relative to the full-authorization policy.

Side-Channel Leakage of Device State Because APM re-evaluates posture on every privileged request, the resource server observes the posture signal at high frequency. Implementations MUST NOT return different response codes or timing based solely on posture quality in a way that leaks posture details not already visible from the authorization outcome. APM SHOULD be applied only to operations designated as privileged. The principle that authenticated key exchange security requires binding identities to session keys via signatures and MACs together () is analogous to APM's multi-factor consistency check; the same binding-integrity properties SHOULD be maintained throughout the APM enforcement path. The remaining threat considerations (compromise of the posture-signal channel, DPoP and mTLS binding compromise, CAEP signal injection) are addressed by the posture-signal integrity requirements in , the trusted-issuer allowlist requirement for CAEP inputs in , and the independence requirement that the posture signal used by APM SHOULD be a direct attestation from the device itself, not solely derived from CAEP events.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting, as required by . Organization: Sanctum SecOps LLC Description: An experimental Go implementation of the APM Consistency View assembly and graduated-outcome dispatch, covering the certificate-thumbprint check (Step 2), DPoP-key-binding check (Step 3), and graduated-outcome application for all three outcome classes defined in . The wire format encoding of authorization_details per and the WWW-Authenticate challenge format per are implemented. Located at poc/apm/ in the companion repository at https://github.com/Sanc-Admin/sanctum-ietf (private until counsel hand-off). Coverage: Consistency View assembly and all five steps of the algorithm in , wire-format encoding of APM outcome objects, and HTTP status code mapping per . Maturity: Experimental reference implementation. This implementation is provided for early interoperability testing only and MUST NOT be deployed in production or used for security-critical operations without review by qualified security and legal counsel.

IANA Considerations

authorization_details Type Registration IANA is requested to register the following authorization_details type in the OAuth Authorization Details Types registry established by :

The value TBD2 is a placeholder to be assigned upon RFC publication. For early interoperability, implementations MAY use the type string urn:apm:graduated-outcome:v1 directly; this string is stable and does not depend on the IANA OID arc. The publicly registered Sanctum SecOps PEN (1.3.6.1.4.1.65953) is used for any experimental OID-based identifiers and MUST NOT be relied upon as a permanent registration.

References

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. 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] 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. 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 describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. MATTR Bundesdruckerei SPRIND This specification defines an extension to the OAuth 2.0 protocol [RFC6749] that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. National Institute of Standards and Technology

Worked Example: Compliance Downgrade -- scope_reduction Outcome All JWT and certificate thumbprints are synthetic. No real credentials are used. Context: Device compliance has dropped (MDM reports a policy violation). Current posture has device_compliance = non_compliant while the Issuance Posture had compliant. Current posture signal JWT payload (synthetic):

APM Consistency View evaluation:

scope_reduction effective_scope = "read" (admin and write removed) ]]>

Response (resource requires write scope, not in effective_scope):

The client MUST obtain a new token after re-establishing device posture at the required compliance level before accessing write-scoped resources.

Appendix B. Mapping to NIST SP 800-207 Zero Trust Architecture NIST SP 800-207 defines a three-component decision plane for Zero Trust Architecture. APM maps to this architecture as follows:

APM does not introduce new architectural roles beyond those defined in . It specifies the information flows -- specifically, the Consistency View and Issuance Posture -- that enable the PE to make the per-request graduated-outcome decisions that ZTA requires. Informative reference: .

Acknowledgments The author thanks the OAuth Working Group for the certificate-binding, proof-of-possession, and step-up foundations on which this mechanism builds.