Skip to content

Overasking Protection

Problem Statement

A fundamental concern in digital identity ecosystems is overasking — when a Relying Party (RP) requests more personal data than necessary for its service. This creates several risks:

  • Privacy violation: Users may unknowingly share more data than needed
  • Data minimization breach: GDPR requires collection of only necessary data
  • Trust erosion: Users lose confidence if they feel exploited
  • Accidental disclosure: Users may approve requests without fully understanding what they're sharing

Without technical safeguards, users must rely solely on their own judgment to assess whether a data request is proportionate — a burden that is unreasonable given the complexity of digital services.

Overasking Scenario

A cinema ticket website requests not only proof of age (required for age-restricted films) but also the user's full name, address, and nationality. The user, eager to complete their purchase, approves the request without noticing the excessive data collection.

Regulatory Foundation

eIDAS 2.0 Requirements

The eIDAS 2.0 regulation explicitly addresses overasking through Article 5b, which requires:

  1. Registration of intended use: RPs must declare in advance which attributes they intend to request and for what purpose
  2. Purpose limitation: Requests must be limited to data necessary for the declared purpose
  3. Transparency: Users must be informed about who is requesting data and why

GDPR Alignment

The overasking protection mechanism supports GDPR principles:

GDPR Principle How Overasking Protection Helps
Data minimization Technical enforcement of "only necessary data"
Purpose limitation Requests tied to declared, registered purposes
Transparency Users see exactly what is requested vs. what is declared
Accountability Registered intended use creates auditable record

How Overasking Protection Works

Step 1: RP Registers Intended Use

Before an RP can request credentials from Wallets, it must register at a national Registrar. This registration includes:

Intended Use Declaration

Field Value
Purpose (EN) Age verification for alcohol purchase
Purpose (DE) Altersverifikation für Alkoholkauf
Credentials PID
Attributes age_over_18 (boolean)

Purpose can be provided in multiple languages for display to users.

What the Registrar Does and Does Not Validate

The Registrar validates:

  • RP identity — The legal identity of the Relying Party including an optional intermediary
  • Technical correctness — The declaration is well-formed and complete

The Registrar does not validate:

  • Purpose legitimacy — Whether the stated purpose is lawful under GDPR
  • Proportionality — Whether the requested attributes match the purpose
  • Legal basis — Whether the RP has a valid legal basis for data collection

Why the Registrar Does Not Validate Purpose Content

Avoiding liability and bottlenecks

If the Registrar validated the GDPR compliance of each purpose declaration, it would:

  1. Assume liability for the correctness of that assessment
  2. Need ongoing verification — GDPR compliance depends on context that can change (e.g., business model changes, legal interpretations evolve)
  3. Create a bottleneck — Every registration would require legal review, slowing onboarding and making it much more expensive
  4. Require revocation monitoring — The Registrar would need to continuously verify that the legal basis remains valid and revoke certificates when it doesn't

Instead, the Registrar acts as a transparent publisher:

  • Stores the declared purpose securely
  • Makes it publicly accessible for scrutiny
  • Enables third parties (regulators, consumer protection, users) to verify compliance
  • Leaves GDPR responsibility where it belongs: with the Relying Party

Why This Approach Works Best

Design Choice Benefit
RP self-declares purpose RP remains fully accountable under GDPR
Registrar publishes transparently Enables public audit and regulatory oversight
Machine-readable format Wallet can automatically enforce boundaries
User sees purpose at consent time Informed consent with context
No central validation bottleneck Scalable onboarding for RPs
Immutable record Creates evidence trail for disputes

This design follows the principle of transparency over gatekeeping: rather than creating a central authority that approves purposes (which would be slow, legally risky, and potentially a single point of failure), the system ensures that all declarations are visible and auditable.

Importantly, the approach ensures that registration of a use case can happen in an inexpensive, quick, and automated fashion. This enables the use of fine-grained registrations for use-cases that provide transparency for end-users and identify the actual receiver of the data, instead of providing incentives for "catch-all" registrations, for relying on bypassing registration (see discussion below), and for centralized data requests and processing.

Step 2: RP Receives Registration Certificate

Upon successful registration, the RP receives a Registration Certificate that cryptographically binds:

  • The RP's identity
  • The declared purpose (human-readable, multi-language)
  • The permitted credential types
  • The permitted attributes within each credential

This certificate is machine-readable, enabling automated validation by Wallets.

Step 3: RP Makes a Request

When the RP requests data from a Wallet, it includes:

  1. Access Certificate — proving who the RP is
  2. Registration Certificate — declaring what the RP may request
  3. Actual request — specifying what the RP wants now, which must be a equal or a subset of the attributes registered

Step 4: Wallet Validates the Request

The Wallet automatically compares:

Registered (allowed) Requested (actual) Result
age_over_18 age_over_18 ✅ Valid
age_over_18 age_over_18, full_name ⚠️ Warning
age_over_18, full_name age_over_18 ✅ Valid

Rule: The actual request must be equal to or a subset of the registered intended use.

Step 5: User Is Informed

Based on the validation result, the Wallet presents information to the user:

Normal Request (within scope)

Consent Screen

🏪 Liquor Store Online

Purpose: Age verification for alcohol purchase

Requesting:

  • ☑ Proof that you are over 18

[Approve] [Decline]

Overasking Detected

Excessive Data Request

🏪 Liquor Store Online

Registered purpose: Age verification for alcohol purchase

Requesting MORE than registered:

  • ☑ Proof that you are over 18 (registered)
  • ⚠️ Full name (NOT registered)
  • ⚠️ Address (NOT registered)

This request exceeds what the service registered. You may still proceed, but consider whether this data is truly necessary.

[Proceed Anyway] [Decline]

Wallet Provider Policy

The default behavior when overasking is detected is determined by each Wallet Provider. This allows for different approaches based on the provider's privacy stance and user base.

A privacy-protective default would be:

Scenario Default Behavior User Override
Request within scope Allow (with consent) —
Request exceeds scope Reject by default User can enable "Allow extended requests" in settings
RP not registered Reject No override possible

This approach follows privacy by design principles:

  • Protects non-technical users — The majority of users who are not skilled in privacy topics are protected automatically
  • Informed opt-in — Advanced users who understand the implications can choose to allow overasking requests via settings
  • No surprise data sharing — Users cannot accidentally share more data than the RP officially registered for

Settings Example

Privacy Settings

  • ☐ Allow requests that exceed registered intended use (When enabled, you will see a warning but can proceed with requests that ask for more data than the service registered for)

Alternative Approaches

Wallet Providers may choose different defaults based on their target audience:

Approach Default Trade-off
Strict (recommended) Reject overasking Maximum privacy, may occasionally block legitimate edge cases
Warning only Allow with warning More flexible, but risk of accidental over-sharing
User choice per request Ask each time Flexible but increases cognitive load

Benefits

For Users

  • Automatic protection — no need to manually assess every request
  • Clear warnings — immediately see when something is unusual
  • Informed consent — understand exactly what is being requested and why
  • Reduced cognitive load — trust the system to flag problems
  • Privacy by default — protected even without technical knowledge

For Relying Parties

  • Clear guidelines — know exactly what can be requested
  • Legal compliance — built-in GDPR data minimization support
  • Trust building — users trust RPs that request only what's needed

For the Ecosystem

  • Accountability — registered intended use creates audit trail
  • Enforcement — technical mechanism supports regulatory requirements
  • Transparency — public registration enables scrutiny

Updating Intended Use

RPs may need to update their intended use over time (e.g., adding new services). The process ensures continued protection:

  1. RP submits updated intended use declaration to Registrar
  2. Registrar validates the new scope
  3. New Registration Certificate is issued
  4. Old certificate may be revoked or allowed to expire
  5. Requests using the old certificate continue to be validated against the old scope