BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

2.4 Federation and Assertions (was: How to Use this Suite of SPs)

NIST PIV and digital identity SP 800-63-4 against SP 800-63-3
All changes in this version
modified 2 Continuous improvement programs. Establishing a continuous evaluation part of 2

Title changed

Before · SP 800-63-3

How to Use this Suite of SPs

After · SP 800-63-4

How to Use this SuiteFederation ofand SPsAssertions

Control changed

Before · SP 800-63-3

The business model, marketplace, and composition of how identity services are delivered has drastically changed since the first version of SP 800-63 was released. Notably, CSPs can be componentized and comprised of multiple independently-operated and owned business entities. Furthermore, there may be a significant security benefit to using strong authenticators even if no identity proofing is required. Therefore, in this revision, a suite of SPs under the 800-63 moniker has been created to facilitate these new models and make it easy to access the specific requirements for the function an entity may serve under the overall digital identity model.

After · SP 800-63-4

TheNormative businessrequirements model,can marketplacebe found in [SP800-63C] , Federation and compositionAssertions .

Section III of howOMB [M-19-17] , Enabling Mission Delivery through Improved Identity, Credential, and Access Management , directs agencies to support cross-government identity servicesfederation areand deliveredinteroperability. hasThe drasticallyterm changedfederation sincecan be applied to several different approaches that involve the firstsharing versionof information between different trust domains, and may differ based on the kind of SPinformation 800-63that wasis releasedbeing shared between the domains. NotablyThese guidelines address the federation processes that allow for the conveyance of identity and authentication information based on trust agreements across a set of networked systems through federation assertions. There are many benefits to using federated architectures including, CSPsbut not limited to:

• Enhancing user experience (e.g., a subject can be componentizedidentity-proofed andonce comprisedbut oftheir subscriber account used at multiple independently-operatedRPs)

• Reducing costs for both the subscriber (e.g., reduction in authenticators) and ownedthe businessorganization entities(e.g., Furthermorereduction in information technology infrastructure and a streamlined architecture)

• Minimizing data exposed to RPs by using pseudonymous identifiers and derived attribute values instead of copying account values to each application

• Supporting mission success, theresince mayorganizations will need to focus fewer resources on complex identity management processes

While the federation process is generally the preferred approach to authentication when the RP and IdP are not administered together under a common security domain, federation can also be applied within a significantsingle security benefitdomain tofor usinga strongvariety authenticatorsof evenbenefits, ifincluding nocentralized account management and technical integration.

These guidelines are agnostic to the identity proofing, isauthentication, requiredand federation architectures that an organization selects, and they allow organizations to deploy a digital identity scheme according to their own requirements. ThereforeHowever, there are scenarios in thiswhich revisionfederation could be more efficient and effective than establishing identity services that are local to the organization or individual applications, asuch suiteas:

• Potential users already have an authenticator at or above the required AAL.

• Multiple types of SPsauthenticators underare required to cover all possible user communities.

• An organization does not have the 800-63necessary monikerinfrastructure hasto beensupport createdthe management of subscriber accounts (e.g., account recovery, authenticator issuance, help desk).

• There is a desire to facilitateallow theseprimary newauthenticators modelsto be added and makeupgraded itover easytime towithout accesschanging the specificRP’s requirementsimplementation.

• There are different environments to be supported, since federation protocols are network-based and allow for implementation on a wide variety of platforms and languages.

• Potential users come from multiple communities, each with its own existing identity infrastructure.

• The organization needs the functionability anto entitycentrally maymanage serveaccount underlife cycles, including account revocation and the overallbinding digitalof new authenticators. An organization might want to consider accepting federated identity modelattributes if any of the following apply:

• Pseudonymity is required, necessary, feasible, or important to stakeholders accessing the service.

• Access to the service requires a defined list of attributes.

• Access to the service requires at least one derived attribute value.

• The organization is not the authoritative or issuing source for required attributes.

• Attributes are required temporarily during use (e.g., to make an access decision), and the organization does not need to retain the data.