Identity & trust governance Β· v1.0 Β· 2026

E-UBI Identity & Trust

Community infrastructure becomes fragile when credentials are scattered, peer trust is implicit, or identity authority drifts away from the people maintaining the node. The identity layer should define who can authenticate, who can recover, what peers are trusted for, and how compromises are contained without guesswork.

πŸ” local authority🧾 peer trust policyπŸ” key rotation🧰 recovery sharesπŸ‘₯ steward custody
Community Networking / Local Infrastructure Nodes expansion and future network systems work: Caleb Bott. This layer turns the service matrix into a concrete operating boundary by documenting identity authority, credential custody, peer enrollment, revocation, and the recovery path when trust fails or stewards change.

Federated systems still need local identity authority

A node can participate in a shared ecosystem without surrendering all account, session, and administrative power to a distant service. The practical model is local authority first: local accounts, scoped federation mappings, and explicit separation between resident access, operator access, and peer-level trust.

🏠 Local identities
site members, operator roles
β†’
πŸ”„ Scoped federation
relay mappings, peer assertions
β†’
🧭 Trust registry
approved peers, key fingerprints
β†’
🌍 Public publication
only what is meant to travel
Resident access
Local accounts or local broker
Day-to-day users should still be able to authenticate against the local node for local tools even during upstream instability.
Operator access
Separate from public-facing identity
Administrative credentials, recovery roles, and break-glass accounts should not be mixed with ordinary user sessions.
Peer trust
Named and scoped
A trusted peer might mirror packages or hold encrypted backups without gaining broad access to local records or admin controls.
Revocation model
Fast and documented
If an account, key, or peer relationship is compromised, operators should know exactly what gets disabled first and what services remain safe.

The safest secret is the one with a clear home and a clear backup path

Secrets become dangerous when copied for convenience. Credential custody should define where each secret class lives, who is allowed to retrieve it, whether a peer can hold an encrypted recovery copy, and what requires in-person or two-person access.

πŸ” Credential custody map

Identity and credential custody mapDiagram showing local vault, offline recovery media, peer escrow copies, and public services separated by trust boundaries.Local vaultadmin credentialsVPN / tunnel keysdevice enrollment materialOffline recoverysealed recovery mediaprinted contact / procedure sheetbreak-glass instructionsPeer escrowencrypted backup copiessigned public keysno routine plaintext access

The goal is not to make recovery impossible. It is to keep recovery possible without turning every trusted peer into a routine holder of local secrets.

# Example secret classes [local-admin] storage = local vault only recovery = two named stewards [service-tokens] storage = local vault recovery = rotate on restore if exposure is suspected [peer-restore-share] storage = encrypted export for approved peer recovery = decrypt only during documented restore event [public-verification-keys] storage = wide distribution allowed recovery = replace and republish if compromised

A peer should be trusted for specific jobs, not vague friendship

The clean model is explicit peer policy: what a peer may mirror, what it may verify, what it may help restore, and what it must never receive. This keeps federation cooperative without becoming an accidental single admin domain.

Enrollment
Fingerprint + contact + role
Add peers through a documented roster that records key fingerprint, host role, steward contact, and permitted lanes.
Scope
Mirror, relay, restore, verify
A peer can be trusted to mirror static assets without being trusted to relay identity assertions or hold restore material.
Verification
Signed artifacts + operator log
Important packages, snapshots, public notices, and trust updates should be signed and logged so disputes can be resolved with evidence.
Suspension
Disable first, investigate second
If trust becomes ambiguous, pause the peer relationship quickly and preserve logs rather than letting uncertainty linger during an incident.
# Example peer trust manifest [peer.region-north] fingerprint = SHA256:ABCD... roles = package-mirror, encrypted-restore-target receives = signed snapshots, public docs, release bundles denied = local admin secrets, member records, break-glass credentials [peer.region-east] fingerprint = SHA256:WXYZ... roles = relay, telemetry-rollup receives = queue events, coarse health metrics denied = restore shares until explicit approval

Rotation should be a routine, not a panic ritual

If key rotation only exists in theory, it will fail under pressure. Communities should know what rotates on schedule, what rotates after a steward departure, what rotates after a suspected compromise, and how local service continuity is preserved while that work happens.

1
Classify the event
Distinguish scheduled rotation, volunteer turnover, device loss, suspected credential leak, or confirmed hostile access. The classification drives urgency and scope.
2
Freeze risky trust lanes
Pause peer sync, outbound admin access, or exposed relays before rotating material if there is any chance the current trust state is wrong.
3
Rotate in dependency order
Start with highest-risk credentials, then service tokens, then peer trust material, then public verification outputs. Keep a written order so volunteers do not improvise under stress.
4
Re-verify peers and services
After rotation, confirm fingerprints, test essential login paths, re-check restore targets, and make sure suspended lanes are intentionally re-enabled rather than silently coming back.
5
Log the event and update custody docs
A rotation that is not documented becomes a future outage. Update the operator packet, contact sheet, and trust manifest the same day.

Recovery is credible only if a second steward can rebuild trust from documentation

The identity layer should shorten the most stressful moments: volunteer departure, suspected compromise, lost hardware, or peer dispute. That means a legible custody map, named recovery roles, enough local documentation that a new steward can restore access without becoming the next single point of failure, and clear linkage to the steward handbook and service-class runbooks that govern the response.

Volunteer departure

Revoke or rotate operator-facing credentials, review break-glass access, and confirm that no single departing steward was the only holder of critical recovery knowledge.

Lost admin device

Invalidate affected device keys quickly, preserve logs, and prefer temporary restriction of remote admin over blind trust that the device is merely misplaced.

Peer trust dispute

Move the affected peer to suspended state, preserve signed evidence, and continue local service wherever possible while the dispute is resolved through named stewards.

Site rebuild

Restore from local media and approved peer escrow, then re-establish trust relationships intentionally rather than copying every old credential forward by habit.