Assurance

["Roy, Nicholas S" <>]

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

 

Nick

 

-----Original Message-----
From: [mailto:] On Behalf Of Ann West
Sent: Wednesday, June 27, 2012 3:37 PM
To:
Subject: Re: [Assurance] If apply for Silver, then apply for Bronze?

 

Thanks for your comments Nick. See below.

 

----- Original Message -----

> "...InCommon and the AAC propose requiring IdPOs applying for Silver

> certification to also apply for Bronze. There is no impact to the

> fees to support both, and no audit needed if one uses the new

> Representation of Conformance methodology in the new 1.2 version of

> the Identity Assurance Profiles."

>

> This seems reasonable and logical to me.  A school applying for

> Silver should be able to differentiate Silver from Bronze in their

> technical implementation.  If a school just applies for Bronze

> up-front, then later does a Silver audit and applies for Silver

> separately, does that school need to include all the Bronze stuff in

> the audit and re-apply for Bronze?

 

No. Once an IdPO is certified to assert Bronze, there's no need to apply

again (unless your certification lapses for some reason.)

 

> On the other hand, doesn't the IAQ requirement in 4.2.6.1 already

> mandate a differentiation, and under 4.2.7.2 states that an

> institution not approved for a specific IAQ must not include an IAQ

> that the institution hasn't been certified for and must not include

> an IAQ that doesn't meet the requirements of that IAP? 

 

Yes.

 

> 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.

 

> 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.

 

> 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.

 

> 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.

 

> If different IAQs are part of the big picture, RPs should

> be able to handle Silver in lieu of Bronze.

 

I think handling *many* different IAQ's, beyond Bronze and Silver, are the point.

 

Thanks!

Ann

 

 

>

> Nick

>

> -----Original Message-----

> From:

> On Behalf Of Ann West

> Sent: Wednesday, June 20, 2012 11:52 AM

> To:

> Subject: [Assurance] If apply for Silver, then apply for Bronze?

>

> Hello,

>

> As InCommon and the Assurance Advisory Committee work through the

> details of Assurance in action, the relationship between Bronze and

> Silver profiles needs clarification. It stems from the assumption

> that logically Bronze is a subset of Silver and that this can be

> transferred to the application process and over the wire behavior.

>

> From the point of view of the admins supporting the 819 SPs in the

> federation, it would be less of an overall development burden if

> they didn't need to code for the relationship between the profiles.

> They ask for and receive the profile they require for their service.

> If they want the Bronze qualifier, they should receive Bronze, not

> Silver.

>

> But can't I just assert Bronze-ness for Silver users? Because of the

> differences in implementation, InCommon has no way of knowing. The

> IdPO needs to have processes in place to determine whether users

> that aren't Silver qualify for Bronze. In some cases, IdPOs are

> setting up separate systems for Silver. The second-factor credential

> may qualify for Silver, but the plain-old-password infrastructure

> used to support Bronze may not.

>

> So InCommon and the AAC propose requiring IdPOs applying for Silver

> certification to also apply for Bronze. There is no impact to the

> fees to support both, and no audit needed if one uses the new

> Representation of Conformance methodology in the new 1.2 version of

> the Identity Assurance Profiles.

>

> And one final note: who cares about Bronze anyway? From what we hear,

> our FICAM friends would like existing NIH and NSF services operating

> in InCommon to start requesting Bronze. Once they approve 1.2

> Profile and Framework docs, we'll be working with the Community and

> FICAM to develop next steps.

>

> Thoughts about this proposal?

>

> Ann

>

>

>

> --

> Ann West

> Assistant Director,

> Assurance and Community

> Internet2/InCommon/Michigan Tech

>

> office: +1.906.487.1726

>

>