Minor wording changes in background (replace “Relying Party” with “Verifiers” and add “privacy” to concepts IAM systems and practitioners must pay attention to)
regarding a question of “On this diagram - why do we need to mention ‘Wallet’? Can it just be app? Same for Verifier / Reader, can we just mention verifier?”
John did it this way to encompass the expectations of different stakeholders who use both terms. For our purposes, they serve the same function.
consensus is to remove “verifier” from Verifier / Reader in the green box (lower right)
regarding Wallet / App, that is how it’s used by AAMVA; general consensus is to use “App”
Provider/Vendor - why don’t they match on both sides? It’s not always a vendor relationship with the Holder, where it more likely is with the Issuer and Verifier. General consensus is to leave this as is.
Suggest we also update the graphic to include a Terms and Conditions box between the Issuer and the Provider (Provider accepts terms from the Issuer; some of these things may be passed on to the Holder, others may not)
Note the Provider may have relationships with every entity in this diagram
Perhaps we need a text box linked off from the Issuer indicating it may have constraints as a result of terms from Providers and Verifiers
In practice, there should be dotted lines between Issuers and Providers; there are starting to be contracts between Issuers and Providers, but the space is not mature.
Is there regulation about how id’s can be used? how is all this enabled in terms of law and regulation? It all depends on legal frameworks. The law is especially patchy (i.e., not all use cases are covered)
The issue may be more nuanced that might not be captured by a text box for the diagram.
Note that while we do not specifically discuss laws and contracts, we are not lawyers but we must recognize that contractual relationships can introduce patterns to watch for.
Motion to approve the charter modulo the changes as discussed today (specifically: replace “Relying Party” with “Verifiers” and add “privacy” to concepts IAM systems and practitioners must pay attention to; update the diagram to change Wallet / App to App, Verifier / Reader to Reader; update the graphic to replicate what’s between Provider and Holder in between Provider and Issuer; move all dates by one quarter) - APPROVED
Will circulate candidate final version with spreadsheet for comments before the next meeting
Salvatore D'Agostino noted that the ANCR group is close to publishing and that elements of that spec, when published, may be useful as possible requirements in the PEMC report when publishedWhy is this limited to in-person?
That has been done to limit the scope and help get this early document out sooner. Also, the ISO spec is not ready for remote use cases either. Perhaps rephrase as in-person use cases, both attended and unattended (who is responsible for making a match between the data and the person; use case 2 could support something like a kiosk that the person must physically use). Can we call out the scope where the verification could be done the device rather than a person on the other side? Suggest making the point in use case 2 that the verifier could be a person or a device.
we do not have a technical standard for doing use case 2, and unlikely to have one any time soon. If we want to limit to what we have now, then use case 2 might be premature.
is this about privacy or about standards? What about what’s coming into the marketplace now? Are we writing to what humans need, what things might look like in the future, or tying to standards? If we’re working to any mobile credentials, then we need to reflect broader use cases.
The user’s device is performing the verification and the match in the first sentence in UC2. Something like a Stripe device can do that, but there are limitations to what companies are allowed to put financial apps on phones. If the verifier needs to know about the hardware being presented, that’s a privacy concern. It trusts the bits based on the issuance, not on the device, and yet it is difficult to imagine where a verifier can ignore the device itself when verifying information. If the issuer has done that device verification, though, will the verifier need to do more?
This question of how much we suggest compliance with current standards is not part of the use case; it may come later.
Fundamental difference when it comes to who is doing the verification of the person. Proposed change is to remove the notion of biometric identification from the first half of the UC2.
5 min.
Government-issued Digital Credentials and the Privacy Landscape