Assurance

[Ann West <>]

On 3/14/14 12:01 PM, "Eric Goodman" <> wrote:

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.

Regarding reading the future, there are really three questions we're working now to answer: 

• Will the FICAM 2.0 release affect our spec? Some of the new text reflects the merging in of existing documents that InCommon's program already supports. These won't affect our spec.
• Assuming the answer to the above question is yes, are the changes substantive? For example, FICAM would like to normalize terminology across all the TFPs. While this will change the InCommon spec, the updates won't affect IdP implementations.
• Assuming there are substantive changes to InCommon's spec, what would be the timing for reflecting them in our documents? When we know the answer to the first two bullets and understand the scope of the possible changes, we'll let you know!

Best,

Ann

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