Attendees: James Jung, Mark Hapner, Richard Wilsher, Hiroyuki Sato, Martin Smith, Nathan Faut, Ken Dagg, Ruth Puente.

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

Key discussion items:

Richard suggested that if Kantara is going to offer a basis for assessing federations, it would be necessary to mandate there has to be a Federation Authority designated and a Federation Authority, has a Federation Agreement described. This is his biggest conclusion from the quick response from NIST representatives. Ken commented that one of the parties has to take the dominating role and become the Federation Authority and they have to set up a Federation Agreement. He added that there should not be put any restriction for what a Federation is meant. The current situation is that CSPs are being assessed, what this is doing a two-party federation is in essence approving the use of that CSP by an RP and putting in place restrictions and things in an RP are part of these two-party agreement. It has not been covered until now. It was asked if there is anything that needs to be thought about to cover that use case. Ken responded that in the case of Google seen as a CSP, this is an agreement where they will force their clients to sign up to in order to use Google as a service, as a CSP service, and Google is already doing that. How that aligns with FAL2? Ken does not know, but he thinks this is a use case that fits. Richard added it suggests a specific form of approval, it would be that the Federation Authority would be assessed as to the validity of the Federation Agreement and their ability to elicit, that would not include anything with regard to how the CSPs themselves or the RPs themselves actually were able to comply with the Federation Agreement, which would require separate assessment or separate parties. Being the Federation Authority is a specific role, and the group should be able to assess somebody or an entity which claims to fulfill that role. If at the same time they are acting as either and RP or an IdP, they should be assessed against the criteria related to that context. They have to be assessed according to the role of the Federation. Ken commented it makes sense.
In relation to the blacklist (63C #0130), Richard mentioned there is no clarity from NIST on this, there was input from Dr. Sato. Richard showed the text that served as context to the email he sent. In the note it was explained that “whitelists are implemented as a metadata file in which allowable RPs together with release-able attribute lists and possible level of assurance are listed”. Sato explained his understanding on this field, he said that whitelist are the metadata operated by an IdP or RP. Richard added that he understands that people on the blacklist are people that are not in the whitelist. Ken said that it could be organizations that have been emplaced in the blacklist because they do not want to be communicating. Richard argued he has a problem understanding, he said that if you have a Federation, you would have a mechanism to allow people into it. Therefore, the blacklist would be redundant. Richard commented that there have been some instances (including the IAL2 criteria), where criteria was created which do not express what is in the NIST text. The KI_criterion was modified as “If an RP with which the CSP is conducting a transaction is neither in a whitelist or a blacklist, the CSP SHALL require an authorized party (as defined in the applicable Fedn Agrmnt - see 63C#9999) to give a runtime authorization decision/consent prior to the transaction being executed”.
About 63C#0140, Richard pointed out that there is still lack of consistent terminology. Notwithstanding that, all he was saying is that if you allow a subscriber to make a decision, you can retain that decision. There is nothing in these criteria which specify what is the scope of an authorization decision. Ken added that it is necessary to make sure that the system has that capability.
63C#0150: Richard commented that it is so indirect. First of all, it is necessary to know whether or not the RP maintains a whitelist, it is necessary to know whether an IdP is in that RPs whitelist, does the IdP even know it is in that RPs whitelist? Nathan said, “if I am an RP, I do not have to limit my own transactions to other federations”. Richard said no, furthermore, is the Federation Authority which sets the basis on which vetting is exercised. The IdP has to know that is in the RPs whitelist. Nathan said that it is not necessary, the RP is in the Federation and there is no certainty that all the IdPs are. If the IdPs are, and this is probably covered, if there is not. it is up to the RP to make sure, not a requirement on miscellaneous IdPs. Richard continued that all IdPs in an RPs whitelist, who is managing conformity to the statement. Nathan responded that RPs are being assessed here, it has to say the RPs shall assure that all IdPs in the whitelist are conformant. Ken agreed to this. Richard stressed on that basis that he does not think that Kantara is necessarily in a position to mandate Kantara approval over IdPs and RPs. Therefore, the RP has to have means to determine whether the CSP has either been approved under the Kantara’s 63C rev.3 class of approval or has been assessed by the Federation Authority and found to be conformant to the Federation Agreement. 63C#0150 a) was modified: “been approved under Kantara’s NIST 800-63 rev. 3’ Class of Approval at IAL/AAL 2 or 3 as scoped for the nature of the CSP’s service; OR”.
63C#0160 and #0170 were agreed.
Richard clarified that for historical purposes, in case there are relative newcomers who are not familiar with this, in Kantara it is talked about subscribers and subjects. Anyone acting individually would be both, a subscriber and a subject, but a subscriber may be an organization (which has a number of subjects within it), that is why the distinction was made in the glossary.
In 63C#0140 KI_criterion was modified “if a CSP remembers a Subject’s authorization decision with regard to a specific RP, the CSP SHALL allow the Subject to revoke that decision at any time”.
63C#017 KI_criterion was modified “If an RP remembers a Subject’s authorization decision with regard to a specific CSP, the CSP SHALL allow the Subject to revoke that decision at any time”.
In 63C#0180 KI_criterion “…transmit a Subject's PII unless it is expressly for…” was modified as “…transmit a Subject's information unless it is expressly for…”. 63C#0180 was agreed.
63C#0190 KI_criterion was modified as “The CSP SHALL mask any sensitive information…”. It was agreed.
63C#0200 KI_criterion was modified as “The CSP SHALL limit the duration in which sensitive information is displayed in clear, subject to a maximum of 60 seconds or as specified in the applicable Federation Agreement”. 63C#0200 was agreed.
Ken suggested to modify 63C#0210 KI_criterion as “The CSP SHALL provide and publish mechanisms by which Subjects can resolve any complaints or problems”. 63C#0210 was agreed.
63C#0220 KI_criterion was modified as “The CSP SHALL ensure that, prior to any Subject attributes being transmitted to any RP, the Subject SHALL receive explicit notice and be able to provide positive confirmation to those attributes' transmissions”. It was agreed.
About 63C#0240, Ken commented that there are a lot of existing systems that will not meet these requirements because they send all these attributes really nearly without having asked whether if they can. Richard added that an IdP may say “this is not applicable, we never transmit optional attributes, they never get a choice, we just do it”. Nathan said that general consent for him should be a concern to Kantara, if you put out something that will be very costly for an IdP to implement, then you are going to have to request. Ken continued that this is NIST implementing or stating something, it is not implementable today, how can it be dealt with? A comment was added in the document: “This criterion is applicable ONLY when the IdP/CSP transmits optional attributes rather than transmitting a pre-defined ‘package’ of attributes”.
63C#0250 KI_criterion was modified as: “If an RP with which the CSP is conducting a transaction is not in a whitelist the CSP SHALL require a runtime authorization decision/consent from an authorized party (as defined in the applicable Federation Agreement – see 63C#9999) prior to releasing user information”. A comment was also added: “authorization decision/consent from an authorized party (as defined in the applicable Federation Agreement – see 63C#9999) prior to the transaction being executed”. A concern was raised by Mark, that all of these relationships exist in the simpler binary case of A and B, so when you get to see the issue is that C introduces new elements that did not exist in A and B, and what are those new elements? How do those new elements impact a binary relationship? Richard added this is about establishing the fundamental means of connection, what happens once that connection is made, is beyond the scope of the group. Mark argued he continues to be confused, he said that if there is an RP and a CSP you are just talking about medical records. Where the RP is the doctor who has been allowed by their patient to access medical records at the patient’s IdP. Mark remarked that this gets back to this point of terminology, very poorly defined and very confusing. He stressed that if this document was intended to be used to in some way help in achieving the Federation that is being described, he would say it is completely useless (63C as in some way being useful in creating something like Mastercard, or the medical federation that was described). To agree with 63C#0250, it was asked to delete the comment that was previously added (“authorization decision/consent from an authorized party (as defined in the applicable Federation Agreement – see 63C#9999) prior to the transaction being executed”).
Richard pointed out that it is important not to forget that this work is being sponsored by ID.me.
Martin commented that his concern is about cost implications, because it is his perception that one of the main limitations in the market with the assessments is uncertainty about costs. Richard responded that some people will come along and say, “we want to be AAL2 and IAL2”, some come along and say, “we are just providing a small subset of IAL and nothing else”. Therefore, the cost is still driven by the scope and complexity of what they want to be assessed against. Ken said that from a business strategy point of view (as Richard described), there are customers within the US, who have said “Since Kantara is offering assessment, they wish to be assessed so the government agencies can purchase their solutions”. There is a belief that if they have a Kantara approval on their services, government agencies can purchase them.

Browser not supported