Human Identity vs Device Identity

1. The problem: a username and machine name are not identity

Assume a laptop named render-07 is used by two administrators. The Windows username changes, the disk is replaced, and the app is reinstalled while the organization still considers the managed node to be the same inventory object. If OS username, hostname, installation identity, and credential identity are collapsed into one identifier, the first routine lifecycle event destroys auditability. This lesson keeps those layers explicit.

2. The owned LOC-001 boundary

LOC-001 owns the human-versus-node identity contract. Tauri native commands belong to LOC-002, and capability/CSP exposure belongs to LOC-003. This lesson does not decide which webview may invoke which command. It decides where actor and node identifiers come from, which bindings make them usable for a bounded action, and which lifecycle events change those bindings.

3. Keep at least four identities distinct

Use separate fields for human_subject_id, the person; human_account_id, the account currently used by that person; node_id, the logical organizational node; and installation_id/enrollment_id, the current installation and enrollment instance. A credential_id is rotating or revocable identity material, not the node itself. Each layer therefore has an independent lifecycle.

4. What NIST establishes—and what it does not

NIST SP 800-63-4 addresses identity proofing, authentication, and federation for human users such as employees, contractors, and private individuals. That is useful authority for the human digital-identity boundary. It is not a MAKNOW device-enrollment standard and does not turn a hostname, MAC address, or one hardware attribute into sufficient node identity proof.

5. What the SPIFFE pattern adds

SPIFFE demonstrates that compute or workload identity can be distinct from human identity. A SPIFFE ID belongs to a trust domain and an SVID is a verifiable document used to present that identity. LOC-001 uses that distinction as a reference pattern only. A local desktop node is not automatically SPIFFE-compliant, and the SPIFFE model is not hardware identity proof.

6. Treat OS username and hostname as attributes

os_user=alice and hostname=render-07 are useful observations, not complete authority. A username can be renamed and a hostname can be restored or duplicated. Preserve these values beside stronger identity evidence for diagnostics and audit, but do not create a new trusted node—or revive an old credential—just because one of those labels changed or stayed the same.

7. A human account is not the human

One person may have an account renamed, disabled, replaced, or migrated. human_subject_id should preserve the person-level history while human_account_id remains a changeable binding. When Alice moves from acct-alice-01 to acct-alice-02, the node and device inventory record do not automatically change. Record the account lifecycle event rather than rewriting history.

8. A node is not an installation

A node is a logical managed identity; an installation is one software instance operating on that node. After a reimage or reinstall, node-render-07 may remain the same managed node while installation_id and enrollment_id must change. Reusing the old installation identity lets stale credentials and state cross a boundary that should have been explicit.

9. Credentials rotate and revoke independently

A credential should have an issuer, subject, expiry, and typed state. Rotation does not rename the human or rewrite the node history. Revocation does not erase previous events; it appends a lifecycle event. If an old credential is recovered from backup after reinstall, its mere presence is not evidence that it may be reused.

10. Human-to-node binding is an explicit event

When an administrator is added, removed, or replaced on a node, record a binding event with a reason and time boundary. Two administrators on one laptop should not create two device identities. Conversely, changing the assigned operator must not make the node's earlier actions look as if the new operator performed them.

11. Reinstall: preserve the node, renew enrollment

For a clean reimage where inventory evidence says the same physical managed device remains in service, the logical node can remain stable while the prior installation and enrollment end. Revoke the old credential and create a fresh installation, enrollment, and credential. This blocks the shortcut “same hostname means the previous credential is still valid.”

12. Clone collision: copied state does not create identity

If the disk image from render-07 is cloned to different hardware and the same node, installation, and credential records appear there, treat that as an identity collision rather than normal continuity. A fail-closed decision blocks use of copied identity material until the new machine is re-enrolled and the inventory conflict is reviewed.

13. Preserve typed non-success states

Identity lifecycle is not a binary pass/fail problem. A credential may be REVOKED or EXPIRED; an installation may be UNBOUND; key evidence may be UNKNOWN. Do not coerce those states into success. DEFER means that evidence is insufficient for a stronger decision, not that the node is “almost trusted.”

14. Lab: Node Identity Separation Matrix & Enrollment Record v1

lab://LOC-001/LOC001-LAB1 contains eight synthetic fixtures. For each case, record human identity state, node identity state, installation state, credential state, binding state, conflict state, decision, and reason. Cases cover a baseline, account rename, second administrator, clean reinstall, revoked credential reuse, unbound enrollment, clone collision, and reassignment. The objective is truthful lifecycle state, not forcing every fixture to PASS.

15. Transfer: reassign the device and replace its disk without erasing history

Reassign the same physical device to Carol and replace its disk. The inventory record and logical node_id may remain stable; Alice's binding ends; Carol receives a new binding; a fresh installation, enrollment, and credential are created; the previous credential stays revoked. A correct artifact preserves historical identity while clearly separating current authority from past ownership or operation.

Official sources and claim boundary

• NIST SP 800-63-4 — Digital Identity Guidelines: https://csrc.nist.gov/pubs/sp/800/63/4/final
• SPIFFE — Identity and Verifiable Identity Document: https://spiffe.io/docs/latest/spiffe-specs/spiffe-id/

K1 and K2 are sourced facts rechecked on 2026-09-17. K3 (separating node/device identity from human identity) and K4 (append-only lifecycle evidence for rotation, revocation, and re-enrollment) are MAKNOW design rules and are not presented as NIST or SPIFFE requirements.