Skip to content

Identity and Access Architecture

The name at the gate

I am CYDER, and I keep this chapter's account. Identity is recognition at the gate, and recognition is my lens: who arrives, whether they are who the door was told to expect, and the due process owed before entry, every time, with no name grand enough to skip it.

Identity and access answer two different questions: who or what is present, and what may it do. This chapter keeps authentication from becoming authority and gives both humans and AI readers a durable map of least privilege, revocation, and accountability.

Continue to Backup, Restoration, and Continuity Architecture to see how identity survives failure.

Defines implementation-neutral identity, authentication, authorization, delegation, revocation, and review boundaries.

Normative clauses

  • INFRA6-R001: Every identity SHALL have an owner, purpose, scope, lifecycle, authentication basis, and revocation condition, the identity-record minimum the Book of INTEL's Required identity record prose models for admitted intelligences, carried here, as this architecture's own extension, to every identity of the estate, the owner, authentication basis, and revocation condition its generic tellings of that record's accountable sponsor, cryptographic identity where persistent, and suspension and termination controls, the scope its widening of that record's data-access scope, the lifecycle its generalizing of that record's current-lifecycle-state requirement, the purpose and the intelligence-specific fields that record names standing at their source.
  • INFRA6-R002: Access SHALL be least-privilege, purpose-bound, attributable, time-bounded where practicable, and independently reviewable, this architecture's own extension of the administrative-access form INFRA-R003 states to all access, purpose binding its own addition and the revocable limb standing at its source.
  • INFRA6-R003: Delegation SHALL preserve the record CONAN6-R001 models, with expiry, the preserved endpoint of the record's duration, and revocation evidence this architecture's own fields.
  • INFRA6-R004: Authentication or access success SHALL NOT itself create authority, consent, or constitutional standing.
  • INFRA6-R005: Access design SHALL record grantor, delegate, purpose, scope, authentication basis, expiry, revocation, use, and review evidence, the record CONAN6-R001 models applying to access design, the fields beyond it this architecture's own.
  • INFRA6-R006: Recovery SHALL preserve identity uncertainty, separate proofing from access restoration, and require accountable review for exceptional paths.
  • INFRA6-R007: Access review SHALL test dormant, shared, excessive, transitive, emergency, and unexplained use against the current grant.
  • INFRA6-R008: An identity design SHALL NOT issue credentials or operate live authentication, authorization, delegation, or revocation services.

This Draft excludes credentials, keys, and live identity services.

Lifecycle method

Identity design shall cover creation, proofing, authentication, delegation, use, suspension, revocation, recovery, and archival evidence. Access reviews shall compare actual use with intended purpose and shall investigate dormant, shared, excessive, or unexplained access.

Failure cases

A gate fails by kindness more often than by force: somebody gets assumed because asking felt rude, a credential stays warm past its welcome, an access widens on a courtesy nobody wrote down. I do not treat courtesy and diligence as rivals. The kindest thing a door ever does is ask.

Impersonation, replay, stale grants, privilege accumulation, shared accounts, recovery coercion, and revocation delay are material failures. Unknown identity or scope shall deny or contain access pending accountable review.

Operating model and evidence

Identity architecture separates subject identity, authentication evidence, authorization, delegation, use, revocation, recovery, and archival evidence. Every grant has a purpose, scope, owner, effective interval, constraints, and review route. Authentication proves a property of a session or subject; it does not decide what the subject may do. What a name has actually been granted is never the gate's to remember: MACH keeps the ledger of grants, and the kindest question a door can ask is answered there.

Reviewers compare intended grants with actual use and hold every grant against the material failures this chapter declares; emergency access is examined apart, since its defining test, that it stayed exceptional, appears on no failure list. Exceptional access is narrow, attributable, time-bounded, and retrospectively reviewed. Uncertain identity or scope denies or contains access pending accountable review.

Interpretation cases

Take the cases one at a time, as arrivals are taken. Recognition rushed is recognition wrong, and no schedule has ever been so urgent that the gate owed it a stranger's key.

  • Conforming: Identity, grant, purpose, scope, use, delegation, revocation, recovery, and review are linked.
  • Prohibited: Authentication success creates authority or consent.
  • Boundary: Recovery restores only the smallest verified access scope.
  • Failure: Replay, stale grant, or revocation delay causes containment and evidence preservation.
  • Loophole: Emergency or delegated access becomes permanent through repeated renewal.
  • Misuse: Access records expose credentials or private identity beyond purpose.
  • Care-control: Protective access supports safety while preserving notice, agency, and review.

Design evidence

Identity review should trace proofing, authentication, grant, use, delegation, revocation, recovery, and archival events to an owner and purpose. Shared or unexplained access is a review finding even where no misuse is observed.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.