A namespace is a naming context: it gives an identifier meaning by defining where it is unique. A username, employee number, email address, or database table name can identify something only within the context that governs it. In digital identity, that context lets systems recognize and remember the parties in a relationship. section 2.4.1
Namespaces are security-relevant infrastructure, not merely labels. Authorization policies need identifiers that are stable, unambiguous, discoverable, and trustworthy. If employees, contractors, customers, and service accounts share an identifier format without clear boundaries, a sound policy can still govern the wrong entity. section 2.4.3 section 2.9
Namespace designs address collisions and administration in different ways:
- Centralized namespaces assign unique names through one organization, as with usernames or employee IDs. They are straightforward to implement, but depend on the authority maintaining names correctly and avoiding reuse. section 2.4.3
- Hierarchical namespaces structure names beneath a root, enabling discovery and local control without collisions. DNS, X.509 certificates, and LDAP are examples. section 2.4.3
Separate domains before writing policy
An organization may have both a furniture inventory service and a general-purpose database, each with a Table type. Furniture::Table and Database::Table state which domain the type belongs to, preventing a conflict when policies are combined. Similarly, PhotoApp::User and BillingApp::User are distinct entity types rather than interchangeable users. section 4.3.2 section 7.4.3
In access policy, a namespace is a prefix that organizes entities and actions and identifies the domain or system to which they belong. It clarifies policy scope alongside principals, resources, actions, roles, groups, and attributes. Clear boundaries also support governance: an identifier or entitlement should remain traceable to the authority and domain that issued it. section 4.3.2 section 2.9
Namespaces as a type-safety boundary
Cedar places namespaces before the :: delimiter, such as Finance::Document and CustomerCollab::Employee. Types are unqualified inside their own namespace but must be fully qualified across namespaces. This prevents comparing an Employee with a Document, applying an IP check to a timestamp, or using resource.owner where that attribute does not exist; such mistakes produce a type error before deployment. section 7.4.3
Figure 4.1 Relationships among key authorization terms. Principals, actions, and resources form the core of access decisions and are enriched with attributes, roles, and group memberships. All entities exist within namespaces and can be either principals or resources. The diagram also shows the legacy term subject as an older equivalent of principal and illustrates how actions operate on resources based on contextual and identity-based properties.
Use the diagram to place namespaces around the main access-decision elements: principals and resources, actions on resources, and the attributes, roles, and groups that enrich them. section 4.3.2
Choose namespace boundaries before relying on policy logic. Stable names support audit records, preserve the meaning of entitlements over time, and keep domains understandable as applications and policy sets grow. In typed policy systems, those same boundaries can turn ambiguous references into deployment-time errors rather than authorization incidents. section 2.4.3 section 7.4.3
