Core concepts
Identity, proofs, capabilities, sessions and authority are different contracts.
Identity
A DID names an entity. An OAS document describes verification methods and related metadata. Parsing the name or retrieving the document does not establish permission to act.
The current local path persists a real Ed25519 DID and explicitly authorized receiver trust. Its result may have a current owner root or approved self root; neither mode automatically grants operation permissions. Local identity.
Proof
A signature binds bytes to a key under a specific protocol. Challenge proofs, document proofs and ACT signatures have different signed representations. Use the appropriate canonicalization/byte contract instead of reusing a generic signing example.
The current possession envelope is {token, delegations}: JWTs binding exact audience, issued nonce and key purpose. Its replay consumption is atomic and durable. Verification. Live SVG/expressions are presentation and cannot replace that proof.
Capability
An ACT expresses an issuer's scoped grant for a subject, audience, tenant and time window. Verification requires configured trusted keys and action-specific policy. Proof-of-possession, revocation distribution and external budgets require the corresponding calling-protocol integration.
Session
A session represents bounded authenticated state for a particular server implementation. The older source-only Rust server uses JWT sessions; the published HTTP 0.1.1 adapter uses opaque stored sessions with documented limitations. Neither is interchangeable with the current possession-proof protocol by renaming a header.
Lineage and authority
Local lineage verifies document/proof relationships. Privileged authority needs the verifier's configured trusted source and required scope/freshness/revocation checks. A document cannot appoint its own trusted authority backend.
Custody and recovery
Seeds and keypairs are secret material. The actual SDK algorithm/binding determines what can be restored. Cross-language ACT conformance does not mean cross-language encryption-key equivalence.
Continue with authentication, ACT format, lineage, and key management.