2024-01-10 Meeting notes

Approved


Date

Jan 10, 2024

Attendees

See the Participant roster

Voting (3 of 6 required for quorum)

Participant

Attending

Participant

Attending

1

Chaudhury, Atef

 

2

Jones, Thomas

Y

3

Krishnaraj, Venkat

 

4

Thoma, Andreas

Y

5

Wunderlich, John

Y

6

Williams, Christopher

 

Non-Voting

Participant

Attending

Participant

Attending

1

Auld, Lorrayne

 

2

Aronson Mark

 

3

Balfanz, Dirk

 

4

Brudnicki, David

 

5

D'Agostino, Salvatore

Y

6

Davis, Peter

 

7

Dowtin, Jazzmine

 

8

Dutta, Tim

 

9

Flanagan, Heather

 

10

Fleenor, Judith

 

11

Glasscock, Amy

 

12

Graaf, Irene

Y

13

Gropper, Adrian

 

14

Hodges, Gail

Y

15

Hughes, Andrew

 

16

Jordaan, Loffie

Y

17

LeVasseur, Lisa

 

18

Lopez, Cristina Timon

 

19

Pasquale, Jim

Y

20

Snell, Oliver

 

21

Stowell, Therese

 

22

Sutor, Hannah

Y

23

Tamanini, Greg

 

24

Vachino, Maria

 

25

Whysel, Noreen

 

Goals

  • Review process for requirement creation and review

  • Begin work on 1.1 requirement

Discussion items (AKA Agenda)

Time

Item

Who

Notes

Time

Item

Who

Notes

5 min.

  • Start the meeting.

  • Call to order.

  • Approve minute

  • Approve agenda

@John Wunderlich

Called to order: 1:15pm EST

Quorum reached: Yes

Minutes to approve: APPROVED 1:59pm EST

https://kantara.atlassian.net/wiki/spaces/PEMCP/pages/310116353

5 min.

Open Tasks Review

All

Link to Recommendations (Commenter Link): Recommendations for Privacy Enhancing Mobile Credentials

5 min

Yearly Administration Tasks

 

Leadership Elections Results

Result of email ballot Jan 9, 2024

Chair: @John Wunderlich

Co-Chair: @Christopher Williams

Secretary: Vacant

15 minutes

Requirements Report - Logistics

@John Wunderlich

Review of process being proposed to deal with requirements. (See link to Google Doc above)

  • Draft When a requirement is first added to the Google Doc, it is in draft.

  • Submitted When a requirement is ready to be discussed by the group and is on the agenda for a workgroup meeting it is moved to submitted status at that meeting. A link to the meeting note or notes where the requirement is discussed is added to the requirement in the document. Also, individuals may take on tasks related to the requirement which will be tracked in the Google Doc.

  • Under Review Once a requirement has been discussed at a meeting, it is Under Review until the workgroup completes the discussion and changes to the requirement. When that is done the workgroup will vote or reach consensus that the requirement should either be included in the recommendation report or excluded.

  • Candidate Discussion on the requirement is complete and it will be part of the recommendation report.

  • Excluded Discussion on the requirement is complete and it will not be part of the recommendation report.

 

  • When initially added, DRAFT

  • Post-discussion, SUBMITTED - under open consideration

  • Comments welcome in Google Doc and during meetings

  • Deal with 1-2 requirements per meeting

30 minutes

Requirements Report - Individual Requirements Discussion

1.1 Selected Data Release

All

Discussion:

1.1 Selected Data Release

  1. Concern with the real human experience around the requirement. It is difficult to stand up in public and especially in a crowded place and refuse to share data.

    1. Operational circumstances may mitigate against selective disclosure. How do we want to deal with this? Initially, we said all requirements would be phrased as a “must”. We can add something to the statement that says “unless operationally infeasible” - but this leaves room for verifiers to say “we don’t have the right hardware, so not going to do this”

    2. We could also put a note in the description saying that this one may be disregarded under certain conditions

    3. The issuer should ensure…

  2. One of the benefits of the digital credential is that you don’t have to disclose everything in the credential. We’ve been referring to this as selective data release. Relying party only requests a subset.

    1. We want to see if there’s a different way to convey that you shouldn’t have to always release all of the data that you have

    2. Another way to do this, would be to say what the purpose is rather than what the data is.

    3. Purpose should be clear

  3. Maybe we should write this as a paired requirement - the purpose should be stated, the provider agrees, and grants access only to those elements.

    1. Maybe we rewrite it and it applies to Verifiers, Issues, and Providers

    2. For all 3, must take steps to ensure that the data released and the data collected is only the data for the purpose

    3. Does legal requirements up front simplify definition?

      1. We are trying to avoid legal requirements - technical and business doc.

      2. Need a statement saying, if we say “must”, but your legalities do not allow that, then the requirement does not apply to you

    4. Ensure that request is presented to holder so that the holder can understand what is requested, and choose to respond to it yes/no. The method by which is not the issue. The issue is that the use has to be informed about what is being requested.

  4. If we don’t address how to respond to request, it leaves open the door. The important part is to have the request clear for the holder to react to. The manner in which the holder reacts can vary.

    1. Even when they don’t, maybe there is a requirement that there is a record of this. In each case, the thing we are talking about is part of a record.

      1. Issuing authorities - requirement for transaction log

        1. Verifier has to make request not knowing if it’s ever seen this person before. Wallet needs to make the decision.

  5. Pre-defined “bundles” - the idea of pairing the two comments together for must allow of selective data release + pre-consent data bundles

    1. We could say “The issuer must ensure functionality allowing selective data release unless the entity and use case conforms to the requirements of an approved data bundle”

  6. Should we change requirement 1.1 to put it on issuers to only collect data needed for the purpose

    1. There can be more than 1 purpose in a request. Some of the data requested may be required and some of it may be optional.

    2. Privacy-enhancing - we should come down against blanket purposes. If you are asking for it and you don’t need it, then it’s not a PEMC.

  7. Challenges with “selective disclosure”

    1. I shouldn’t have to hand over all of the data in my credential if someone who needs some of the data - this is a pro of the digital world

    2. How we implement that could have different forms

      1. The user actions that proceed the disclosure of data has become the focus, and it shouldn’t be

  8. Keep the requirement on the issuer, but don’t call it selective data release

    1. Issuer must ensure credential can be partially shared - whatever standard it follows, allows some of the data to be shared, not all of it

    2. Wouldn’t this lead to different outcomes for users? Some wallets could be more privacy preserving than others. Is it appropriate that the user may be “tricked” into releasing more data in one transaction than another? There’s a place for UX, but also a high bar for privacy.

      1. There are other places where standards for wallets are being debated

      2. The nature of the releases of data would be under the control of the holder

    3. For it to be privacy-enhancing, the ecosystem to which that is issued, makes decisions about how they’re going to implement selective disclosure from holder or provider side. On part of verifier, they only request what is appropriate. This would be a related requirement for provider to holder, and another for the verifier, so that these 3 things hang together?

      1. Only requirement for wallet is that it allows user choice

      2. The idea of requirements being linked together if they need to be “back to back”

1:59PM EST

Adjourn

 

 

Next meeting

Jan 17, 2024

Action items