BaselineWatch
34 requirements
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

NIST PIV and digital identity SP 800-63C

34 requirements · published 2020-03-02
Changes in this version
All1 The agency SHALL consult with their Senior Agency Official for Privacy10 Usability Considerations11 Examples12 References2 The agency SHALL publish or identify coverage by a System of Records Notice3 The agency SHALL consult with their SAOP to conduct an analysis determining4 The agency SHALL publish or identify coverage by a Privacy Impact Assessment5 Expiration: A timestamp indicating when the assertion expires and SHALL no6 Identifier: A value uniquely identifying this assertion, used to prevent attackers7 Signature: Digital signature or message authentication code (MAC), including key8 Security9 Privacy Considerations
RefTitleText
1 The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) to conduct an analysis determining whether the requirements of the Privacy Act are triggered by the agency that is acting as an IdP, by the agency that is acting as an RP, or both (see Section 9.4 ).
2 The agency SHALL publish or identify coverage by a System of Records Notice (SORN) as applicable.
3 The agency SHALL consult with their SAOP to conduct an analysis determining whether the requirements of the E-Government Act are triggered by the agency that is acting as an IdP, the agency that is acting as an RP, or both.
4 The agency SHALL publish or identify coverage by a Privacy Impact Assessment (PIA) as applicable.
5 Expiration: A timestamp indicating when the assertion expires and SHALL no longer be accepted as valid by the RP (i.e., the expiration of the assertion and not the expiration of the session at the RP).
6 Identifier: A value uniquely identifying this assertion, used to prevent attackers from replaying prior assertions.
7 Signature: Digital signature or message authentication code (MAC), including key identifier or public key associated with the IdP, for the entire assertion. 8. Authentication Time: A timestamp indicating when the IdP last verified the presence of the subscriber at the IdP through a primary authentication event (if avail
7.1
in 7
 Back-Channel Presentation In the back-channel model, the subscriber is given an assertion reference to present to the RP, generally through the front channel. The assertion reference itself contains no information about the subscriber and SHALL be resistant to tampe
7.2
in 7
 Front-Channel Presentation In the front-channel model, the IdP creates an assertion and sends it to the subscriber after successful authentication. The assertion is used by the subscriber to authenticate to the RP, often through mechanisms within the subscriber’s bro
7.3
in 7
 Protecting Information Communications between the IdP and the RP SHALL be protected in transit using an authenticated protected channel. Communications between the subscriber and either the IdP or the RP (usually through a browser) SHALL be made using an authenti
8 Security This section is informative. Since the federated authentication process involves coordination between multiple components, including the CSP which now acts as an IdP, there are additional opportunities for attackers to compromise federated
8.1
in 8
 Federation Threats As in non-federated authentication, attackers’ motivations are typically to gain access (or a greater level of access) to a resource or service provided by an RP. Attackers may also attempt to impersonate a subscriber. Rogue or compromised
8.2
in 8
 Federation Threat Mitigation Strategies Mechanisms that assist in mitigating the above threats are identified in Table 8-2. Table 8-2 Mitigating Federation Threats Federation Threat/Attack Description Example Assertion Manufacture or Modification Cryptographically sign the ass
9 Privacy Considerations This section is informative.
9.1
in 9
 Minimizing Tracking and Profiling Federation offers numerous benefits to RPs and subscribers, but requires subscribers to have trust in the federation participants. Sections 5 , 5.1.4 , and 6.3 cover a number of technical requirements, the objective of which is to minimize
9.2
in 9
 Notice and Consent To build subscriber trust in federation, subscribers need to be able to develop reliable assumptions about how their information is being processed. For instance, it can be helpful for subscribers to understand what information will be tran
9.3
in 9
 Data Minimization Federation enables the data exposed to an RP to be minimized — resultantly, the subscriber’s privacy is enhanced. Although an IdP may collect additional attributes beyond what the RP requires for its use case, only those attributes that wer
9.4
in 9
 Agency-Specific Privacy Compliance Section 5.2 identifies agency requirements to consult their SAOP to determine privacy compliance requirements. It is critical to involve the agency’s SAOP in the earliest stages of digital authentication system development to assess and mit
9.5
in 9
 Blinding in Proxied Federation While some proxy structures — typically those that exist primarily to simplify integration — may not offer additional subscriber privacy protection, others offer varying levels of privacy to the subscriber through a range of blinding techno
10 Usability Considerations This section is informative. ISO/IEC 9241-11 defines usability as the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” This
10.1
in 10
 General Usability Considerations Federated identity systems should: • Minimize user burden (e.g., frustration, learning curve) o Minimize the number of user actions required. o Allow users to quickly and easily select among multiple accounts with a single IdP. For example
10.2
in 10
 Specific Usability Considerations This section addresses the specific usability considerations that have been identified with federated identity systems. This section does not attempt to present exhaustive coverage of all usability factors related to federated identity syst
10.2.1
in 10.2
 User Perspectives on Online Identity Even when users are familiar with federated identity systems, there are different approaches to federated identity (especially in terms of privacy and the sharing of information) that make it necessary to establish reliable expectations for
10.2.2
in 10.2
 User Perspectives of Trust and Benefits Many factors can influence user adoption of federated identity systems. As with any technology, users may value some factors more than others. Users often weigh perceived benefits versus risks before making technology adoption decisions. It
10.2.3
in 10.2
 User Models and Beliefs Users’ beliefs and perceptions predispose them to expect certain results and to behave in certain ways. Such beliefs, perceptions, and predispositions are referred to in the social sciences as mental models. For example, people have a menta
11 Examples This section is informative. Three types of assertion technologies are discussed below: SAML assertions, Kerberos tickets, and OpenID Connect tokens. This list is not inclusive of all possible assertion technologies, but does represent tho
11.1
in 11
 Specific Assertion Markup Language (SAML) SAML is an XML-based framework for creating and exchanging authentication and attribute information between trusted entities over the internet. As of this writing, the latest specification for SAML is SAML v2.0, issued 15 March 2005. The b
11.2
in 11
 Kerberos Tickets The Kerberos Network Authentication Service [ RFC 4120 ] was designed to provide strong authentication for client/server applications using symmetric-key cryptography on a local, shared network. Extensions to Kerberos can support the use of
11.3
in 11
 OpenID Connect OpenID Connect [ OIDC ] is an internet-scale federated identity and authentication protocol built on top of the OAuth 2.0 authorization framework and the JSON Object Signing and Encryption (JOSE) cryptographic system. OpenID Connect builds
12 References This section is informative.
12.1
in 12
 General References [FEDRAMP] General Services Administration, Federal Risk and Authorization Management Program, available at: https://www.fedramp.gov/ . [M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Governme
12.2
in 12
 Standards [BCP 195] Sheffer, Y., Holz, R., and P. Saint-Andre, Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) , BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, https://doi.org/10.17487
12.3
in 12
 NIST Special Publication NIST 800 Series Special Publications are available at: http://csrc.nist.gov/publications/PubsSPs.html . The following publications may be of particular interest to those implementing systems of applications requiring digital authentication.
12.4
in 12
 Federal Information Processing Standards [FIPS 140-2] Federal Information Processing Standard Publication 140-2, Security Requirements for Cryptographic Modules, May 25, 2001 (with Change Notices through December 3, 2002), https://doi.org/10.6028/NIST.FIPS.140-2 .

34 of 34.