2023-01-04 Meeting notes

Aronson, Marc

Yes

Davis, Peter

D'Agostino, Salvatore

Yes

Hodges, Gail

Yes

Jones, Thomas

Yes

Krishnaraj, Venkat

Thoma, Andreas

Yes

Wunderlich, John

Yes

Auld, Lorrayne

Balfanz, Dirk

Chaudhury, Atef

Yes

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: 13:01 ET

Quorum reached

Minutes approved:

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

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

5 min.

Open Tasks Review

All

See updated update (previously assigned to @Tom Jones )

• see updates to the Implementor’s Guidance Report Verifiers)

40 min.

Draft Report Discussion

@John Wunderlich 

Report from Implementor’s Report sub-group

• Draft Google Doc NEW VERSION: Privacy Enhancing Mobile Credentials Workgroup Draft Implementor’s Report (v2)

Notes:

• Verifier section

  • John has revised the wording to the framing section for Verifiers to start establishing a virtuous circle tieing vendors to verifier

  • Each subsection now has an explanation of the principle, then a descriptive use case example, then an italicized version of the requirement

    • What are the requirements in italics? Why do we need more than what’s in the explanation? The requirement only applies to the example; we’re not trying to write the requirements for everything. This document is about guidelines, not formal recommendations. Consider explicitly explaining the use of italics (a “how to read this document” at the start of the doc)

    • for UC2 - it seems to describe a mechanism for unlocking the data (biometric proofing), but doesn’t touch on what data is released. Is that correct? Yes. Should this be more purpose and field driven? Why these use cases? They represent three major buckets of problems / categories of scenarios (data + field focused, device focused, and relationship focused). Should we be explicit that thinking through any one example, implementer needs to consider all of the categories of scenarios covered in UC1-3. Atef to draft text.

  • Data Minimization: but UC1 talks about data retention. Is that what we want? Minimization is more than just the collection; it’s also about use, sharing, retention, etc. For each purpose of processing, data minimization is a requirement across the lifecycle for that purpose. Perhaps UC1 could cover the processing instead of the retention?

    • If data minimization includes all processing, do we need separate principles for retention and collecting? We are inheriting the principles as articulated by ISO. We might need a better explanation to distinguish them.

  • Use, Retention, and Disclosure: perhaps this needs to be the more granular one than Data Minimization?

  • The verifier shouldn’t have to trust the device, they should trust the issuer. Trying to figure out how to trust the device is turtles all the way down. Need to distinguish whether the device is part of the trust chain or not. As an example, we do trust the iPhone in many ways, including to do payment verification via biometrics. Some debate whether the trust is about the transmission. or whether it’s more than that. The issuer must test the device to establish the necessary level of trust (part of the mdoc).

  • Privacy compliance - need to be more clear about who the documentation is for; it isn’t just about documenting the law/regulation.

  • Group requested to offer suggested changes via Suggestion mode in the new doc

5 min.

Government-issued digital credentials and the privacy landscape WP updatte

@Heather Flanagan (Unlicensed)

• Introductory text drafted. See

Requirements Review

@John Wunderlich

Pending

Other Business

Adjourn