You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

InCommon and NIH have made progress toward federated access to select NIH applications based on university-based identity systems and user attributes.  One of the next challenges comes from situations in which a particular institution meets InCommon criteria for stricter profiles of identity assurance in terms of its infrastructure and operations, while particular members of the institutional community may fit stricter or looser profiles in terms of identity proofing and the kinds of identity credentials they use for authentication.  This situation will be real for a significant number of institutions. 

The question becomes, given a SAML-based approach to Identity Provider/Service Provider (IdP/SP) interactions, how will the profile of identity assurance that applies in a given transaction be communicated from the IdP to the SP. David Wasley, as a member of the InCommon Technical Advisory Committee, has promoted the use of the concept of "identity assurance profiles."  This terminology, he argues, will provide a better fit for the situation defined above than the more common term, "level of assurance."  The document you are now reading adopts the identity assurance profile model and proposes a way to codify any number of such profiles in SAML assertions.

It seems likely that different federations will define different profiles for identity assurance. InCommon, for one, has stated that it will define "bronze" and "silver" profiles, and will certify particular IdPs to be in conformance with a named profile provided their operations and infrastructure meet the associated criteria.  It is the intention of InCommon that an institution with an identity assurance profile of bronze could reasonably be mapped to what NIST SP 800-63 defines as level one.  Silver is intended to map to NIST level two.  The ultimate arbiter is the SP that receives assertions from an IdP.  They may well want to do a risk assessment of their applications and then decide which identity assurance profiles are appropriate for each.

The identity assurance of a given interaction of user, IdP and SP is dependent on many factors.  However, in the interest of simplicity of operation, it seems desirable for an IdP to assert that a given interaction, taking everything into consideration, fits a particular identity assurance profile. 

  • No labels