Meeting Status Metadata
Quorum | |
---|
Notes-Status | Status |
---|
colour | Blue |
---|
title | Ready for review |
---|
|
|
---|
Approved-Link | TBD |
---|
Info |
---|
The meeting status metadata table is used for summary reports - copy the status macros from the table in these instructions: Quorum: Status |
---|
colour | Yellow |
---|
title | not quorate |
---|
|
Notes-Status: Status |
---|
colour | Blue |
---|
title | Ready for review |
---|
|
Approved-Link: Insert a link to the Meeting Notes page holding the approval decision for this notes page |
Agenda
Administration:
Roll call, determination of quorum.
Minutes approval
Kantara Updates
Assurance Updates
IAWG Actions/Reminders/Updates:
ISO 17065 Discussion Items
Group Discussion:
Any Other Business
\uD83D\uDC65 Attendees
...
Nonvoting:
Staff:
...
Andrew Hughes, Deepanker Saxena, India Donald, Jimmy Jung, Mark King, Richard Wilshire, Scott Jones
Non-Voting: Eric Thompson,
Guests: Josh Rooke Ley
Staff: Lynzie Adams, Kay Chopard, Carol Buttle, David Nutbrown, James Keenan
Quorum determination
Meeting is quorate when 50% + 1 of voting participants attend
There are <<nn>> <<12>> voters as of <<YYYY<<2024-MM09-DD>>05>>
Approval of Prior Minutes
...
Motion to approve meeting minutes listed below:
Moved by: Jimmy Jung
Seconded by: Andrew Hughes
Link to draft minutes and outcome | Discussion |
---|
| Motion passes with no objections. |
\uD83D\uDDE3 Discussion topics
Time | Item | Presenter | Notes |
---|
| | | Good approach seems to be “divide and conquer” - everyone looks at their areas of interest. Carol is looking at the more global picture. Also consider 800-63 in its own “bubble”-if you try to compare with other schemes, the conceptualization makes it too confusing.
Scott: How much change is present from the last version to this most recent version? (1st version of rev. 4 v. this 2nd version - clarification) Andrew: Notable changes include syncable authenticators, wallets as federated, clarifying the place/type of proofing interactions (remote/supervised), volume C poses problems as Federation is hard to do when not everyone does federated technologies Richard: Only looked at 63A, but they seem to have brought enrollment into this section, which was previously in 63B Seems that NIST is trying to embrace the outcome of a successful proofing/”registration” (the retention of the proofing record and the binding to authenticators). Having a registry of digital records is one thing, but authenticator binding is a distinctly separate outcome.
Eric: Attended/remote/onsite, etc. and the requirement to validate all pieces of verify all pieces of evidence and fair validation (biometric validation against a driver’s license makes sense but what are the verification methods for a social security card?) Concept of fair evidence is tricky-how to best do it? Jimmy: worth it to determine what’s realistically available in terms of IDs? Must consider equal/equitable access
Richard: Persisted with an authoritative source having to have access to issuing source, and now they’ve got another option: a “creditable source”-requiring payment. Complications because often times what you need is not available from certain issuing sources, so the assessors/interpreters of the criteria must then fall back on “reasonable belief”. Josh: Noticed requirement that the issuing source perform something attended–how is this proven? Andrew: Mandatory requirements/expectations of confirmation (Kantara’s response has been to have their own requirements that stick somewhat closely to 800-63, but also try to fix some of it). Will be included in a comment. Richard: Changes terminology for proofing - provided more structure but then after defining 4 types, they use different terms. Remote unattended is not addressed for IAL1/2. (not applicable for IAL3 as you can’t do remote) Introduced a “service definition” - problematic to have it go as far as a published practice statement (could reveal weaknesses/competitive advantages). Could be good to have a service definition that describes mutual obligations and expectations but how this fulfilled is not clearly defined. Telling CSPs how to implement a published definition of policy with a practice statement might be too in the weeds. NIST seems to have taken Kantara’s input on federation agreements/authority
Andrew: 800-63 written for federal agencies, but pockets of material do pop up from federal bridge, which don’t apply to broad commercial space.
Syncable authenticators update: Carol is reviewing and concerned about the “complementary controls” because it’s not well-defined. Potential for complications/risks. Cautionand direct feedback will be needed. Small group email chain (Richard and Jimmy have been working on a draft of additional criteria to address syncable authenticators) Richard: For the criteria that the CSP is not able to demonstrate conformance (as it is outside of the scope of its control)-add a statement to the guidance column in the SACs that says “if you can’t control the environment in which the authenticators were created, you have to simply rely on it”--mark it as “In scope/not applicable”. Email also included a notice with this qualifier (Kantara produced notice with an identifiable reference that would explain why these criteria would be deemed not applicable and convey the point that if a service which had gained approval, it did not have approval for the FIDO implementation, as these criteria were outside the scope of approval. Any other authenticators would be assessed and embraced within the approval).
Before next week: Carol will write up her thoughts to get things documented. Richard and Jimmy will continue their work on syncables. Group agrees to primarily focus on the “show stopper” issues and requirements lacking clarity/practicality. Carol will lead call on September 12, due to Identity Week conflicts.
|
| | | |
| | | |
✅ Open Action items
Info |
---|
Action items may be created inline on any page. This block shows all open action items from all meeting notes. |
...