The suite · Identity
Who the agent is. Separated, on purpose, from what it may do.
Identity questions and authorization questions decay at different speeds. “Is this agent who it claims to be?” is true for minutes and should be re-proven constantly. “Was this payment inside the mandate?” must survive an audit years later. Systems that answer both with one credential fail at both. Fidacy keeps them apart: identity is an INPUT to the verdict, never the verdict itself.
Identity by public key, never by shared secret
An agent identifies itself with a key it can prove possession of. Fidacy resolves did:web and SPIFFE identities, verifies the proof, and scores what it found. No API-key-as-identity, no secret that a leaked log turns into an agent.
the strength ladder the engine applies; every verdict carries the result, readable on the console's transaction detail
The split the ecosystem already agreed to
On the Universal Commerce Protocol threads, the emerging standard treats identity and transaction risk as separate attestations from separate issuers: short-lived identity credentials from identity providers, session-scoped risk verdicts from a neutral non-party. We co-built the attestation envelope that carries both, ran the first cross-issuer verification on record, and published the specs. An agent can carry a partner's identity claim and a Fidacy verdict side by side, each verifiable alone.
Why the separation matters commercially: an insurer, auditor or counterparty six months from now does not ask who the agent was. They ask what it did and whether it was authorized. Identity answers the first question and expires; the signed verdict and its Bitcoin-anchored trail answer the second, forever.