Tom,
I think you raise an interesting point. In this case, as I understand it (and as discussed in the PEMC), the challenge is how to minimize the probability that the holder of a credential is surprised by what eventually happens to data from
that credential shared with a relying party.
In WG10 we are working on including information about the relying party, and also explicitly what the purpose/use case for the request is, in the request. While there certainly is room for improvement in this respect (while balancing (1)
the volume information provided in the request, (2) the volume of information a holder can reasonably process before responding, and (3) a wallet’s liability in presenting the information to the holder), I think the important point is that this information
is not helpful if the holder cannot trust the claim made by the relying party. In short, any (technical/protocol) solution for a relying party to explain what it is going to do with the data, and for the holder to convey the holder’s acceptance of this, also
needs a way to hold the relying party accountable.
From the github post, it looks as if the European solution to this is their regulations. This works for stakeholders in the EU. (The example in the github post of an EU citizen still being protected by GDPR when renting a vehicle in the
US may not always be true. My read of the discussion at
https://www.activemind.legal/guides/gdpr-non-eu-businesses/ is that a business that obtains data from an EU citizen only falls under GDPR if such services are “geared toward the European market”. A US vehicle rental company that does not advertise in the
EU may be an example of such a business.) This does not solve the issue when conducting transactions between jurisdictions with different regulatory protections.
This is why we are very much invested in the PEMC approach. We see this as a way to help a credential holder trust a relying party (and trust what the relying party claims to be doing with the holder’s data) that does not depend on jurisdictional
regulations.
I am not aware of a technical/protocol concept that will, on its own and absent jurisdictional regulations or something like a PEMC certification, allow a holder to hold the relying party accountable. We are actively exploring this space
though, so would be all ears if you have suggestions.
Thanks,
From: Tom Jones <thomasclinganjones@gmail.com>
Sent: Wednesday, April 23, 2025 11:06
To: pemc kantara <Wg-pemc@kantarainitiative.org>
Subject: [WG-PEMC] the current OID4VP standard is (IHMO) not compliant with PEMC
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.
This issue from the still evolving spec shows (IMHO) that the spec currently planned for the EUDIW (and other) ecosystem will not meet the PEMC because it is not clear how informed consent is achieved. Complexity is (IMHO) not a good answer
in the world of AI and human inattention.
So what to do? Allow the sort of obfuscation that the OIDF spec demands? Or to take arms against a sea of complexity and by opposing, end it.
Kantara has proposed an alternative solution that avoids the complexity.
Peace ..tom jones