...
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.
With the UK, EU, and Australia they managed to throw out anything to do with RPs because everything was protected by the data protection regulations which apply to everybody. The requirements set in those were relevant in those cases. At that stage that it did make sense to have some things about RPs for the U.S. because there were other RPs who would be coming along later who would be expected to do things that would not necessarily be covered automatically under the current U.S. approach to data protection. This is an unusual stance but never the less does make sense in this context.
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.