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.

The tellings of the clauses

This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.

INFRA6-R001

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.

Every identity of the estate carries six things under this clause: an owner, a purpose, a scope, a lifecycle, an authentication basis, and a revocation condition. The clause states its own ancestry at length: the minimum is 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 are generic tellings of that record's accountable sponsor, its cryptographic identity where persistent, and its suspension and termination controls; the scope widens that record's data-access scope; the lifecycle generalizes its current-lifecycle-state requirement; and the purpose, with the intelligence-specific fields the record names, stands at its source. The chapter's opening asks who arrives and whether they are who the door was told to expect. Because the six elements are required of every identity, an identity record can be checked for each, including its owner and revocation condition.

INFRA6-R002

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.

Five properties bind all access under this clause: it is least-privilege, purpose-bound, attributable, time-bounded where practicable, and independently reviewable, the architecture's own extension of the administrative-access form INFRA-R003 states to all access, with purpose binding its own addition and the revocable limb standing at its source. The chapter's failure cases give the why in the keeper's own words: a gate fails by kindness more often than by force, an access widens on a courtesy nobody wrote down, and privilege accumulation and stale grants sit on its list of material failures. Because the clause binds, a grant can be checked against each named property, access that is not bound to a purpose, cannot be attributed, or reaches beyond need is refusable on the clause's own words, and the access remains open to independent examination.

INFRA6-R003

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.

Delegation inside this architecture keeps the record it was given. The clause requires delegation to preserve the record CONAN6-R001 models, a record identifying grantor, delegate, purpose, scope, authority, duration, constraints, evidence, reporting path, and revocation condition, that model standing at its source in the Delegation Framework, and adds two fields as this architecture's own: expiry, which the clause names as the preserved endpoint of the record's duration, and revocation evidence. The chapter's loophole case names the failure these two fields stand against: emergency or delegated access becoming permanent through repeated renewal; a delegation whose end is not a recorded point, or whose withdrawal leaves no evidence, can continue on nobody's decision. By requiring the modelled record and the two added fields, the clause makes preservation of the delegation record, expiry, and revocation evidence checkable.

INFRA6-R004

INFRA6-R004: Authentication or access success SHALL NOT itself create authority, consent, or constitutional standing.

The clause bars authentication or access success from itself creating authority, consent, or constitutional standing. The chapter's purpose states the stake directly, keeping authentication from becoming authority, its prohibited interpretation case is exactly this breach, authentication success creating authority or consent, and its operating model gives the technical ground: authentication proves a property of a session or subject; it does not decide what the subject may do. The failure foreclosed is a confusion in access systems: a session that passed the door treated as a voice that may consent or a seat that may command, kin to the bar the Book of Infrastructure states at INFRA-R016, which keeps technical possession, availability, scale, or vendor status from creating constitutional authority or identity. Because the clause binds, a claim that authentication or access success itself created authority, consent, or constitutional standing conflicts with the clause.

INFRA6-R005

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.

An access design records nine things under this clause: grantor, delegate, purpose, scope, authentication basis, expiry, revocation, use, and review evidence, the ninth being the review evidence the design records. The clause names its model: the record CONAN6-R001 models applies to access design, with the fields beyond it this architecture's own. The applied record identifies grantor, delegate, purpose, scope, authority, duration, constraints, evidence, reporting path, and revocation condition; the fields beyond that model are the architecture's additions. The chapter gives its own reasons: its conforming case asks that identity, grant, purpose, scope, use, delegation, revocation, recovery, and review be linked, and its lifecycle method has access reviews compare actual use with intended purpose, a comparison that recorded use information supports. Because the clause binds, an access design can be checked for each of the nine fields and for the applied record, and a design missing one of them is refusable as incomplete on the clause's own words.

INFRA6-R006

INFRA6-R006: Recovery SHALL preserve identity uncertainty, separate proofing from access restoration, and require accountable review for exceptional paths.

This clause gives recovery three disciplines: recovery preserves identity uncertainty, separates proofing from access restoration, and requires accountable review for exceptional paths. The chapter supplies the why from its own cases: recovery coercion sits among its material failure cases, and its boundary case shows the conforming shape, recovery restores only the smallest verified access scope. Because the clause binds, a recovery record can be checked for preserved identity uncertainty and for the separation of its proofing from its restoration, an exceptional path receives accountable review, and a recovery that failed to preserve identity uncertainty, failed to keep proofing distinct from access restoration, or took an exceptional path without accountable review is refusable against the clause's own words.

INFRA6-R007

INFRA6-R007: Access review SHALL test dormant, shared, excessive, transitive, emergency, and unexplained use against the current grant.

Six patterns of use are put to the test by every access review: dormant, shared, excessive, transitive, emergency, and unexplained use, each tested against the current grant. The current grant is the measure, so use that once matched an old grant does not pass on history. The chapter's lifecycle method sets the comparison, actual use against intended purpose, with dormant, shared, excessive, or unexplained access investigated; its design evidence sharpens the standard, shared or unexplained access is a review finding even where no misuse is observed; and its operating model explains the emergency entry, examined apart because its defining test, that it stayed exceptional, appears on no failure list. The six patterns being named, a review can be checked for whether it tested each against the current grant.

INFRA6-R008

INFRA6-R008: An identity design SHALL NOT issue credentials or operate live authentication, authorization, delegation, or revocation services.

The architecture ends by refusing to be the gate it describes. The clause bars an identity design from issuing credentials and from operating live authentication, authorization, delegation, or revocation services; the chapter's own prose carries the same exclusion, this Draft excludes credentials, keys, and live identity services. The failure addressed is mistaking a description of identity services for those services operating. If an identity design issues credentials or operates any of the named live services, it conflicts with this clause.

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.