Attendees: Ken Dagg (Individual Contributor and IAWG Chair), Martin Smith (Individual Contributor and IAWG Vice-Chair), Andrew Hughes (IDEMIA), Richard Wilsher (Zygma), Nathan Faut (KPMG), James Jung (Slandala), Colin Wallis (Kantara Initiative), Ruth Puente (Kantara Initiative).

Draft reviewed during the meeting: KIAF-1430 SP 800-63A Service Assessment Criteria v3.1.4+IAL3.xlsx

Key discussion items

Richard mentioned that there were a couple of changes in the document since last week that he is going to show.
63A#3030: This particular requirement is effectively the same of IAL2, the wording is different. Richard proposed to eliminate the requirement and say “See 63A#0220 and #0230”. Martin commented that in column R it says “at the same strength”, while column H says “with a process”; he thinks it is a little ambiguous to say validated evidence at the same strength. Richard stressed not to confuse strength with strong. Andrew commented that it is being encountered the structural terminology problem with 800-63 where they are using the same label, he does not think there is a good way to solve it yet.
In relation to 63A#0220, it was added a note “Rev. 4 ‘Level f Rigour’?”.
Richard explained he changed slightly criterion 63A#0360 b). He said that if the subject is allowed to put information on itself, it would be validated again with the issuing source. He suggested to provide guidance, to clarify what is meant in here. Richard also commented that the CSP has to have some means of validating the address with some system of record, it could be perhaps a new utility bill, but the point is how it is done convincingly. Andrew said that this is when the issuing data base was legitimately updated, and the applicant is trying to tell you that if you go and check, this is what you are going to find in the issuers database. For this piece of evidence, this data field has changed, is changed at the issuing database but they have not reached the credential evidence yet because it takes time. The evidence does not reflect what is now in the issuing database, because sufficient time has not passed. Richard explained that guidance covers the specific case that Andrew is concerned about. Andrew said that the criteria is fine, it is just needed some guidance.
63A#3070: Richard asked if it is necessary to mention here “only”, for him it sounds redundant (considering the previous criterion). Andrew said it is confusing. Martin said he agrees with it. It was re-written as “Superseded by #3060”.
63A#3080: Richard asked what it is a ‘notification of proofing’, do you only send it if it is successful? or do you send it if it fails as well? Is it the outcome of the proofing? Martin asked what the purpose is. Richard said that he thinks that the real purpose is to tell someone that it works. Andrew commented that supposing the purpose of this is to establish a communication channel with the applicants, and that communication channel must have an address that is in the address record; therefore to actually confirm that the applicants can receive anything at the address record, you have to send something. Andrew explained that what NIST tries to describe in here, in addition to all the validation of address, is the ability to use this communication channel that was just validated to send the enrollment code in case the binding to the credential happens at a different time. It was commented that the requirement seems to suggest that you need both, a successful and an unsuccessful proofing. Richard said that it allows a break in the process between proofing and binding. Andrew mentioned that the full text in 4.4.1.6 item 3, Self-asserted address data is: “Self-asserted address data that has not been confirmed in records SHALL not be used for confirmation”. However, the IAL3 version of that statement is “Self-asserted address data SHALL not be used for confirmation”; thus, IAL3 is unclear and IAL2 is clear. Richard proposed to use this clause and make it apply for 2 and 3. Andrew suggested to look at the IAL2 address confirmation, just to make sure it was not edited out in IAL3 by accident. Richard argued that the idea is to make sense and provide criteria. Andrew said this is what he is suggesting. Richard suggested re-writing it as “proofing outcome”. Martin agreed. It was agreed.
Andrew said he is making a note to himself to make a comment to version 4. Was the intention to notify the person who is issuing source record that something is going on? Or was it to notify the applicants of the status of the proofing?
Martin said he is concerned about having a clear text that provides or let somebody bind a credential any length of time, it is not the length of time, it is a token without any encoding. Andrew responded he has an answer for that, it is in IAL2, in 4.4.1.6 Address Confirmation. Richard made a note on this in row 71 that there are two missing clauses. Andrew mentioned that indeed there is missing the clause 5 in this block of criteria. Richard mentioned he will make some research about this.
Richard found the clauses; he had not included it in which applies to IAL2.
Andrew commented that section 4.6 in 63A Enrollment Code, this is a structure problem with 63A. The normative text in 4.6 about Enrollment Code says, “An enrollment code allows a CSP to confirm the applicant controls an address of record as well as offering the applicants the ability to reestablish binding to their enrollment record”. Therefore, this does a purpose with what is being done with the Address of Records, it is because in 6.4 clearly says they control the Address of record.
Richard asked if clause 5 in 4.4.1.6 should apply for both IAL. He thinks that all of these criteria are applicable to both IAL2 and IAL3. Richard made a note in row 84 “Consider extracting for use at IAL2/3. He explained that in the absence of any qualification, it can be assumed that it applies for both.
63A#3090: Richard said that this requirement can be taken and reasonably, re-interpret that in terms of the criteria that is up wrongly consolidated with IAL2. Richard added a note “Refer to 4.4.1.6 rqts/criteria”.
63A#3060: Andrew suggested to add a note “Use 1^st paragraph 4.6 as guidance”. Richard added it.
63A#3100: It was deleted the final part of the criterion “…for the purposes of non-repudiation and re-proofing”, but it was written as guidance: “The fundamental reason recording the biometric data is for the purposes of non-repudiation and re-proofing”. It was agreed.
63A#3120: Andrew commented that he believes if 800-63 is checked, it can be realized that they do not use high baseline anymore, they probably use the term high impact system. He commented that it is safe to use high baseline because everyone will get it. Richard said that he will maintain high baseline highlighted for the other IAL3 things where it is clearly more demanding or different from. Guidance text was eliminated. The criterion was agreed.
Richard shaded yellow 63A#0330 criterion. It needs revision, a note was added “Align to NIST language”.
63A#3130: The guidance text was eliminated. The criterion was agreed.
Richard checked and 5.3.3.1 and 5.3.3.2 are applicable for both IAL2 and IAL3. Andrew mentioned that in 5.3.3.2 in the second paragraph, it refers specifically to IAL3.He explained that if that phrase “in addition to the IAL3...” was deleted, all the list of items would apply for IAL2 and IAL3. Andrew said that the editing mistake NIST made could be fixed and it does not excuse you from following IAL3 stuff when you are doing IAL3.
Richard stressed that it is an unsightly piece of writing, when he reads “In-person proofing at IAL3 can be satisfied in either of two ways”, he is inclined to think that all of 5.3.3 is exclusively for IAL3, but it is not the case at all.
Richard said it is agreed that 5.3.3 is applicable for IAL2 and IAL3.

Next steps:

Richard mentioned that the revision was done in 2-3 weeks. He commented that if he gets this document tided and sent out the revised version for next week, probably it would be spent 30 minutes confirming the changes and then, it could begin 63B SAC (AAL3).
Ken said that the other option is to make FAL3. Richard said it could be.

Browser not supported