NIST SP 800-162 — Guide to Attribute Based Access Control (ABAC)

Source: NIST CSRC publication record · PDF (NVL Pubs). Published January 2014; reaffirmed August 2019.

What this is

NIST SP 800-162 is the vendor-neutral, currently-active codification of the four-role ABAC architecture — the PEP / PDP / PIP / PAP split — generalized from XACML 3.0 into a policy-language-agnostic NIST publication. It is the wiki’s preferred citation when an absence claim or architectural argument needs a living anchor for the four-role vocabulary; OASIS XACML 3.0 (2013, dormant) is the historical lineage.

The publication’s role split (§2.2) is identical to XACML’s:

Functional point	Role	NIST SP 800-162 reference
PEP — Policy Enforcement Point	Intercepts the request, asks the PDP, applies the result	§2.2
PDP — Policy Decision Point	Evaluates policy against attributes; returns allow / deny	§2.2
PIP — Policy Information Point	Provides attributes the PDP needs (subject, resource, environment)	§2.2
PAP — Policy Administration Point	Manages the policy lifecycle	§2.2

What NIST adds beyond XACML: deployment considerations (§2.3, §3) for federated environments, NHI / service-account handling, attribute-source trust modeling, and operational lifecycle guidance — material useful for the wiki’s CMM D2 (Identity) and D3 (Control & Least-Agency) evidence.

Why this is the wiki’s preferred role-vocabulary citation

Three reasons NIST SP 800-162 is the right anchor for any “PEP / PDP / PIP / PAP” claim, in preference to XACML:

1. Living standard. Reaffirmed by NIST in August 2019; published by an active U.S. federal standards body; cited in current security-architecture and Zero Trust work. XACML 3.0 is dormant (no major revision since 2013, errata since 2017). Per the Standards Validation Methodology, absence claims should anchor on living standards where possible.
2. Policy-language agnostic. NIST SP 800-162 specifies the role decomposition without requiring XACML’s XML syntax. This matters because modern PDP implementations (Cedar, OPA, capability-token engines) replace the language but preserve the architecture — NIST 800-162 is the standard that names what they all share.
3. Bridge to Zero Trust. NIST SP 800-207 (Zero Trust Architecture, 2020) builds on the same role logic with a slightly different vocabulary (Policy Engine + Policy Administrator + Policy Enforcement Point). Citing 800-162 places the wiki on the standards continuum 800-162 → 800-207 → modern zero-trust deployments.

Relationship to XACML, Cedar, OPA, capability tokens

Artifact	Layer	Relationship to NIST SP 800-162
OASIS XACML 3.0	Policy-language + role-architecture	Predecessor that NIST SP 800-162 generalizes. Wiki cites XACML for historical lineage; cites 800-162 for current authoritative role vocabulary.
Cedar	Policy language + engine (PDP role)	Modern PDP implementation that fits inside the SP 800-162 architecture. Cedar does not redefine the four roles; it occupies the PDP slot.
Rego	Policy language + engine (PDP role)	Same as Cedar — a PDP implementation, not a redefinition of the role architecture.
Capability tokens (Tenuo Warrants, Macaroons, UCAN, Biscuits)	Alternative authorization model	Different paradigm: policy is bound into the credential, evaluated implicitly when presented. Reduces PDP-call frequency at the cost of needing strong attenuation and revocation primitives. NIST SP 800-162 §3 acknowledges capability-style alternatives at the deployment-considerations level.

In the wiki

• XACML — historical lineage; the role vocabulary itself comes from XACML 3.0 even though the active standards anchor is 800-162
• Oversight Layer — wiki’s architectural primary term; PDP/PEP/PIP/PAP roles inherited from this lineage
• Reference Architecture — six planes annotated with the four roles
• CMM — nine domains colored with the four-role palette; CMM D2 + D3 evidence requirements draw on SP 800-162 §3 deployment considerations
• Standards Validation Methodology — recommends preferring SP 800-162 §2.2 over the OASIS XACML spec for any role-vocabulary citation

Status

adoption_signal: maintained — the publication has been reaffirmed (2019) and remains the canonical NIST reference for ABAC, but no major revision is in flight. The vocabulary is stable; no active drift to track.

Not in this wiki summary

SP 800-162 §3 (Considerations) is partially covered above for deployment / lifecycle guidance; the full §3 includes federation, interoperability, and audit considerations not yet pulled into wiki claims. If a future absence claim invokes 800-162 §3 specifically, expand the scope_in_wiki: field and the corresponding wiki summary before relying on it.