SAC 63C Sub -Group Meeting 2020-04-29

Attendees: Ken Dagg, Richard Wilsher, Martin Smith, James Jung, Sato Hiroyuki, Colin Wallis, Ruth Puente

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

Richard walked the group through the last changes added to the document.
Martin asked about SSI, Richard explained the meaning, Sensitive Subject Information, “information of a personal or sensitive nature relating to a Subject” and clarified it was agreed in the last meeting.
Colin said that he is worried about that NIST may include the notion of self-sovereign identity in the 800-63 rev4, he mentioned it is just a guess, but this is concerning him. Ruth mentioned that next week there will be a meeting with NIST, and then the question can be raised to them. Richard said that it can be discussed.
Richard added he has been trying to find an acronym which could be dropped in this criterion (63C#0110). Martin commented that it is being ambiguous as to whether exercise includes just identity related information or it could be tailored data, like medical records. Ken argued that he thinks it includes all of that, because it is information that is sensitive to the subject. It is not a PII, it is more than PII.
Richard pointed out about 63C#0110 that NIST says that they may or may not be Federation Authority. He thinks it would be wrong to write a criterion that references a Federation Authority when the requirement in NIST document does not explicitly reference that. If there is no Federation Authority, then the RPs and IdPs cannot meet this requirement.
In relation to 63C#0115, Richard raised the need to come up with a definition of Federation Agreement and probably some notes with it to explain the details. It is difficult to put this into a simple sentence. Ken agreed on this, it would work with row 16, making this somehow part of the Federation Agreement rather than the Federation Authority having to do something. Richard said that the problem with row 16 is with “The Federation Authority SHALL, when vetting federation participants (per 63C#0330) record, and publish to other federation participants, whether the participant conforms to the applicable provisions and requirements in the SP 800-63 [rev.3] suite”, it is an explicit NIST statement. The problem is that it is getting to a position where the Federation Authority might not exist. Ken stressed that the Federation Agreement is going to require that they all abide by. Richard argued how do they know if they meet these requirements. Ken remarked that either it is Kantara Approval or Certification from some other body, they have to meet the requirements of 800-63 suite. Martin said that all of the parties to be Federation Agreement together are in fact Federation Authority. Ken commented that the other option in there is, if they are approved bodies that can certify or approve RPs then, if it is approved by a certified body, then it is good to go.
About 63C#0110, Richard re-stated the criterion. He defined categories a) and b), and with those the criterion for #0115 would not be necessary.
63C#0150 criterion now is covered by 63C#0110.
Richard is going to make a further research about rows 59-63.
In row 61, about “This information is used by relying parties, as shown in the right side of Figure 5-4, to determine which identity providers meet their requirements”, Richard commented that if it is interpreted in a normative context, it allows to support other requirements. He stressed that it should be read in a fully normative sense.
Richard suggested in relation to row 81, to separate the requirement into two parts, one with the disclosure of information and the other with the measures. Richard added the comment “Do a PRA a) subsr activity b) processing info” in row 82, and in row 83 he wrote “Implement measures per PRA”. Ken said to Martin that when Privacy Risk Assessment was made, it was in essence a data flow diagram out in a note of the service. Martin asked where does the control of the data subjects enter the picture? Ken responded that it is necessary to look at what the user is told or the individuals that were going to collect the data. Richard commented that it is implied in many cases where there is reference to authorization consent because implicitly, if you fail to hit it, you are creating a bridge of privacy.
In relation to row 86, Richard mentioned his comment “My reading of §9.4suggests that these 'agency' refs are all to the same agency, not others with which it may interact”. He said that in the requirement, it refers to one agency. It is awkwardly expressed in the NIST text. Therefore, he interpreted the whole requirement as referring to one single agency. It was agreed up to row 89 (63C#0370).
Richard said that he re-wrote 63C#0380, now it says “The CSP SHALL communicate to any requesting whitelisted RP the timestamp and the outcome of the latest authentication event relating to the Subject”. Richard stressed that it is ok, notwithstanding the fact that NIST participation next week is pending.
Richard commented that he did not receive a response on the document he sent to Ken. Ken responded that he received it and that it is interesting. However, he stressed he needs a further thought on it. He added he cannot say he totally agrees with every definition, he finds the textual flow of the diagrams to be in many cases disruptive.
About 63C#0410, Richard mentioned that he does not understand properly what timestamp means, he thinks it is a record of a moment in time that has happened. Therefore, he has problems with the concept timestamp for future events. This is why he changed the wording there in letter e) as “an indication of the period of validity or the expiration time of the assertion, post issuance”. In point 7, Richard chose to interpret it as “a cryptographic authentication signature”. Ken commented that it makes sense. Martin asked if it is not being required the assertion to be encrypted, it just has to be signed. Richard confirmed it. The criterion in point 8 was also modified as “a timestamp for the latest successful authentication event relating to the Subject of assertion”. The requirement in row 103 was confusing for Richard, he tried to interpret it positively as “the assurance level of the authentication event, having regard to 63C#0040”. Ken argued he cannot find any sense to why they would not assign something. Richard pointed out that if an RP wants to receive an assertion at level 2, it is prohibiting from them conducting a transaction which requires level 3. It was decided to delete “having regard to 63C#0040” and this section was labelled as “Kantara-specific”.
63C#0420 criterion was modified as “The RP SHALL process assertions within the scope of the information defined for each sub-item to 63C#0410”. It was argued that it still not very specific, Richard suggested to add “defined for each sub-item to 63C#0410 i)”, this way it is limited only to the level of authentication, which he thinks this is what the text is trying to say. Ken suggested to leave it as it is and ask NIST what they mean. It was written to ask further questions to NIST, “each sub-item” was eliminated. It will be accepted for the moment (the requirement), but the questions for NIST will remain.
In 63C#0410, it was modified the a) criterion as “a unique identifier (within the domain of its service) for the Subject to which the assertion relates”.
Richard added a comment as a reference in 63C#0430 “ 63C#0410 a)” which also says Subject identifier unique within domain of a service. This requirement was agreed.
In relation to 63C#0440, Richard showed the “Digital Identity Guidelines” document to explain better the requirement. However, it was still confusing. Accordingly, Richard wrote for NIST “What is it that is being mitigated by this clause?”. This requirement still remains open.
Martin asked what the addressable market for assertion is, for Kantara assessment. Richard answered that he has never done the market and he would not do it, unless Colin wanted to. He mentioned that there are four CSPs who have had an interest in Federation criteria.
63C#0450 was agreed, and Richard added the comment “ 63C#0410 f)”.
In relation to row 108, Richard mentioned he modified the criterion text and now it says, “The RP SHALL not, once having consumed an assertion, use the assertion’s expiration to [artificially] limit or extend the Subject’s session’s duration at the RP”. Richard asked if the group agrees with the change. Ken commented that he would change consumed to accepted, Martin agreed. Ken said that for him artificially does not add anything. The final version of the criterion was “The RP SHALL not, once having accepted an assertion, use the assertion’s expiration as a reason for limiting or extending the Subject’s session’s duration at the RP”. It was agreed.
Richard commented that a new SAC suite review is coming up, xAL3, and actually the agreement between the sponsor and Kantara has been concluded, therefore the group can start working on this.
About 63C#0480, Ken said he is ok with it, but his question is: “is it needed to provide guidance to folks? What sort of measures?”. Accordingly, Richard modified the criterion as “The CSP SHALL implement within assertions it generates measures to prevent attackers from manufacturing valid assertions or reusing captured assertions at RPs for which the assertion was not intended”.
Richard asked Ken why he did not like the criterion in 63C#0500 and 63C#0510 assuming these references hold. Ken clarified that he prefers the text to say, “covered by” instead of “see”, because then you have criteria. Therefore, 63C#0480- 63C#0510 were agreed.
Richard will add questions 10 and 11 to NIST.

Browser not supported