Which digital identities should your business accept?

Every week, a bank asks me a version of the same question.

If an AI agent submits a credit card application to the bank and includes a digital credential of its owner, should it be accepted? What’s the difference between this ID and that one?

Two credentials can carry the same name and date of birth and mean very different things. One was issued after the person was verified against a federal identity standard, with documents examined, evidence validated, and the person matched to them. The other credential is simply someone’s information typed into a web form and shared with AI.

Both arrive digitally signed and cryptographically valid. A signature tells you the data hasn't been altered. It doesn't tell you whether anyone checked that the person is real.

That's the decision in front of every large organization right now. The agent delivers the credential. You still decide whether you’re willing to accept it as an ID. We explain this to our customers with three simple questions:

1. How was this person verified?

2. Can I trust this credential is authentic?

3. Does accepting this ID satisfy my regulatory obligations?

1. How did you verify this person?

If you've ever gathered documents to get a REAL ID, you've encountered the physical version of this problem. Your state issues your driver's license. A federal agency (e.g. the TSA) needs to rely on it. The federal agency needs confidence that the identity verification process that happened at every state’s DMV was secure.

The REAL ID Act established minimum security standards for state-issued licenses and identification cards. That created a common baseline for federal acceptance across different issuing states.

States previously had different policies and procedures for issuing driver’s licenses. It was easy to get an ID in some states and harder in others. REAL ID made it possible to establish a consistent basis for trusting all driver’s licenses issued by any DMV.

Digital identity needs the same discipline. A business must be able to examine how the identity was established before deciding to accept it. Before accepting an ID, every business should understand the answer to these questions:

• What identity evidence did the issuer examine?
• How did it check that the evidence was authentic and belonged to the applicant?
• What happens when the information doesn't match?

An issuer that says, "Trust us, we verified her" is just a conclusion. It says nothing about the policy behind that conclusion.

Our federal government provides a framework for this evaluation with NIST's Identity Assurance Levels. IAL2 requires evidence to validate and verify the applicant's identity. It’s an identity proofing standard not only referenced by federal agencies but increasingly incorporated into industry regulations, underwriter policies, etc.

Published verification policies make that work inspectable. But anyone can publish a policy. Ask whether or not an auditor has independently examined the service to confirm it actually follows it, what they assessed, and whether they showed continued compliance with their own policies.

Proof's Digital ID received Kantara Initiative certification against NIST SP 800-63 rev.3 at IAL2. Kantara certification is a specific, independently assessed claim about our service, which is much more reliable than another digital credential with an unexplained promise of strong identity.

This first question establishes how an identity was verified. The next question is whether you can safely rely on the credential being presented now.

2. Can I trust this credential?

A real driver's license can be copied. A properly verified person can have their account compromised. Strong enrollment doesn't remove the need to protect what happens afterward. The full credential lifecycle must be secure.

For digital identity, that means examining the keys, the systems that manage them, and the people allowed to operate those systems. You need assurances that the credentials are authentic and cannot be easily faked, copied, or issued out of policy.

A certificate authority, or CA, issues certificates that bind public keys to identities under defined policies. Proof operates its own CA, so anyone relying on a Proof credential gets a documented chain they can validate when it's presented.

How is the signing key protected? If cryptographic keys are not managed securely, anyone can create a legitimate ID and pretend to be the DMV. This would create uncertainty about every ID that was already issued; none of them could be trusted as authentic at that point. Our CA documentation describes an offline root signing key protected in an air-gapped hardware security module, a FIPS-compliant device for protecting cryptographic keys. We deploy unique technology to ensure our keys are protected and cannot be compromised.

Who is allowed to operate it? Who can authorize issuance? Who can access the systems? Which operations require more than one person, and what records are kept when someone performs them? Our Certification Practice Statement documents personnel controls, trusted roles, and multi-person controls for CA operations and certificate lifecycle procedures. Those controls address the possibility of mistakes, unauthorized access, and misuse inside our operation itself. This ensures that, even inside our organization, the cryptographic keys are safe.

Whether the credential is still “good” right now. A business also needs a way to validate that a credential is still in good standing at the time of an authorization. Strong issuance doesn’t help if a revoked credential can still be used. Proof digital IDs can be validated at the time of every transaction to confirm they haven’t been revoked or marked as fraudulent. This continuously protects both parties beyond the initial enrollment.

Who says this CA can be trusted? What independent organization has audited that all these claims are true?

Proof's WebTrust audit addresses certificate authority operations. It includes an accredited assessor's review, documented findings, an independent certification decision, and continuing QC of our controls.

Trust isn't earned through brand recognition; you can only accept an identity if independent auditors can attest to its ongoing security. When a dispute arises in front of a judge or regulator, you still have to prove you’ve fulfilled all obligations. “Trust me, I verified the person’s identity with this company” has no legal standing in court.

3. Does this satisfy my obligations?

Many industries have regulations for doing business. These are put in place to safeguard the industry from fraud. Let’s dig into an example of how a bank should think about digital identity issuers.

A bank doesn’t ask for identity data simply because it would prefer less fraud. It has regulated requirements for opening and maintaining customer relationships.

Under its Customer Identification Program, a bank needs risk-based procedures that let it form a reasonable belief about a customer's true identity. The framework also includes recordkeeping requirements.

Suppose the person later says an agent opened an account they never approved. Saying "we used a trusted brand" or "the risk score looked good" doesn't establish that you fulfilled your duties. The identity issuer’s reputation alone won't defend that decision in a lawsuit. Showing what was done proves you’ve met your obligation as a bank.

This is the point of chaining trust. You connect a requirement your business must meet to a specific control the issuer performs, then retain evidence that the control applies to the identity you accepted.

Then you can give a concrete explanation: "Our process requires these identity checks. This issuer performs them under this published policy, and this independent assessment examined those controls. We verified that this credential meets our acceptance requirements, checked the owner's signed approval, and recorded the decision before acting."

Identity is one item on a bank’s requirements checklist; it’s not the whole list. Where regulation permits reliance on an issuer’s work, an audited process shows how a bank handled that item. The bank still must meet other regulator requirements like confirming eligibility, running a sanctions screen, collecting consent, and keeping records as long as required. A strong credential doesn’t necessarily check these boxes unless it’s part of the CA policies.

No credential, brand, or trust mark guarantees a favorable outcome in a lawsuit. The protection you're building is a process supported by evidence: what you were required to do, how you did it, and what evidence you can produce when challenged.

Businesses can say ‘yes’ to a digital identity and explain why

Some identities will meet those requirements. Others will need additional verification or won't be acceptable for a specific use case or industry. This creates a basis for which identity authorities you can accept and defend it afterward. That's an identity network working as it should: any issuer can participate, and every business decides for itself who to rely on.

Proof's approach connects rigorous identity verification, CA operating controls, independent assessment, and records that work inside consequential transactions. Hold us to the same standard: show the policy, show who assessed the controls, and show the evidence supporting the action.

When an agent presents a Proof digital identity, the business should be able to trace its confidence back through all three questions: how the owner was verified, how the credential is protected, and why the evidence fits the business's obligations.

Then, businesses can accept the identity because you can substantiate the decision. Examine Proof's certificate authority and verification policies.