Verifiable identity, as used here, means an identity claim that can be checked against appropriate evidence. A familiar name, logo or interface is a claim; it is not the evidence. What a personal account, a business service and a software agent must prove can be very different. Establishing an identity also does not decide what that participant may do.
A useful identity review connects three questions: what is being claimed, what evidence supports it, and which decision that evidence helps you make.
Start with the decision
| Review | What the evidence establishes |
|---|---|
| Evidence |
A government document, an enrolled device key and a server certificate answer different questions. The first may be part of identity proofing; the others can demonstrate control of a credential or an endpoint. Their conclusions should not be silently exchanged. |
| Permission |
NIST’s identity-proofing guidance separates proofing from later account authentication. Authorization adds another decision: may this authenticated participant perform this operation? A real identity can still request something outside its authority. |
People, services, devices and agents
A person’s legal identity is different from an account identifier or a pseudonym. Collect legal-identity evidence only when the service has a justified need. A domain is also different from the business that operates it; an encrypted connection does not decide that business’s trustworthiness.
For a device, identify the enrolled credential, who can activate it, and how loss or replacement is handled. For an agent, identify its owner, workload identity, permitted tools and current task. Asking software to prepare a report should not grant it every permission of the person who asked.
A credential is not an entire trust decision
W3C Verifiable Credentials Data Model 2.0 describes a specific issuer–holder–verifier model. The broad phrase in this article does not imply that Identité implements that standard, verifies government documents or provides KYC.
Mutual authentication is an established model of parties authenticating each other. WebAuthn scopes credentials to a relying party and validates the authentication context. Those protocol properties deserve recognition; they are distinct from a person deciding whether to approve a payment.
Where Identité fits
The published Full Duplex Authentication® flow describes an enrolled app checking its configured authentication-server relationship. The integration connects that server with the requesting application; the person reviews the expected request and its comparison cues.
PasswordFree® brings that foundation to customer registration and return. NoPass™ brings it to workforce access and supported approval checkpoints. Start with the people, application and recovery journey you want to improve, then evaluate the integration that fits.
Evaluate one workflow
-
Choose a returning-account or held-operation workflow. Name the participant, the evidence, the trusted reference and the decision that relies on each. Record who enrolls, recovers and revokes the authenticator, and which application owns permissions and execution.
-
Then test unexpected requests, decline, expiry, unavailable devices and changed operation details. For a sensitive action, demonstrate what correlates approval with the held operation. A reassuring screen does not prove that every field is cryptographically signed.
Use the sensitive-action integration checklist and the distinction developed in One AUTH Is Not Enough to separate evidence about identity from permission to act.
Questions worth asking
Must every service know a legal identity? No: choose evidence proportionate to the decision. Does an authenticated account establish trust forever? No: permissions, session protection, recovery and incident response remain part of the system. Can generic agent identity or continuous monitoring be inferred from FDA? No: those need separate implementation and evidence.