Skip to Content.
Sympa Menu

assurance - Re: [Assurance] If apply for Silver, then apply for Bronze?

Subject: Assurance

List archive

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


Chronological Thread 
  • From: Ann West <>
  • To:
  • Subject: Re: [Assurance] If apply for Silver, then apply for Bronze?
  • Date: Wed, 27 Jun 2012 16:36:59 -0400 (EDT)

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?

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

> 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)?

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

> 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:
>
> [mailto:]
> 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
>
>



Archive powered by MHonArc 2.6.16.

Top of Page