Hi;

I’m continuing to noodle in the PEMC Requirements Conformance Documentation.

I have put the following under Principle 1: Consent and Choice

Applying the Consent and Choice Principle to Mobile Credentials
Where consent is the applicable basis for processing data, this principle mandates that organisations, including Issuers, Verifiers, and their respective Providers and Vendors, shall only process personal information with the explicit consent and choice of the individual Holder. This underscores the fundamental right of individuals (Holders) to control their personal information within the mobile credential ecosystem.
Consent is only valid if the Holder has a genuine choice to allow or disallow the processing of their information. This means mechanisms must be in place for Holders to make informed decisions before or when any data processing occurs. These mechanisms should present distinguishable processing options, empowering the Holder to select their preferred level of data interaction.
Considerations for Implementors:

Informed Decision-Making: Holders must be provided with clear, concise, and easily understandable information about what personal data is being collected, how it will be used, and with whom it might be shared. This information is crucial for them to make an informed choice.
Granular Choices: Where feasible, offer granular options rather than an all-or-nothing approach. This allows Holders to consent to specific processing activities while opting out of others, enhancing their control.
Timing of Consent: Consent must be obtained at or before the point of data processing. It should not be a retroactive justification for data already processed.
Opt-Out Mechanisms: Clear and accessible mechanisms must exist for Holders to opt out of data collection or usage practices. Their decisions to opt out must be respected and promptly implemented by the system.
Cognitive Overload Mitigation: While obtaining explicit consent is paramount, organisations must be mindful of potential "consent fatigue" or cognitive overload on Holders. Continuously prompting for consent for every minor interaction can diminish the effectiveness of the consent process itself. Stakeholders should explore and implement strategies to balance explicit consent requirements with user experience, ensuring that consent requests are meaningful and not burdensome. This involves setting preferences that persist or providing clear explanations of ongoing processing based on initial consent, with easy ways to review and revoke that consent.

The Consent and Choice Principle for mobile credentials supports individual autonomy and transparency, ensuring that Holders are active participants in decisions regarding their data, rather than passive subjects of data processing.

2.1.1.1 Obtain Consent for Verifier Processing
Description

Applicability

Issuer and Vendors to Issuers.
Verifiers and Vendors to Verifiers.
Providers to Holders

Pre-conditions
Data Scope has been documented
The Verifier should explicitly identify and document the personal information elements they intend to request or derive from a Holder's mobile credential. Without knowing what data is involved, it's impossible to design an appropriate consent mechanism or adequately inform the Holder.

Purposes have been identified and documented.
The Verifier should clearly define and document the specific, legitimate purpose(s) for collecting and processing each personal information element or group. Consent must be specific to the purpose(s) for collection. Vague or overly broad purposes invalidate consent. This also forms the basis of the Notice to the Holder.

Notice Mechanism has been implemented.
The Verifier has designed and implemented an evident, conspicuous, and easily understandable Notice. This Notice must be presented to the Holder before or at the point of requesting mobile credential data and must contain:

A description of the personal information attributes being requested/processed.
The purpose(s) for processing.
The identity of the Verifier (and any relevant third parties the data might be shared with, if applicable, along with purposes for that sharing).
Information on how the Holder can withdraw consent (if applicable to the specific interaction).
A link to a more detailed privacy policy, if appropriate

Consent Mechanism has been implemented.
The Verifier has designed and implemented an unambiguous mechanism for the Holder to provide affirmative consent after reviewing the Notice. This mechanism must:

Be separate from other terms or actions (e.g., not bundled with general terms of service acceptance unless directly related and clearly explained).
Offer an explicit "accept/agree" or equivalent affirmative action.
Allow the Holder to equally easily "decline/disagree" or abstain from providing the credential data without undue friction (beyond being unable to access the service that requires that data).

There is a Consent Record System
The Verifier has a reliable system or process to record the Holder's consent (e.g., timestamp, specific version of notice consented to, scope of consent given).

There is a No-Consent Process
The Verifier has a defined process for scenarios where a Holder withholds consent, ensuring that processing related to the denied consent does not occur and the Holder is appropriately informed of any consequences (e.g., inability to access a specific service).

Staff Training
The Verifier has been trained. Staff who engage with consent systems or processes (e.g., those involved in designing interaction flows, IT staff implementing the systems, and customer-facing staff, if applicable) are trained on this consent requirement and internal procedures.
Tests
Notice Availability & Timing Test
Procedure: Initiate an interaction requiring credential data from the Verifier's system.
Observation: Is a Notice presented before or at the point of data request? Is it easily accessible and readable?
Success Criteria: Notice is timely and presented.

Notice Content Adequacy Test
Procedure: Review the content of the presented Notice.
Observation: Does it accurately list the personal information to be processed? Does it clearly state the specific purpose(s)? Is the Verifier identified? Is the language understandable to a typical Holder?
Success Criteria: Notice content is complete, accurate, and transparent as per pre-conditions.

Consent Action Test
Procedure: Interact with the consent mechanism.
Observation: Does the system require an explicit, affirmative action from the Holder to signify consent (e.g., clicking "Agree," unchecking a pre-filled box is not sufficient)? Can the Holder easily decline?
Success Criteria: Consent requires an explicit, affirmative action. Declining is straightforward.

Data Processing Post-Consent Decision Test
Procedure:
Scenario A: Provide consent. Attempt to complete the transaction/interaction.
Scenario B: Decline consent. Attempt to complete the transaction/interaction.
Observation:
Scenario A: Does the system process the Holder's data as described in the Notice?
Scenario B: Does the system refrain from processing the Holder's personal information for the purpose for which consent was denied? Is the Holder informed of the outcome of declining (e.g., service unavailability)?
Success Criteria: Data processing aligns with the Holder's consent decision. The system respects denial of consent.

Consent Record Audit:
Procedure: (If backend access or logs are available) After a successful consent interaction, attempt to locate the record of this consent.
Observation: Is a record of consent stored? Does it contain relevant details (timestamp, scope)?
Success Criteria: A verifiable record of consent exists.

Test Results

Meets Requirement: The Verifier meets all test conditions for its use case.
Partially Meets Requirement: The Verifier meets at least 50% of the test conditions that apply for its use case

Does Not Meet Requirement: The Verifier meets less than 50% of the test conditions that apply for its use case.