An attribute is a named piece of information about an entity that can influence an authorization decision. Attributes may describe a principal, resource, action, or environment: a user’s department or clearance, a report’s classification or owner, a request’s action type, or the current time and network risk. In attribute-based access control (ABAC), policies evaluate these values at request time rather than granting everyone in a role identical access. section 6.2 section 6.2.3
Useful attribute categories include:
- Principal attributes identify relevant facts about a requester, such as department, clearance, employer, certification status, or group membership. section 6.2 section 16.6
- Resource attributes describe the protected item, such as classification, owner, owner department, type, region, or sensitivity level. section 6.2 section 8.1.2
- Environmental and request attributes capture changing context, including time, network risk, device posture, geolocation, and requested action. section 6.2 section 9.2.3
- Relationship data can also supply authorization inputs, such as document owner, editor, viewer, organization membership, or parent-folder hierarchy. section 1.4.2
A finance report request
A policy can permit a financial-report request only when the requester belongs to the owner’s department, has high clearance, and requests access before 6 p.m. Alice is allowed because her current attributes satisfy every condition; Bob is denied because his clearance is low. The policy remains static, while attribute values from identity, resource, and environmental systems change per request. section 6.2.1
Figure 6.4 Attribute-based authorization with principal, resource, and environment attributes. Access decisions are based on evaluating policies in the context of attributes from multiple sources. Alice’s attributes meet the policy conditions, so access is granted. Bob’s do not, so access is denied.
Compare principal, resource, and environmental attributes in one decision: Alice’s values meet the policy conditions, while Bob’s do not. section 6.2
Attribute quality is a security boundary. A correct policy can still produce unsafe access if clearance, employment status, device state, or other inputs are spoofed or stale. Critical attributes should be proofed when established or changed, checked against an up-to-date source of truth where possible, and supported by account lifecycle, revocation, and audit controls. Long-lived credentials can preserve outdated attributes and lead to unauthorized access. section 2.6.3 section 6.2.3
Policies gain flexibility by combining attributes from multiple systems, but that flexibility creates operational work: schemas need clear names and types, complex facts should not be packed into fragile strings, and request-time context must be modeled deliberately. Centralized policy evaluation can keep rules reusable and auditable, while teams layer organization-wide constraints with domain-specific conditions. section 9.2.3 section 6.2.4
Attributes can originate in verifiable credentials as well as internal systems. After a policy enforcement point verifies a credential presentation, it normalizes selected claims into an internal attribute schema for the policy decision point. Policies then use employer, certification, or project-role attributes without depending on how the credential was presented. section 16.2 section 16.6
