Assurance

["Jones, Mark B" <>]

From the document you linked:

 

The TFPAP model is based on comparing the policies and practices of non-Federal Government TFPs to the risks and assurance outcomes of OMB Policy Memorandum M-04-04, NIST Special Publication (SP) 800-63 [4], the Fair Information Practice Principles (FIPPs) and other relevant Government guidance.

 

My understanding is that there is no distinction between the LoA requirements among the various documents.  All of this is rooted in the documents listed in the above quote.

 

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Thursday, March 13, 2014 12:10 PM
To:
Subject: [Assurance] NIST vs. TFS vs. Silver

 

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