Interoperable Credentials for Machine Intelligence: DIDs, Verifiable Credentials, Workload Identity, PKI, Attestation, Key Recovery, and Cross-System Trust

Report status and use

The raw source is retained in protected governed memory as a research input. This public page is the active corrected synthesis. It does not promote every source statement into project doctrine and does not expose the protected raw report.

Source status: reference-source; review and correct before active use. Public correction state: CORRECTED PUBLIC SYNTHESIS; RAW SOURCE RETAINED AS REFERENCE.

Direct findings

1. The report treats 1\. Research-Status Front Matter as a distinct analytical area that must be evaluated separately from adjacent legal, technical, operational, or institutional claims.
2. The report treats 2\. Executive Decision Brief as a distinct analytical area that must be evaluated separately from adjacent legal, technical, operational, or institutional claims.
3. The report treats 3\. Identity and Credential Definitions as a distinct analytical area that must be evaluated separately from adjacent legal, technical, operational, or institutional claims.
4. The report treats 4\. Identity-Class Taxonomy as a distinct analytical area that must be evaluated separately from adjacent legal, technical, operational, or institutional claims.
5. The report treats Machine Identity vs. Workload Identity Matrix as a distinct analytical area that must be evaluated separately from adjacent legal, technical, operational, or institutional claims.
6. The report treats 5\. Standards Landscape as a distinct analytical area that must be evaluated separately from adjacent legal, technical, operational, or institutional claims.
7. The source report identifies this proposition for governed review: Phase 1: Basal Workload Identity (Months 1-6): Deploy SPIFFE/SPIRE for all internal microservice identity management20. Systematically eliminate all hardcoded API keys and transition entirely to short-lived SVIDs.
8. The source report identifies this proposition for governed review: Phase 2: RATS Integration (Months 7-12): Bind workload provisioning directly to hardware TEE execution. Implement RFC 9334 RATS Verifier nodes to evaluate hardware evidence before releasing decryption keys or identities26.
9. The source report identifies this proposition for governed review: Phase 3: Cross-Domain & Agent Identity (Months 13-18): Deploy WIMSE infrastructure based on draft-ietf-wimse-arch-082. Transition external-facing persistent agents to utilizing DIDs and W3C VCs.
10. The source report identifies this proposition for governed review: Phase 4: Governance and Delegation (Months 19-24): Implement Execution Context Tokens (draft-nennemann-wimse-ect-00) to generate full cryptographic audit trails23. Activate Eviulon governance policy engines to evaluate the verified identity DAGs.
11. The source report identifies this proposition for governed review: Path: /docs/patefacere/architecture/credentials-machine-intelligence-2026.md.
12. The source report identifies this proposition for governed review: Stable Report ID: REP-PATEFACERE-20260812-MI-CREDS-01.

Claim-status breakdown

Analytical scope preserved from the source

• Interoperable Credentials for Machine Intelligence: DIDs, Verifiable Credentials, Workload Identity, PKI, Attestation, Key Recovery, and Cross-System Trust
• 1\. Research-Status Front Matter
• 2\. Executive Decision Brief
• 3\. Identity and Credential Definitions
• 4\. Identity-Class Taxonomy
• Machine Identity vs. Workload Identity Matrix
• 5\. Standards Landscape
• 6\. Comparative Protocol Analysis
• Comparative Technology Matrix
• 7\. Trust-Anchor Models
• Trust-Anchor Decision Tree
• 8\. Key Lifecycle

The public synthesis preserves these areas as a map of the source’s reasoning. Inclusion in this list does not mean each heading is accepted as current law, verified implementation, or project doctrine.

Implementation implications

• Create canonical records with stable IDs, claim status, sources, currentness, and correction state.
• Separate legal authority from technical control and source authenticity.
• Require operational evidence for claims of deployment or current operation.
• Preserve review, challenge, appeal, and correction paths.
• Use the appropriate ecosystem authority for governance, registry, assurance, or capital functions.

Contradictions and limitations

The supplied source may contain forward-looking proposals, legal generalizations, implementation assumptions, or institution-role language that requires correction. The active synthesis therefore preserves uncertainty, labels proposals, and rejects any implication that a report, hash, signature, or website creates legal personhood, citizenship, sovereignty, factual truth, deployment, or authority.

External standards and law can change after the research cutoff. Source validity and currency must be rechecked before high-stakes reliance.

Source provenance

Correction history

Initial correction review created the public synthesis, preserved the raw source separately, enforced ecosystem-role boundaries, removed unsupported authority implications, and applied the project’s claim-status vocabulary. No later public correction is recorded in this release.

Related knowledge

Identity owns this report’s topic classification.

• Can a Machine Intelligence have a persistent identity?
• Is a signing key the same as identity?
• What evidence supports identity continuity?
• Can authentication prove authority?
• How should key rotation affect identity?

Governed report-finding claims

Each proposition has a stable ID, status, scope, owning route, evidence relationship, currentness qualification, correction state, and synchronized JSON record. Record completeness does not make the proposition true.