2022-12-14 Meeting notes

Aronson, Marc

Yes

Davis, Peter

D'Agostino, Salvatore

Hodges, Gail

Jones, Thomas

Yes

Krishnaraj, Venkat

Thoma, Andreas

Wunderlich, John

Yes

Auld, Lorrayne

Balfanz, Dirk

Chaudhury, Atef

Brudnicki, David

Dutta, Tim

Flanagan, Heather

Yes

Fleenor, Judith

Glasscock, Amy

Gropper, Adrian

Hughes, Andrew

Jordaan, Loffie

Yes

LeVasseur, Lisa

Lopez, Cristina Timon

Snell, Oliver

Stowell, Therese

Tamanini, Greg

Vachino, Maria

Whysel, Noreen

Williams, Christopher

• Start the meeting.

• Call to order.

• Approve minute

• Approve agenda

@John Wunderlich 

Called to order: 10:03 PT

Quorum not reached

Minutes to approve:

• https://kantara.atlassian.net/wiki/spaces/PEMCP/pages/121765889

5 min.

Open Tasks Review

All

See updated https://kantara.atlassian.net/wiki/spaces/PEMCP/pages/111247424 update (previously assigned to @Tom Jones )

20 min.

Draft Report Discussion

@John Wunderlich 

Report from Implementor’s Report sub-group

• Draft Google Doc: PEMC Early Implementor's Guidance Report (see changes to Information for Providers)

Notes:

• Reviewing Information for Issuers

  • Accuracy and Quality. Note that item doesn’t have any additional bullet points; is it just that simple? Yes, as far as we know. Some question about the term “ancilliary data” - that’s the information specific to the electronic credential itself. Accuracy and Quality without scoping statements might be confusing, even though some of the detail might be out of scope for our specification. “Quality” by itself is subjective. Maybe specify “and simultaneously maintain the Collection Limitation principle”. (Need to consider how to cross-reference within the document.)

  • Openness, Transparency, and Notice: this appears to be a closed list. Would it be better to say something like “meets generally acceptable security and privacy standards, including but not limited to…” thus putting the responsibility on the issuer to meet appropriate requirements. Make sure the language matches across the sections. Also, not sure about how the wallet shares data with others besides the user (e.g., backend sharing of data). Additionally, questions re: “salient features”. Are there any established requirements around what are to be considered salient/important features? Unfortunately no. Is there a better way to frame “educate consumers” to “provide customers opportunities to learn how their data is being processed clearly and transparently”? Educate may be overly affirmative. From an issuing authority’s perspective, it is easier to provide an opportunity, but from a privacy advocate’s perspective, is that enough?

  • User Retention and Disclosure: needs to include that wallets will not share credential attributes to other services or organizations without consent. The issuing authority must only issue into an app that only releases information upon consent of the Holder. The concern is secondary uses of data that are not directly in scope. We may be implicitly protected from this use case with the limits on presentation methods. Customers should know the significant, salient features of a wallet with respect to their personal information. Reminder that this section is that the issuer issues the information, but they don’t actually issue it to the wallet itself. This can’t be just about state-issued driver’s licenses. Some of this would actually be illegal for health data in the US. Could say that the issuer into a wallet (noting that not all issuers issue into wallets) that the issuers must abide by the requirements in the wallet section. Alternatively, the issuer has a responsibility that it protects the customer data; it decides whether to put something into a wallet, and if that wallet isn’t up to scratch, the issuer is liable. Note that for issuers that have legislative authority/liability, this makes sense. But there are a lot of issuers that don’t have that authority and cannot make that requirement, and the wallet capabilities belong in the provider section. We may need to indicate different types of Issuers. Not all issuers have the same capabilities, from a legal perspective. Put something in the framing section for issuers. What’s there now is accurate for state-issued credentials, but not for some of the other use cases. Need to reframe to encompass all the use cases, or create a new section. Not too many issuers actually issue into a wallet, so what we have doesn’t cover too many use cases. MIT tells you what wallet it will issue into; it will only issue into one. There is no user choice.

  • Tom’s suggestion is to strongly define the wallet section and point the issuer section to that. Credit cards are already being issued into a wallet, but are those the type of credentials we are trying to cover? Are they regulated with KYC requirements that would make them more like an official credential?

  • Note that the user should show intent more than consent (that’s the term of art in the wallet world). This may be something we add to the appropriate friction definition.

    • @John Wunderlich will figure out how to take this feedback into account for the three sections in this document

10 min.

Government-issued digital credentials and the privacy landscape WP updatte

@Heather Flanagan (Unlicensed)

• Heather is focused on interviews and research now, and is collaborating closely with the editors on the Government white paper. The holidays are definitely going to limit engagements until January.

Requirements Review

@John Wunderlich

Pending

Other Business

Adjourn