How does Digital Identity Acceptance Statement (DIAS) work?

What a DIAS decides, and why it sits between proofing and reliance

A DIAS is not a proofing method itself. It is the decision layer that tells a relying party which digital identity evidence, proofing method, or trust assertion is acceptable for a specific service, transaction, or risk tier. That makes it useful wherever onboarding, authentication, or delegated access decisions need a consistent trust rule rather than ad hoc reviewer judgement.

The practical value of a DIAS is that it converts a trust expectation into an operational standard. Instead of asking teams to interpret identity signals case by case, it states what level of assurance is required, which evidence counts, and when an exception can be accepted. In that sense it acts as a bridge between identity proofing, policy, and runtime acceptance of the identity.

A well-formed DIAS usually answers four questions: what identity or proofing route is being accepted, for what use case, under what assurance threshold, and with what supporting evidence or compensating checks. It can also distinguish between a full trust decision and a limited one, for example accepting an identity for low-risk access but not for high-risk transactions or privileged actions.

How the acceptance decision is applied in onboarding and service access

In practice, DIAS works by being referenced at the point where the organisation onboards a user, accepts an externally issued identity, or evaluates whether an existing identity is sufficient for a particular service. The statement should be written tightly enough that the implementers know what to validate, but flexibly enough that the operational team can apply it without re-litigating the original policy every time.

The statement also needs a path for exceptions. If a proofing method or identity source does not fully meet the stated acceptance criteria, the organisation must decide whether to reject it, step up the checks, or allow a bounded exception with additional controls. That is why DIAS is often most effective when it is paired with a clear evidence model, such as document checks, authoritative source checks, or higher-assurance re-verification for sensitive actions.

For teams working across national or cross-border identity schemes, the acceptance rule should be explicit about scope and interoperability. The eIDAS 2.0 framework is a useful reference point when the acceptance decision depends on recognised digital identity schemes and wallet-based trust relationships.

What makes a DIAS trustworthy in practice

A DIAS is only useful if it is grounded in verifiable trust signals. That means the organisation should be able to show why a particular identity source, wallet, or proofing method is accepted, what evidence was checked, and what residual risk remains. If those elements are vague, the statement becomes a policy slogan rather than a decision artifact.

One practical test is whether the DIAS can survive a challenge from an auditor, service owner, or risk owner. If the answer is “because we usually accept that method,” the statement is too weak. If the answer identifies the assurance level, the evidence class, the applicable use case, and the exception boundary, then the acceptance logic is much more defensible.

Where the acceptance decision depends on the quality of the identity proofing process, it is helpful to anchor the thinking in Identity Proofing and KYC Guide so the organisation is clear on what evidence, liveness, and fraud checks support the trust decision. For broader wallet and reusable identity patterns, Digital Identity, eID and Identity Wallets Guide helps frame how reusable credentials and trust frameworks affect acceptance.

Risk and Threat Considerations

DIAS becomes risky when it is too permissive, too vague, or too static. If the acceptance statement allows weak proofing methods to satisfy higher-risk transactions, attackers can exploit the gap by presenting fabricated, replayed, or low-assurance identities that still pass the organisation’s trust threshold.

Failure mechanism: The acceptance rule is misaligned with the actual sensitivity of the transaction, or it omits the evidence checks needed to detect synthetic, stolen, or replayed identity material.

Impact: The organisation may accept the wrong identity, over-trust a weak proofing path, or create a fraud route into onboarding, account recovery, or privileged access.

Practitioner Guidance

What to verify: Make sure the DIAS names the identity source, the acceptance context, the assurance threshold, and the evidence required to justify the trust decision. If any of those are implicit, the statement will be interpreted differently by different teams.

Decision rule: If the identity is being accepted for a higher-risk action than it was originally proven for, require step-up checks or a separate acceptance rule rather than reusing a lower-assurance statement unchanged.

What practitioners underestimate: The hardest part is not writing the statement, it is keeping it current as fraud patterns, proofing methods, and service risk change. A DIAS should be reviewed whenever the organisation changes onboarding flows, identity sources, or the consequences of a successful identity compromise.

Practitioner takeaway: Treat DIAS as a living trust decision, not a static policy note, and keep the acceptance rule tied to the specific transaction risk it is meant to govern.

Related resources from NHI Mgmt Group

• Digital Identity Acceptance Statement (DIAS)
• Why do digital identity and fraud prevention discussions matter so much in blockchain policy work?
• How should organisations implement interoperable digital identity acceptance without exposing unnecessary personal data?
• Who should own policy for digital credential acceptance in a customer identity programme?