Why does Switzerland require public registration of data requests before a business can use the e-ID as a relying party?

Why public registration changes the behaviour of a relying party

Switzerland is not just asking a business to accept e-ID assertions, it is asking it to become a relying party that can be scrutinised. Public registration turns the verifier’s data request into a declared act, not a private implementation detail. That matters because the actual privacy risk is often not the login itself, but the quiet drift from “needed to verify” into “collecting because it is available.”

For a relying party, the registration step creates a baseline that can be compared against the live request path. If the business later asks for more attributes, expands the use case, or changes the purpose in practice, that deviation is visible. This is especially important in identity systems where the same technical mechanism can support very different business outcomes, from simple age checks to broader profiling.

The design also helps separate trust in the e-ID from trust in the verifier. The credential may be legitimate, but the relying party still needs to justify why it needs each attribute and what it will do with it. Public registration makes that justification part of the system boundary rather than a promise buried in policy text.

Why the rule matters for data minimisation and purpose control

The core security and privacy effect is restraint. A verifier that must declare requested data and purpose in advance has less room to expand collection opportunistically. That is a practical control against excessive disclosure, because it ties attribute access to a stated business purpose instead of letting the request logic silently evolve.

This also improves accountability across the full lifecycle of the relying party. Users, auditors, and regulators can compare the public declaration with the actual request behaviour, which makes challenge and review possible. In practice, that means the rule is doing governance work as well as privacy work: it creates a reference point for consent, proportionality, and later dispute handling.

For businesses, the main implication is that “what we ask for” becomes part of the compliance surface. If the declared purpose is narrow, internal teams cannot treat broader data access as an implementation convenience. If the purpose changes, the registration record should change with it, otherwise the mismatch itself becomes a control failure.

What users and regulators gain when requests are public

Public registration gives external parties a concrete artefact to inspect. That matters because many identity abuse patterns depend on opacity, where an organisation asks for more attributes than the user can realistically evaluate at the point of request. Registration reduces that asymmetry by making the scope of collection legible before data is exchanged.

It also creates a stronger basis for enforcement. If a verifier asks for more than the stated purpose supports, the issue is no longer only “bad practice,” it is a traceable divergence from the published relying-party profile. That makes escalation simpler, because the evidence is in the declared request rather than inferred after the fact.

For the user, the practical value is not abstract transparency. It is the ability to compare a request against a known purpose and decide whether the request is proportionate. For the regulator, it creates a searchable catalogue of who is asking for what, which is far more useful than trying to reconstruct request logic after complaints start.

Risk and Threat Considerations

The main risk is silent scope creep: once a verifier is technically able to request attributes, it may gradually ask for more than the original service need justified. In identity systems, that kind of drift is hard to detect after the fact because the same request path can look routine even when the purpose has expanded.

Failure mechanism: a relying party introduces broader attribute requests, reuses the same registration for a new purpose, or changes the live request flow without updating the declared purpose. That breaks the comparison point that makes overreach visible and undermines user and regulator review.

Impact: unnecessary disclosure, weaker purpose limitation, and a higher chance that users cannot meaningfully judge whether the request is proportionate. It also creates a governance gap, because the organisation’s public declaration no longer matches its actual data collection behaviour.

Practitioner Guidance

What to verify: treat the registered purpose and attribute set as the control baseline. If product teams want new fields, new reuse, or a different verifier workflow, require a review of whether the public registration still describes reality.

What good looks like: the live e-ID request, the published relying-party declaration, and the internal business justification should all match closely enough that a reviewer can see why each attribute is needed. If they do not, the mismatch is the issue to fix, not a paperwork detail.

Common mistake: treating registration as a one-time onboarding step. In practice, it is a change-control mechanism for data requests, so it needs the same discipline you would apply to any other externally visible access boundary.

Practitioner takeaway: the value of public registration is not administrative visibility for its own sake, it is that it makes data collection testable against a declared purpose, which is what prevents quiet expansion of access.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• How should security teams make NHI best practices usable across the business?
• How should security teams use IAST and RASP in NHI governance?
• What breaks when employees use shadow SaaS for business data?