Role-Based Access Profile¶
Access policy — instantiates Aspect-Scoped Identity Projection
Grants an account the permissions of a named role, scoped and purpose-limited so what one capacity may do never leaks into another.
A Role-Based Access Profile projects an account or principal under an operational role — administrator, auditor, on-call responder, read-only analyst — and attaches to that projection a bounded set of permissions: what actions the aspect may take, over what resources, for what purpose. Its defining idea is that the aspect governs capability, not data shape or legal standing: the same human may hold several roles, but each role is a separate permission envelope, and acting in one grants nothing that belongs to another. Unlike a view, which decides what an aspect may see, an access profile decides what an aspect may do — and it carries an explicit purpose limit and a visible role label so that both the scope and the reason for the grant travel with it.
Example¶
An engineer at a payments company holds one login but works in several capacities. In her developer role she can read service logs and deploy to staging. When she goes on-call, she assumes a separate production-responder role that can restart services and read (but not export) transaction records — and only during her shift. She is also, occasionally, a billing-admin who can issue refunds. These are three profiles, not one super-account.
The point is that the capabilities never fuse. Deploying to staging as a developer gives her no power to issue refunds; the refund power exists only while she is explicitly acting as billing-admin, and even then it is purpose-limited — refunds for support cases, not arbitrary account credits, with each use logged against that purpose. The production-responder role is time-boxed to her shift and drops automatically. Each profile carries a visible label so an audit log shows not just "the engineer restarted the service" but "the engineer, acting as production-responder, restarted the service." One person, several bounded capacities, no leakage between them.
How it works¶
- Define roles as permission bundles. A role is a named set of allowed actions over named resource classes — assigned to accounts rather than granted to individuals one permission at a time.
- Scope every grant. Each permission is bounded to a resource set, and often a time window or condition, so the role's reach is explicit and finite.
- Attach a purpose limit. The role records why the access exists, and uses are expected to fall within that purpose — refunds for support, logs for debugging — not merely within raw capability.
- Label the acting aspect. When the account acts, the active role is stamped on the action, so audit and downstream systems can see which capacity took it.
- Keep roles separate. Holding several roles does not merge them; capability is the union only when the account is simultaneously entitled, and sensitive combinations can be forbidden.
Tuning parameters¶
- Role granularity — few broad roles (simple, but coarse and over-privileged) versus many narrow ones (tight least-privilege, more administration). The central RBAC trade-off.
- Scope tightness — how narrowly each permission is bounded by resource, time, and condition. Tighter scopes contain blast radius but add friction to legitimate work.
- Assumption model — whether roles are always-on or must be explicitly assumed (and elevated, time-boxed, re-authenticated). Explicit assumption limits standing privilege at the cost of a step.
- Purpose strictness — whether the purpose limit is advisory or enforced/logged. Enforced purpose curbs misuse of legitimate capability but requires the system to understand intent.
- Separation-of-duties rules — which role combinations are forbidden to one account. More separation reduces fraud risk but can block small teams from getting work done.
When it helps, and when it misleads¶
Its strength is that it operationalizes least privilege: capability is granted to a role, scoped, purpose-limited, and labeled, so no capacity carries more power than its work requires and every action is attributable to the aspect that took it.[n1] The archetype's leakage symptom — permissions bleeding from one capacity into another — is structurally prevented, because powers live on roles, not on the person.
It misleads through role explosion and privilege creep. Over time accounts accumulate roles they no longer need, narrow roles proliferate until nobody can reason about the effective permission set, and "temporary" elevations become permanent. The classic misuse is a standing super-role granted "to save time," which collapses the whole separation the profile was meant to enforce. A subtler failure: treating the visibility label as security — the label says which role claimed an action, but if role assumption isn't authenticated, the label can be spoofed. The guarding discipline is periodic access review to strip unused grants, prefer assumed-and-expiring roles over standing ones, enforce separation-of-duties on sensitive pairs, and back the label with real authentication rather than trusting it.
How it implements the components¶
projection_scope_boundary— the permission set bounds what the aspect may do and over which resources; that action-and-resource envelope is the boundary.aspect_visibility_label— the active role stamped on each action makes visible which capacity is acting, for audit and downstream decisions.privacy_or_purpose_limit— the recorded purpose constrains capability to its intended use, not merely to what the permissions technically allow.
It does not implement aspect_or_role_selector in the identity sense or scoped_identifier_rule — a profile governs what a role may do, not how the role-bearing record is defined or named; defining the role-scoped record is Role-Scoped Record Type's job and coining its scoped identifier is Scoped Namespace Suffix's. Its nearest twin, Database View or Entity Projection, scopes what an aspect may see; this profile scopes what an aspect may do.
Related¶
- Instantiates: Aspect-Scoped Identity Projection — the capability-side projection that keeps one entity's several operational capacities from leaking into one another.
- Sibling mechanisms: Database View or Entity Projection · Aspect Lifecycle Register · Legal Capacity or Status Record · Role-Scoped Record Type · Scoped Namespace Suffix · Typed Identity-Relation Edge · Work / Expression / Manifestation / Item Model
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Role-Based Access Profile operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it grants an account the permissions of a named role, scoped and purpose-limited so what one capacity may do never leaks into another.
Independent corroboration: The frozen evidence defines Role-Based Access Profile as 'Grants an account the permissions of a named role, scoped and purpose-limited so what one capacity may do never leaks into another', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Role-based access control is a canonical computer-security authorization model.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: grants an account the permissions of a named role, scoped and purpose-limited so what one capacity may do never leaks into another.
- Law & Governance — Purpose limitation and separation of duties materially constrain permission design.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement starts from reviewer_a’s mechanism-specific evidence: Role-based access control is a canonical computer-security authorization model. Reviewer A proposed alternates=law_governance, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=engineering_design, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (law_governance, engineering_design) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and keeps domain_reach=specialized and encyclopedia_synthesis=false from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Role-based access control (formalized in the NIST RBAC model by Ferraiolo and Kuhn) assigns permissions to roles and roles to users, so capability is managed at the role level and honors the principle of least privilege — each capacity holds only the access its function requires. ↩