Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#ParticipantAttending
1Davis, PeterY
2Hodges, GailY
3Hughes, AndrewY
4Jones, ThomasY
5Thoma, AndreasY
6Williams, ChristopherY
7Wunderlich, JohnY

Non-Voting

#ParticipantAttending
1Aronson, MarcY
2Brudnicki, David
3Dutta, Tim
4Fleenor, Judith
5Gropper, Adrian
6Jordaan, LoffieY
7LeVasseur, Lisa
8Snell, Oliver
9Stowell, Therese
10Tamanini, Greg
11Whysel, Noreen

...

TimeItemWhoNotes

Call to Order

If quorum:

  • Approve agenda
  • Approve minutes
  • Meeting called to order at 13:03 Eastern
  • The meeting has (n't) go got quorum
10 min.Actions or issues from prior meetings

See tasks on Meeting Page

Reviewed completed tasks

40 min.Report content discussion & reviewAll
  • discussion about the use cases
    • scope of the use cases - focus on the interactions of the Primary Actor in their journey to fulfil the business requirement
    • Peter: the actual business requirement (of the venue) for Communicate a Credential Presentation is actually "Obtain proof of age to fulfill regulatory obligations"
    • Tom: There are actually a set of Purposes that are the focal point for the Business Requirement
    • Andrew: we should look at each actor in the role of Primary Actor - because each Actor could have different desired actions - that might not appear if looking at steps from certain other actors' point of view
    • Christopher: Holders will never read these specifications - only developers/providers/organization - because they must implement something
    • PEMC shall use this convention: Use Cases describe the steps taken by Actors. Actors can only be Humans. 
    • e.g. the Reader software designer must fulfil requirements of their Primary Actor - the operator of the Reader software. The operator of Reader software has business (and technical) requirements that are determined by that operator's Stakeholders e.g. regulatory, statutory, business customs, usability obligations and stakeholders (reminder: an Actor is a special type of Stakeholder that interacts with the System). Note: the stakeholder interests and operator's requirements must be run through the "privacy enhancing" lens - and maybe this influences the privacy defaults 
    • Christopher: there is no guidance within 18013-5 to Reader developers about what to do if the Presentation does not return a specific piece of information e.g. date of birth AND Age_over_nn. There are 18013-5 requirements for what the Holder's application must do. ie the Holder's application behaves in Privacy Enhancing ways - but nothing for Reader developers on how to develop Reader software in a Privacy Enhancing way. Same concerns apply to the developer of Issuer software - guidance about how to build the system in a Privacy Enhancing way.
    • Tom: note that concrete use cases are more like the 'harmonization of the rules' material from Tom
    • John: task assignments for the initial drafts for Abstract Use cases
      • Loffie to create an initial draft for Issuance
    • Gail: PEMC needs to ensure alignment with AAMVA implementation guidance & Future Identity Council guidance
    • Christopher: raises concerns about scope of user stories - ensure that PEMC remains focused on digital/mobile credentials - stay away from the other topics that are not related
      • Try to include 'open issues' section in user stories
5 min.Adjourn

Meeting Adjourned at 14:00 Eastern

Next meeting

 


Action items

  •  Loffie Jordaan to create an initial draft for Issuance use case
  •  Gail Hodges to present to the PEMC meeting overview and some specifics from the FIC guidance material 
  •  Loffie Jordaan to present to the PEMC meeting overview of the AAMVA implementation guidance material
  •  
  •