Actor Identity

Table of contents

Actor Identity

A compliance primitive: a verifiable binding of an action to the actor who authorized it. Each binding is an attestation with an opaque, host-allocated immutable id (no meaningful content); the action reference, actor reference, proof, and timestamp are immutable properties, set at attest time. Verification is a read-only query, not a state transition. The contract the atom enforces is non-repudiation — a verified attestation binds the named actor to the named action and the actor cannot plausibly deny it.

Intent

Regulated systems require that every action of consequence be attributable to an actor who authorized it, and that the attribution survive adversarial scrutiny — disputed transactions, regulator audits, breach investigations, court proceedings. The shape is constant across domains: at action time, the actor produces a proof (a signature, a cryptographic attestation, a witnessed approval) that binds their identity to the specific action. At verification time, anyone with access to the attestation can confirm the binding without trusting the system that recorded it.

The pattern addresses the who question that audit trails alone cannot answer. An event log records what happened; an attestation records who authorized it in a form the regulator accepts as binding. Without attestations, the audit trail is the system’s claim about who acted; with attestations, the audit trail is the actor’s own commitment to having acted.

This is a freestanding atom in the EOS (Essence of Software — Daniel Jackson’s framework for specifying software concepts as freestanding, composable units) sense. It has its own state (the attestation record), its own actions (attest, verify), and its own operational principles (proofs are immutable; verification is a read-only function of the attestation and the actor registry’s public material). It does not implement actor registration, credential lifecycle, authentication flows, authorization rules, multi-actor witness schemes, or compromise disclosure. Each is a separate composable atom; see Composition notes.

Summary

Actor Identity answers one question: “who authorized this action, and can you prove it?” It works through attestations — permanent records that tie a specific person or system to a specific action by way of a proof: a tamper-resistant artifact computed from the actor’s private credential that anyone can later check without needing the credential itself. Creating an attestation consumes the credential to produce the proof and then throws the credential away; only the proof is kept. Checking one is purely read-only: given an attestation’s identifier, the system re-checks the stored proof against the recorded action and actor, using only public information about the actor. The guarantee is non-repudiation — if the check passes, the named actor really did authorize the named action and cannot credibly deny it (short of claiming their credential was stolen). This is the mechanism behind supervisor sign-off on large wire transfers, doctors’ electronic prescriptions for controlled drugs, chip-and-PIN card payments, legally binding e-signatures, and signed code commits in regulated software — attest when the action happens, verify at audit time, and the answer comes from the records rather than from anyone’s word.

Structure

Identity model

Every attestation known to the system has an attestation_id — an opaque, immutable identifier allocated by the host id source at the I/O seam on attest (per the Logic Confinement Principle in execution-contract.md, the id is injected into the transition, not generated inside it; see Inputs and Behavior). The id is the attestation’s identity; the action reference, actor reference, proof, and timestamp are immutable properties of the attestation, not its identity.

Two attestations for the same action by the same actor have different ids — re-attestations after credential rotation, retries after partial failures, and multi-action sequences are distinct attestations with their own records. Ids are not reused.

The opaque-id model matters here for the same reason it mattered in Provisional Commitment: identifying an attestation by (action_ref, actor_ref) would collapse legitimate re-attestations, and identifying by timestamp would lose precision under concurrent attestations. Opaque ids preserve the one-attestation-one-id discipline that makes per-event audit reconstruction tractable.

Inputs

An action reference identifying what is being attested. The atom treats this as opaque — the host pattern defines what an action is and how to reference it.
An actor reference identifying who is attesting. Also opaque — the actor registry is a separate concept.
A credential — the private material the actor uses to produce the proof. The atom consumes this at attest time and never persists it.
Actions:
- attest(action_ref, actor_ref, credential) → attestation_id | rejected(invalid-request | invalid-credential | storage-failure)
- verify(attestation_id) → verified | failed-verification(proof-invalid | actor-unknown-in-registry | registry-unavailable) | not-known
A clock providing wall-time timestamps, an id source for attestation_id allocation, and the cryptographic primitive (and any entropy) the proof computation requires — all injected at the atom’s single I/O seam. Per the Logic Confinement Principle (see execution-contract.md), the host reads the clock, allocates the attestation_id, and supplies the cryptographic material at the seam, before the transition runs; the pure transition receives them as inputs and reads no clock, mints no id, and generates no randomness internally. None is supplied by the business caller (the credential remains the only caller-supplied secret) — which keeps the transition deterministic.

Outputs

The current set of attestations.
For each attestation: attestation_id, action_ref, actor_ref, attested_at, and the proof.
attest returns the new attestation_id on success, or a rejection naming the failed precondition.
verify returns verified, failed-verification(reason), or not-known. The verify call itself does not modify state.

State

A single stable state: Attested. There are no transitions out of Attested — the atom has no surface for revoking, invalidating, or modifying an attestation once it is recorded. Verification is a read-only query over the attestation’s stored fields and the actor registry’s public material. Whether a verification result changes over time — because the actor registry’s view of the actor changes (key rotation, public material updates) — is a property of the composing actor registry, not of the atom.

Each attestation carries:

attestation_id — opaque, immutable, host-allocated at the seam (see Inputs). Set on attest. Never changes.
action_ref — opaque reference to the action being attested. Set on attest. Never changes.
actor_ref — opaque reference to the actor doing the attesting. Set on attest. Never changes.
proof — the cryptographic or procedural artifact that binds actor_ref to action_ref. Set on attest. Never changes.
attested_at — wall-time when the attestation was recorded. Set on attest. Never changes.

Transitions:

attest(action_ref, actor_ref, credential) → a new attestation is recorded in Attested with the injected attestation_id, the supplied action_ref and actor_ref, the proof computed from the credential and the injected cryptographic material, and attested_at stamped from the injected clock (all read at the seam before the transition; see Inputs). Returns attestation_id.
(no other transitions)

Flow

Composing pattern initiates an action that requires attribution (attribution — the binding of an action to the actor who performed it). It calls attest(action_ref, actor_ref, credential) with the actor’s credential in hand.
Atom validates the credential and computes the proof. If the credential does not validate against the actor’s public material, the call is rejected. Otherwise the atom records the attestation and returns the id.
Time passes; the attestation persists. The host system stores the attestation_id alongside whatever it represents (the commitment record, the event log entry, the contract artifact).
An auditor, verifier, or composing pattern queries the attestation. Calls verify(attestation_id). The atom retrieves the attestation, checks the proof against action_ref and actor_ref using the actor registry’s public material, and returns the verification result.

Decision points

At attest(action_ref, actor_ref, credential) — action_ref, actor_ref, and credential must be non-null and non-empty; otherwise invalid-request. (Further structural validation of the opaque references is the composing pattern’s responsibility — the atom does not know what a valid action or actor looks like.) The credential must validate against the actor registry’s public material for actor_ref; otherwise invalid-credential. The credential is consumed, never stored. If the attestation store write fails after successful credential validation, the atom returns rejected(storage-failure) — no attestation is recorded. Durability of the attestation store is implementation-owned; see Edge cases.
At verify(attestation_id) — attestation_id must reference a recorded attestation; otherwise not-known. (This is a lookup miss, distinct from a verification failure.) The stored proof must check out against the stored action_ref and actor_ref using the actor registry’s current public material; otherwise failed-verification(proof-invalid). If the actor registry cannot return public material for actor_ref — because the actor has been deleted from the registry — the atom returns failed-verification(actor-unknown-in-registry); if the registry is unavailable, failed-verification(registry-unavailable). Both are distinct from proof-invalid (the proof exists but fails) and from not-known (the attestation id is not in the store). The verify call itself never rejects in the same sense as other action calls — verified, failed-verification, and not-known are the three legitimate outcomes, and a composing pattern should treat each distinctly.

Behavior

Observed behavior, derived from how regulated systems use attestations:

An attestation is a cryptographic or procedural artifact, not merely a logged claim. The atom is vocabulary-neutral about the mechanism (asymmetric signature, MAC — Message Authentication Code, a short tag computed over data with a shared secret — over a shared secret, smart-card-bound proof, qualified electronic signature, witnessed approval) — the contract is only that the proof verifies later from the recorded fields alone.
Verification needs no out-of-band lookup at verify time beyond the actor registry’s public material. The attestation is self-contained relative to the registry; a verifier with the attestation and the registry’s view of the actor can decide.
attest never modifies an existing attestation. It always creates a new one. Re-attesting the same action by the same actor produces a separate record with its own id — useful for credential-rotation scenarios where multiple proofs over the same action accumulate.
The credential is consumed by attest and never persisted by the atom. Credential management — storage, rotation, recovery, HSM (Hardware Security Module — a dedicated tamper-resistant device for storing keys and performing cryptographic operations) binding — is an entirely separate concept.
Time, id, and cryptographic material are injected at the seam, not generated inside the transition. Per the Logic Confinement Principle (execution-contract.md), the host reads the clock, allocates the attestation_id, and supplies the cryptographic primitive and entropy at the deployment seam before attest’s transition runs; verify’s cryptographic check likewise runs against injected primitive material. The core transition is a pure function of its caller inputs and these injected inputs — it reads no wall clock, mints no id, and improvises no crypto internally. This is the determinism the execution contract requires, and it leaves the caller signatures (attest, verify) unchanged.
verify results depend on the actor registry’s current view of actor_ref. If the registry’s public material for the actor changes (key rotation), previously-verified attestations may begin to fail verification under the new key, unless the registry maintains historical material. Whether the registry does so belongs to the registry, not the atom.
The atom does not retroactively invalidate attestations made with a credential later determined to have been compromised. That reinterpretation belongs to a Compromise Disclosure composing pattern; see Edge cases.

Feedback

Each successful action produces an observable, measurable change:

After attest — a new attestation appears in the system with a fresh attestation_id, the supplied action_ref and actor_ref, the computed proof, and attested_at. Total count increases by one. The id is returned.
After verify — no state change. The atom returns one of verified, failed-verification(reason), or not-known.

Each rejected attest action produces an observable refusal: invalid-request, invalid-credential, or storage-failure. Each verify outcome is a first-class result (not a rejection): verified, failed-verification(proof-invalid | actor-unknown-in-registry | registry-unavailable), or not-known.

The attestation set is queryable. Per-attestation fields (id, action_ref, actor_ref, attested_at, proof) are observable to auditors and operators; whether end-users see them is a presentation policy of the host system.

Invariants

The following invariants (conditions that must always hold, regardless of what sequence of actions has occurred) constitute the verification surface of the pattern:

Invariant 1 — Attestation immutability. Once recorded, an attestation’s attestation_id, action_ref, actor_ref, proof, and attested_at never change.
Invariant 2 — Action binding. For any attestation in the system, the recorded proof verifies cryptographically or procedurally against the recorded action_ref. A proof produced for a different action does not verify against this attestation.
Invariant 3 — Actor binding. For any attestation in the system, the recorded proof verifies against the recorded actor_ref using the actor registry’s public material. A proof produced by a different actor does not verify against this attestation.
Invariant 4 — Id stability. An attestation’s attestation_id is set on attest and never changes.
Invariant 5 — No id reuse. No two attestations share an attestation_id across the lifetime of the system.
Invariant 6 — Self-containment. verify(attestation_id) requires only the attestation’s stored fields and the actor registry’s public material for actor_ref. No additional out-of-band data is consulted at verify time. This holds for the atom’s design; specific credential mechanisms (X.509 certificate-based credentials requiring revocation status checks) may require additional data at verify time if revocation status is not embedded in the proof — see Certificate revocation status in Edge cases.
Invariant 7 — Verification consistency under fixed registry state. For any attestation and any fixed view of the actor registry, repeated verify calls return the same result.
Invariant 8 — Non-repudiation contract. If verify(attestation_id) returns verified, then under the assumption that the actor’s credential was not compromised at or before attested_at, the actor referenced by actor_ref authorized the action referenced by action_ref at attested_at. The contract is conditional on credential integrity; reinterpretation under compromise belongs to a Compromise Disclosure composing pattern.
Invariant 9 — Attestation durability. Once recorded, an attestation is never deleted by the atom. The attestation store’s record count is monotonically non-decreasing. The atom provides no deletion surface; cascading deletion under a retention policy is the composing pattern’s responsibility (see Tamper Evidence and Retention Window in Composition notes). An attestation_id returned by a successful attest call is durably persisted; a storage-failure rejection guarantees no partial record was written.

Action binding and actor binding together give the attribution property — the regulator’s question “who authorized this action?” has a structural answer rather than a procedural one. Attestation immutability and self-containment together give the survivability property — attestations remain verifiable independent of the system that recorded them. The non-repudiation contract names the regulatory bar the atom is built to clear.

Examples

The same atom, five regulated domains, identical mechanic.

Banking — wire transfer authorization

A teller initiates a $50,000 wire. Bank policy requires supervisor approval for wires over $10,000. The supervisor reviews and attests — attest(wire_w91, supervisor_s12, supervisor_credential) → attestation_a44. The attestation is stored alongside the wire record. Six months later, an internal auditor reviewing the day’s high-value wires queries verify(a44) and receives verified — confirming supervisor s12 authorized wire w91 at the recorded time, without trusting the teller’s account of the conversation that preceded it.

Healthcare — electronic prescription for a controlled substance

A physician writes a Schedule II prescription. DEA (US Drug Enforcement Administration) Electronic Prescriptions for Controlled Substances (EPCS) regulations require two-factor cryptographic attestation. The physician’s EHR (Electronic Health Record — the digital patient chart system) computes attest(rx_r37, dr_park, dr_park_credential) using the physician’s smart-card-bound credential and a second factor. The prescription transmits to the pharmacy with attestation_a91. The pharmacy calls verify(a91) before dispensing; verified → fill. Two years later, during a DEA audit, the same verification proves Dr. Park authorized that specific prescription on that specific date.

Payments — chip-and-PIN transaction

A cardholder taps a chip card at a terminal and enters their PIN. The card produces a cryptographic attestation: attest(transaction_t883, card_c41, card_credential). The terminal forwards the attestation with the transaction. The issuer calls verify before authorizing the charge. Months later, the cardholder disputes the charge as unauthorized; the issuer produces attestation and re-verifies. verified → the card was physically present and the correct PIN was entered, shifting liability to the cardholder per scheme rules. failed-verification → the dispute is upheld.

Legal — qualified electronic signature on a contract

Two parties sign a contract via a qualified electronic signature service. Each invokes attest(contract_c12, party_ref, qualified_signature_credential) using credentials issued by a qualified trust service provider. Two attestations are stored alongside the contract. Any future party — opposing counsel, mediator, court — invokes verify on either attestation. Under eIDAS Regulation (Electronic Identification, Authentication and Trust Services — the EU regulation governing electronic signatures and identity), qualified electronic signatures carry the same legal effect as handwritten signatures, and the verification result is admissible evidence of authorship.

Source control — signed commits in regulated software

A developer at an FDA-cleared (US Food and Drug Administration — the federal agency regulating drugs and medical devices) medical-device company pushes a commit signed with their hardware-key-backed credential. The version-control system records the attestation: attest(commit_c44a, dev_smith, smith_credential) → attestation_a17. CI infrastructure calls verify(a17) before allowing merge into the release branch. During an FDA software-of-unknown-provenance audit, the auditor walks the release branch and re-verifies every commit’s attestation. SOX (Sarbanes-Oxley Act — US financial reporting law)-scoped financial systems and Common Criteria evaluated products follow the same pattern.

The mechanic is identical across all five. What differs: the credential mechanism (smart card, software key, qualified signature instrument, hardware token, chip-card secure element), the verification frequency (every action vs. on dispute vs. on audit), the regulatory consequence of failed-verification, and the composing patterns active around it (two-factor for prescriptions, witness signatures for some legal contracts, MFA — Multi-Factor Authentication, requiring two or more independent proofs of identity — for high-value wires).

Rejection paths

verify — failed-verification(proof-invalid): An auditor reviewing a batch of wire authorizations calls verify(attestation_a17). The actor’s key has been rotated since the attestation was recorded, and the registry’s current public material for actor_ref: supervisor_s12 no longer matches the stored proof. The atom returns failed-verification(proof-invalid). The auditor notes the failure; the composing audit workflow escalates for manual review. The attestation record is unchanged — Invariant 1 prevents modification; the failure is a verification-time result, not a record defect.

verify — not-known: A composing pattern references an attestation_id that was never written (a partial-failure scenario where attest returned storage-failure and the composing pattern cached the id before confirming success). verify(attestation_a_unknown) returns not-known — the id is not in the attestation store. This is structurally distinct from failed-verification: the id does not reference any attestation. The composing pattern must treat not-known as a missing record (requiring re-attestation) rather than a verification failure.

attest — rejected(invalid-credential): A supervisor approves a high-value wire using a credential that was rotated out earlier that day. attest(wire_w55, supervisor_s12, rotated_credential) → the credential fails to validate against the registry’s current public material for supervisor_s12; the atom returns rejected(invalid-credential). No attestation is recorded — invalid-credential is a guard rejection that fails before any store write (see Decision points); the composing workflow prompts re-attestation with the current credential.

Regulated adversarial scenarios

Three scenarios the atom must survive in regulated contexts:

Regulator audit. A regulator asks “who confirmed commitment c41?” The auditor follows the commitment record to its attestation_id, calls verify, and reads actor_ref from the verified attestation. The verification is performed against stored fields and registry public material — not against developer testimony, log integrity, or system trust. Invariants 2 and 3 are the structural answer.
Disputed transaction. An actor claims they did not authorize an action. The investigator retrieves the attestation and calls verify. If verified, the proof binds the named actor to the named action at attested_at (Invariant 8). The actor cannot plausibly deny it without claiming credential compromise — an out-of-band investigation governed by a separate Compromise Disclosure pattern. If failed-verification, the dispute is upheld and the system’s record is corrected.
Compromised credential discovered. A credential is later determined to have been compromised before some date. The atom does not retroactively invalidate attestations made with that credential — Invariant 1 forbids modifying recorded attestations, and Invariant 8 is conditional on credential integrity. Reinterpretation of attestations made during the compromise window belongs to a Compromise Disclosure composing pattern, which produces new records that reframe the previously-verified attestations as untrustworthy. The atom’s attestation store remains immutable; the meaning of its records changes via composition, not via mutation.

Edge cases and explicit non-goals

What this atom does not cover:

Actor lifecycle. Actor registration, deactivation, suspension, revocation, and recovery belong to an Actor Registry / Identity Provisioning pattern. The atom takes actor_ref as opaque and consults the registry’s public material via verify.
Authentication. Login flows, session management, MFA challenge-response — these produce the credential the atom consumes. The atom does not opine on how the credential reaches attest.
Authorization. Whether the actor was permitted to take the action is a separate question from whether they authorized it. Authorization / RBAC (Role-Based Access Control — permissions granted via roles) / ABAC (Attribute-Based Access Control — permissions decided from attributes of the actor, resource, and context) is a composing pattern.
Credential management. Storage, rotation, recovery, HSM-binding, biometric protection — implementation concepts. The atom never persists the credential.
Multi-actor attestation. Witness signatures, m-of-n approvals, co-signed contracts, dual-control workflows — each attest call records one actor’s binding. Multi-actor schemes compose with a Witness / Co-signature pattern.
Retroactive credential revocation. As discussed above, attestations are immutable; reinterpretation under compromise belongs to Compromise Disclosure.
Tamper-evidence on the attestation store. The bare atom assumes the attestation store has not been rewritten by an adversary with write access. Cryptographic hash chains, Merkle trees, and timestamp-authority anchoring belong to a Tamper Evidence composing pattern. (Many credential mechanisms — qualified signatures, blockchain-anchored attestations — provide tamper-evidence as a side effect; the atom does not require it but composes naturally with it.)
Time-of-attestation veracity. attested_at is stamped from the injected clock at the seam (see Inputs and Behavior); clock access is confined to the seam, but clock quality — whether that clock is honest, monotonic, or synchronized — is handled at the deployment layer. Trusted timestamping (RFC 3161 — the Internet standard, “Request for Comments” document 3161, defining a trusted time-stamping protocol) is a composing pattern that supplies a verifiable time-anchor.
Action-content immutability. The atom binds action_ref, not action content. If the action’s content can be mutated after attestation (an editable document, a modifiable transaction record), the binding loses meaning. The host pattern is responsible for either binding to immutable content (e.g., a content hash) or composing with a Content Lock pattern.
Cross-system identity portability. actor_ref is opaque to the atom; portability across trust domains (federated identity, cross-organizational verification) belongs to an Identity Federation pattern.
Group attestations, pseudonyms, anonymous credentials. Single actor reference per attestation. Group signatures, ring signatures, and selective-disclosure credentials are separate concepts.
Verification result caching. verify is read-only and idempotent under fixed registry state, but the atom does not specify whether implementations may cache the result. Caching is implementation policy; a stale cache under a registry change is handled at the deployment layer.
Certificate revocation status. For attestations using X.509 (the standard format for public-key certificates) certificate-based credentials, verification may require determining whether the certificate was revoked at or before attested_at. OCSP (Online Certificate Status Protocol — a way to check in real time whether a certificate has been revoked) stapling embeds the revocation status proof in the credential mechanism and keeps verification self-contained (satisfying Invariant 6); without stapling, the verifier must query a live OCSP responder or CRL (Certificate Revocation List — a published list of revoked certificates) distribution point, which introduces an out-of-band dependency that weakens Invariant 6. Short-lived certificates that expire before revocation is likely also satisfy self-containment. The credential mechanism choice — stapling, live revocation check, or short-lived certificates — is handled at the deployment layer; the atom’s self-containment invariant holds for mechanisms that embed revocation status in the proof and must be noted as conditional for mechanisms that rely on external revocation services at verify time.
Attestation store durability. attest writes a new record as a single atomic operation; a write failure after credential validation returns rejected(storage-failure) with no partial record in the store. Durability across crashes, replication lag, and storage-engine failure is implementation-owned. High-assurance deployments should compose with a Write-Ahead Log or equivalent mechanism to ensure that a storage-failure response and the absence of a persisted record are consistent.

Where the atom breaks down: when authorization cannot be reduced to a single actor (truly anonymous attestation in regulated contexts is a contradiction in terms); when the credential mechanism cannot produce a verifiable proof (shared secrets where anyone with the secret could forge an attestation); when the host environment has no actor registry the verifier can consult.

Composition notes

Actor Identity is freestanding and is the non-repudiation contract that several other atoms reference:

Provisional Commitment — every place_hold, confirm, release, and expire produces an attestation; the commitment’s audit trail includes attestation_ids alongside per-transition timestamps. This is the non-repudiation composition Provisional Commitment’s Lineage notes anticipated.
Event Log — every appended event carries an attestation_id in its payload (or as a structured sidecar); readers verify before trusting the recorded actor field. Event Log’s existing edge case naming Actor Identity as forthcoming is now resolved by this atom.
Permissions — every grant and revoke is paired atomically with an attestation under the issuing actor’s credential; the records alone answer “who granted this access, when, and under what credential?” The Attributed Permissions Admin composition is the formalization of this wiring, with eight emergent invariants (attribution completeness, revocation attribution, attestation-time monotonicity, attestation exclusivity, orphan-log durability, and more) and a dynamic Alloy (a formal modeling language for checking structural and temporal properties of a design) trace model verifying its temporal claims. This is the bottom rung on which Authorization / RBAC and Delegation compose without re-inventing the attribution surface.
Actor Registry / Identity Provisioning (forthcoming) — supplies the public material verify consults and the actor lifecycle (registration, key rotation, suspension, revocation).
Credential — produces the credential the atom consumes. Credential answers “did the right material arrive?”; Actor Identity answers “who authorized this action and can you prove it?” The two atoms are distinct freestanding atoms sharing the same principal_ref / actor_ref namespace. Their relationship — cascade on revocation, permitted interchangeability of secret material, audit identity unification — is owned by the Authenticated Actor composition. See demos/attributed-permissions-admin/CORNERS.md §Cross-atom identity surface aliasing for the implementation-discovered gap that surfaces the need for that composition.
Authenticated Actor — wires Credential and Actor Identity under a single principal, owning the three invariants neither atom currently specifies: revocation cascade, secret surface separation, and principal_ref / actor_ref namespace binding.
Authorization / RBAC (forthcoming) — combines what an actor can do with what they did do. Attestation answers the second; authorization answers the first.
Compromise Disclosure (forthcoming) — handles retroactive credential invalidation by producing reinterpretation records, never by mutating the attestation store.
Witness / Co-signature (forthcoming) — multi-actor attestations (m-of-n approval, dual control, qualified witness signatures).
Tamper Evidence — cryptographic chaining (or Merkle-tree commitment, or external anchoring) of the attestation store, so that any rewrite of recorded attestations is detectable from the records alone.
Trusted Timestamping (forthcoming, per RFC 3161) — verifiable time-anchor for attested_at.

The canonical regulated-audit stack composes Event Log + Actor Identity + Retention Window + Tamper Evidence as four freestanding atoms; the Audit Trail composition is the wiring.

Standards references

Actor Identity is a foundational compliance primitive with deep regulatory anchoring:

NIST (National Institute of Standards and Technology — US federal standards body) SP 800-63-3 (Digital Identity Guidelines) — Identity Assurance Levels (IAL), Authenticator Assurance Levels (AAL), Federation Assurance Levels (FAL) — graded measures of how strongly identity, authentication, and federation are established. The atom’s credential-consumed-not-stored discipline and verification self-containment correspond to NIST’s authenticator and verifier requirements.
eIDAS Regulation (EU 910/2014) — qualified, advanced, and basic electronic signatures. Qualified electronic signatures carry the same legal effect as handwritten signatures across the EU; the atom’s non-repudiation contract is the operational form.
FIPS 186-4 / FIPS 186-5 (Federal Information Processing Standards — mandatory US government computing standards; here the Digital Signature Standard) — cryptographic foundation for asymmetric attestation. The atom is mechanism-neutral but FIPS 186 is the canonical credential-mechanism anchor.
ISO/IEC 27001 §A.9 (Access Control) and §A.12.4 (Logging and Monitoring) — the International Organization for Standardization / International Electrotechnical Commission information-security standard; actor attribution as an access-control and audit requirement.
21 CFR (Code of Federal Regulations — the codification of US federal agency rules) Part 11 (FDA Electronic Records and Electronic Signatures) — for healthcare, pharmaceuticals, and medical devices: requires electronic signatures to be uniquely attributable to one individual, with cryptographic or procedural binding that resists repudiation.
HIPAA (US Health Insurance Portability and Accountability Act) §164.312(d) (Person or Entity Authentication) — verification that a person or entity seeking access is the one claimed.
DEA EPCS (21 CFR §1311) — Electronic Prescriptions for Controlled Substances: two-factor cryptographic attestation requirements.
GDPR (EU General Data Protection Regulation) Article 32 (Security of Processing) — names “ensuring the ongoing confidentiality, integrity, availability and resilience of processing systems and services”; non-repudiation is a recognized security property under Article 32’s scope.
Sarbanes-Oxley §302 and §404 — officer certifications and internal control over financial reporting. Authenticated attestations on financial-system changes are §302 / §404 evidence.
PCI DSS (Payment Card Industry Data Security Standard — the card networks’ mandatory security rules for handling cardholder data) Requirement 8 (Identify and Authenticate Access) — for payment systems handling cardholder data.

It inherits from:

Daniel Jackson, The Essence of Software — the freestanding-atom posture; the discipline of composing authentication, authorization, registry, witness, and compromise concepts as separate atoms.
Eiffel’s design-by-contract — preconditions on attest; named rejection and verification reasons.
Public-key cryptography literature (Diffie-Hellman, RSA — Rivest-Shamir-Adleman, ECDSA — Elliptic Curve Digital Signature Algorithm, EdDSA — Edwards-curve Digital Signature Algorithm; standard digital-signature schemes) — the foundational mechanism for verifiable proofs of authorship.
Non-repudiation literature in computer security (Zhou and Gollmann, ISO/IEC 13888) — the formal framing of non-repudiation services as distinct from authentication.

Generation acceptance

A derived implementation of Actor Identity is acceptable — in the regulator-acceptance sense — when an external auditor, given the attestation store plus the composing actor registry’s public material, can do all of the following without recourse to source code, runbooks, or developer narration:

Reconstruct any attestation from its stored fields. attestation_id, action_ref, actor_ref, proof, attested_at are sufficient for the verifier; no additional state is consulted at verify time beyond the registry’s public material.
Verify each attestation independently. verify is a function of the attestation and the registry’s current view of the actor. The auditor can run verification themselves with no privileged access beyond the public material.
Confirm action binding and actor binding. The proof verifies against the recorded action_ref and actor_ref, and only against those (Invariants 2 and 3).
Distinguish the three verify outcomes. verified, failed-verification(reason), and not-known are observable as distinct first-class results, not collapsed into a single boolean.
Identify the composing patterns active in this deployment. Whether actor registry, authentication mechanism, witness scheme, compromise disclosure, tamper evidence, and trusted timestamping are wired in, with what configuration.

This is the generator’s contract: any code generated from this atom must produce attestations and a verification surface that pass the five checks above. The bar is the regulator’s question — “can you prove who authorized this action?” — not the developer’s intuition.

Status

grounded on Final Critique 4 — 2026-06-18 (Final Critique 4 — the first AI-conducted adversarial round, fresh-reader Opus, 2026-06-18 — closed three foundational logic-confinement findings: clock, cryptographic material, and attestation_id are now host-injected at the I/O seam rather than generated inside the attest transition; caller signatures unchanged; see Lineage. Formal-layer vote is NO, 2026-06-03 — English-only, minimum-formalism. The pattern was grandfathered at the legacy grounded — 2026-05-20 token until this round.) — all required structural elements resolved; identity model explicit; attest and verify action signatures with fully-named rejection and outcome reasons; nine invariants including attestation durability (Invariant 9); five cross-domain examples spanning banking, healthcare, payments, legal, and source control, plus an attest rejection-path example; regulated adversarial scenarios cover regulator audit, disputed transaction, and compromised credential; fifteen edge cases including certificate revocation status and attestation store durability. First entry in compliance.

Lineage notes

This atom survived all three pressure-testing passes (see pressure-testing.md) on its first iteration.

Conventions inherited from prior work. This atom is the second regulated atom in the library and was drafted with the two conventions Provisional Commitment first introduced — Regulated adversarial scenarios as an examples subsection and Generation acceptance as a standalone section — baked in from the first draft rather than added in a second iteration. (Both conventions have since been promoted to canonical status in contributing.md and pressure-testing.md; patterns drafted after this one inherit from the methodology directly rather than from any specific predecessor.) This atom is also the first to resolve a forthcoming-link that another published atom (Provisional Commitment) named; the existence of Actor Identity converts Provisional Commitment’s (forthcoming) markers into resolved cross-references.

Pass 1 — Structural completeness (GRID — the nine-node completeness framework: Intent, System, Friction, Flow, Decision, Feedback, State, Behavior, Proof). Clean. The State node is unusually small (one stable state, Attested, and no transitions out) — early drafts considered modeling Attestation → Revoked or Attestation → Superseded but both were caught by Pass 2 as over-absorption (revocation belongs to the actor registry; superseding belongs to a re-attestation that produces a separate record). All nine GRID nodes resolved with their references intact, including a small but meaningful one: verify is captured under Decision points with its three first-class outcomes rather than forced into the success-or-rejection mold the other atoms use.

Pass 2 — Conceptual independence (EOS). Clean. Seven concerns were candidates for absorption and all seven are correctly named as composing patterns rather than folded in:

Actor registration and lifecycle — generic across every system with identified actors. Composes with Actor Registry / Identity Provisioning.
Authentication flows — generic across every system requiring login. Composes with an Authentication pattern.
Authorization rules — generic across every system distinguishing what an actor can do from what they did. Composes with Authorization / RBAC.
Multi-actor attestation — recurs in any high-stakes regulated context. Composes with Witness / Co-signature.
Compromise disclosure — recurs across every cryptographic system. Composes with Compromise Disclosure.
Tamper-evidence on the attestation store — recurs across every regulated record. Composes with Tamper Evidence.
Trusted timestamping — recurs whenever the time of action matters to the verifier. Composes with Trusted Timestamping.

The temptation to absorb authentication into Actor Identity was the strongest of these — both concern who is acting — but the distinction matters: authentication answers “is this caller the actor they claim to be, right now?” and produces a credential; attestation answers “can a future verifier confirm this actor authorized this action?” and consumes the credential. Different state machines, different verification surfaces, different lifecycle. Keeping them separate is what makes Authentication composable with non-attestation actions and Actor Identity composable with non-interactive verification.

Pass 3 — Adversarial scrutiny (Linus mode). Four findings, all closed in-pattern:

verify return shape. Early drafts had verify(id) → ok | rejected(reason), which collapsed the lookup-miss case (not-known) with verification failure (proof-invalid). Resolved: three first-class outcomes — verified, failed-verification(reason), not-known. Decision points names them explicitly and Behavior cautions composing patterns to treat them distinctly.
Credential storage. The first draft was silent on whether the atom persisted the credential. Resolved: explicit credential is consumed by attest and never persisted in Inputs, Behavior, and the Edge cases entry on credential management. The atom takes a credential as input; the atom does not become a credential store.
Verification result drift under registry change. The first draft asserted verify is idempotent. Resolved: Invariant 7 is qualified as under fixed registry state; Behavior explicitly names that registry changes (key rotation, public material updates) may change verification results, and that historical-material retention is the registry’s concern, not the atom’s.
Non-repudiation contract preconditions. The first draft’s Invariant 8 read as unconditional — if verified, the actor authorized the action. Resolved: the contract is explicitly conditional on credential integrity, with reinterpretation under compromise deferred to Compromise Disclosure. The conditional framing matches what cryptography literature actually claims and what regulators actually accept.

Three deferred concerns are named as explicit out-of-scope rather than fixed in-pattern: time-of-attestation veracity (clock semantics), action-content immutability (host pattern’s responsibility), and verification result caching (implementation policy).

The three passes together exercise the architecture as designed: GRID catches structural completeness (the single-state model is small but complete, with verify under Decision points); EOS catches the seven over-absorption temptations; Linus catches the four hidden decisions (verify outcomes, credential storage, registry drift, contract preconditions). The atom is stronger because all three checks happened.

Refinement round 1 — re-run of all three passes. Six findings, all closed in-pattern:

Action signature incompleteness — attest (Pass 1 / Pass 3). The Inputs signature used rejected(reason) while the actual reasons (invalid-request, invalid-credential) were only named in the Feedback section. A reader of the Inputs section alone could not enumerate the rejection vocabulary. Resolved: Inputs signature updated to rejected(invalid-request | invalid-credential | storage-failure); storage-failure added as a new named reason (see next finding).
Persistence failure during attest unnamed (Pass 3). If the credential validates and proof is computed but the store write fails, the atom had no named outcome for this. The credential is consumed; a retry would require a fresh credential. Resolved: storage-failure added as a rejection reason; Decision points updated to specify that storage-failure leaves no partial record; new edge case (Attestation store durability) specifies the consistency guarantee.
verify failure taxonomy incomplete (Pass 3). Only proof-invalid was named for failed-verification(reason). Registry unavailability and actor deletion are real failure modes with different operational meaning — registry unavailable is transient and retryable; actor unknown in registry may be permanent. Resolved: failed-verification(proof-invalid | actor-unknown-in-registry | registry-unavailable) in both Inputs and Feedback; Decision points updated with explicit descriptions of each.
“Well-formed” for opaque refs undefined (Pass 3). Decision points said action_ref and actor_ref “must be well-formed” without defining what that means for opaque inputs. Resolved: “well-formed” replaced with “non-null and non-empty” as the atom’s minimum constraint, with a note that further structural validation is the composing pattern’s responsibility.
Certificate revocation status (Pass 3). Invariant 6 (self-containment) claims verify requires only stored fields and registry public material. For X.509-based credentials, OCSP revocation status may be required at verify time unless stapling embeds it in the proof — a real out-of-band dependency that Invariant 6 did not address. Resolved: Invariant 6 updated with a caveat referencing the new Certificate revocation status edge case; new edge case names OCSP stapling, live OCSP, and short-lived certificates as the resolution options and defers the mechanism choice to deployment.
No attestation durability invariant (Pass 3). The State section’s single-state model implied records are permanent but no formal invariant stated it. The atom’s design provides no deletion surface — this is a structural guarantee worth formalizing, analogous to Notification’s Invariant 9 added in its second pass. Resolved: Invariant 9 (Attestation durability) added; it names the monotonically non-decreasing record count, the absence of a deletion surface, and the consistency guarantee between storage-failure responses and the absence of partial records.

Pass 2 was clean: no new over-absorptions surfaced. All six fixes are in-pattern resolutions or new edge-case entries.

Scheduled rescan: 2026-05-20. Pass 1 clean. Pass 2 clean. Pass 3 surfaced one refining finding: the main Examples section contained five domain examples showing only successful attest + verify → verified paths; no concrete example showed verify → failed-verification or verify → not-known. The regulated adversarial scenarios section covered the adversarial paths conceptually (disputed transaction and compromised credential), but without a concrete action-call-and-result walkthrough of the failure outcomes. Resolved: two rejection-path examples added to the Examples section — verify → failed-verification(proof-invalid) (key rotation scenario) and verify → not-known (missing attestation id from a storage-failure scenario). No foundational findings. Status date updated to 2026-05-20.

Formal-layer vote — 2026-06-03: NO. Invariants are single-state immutability and a monotonically non-decreasing attestation store; verify is a pure query with no state transitions, concurrency, or ordering-across-sequences surface. Grounds English-only (minimum-formalism). Vote per pressure-testing.md §Formal models — The formal-layer vote.

AI adversarial round — Final Critique 4 (first real AI round) — 2026-06-18. This atom grounded 2026-05-20 under the early process — one foundation pass plus one refinement round, with Pass 3 “Linus mode” author-conducted and no fresh-reader AI adversarial round — and carried the legacy grounded — 2026-05-20 token (grandfathered). This round is that missing AI-conducted adversarial round, run by a fresh-reader Opus (Happy-Torvalds-X2); it is the atom’s Final Critique 4 (Rounds 1–3 being the foundation/refinement baseline, per pressure-testing.md §Round structure). Three foundational findings, all the same root — the atom predated the Logic Confinement Principle and described time, identity, and cryptographic material as generated inside the attest transition — all closed in-pattern by adopting the corpus-canonical host-injected-at-seam formulation (as in Session and Capability):

F4-1 — clock. attested_at = now / “implicit clock” → the clock is injected at the I/O seam and attested_at is stamped from it before the transition runs (Inputs, State transition, Edge cases Time-of-attestation veracity).
F4-2 — cryptographic material. The proof was “computed from the credential” with no seam declaration → the cryptographic primitive and any entropy are deployment-supplied at the seam, verify’s check runs against injected primitive material, and the core transition improvises no crypto (Inputs, new Behavior bullet).
F4-3 — attestation_id. “system-generated … produced by attest” (minted in-transition) → allocated by the host id source at the seam and injected (Identity model, State, blockquote).

The caller signatures attest(action_ref, actor_ref, credential) and verify(attestation_id) are unchanged — time/id/crypto are host-injected, not caller-supplied. The confinement commitment is pinned in a Behavior bullet rather than a new numbered invariant, so the invariant set stays at nine and dependents’ “Actor Identity invariants (1–9)” references (Authenticated Actor, Audit Trail) remain accurate. Refining/rhetorical folded: an attest → rejected(invalid-credential) rejection-path example; the Time-of-attestation veracity edge case reworded to the access-confined / quality-deployment distinction; “system-generated” → “host-allocated” throughout.

Confirming fresh-reader Opus clearance gate (2026-06-18): CLEAR, 0 foundational — all three fixes verified genuinely closed against the canonical reference atoms and the execution contract, caller signatures and invariant numbering confirmed stable at all wrap sites, no new surface. Compositions affected — confirming check only, NOT a re-pass (signatures, invariant set/numbering, states, and transitions all stable): Authenticated Actor, Actor Suspension, Audit Trail, Attributed Permissions Admin, Reservation Lifecycle, and the patterns reached through Audit Trail. Grounds at Final Critique 4.