- Wg-pemc - mailman.kantarainitiative.org

Deck
by John Wunderlich 03 Apr '24

03 Apr '24

Have a better than expected day, John Wunderlich LinkedIn: https://www.linkedin.com/in/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.

1 0

Prior meeting still open. Try this instead
by John Wunderlich 03 Apr '24

03 Apr '24

Here’s my own Zoom https://us06web.zoom.us/j/7325916646 Have a better than expected day, John Wunderlich LinkedIn: https://www.linkedin.com/in/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.

1 0

Important discussion tomorrow
by John Wunderlich 03 Apr '24

03 Apr '24

Dear all, I would like to extend my invitation to all the members of the PEMC to join tomorrow's call, as it is important that we provide our feedback to Kantara. Eve Mahler has been guiding the Kantara board through a nano-visions exercise, and they are hoping to receive inputs from every group to discuss on the next Leadership Council Monthly call. I will share Eve's deck during the call tomorrow and if you can participate we can brainstorm the PEMC response. Have a better than expected day, John Wunderlich LinkedIn: https://www.linkedin.com/in/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.

3 6

Inclusive purpose and consent document
by Tom Jones 02 Apr '24

02 Apr '24

I am sharing a document under development by the Resilience Identifiers for Underserved Populations to ensure that the work product of the two work groups stays aligned. We have focused on the data that needs to flow from the Verifier to the User Device in order to ensure that the data displayed to the holder will be appropriate to the purpose specified and so that the holder can make an informed consent for themselves or for the subject that has delegated them authority to make a decision for that subject. It is expected that this data will flow from the verifier to the user's device so that the device can make the decision about the appropriate user agent (or wallet) to handle the request. It is up to the device and the user agent to form the UX for holder consent. Other arrangements of the device and agent are, of course, possible. Please let us know if there is any particular action RIUP should take to help assure alignment. https://docs.google.com/document/d/1n7HobJ6QTsNld5rn1uuIiNw0A__L44ug/edit?u… ..tom

1 0

adoption of document for purpose and consent
by Tom Jones 20 Mar '24

20 Mar '24

This document was adopted for development by the Reliable Identifier for the Underserved Populations (RIUP) Kantara work group. This is just an informative notice and does require any action by the PEMC. But feedback from the members would be highly appreciated. https://docs.google.com/document/d/1n7HobJ6QTsNld5rn1uuIiNw0A__L44ug/edit?u… ..tom

1 0

making a difference
by Tom Jones 06 Mar '24

06 Mar '24

I am having trouble getting privacy enhancing techniques into the wallet-verifier communications in OpenID and OWF. If we don't have a doc (even a draft) to show the standards makers soon it will be too late to make a difference. I have included an attachment that shows the problem i am having even getting a user friendly name of the verifier into the wallet. ..tom

1 0

interesting view on observability and purpose from EU
by Tom Jones 01 Mar '24

01 Mar '24

We now have new requirements - observability and purpose - it seems that the idea of a general purpose wallet has been effectively eliminated in the EU and by those states that mandate their own wallets for their own creds. Statement by the Commission on unobservability on the occasion of the adoption of Regulation 2024/... + The Commission welcomes the agreement reached, which in its view, confirms that this amending Regulation does not allow for the processing of personal data contained in or arising from the use of the European Digital Identity Wallet by the Wallet providers for other purposes than delivering wallet services. The Commission also welcomes the inclusion of the concept of *unobservability in Recital (11c) of the draft amending Regulation, which should prevent wallet providers from collecting and seeing the details of user’s day-to-day transactions.* The Commission is of the view that this concept means that there should not be correlation of data across different services for the purposes of user tracking or tracing or for determining, analysing and predicting personal behaviour, interests or habits. At the same time, the Commission acknowledges that, in full compliance with Regulation (EU) 2016/679, the providers of European Digital Identity Wallets may access certain categories of personal data with the user’s explicit consent, such as in order to ensure continuity in the provision of wallet services or to protect users from disruptions in their provision.* That data should be limited to what is necessary for each specific purpose.’ * AM_Ple_LegStatOther (europa.eu) <https://www.europarl.europa.eu/doceo/document/A-9-2023-0038-AM-007-007_EN.p…>

2 1

to enhance privacy we need to focus on the link between the verifier and the user's wallet
by Tom Jones 28 Feb '24

28 Feb '24

Here is a doc I am pushing thru a variety of standards. https://docs.google.com/document/d/12uuiEEkfnYoBwphkiNHQmFVH0H24gl3h/edit?u… ..tom

1 0

Reason for request
by Jordaan, Loffie 23 Feb '24

23 Feb '24

Tom, In yesterday's meeting, you suggested (if my understanding is correct) that the reason for any request from a verifier can logically be simplified into the following structure: Purpose A Required field 1 Required field 2 Required field 3 Purpose B Required field 1 Required field 4 Required field 5 An underlying assumption is that for any purpose there are never optional fields. Consider the following use cases: 1. A verifier offers patrons to enter into a lucky draw. Local legislation requires a name and address to be recorded. The verifier would like to allow entrants the option of also providing an email address that will only be used to notify the patron in case of winning. 2. A verifier offers to provide a patron with promotional material. At minimum, the verifier needs the patron's email address. When enrolling in the service, the patron can optionally provide a name. 3. In order to open a new bank account online, a bank needs Name and DOB. The customer has the option to also provide a DLN for a quicker account creation turnaround time (since the bank needs less time for their background checks). 4. An airport security checkpoint requires a person's portrait image, name and DOB. In addition, if the customer has a commercial driver's license with a Hazmat endorsement, the customer can go through a faster lane (since the FBI has already checked the person out). The security checkpoint would also like to collect zip code information (to be anonymized) for research purposes. Customer's do not have to provide zip code information. Also playing into this is the need for cross-jurisdictional interoperability. This means that the purpose must be conveyed using a code and not via freeform text. (Purpose definitions will not include the fields associated with them; fields required for a given purpose is identified in a request at transaction time.) I see the following options: 1. Create very narrowly defined purposes for the examples above. This would require the creation of a very large and likely incomplete set of coded purposes. (The option of only allowing a single purpose per transaction would be an arguably worse flavor of this option.) 2. Define broader standardized purposes, and allow each purpose to contain mandatory and optional fields (identified in the request at transaction time). 3. ? Thoughts anyone? Thanks. [Logo, company name Description automatically generated]<http://www.aamva.org/> Loffie Jordaan Business Solutions Architect Phone: 703.908.5864 Email: ljordaan(a)aamva.org<mailto:ljordaan@aamva.org> aamva.org<http://www.aamva.org/> [Icon Description automatically generated]<https://www.facebook.com/AAMVA/>[A picture containing text, wheel, gear Description automatically generated]<https://twitter.com/AAMVAConnection>[Icon Description automatically generated with medium confidence]<https://www.youtube.com/channel/UCrW3jQf3p_25zeK9EQbCrAA>[A picture containing graphical user interface Description automatically generated]<https://www.flickr.com/people/aamva/>[Icon Description automatically generated]<https://www.linkedin.com/company/aamva/>[Icon Description automatically generated]<https://www.instagram.com/aamvaconnection/>[Icon Description automatically generated]<https://aamvacast.podbean.com/>

4 5

Collected data about the choice of handling requests from Verifiers to Wallets base on today's meeting
by Tom Jones 21 Feb '24

21 Feb '24

What should a request to the wallet look like to achieve the purpose of the Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> and the privacy of the Subject <https://tcwiki.azurewebsites.net/index.php?title=Subject>. Context Today it is possible to use a driver's license issued in California to enter a bar in Thailand. The question arises about how a request from a Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> in any jurisdiction can make a request that all digital Wallets <https://tcwiki.azurewebsites.net/index.php?title=Wallet> could meaningfully handle to allow existing purposes. The use cases listed below include cases were interoperability of wallets with disparate requirements in diverse identity Ecosystems <https://tcwiki.azurewebsites.net/index.php?title=Ecosystem> are important to the person that selects which wallet to use. Problems 1. Users will not select Wallets <https://tcwiki.azurewebsites.net/index.php?title=Wallet> that cannot get them access to resources that they depend upon. This page focuses on the way to create a request from a verifier such that it can be handled by the wallets that the user is likely to have in their possession. 2. When the request from the Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> includes multiple purposes it is not likely that the user can be expected to switch from one wallet to another. Nor is it clear that the user ID will be the same in two different wallets. 3. Many states in the US are issuing Mobile Driver's License <https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License> wallets that can only hold their own State Issued Identifiers <https://tcwiki.azurewebsites.net/index.php?title=State_Issued_Identifier>. Thus using that Wallet <https://tcwiki.azurewebsites.net/index.php?title=Wallet> for other purposes of the Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> will force the user to select different wallets to gain access the the desired resource. A solution that many user will avoid. 4. Technologies, including cryptographic methods, are changing rapidly. If these changes are not accommodated by users with existing mobile devices, the user will not be able to use them until they upgrade their device. 5. Use Cases 1. A wallet that holds a California Mobile Driver's License <https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License> can be used to enter a bar in a different country with different legal requirements. 2. A shopper at a grocery store wants to give the store their Loyalty ID <https://tcwiki.azurewebsites.net/index.php?title=Loyalty_ID> in order to take advantage of selective discounts available to loyal customers. 3. A sovereign state needs State Mandated Identification <https://tcwiki.azurewebsites.net/index.php?title=State_Mandated_Identificat…> in order to have a consistent Identifier <https://tcwiki.azurewebsites.net/index.php?title=Identifier> for any of the several hundred licenses and other uses. Solutions This page describes two ways to handle requests from wallets that need to server multiple purposes in a single request to the wallet. While it is possible that a wallet could handle both types of request, interoperability would be improved if only one of these methods were selected. 1. Allow the request to contain both optional and required claims and list multiple purposew as advisory and not directly connected to the list of claims required. 2. Allow the request to contain multiple purposes and let the holder make a choice on which purpose to consent. In many cases the purpose should be sufficient to determine the claims provided by the wallet. This has also been called the collection of transaction sets, where each transaction was related to one purpose.

1 0