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@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/>
