Thanks everyone for your input.
Christopher, I agree that the definitions of the purposes (including what data elements may be included in each) are out of scope.
As requirement 1.4 currently reads, we also allow more than one “purpose” in a transaction, and talk about “required and optional” elements in the description. We can:
- Simplify the requirement to allow only one purpose.
- Keep the provision for more than one purpose in a single transaction.
Practically I do think that #2 is better. Requiring another transaction for each purpose would likely introduce additional friction to an interaction between a holder and a verifier.
If we continue to allow more than one purpose in a single transaction, I think we do want to ensure the holder:
- Is aware that the request is for more than one purpose;
- Is able to check the data the verifier requests for each purpose; and
- Is able to selectively approve the request. (At minimum this means that the holder must be able to approve individual purposes. This is however a different discussion.)
At issue then, for purpose of requirement 1.4, is what the verifier must do to enable this. My thinking is that the verifier must provide sufficient information to the holder to support items a and b; item c is out of scope of requirement 1.4. The challenge is to find terminology to convey this.
Would something like the following work (to replace the existing 2nd paragraph in the Description)?
The Verifier must inform the Holder about the purpose or purposes of the transaction, and of the data needed for each purpose.
In this way we sidestep the mandatory/optional issue. This verbiage does not prevent all the data needed for a purpose from being mandatory, and it also does not prevent a verifier from identifying some mandatory and some optional data for a particular purpose.
Thoughts?
I can also see this becoming a requirement on its own, as it can be argued that it is distinct from requiring the verifier to only request the data that it needs.
And Sal, thanks for the link to the 2016 work. This will be good input for WG10 in our technical deliberations.
Thanks.
Loffie Jordaan
Business Solutions Architect
Phone: 703.908.5864
Email: ljordaan@aamva.org
From: Tom Jones <thomasclinganjones@gmail.com>
Sent: Thursday, February 22, 2024 12:31
To: Salvatore D'Agostino <sal@idmachines.com>
Cc: Christopher Williams <williams.2560@gmail.com>; Jordaan, Loffie <LJordaan@aamva.org>; pemc kantara <wg-pemc@kantarainitiative.org>
Subject: Re: [WG-PEMC] Re: Reason for request
WARNING: This email originated from outside of AAMVA. Do not click on links or open attachments unless you recognize the sender and know the content is safe.
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
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:
- 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.
- 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.
- 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).
- 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:
- 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.)
- Define broader standardized purposes, and allow each purpose to contain mandatory and optional fields (identified in the request at transaction time).
- ?
Thoughts anyone?
Thanks.
Loffie Jordaan
Business Solutions Architect
Phone: 703.908.5864
Email: ljordaan@aamva.org
_______________________________________________
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
