15 min. | Workgroup Charter Update | @Christopher Williams @Heather Flanagan (Unlicensed) | Present, review, and (hopefully) vote on the updated Work Group Charter |
30 min. | Draft Report | @Christopher Williams | Review of proposed changes to PEMC Early Implementor's Guidance Report Editors Draft 2 Tom continues to be concerned that the document has moved towards an issuer and business focus; we don’t talk about the user experience or the wallet. Is this entirely an organizational document for them to use and decide whether they are qualified to do anything, or should it be a human oriented approach? The Issuer goes to great length about what they will ask of the wallet, but what about what the human asks of the wallet? The Issuer has a responsibility towards the user to make sure the wallet does certain things. What happens if/when the human does not trust the Issuer? It’s the user’s wallet not the Issuers wallet. But it’s the issuer that decides whether the wallet has sufficient protections and functionality to hold the human’s information. From the OIDF perspective, they’ve changed their mission/vision to be user oriented. So even though they are developing technical protocols, the mission is around people who are the end beneficiaries everyone is trying to serve. Is Kantara’s mission human oriented? We don’t have much representation from civil society here to help round out the perspectives on this work. If the language we’re using corporate oriented, and what we’re specifying is corporate oriented, we’re missing something. Need to include more human-oriented language. OIDF: New vision statement: Help people assert their identity wherever they choose OIDF New mission statement: Lead the global community in creating identity standards that are secure, interoperable, and privacy preserving
This did begin as an Implementor’s Guide, and so the bias towards Issuers is understandable. Ultimate goal is to get to the place where we can have a trust mark so any party in the ecosystem can see the stamp and understand the privacy implications because they’ll know what it means. Could also take a look at what would be tested in the marketplace. Since states are sovereign, what you can write specs for is what the verifier hardware and software looks like and what the user hardware/software looks like. That’s what’s controllable, not the states. The focus should be on the wallet and the issuer can pick the specs they’ll use. There may be models where users control their wallet, but the wallet entity is the controlling force, so pointing to the wallet might not fix the problem. What can the working group reasonably accomplish? Certification will be conformance on entities, not the users themselves. We’re trying to into place appropriate end-to-end processes. But maybe users are certified via things like RealID? Authentication of a user in the wallet is an issue of the wallet and how it interacts with the user, but what the verifier needs to know is that the credentials are correct. Issuers only issue into trusted wallets. How do issuers know that? That’s what the spec is supposed to cover so every issuer doesn’t have to create their own wallet. Issuers have to choose wallets to select the right kind of wallet, or does the individual have to evaluate the wallet? Something else has to evaluate the wlalet to describe what it’s functionally capable of. It’s the wallet that’s key to this exchange, so that should be more our focus.
What is not currently true is that the State of California will generically provision credentials to wallets without a gating function. So for now it is an Issuer led or Issuer controlled ecosystem model. The Issuer is the linchpin player; the wallet plays a critical role, but the Issuer decides which wallets they will enable. this is a policy point on the part of the Issuer. The technical specs are building to a world where the wallet can act like a web browser, and it would functionally work with the issuance hardware. This broader policy question is a good question to discuss here; it matters back to our charter. Are we only trying to address credentials being issued by sovereign issuers, or all types of identities which have different frameworks. Originally we were trying to be as broad as possible, but the philosophies may become too disperse to capture in one space. the Open Wallet Foundation is trying to be that broad, but they are leaning into privacy issued wallets and credentials, but it’s still very much an emerging space. It’s not as far along as the PEMC work. So we have both a timing and scope constraint. Easier to focus on government-issued credentials than simultaneously trying to address privately-issued credentials.
We could approach this in a phased perspective. We could start with government-issued credential, and then at a later phase look at private-sector issued credentials, seeing what adaptations would be needed at that point for those credential types (this would suggest a change to the charter as well). What does the sovereign entity rely on for making their decisions? That’s not covered in the Guidance. The purpose of the group is to address the privacy gaps that exist in the standards, so Kantara should provide privacy principles. We should close that gap.
Proposal The working group charter should initially focused on recommendations for government-issued credential requirements, and a phased focus on private sector issued credentials. Then we can come back to how users are contemplated. Second recommendation, to include background or purpose copy to note that intention is to ultimately be of service to end users and relying parties by ensuring privacy enhancing mobile credential ecosystems are established.
For next call |