2024-09-05 IAWG Meeting Notes DRAFT

quorate

Ready for review

TBD

2024.08.29

• 2024.08.22

Motion passes with no objections.

• Draft 2 of 800-63-4

• Good approach seems to be “divide and conquer” - everyone looks at their areas of interest.  Carol is looking at the more global picture.

  1. 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)

  1. 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

  2. Richard: Only looked at 63A, but they seem to have brought enrollment into this section, which was previously in 63B

     1. 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.

  3. 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?)

  4. Concept of fair evidence is tricky-how to best do it?

  5. Jimmy: worth it to determine what’s realistically available in terms of IDs?

     1. Must consider equal/equitable access

  6. 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”.

  7. Josh: Noticed requirement that the issuing source perform something attended–how is this proven?

  8. 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.

  9. Richard: 

     1. Changes terminology for proofing - provided more structure but then after defining 4 types, they use different terms.

     2. Remote unattended is not addressed for IAL1/2. (not applicable for IAL3 as you can’t do remote)

     3. 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.

     4. NIST seems to have taken Kantara’s input on federation agreements/authority

  10. 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.

  1. Small group email chain (Richard and Jimmy have been working on a draft of additional criteria to address syncable authenticators)

  2. 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”.

     1. 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.