John Wunderlich to contact Voting members who have not attended the last three meetings and have not provided regrets to confirm if they still want to be voting members to make quorum more achievable.
Submit (any person can submit a requirement for consideration using the template (See How to create a requirement). The WG will set the status of the requirement to SUBMITTED
Review: At each scheduled meeting of the group, it will discuss one or more requirements, at which point attendees can make suggestions for revisions. After the meeting, the owner of the requirement or the chair should change the status of the requirement to REVIEWED
Revision: The proponent/author of the requirement or a person designated by the WG will revise the requirement following the meeting and, when complete, will change the status of the requirement to REVISED
Candidate: After revision, the requirement will return to the WG for discussion. Depending on the results of the debate, the status of the requirement will be set to one of the following:
REVIEWED Sent back to review for another round of revision
CANDIDATE If the group feels that the requirement is 'done,' the status will be set to Candidate - meaning that it will be considered for the recommendation report (we won't know for sure until all the candidates are ready and the WG can see them as a group)
NOT INCLUDEDIf the group feels that, after revision, the requirement is out of scope or is otherwise inappropriate for inclusion in the recommendation report,
The work group discussed the above process and there is a consensus that this is a reasonable starting point for the process.
The work group discussed the first requirement and a couple of issues arose:
It is the case that each requirement should be within the scope of the scoped implementor. If the requirement is for a Verifier, then it should be something that a Verifier can do and be tested, for example.
The template for requirements has been updated and each requirement that has already been written may need to be updated.
It turns out that the term Provider creates some confusion and we will go back to "Holder"
For Issuers, Holders, and Verifiers there may be a distinction between Controllers and Processors will need a clear articulation in the description of a requirement. For example, the organization that is doing an age verification check is the Verifying Organization (or Data Controller under the GDPR) but it will be using a Verifying System provided by another organization. In order for the age verification check to be Privacy Enhancing, the Verifying Organization has to select and use Verifying Systems that enable it to meet the Holder's reasonable expectations. What that means should be articulated in the Requirement Description so that each party understands their assignment.
John Wunderlich to update the Confluence Pages for the requirements created for the draft implementor's report so that they use the updated PEMC Requirement template
Authors of the other requirements should make sure that there is a page for each requirement and that the requirement is entered into the candidate requirements table.
To facilitate moving forward members of the work group should review existing requirements and add comments for each requirement so that action items and revisions can be identified and acted on between meetings.
Other Business
5 min.
Adjourn
Next Wednesday will be the Leadership Council, so the next meeting of the WG will be in two weeks