Published-06-17-17-2017-08-17 Minutes

Attendees

It was discussed what we are trying to produce in the sub-group.
Andrew shared a straw man on 63B (Section 5.1.7) and asked the group if this was the right direction of the work.
Kantara Initiative Mail - [SG-800-63-3] Sample analysis of 63-3B requirements.pdf
5.1.7 analysis ACH.docx
There was a general consensus that the straw man was not what the group is trying to achieve and produce.
It was commented that the outcome of the group, should enable an assessor to assess that a CSP meets 800-63-3.

Andrew said that if our objective is to strict evaluate conformity to the requirements stated in -63, we should produce an assessment guide and instructions to some extent in order to have assessors assess in a similar ways and come to similar conclusions.

Richard W. stressed that it is not only a set of criteria which defines what is required, but discrete statements and evaluate if they need clarification.
Richard W. pointed out that assessors´s concern is that when reading the statement with SHALLs determine that the provide to the service meets the requirements, there might be a policy or practice statement.

Mark commented that it would be good to structure the claims in a useful way.
Richard W. suggested to break the source doc. down, identify the requirements text and make a number of discrete statements. For example in 5.1.7.1 there are 4 discrete requirements, so the CSP is aware on what they need to show to be compliant.

Scott highlighted that we should focus on criteria clearly identified list of what are the sets of requirements, get them all clearly articulated so that can be evaluated or assessed. We need to use a structure to formally express the content that can be evaluated in a rigorous way.
Richard W. commented that the current IAF SAC is beyond 800-63-2 in order to provide a more international approach.
In this sense, it was said that we should focus on 63-3 beyond just FICAM circle.
Scott reminded the group that in this phase we need to identify and document the requirements.

Mark to document and create a directed graph with optional and required edges on it that describes the spec (with JSON-LD)
Andrew Hughes to break down 63B
Scott to break down 63C