Skip to content

identitycore-platform.boundary-model.md

Latest commit

 

History

History
86 lines (62 loc) · 4 KB

identitycore-platform.boundary-model.md

File metadata and controls

86 lines (62 loc) · 4 KB
Raw

Delegated Identity And Session Policy Boundary Model

Purpose

This document closes public issue #3: Create an identity and session policy map for agentic workflows that need delegated access.

It provides concrete agentic-enterprise evidence for IdentityCore Platform. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

Authentication, RBAC evaluation, delegated access, session elevation, account recovery, token issuance, tenant-claim mutation, and any agent-assisted workflow that can change identity or authorization state.

Actors

Actor Responsibility
End user Owns account authentication, consent, and session activity.
Workspace administrator Manages tenant policy, role assignment, and recovery decisions.
AI identity assistant Can explain policy state and propose remediation; cannot grant access.
Policy engine Evaluates roles, tenant claims, session age, and risk signals.
Maintainer Reviews auth, session, audit, and provider fallback evidence.

Identity Boundary

  • Authentication identity, tenant membership, delegated authority, and AI assistant capability must be separate concepts.
  • The AI identity assistant cannot create accounts, grant roles, reset MFA, rotate secrets, or bypass session policy.
  • Every role, token, and session decision must preserve actor, policy version, tenant, risk state, and reviewer context.
  • OAuth secrets, signing keys, session cookies, and recovery tokens must never be exposed in prompts, logs, examples, or screenshots.

Tool And Action Boundary

Action Boundary
evaluate_access Read-only policy evaluation with tenant and session context.
propose_role_change Draft recommendation only; administrator approval required.
elevate_session Requires explicit human step-up and policy reason.
recover_account Requires human review, audit evidence, and out-of-band verification.
revoke_session Allowed through approved admin policy with audit record.

Human Approval Gates

  • Before granting, removing, or escalating roles.
  • Before resetting MFA, changing account recovery state, or issuing recovery links.
  • Before widening delegated access for an agent-assisted workflow.
  • Before changing policy defaults, session duration, or tenant claim mapping.
  • Before deleting identity, session, or access-decision audit records.

Audit Event Model

Event Minimum Evidence
access.evaluated subject, tenant, resource, policy version, decision
role_change.proposed subject, requested role, reason, proposer, risk class
role_change.approved approver, policy version, before/after roles
session.elevated subject, method, reason, duration, approver
account_recovery.completed account, verification method, reviewer, outcome

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint to prove static project health.
  • npm run test for policy, session, role, and audit fixtures when available.
  • npm run build to prove the application compiles.
  • Use synthetic tenants, users, roles, and policy fixtures in public proof.

OSS And Self-Hosted Fallbacks

  • Use Auth.js/NextAuth and local OAuth test providers for contributor proof where feasible.
  • Use PostgreSQL or SQLite for session, role, and audit event fixtures.
  • Keep hosted identity, email, MFA, and policy decision providers behind explicit adapters.
  • Prefer OpenID Connect and standards-based claims over provider-specific lock-in.

Contributor Follow-Up

Add a small policy fixture that maps subject, tenant, role, resource, session risk, policy decision, reviewer, and audit event.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path