Attendees: Ken Dagg; Mark Hapner; Sato Hiroyuki; Richard Wilsher; Martin Smith; Colin Wallis; Ruth Puente

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

Richard expressed he wanted to start by looking at the changes he made after last meeting.
Ken said he commented on the ones highlighted in yellow.
It was agreed on 63C#070.
63C#0100 Ken disagreed, he said that the criterion needs to apply to all parties that are federated, not just the IdP or the CSP. Richard argued that his point was that if you are passing information, you have to be in a transmissible mode, which makes the IdP sending the assertion, whereas the RP side is receiving it. That is why Richard suggested IdP only. Ken suggested that he could say “all parties”, that way anyone who is involved and there is nobody who can claim that a proxy or a broker does not fit RP or IdP and go through that argument. The criterion was modified as “All Federation parties SHALL restrict their transfer of SII in accordance with all applicable laws, regulations, contracts and policies as they apply to the relevant party”. It was agreed.
It was asked about self-assertion, however Ken emphasized that this is not the topic for the discussion.
About 63C#0110 the team agreed. Martin just suggested to remove the word “can” in the criterion and it was accepted.
63C#0150 was agreed. “Can” was also removed from the criterion.
Ken suggested to Richard to make sure there are no other “can” in the text. Richard said he is going to make a note.
Sato said that there would have to be certain Federation Authority maintaining that list in order to enable dynamic registration. Richard added that 63C does explicitly say that there does not have to be a Federation Authority, certainly that is not mandating the existence of an Authority capitalized. Martin said that he thinks it is wrong, and some work should be done around it. Richard responded that this flexibility was allowed, he added that what is not being addressed is how whitelists are established and managed. Accordingly, 63C#0280 criterion was modified, “Federation Authority” was replaced by “Federation Agreement” and “and publish” was removed. It was agreed.
In 63C#0280, the criterion was modified as “See 63C#0325 i)”.
In relation to 63C#0310 Richard said this is a Kantara specific criterion and accordingly the group needs to do something. Ken said that in many other cases it has been talked about Federation Agreement, rather than Federation Authority having to do something. Richard clarified that it says the Federation Authority or in the absence of that, somebody has to take responsibility to create a documented Federation Agreement. Martin suggested that it is necessary to have a Federation Agreement, as a contract. Ken stressed that the solution is to say that a contract SHALL exist or a Federation Agreement. The criterion was modified as “Federation participants SHALL interoperate in accordance with a documented Federation Agreement which SHALL define the obligations upon participants within the applicable Federation”. It was agreed.
63C#0350 and 63C#0355 were agreed. The criterion was slightly modified, instead of “The CSP/RP”, it says now “Each Federation participant”.
63C#0380 and 63C#0390 were agreed.
About 63C#0420, Ken asked if it is necessary to have a criterion saying that assertion should specify AAL and IAL. Richard said that the problem is that it has not been assigned to any role, it will have to be assigned to both RP and IdP. Ken agreed. It was agreed.
Note: Martin had to leave, from now on the “agreed ones” will be sandy shaded for Martin’s review.
About 63C#0440 Ken said that after the discussion with NIST he agrees on this.
63C#0520 was agreed.
In relation to 63C#0530, Ken explained that NIST mentioned that if you use a digital signature you have to use an asymmetric key, and if you use MAC use a symmetric key. Richard said that they basically have said this elsewhere, but it was referring to the IdP, this is essentially the same referring to RP. Richard stressed it is not necessary to have a) and b). Ken agreed, the only concern he has is about the conversation with Justin last week it was “if you use this technology, you have to do this; if you use that technology, then you have to do that. If you use some other technology, we are not sure, but it has to be a cryptographic signature”. Ken remarked he has no problem with multiple options, his only concern is with the detail, is there any other way of doing a digital signature, other than using asymmetric keys? Richard responded that there might be, but now the group cannot think of one. Richard reckons these points are redundant. Therefore, a) and b) were removed. It was agreed. The criterion was modified as “Covered by 63C#0410”.
About 63C#0540, Ken asked if guidance is needed. Richard said no. Richard continued saying that in the requirement he would not choose “independent”, he would use “unique to”; that is why he thinks there is no guidance needed. It was agreed.
Sato wrote a comment on the chat: “In the OpenID community, SII stands for Self-Issued IdP. Using SII for Subscriber Identifying Information may cause confusion”. It was agreed that we need to create another acronym for SII. Richard and Ken will take that action.
In 63C#0550, the criterion was modified in the beginning as “Each Federation participant SHALL only use…”. It was agreed.
In row 129, it was modified as “Covered by 63C#0410 g)”. It was agreed.
Rows 130-131 were agreed.
About 63C#0560, Ken asked if it was generalized (to the RP). Richard explained that requirements in rows 133-135 refer to RP and IdP. Richard also explained that an assertion needs a relying party. Ken added that now the RP does not have to be marked. 63C#0560 and 63C#0570 were agreed.
In 63C#0580, Ken commented he was not sure. Richard commented that the idea is to prevent injection replay of an assertion generated from one RP at another. If the IdP knows that is going through a broker, then it can imply a refer which allows the recipient relying party to recognize that it is intended target. Ken thinks it does work, the only suggestion would be “notes to assessors or to whomever that a proxy acts as an RP when it is receiving a message, an assertion”. Ken’s comment was added as ‘Guidance- when a proxy acts as an RP it should be able to determine that it is the intended recipient for the purposes of passing-through the assertion’. It was agreed.
63C#0590 was agreed.
About 63C#0600 Richard mentioned that it is probably covered by 63C#0630 and 63C#0670. It was written “See 63C#0630 and 63C#0670”. It was agreed.
63C#0610 was agreed.
63C#0620: Richard explained he listed four points from this requirement. He also explained that the criterion is the literal text, but it is all on the context of the proxy acting as an IdP. Ken said this is his concern, it is not a proxy IdP, it is a proxy acting as an IdP; it is a significant difference. Ken stressed that the wording is the problem. Going back to 63C#0610, Richard commented in the document “Rev. 4: An IdP acting as a proxy”. 63C#0620 was agreed.
63C#0630: Ken asked if it is when acting as a proxy or if it is in any CSP. Richard said it does not use the word proxy in 6.3.2. It was agreed.
63C#0640 was agreed.
63C#0650: Ken commented that the criterion that Richard specified is accurate. He does not know how this can be assessed. The comment that was made in the Editor’s section was moved to comments for Rev.4. It was agreed.
About 63C#0660 Ken asked where it is the privacy risk assessment, the previous one. He asked to make a note to find it later. Richard marked this criterion to be revised later.
63C#0670: Richard said that this refers to when you actually do the sharing. Ken added that then it would be runtime. A comment was added “This refers to the consenting RPs identified through ‘0650 b) iii)”. It was agreed.
63C#0680: Ken asked if this criterion is covered by any other criteria. Richard said he does not know; it would have to be revised. Ken believes it is covered, he said that maybe at the end there could be a further revision. It was agreed.
63C#0690 was marked to be revised later.

Progress made: Richard said that it was reached about 81% of progress during this meeting.

Action items:

Given Dr. Sato's comment "In the OpenID community, SII stands for Self-Issued IdP. Using SII for Subscriber Identifying Information may cause confusion”. Richard and Ken agreed to work on a new acronym for SII.
Martin to review the “agreed ones” sandy shaded.

Browser not supported