The way I envisioned the transaction sets is that all elements, if listed at all, would be mandatory. Each transaction would correspond to one purpose and could be either required or optional. In your use case there would be three purposes. The requirement for privacy reasons is that the user would see all purposes and the ID of the requestor. It is up to the wallet to create the UX.

thx ..Tom (mobile)

On Thu, Feb 22, 2024, 9:16 AM Salvatore D'Agostino <sal@idmachines.com> wrote:

quick thoughts

yes verifier must have a purpose and it is contextual

We had spent some time on this a few years ago.

Limited number makes sense, can see some rationale to single purpose or being able to combine them in a transaction

Assign a bit value to each, with some order

here is the link to the work from 2016 fwiw

https://kantara.atlassian.net/wiki/spaces/archive/pages/3508305/Appendix+CR+-+V.9.3+-+Example+Purpose+Categories




From: Christopher Williams <williams.2560@gmail.com>
Sent: Thursday, February 22, 2024 12:12 PM
To: Jordaan, Loffie <LJordaan@aamva.org>
Cc: wg-pemc@kantarainitiative.org <wg-pemc@kantarainitiative.org>
Subject: [WG-PEMC] Re: Reason for request
 
Loffie & Tom,

Thank you for highlighting this technically difficult subject that we all just culturally move through today with physical cards.

I think the third option is something we started discussing yesterday.  The definitions of the purposes and/or data elements are out of scope of our privacy requirements. Our workgroup only needs to focus on writing requirements generically, such that an assessor is able to determine if the verifier is following the required procedures and regulations for the stated purpose in the verifier's jurisdiction. 

Happy to discuss more at the next meeting.

Christopher

On Thu, Feb 22, 2024 at 12:00 PM Jordaan, Loffie <LJordaan@aamva.org> wrote:

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

Loffie Jordaan

Business Solutions Architect

 

 

Phone: 703.908.5864

Email: ljordaan@aamva.org  

aamva.org

 

 

Icon Description automatically generatedA picture containing text, wheel, gear Description automatically generatedIcon Description automatically generated with medium confidenceA picture containing graphical user interface Description automatically generatedIcon Description automatically generatedIcon Description automatically generatedIcon Description automatically generated

 

 

_______________________________________________
A Community Group mailing list of KantaraInitiative.org
Wg-pemc mailing list -- wg-pemc@kantarainitiative.org
To unsubscribe send an email to staff@kantarainitiative.org
List archives --  https://mailman.kantarainitiative.org/hyperkitty/list/wg-pemc@kantarainitiative.org/
______
Group wiki -- https://kantara.atlassian.net/wiki/spaces/Wg-pemc

_______________________________________________
A Community Group mailing list of KantaraInitiative.org
Wg-pemc mailing list -- wg-pemc@kantarainitiative.org
To unsubscribe send an email to staff@kantarainitiative.org
List archives --  https://mailman.kantarainitiative.org/hyperkitty/list/wg-pemc@kantarainitiative.org/
______
Group wiki -- https://kantara.atlassian.net/wiki/spaces/Wg-pemc