Skip to Content.
Sympa Menu

ad-assurance - Re: [AD-Assurance] Microsoft Strategy / FICAM / Kantara

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

Re: [AD-Assurance] Microsoft Strategy / FICAM / Kantara


Chronological Thread 
  • From: David Walker <>
  • To:
  • Subject: Re: [AD-Assurance] Microsoft Strategy / FICAM / Kantara
  • Date: Wed, 08 May 2013 08:41:46 -0700
  • Authentication-results: sfpop-ironport01.merit.edu; dkim=pass (signature verified)

InCommon's filled-out application was really just a mapping of InCommon documents to the TFPAP to build the case for certification.  I don't think there'd be anything helpful there.  I'm sure, by the way, that Appendix C in the TFPAP is what was intended.  As you figured out, the application is clearly intended to be a companion to the TFPAP. 

(Originally, they didn't have a template for applications.  I believe it was InCommon's application to version 1.0 of the TFPAP that got them thinking about a template.  David Wasley, who prepared that application for InCommon, created his own template that looked very similar to the one that FICAM now uses.)

David

On Wed, 2013-05-08 at 13:20 +0000, Capehart,Jeffrey D wrote:
David,

 

Does the InCommon filled-out TFP application just map Bronze/Silver criteria to each row, or perhaps would there be additional guidance that would be useful for implementers and evaluators/auditors to see?

 

The Assessment Package must build the case that the Applicant’s trust model and practices are comparable at the desired LOA. Applicants are not required to submit their assertions in any particular format, nor are they required to comply strictly with any particular trust criterion. Instead, the Applicant must demonstrate that its trust specifications meet or exceed the trust criteria in NIST SP 800-63. Failure to comply with any particular requirement is not fatal, since alternative mitigation strategiesmay satisfy trust criteria, especially at LOA 1 and LOA 2.

 

Per Table 8C row 1:Sufficiently protect shared secrets such as passwords.  See Appendix C for definition of “Approved”.

 

Unfortunately, Appendix C was blank.  However, I was able to find the Appendix C definitions in the TFPAP process doc.

http://www.idmanagement.gov/documents/FICAM_TFS_TFPAP_v1.1.0.pdf

 

Some additional interesting notes re: FICAM TFS/TFP/TFPAP.

 

TFPs demonstrate comparability to TFS requirements for security and privacy. Identity Providers demonstrate comparability to a TFP.

 

Subsequent to adoption, a TFP is subject to periodic comparability audits, and possibly discontinuance(i.e., no longer acceptable to the Federal government).

 

The TFS will evolve over time. As the needs of the Program change or become clearer, it is likely that the trust framework adoption process will evolve. Draft revisions of this document will be made available to applicable Federal government agencies and organizations, including TFPs, for comment. Those comments will be provided to the TFS for consideration and possible inclusion before final revision.

 

Jeff

 

From: [mailto:] On Behalf Of David Walker
Sent: Tuesday, May 07, 2013 7:39 PM
To:
Cc: DHW
Subject: Re: [AD-Assurance] Microsoft Strategy / FICAM / Kantara


 

Jeff,

I haven't looked through the FICAM roadmap very critically, but I think we're looking at the issue correctly.  The FICAM tool that we used to demonstrate comparability for InCommon's IAP is the Trust Framework Provider Application Template, which parallels the TFPAP:

http://www.idmanagement.gov/documents/TFP_Application_Template.doc


In particular, see row 1 of Table 8C: Token and Credential Management.

The roadmap seems to be a more inward-facing document for government agencies, and as such it recognizes the need for a transition period.  I think they are viewing identity assertions that we provide as something new that doesn't need a transition period; it just needs to be ready on day one.  The roadmap does, however, indicate that they're aware of the need for transition in many cases, and that may be useful to us.

David



 






Archive powered by MHonArc 2.6.16.

Top of Page