...

Federation:

...

It is noted that Volume C has more material in this revision. What is the rationale for beefing it up? Is it related to the maturity of federation in federal government over time? Or in response to certain incidents that NIST has been dealing with the last several years?

R: When NIST was creating rev.3 there were already fairly clear paths for the content of what became Volume A and Volume B. But, the bits about federation and network connections were spread throughout rev.2. So, in creating rev.3 that was the first attempt at pulling that all together into a separate volume. With rev.4, NIST has been able to combine comments received over the last 5 years and their experience to realize they were implying several things that were required… but were not necessarily named (i.e. how connections were made, how trust was managed, how information was conveyed, etc). There was a lot left unsaid but now NIST is trying to be explicit.

...

Significant changes were made around FAL3 as well in order to accommodate for different types of proof of possession assertions. FAL1 is still pretty similar to rev. 3.

...

People conveyed concern because FEDRAMP said you must do everything in 800-63 for all three (A,B,C) at the same level. These are often organizations that are not federated except to themselves. Have any of those comments made it to NIST or into these updates?

R: There were comments about FEDRAMP doing that very early on in the rev. 3 lifecycle. Things were split up into volumes (A,B,C) so that they could stay split up! Stop tying them back together!

...

Agencies have asked “I’m not federating externally but I am using SSO and using federation protocols to support that, what is the expectation to apply federation levels to that particular use case?” NIST is attempting to make clear within the text and through their presentations that it is still something covered within 63c. That said, if your use case requires IAL3 and AAL3 it may not necessarily require FAL3. They are intended to vary separately. That needs to be determined on the specifics of the use case. With that in mind, if you are using federation protocols and systems in an internal enterprise system you should have some FAL, but it is not necessarily going to be the same number as the other dimensions.

...

One issue is understanding how equity in federation applies. Do you have any brief comments on how you think the inclusion of equity has impacted federation?

R: It’s a little bit of a different context than 63a and 63b because it’s more of an underlying protocol. There are certain aspects, particularly as you start to look at your trust agreements and other agreement components and the level of assurance expected from providers. Some of that information & documentation is going to be expected to be captured there but certainly not the same as 63a and 63b. Aspects of equity definitely need to be built into federation agreements – and potentially how to explain some of these things. More of an accessibility issue rather than equity. Ensuring the end-user understands what’s happening when federation occurs and explaining it in a way that a user can actually understand what is happening.

Some of this is referenced in the new equity section of the 63c rev.4 draft. A bit of a different case than proofing where there is a lot of fairly specific examples of issues that are discussed. There are equity considerations that need to be taken into account while developing the trust agreements and policies so that the impact the system may have on the users is understood. This is a place where the distinction between equity, accessibility, and privacy all start to blend together.  Do not consider equity, accessibility, and privacy issues to exist in a vacuum – they are very much intersectional. If there is a privacy issue that lends itself to an undue burden/impact for a particular group, that is considered an equity impact. It might be talking about it in the context of privacy or security, but the point is looking at the outcome (what is happening across demographic groups or socioeconomic strata? Is it creating an inadvertent barrier to entry or access?). It’s more complicated as the issues start to overlap when you think about where this comes up in federation – and across all of the volumes.  

In 63c there now appears to be requirements on the RPs. Previously, it’s been mostly requirements on the IDPs/CSPs. Any observations on this? Internally, Kantara will need to adjust their assurance program model is fit these new requirements.

The requirements on RPs are not new. Another example where 63c requirements were there but they were not laid out – only implied. The text has been reorganized to make it more obvious in rev.4. RPs have always been required to do the validation of the assertions, manage any sign-in keys they had, process things in a particular context/way (i.e., expired assertions), etc. All of this was already there it was just woven in a way that was not as obvious. This is one of the document structural changes NIST made a point to correct in this revision.

The importance from NIST’s perspective is that the requirements on the RPs are explicit and clear because there is the supposition that the vast majority of the trust lays with the IDP/CSP and not as much on the RP. NIST wanted to emphasize that there is a very critical role that the RP is playing and it needs to be done to a well-defined approach. Making sure those were clear was essential. Very specific to federal RPs and other organizations that choose to use this guidance that there is an expectation to do certain things and maintain certain expectations within the federation process. This is not an unprecedented thing – in the PKI world it is very common within a certificate policy for the template to lay out the responsibilities of the RPs there.

In any conformity assessment program, you have to make decisions around what the scope is going to be for the different programs. In terms of performing an assessment, it doesn’t matter if it is a CSP or an RP. There is a set of requirements that are assessed and either they are being met – or not. The problem potentially with RPs is that if it’s a large community, how long will it take? How complex does that make it? How does one even manage the logistics? Do we end up with RPs entering into separate agreements? Or a blanket agreement? None of this is really NIST’s responsibility to answer but they will be the principal consideration when Kantara moves forward.