Assurance

["Jones, Mark B" <>]

What exactly do you mean by “full-on LoA support”?

 

It seems to me that LoA 1 as defined by 800-63 is a bare minimum for any serious service.  I’m not trying to say that LoA 1 as defined by 800-63 is perfect, just that users should expect that if they manage their password properly their account will remain in their control, and compliance with a standard is the basis for such trust.

 

As far as formalized best practices, it is my opinion that what you are looking for is Bronze or anything else based on the 800-63 LoA 1 specifications.  I’m not aware of any formal standard that would be an alternative to 800-63.  And I would guess that changes in 800-63 would eventually need to be reconciled with the InCommon IAPs but maybe someone else can do more than guess on that point.

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Friday, March 14, 2014 11:01 AM
To:
Subject: RE: [Assurance] NIST vs. TFS vs. Silver

 

Thanks to both of you for the clarity.

 

Mark, FWIW, the TFP LoA 2 requirements have some large (though mostly optional) additions, which is what raised the question in the first place.

 

I'm clear that for actual compliance I only need worry about InCommon (since that's the only compliance I'm seeking), I was more wondering how much the items that have been added to the TFP above and beyond what's in NIST 800-63 is likely to impact us (both my organization and the community) in the long term. I'm looking at InCommon IAPs, NIST and other sources for some formalized best or accepted practices for various operations (that don't require full-on LoA support), and I'm wondering how much it makes sense to (and how quickly I should be looking to) leverage information from each source.

 

For example, we know that password brute force protection rules changed somewhat substantially in the last rev NIST 800-63-2, so I'm wondering how aggressively to try to focus on that vs. the older language (as expressed in Silver/Bronze). Similarly, the new FICAM TFP adds (again, mostly optional) expectations about device fingerprinting and login behavior tracking to LoA 2.

 

I know neither of those changes applies to us under the current InCommon IAPs, but I'm asking more to help me read the tea leaves as to how long such changes are likely to take to flow from the TFP and NIST to InCommon.

 

Again, thanks for the clarification.

 

--- Eric

 

From: [] On Behalf Of Ann West
Sent: Thursday, March 13, 2014 1:06 PM
To:
Subject: Re: [Assurance] NIST vs. TFS vs. Silver

 

Hi Eric,

 

NIST wrote 800-63 for US Government Agency to Agency service use. It is not a Trust Framework Program (TFP), because it doesn't deal with the legal, organizational, technical _expression_ and assessment requirements, to name a few.  

 

FICAM was established to (roughly) expand on 800-63 and create a certification program for non-government IdPs to interact with Agency Relying Parties (RPs) To do this, FICAM had to figure out how to include the additional trust components for each of these non-gov IdP in sectors like banking, education and health care. FICAM was aware that these other communities have different but comparable ways of operating that are not included in 800-63, and in the interest of growing the program, they decided to be somewhat flexible to accommodate those.

 

To scale the certification of IdPs then, FICAM decided to focus on certifying TFPs like InCommon, which in turn would certify IdPs (or Credential Service Providers [CSPs] in FICAM-speak). Fast forward to today, some of the Trust Framework Providers' specs are short and very close to the original FICAM spec and some are long and very prescriptive. InCommon's focuses on intent, leaving the "how" up to the campus. The authors of InCommon's spec wanted to accommodate the US Government requirements while maintaining campus flexibility as much as possible. You know this as Alternative Means which none of the other Trust Frameworks have. We also negotiated no-audit LoA1, which is now standard in FICAM 2.0. We also don't include all the MFA methodologies in our specs that are in 800–63 to reduce technology-chasing revisions. We instead rely on the community submitting Alternative Means which become normative such as the MFA example on the assurance.incommon.org site.

 

It's great that you reviewed the new FICAM docs, but put them in perspective: They provide background on where they are taking their program. But no worries, InCommon (the Assurance Advisory Committee and staff) are currently in negotiations with FICAM to determine how their 2.0 version will affect our spec. We think it will be minimal (not substantive really), but time will tell. For instance, their 2.0 assumes IdPs are not members of an operating federation. (Kantara, for instance, is a FICAM-certified Trust Framework Provider but does not operate a federation.) This assumption has driven FICAM to develop an Authority to Offer Services (ATOS) document that IdPs must follow when preparing to federate over-the-wire with an Agency RP. InCommon is making the case that IdPs in InCommon already support much of what's in the ATOS so no additional work on the spec or by the IdP is needed.

 

Stay tuned.

 

Ann

 

 

On 3/13/14 1:09 PM, "Eric Goodman" <> wrote:

 

I had an opportunity to read through the new FICAM TFS TFPAP at

 

http://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_TFPAP_v2.0.pdf

 

I'm having some difficulty comprehending the intended distinction between the LoA requirements detail defined in this framework vs. the LoA requirements defined in NIST 800-63. The LoA requirements in the FICAM/TFS document seems to be a reasonable evolutionary update (at least for LoA 2 – I haven't really read the higher LoA's) of the areas of concern that Trust Framework Providers need to address in their Trust Frameworks.

 

What I'm confused by is that I thought InCommon looked generally to NIST-800-63-n as the "boilerplate" to which Bronze and Silver are attempting to provide equivalent(ish) protections. Is there a reason why these requirement categories are so detailed-ly repeated in the two separate documents? Is it just that FICAM and NIST are different agencies, and FICAM is providing guidance to NIST on what 800-63-n+1 should address? Is InCommon actually matching to the FICAM requirements and just uses NIST-800-63-n as an approved TFP for reference?

 

Thanks for any clarification, and apologies if this is the wrong list for the question. (I presume that eventually the information in the TFSPAP doc will be relevant for discussion on this list, just trying to get clear if it is today!)

 

--- Eric

Attachment: smime.p7s
Description: S/MIME cryptographic signature