They usually fail where business process, legal basis, and technical scope diverge. Teams may build a verifier that can request many attributes, but the law or policy only supports a narrow use case. If registration, trust onboarding, and data-minimization controls are not aligned, the result is an integration that works technically but fails compliance review and user trust.
Where relying party integrations with a national digital ID usually break down
The failure point is rarely the cryptographic verification step by itself. More often, the integration collapses when the relying party treats a digital ID as a generic attribute source instead of a tightly scoped trust arrangement. That is where policy, consent, onboarding, assurance level, and data minimisation stop lining up with the actual business use case.
A technically sound verifier can still fail in practice if the organisation has not agreed what it is allowed to ask for, why it is asking, and who approves the trust relationship. In that sense, the “integration” problem is usually a governance and operating-model problem that happens to surface through software.
Why business process and legal basis must be designed before the API
The most common mismatch is between the business process and the legal or policy basis for the transaction. A team may want one reusable digital ID flow for onboarding, age check, address proof, and recovery, but the trust framework may only allow one narrow relying-party purpose. When the product team defines the journey first and the legal basis second, the verifier ends up over-requesting data or supporting a use case it cannot defend.
That gap also appears when registration, trust onboarding, and data retention are handled by different teams. If the relying party cannot prove why it needs each attribute, how long it keeps it, and which rule authorises the request, compliance review will fail even if the cryptography, wallet protocol, and attribute presentation all work as designed.
The Digital Identity, eID and Identity Wallets Guide is useful here because it frames the relying-party side of wallet and trust-framework integration as a policy and assurance problem, not just a protocol exercise.
Why scope creep and weak data minimisation create the most visible failures
Many implementations fail because they request more attributes than the use case actually needs. In a national digital ID flow, scope should be the first control boundary: if the business only needs to confirm eligibility, then identity assertion and one or two eligibility attributes may be enough. Requesting excess data creates avoidable privacy friction, user drop-off, and internal objections that can kill the integration after pilot.
Another frequent failure is assuming that “can verify” means “may verify.” A relying party might technically support multiple presentation requests, but each extra request expands the trust surface and raises questions about proportionality, purpose limitation, and retention. That is why data minimisation is not an optional privacy enhancement here, it is a core design constraint for adoption.
The Mobile Driving Licence (mDL) Guide helps illustrate this because mDL deployments often expose the same issue: the protocol can support rich disclosure, but the relying party still has to keep the request tightly bounded to the real transaction.
Why trust onboarding and interoperability failures show up late
Teams often underestimate how much work sits outside the verifier itself. Trust onboarding, issuer acceptance, environment separation, certificate handling, and operational support are usually where a “working” integration becomes fragile. If the relying party cannot reliably prove its identity to the ecosystem, or if onboarding criteria are ambiguous, the result is a system that passes a lab demo but stalls in live approval.
Interoperability failures are also common when organisations assume every national digital ID implementation will behave the same way. Differences in wallet behaviour, presentation policies, attribute release rules, and user experience can turn a seemingly standardised integration into a set of country-specific exceptions. At that point, integration failure is less about missing code and more about misread assumptions.
The Digital Identity, eID and Identity Wallets Guide is also relevant to onboarding and interoperability because it covers how trust frameworks and wallet ecosystems shape what a relying party can actually deploy.
Risk and Threat Considerations
When relying party scope is broader than the legal basis, the main risk is not just rejection by a policy team. The bigger exposure is that the organisation creates an integration path that appears trustworthy while quietly collecting or requesting more identity data than it can justify. That can trigger privacy complaints, audit findings, and ecosystem suspension.
Failure mechanism: The relying party designs for protocol capability first, then discovers too late that the trust framework, consent model, or purpose limitation rules do not permit the requested attribute set or transaction pattern.
Impact: The organisation may need to redesign the journey, narrow the attribute request, rework onboarding evidence, or pause deployment after investing in a technically successful but non-compliant integration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Controls which attributes or actions a relying party may request or release. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Covers external users presenting national digital ID credentials to the relying party. | |
| PT-3 — Personally Identifiable Information Processing Purposes | Directly addresses purpose limitation and minimisation for requested identity attributes. | |
| Recommendation — Enforce attribute-release rules that match the approved use case and legal basis. Validate external-user identity flows against the approved assurance and onboarding model. Document and enforce the specific purpose for every identity attribute request. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Supports minimisation, lawful handling, and review of identity data in digital ID integrations. |
| Recommendation — Review digital ID attribute collection against privacy and PII handling requirements. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Applies to trust onboarding, authentication, and access decisions in identity ecosystems. |
| Recommendation — Align relying-party onboarding and access controls to the approved identity trust model. | ||
Practitioner Guidance
What to prioritise: Start by freezing the exact use case, the minimum attribute set, and the approval path for trust onboarding. If those three are not aligned, do not treat protocol completion as readiness.
What to verify: Check that the relying party can explain, in plain terms, why each requested attribute is necessary, what business decision it supports, and what policy or legal basis permits it. If that explanation is weak, the integration is not ready for production use.
What good looks like: The relying party can complete verification, limit disclosure, and pass compliance review without changing the user journey late in the project. The most durable integrations are the ones where scope, onboarding, and retention were designed together from the start.
Practitioner takeaway: The hard part is usually not verifying a national digital ID, it is proving that the verification request itself is justified, proportionate, and supportable across business, legal, and technical ownership.