2020-04-22 Meeting Minutes

Attendees: Martin Smith, Nathan Faut, Sato Hiroyuki, Ken Dagg, Richard Wilsher, Colin Wallis, Ruth Puente

Apologies given in advance: Mark Hapner.

Draft reviewed during the meeting: KIAF-1450 SP 800-63C Service Assessment Criteria v0.07.0.xlsx

Ken introduced saying that it is getting closer for IAWG to start working on the level 3 criteria. It would be IAL3, AAL3 and FAL3 and they want everything to come out around the same time, therefore FAL2 and all the level 3 Service Assessment Criteria should be published around the same time.
Colin commented that he is aware that CARIN Alliance is very interested on what is going on here with respect to ONC TEFCA.
Richard pointed out that to date we have addressed 41% of the 63C SAC criteria.
Richard mentioned that he had a discussion with Ken, and he wants to float it with the group. It is based upon NIST phrasing (which he revised). What he proposed was to use a term in the text, in order to provide a hard criterion to interpret NIST phrases. He came up with the idea of SSI (Sensitive Subscriber Information). Martin commented that it is still being talked about information, he would not say tailored information, but information in identity management assertion. Richard responded that the idea is to find a quick solution for the next few weeks, to move forward with a review on these criteria and if it is necessary, this topic can be reviewed again. At the moment, Richard said he is proposing to define SSI as ‘information of a personal or sensitive nature relating to a Subject’. Ken commented that the value of this is when it goes back and look at how it views the term SSI against the requirements that NIST has stated, then it can be developed a definition for SSI that fits all the instances. He said that last week it was a record of almost eighteen or twenty criteria approved, but it was over two hours (an average going through sixty-eight an hour). If it continues like this, his guess is that to get the level 3 criteria, the group would be working until July-September 2021 and surely this is not wanted.
In relation to the Requirement ‘All RPs in an IdP’s white list SHALL abide by the provisions and requirements in the SP 800-63 [rev.3] suite’, Richard said he questioned who is going to make that determination? It says two things in the criteria: Federation Authority SHALL determine whether the participants conform to the SP 800-63 suite and then, the Federation Agreement SHALL, require that federation participants only include in their whitelist those federation participants, whom the Federation Authority has vetted and found to conform to the applicable provisions and requirements in the SP 800-63 [rev.3] suite. This way, it then becomes Federation Authority’s responsibility when vetting to make sure that the RPs and IdPs whitelists have met these requirements. 63C#0110 criteria 1 and 2 were agreed.
It was asked about 63C#0130 who is the authorized party. Ken clarified that it says in the KI_criterion that it is defined in the applicable Federation Agreement (see 63C#9999). Richard added that having made that observation, the question is whether the word Subject should be removed or not (in 63C#0140) and simply refer to SSI authorization decision. Ken agreed on removing the word ‘Subject’, also he added that from ‘use of subject’ further on has to go as well. Ken suggested that Richard should make a note on this to review it himself later, he believes it is not necessary to make it as a group. The note was added as: “Review all uses of 'Subject' in context of authorizations, ACTIONED 2020-04-23”.
63C#0270 was accepted.
In relation to 63C#0290, it was asked what dynamic registration is. Is it talking about Identity Proofing or what? Richard answered that it is allowing Federation participants to integrate with one another, it has nothing to do with proofing, it is registration of RPs and IdPs within a Federation. It has nothing to do with whether the other party has been vetted and accepted as being a suitable participant. Ken clarified they want to minimize the system administrator evolvement. The following note was added: “For what purpose registering - to join the federation? To be placed on a white list? NIST”. Richard commented that David Temoshok (NIST) is involved with the ISO meetings which seems is virtual. Probably he will not be available this week. 63C#0290 a was modified “publish to the extent necessary its configuration information”. Ken suggested to make a note on row 45 considering Martin’s concern about secure “MFS raised the qn as to the need to employ mutual authentication for IdPs and RPs. Input to rev.4”, it is a comment for NIST on improvement.
Ken noticed that in row 48 it says ‘CrP’, he asked if it should be Federation Agreement. Richard clarified that the reason why he wrote CrP was very deliberate. The problem with identity provider is that the term, which is used, is used to also inverse the management of credentials. Finally, the criterion was changed as “The CSP SHALL require the Subject or an authorized party (as defined in the applicable Fedn Agrmtn - see 63C#0320 c) to give a runtime SSI authorization decision/consent prior to the transfer of any SSI”.
Richard noticed that row 59 is empty, the criterion says: “see 0150”, he made a note to research it. Later, he said that he thinks it was left open as trying to put into Federation Agreement the requirement to be 63C rev. 3 conformant, but he said he will check this.
About row 76, Richard commented he did not consider necessary to actually write any criterion for this.
Richard repeated he will continue with the research about row 60 and 59 (including from row 79).
In row 77 Richard added “see #0320 c)”.
About 63C#0350 it was commented that this one does not provide any role for any control for the subscriber. Richard responded it does not explicitly, but by listing those clauses from a) to f) it does. Ken added that the essence of a privacy risk assessment (going back to his experience with the government of Canada), is basically to look at the information you have collected about individuals. Therefore, if it is a privacy risk to the individual it is subject to privacy risk assessment. Ken also said that if it is agreed to sell the data, that is not the issue, the issue is the transmission of the data under the contract that was signed. As soon as information is transmitted, then it is an outgoing of information about an individual that gets covered under applicable privacy laws.
Richard pointed out about 63C#0180 that it would be better to say “authorization” instead of “Subject request”. It was modified as “in response to a specific authorization (per Fedn Agrment - ref XXXX which SHALL be logged and recorded”.
In relation to 63C#0360, Martin said he disagrees on the word “policy”. It was added in comments to “ 4 input?”. Considering Martin’s comment, Richard proposed to re-write the criterion as “The CSP SHALL NOT make access to its services conditional upon the Applicant's provision of consent regarding SSI beyond that necessary to satisfy the applicable CrP and Privacy Policy”. Richard pointed out that this is the best that can be done in a bad situation. 63C#0360 was agreed.
In 63C#0370 Richard said that it is necessary to develop criteria.
About 63C#0380, Richard stressed that he could not understand this one, that he tried his best. It was asked if it is a kind of freshness check or something? Ken answered that he believes the same. Richard expressed that he thinks it is related to given authentication and that allows a session to open, it is a reference point. Ken said that whether it is successful or not it does not really matter, but what happens is that they have to be able to communicate information as to the time the last authentication event took place. At that point, to whomever they are communicating it will make the decision what they do with it. It was commented that the expected use, first of all, who you want to send it to, and secondly, maybe how often. Richard continued that the requirement is only to convey the information regarding the time, not even the outcome of it. It was added as a comment “Ask NIST - what knowledge of the authentication outcome is required? Is this not covered by following criteria? Otherwise, what use case?”. Ken said it is a suggestion for rev. 4, to please provide some use cases. It was asked if it is possible that what it is saying is that a second RP wants to know if it is authenticated lately to start a second session with them, that the IdP would communicate the time and the result to the second RP.
Sato commented about last point that the NIST requirement is that IdP shall communicate any information of the timestamp. If the CSP is not adequate, CSP must send timestamp. He suggested to remove “if”. Ken agreed with Sato. Richard said he will re-write this criterion later.
Ken apologized for leaving early.
About 63C#0400 it was commented that the requirement is written in sort of passive voice, it was also argued that it is not clear what work the CSP has to do to support any of those protocol options. Richard remarked that right now, it is not possible to determine meaningful assessable criteria for this. It was added as a comment “Seek NIST clarification- is it the intention to oblige the CSP to support single sign-out (e.g.)? FAQ update?”.
Richard commented he has had a question on his mind, it is about inviting NIST to discuss with the group the questions that are coming up. Richard stressed that a recommendation should be written to the Chair. He said that they could be convinced that there is sufficient case to fix now and not later, that could be helpful. Richard will suggest this to Ken.