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

3.12.3.1 External Identity APIs

NIST PIV and digital identity SP 800-63C-4 against SP 800-63C
All changes in this version
added 3 Common Federation Requirements part of 3.12.3

Title changed

Before · SP 800-63C

After · SP 800-63C-4

External Identity APIs

Control changed

Before · SP 800-63C

After · SP 800-63C-4

While most identity APIs used in federation protocols are hosted as part of the IdP, it is also possible for the IdP to grant the RP access to external identity APIs that are hosted outside of the IdP. External identity APIs are normally provided by attribute providers other than the CSP and provide attributes about the subscriber in addition to those available from the subscriber account. When the IdP grants access to an external identity API, the information returned from the external identity API is associated with the subscriber just like an identity API hosted by the IdP. For the purposes of the trust agreement, the IdP is responsible for the association of the external identity API’s content with the subscriber account, even though the IdP does not have control of the data returned by the external identity API.

As the attributes returned by the external identity API are assumed to be independent of those returned directly from the IdP, the contents of the external Identity API MAY use different identifiers, formats, or schemas from those used by the IdP. In particular, an external identity API is not expected to use the same federated identifier as an IdP- hosted identity API. For example, an IdP could provide access to a subscriber’s medical license information. Instead of the IdP asserting the license status directly, the IdP provides the RP access to a record at a medical licensure agency that represents the subscriber. The federation protocol can enable this by allowing the IdP to provide a link to an API with the record that represents the subscriber as well as a credential that allows limited access to this API. The RP can then make a strong association between the subscriber and the medical license record, even though the license record will likely use a different identifier and would not otherwise be correlatable by the RP. The IdP remains responsible for providing this link to the RP.

Any use of external identity APIs for providing attributes SHALL be enumerated by the trust agreement as part of listing attribute sources.