Assurance

[Ann West <>]

Thanks Nick,

I've also been out. (I think this thread will take a while.) ;)

See my comments in blue. Apologies to plain text readers.  

Ann

---

Thanks Ann, sorry for taking so long to get back around to this, I was out of the office for a while.

 

Nick

 

-----Excerpts from Original Message-----

 

> Maybe some

> clarification around Silver not being an adequate replacement for

> Bronze or "these are not downwards compatible" would be enough?

 

How would this help?

 

It probably wouldn’t for most, but for those unfamiliar with the IAPs, just starting out, some up-front notification of this might help them sort through things more easily.

So do a diff of the Profiles? We have a table in the Profiles document that summarizes the major criteria and which Profile requires what, but it sounds like you think more digested version is needed?

 

> While an IdP should be capable of differentiating IAQ requirements

> and handling them appropriately, If an RP can accept Bronze and

> requires Bronze, it should be able to deal with Silver, too, if

> Silver is good enough for its needs (and it arguably is). 

 

So you're saying that an RP should know how all InCommon IAQs are related be able to make a decision based on that knowledge. If a RP wants Bronze and gets Silver (or wants Bronze and gets Gold in the future), it should be able to support this.

 

What happens when interfed becomes the norm and each fed has assurance profiles? Let's say they are FICAM trust framework providers. All those RPs have to know how the InCommon profiles are related too even though they aren't a member? And it gets more complicated with international federating.

 

Very true, but in the case of interfederation, I would think these kinds of mappings are already going to be very difficult to traverse.  Some kind of a statement like: “Silver is the same as Bronze with the addition of identity registration, required audit and more base password entropy” might help to traverse those differences.   Eventually, some kind of machine-traversable policy represented in metadata might make that easier to do, in some future world where we all have jet packs.  If there’s a simple enough need on the part of the RP wanting bronze (I need to know that the same person is always logging in, but I don’t need to know exactly who they are) then the plain English explanation of Bronze à Silver that I provided above, if accurate (probably it’s not but it was good enough for demonstration purposes) might help.

Mapping is one issue. One could say, though, that Kantara LoA 1 is comparable to OIX LoA 1 which is comparable to Bronze, given they are all FICAM approved LoA 1 profiles. Most of the differences (aside from audit now) that you're describing falls under the FICAM requirements and 800-63 as the root of their program. So understanding each Trust Framework (like FICAM) and how they determine LoA is the place to start, not necessarily the individual profiles (like InCommon Bronze). 

 

> It feels

> a little bit like all of the burden for assurance (especially things

> like privacy that should have requirements for both IdPs and RPs)

> are being put on the IdP side of the operation.  I think the RPs

> requiring assurance have some responsibility here too, including

> technical responsibility to be able to flexibly support the way the

> IAPs work in InCommon. 

 

I'm still not understanding what's behind this request. Do you feel that assessing your infrastructure for Bronze is too much work, given all the tasks you have to support Silver? You could just decide that only Silver users can assert Bronze, sign the new Assurance Addendum (that will support the non-audited Bronze) and be done.

 

Or something that I'm missing (which is most likely the case)?

 

I guess my concern here was going to be if we had to do another assessment or audit later if we initially certified at Silver and then wanted to do Bronze later.  But if we can just assess those areas that are different and apply for whichever IA profile we didn’t already have with “diffs” then that’s moot.  The thing about privacy requirements was in regard to the requirement that the IdP do a bunch of notification work up-front on the RP’s privacy policy, when that should be the job of the RP, not the IdP.

Yes, I can't comment too much on the Privacy Policy, since that's a FICAM requirement. I do know the Federal RP have Privacy Requirements as well and can dig up the background for that, if you're interested. 

Regarding the application, I think the big issue is the audit, yes? Here are the scenarios:

- You apply for Bronze and use the self-attestation option and just sign the Assurance Addendum. Done. Later you apply for Silver. Internally you may implement the diffs of the profiles, but you must have a full audit to be certified.

- You apply for Bronze and use the audit option, sending us the Assurance Addendum and the audit summary. Done. Later, you apply for Silver. Nothing has changed since your Bronze audit, so it's  pretty easy for the auditor to review the criteria that are shared between the two profiles and then focus on the Silver requirements, effectively doing a diff.

- You apply for Silver and get an audit. As I mentioned at the start of this thread, we're proposing that you must also apply for Bronze at the same time. The easiest way to do this is 1) to ensure that only Silver users can assert Bronze (then you don't have to keep track of folks who are Bronze but not Silver) and 2) self-attest that you support Bronze by signing the Assurance Addendum (which you have to do anyway).  

Later, if you want to change how you're supporting Bronze and start using, say, your updated plain-old-password infrastructure instead of relying on your shiny multi-factor system, just let us know. Most likely it will be a discussion with the AAC and you're on your way. 

> It seems like if the InCommon assurance

> framework fits within the ICAM SAML 2 profile, federal RPs requiring

> assurance from InCommon IdPs should be able to fully support that

> profile.

 

Agreed. However, I don't think that accepting a LoA2 profile in lieu of an LoA1 profile is in their SAML 2 profile. I could be wrong about that, but my skimming of the document didn't reveal this as a requirement. Can you cite the par?

 

You’re right, that’s not in scope, but it feels like there should be some sort of mechanical way to traverse and map the policy – otherwise, this is as hard within the federation as you rightfully state it would be in the interfederation scenario.  At least within the federation, It becomes not hard if everyone certifies to all the LoAs available, but I don’t think that’s going to happen.

Agreed that assurance needs mapping, similar to the PKI space and the Federal PKI Bridge or SAFE BioPharma. And maybe the Feds will do that for different sectors in the US. Internationally, I think R&E community will have a key role because of our missions and collaborations. BTW, Leif Johansson has developed an IANA draft for a Level of Assurance Profile registry that might start us down at least the profile discovery road: 

https://datatracker.ietf.org/doc/draft-johansson-loa-registry/ 

Ann