Skip to Content.
Sympa Menu

assurance - Re: [Assurance] Executive Order from the President of the United States

Subject: Assurance

List archive

Re: [Assurance] Executive Order from the President of the United States


Chronological Thread 
  • From: Ann West <>
  • To: "" <>
  • Cc: "" <>
  • Subject: Re: [Assurance] Executive Order from the President of the United States
  • Date: Tue, 21 Oct 2014 21:01:22 +0000
  • Accept-language: en-US

An excerpt from my email to the list from March 13: 

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.


Ann

From: <Farmer>, Jacob <>
Reply-To: "" <>
Date: Tuesday, October 21, 2014 at 4:56 PM
To: "" <>
Cc: Brett Bieber <>
Subject: RE: [Assurance] Executive Order from the President of the United States

For at least one example, the identity proofing requirements in Silver are more flexible than those in LOA 2.  Specifically, Silver adds the “Existing relationship” proofing mechanism.

 

Jacob

 

 

 

From: [] On Behalf Of Jones, Mark B
Sent: Tuesday, October 21, 2014 4:45 PM
To:
Cc:
Subject: RE: [Assurance] Executive Order from the President of the United States

 

I would be interested in an example of a significant difference between NIST 2 and Silver.  Why is it important not to equate the two?

 

From: [] On Behalf Of Farmer, Jacob
Sent: Tuesday, October 21, 2014 3:30 PM
To:
Cc:
Subject: RE: [Assurance] Executive Order from the President of the United States

 

The NIST standards were written in such a way that they really could only be implemented by a Federal Government entity.  For example, they make references to specific artifacts of the way the Federal Government is organized.  I don’t think the broad industry interest was anticipated.

 

Jacob

 

From: [] On Behalf Of Bradner, Scott
Sent: Tuesday, October 21, 2014 4:28 PM
To:
Cc:
Subject: Re: [Assurance] Executive Order from the President of the United States

 

I have wondered, why did I2 decide to not just use the NIST standards - 

 

seems to present an ongoing issue to be " comparable, but not the same’

 

Scott

 

On Oct 21, 2014, at 4:24 PM, Michael R. Gettes <> wrote:

 

NIST 1 != Bronze.

NIST 2 != Silver.

 

They are comparable, but not the same.

 

/mrg

 

On Oct 21, 2014, at 4:19 PM, Brett Bieber <> wrote:

 

That document doesn't mention specifications such as NIST Levels 1 (Bronze), 2 (Silver), 3, 4, directly, but instead generalizes the importance of common standards, requirements, & accountability.

 

 




Archive powered by MHonArc 2.6.16.

Top of Page