2024-01-17 Meeting notes

Chaudhury, Atef

Jones, Thomas

Y

Krishnaraj, Venkat

Thoma, Andreas

Wunderlich, John

Y

Williams, Christopher

Y

Auld, Lorrayne

Aronson Mark

Balfanz, Dirk

Brudnicki, David

D'Agostino, Salvatore

Davis, Peter

Dowtin, Jazzmine

Dutta, Tim

Flanagan, Heather

Fleenor, Judith

Glasscock, Amy

Graaf, Irene

Y

Gropper, Adrian

Hodges, Gail

Hughes, Andrew

Jordaan, Loffie

Y

LeVasseur, Lisa

Lopez, Cristina Timon

Pasquale, Jim

Snell, Oliver

Stowell, Therese

Sutor, Hannah

Y

Tamanini, Greg

Vachino, Maria

Whysel, Noreen

5 min.

• Start the meeting.

• Call to order @ 1:05

• Approve minute

• Approve agenda

@John Wunderlich

Called to order: 1:05pm EST

Quorum reached: Y

Minutes to approve: APPROVED 1:23pm EST

10 min.

Scheduling

All

We have received a request to consider re-schedule the call

Note: @John Wunderlich unavailable for the next 4 or 5 meetings at this time.

5 min.

Open Tasks Review

All

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

5 min.

Discuss promotion of requirements from Draft/Under Review to Candidate

All

MOTION: Proposal for 4 requirement statuses:

• Draft (when it first comes in)

• Under Review (when it goes under discussion in a meeting)

• Candidate (voted on with quorum)

• Excluded (voted on with quorum)
  
  Anyone can make recommendation for vote. When in Candidate or Excluded status, there is no further discussion on it unless we vote it back down to “Under Review”

DECISION: APPROVED

30 minutes

Requirements Report - Individual Requirements Discussion

1.1 Selected Data Release

All

1.1 Selected Data Release (Issuers) Candidate

Ongoing discussion:

• Added related and matching requirements for Verifiers and Providers

• Added non-controversial change to 1.1

• John added a note - selective data release- when asked for a certain number of elements, person should be able to respond back and only accept individual elements.

  • Can user also disclose more information than is requested? Concept of additional minimization - additional clarification

  • in MDL you can only release what’s been requested, but no technical controls to prevent it from happening

    • Is it always that the user can choose to do less, but never can the user do more? If that is the intent, we need more language to make that clear

• Issuer must ensure case where holder does not say “yes” to everything

• Is “Choose to Release” always a yes/no answer? Or does holder have the ability to respond with fewer elements than requested.

  • Yes/No qualify as selective release? Consensus seems to be “no”

  • If you’re requested to release your DoB, but you want to give data over 21 statement, do you have that ability?

    • Matching requirements for different parties, or do we combine them all into one requirement?

      • They need to be separate because they are different requirements.

      • For verifier, should be “data minimization”

• Will be splitting out requirements into V,I,P

  • Providers: Selected Data Release

  • Issuers: Selected Data Release Capability

    • The issuer always has the control to provision. Possible future state - Issuer doesn’t know which wallet it is being provisioned into, because it’s the user’s choice

    • Issuer needs to know what wallet provisioned into, so it can manage lifecycle

    • Standard in place so eventually you could write your own wallet that follows the standard

    • Circumstance where credentials are issued, are time based, and don’t phone home (ideal model)

• Issuer could say “I will provision into your wallet if it follows XYZ standard”

Decision:

Requirement 1.1 moved to “Candidate” , via quorum.

1.2 Context for User Processing Draft

1.3 Consent for Verifier Processing Draft

1.4 Selected Data Request (Verifiers) Under Review

• Add “data elements that are required by policy must be requested. Data elements that are desired for other business purpose may be optionally requested. Optional requests must be opt-in”

  • User gesture approval for anything that’s not required

• Do we need a separate requirement for Verifiers that says that they won’t bundle things together that are for different purposes?

  • Limit to data on credential vs data that would be outside of it?

    • Verifier wouldn’t know this

    • 4.1 and 4.2 are related requirements - limiting collection

• Statement should only be first sentence. Rest of it should be moved to description, if included at all. We shouldn’t be overloading these requirements - make them as simple as possible.

  • Can we delete the word “set” as set implies more than 1 transaction?

    • Yes.

  • Should we also remove “purposes” - implies you can ask for more than one thing at the same time.

    • Reality is that it’s a single transaction to avoid overloading holder with multiple requests

  • Should require more than one gesture to get more info than users are requesting

    • This works if the holder is made clear about what the current transaction is.

    • Verifier must ensure that holder knows what the transaction is - different requirement, but related

• “Data elements that are desired for other business purpose may must optionally be requested” - is this still accurate?

  • Intent is “i want your email to send your offers”

  • Do we need to add “via separate request” to the end of the sentence?

  • User experience implications to too many requests

• Concern with “separate” - might need a different verb, like “Distinguish”

• API from verifier - you want verifier to make one request to user, user has one screen with all of the options

  • Separate request packets makes user have to deal with multiple screens

• Added example to requirement

• CA DL as issued today has optional capability like this. Different things, but it’s a single request.

  • How do you convey optionality?

• Could other requirement be that once you’ve accepted it, you’ve accepted it - you can’t get data, then give another requirement. Once you’ve given up data, you shouldn’t have to give up more data.

  • Friction free if only required info

  • Design pattern - another consent required for optional info

  • Do it once, and there can never be another request for more required data
    
    

1.5 Selected Data Release (Providers) Draft

1:57pm EST

Adjourn