Kantara Initiative IAWG 800 63 3 SubGroup Kickoff

Kantara Initiative IAWG 800 -63 -3 Sub-Group Kickoff 2017 -08 -10

Agenda 1) Scope of the sub-group 2) Ground rules for requirements decomposition -Requirements Naming Scheme -Requirements Data Model 3) Work Plan 4) Timeframe 5) Participation - sub-group members 6) Logistics 7) Ao. B (Assessment method granularity) © Copyright 2017 Kantara Initiative, Inc.

Why are we here? 1. Produce a list of requirements from SP 800 -63 -3, 63 A, 63 B and 63 C 2. Document the assessment methods used to evaluate compliance with those requirements 3. Determine if the Common Organizational SAC from IAF 5. 0 is still applicable. © Copyright 2017 Kantara Initiative, Inc.

Proposed ground rules for requirements decomposition 1. "The Rule of SHALL": A requirement is recognized by the verbs SHALL and SHALL NOT contained in a normative section of the source text. 2. "The Rule of SHOULD": A recommendation is recognized by the SHOULD or SHOULD NOT verbs. 3. "The rule about names" requirements must follow naming scheme to produce uniquely identification - tagged in a way that will help the reader find the source. © Copyright 2017 Kantara Initiative, Inc.

Proposed ground rules for requirements decomposition (Continuation) 4. "The rule of sentences": requirement must be expressed as a simple, complete sentence, with a subject, verb and perhaps object. The source text may be reworked to break down to "atomic" requirements. 5. "The rule of accountability": requirements must apply to something (actors may include: RP, agency, CSP, applicant, subscriber, assessor). When the source text is written in passive voice such that the actor is unclear (e. g. A 4. 2. 1), rework the requirement to be active (for example, from “Identity proofing SHALL NOT be performed to determine suitability or entitlement to gain access to services or benefits” to "The CSP may not use the results of identity proofing to determine suitability or entitlement to gain access to services or benefits. ") 6. "The Rule of Conditions": everybody knows that requirements are required, except when they are optional. We need to be clear about any conditions, otherwise requirements are mandatory. Some requirements will apply only at certain assurance levels. In some cases there's a choice, for example A 4. 4 states that at IAL 2 CSPs SHALL proof according to either 4. 4. 1 or 4. 4. 2. © Copyright 2017 Kantara Initiative, Inc.

Proposed requirements Naming Scheme 1. The first character of the requirement name denotes the source document, it shall be either “ 3”, “A”, “B” or “C” 2. Subsequent numbers denote the section number in which the requirement is found. (e. g. “ 4. 2”) 3. Numbered lists within a section use the list number (e. g. “ 4. 6. 5”) 3. Some sections will contain multiple requirements, and requirements will need to be broken into parts. Use small roman numerals for these (e. g. “ 4. 6. 5. i”) © Copyright 2017 Kantara Initiative, Inc.

Requirements Data Model 1. Every requirement will have: a. A name generated by a name scheme such as above b. A text that contains the wording of the requirement (before and after) c. A subject which is the entity or entities who are subject to the requirement. d. (sometimes) One or more conditions when the requirement becomes mandatory (e. g. “at IAL 2”, “when doing in person identity proofing”, etc. ) e. All of these attributes can be “calculated” from the source text 2. For each requirement the workgroup will derive one or more “assessment methods” – this is where the harder work begins © Copyright 2017 Kantara Initiative, Inc.

Work Plan l Step one: identification: Analyze the source texts with the rules above to create a list of the requirements and recommendations. l Step two: tagging. Tag the requirements to identify which ones belong to which AL, as well as which entities the requirement applies to, and any conditionality in the requirements. (WHAT, WHO, WHEN) l Step three: express assessment methods. Could include a list of standard evidence, common assessor and assessee activities, reporting templates…? © Copyright 2017 Kantara Initiative, Inc.

Timeframe Schedule: 11 meetings, 10 weeks l Step zero: find any pre existing work products to include in the mix l Step one: identification 8/10 -8/31 l Step two: tagging 8/31 -9/14 l Step three: assessment methods 9/14 -10/19 © Copyright 2017 Kantara Initiative, Inc.

Sub-group members Scott Shorter, KUMA – Coordinator David Temoshok, NIST Mark Hapner, Resilient Ethan Ayer, Resilient Aakash Yadav, OKTA Jenn Behrens, KUMA Kimberly White, Lexis. Nexis Pax Axelsson, SUNET (TBC) © Copyright 2017 Kantara Initiative, Inc.

Logistics l l Wiki space for recording meeting notes and statushttp: //kantarainitiative. org/confluence/display/IAWG/Subgroup+on+80063 -3? src=contextnavpagetreemode Google spreadsheet for the work product (maybe with a static snapshot saved once a week or so and uploaded to the wiki page) l Mailing list sg-800 -63 -3@kantarainitiative. org l l PM Support ruth@kantarainitiative. org Technical Support oliver@kantarainitiative. org l Weekly meetings on Thursday at 3 pm ET (Go. To. Meeting) © Copyright 2017 Kantara Initiative, Inc.