14 Optional Audit Mechanism and Resident Seed Lifecycle

14.1 Scope and Trust Model

AHI is required only by services that request auditability or category-scoped uniqueness. Ordinary DID, VC and ZKP use does not require a national ID, municipality, seed, or audit service. Wallet owners choose their trust anchors. AMATELUS verifies evidence; municipalities administer resident registration; services decide authorization, benefits, account restrictions and acceptance. No nationwide seed registry or central online query per presentation is required.

The municipality is trusted to bind a resident to a seed and to preserve that binding through issuance, relocation and recovery. It can compute the AHIs of residents whose national ID and seed it holds. Anonymity from that municipality is not claimed. Learning that an AHI was used, or obtaining another service’s history, additionally requires access to those records. Warrants, access controls and disclosure procedures are operational requirements, not cryptographic gates that make unauthorized computation impossible.

14.2 Derivation and Category Scope

AHI = H(Encode("AMT-AHI-v1", categoryId, nationalID, ahiSeed))

ahiSeed is an independently generated, cryptographically random 256-bit secret. A public category and a low-entropy national ID alone do not provide resistance to candidate enumeration. Hash collision resistance does not prove anonymity or unlinkability.

Encode encodes each byte string as its byte length in canonical decimal ASCII (no leading zero except zero itself), a colon, and those exact bytes. The domain tag and field order are fixed. encodeAHIInput implements this framing in the Lean model; hash primitives remain abstract.

• A benefit event uses an authority-defined event ID; an annual benefit uses a scheme-and-year domain; a continuing service uses a stable domain.

• The same resident, category, national ID, seed and version produce the same AHI. A new event does not require a new seed or resident VC.

• Category IDs are public. The verifier supplies the expected canonical ID; the wallet cannot substitute a fresh ID to evade duplicate checks.

• Services sharing a category intentionally share a correlation domain. Different categories use different inputs, not a mathematical guarantee that hash outputs can never collide.

• Cross-municipality duplicate-benefit checks require a shared event domain and coordinated benefit records. AHI alone does not share database state.

14.3 Resident Credential

A municipality issues the initial seed at birth or first registration. The seed is a private attribute of the resident VC, not a separate mandatory VC and not a field in a publicly disclosed residence certificate.

ResidentSeedCredential (private, issuer-signed payload):
  subject, nationalID, seed, previousSeeds
  issuer, credentialRef, revocationRef
  derivationVersion = "AMT-AHI-v1"
  signature (covers the entire payload and ordered history)

The Lean type fixes version 1 through the derivation domain tag. A later version must be separately specified, signed and migrated. Secret values must not appear in public VC identifiers, logs, status URLs, status lists or ordinary presentation inputs. The issuer stores sufficient protected issuance records to recover the seed and its complete history. Random generation and secure storage are implementation obligations, not consequences of a 32-byte type alone.

14.4 Ordinary Reissue, Relocation and Lost Devices

1. Reuse the existing key-management identity verification and issuance-record lookup procedure. Changing a DID does not establish a new resident identity.

2. For relocation, the holder carries the old municipality’s resident VC. The new municipality verifies the trusted original issuance, the person’s relationship to the new key, and continuity of the resident identity.

3. Preserve the national ID, seed and ordered seed history in the newly signed credential. Regular expiration, a device change or relocation does not trigger seed rotation.

4. In a ZKP-only presentation, disclose the seed and necessary history only to the authorized receiving municipality over an authenticated encrypted channel; prove that these values belong to the same signed old credential. Bind the handover values, recipient and challenge to that proof. Do not send the complete VC as an ordinary service presentation.

5. For a lost device, restore these attributes from issuer records using the existing DID migration/reissue flow. Device loss alone is not seed exposure.

6. Handle old credentials under the issuer’s revocation and multi-device rules. Reissuance does not instantly invalidate cached offline evidence.

routine_reissue_preserves_ahi proves deterministic AHI preservation when SameSeedLineage holds. It does not prove real-world identity checks.

Initial-registration deception, including an analog relocation that hides an old registration, is handled by municipal resident administration. The protocol does not claim to detect it cryptographically. Benefits and elections combine AHI with their eligibility, recipient or electoral-roll and consumption records. The economic cost of re-registration is a risk consideration, not a theorem.

14.5 Exceptional Seed Rotation

A seed may be retained indefinitely while its secrecy, generation quality and the derivation assumptions remain adequate. Signing-key rotation and VC renewal are separate operations. Suspected seed compromise or generation defects may require seed rotation.

1. The issuer confirms continuity, issues a new seed and signs a new resident VC containing the complete previous history followed by the old current seed. A holder cannot omit that history while satisfying the proof relation.

2. Preserve ordered continuity over multiple updates. The issuer prevents conflicting successor issuance and processes old-credential revocation.

3. To a service, prove only the predecessor and successor AHIs for that service’s category. Do not reveal seeds, the whole VC, other categories or a globally shared migration identifier.

4. Atomically merge existing restrictions, received benefits and consumed rights for predecessor AHIs before activating the successor. Concurrent migration/registration must serialize on the affected lineage records.

5. A first visit after rotation still supplies the category-scoped predecessor proof. If no predecessor has a local record, register according to the normal policy; do not interpret absence of a record as absence of signed history.

rotation_preserves_predecessors proves history extension in the model. The transparent list representation has linear cost in the number of rotations. A future aggregation scheme must prove equivalent complete continuity before replacing it. Offline acceptance can still permit stale credentials; online atomicity is not a guarantee against offline double spending.

14.6 Proof Relation and Service Verification

The circuit must verify all of the following:

1. A trusted issuer signed the resident subject, national ID, seed, version, revocation reference and complete ordered history as one credential.

2. Attribute proofs and AHI refer to the same underlying subject, including an issuer-approved relationship to the presentation key. A proxy cannot use the principal’s age as its own age.

3. The derived AHI and every predecessor AHI use the expected category.

4. The proof binds the verifier, requested predicate, challenge and purpose. Separate proofs require a session-scoped common subject commitment or an equivalent composition proof, not a new permanent public identifier.

5. Original credential/delegation conditions remain in force. Each status observation retains its own authenticated time and verification state.

The Lean AHIProofRelation records this contract using an explicit resident credential verifier and the common presentation checks. Cryptographic circuit soundness and the verifier callbacks are not implemented by the record type.

verified = verifyAHIProof(proof, expectedCategory, expectedContext)
require verified.success
ahi = verified.publicInputs.ahi
predecessors = verified.publicInputs.predecessors
transaction:
  merge category-local predecessor records into ahi
  check restrictions and duplicate registration/consumption
  register or authorize using (expectedCategory, ahi)
  commit

An independent, unverified AHI argument is prohibited. Compatibility APIs must compare it exactly with the verified AHI. Constraints and transactions belong to the service database. Token issuance and audit records use that same verified value. service_request_uses_verified_ahi proves this binding; repeated_registration_rejected models the sequential uniqueness rule, not a distributed database implementation.

14.7 Verification Scope and Acceptance Criteria

The Lean model proves deterministic continuity, ordered history extension, category/context checks and field-preserving processing under explicit verifier contracts. It does not prove cryptographic unlinkability, lawful access, municipal uniqueness, physical identity or production-circuit correctness.

Implementations must reject a substituted AHI/category, mixed subjects, omitted rotation history, altered seeds and replay into another context. They must preserve AHIs after relocation/recovery, retain restrictions across multiple rotations, serialize concurrent registrations and never expose seeds in public artifacts. Audit-free presentations remain supported.

14.8 Wallet Authorization of Requested Categories

Before releasing an AHI or its predecessors, the wallet authenticates the verifier and validates a signed category-authorization credential through its own trust anchors. The authorization binds authority, verifier, category, purpose, credential reference and expiry. Signature, delegation and status checks use the existing VC trust and revocation policy. The credential may be carried locally; no national category directory or online check at every presentation is required.

walletAuthorizesCategory requires both verified authority and separate user consent. A confirmation button alone does not establish the verifier’s right to request another service’s category. prepareAHIForPresentation returns no current or historical AHI when this check fails. Context binding in the proof is still required, but does not replace wallet-side category authority. Multiple authorized verifiers may share an event category; the verifier’s DID is not added to the AHI hash. Existing seed, seed history, recovery and optional-AHI operation remain unchanged.