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.5.1 Non-Federated Digital Identity Model (was: SP 800-63-1)

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.5

Title changed

Before · SP 800-63-3

SP 800-63-1

After · SP 800-63-4

SPNon-Federated 800-63-1Digital Identity Model

Control changed

Before · SP 800-63-3

NIST SP 800-63-1 updated NIST SP 800-63 to reflect current authenticator (then referred to as “token”) technologies and restructured it to provide a better understanding of the digital identity architectural model used here. Additional (minimum) technical requirements were specified for the CSP, protocols used to transport authentication information, and assertions if implemented within the digital identity model.

After · SP 800-63-4

NISTFigure SP3 800-63-1shows updatedan NISTexample SPof 800-63a tocommon reflectsequence currentof authenticatorinteractions (thenin referredthe tonon-federated asmodel. “token”)Other technologiessequences could also achieve the same functional requirements. One common sequence of interactions for identity proofing and restructuredenrollment itactivities tois providerepresented as follows:

• Step 1: An applicant applies to a betterCSP understandingthrough ofan identity proofing and enrollment process. The CSP identity-proofs that applicant.

• Step 2: Upon successful identity proofing, the digitalapplicant is enrolled into the identity architecturalservice modelas useda heresubscriber.

– AdditionalA (minimum)subscriber technicalaccount requirementsand werecorresponding specifiedauthenticators forare established between the CSP and the subscriber. The CSP maintains the subscriber account, protocolsits usedstatus, and the enrollment data. The subscriber maintains their authenticators. Fig. 3. Non-Federated Digital Identity Model Example Verifier

CSP Subject

RP 1

2 4 3 5

Identity Proofing and Enrollment

Authenticator Enrollment / Issuance Authentication Request

Authentication Process Authenticated Session

Subject Roles Applicant

Claimant Subscriber

Steps 3 through 5 can immediately follow steps 1 and 2 or be done at a later time. The usual sequence of interactions involved in using one or more authenticators to transportperform digital authentication information,in the non-federated model is as follows:

• Step 3: The claimant initiates an online interaction with the RP and assertionsthe ifRP implementedrequests withinthat the digitalclaimant authenticate.

• Step 4: The claimant proves possession and control of the authenticators to the verifier function through an authentication process:

– The verifier interacts with the CSP to verify the binding of the claimant’s identity modelto their authenticators in the subscriber account and to optionally obtain additional subscriber attributes.

– The CSP or verifier functions of the service provider give information about the subscriber. The RP requests the attributes that it requires from the CSP. The RP optionally uses this information to make authorization decisions.

• Step 5: An authenticated session is established between the subscriber and the RP.