Hi; Here are the notes from today. The PEMC Requirements Conformance Worksheet is intended to be the working document for reporting on a conformance test. It’s a relatively simple worksheet to be completed when an organisation is ready to so a self-assessment or to be assessed by a third party. The WIP is a Google Sheet here. https://docs.google.com/spreadsheets/d/1kxUWyCnL-KKGBVzDsvLMujmDM7ItEPtlGs5n... The PEMC Requirements Conformance Test Doc is the documentation to support the worksheet. It is intended to explain how to assess each requirement by providing descriptions, pre-conditions, and test for conformance. The WIP is a Google Doc here: https://docs.google.com/document/d/1sDS2F7ndtGnc1jFY4yIfvsdpai1Y5s9ZFfFCVX59... Here’s the first example from Principle 1 and including the first requirement. Feel free to comment in the Google documents. Principle 1: Consent and Choice The Holder must consent to the processing of their personal data. 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. At its core, this principle emphasises individual autonomy. 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 any data processing occurs. These mechanisms should present distinguishable processing options, empowering the Holder to select their preferred level of data interaction. Key Considerations for Implementation: 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 unduly 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. By adhering to the Consent and Choice principle, organisations can build trust with Holders, foster greater transparency, and ensure their mobile credential solutions align with fundamental privacy rights. This approach moves beyond mere compliance, positioning privacy as a core tenet of the system's design and operation, where choice is the appropriate basis for legitimate processing. 1. Obtain Consent for Verifier Processing Description Obtaining consent for verifier processing requires that Verifiers secure valid consent from holders before processing any personal information received via a mobile credential. The act of a Holder presenting their mobile credential to a Verifier does not necessarily grant implicit permission for the Verifier to process the contained personal data for any purposes. Instead, the Verifier must determine if they must obtain the Holder's explicit consent in response to a clear notice provided by the Verifier to the Holder. Applicability • Issuer and Vendors to Issuers. • Verifiers and Vendors to Verifiers. • Providers to Holders Pre-conditions 1. Identify the Data Without knowing what data is involved, it's impossible to adequately design an appropriate consent mechanism or adequately inform the Holder. The Verifier should explicitly identify and document all personal information elements they intend to request or derive from a Holder's mobile credential. 1. Identify the Purposes Consent must be specific to the purpose. Vague or overly broad purposes invalidate consent. This also forms the basis of the Notice to the Holder. For each personal information element identified, the Verifier should clearly define and document the specific, legitimate purpose(s) for its collection and processing. 1. Design the Notice Mechanism The Verifier should design a system or process for presenting an evident, conspicuous, and easily understandable Notice to the Holder before or when requesting the mobile credential data. This notice should include: • 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 1. Design the Consent Mechanism The Verifier should design an unambiguous mechanism for the Holder to actively signify their consent after being presented with the Notice. This mechanism should: • 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). 1. System for Recording Consent The Verifier should have a reliable system or process to record the Holder's consent (e.g., timestamp, specific version of notice consented to, scope of consent). 1. Processing for Handling Lack of Consent The Verifier should have a defined process for what happens if a Holder does not consent. This usually means the specific processing (and potentially the related service) cannot proceed. 1. Staff Training and Awareness Relevant staff (e.g., developers, product managers, legal/compliance, customer-facing personnel) should be trained on this consent requirement and the Verifier's processes for upholding it. Test conditions • Notice Presentation Test Simulate a Holder interaction: • Is a Notice presented to the Holder before or when requesting credential data? • Is the Notice easy to find and read? • Does the Notice appear consistently across platforms or systems? Success: The Notice is presented as required • Notice Content Review Examine the content of the Notice: 1. Does the Notice accurately describe the personal information attributes processed? 2. Does the Notice state the purpose(s) for processing? 3. Is the Notice language easy for a typical Holder to understand? 4. Does the Notice identify the Verifier? Success: The Notice content is complete, accurate, and understandable. The Notice aligns with data elements and purposes. • Consent Functionality Test Interact with the consent mechanism: • Is there an explicit, affirmative action required from the Holder to indicate consent (e.g., a checkbox that is unchecked by default, a button to "Agree")? • Is it equally easy to decline or withhold consent? • Does the system prevent processing if consent is not given? • Can the Holder proceed with a "decline" option, and does the system respect this choice by not processing the data for that purpose? Success: The consent mechanism requires an affirmative act, allows for refusal, and the system respects the Holder's choice. • Consent Record Verification Test • After a Holder gives consent, is a record of this consent generated and stored? • Does the record include relevant details (e.g., what was consented to, timestamp)? Success: A verifiable record of consent is created. • Test Privacy Defaults Examine the consent interface: • Are consent options (e.g., checkboxes) pre-filled or pre-selected to indicate agreement? Success: Consent requires an active opt-in; no pre-checked boxes or reliance on inaction as consent. • Data Processing Audit After an interaction where consent was (or was not) given: • if consent was given, verify that only the data elements for which consent was obtained are processed, and only for the stated purposes. • If consent was not given, verify that the Verifier does not process the Holder's personal information from the mobile credential for the requested purpose. Success: Data processing (or lack thereof) aligns with the Holder's consent (or withheld). • Withdrawal of Consent Test If the Verifier offers a mechanism for consent withdrawal: • Is this mechanism easily accessible and usable by the Holder? • Does withdrawing consent effectively stop further processing (for which consent was the basis)? Success: Withdrawal mechanism functions as described and effectively revokes consent. 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. Have a better than expected day, John Wunderlich “The law, in its majestic equality, forbids rich and poor alike to sleep under bridges, to beg in the streets, and to steal their bread.” ― Anatole France Calendly: https://calendly.com/privacycdn LinkedIn: https://www.linkedin.com/in/privacycdn/ Bluesky: https://bsky.app/profile/privacycdn.bsky.social Mastodon: https://mastodon.social/@PrivacyCDN Twitter: https://twitter.com/PrivacyCDN -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
