Attendees:
Voting Participants: Andrew Hughes [Ping], Jimmy Jung [Slandala], Mark Hapner, Martin Smith, Richard Wilsher [Zygma], Mark King, Mark Hapner, Chris LaBarbera [Verizon], Zaid AlBukhari [NextGenID]
Non-voting Participants: Mike Magrath [Easy Dynamics], Lorrayne Auld, Sarath Laufer [AU10TIX], Jazzmin Dowtin Yehoshua Silberstein [IDEMIANotarize]
Staff: Lynzie Adams, Kay ChopardAmanda Gay
Proposed Agenda
Administration:
Roll call, determination of quorum
Minutes approval
Kantara updates
Assurance updates
Discussion:
Defining an IALx API
800-63-3 Criteria Issues to Resolve - continue work through criteria updates, including revisions to Supervised Remote criteria (#0490-#0580)
Any Other Business
...
Jimmy Jung moved to approve the draft minutes from the July 13th August 3rd IAWG meeting. Mark Hapner seconded the motion. Motion carried with no objections.
Kantara Updates
Amanda Gay started with Kantara this week and will be providing additional support to the IAWG secretary role for agendas, minutes & GPA processing.
Assurance Updates
n/a
Discussion:
Defining an IALx API
Central question being considered: What would it take to define an API for IAL levels?
The idea being that many, if not all, ID proofing services being offered are API based. The way IAWG has defined the concepts of IAL conformance to the criteria, there is no hard line on what the boundary is on an identity proofing service. Two reasons - 1) there is a handoff point for binding the proofing event to the authenticator - could be any parties responsibility and 2) some IDV proofing services just don’t offer every possible capability of 800-63A proving. People are pushing for a more standardized way for an API to be IAL conformant. We need to consider what can be tested versus what has to be assessed. And what would it mean to call an IAL2 API and get a result. Is this something we can handle in Kantara?
Richard noted that CO#0100 requires the CSP to provide a detailed spec which defines how a user of the service can configure it so as to be assured of receiving a service which at least meets the applicable Assurance Level baseline. The issue is the CO_SAC is currently not mandated (though it has been recommended to change that). We aren’t in a position to do any meaningful testing so it’s a question if it’s worth putting our resources into that.
This discussion and decision needs to happen soon. Richard feels that could potentially need it’s own work group to stand it up if we go that route. Who are the Kantara members asking for this? It sounds like it’s the consumers of our approved services that are asking. Chris feels like it’s commoditization and outside the scope of what we are trying to do. Yehoshua agreed. Especially with rev.4 still lingering that could change what IAL is. Jimmy doesn’t buy ‘security in obscurity’ but think we need to articulate the question a little better and understand what these folk are looking for. We should reach out to existing providers - especially those with APIs - and asking what they think. And is there a way to characterize theirs that could loop into the work we might take on. Andrew agrees - and that helps us determine if there is a need for such a thing.
Yehoshua asked if we are referring to an API for performing identity proofing or an API for relying on a completed identity proofing? Andrew believes it’s mostly the latter. Richard noted that this eliminates component providers from the scope. Andrew feels that’s part of the bigger discussion - Is there a standardization point or not? And if so, what are we standardizing? Andrew is going to create a better description of what the problem is and what might need to be solved. Then we can have a more focused discussion to see if there is any merit in moving forward.
Mark Hapner mentioned that one main challenge in determining if this is a good idea is if we can come up with a practical way for encapsulating the complete workflow of multiple information exchanges through different technologies.
800-63-3 Criteria Issues
The group continued to work through issues raised from ARB, assessors, etc that must be resolved. Notes are in the document as well.
63A#0490 - #0580
| View file | ||
|---|---|---|
|
Any Other Business
n/aJimmy summarized the email exchanges about these criteria over the past week. Lorrayne & Maria cited some examples where supervised remote might show up in IAL2. This might impact how we think about these requirements. Richard suggested that Lorrayne, Jimmy, Maria, & Richard should huddle and make a determination on the criteria and propose that to the group at the next meeting. Lorrayne suggested looking at §3.2 for additional information.
63B#0600
Accepted the changes as proposed on issue tracker.
63B#1680
After a lengthy discussion over the NIST meaning, it was determined that only federal agencies are required to have digital identity acceptance statements (DIAS) - though the rest of the source text in §5.2.10 is speaking to the broader service provider. It appears to be a split criteria where both the CSP and agency have a part. Mike stated that according to 63B, the DIAS falls to the CSP to write. Lorrayne & Mike noted that §5.1 and §5.5 of the base volume has more about DIAS (agencies SHALL develop a “Digital Identity Acceptance Statement”, in accordance with SP 800- 53 IA-1 a.1) and contradicts what 63B appears to say (the CSP SHALL…. include this migration pan in its DIAS). Andrew summarized that item 4 in the NIST language is mis-categorized and we should alert them to this if it’s not already a proposed change in the rev.4 text. Lynzie will send an email to NIST regarding this. For our criteria, “the CSP” is changed to “Federal Agencies”.
This issue made the group recognize that more attention needs to be paid to the base volume when creating rev. 4 criteria.
§6.1.2.2
It’s not in scope because the SHALL in “Before binding the new authenticator, the CSP SHALL require the subscriber to authenticate at AAL1” is reliant on the MAY in the previous sentence. Richard proposed that the wording could be changed to “If the subscriber requested that the account be upgraded to AAL2… then, the CSP SHALL” but doesn’t know that’s it’s worth it.
Andrew thinks this should be submitted to NIST as a rev. 4 comment as well. Andrew believes “If the subscriber’s account has only one authentication factor bound to it (i.e., at IAL1/AAL1) and an additional authenticator of a different authentication factor is to be added, the subscriber MAY request that the account be upgraded to AAL2. The IAL would remain at IAL1” is incorrect and shouldn’t be a MAY - and likely needs reformulated. Are they intending to say all CSPS shall allow this thing to happen - and if they do allow it, do it this way? Or is it truly a permission?
Jimmy noted that though it starts off with a MAY, if they choose to do it, there are requirements. And we’re not requiring them. Richard continues to feel we should not bother changing it - but make a note to revisit in 63-4. Richard thinks we need to consider the SHOULDs and MAYs more in rev 4 than was done in rev 3.
No change right now. But watch for use of control statements in rev-4.
63B#1900
Richard thinks that ‘is obligated to do so’ in part d) covers us not having to give notice to the subject. Jimmy noted that it appears d) isn’t even part of NIST text - just a Kantara-specific criteria. Richard mentions its because we have other clauses that says CSPs have to meet all legal obligations.
Any Other Business
Jimmy mentioned that NextGenID held a Next Generation Federal ICAM User Group (NGFIG) last week, initiated by the Treasury & HHS. It was mostly US Government attendees. Jimmy spoke a bit about Kantara - mentioning the PEMC & Deepfakes groups. Watching them talk through their implementation of supervised remote - in the federal space you can do supervised remote but you can’t do issuance remote. How that works out for them will be interesting. There is a benefit - but it's limited in the need to physically give something still.