# InfoTechCanon Access Control Model

**Short Name:** `ITC-ACCESS`
**Document Status:** Seed Standard Release Candidate 1
**Version:** RC1-seed
**Date:** 2026-05-22
**Repository Context:** `info-tech-canon`
**Document Type:** InfoTechCanon Domain Standard
**Intended Audience:** Security architects, platform engineers, identity engineers, authorization-system designers, service owners, DevSecOps teams, governance designers, application developers, operators, agentic tooling designers, repository maintainers, and standards authors.

---

# 1. Purpose

The **InfoTechCanon Access Control Model** defines a canonical seed model for representing authorization and access-control semantics across applications, platforms, services, infrastructure, repositories, operational tools, data systems, and human-agent environments.

It provides the canonical vocabulary for:

- subjects,
- principals,
- identities as references,
- resources,
- actions,
- permissions,
- privileges,
- entitlements,
- grants,
- bindings,
- policies,
- conditions,
- authorization requests,
- authorization decisions,
- enforcement,
- sessions,
- delegation,
- temporary access,
- break-glass access,
- access reviews,
- and access evidence.

This standard deliberately distinguishes access control from generic organization modeling, governance, identity provisioning, and authentication protocols.

It answers the core question:

```text
Which authenticated subject may perform which action on which resource,
under which policy, in which context, with which evidence and review path?
```

---

# 2. Position in InfoTechCanon

The Access Control Model is a **domain standard** within InfoTechCanon.

It depends on the existing seed standards as follows:

```text
Organization = actors, persons, agents, teams, roles, memberships, authority.
Governance   = policies, controls, decisions, exceptions, reviews, evidence.
Landscape    = systems, services, resources, endpoints, repositories, data, runtime objects.
Task         = work items, requests, changes, reviews, remediation.
Tagging      = classification and selectors, not access semantics by default.
Access       = authorization relationships and decisions.
```

```text
InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonLandscapeModel
├── InfoTechCanonOrganizationModel
├── InfoTechCanonGovernanceModel
├── InfoTechCanonTaskModel
├── InfoTechCanonTaggingStandard
├── InfoTechCanonAccessControlModel     <-- this standard
├── InfoTechCanonSecurityModel
├── InfoTechCanonDataModel
├── InfoTechCanonDevSecOpsModel
├── InfoTechCanonPatternLanguage
└── Application Profiles
```

---

# 3. Boundary with Adjacent Standards

## 3.1 Boundary with Organization

The Organization Model owns:

```text
Person
Agent
Team
Organization
Role
Membership
Assignment
Authority
Responsibility
Accountability
Ownership
Stewardship
```

The Access Control Model owns:

```text
Subject
Principal
AccessRole
Permission
Privilege
Entitlement
Grant
RoleBinding
PolicyBinding
AuthorizationRequest
AuthorizationDecision
EnforcementPoint
AccessSession
AccessReview
AccessExceptionReference
```

Boundary rule:

```text
Organization defines who actors are and what organizational roles or responsibilities they carry.
Access Control defines what authenticated subjects may do to protected resources.
```

## 3.2 Boundary with Governance

The Governance Model owns:

```text
Policy
Control
ControlObjective
Decision
Approval
Exception
Risk
Evidence
Review
Audit
ComplianceRequirement
```

The Access Control Model uses governance concepts for:

```text
access policy references
access-control objectives
access reviews
access exceptions
access evidence
access approvals
risk-based access decisions
```

Boundary rule:

```text
Governance defines why and under what rule access should be controlled.
Access Control defines how authorization is represented, decided, granted, enforced, and reviewed.
```

## 3.3 Boundary with Landscape

The Landscape Model owns:

```text
Service
ApplicationService
Repository
RuntimeResource
Endpoint
DataStore
Dataset
Environment
NetworkResource
PlatformResource
```

The Access Control Model refers to these as protected resources.

Boundary rule:

```text
Landscape owns resource identity and relationships.
Access Control owns access semantics for those resources.
```

## 3.4 Boundary with Security

The Security Model should own:

```text
Threat
Vulnerability
AttackPath
SecurityFinding
SecurityEvent
SecurityIncident
SecurityControlImplementation
```

Access Control owns authorization semantics.

Security may analyze or test access control as a security domain.

## 3.5 Boundary with Identity and Authentication

Identity provisioning and authentication are related but distinct.

This standard references but does not fully own:

```text
User provisioning
Identity provider configuration
Authentication factors
MFA token lifecycle
Password policy
Federation protocol details
SCIM provisioning protocol
OIDC authentication protocol
SAML assertion protocol
```

Access Control begins after or alongside identity proofing and authentication:

```text
Authentication asks: Is this subject who or what it claims to be?
Authorization asks: What may this subject do now?
```

---

# 4. Research Basis and External Alignment

This seed standard draws on multiple access-control bodies of knowledge.

## 4.1 RBAC

Role-Based Access Control provides the classic model of users, roles, permissions, operations, and objects. The NIST/INCITS RBAC reference model distinguishes core RBAC, role hierarchies, and separation-of-duty constraints.

## 4.2 ABAC

Attribute-Based Access Control models authorization decisions as evaluations of subject, object/resource, action, and environment attributes against policies, rules, and relationships.

## 4.3 ReBAC and Zanzibar-Style Authorization

Relationship-Based Access Control represents access through relationships among users, groups, resources, tenants, and objects. Zanzibar-style systems use tuples and namespace/configuration models to evaluate authorization at large scale.

## 4.4 Policy-Based Access Control

Policy-based systems such as XACML, OPA/Rego, Cedar, Keycloak Authorization Services, and similar tools decouple authorization logic from application code and evaluate access requests against explicit policies.

## 4.5 OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework enabling limited access to HTTP services, commonly through access tokens. OpenID Connect adds an identity layer on top of OAuth 2.0 for verifying end-user identity and retrieving profile claims.

These are protocol and token ecosystems, not complete canonical authorization semantics.

## 4.6 SCIM

SCIM provides platform-neutral schemas and protocols for provisioning users, groups, and related identity resources across domains.

SCIM is a mapping target for identity references, subjects, users, and groups, but does not replace access-control semantics.

## 4.7 Kubernetes RBAC

Kubernetes RBAC demonstrates practical resource/action authorization using Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. It is a key profile target for platform and cluster access.

## 4.8 Keycloak, privacyIDEA, OPA, OpenFGA, Cedar, Casbin

Practical tooling demonstrates complementary access-control approaches:

```text
Keycloak
  identity, federation, realm/client roles, authorization services, policy enforcement.

privacyIDEA
  MFA and authentication-token orchestration with policy-driven behavior.

OPA
  general-purpose policy decision engine and Rego language.

OpenFGA
  Zanzibar-inspired fine-grained relationship-based authorization.

Cedar / Amazon Verified Permissions
  schema-aware fine-grained authorization policy language and decision service.

Casbin
  authorization library supporting many models such as ACL, RBAC, ABAC, ReBAC, PBAC, and others.
```

InfoTechCanon should map to these, not be captured by any one of them.

---

# 5. Seed Standard Design Stance

This standard is a **seed standard**, not a full implementation specification.

It shall:

1. define canonical access-control semantics,
2. distinguish identity, authentication, authorization, and governance,
3. support RBAC, ABAC, ReBAC, ACL, PBAC, and hybrid approaches,
4. support human and non-human subjects,
5. support agentic access and operational access,
6. support fine-grained resource/action authorization,
7. support temporary, delegated, emergency, and service-account access,
8. support policy decision and enforcement architecture,
9. support mappings to real standards and tools,
10. remain markdown-first and agent-retrievable,
11. and support future assimilation of access-control standards, products, and implementation patterns.

---

# 6. Scope

## 6.1 In Scope

This standard covers canonical representation of:

- subjects,
- principals,
- identity references,
- authenticated subjects,
- resources,
- protected resources,
- resource scopes,
- actions,
- operations,
- permissions,
- privileges,
- entitlements,
- grants,
- role bindings,
- policy bindings,
- access policies as references,
- access-control policies as access-specific artifacts,
- conditions,
- attributes,
- relationships,
- authorization requests,
- authorization decisions,
- authorization evidence,
- policy enforcement points,
- policy decision points,
- policy administration points,
- policy information points,
- access sessions,
- delegated access,
- temporary access,
- emergency access,
- break-glass access,
- service-account access,
- agent access,
- access reviews,
- access exceptions,
- and least privilege analysis.

## 6.2 Out of Scope

This standard does not fully define:

- identity proofing,
- account lifecycle management,
- password policy,
- MFA token enrollment,
- authentication protocol implementation,
- OAuth flow implementation,
- OIDC claim design,
- SAML profile implementation,
- full SCIM provisioning implementation,
- HR master data,
- all cybersecurity incident handling,
- full IAM product configuration,
- or legal/compliance interpretation.

Those may be mapped, assimilated, profiled, or handled by adjacent standards.

---

# 7. Normative Language

The following terms are used normatively:

- **SHALL** indicates a mandatory rule for conformance.
- **SHOULD** indicates a recommended practice.
- **MAY** indicates an optional capability.
- **MUST NOT** indicates a prohibited practice.
- **SEED** marks a concept defined provisionally here but open to later refinement.
- **EXTRACT** marks a concept that may later move to a more specialized standard.

---

# 8. Core Principles

## 8.1 Authentication Is Not Authorization

The model SHALL distinguish authentication from authorization.

Authentication verifies or establishes subject identity.
Authorization determines whether an authenticated or otherwise recognized subject may perform an action on a resource.

## 8.2 Organizational Role Is Not Access Role

An organizational role does not automatically imply an access role.

Access roles are permission-bearing constructs.

## 8.3 Permission Is Not Assignment

A permission defines allowed action on resource type or scope.
An assignment or binding connects a subject, role, permission, or policy to a concrete access scope.

## 8.4 Grant Is Not Decision

A grant is a durable or time-bound authorization relationship.
A decision is the result of evaluating a specific access request.

## 8.5 Access Requires Scope

Access rights SHOULD be scoped to resource, tenant, environment, service, dataset, system, or operational context.

## 8.6 Conditions Matter

Access may depend on attributes, relationships, time, network, device, authentication strength, risk, purpose, or environment context.

## 8.7 Enforcement Is First-Class

An access decision has practical effect only if enforced by an enforcement point.

## 8.8 Access Must Be Reviewable

Access grants, privileged access, emergency access, and agent access SHOULD be reviewable and evidence-carrying.

## 8.9 Least Privilege Is a Directional Principle

Access-control implementations SHOULD minimize permissions relative to required purpose and scope.

## 8.10 Tags Are Not Entitlements by Default

Tags may help select resources or policies but MUST NOT become entitlements unless an access-control profile explicitly defines that behavior.

---

# 9. Canonical Seed Metadata

Every access-control artifact SHOULD support structured metadata.

Recommended front matter:

```yaml
---
id: itc-access:Permission
type: concept
standard: InfoTechCanonAccessControlModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonAccessControlModel
preferred_label: Permission
related:
  - itc-access:Action
  - itc-access:Resource
  - itc-access:Grant
  - itc-access:AuthorizationDecision
mappings:
  - itc-map:permission-to-rbac-permission
---
```

Recommended artifact statuses:

```text
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
```

Recommended concept statuses:

```text
proposed
experimental
candidate
canonical
deprecated
retired
```

---

# 10. Root Access-Control Taxonomy

```text
AccessControlEntity
├── SubjectEntity
│   ├── Subject
│   ├── Principal
│   ├── AuthenticatedSubject
│   ├── HumanSubject
│   ├── ServiceSubject
│   ├── AgentSubject
│   ├── GroupSubject
│   └── FederatedSubject
├── ResourceEntity
│   ├── Resource
│   ├── ProtectedResource
│   ├── ResourceType
│   ├── ResourceInstance
│   ├── ResourceScope
│   └── ResourceOwnerReference
├── ActionEntity
│   ├── Action
│   ├── Operation
│   ├── ResourceAction
│   ├── AdministrativeAction
│   ├── PrivilegedAction
│   └── DelegableAction
├── AuthorizationEntity
│   ├── Permission
│   ├── Privilege
│   ├── Entitlement
│   ├── Grant
│   ├── Denial
│   ├── AccessRole
│   ├── RoleBinding
│   ├── PolicyBinding
│   └── ScopeBinding
├── PolicyEvaluationEntity
│   ├── AuthorizationRequest
│   ├── AuthorizationDecision
│   ├── DecisionReason
│   ├── Condition
│   ├── Attribute
│   ├── RelationshipTuple
│   └── EvaluationContext
├── EnforcementEntity
│   ├── PolicyEnforcementPoint
│   ├── PolicyDecisionPoint
│   ├── PolicyAdministrationPoint
│   ├── PolicyInformationPoint
│   ├── PolicyRetrievalPoint
│   └── EnforcementResult
├── SessionEntity
│   ├── AccessSession
│   ├── TokenReference
│   ├── CredentialReference
│   ├── AuthenticationStrengthReference
│   └── SessionContext
├── SpecialAccessEntity
│   ├── DelegatedAccess
│   ├── TemporaryAccess
│   ├── JustInTimeAccess
│   ├── BreakGlassAccess
│   ├── ServiceAccountAccess
│   └── AgentAccess
└── ReviewEntity
    ├── AccessReview
    ├── AccessCertification
    ├── AccessFinding
    ├── ExcessAccess
    ├── OrphanedAccess
    ├── StaleAccess
    └── AccessRemediation
```

---

# 11. Core Concepts

## 11.1 AccessControlEntity

An **AccessControlEntity** is any identifiable concept used to represent authorization, permissions, access grants, decisions, enforcement, or review.

Recommended attributes:

```yaml
id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:
```

Optional attributes:

```yaml
owner:
steward:
governance_scope:
resource_scope:
source_confidence:
valid_from:
valid_to:
tags:
external_references:
```

---

## 11.2 Subject

A **Subject** is an entity requesting, holding, or exercising access.

A subject may be:

```text
human user
service account
workload identity
AI agent
automation bot
group
federated identity
external partner
```

Canonical rule:

```text
Subject is the access-control view of an actor.
Actor semantics are owned by the Organization Model.
```

---

## 11.3 Principal

A **Principal** is an identity-bearing subject recognized by an access-control system.

Examples:

```text
user account
service account
federated identity
client application
machine identity
agent identity
```

A principal may map to a Person, Agent, Team, or external identity.

---

## 11.4 IdentityReference

An **IdentityReference** points to an identity record in an identity provider, directory, federation source, SCIM system, IAM system, or local user store.

The Access Control Model references identities but does not own identity lifecycle.

---

## 11.5 AuthenticatedSubject

An **AuthenticatedSubject** is a subject whose identity or credential has been verified with a defined authentication strength or context.

---

## 11.6 Resource

A **Resource** is an entity that may be accessed, modified, invoked, viewed, administered, or otherwise acted upon.

Resources may include:

```text
service
API endpoint
repository
branch
environment
cluster
namespace
database
dataset
document
file
secret
certificate
pipeline
artifact
dashboard
tenant
organization
configuration
```

Resource identity is usually owned by Landscape or another domain model.

---

## 11.7 ProtectedResource

A **ProtectedResource** is a resource subject to access-control enforcement.

---

## 11.8 ResourceScope

A **ResourceScope** defines the boundary within which access applies.

Examples:

```text
tenant
organization
project
repository
branch
service
environment
namespace
cluster
dataset
record
region
```

---

## 11.9 Action

An **Action** is something a subject may attempt to do to a resource.

Examples:

```text
read
list
create
update
delete
execute
approve
deploy
administer
impersonate
assume-role
download
share
grant-access
```

---

## 11.10 Operation

An **Operation** is a system-specific or API-specific action.

Operation may be mapped to canonical Action.

---

## 11.11 ResourceAction

A **ResourceAction** is a canonical action applied to a resource type or resource instance.

Example:

```text
repository:write
environment:deploy
dataset:read
secret:rotate
cluster:admin
```

---

## 11.12 Permission

A **Permission** is an authorization unit describing an allowed action or set of actions on a resource type, resource instance, or scope.

Canonical rule:

```text
Permission SHOULD separate action, resource, and scope when possible.
```

---

## 11.13 Privilege

A **Privilege** is a permission or permission set with elevated consequence, sensitivity, or administrative power.

Examples:

```text
root shell
cluster-admin
user-management admin
secret-read
production deploy
impersonation
policy edit
```

---

## 11.14 Entitlement

An **Entitlement** is a permission, access package, role, grant, or benefit assigned to a subject.

Entitlement is often used in IAM governance and access review contexts.

---

## 11.15 AccessRole

An **AccessRole** is a permission-bearing role in an access-control system.

It is distinct from an organizational role.

Examples:

```text
repository-maintainer
cluster-admin
billing-reader
support-agent
release-manager
secret-rotator
```

---

## 11.16 Grant

A **Grant** is a durable or time-bound relationship giving a subject access under defined scope and conditions.

Recommended attributes:

```yaml
subject:
permission_or_role:
resource_scope:
conditions:
granted_by:
valid_from:
valid_to:
source_system:
evidence:
```

---

## 11.17 Denial

A **Denial** is an explicit rule, decision, or binding that prevents access.

Denials may override grants depending on policy profile.

---

## 11.18 RoleBinding

A **RoleBinding** assigns an AccessRole to a Subject within a ResourceScope.

Example:

```text
Subject alice@example.com has AccessRole repository-maintainer on repository info-tech-canon.
```

---

## 11.19 PolicyBinding

A **PolicyBinding** connects a policy, policy set, or access rule to a subject, resource, tenant, environment, or scope.

---

## 11.20 AuthorizationRequest

An **AuthorizationRequest** is a request to determine whether a subject may perform an action on a resource in a context.

Recommended attributes:

```yaml
subject:
action:
resource:
context:
requested_at:
request_source:
```

---

## 11.21 AuthorizationDecision

An **AuthorizationDecision** is the result of evaluating an authorization request.

Recommended decision values:

```text
permit
deny
not_applicable
indeterminate
conditional_permit
```

Recommended attributes:

```yaml
request:
decision:
reason:
policy_references:
evaluated_at:
decision_point:
evidence:
```

---

## 11.22 DecisionReason

A **DecisionReason** explains why an authorization decision was reached.

Reason may reference:

```text
matched policy
missing permission
expired grant
failed condition
explicit denial
insufficient authentication strength
risk signal
break-glass requirement
```

---

## 11.23 Condition

A **Condition** is a requirement that must hold for access to be permitted.

Examples:

```text
time window
network location
device posture
MFA present
ticket reference present
risk score below threshold
resource owner approval
environment is non-production
```

---

## 11.24 Attribute

An **Attribute** is a property of subject, resource, action, or environment used in policy evaluation.

Attribute categories:

```text
subject attribute
resource attribute
action attribute
environment attribute
session attribute
risk attribute
relationship attribute
```

---

## 11.25 RelationshipTuple

A **RelationshipTuple** represents a relationship used for authorization.

Generic form:

```text
subject relation object
```

Examples:

```text
alice viewer document:123
team-platform maintainer repository:abc
group-admins admin tenant:customer1
```

This concept supports ReBAC and Zanzibar-style models.

---

## 11.26 EvaluationContext

An **EvaluationContext** is the set of attributes, relationships, session data, resource data, environmental data, and policy references used to evaluate an authorization request.

---

## 11.27 PolicyEnforcementPoint

A **PolicyEnforcementPoint** is the system component that intercepts or controls access and enforces authorization decisions.

---

## 11.28 PolicyDecisionPoint

A **PolicyDecisionPoint** is the system component that evaluates authorization requests and returns decisions.

---

## 11.29 PolicyAdministrationPoint

A **PolicyAdministrationPoint** is the system component or process where access policies are created, maintained, approved, or published.

---

## 11.30 PolicyInformationPoint

A **PolicyInformationPoint** is a source of attributes, relationships, or context used during policy evaluation.

Examples:

```text
directory
HR system
SCIM service
CMDB
resource inventory
risk engine
device posture service
ticket system
```

---

## 11.31 PolicyRetrievalPoint

A **PolicyRetrievalPoint** stores or retrieves policies for evaluation.

---

## 11.32 AccessSession

An **AccessSession** is a time-bounded context in which a subject exercises access.

A session may reference:

```text
token
credential
authentication strength
device
network
client
risk context
start time
expiry
```

---

## 11.33 TokenReference

A **TokenReference** points to a token used in an access session or protocol exchange.

Examples:

```text
OAuth access token
OIDC ID token
SAML assertion
Kubernetes service account token
SSH certificate
```

---

## 11.34 CredentialReference

A **CredentialReference** points to a credential used for authentication or access.

Examples:

```text
password
SSH key
API key
certificate
MFA token
hardware key
workload identity credential
```

---

## 11.35 AuthenticationStrengthReference

An **AuthenticationStrengthReference** records the strength or assurance of authentication used.

Examples:

```text
password-only
MFA
phishing-resistant MFA
hardware-backed key
workload identity
mutual TLS
```

---

## 11.36 DelegatedAccess

**DelegatedAccess** is access where one subject grants or delegates access authority to another subject within defined limits.

---

## 11.37 TemporaryAccess

**TemporaryAccess** is access granted for a limited time.

---

## 11.38 JustInTimeAccess

**JustInTimeAccess** is temporary access granted only when needed, often after approval, ticket reference, risk check, or workflow.

---

## 11.39 BreakGlassAccess

**BreakGlassAccess** is emergency access used when normal processes are insufficient or unavailable.

Break-glass access SHOULD be:

```text
rare
time-bound
strongly authenticated
logged
reviewed
evidence-carrying
subject to post-use review
```

---

## 11.40 ServiceAccountAccess

**ServiceAccountAccess** is access exercised by a service account, machine identity, workload identity, automation, or non-human subject.

---

## 11.41 AgentAccess

**AgentAccess** is access exercised by an AI or software agent.

Agent access SHOULD declare:

```text
supervising actor
scope
tools
permissions
safety boundaries
audit expectations
revocation mechanism
```

---

## 11.42 AccessReview

An **AccessReview** is a governance review of whether access grants, roles, entitlements, privileges, or policies remain appropriate.

---

## 11.43 AccessCertification

**AccessCertification** is a formal attestation that reviewed access remains appropriate or has been corrected.

---

## 11.44 AccessFinding

An **AccessFinding** is a finding produced by access review, audit, analysis, monitoring, or security assessment.

Examples:

```text
excess access
stale access
orphaned account
unused privilege
privilege escalation path
missing owner
break-glass misuse
```

---

## 11.45 ExcessAccess

**ExcessAccess** is access beyond what is needed for the subject's current purpose, role, task, or scope.

---

## 11.46 OrphanedAccess

**OrphanedAccess** is access assigned to a subject, account, or identity reference that no longer has a valid owner, actor, employment/membership relation, or purpose.

---

## 11.47 StaleAccess

**StaleAccess** is access that was once justified but has not been used, reviewed, or renewed within expected limits.

---

## 11.48 AccessRemediation

**AccessRemediation** is work to correct inappropriate, excessive, stale, orphaned, or risky access.

AccessRemediation may create Task Model work items.

---

# 12. Core Relationship Vocabulary

Recommended root relationship types:

```text
requests_access_to
has_permission
has_privilege
has_entitlement
granted_to
denied_to
bound_to
assigned_role
applies_to_resource
applies_to_scope
permits_action
denies_action
requires_condition
evaluated_by
enforced_by
provided_by
retrieved_from
informed_by
delegated_to
expires_at
reviewed_by
certified_by
violates_policy
remediated_by
maps_to
```

Relationship records SHOULD support:

```yaml
id:
relationship_type:
source_entity:
target_entity:
scope:
valid_from:
valid_to:
source_system:
confidence:
evidence:
rationale:
```

---

# 13. Access Decision Model

## 13.1 Authorization Request Shape

A canonical authorization request SHOULD include:

```yaml
subject:
action:
resource:
context:
  time:
  environment:
  session:
  authentication_strength:
  network:
  device:
  risk:
  purpose:
  request_source:
```

## 13.2 Authorization Decision Values

Recommended decision values:

```text
permit
deny
not_applicable
indeterminate
conditional_permit
```

## 13.3 Decision Evidence

Mature systems SHOULD preserve:

```text
policy references
matched grants
matched denials
condition results
attribute sources
relationship tuples used
decision time
decision point
enforcement point
request correlation id
```

## 13.4 Fail-Safe Rule

Profiles SHOULD define how to handle indeterminate decisions.

Security-sensitive systems SHOULD default to deny unless an explicit profile states otherwise.

---

# 14. Access-Control Patterns

## 14.1 Pattern: Subject-Action-Resource

**Context:** A system needs a stable core authorization model.

**Problem:** Access rules become inconsistent when subjects, actions, resources, and scopes are mixed together.

**Solution:** Represent authorization around:

```text
Subject
Action
Resource
Context
Decision
```

---

## 14.2 Pattern: Organizational Role to Access Role Mapping

**Context:** Organizational roles often need access.

**Problem:** Treating organizational roles as direct permissions creates hidden privilege.

**Solution:** Map OrganizationalRole to AccessRole through explicit grants, bindings, policies, or profiles.

---

## 14.3 Pattern: Policy Decision / Enforcement Split

**Context:** Application code needs authorization but should not hard-code policy logic.

**Problem:** Access rules become scattered across services.

**Solution:** Separate:

```text
Policy Enforcement Point
Policy Decision Point
Policy Administration Point
Policy Information Point
```

---

## 14.4 Pattern: Least Privilege Grant

**Context:** A subject needs access to perform work.

**Problem:** Broad roles accumulate and become risky.

**Solution:** Grant only the needed actions on the needed resources for the needed scope and duration.

---

## 14.5 Pattern: Just-in-Time Privilege

**Context:** Privileged access is needed occasionally.

**Problem:** Standing privileged access creates persistent risk.

**Solution:** Use temporary, approved, logged, expiring access grants.

---

## 14.6 Pattern: Break Glass with Review

**Context:** Emergency access is required to restore or protect critical systems.

**Problem:** Emergency access can become an invisible bypass.

**Solution:** Require strong authentication, explicit reason, time limit, logging, post-use review, and remediation of any misuse.

---

## 14.7 Pattern: Service Account Ownership

**Context:** Non-human accounts access systems.

**Problem:** Service accounts become orphaned or over-privileged.

**Solution:** Every service account should have owner, purpose, scope, permissions, rotation expectation, and review cycle.

---

## 14.8 Pattern: Agent Access Boundary

**Context:** AI or software agents perform actions.

**Problem:** Agents may combine tools and permissions in unexpected ways.

**Solution:** Agent access must declare supervising actor, allowed tools, resource scope, action scope, safety boundary, logging, and review requirements.

---

## 14.9 Pattern: Access Review to Remediation

**Context:** Access reviews find inappropriate access.

**Problem:** Findings do not turn into corrective action.

**Solution:** Model:

```text
AccessReview
  -> AccessFinding
  -> AccessRemediationTask
  -> Evidence
  -> AccessCertification
```

---

## 14.10 Pattern: Relationship Tuple for Collaboration

**Context:** Access depends on relationships such as owner, viewer, editor, parent folder, team membership, or tenant membership.

**Problem:** Flat roles cannot express dynamic collaborative access cleanly.

**Solution:** Use relationship tuples and relationship-based checks where appropriate.

---

# 15. Access Profiles

## 15.1 Profile Format

An Access Profile SHALL declare:

```yaml
id:
profile_name:
status:
implements:
  - InfoTechCanonAccessControlModel
target_context:
included_concepts:
required_relationships:
required_metadata:
decision_model:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:
```

---

## 15.2 Seed Profile: Small SaaS Access Profile

Purpose:

```text
Provide a minimal access model for a small SaaS platform moving toward production readiness.
```

Included concepts:

```text
Subject
Principal
Resource
Action
Permission
AccessRole
RoleBinding
AuthorizationRequest
AuthorizationDecision
AccessSession
AccessReview
TemporaryAccess
ServiceAccountAccess
```

Required relationships:

```text
Principal maps_to Actor
AccessRole has_permission Permission
RoleBinding grants AccessRole to Subject within ResourceScope
AuthorizationRequest evaluated_by PolicyDecisionPoint
AuthorizationDecision enforced_by PolicyEnforcementPoint
AccessReview reviews Grant
```

---

## 15.3 Seed Profile: Kubernetes RBAC Profile

Purpose:

```text
Map Kubernetes RBAC objects into InfoTechCanon access-control concepts.
```

Example mappings:

```text
User / Group / ServiceAccount -> Subject
Role -> AccessRole scoped to Namespace
ClusterRole -> AccessRole scoped to Cluster
RoleBinding -> RoleBinding scoped to Namespace
ClusterRoleBinding -> RoleBinding scoped to Cluster
PolicyRule verbs -> Actions
PolicyRule resources -> ResourceTypes
Namespace -> ResourceScope
```

Known deviations:

```text
Kubernetes RBAC is additive and does not model explicit deny in standard RBAC.
Kubernetes subjects may reference identities outside the cluster.
ClusterRole can be bound namespace-locally through RoleBinding.
```

---

## 15.4 Seed Profile: OPA Policy Decision Profile

Purpose:

```text
Map OPA/Rego-style policy decision architecture into InfoTechCanon access-control concepts.
```

Example mappings:

```text
input -> AuthorizationRequest
data -> PolicyInformation / PolicyData
rego policy -> AccessPolicyImplementation
allow result -> AuthorizationDecision
OPA server/library -> PolicyDecisionPoint
application gateway/service -> PolicyEnforcementPoint
```

---

## 15.5 Seed Profile: OpenFGA / Zanzibar Profile

Purpose:

```text
Map relationship-based authorization concepts into InfoTechCanon.
```

Example mappings:

```text
user -> Subject
object -> Resource
relation -> RelationshipTuple relation
tuple -> RelationshipTuple
authorization model -> Policy / Schema
check request -> AuthorizationRequest
check response -> AuthorizationDecision
```

---

## 15.6 Seed Profile: Keycloak Authorization Profile

Purpose:

```text
Map Keycloak identity and authorization concepts into InfoTechCanon.
```

Example mappings:

```text
Realm -> AccessDomain / TenantScope
Client -> ResourceServer / ClientApplication
Realm Role -> AccessRole
Client Role -> AccessRole within ClientScope
Group -> GroupSubject
User -> Principal
Resource -> ProtectedResource
Scope -> Action / ResourceScope depending on usage
Policy -> AccessPolicyImplementation
Permission -> Permission / PolicyBinding
```

---

## 15.7 Seed Profile: Cedar / Verified Permissions Profile

Purpose:

```text
Map Cedar-style fine-grained authorization into InfoTechCanon.
```

Example mappings:

```text
principal -> Subject
action -> Action
resource -> Resource
context -> EvaluationContext
policy -> AccessPolicyImplementation
schema -> AccessModelSchema
permit/forbid -> AuthorizationDecision rule type
authorization API call -> AuthorizationRequest
```

---

## 15.8 Seed Profile: Ops / Break-Glass Access Profile

Purpose:

```text
Represent high-risk operational access to infrastructure, production systems, secrets, and emergency tools.
```

Included concepts:

```text
PrivilegedAction
TemporaryAccess
JustInTimeAccess
BreakGlassAccess
ApprovalReference
AccessSession
SessionRecordingReference
AccessEvidence
PostUseReview
AccessFinding
AccessRemediation
```

Required relationships:

```text
TemporaryAccess approved_by Actor
BreakGlassAccess requires Reason
AccessSession evidences AccessUse
PostUseReview reviews AccessSession
AccessFinding remediated_by Task
```

---

## 15.9 Seed Profile: Agent Access Profile

Purpose:

```text
Support AI and software agents that act through tools and APIs.
```

Included concepts:

```text
AgentSubject
ToolResource
ActionScope
ResourceScope
SupervisingActor
DelegatedAccess
TemporaryAccess
PolicyBinding
ExecutionEvidence
HumanReview
RevocationMechanism
```

Required relationships:

```text
AgentSubject supervised_by Actor
AgentSubject has_permission Permission
Permission applies_to ToolResource
Grant constrained_by SafetyCondition
ExecutionEvidence evidences Action
HumanReview reviews AgentAccess
```

---

# 16. Mapping Model for the Access Control Standard

Mappings relate InfoTechCanon access-control concepts to external standards, tools, and products.

## 16.1 Mapping Types

Recommended mapping types:

```text
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent
```

## 16.2 Mapping Record

Example:

```yaml
id: itc-map:permission-to-rbac-permission
source_concept: itc-access:Permission
target_body: NIST/INCITS RBAC
target_version: "INCITS 359-2012 / R2022"
target_concept: Permission
mapping_type: closeMatch
scope:
  - role-based access-control modeling
not_valid_for:
  - attribute-based conditions
  - relationship-based dynamic authorization
rationale: >
  Both concepts represent an authorization unit combining operations and objects/resources,
  but InfoTechCanon generalizes permission across RBAC, ABAC, ReBAC, and policy-based models.
confidence: high
status: candidate
owner: InfoTechCanonAccessControlModel
```

## 16.3 Seed Mapping Targets

The Access Control Model SHOULD maintain mappings to:

```text
NIST / INCITS RBAC
NIST SP 800-162 ABAC
XACML 3.0
OAuth 2.0
OpenID Connect
SAML 2.0
SCIM 2.0
Kubernetes RBAC
AWS IAM
Cedar / Amazon Verified Permissions
Open Policy Agent / Rego
OpenFGA
Google Zanzibar
Keycloak roles and authorization services
privacyIDEA policies and MFA concepts
Casbin model/policy concepts
Linux users/groups/sudo
LDAP groups
GitHub repository roles
GitLab permissions
Jira permissions
Cloud provider IAM models
```

---

# 17. Assimilation Hooks

The Access Control Model SHALL be able to receive new access-control standards, tools, products, and patterns through the InfoTechCanon assimilation process.

## 17.1 Assimilation Triggers

Assimilation may be triggered by:

```text
new IAM product
new authorization framework
new policy language
new access-control model
new cloud provider IAM feature
new Kubernetes authorization feature
new DevSecOps access requirement
new agentic access-control need
new production-readiness requirement
new access-control failure
```

## 17.2 Access Assimilation Output

An access assimilation SHOULD produce:

```text
source summary
extracted access concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions
```

## 17.3 Recommended First Assimilation Candidates

```text
Kubernetes RBAC
Keycloak role and authorization model
privacyIDEA policies and MFA model
NIST RBAC
NIST ABAC
OpenFGA / Zanzibar
OPA / Rego
Cedar / Amazon Verified Permissions
SCIM 2.0
OAuth 2.0 / OIDC
Linux sudoers
GitHub repository permissions
```

---

# 18. Integration with Other InfoTechCanon Standards

## 18.1 Organization Model

Access imports organization concepts for:

```text
actor
person
agent
team
group
organizational role
authority
responsibility
ownership
membership
```

## 18.2 Governance Model

Access imports governance concepts for:

```text
access policy
control objective
control
approval
exception
risk
evidence
review
audit
compliance requirement
```

## 18.3 Landscape Model

Access applies to landscape concepts such as:

```text
service
repository
pipeline
artifact
runtime resource
network endpoint
dataset
secret
environment
platform
tenant
```

## 18.4 Task Model

Access creates or references tasks such as:

```text
access request
access approval task
access review task
access remediation task
break-glass review task
agent access review task
```

## 18.5 Tagging Standard

Tags may classify access grants, resources, or policies but must not replace access-control relationships.

## 18.6 Security Model

Security imports access-control concepts for:

```text
privilege escalation
excess access
access finding
identity attack path
credential misuse
authorization bypass
```

---

# 19. Canon Interface Card Usage

Subsystems that implement or produce access-control knowledge SHOULD publish a Canon Interface Card.

Example:

```yaml
subsystem: keycape
implements:
  - InfoTechCanonAccessControlModel
  - SmallSaaSAccessProfile
produces:
  - Principal
  - AccessRole
  - RoleBinding
  - AuthorizationDecision
  - AccessSession
consumes:
  - Person
  - Team
  - Policy
  - Service
relations:
  - Principal maps_to Person
  - Principal assigned_role AccessRole
  - AccessRole has_permission Permission
  - AuthorizationDecision enforced_by Service
source_of_truth:
  principal_identity: keycape
  role_binding: keycape
known_deviations:
  - does not model full HR lifecycle
  - does not own governance policy definitions
```

---

# 20. Retrieval Requirements

The Access Control Model is designed for markdown-based infospaces.

## 20.1 Required Retrieval Properties

Every major concept SHOULD provide:

- stable heading,
- stable identifier,
- short definition,
- longer explanation,
- examples,
- distinction notes,
- relationship examples,
- mapping hooks,
- profile references,
- and common mistakes.

## 20.2 Agent Brief

A mature Access Control Model SHOULD include an `agent-brief.md` file with:

```text
purpose
scope
owned concepts
imported concepts
core distinctions
do / do not rules
relationship patterns
minimal examples
common mistakes
profile list
mapping list
```

## 20.3 Indexes

The access-control information space SHOULD provide indexes by:

```text
concept
relationship
subject type
resource type
action
permission
role
grant
decision
profile
pattern
mapping target
status
source system
```

---

# 21. Conformance Levels

## 21.1 Reference-Conformant

A document or system is reference-conformant if it uses Access Control Model terminology consistently but does not implement structured metadata or validation rules.

## 21.2 Metadata-Conformant

A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.

## 21.3 Relationship-Conformant

A system is relationship-conformant if it represents subjects, resources, actions, permissions, grants, bindings, decisions, and enforcement as explicit relationships.

## 21.4 Decision-Conformant

A system is decision-conformant if authorization requests and decisions are represented with subject, action, resource, context, decision value, and policy or reason references.

## 21.5 Evidence-Conformant

A system is evidence-conformant if access reviews, privileged access, break-glass access, and authorization decisions can be linked to evidence.

## 21.6 Profile-Conformant

A system is profile-conformant if it implements a declared Access Profile and passes its validation rules.

## 21.7 Assimilation-Conformant

A system or repository is assimilation-conformant if it can accept external access-control concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.

---

# 22. Validation Rules

Initial validation rules:

```text
VAL-ACCESS-001: Authentication and authorization SHOULD be modeled as distinct concerns.

VAL-ACCESS-002: OrganizationalRole MUST NOT be treated as AccessRole unless a mapping or profile declares it.

VAL-ACCESS-003: Permission SHOULD identify action, resource, and scope where possible.

VAL-ACCESS-004: Grant SHOULD identify subject, permission or role, resource scope, source, and validity period where applicable.

VAL-ACCESS-005: AuthorizationRequest SHOULD identify subject, action, resource, and evaluation context.

VAL-ACCESS-006: AuthorizationDecision SHOULD record decision value, decision reason, evaluated policy or grant references, and decision point where available.

VAL-ACCESS-007: PolicyEnforcementPoint SHOULD be identified for enforced access decisions.

VAL-ACCESS-008: Privileged access SHOULD be time-bounded or periodically reviewed.

VAL-ACCESS-009: BreakGlassAccess SHOULD require reason, strong authentication, logging, expiry, and post-use review.

VAL-ACCESS-010: ServiceAccountAccess SHOULD declare owner, purpose, scope, and review expectation.

VAL-ACCESS-011: AgentAccess SHOULD declare supervising actor, allowed actions, resource scope, safety boundary, and evidence requirements.

VAL-ACCESS-012: AccessReview SHOULD produce findings or certification evidence.

VAL-ACCESS-013: AccessFinding SHOULD create or reference remediation work when correction is required.

VAL-ACCESS-014: Tags MUST NOT be treated as entitlements unless an Access Profile explicitly defines that behavior.

VAL-ACCESS-015: Imported external access concepts SHOULD be represented through mapping records rather than silently reused.

VAL-ACCESS-016: Profiles MUST NOT redefine canonical concepts. They may constrain them.

VAL-ACCESS-017: Standing privileges SHOULD be justified by purpose, scope, and review cycle.

VAL-ACCESS-018: Orphaned, stale, or excess access SHOULD be detectable in mature implementations.
```

---

# 23. Anti-Patterns

## 23.1 Login Means Access

Assuming that authentication implies authorization.

## 23.2 Organizational Role Equals Permission

Giving permissions directly based on job titles or informal roles without explicit access mapping.

## 23.3 God Role

Creating broad administrator roles without scope, review, or justification.

## 23.4 Standing Privilege Everywhere

Keeping persistent privileged access when temporary or just-in-time access would suffice.

## 23.5 Service Account Without Owner

Allowing non-human accounts without owner, purpose, expiry, credential rotation, or review.

## 23.6 Break Glass Without Glass

Emergency access exists but is not time-bounded, logged, reviewed, or exceptional.

## 23.7 Policy in Code Only

Hard-coding authorization logic in application code without explicit policy model or review path.

## 23.8 Token as Truth

Treating token claims as always sufficient for authorization without checking resource, context, or policy.

## 23.9 Tag-Based Authorization Drift

Using uncontrolled labels or tags to grant access.

## 23.10 Access Review Theater

Running access reviews that do not produce evidence, findings, remediation, or certification.

---

# 24. Initial Repository Placement

Recommended repository layout:

```text
info-tech-canon/
  standards/
    access-control/
      InfoTechCanonAccessControlModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/
```

Seed files:

```text
standards/access-control/InfoTechCanonAccessControlModel.md
standards/access-control/agent-brief.md
standards/access-control/concepts/subject.md
standards/access-control/concepts/resource.md
standards/access-control/concepts/action.md
standards/access-control/concepts/permission.md
standards/access-control/concepts/grant.md
standards/access-control/concepts/authorization-decision.md
standards/access-control/concepts/policy-enforcement-point.md
standards/access-control/concepts/access-review.md
standards/access-control/patterns/subject-action-resource.md
standards/access-control/patterns/policy-decision-enforcement-split.md
standards/access-control/patterns/least-privilege-grant.md
standards/access-control/patterns/just-in-time-privilege.md
standards/access-control/profiles/small-saas-access-profile.md
standards/access-control/profiles/kubernetes-rbac-profile.md
standards/access-control/profiles/openfga-zanzibar-profile.md
standards/access-control/profiles/agent-access-profile.md
standards/access-control/mappings/rbac.yaml
standards/access-control/mappings/abac.yaml
standards/access-control/mappings/kubernetes-rbac.yaml
standards/access-control/mappings/oidc-oauth.yaml
```

---

# 25. Roadmap

## Phase 1: Seed Stabilization

- Establish this standard as `InfoTechCanonAccessControlModel`.
- Add seed concepts, relationship vocabulary, patterns, and profiles.
- Define validation rules.
- Align with Organization, Governance, Landscape, Task, and Tagging.

## Phase 2: First Assimilations

Recommended first assimilations:

```text
NIST / INCITS RBAC
NIST SP 800-162 ABAC
Kubernetes RBAC
Keycloak roles and authorization services
privacyIDEA policies and MFA model
OpenFGA / Zanzibar
OPA / Rego
Cedar / Amazon Verified Permissions
SCIM 2.0
OAuth 2.0 / OIDC
```

## Phase 3: Profile Maturation

- Mature Small SaaS Access Profile.
- Mature Kubernetes RBAC Profile.
- Mature Keycloak Authorization Profile.
- Mature Agent Access Profile.
- Mature Ops / Break-Glass Access Profile.

## Phase 4: Tooling Integration

- Generate concept indexes.
- Generate agent brief.
- Create machine-readable YAML/JSON exports.
- Add validation scripts.
- Use in `user-engine`, `user-accounts`, `user-manager`, `OpsBridge`, `Keycape`, `NetKingdom`, and production-readiness tooling.

## Phase 5: Security Integration

- Feed access findings into Security Model.
- Connect access reviews to Governance.
- Connect privileged actions to observability and audit evidence.
- Connect access remediation to Task Model.

---

# 26. Summary

The InfoTechCanon Access Control Model is the seed standard for representing authorization semantics across human, system, service, platform, and agentic access.

Its most important commitments are:

```text
Separate authentication from authorization.

Separate organizational roles from access roles.

Represent access as subject, action, resource, context, decision, and enforcement.

Support RBAC, ABAC, ReBAC, ACL, PBAC, and hybrid models without being captured by one.

Make grants, permissions, decisions, enforcement, sessions, reviews, and evidence explicit.

Treat service-account, privileged, temporary, break-glass, and agent access as first-class patterns.

Map to external standards and tools without surrendering internal semantic autonomy.
```

This makes the Access Control Model a core seed for production readiness, user management, operational access, security posture, agent boundaries, and interoperable authorization across the InfoTechCanon ecosystem.