+2.5 Examples of Digital Identity Models
---+2.5.1 Non-Federated Digital Identity Model
---+2.5.2 Federated Digital Identity Model With General-Purpose IdP
---+2.5.3 Federated Digital Identity Model with Subscriber-Controlled Wallet

2.5 Examples of Digital Identity Models

The entities and interactions that comprise the non-federated digital identity model are illustrated in Fig. 3. The general-purpose federated digital identity model is illustrated in Fig. 4, and a federated digital identity model with a subscriber-controlled wallet is illustrated in Fig. 5.

In the two cases described in Fig. 3 and Fig. 4, the verifier does not always need to communicate in real time with the CSP to complete the authentication activity (e.g., digital certificates can be used). Therefore, the line between the verifier and the CSP represents a logical link between the two entities. In some implementations, the verifier, RP, and CSP functions are distributed. However, if these functions reside on the same platform, the interactions between the functions are signals between applications or application modules that run on the same system rather than using network protocols.

1. Преглед

2.5.1 Non-Federated Digital Identity Model

Fig. 3. Non-federated digital identity model example

High-level diagram of a non-federated digital identity model showing the entities and interactions between entities of the entire digital identity process, in which the verifier function is done by the RP.

Figure 3 shows an example of a common sequence of interactions in the non-federated model. Other sequences could also achieve the same functional requirements. One common sequence of interactions for identity proofing and enrollment activities is represented as follows:

Step 1: An applicant applies to a CSP through an identity proofing and enrollment process. The CSP identity-proofs that applicant.
Step 2: Upon successful identity proofing, the applicant is enrolled into the identity service as a subscriber.
A subscriber account and corresponding authenticators are established between the CSP and the subscriber. The CSP maintains the subscriber account, its status, and the enrollment data. The subscriber maintains their authenticators.

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 perform digital authentication in the non-federated model is as follows:

Step 3: The claimant initiates an online interaction with the RP and the RP requests that the claimant 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 to 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.
2.5.2 Federated Digital Identity Model With General-Purpose IdP

Fig. 4. Federated digital identity model example

High-level diagram of a federated digital identity model showing the entities and interactions between entities of the entire digital identity process, in which the CSP and verifier functions are done by the IdP.

Figure 4 shows an example of those same common interactions in a federated model.

Step 1: An applicant applies to a CSP through an identity proofing and enrollment process. The CSP identity-proofs that applicant.
Step 2: Upon successful identity proofing, the applicant is enrolled in the identity service as a subscriber.
A subscriber account and corresponding authenticators are established between the CSP and the subscriber.
The IdP is provisioned either directly by the CSP or indirectly through access to attributes of the subscriber account. The CSP maintains the subscriber account, its status, and the enrollment data collected in accordance with the records retention and disposal requirements described in Sec. 3.1 of [SP800-63A]. The subscriber maintains their authenticators. The IdP maintains its view of the subscriber account, any federated identifiers assigned to the subscriber account, and any policies and decisions regarding the release of attributes and information to RPs.

The usual sequence of interactions involved in using one or more authenticators in the federated model to perform digital authentication is as follows:

Step 3: The RP requests that the claimant authenticate and requests any attributes needed from the IdP to make access or authorization decisions. This triggers a request for federated authentication to the IdP.
Step 4: The claimant proves possession and control of the authenticators to the verifier function of the IdP through an authentication process.
The binding of the claimant’s authenticators are verified with those bound to the claimed subscriber account and optionally to obtain additional subscriber attributes.
Step 5: The RP and the IdP communicate through a federation protocol. The IdP provides an assertion and any necessary additional attributes to the RP through a federation protocol. The RP verifies the assertion to establish confidence in the identity and attributes of a subscriber for access to an online service at the RP. RPs use a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL, FAL, and other factors to make authorization decisions.
Step 6: An authenticated session is established between the subscriber and the RP.
2.5.3 Federated Digital Identity Model with Subscriber-Controlled Wallet

Fig. 5. Federated Digital Identity Model With Subscriber-Controlled Wallet Example

High-level diagram of a federated digital identity model with a subscriber-controlled wallet showing the entities and interactions between entities of the entire digital identity process in which the subscriber controls a device with software (commonly known as a digital wallet) that acts as the IdP.

Figure 5 shows an example of the interactions in a federated digital identity model in which the subscriber controls a device with software (i.e., a digital wallet) or an account with a cloud service provider (i.e., a hosted-wallet) that acts as the IdP. In the terminology of the “three-party model,” the CSP is the issuer, the IdP is the holder (i.e., the users device or agent operating on their behalf), and the RP is the verifier. In this model, it is common for the RP to establish a trust agreement with the CSP using a federation authority, as defined in Sec. 3.5 of [SP800-63C]. This arrangement allows the RP to accept assertions from the subscriber-controlled wallet without needing a direct trust relationship with the wallet, as described in Sec. 5 of [SP800-63C].

Step 1: An applicant applies to a CSP identity proofing and enrollment process.
Step 2: Upon successful identity proofing, the applicant goes through an onboarding process and is enrolled in the identity service as a subscriber.
Step 3: The subscriber-controlled wallet is onboarded by the CSP, allowing the wallet to act in the role of IdP in later steps.
The subscriber authenticates to the CSP’s issuance functionality by authenticating to the subscriber account or completes an abbreviated proofing process to demonstrate that they are the same user represented by the subscriber account.
The subscriber activates the subscriber-controlled wallet using an activation factor.
The wallet generates or chooses a signing key and corresponding verification key, including proof of a key held by the wallet.
The CSP creates one or more attribute bundles that include subscriber attributes and the wallet’s verification key (or a reference to that key).
The CSP issues the attribute bundle with corresponding verification key into the subscriber-controlled wallet.

Other protocols and specifications often refer to attribute bundles as credentials. These guidelines use the term credentials to refer to a different concept. To avoid a conflict, the term attribute bundle is used within these guidelines. Normative requirements for attribute bundles can be found in Sec. 3.12.1 of [SP800-63C].

\clearpage

The usual sequence of interactions involved in providing an assertion to the RP from a subscriber-controlled wallet is as follows:

Step 4: The RP requests that the claimant authenticate. This triggers a request for federated authentication to the wallet.
Step 5: The claimant proves possession and control of the subscriber-controlled wallet.
The claimant activates the wallet using an activation factor or authenticates to a hosted service if the subscriber-controlled wallet is hosted by a service provider.
The wallet prepares an assertion that includes the attribute bundle provided by the CSP for the subscriber account.
Step 6: The RP and the wallet communicate through a federation protocol. The wallet provides an assertion, the CSP-signed attribute bundles and optional additional attributes to the RP through a federation protocol. The RP verifies the assertion to establish confidence in the identity and attributes of a subscriber for access to an online service at the RP. RPs use a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL, FAL, and other factors to make authorization decisions.
Step 7: An authenticated session is established between the subscriber and the RP.

1.1 Препратки

1.2 Идентифицирани изисквания

1.3 Свързани регулации

2. Идентифицирани изисквания

Изисквания

3. Свързани регулации

Регулации
  • NIST -

    EN: Publications of the National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, from their electronic versions (OSCAL; SP 800-63-4 from its HTML version, https://pages.nist.gov/800-63-4/). Works of NIST employees are not subject to copyright protection in the United States (17 U.S.C. § 105); the OSCAL content is dedicated to the public domain worldwide (CC0 1.0); outside the United States NIST grants the right to reprint its technical series publications in all formats (NIST copyright statement). Republished courtesy of the National Institute of Standards and Technology; each document names its citation. Divided into sections and converted into the GRCA format, the wording unchanged. Only the versions published by NIST are authoritative.

    DE: Veröffentlichungen des National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, aus ihren elektronischen Fassungen (OSCAL; SP 800-63-4 aus ihrer HTML-Fassung, https://pages.nist.gov/800-63-4/). Werke von NIST-Beschäftigten sind in den USA urheberrechtlich nicht geschützt (17 U.S.C. § 105); die OSCAL-Inhalte sind weltweit gemeinfrei gestellt (CC0 1.0); außerhalb der USA räumt das NIST das Recht ein, seine Technical-Series-Publikationen in allen Formaten neu zu veröffentlichen (Copyright-Hinweis des NIST). „Republished courtesy of the National Institute of Standards and Technology“; jedes Dokument nennt seine Zitierangabe. In Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Maßgeblich sind allein die vom NIST veröffentlichten Fassungen.