2023-02-08 Meeting notes

APPROVED


Date

Feb 8, 2023

Attendees

See the Participant roster

Voting (5 of 9 required for quorum)

Participant

Attending

Participant

Attending

1

Aronson, Marc

Yes

2

Chaudhury, Atef

Yes

3

Davis, Peter

 

4

D'Agostino, Salvatore

Regrets

5

Hodges, Gail

Yes

6

Jones, Thomas

Yes

7

Thoma, Andreas

 

8

Wunderlich, John

Regrets

9

Williams, Christopher

Yes

Non-Voting

Participant

Attending

Participant

Attending

1

Auld, Lorrayne

 

2

Balfanz, Dirk

 

3

Brudnicki, David

 

4

Dutta, Tim

 

5

Flanagan, Heather

Yes

6

Fleenor, Judith

 

7

Glasscock, Amy

 

8

Gropper, Adrian

 

9

Hughes, Andrew

 

10

Jordaan, Loffie

Yes

11

Krishnaraj, Venkat

 

12

LeVasseur, Lisa

 

13

Lopez, Cristina Timon

 

14

Snell, Oliver

 

15

Stowell, Therese

 

16

Tamanini, Greg

 

17

Vachino, Maria

 

18

Whysel, Noreen

 

Other attendees

  •  

Goals

  • Check-in on work progress

  • Review draft outline and status of writing tasks

Discussion items (AKA Agenda)

Time

Item

Who

Notes

Time

Item

Who

Notes

5 min.

  • Start the meeting.

  • Call to order.

  • Approve minute

  • Approve agenda

@Christopher Williams  

Called to order: 10:03 PT

Quorum reached: Yes

Minutes approved

2023-02-01 Meeting notes

0 min.

Open Tasks Review

All

 

15 min.

Workgroup Charter Update

@Christopher Williams

@Heather Flanagan (Unlicensed)

Present, review, and (hopefully) vote on the updated Work Group Charter

  • Group requests more time to review the edits for the most recent issue

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.

      • That’s where Kantara might fit into the model. The Issuing Authority might follow guidelines from AAMVA, and those guidelines might include pointing to Kantara’s work. Kantara is a subset of a wider set of guidelines.

    • 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.

    • Will take this up next week in response to comments that must be added to the draft charter. The above will introduce changes (at least) to Audience and Purpose

For next call

  • Review the charter, provide feedback to the chairs and writer

5 min.

Other Business



 

 

Adjourn



10:42 PT

Next meeting

Feb 15, 2023

Action items

@Heather Flanagan (Unlicensed) to continue to collect proposed changes to the charter and provide an updated version for discussion on the Feb 15 call.