Consent in the Context of Mobile Credentials

Consent is a contested term. There is consensus that it is a good thing, but no consensus on a definition that applies across multiple jurisdictions. Consent management systems, or the obtaining of consent from individuals in the context of mobile credential flows, seek to obtain, record, apply, and retain consent from individual credential Holders. Such systems need to demonstrate compliance, meet privacy expectations, and fulfil business objectives.

The Three-Way Tension

These three objectives—compliance, privacy, and business value—exist in constant tension, reminiscent of the project management adage that you can have something with high quality, at a low price, and delivered quickly, as long as you only pick two. In the consent context, achieving all three goals simultaneously is similarly challenging:

When consent serves business and compliance, it often fails privacy. This pattern dominates much of the Internet today. Organizations implement consent interfaces designed primarily to satisfy legal requirements while maximizing data collection for business purposes. The result is lengthy terms of service, pre-checked boxes, dark patterns that nudge users toward “agree,” and deliberately confusing interfaces. Users click through these mechanisms not because they’ve made an informed choice, but because it’s the only way to access the service. The consent is legally defensible and serves business goals, but it fails to genuinely respect user autonomy or privacy preferences. In mobile credential scenarios, this might manifest as requesting unnecessary attributes “just in case” or bundling consent for multiple purposes into a single take-it-or-leave-it prompt.

When consent aligns with compliance goals and respects user privacy, it may challenge business models and revenue streams. Meaningful consent—as defined in regulations like the EU’s General Data Protection Regulation (GDPR) or Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA)—requires consent that is freely given, specific, informed, and unambiguous. This standard means users must be able to refuse without penalty, understand exactly what they’re agreeing to, and provide an active indication of consent. For mobile credentials, this might mean allowing a Holder to selectively disclose specific attributes rather than presenting an entire credential, or providing granular control over which Verifiers can access which data for which purposes. While this approach genuinely respects privacy and satisfies compliance requirements, it can conflict with business models built on comprehensive data collection, cross-purpose data sharing, or monetization of user information. Organizations may lose valuable data insights, find their services less personalized, or need to develop entirely new revenue models.

When consent meets user privacy expectations and business goals, demonstrating compliance becomes challenging. Consider scenarios where genuine user needs align with business interests—for example, a Holder willingly sharing extensive identity information to expedite a high-value transaction, or a business offering premium features in exchange for detailed preferences. These arrangements can satisfy both parties and create genuine value. However, they may struggle to meet compliance requirements that impose constraints on data collection, retention, or use. Age verification provides a particularly stark example: users may prefer to simply share their date of birth (meeting privacy expectations through simplicity), and businesses may want this information for personalization (serving business goals), but compliance frameworks increasingly require proving age without revealing the actual birthdate—a more complex technical solution that satisfies neither party’s intuitive preferences. Similarly, some privacy regulations mandate data minimization that goes beyond what users themselves would choose, or impose retention limits that conflict with both user desires for persistent personalization and business needs for longitudinal data.

The Mobile Credential Context

Mobile credentials introduce unique challenges to this already complex landscape. Unlike traditional web-based interactions where consent often occurs in a controlled environment with ample screen space and time for deliberation, mobile credential presentations frequently happen:

In real-time, physical-world contexts where the Holder may feel pressure to complete the transaction quickly
On small screens where detailed consent information is difficult to display comprehensively
In situations of unequal power dynamics where refusing to present a credential may mean being denied access to essential services, employment, or spaces
Across multiple interactions where consent fatigue can set in as users repeatedly encounter similar requests
With varying technical literacy where Holders may not understand concepts like selective disclosure, cryptographic proofs, or data minimization

Furthermore, mobile credentials operate in a distributed ecosystem where multiple parties—Issuers, Holders, Verifiers, and potentially intermediaries—each have different interests, capabilities, and regulatory obligations. A consent framework must account for:

Who is obtaining consent and on whose behalf
When consent is obtained (at issuance, at presentation, or both)
How granular consent should be (per-attribute, per-transaction, per-Verifier, or per-purpose)
How consent is communicated between parties in a machine-readable way
How consent is enforced technically when credentials are presented
How consent records are maintained and by whom, especially for later verification or dispute resolution

Purpose of This Framework

This appendix is intended to provide a framework to help implementors of mobile credentials develop and apply a consent model that can conform to the Kantara Requirement for Privacy-Enhancing Mobile Credentials in their jurisdictional and business context. Rather than prescribing a one-size-fits-all solution, this framework acknowledges that implementors must make conscious trade-offs among compliance, privacy, and business objectives based on:

Jurisdictional requirements: Different legal frameworks impose different consent standards, from strict GDPR requirements in Europe to more flexible approaches in other regions
Use case sensitivity: Consent requirements for accessing a concert venue differ substantially from those for healthcare services or financial transactions
Organizational capabilities: The technical sophistication, resources, and organizational maturity available for implementing consent mechanisms
Stakeholder expectations: The privacy expectations of Holders, regulatory expectations of authorities, and business needs of Verifiers and service providers

The goal is not to resolve the inherent tensions among compliance, privacy, and business value, but to make those tensions explicit and provide tools for navigating them thoughtfully. By understanding where your implementation falls on this triangle, you can make informed decisions about consent mechanisms that are honest about their priorities and transparent about their limitations.

Consent as Noun and Verb

In the context of mobile credentials, consent operates as both a noun[^1] and a verb[^2], reflecting its dual nature as both a state of authorization and an act of approval.

Consent as a noun represents the state of authorization, permission, or approval that exists at a given moment. It is the answer to the question: “Do I have permission to collect or use this data?” When a Verifier seeks compliance or approval from the Holder for the collection of credential data, they are seeking to establish or verify this state of consent. This noun form is what gets recorded in consent management systems, what compliance officers audit, and what forms the legal basis for data processing. In technical terms, it might be represented as a consent token, a cryptographic proof, a signed agreement, or an entry in a consent registry. The noun form of consent has properties: it can be specific or broad, temporary or enduring, revocable or irrevocable, documented or implied.

Consent as a verb represents the active process of granting permission in the moment. It is the act of approval or assent itself. When a Holder approves or assents to the collection of credential data when presenting the mobile credential, they are actively consenting—performing the verb. This might manifest as tapping “Share” on a selective disclosure prompt, biometrically authenticating to approve a data release, or confirming which attributes to present to a Verifier. The verb form of consent is the human agency at the center of privacy protection: the moment when an individual exercises control over their information and makes a choice about its disclosure.

The distinction matters because the verb must create the noun—the act of consenting must result in a recorded state of consent that can be referenced, audited, and enforced. A robust mobile credential consent framework must address both:

The interaction design that enables Holders to meaningfully perform the verb of consenting (the user experience, timing, information provided, and genuine choice offered)
The technical infrastructure that captures, represents, and maintains the noun of consent (the data models, protocols, storage mechanisms, and verification methods)

When these two aspects are misaligned—when the act of consenting doesn’t accurately translate into the state of having consented, or when the recorded consent doesn’t reflect the actual agreement made—the consent framework fails at a fundamental level. This alignment between verb and noun, between the moment of choice and the enduring record of that choice, is essential to consent systems that serve all three goals of compliance, privacy, and business value.

Footnotes

[^1]: compliance in or approval of what is done or proposed by another Merriam-Webster online

[^2]: to give assent or approval Merriam-Webster online