Assertions Federation and Assertions

NIST SP 800-63-3 D IGITAL I DENTITY G UIDELINES 21 T hi s pub lic at ion i s a v ai lab le f re e of c har g e f ro m : h ttp s : d oi .or g 10. 6 028 N IS T.S P .8 -63 -3 digital authentication scheme according to their own requirements. However, identity federation is preferred over a number of siloed identity systems that each serve a single agency or RP. Federated architectures have many significant benefits, including, but not limited to: • Enhanced user experience. For example, an individual can be identity proofed once and reuse the issued credential at multiple RPs. • Cost reduction to both the user reduction in authenticators and the agency reduction in information technology infrastructure. • Data minimization as agencies do not need to pay for collection, storage, disposal, and compliance activities related to storing personal information. • Pseudonymous attribute assertions as agencies can request a minimized set of attributes, to include claims, to fulfill service delivery. • Mission enablement as agencies can focus on mission, rather than the business of identity management. The following sections discuss the components of a federated identity architecture should an agency elect this type of model.

4.4.1 Assertions

Upon completion of the authentication process, the verifier generates an assertion containing the result of the authentication and provides it to the RP. The assertion is used to communicate the result of the authentication process, and optionally information about the subscriber, from the verifier to the RP. Assertions may be communicated directly to the RP, or can be forwarded through the subscriber, which has further implications for system design. An RP trusts an assertion based on the source, the time of creation, how long the assertion is valid from time of creation, and the corresponding trust framework that governs the policies and processes of CSPs and RPs. The verifier is responsible for providing a mechanism by which the integrity of the assertion can be confirmed. The RP is responsible for authenticating the source the verifier and for confirming the integrity of the assertion. When the verifier passes the assertion through the subscriber, the verifier must protect the integrity of the assertion in such a way that it cannot be modified. However, if the verifier and the RP communicate directly, a protected session may be used to preserve the integrity of the assertion. When sending assertions across an open network, the verifier is responsible for ensuring that any sensitive subscriber information contained in the assertion can only be extracted by an RP that it trusts to maintain the information’s confidentiality. Examples of assertions include: • Security Assertion Markup Language SAML assertions are specified using a mark-up language intended for describing security assertions. They can be used by a verifier to make a statement to an RP about the identity of a claimant. SAML assertions may optionally be digitally signed. NIST SP 800-63-3 D IGITAL I DENTITY G UIDELINES 22 T hi s pub lic at ion i s a v ai lab le f re e of c har g e f ro m : h ttp s : d oi .or g 10. 6 028 N IS T.S P .8 -63 -3 • OpenID Connect claims are specified using JavaScript Object Notation JSON for describing security, and optionally, user claims. JSON user info claims may optionally be digitally signed. • Kerberos tickets allow a ticket-granting authority to issue session keys to two authenticated parties using symmetric key based encapsulation schemes.

4.4.2 Relying Parties