+4.1 Authenticator Binding
---+4.1.1 Binding at Enrollment
---+4.1.2 Post-Enrollment Binding
------+4.1.2.1 Binding an Additional Authenticator
------+4.1.2.2 Binding Across Endpoints
---+4.1.3 Binding to a Subscriber-Provided Authenticator
---+4.1.4 Renewal

4.1 Authenticator Binding

Authenticator binding refers to establishing an association between a specific authenticator and a subscriber account to enable the authenticator to authenticate for that subscriber account, possibly in conjunction with other authenticators.

Authenticators SHALL be bound to subscriber accounts by either:

Being issued by the CSP as part of enrollment or
Using a subscriber-provided authenticator that is acceptable to the CSP.

The SP 800-63 suite of guidelines refers to the binding rather than the issuance of authenticators to accommodate both options.

Throughout the lifetime of a digital identity, CSPs SHALL maintain a record of all authenticators that are bound to each subscriber account. The CSP SHALL determine the characteristics of the authenticator being bound (e.g., single-factor versus multi-factor, phishing-resistant or not) so that verifiers can assess compliance with the requirements at each AAL. This determination MAY be based on strong evidence (e.g., authenticator attestation), direct information from having issued the authenticator, or typical characteristics of authenticator implementations (e.g., whether a user verification bit is set by [WebAuthn]).

The CSP SHALL also maintain other state information that is required to meet the authenticator verification requirements. For example, the throttling of authentication attempts described in Sec. 3.2.2 requires the CSP or verifier to maintain state information on recent failed authentication attempts, except for activation factors verified at the authenticator.

The record created by the CSP SHALL contain the date and time of significant authenticator life cycle events (e.g., binding to the subscriber account, renewal, update, expiration). The record SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the event.

As part of the binding process, the CSP MAY require additional information about the new authenticator or its associated endpoint to determine whether it is suitable for the requested AAL.

1. Przegląd

4.1.1 Binding at Enrollment

Binding at the time of enrollment is considered to be part of the enrollment process and is discussed in [SP800-63A].
4.1.2 Post-Enrollment Binding
4.1.3 Binding to a Subscriber-Provided Authenticator

A subscriber may already possess authenticators that are suitable for authentication at a particular AAL. For example, the subscriber may have their own multi-factor authenticator and would like to use that authenticator at a verifier that requires AAL2.

CSPs SHOULD, where practical, accommodate subscriber-provided authenticators to relieve the burden on the subscriber of managing many authenticators. The binding of these authenticators SHALL be done as described in Sec. 4.1.2.

As part of this process, CSPs will need to establish the capabilities and characteristics of the subscriber-provided authenticator that they wish to accept to determine its suitability for the use case and the intended AAL. The level of assurance that the CSP requires in the fidelity of these authenticator attributes MAY vary depending on the use case and threat environment. Some authenticators, such as those based on the WebAuthn standard [WebAuthn], provide metadata about the authenticator during the binding or authentication process that can be used by the CSP to inform its decisions. This metadata, for example, could indicate whether an authenticator uses an activation factor to function as a multi-factor authenticator. Similarly, some subscriber-controlled wallets will also offer metadata about its functions, including information about the mechanisms used to unlock the wallet. CSPs SHOULD consider this metadata when choosing how to support a subscriber-provided authenticator. In many cases, such information will not be available, and CSPs SHOULD evaluate the characteristics of commercially available authenticators that are likely to be used by their subscribers and make determinations about what authenticators they will accept. The types of authenticators accepted by the CSP SHALL be documented in the CSP practice statement.

In some high assurance use cases, CSPs may desire additional confidence in the attributes of the authenticators registered by their subscribers. Some authenticators support attestation features that can be used to determine the capabilities and manufacturers of specific authenticators. However, such attestation features are not widely available in authenticators that are likely to be used by public users. The lack of support for attestations SHOULD NOT block the use of authenticators for broad public-facing applications.
4.1.4 Renewal

The subscriber SHOULD bind a new or updated authenticator before an existing authenticator’s expiration. The process for this SHOULD conform closely to the binding process for an additional authenticator, as described in Sec. 4.1.2. The CSP MAY periodically take other actions (e.g., confirming contact addresses) as a part of the renewal process or separately. Following the successful use of the replacement authenticator, the CSP SHOULD invalidate the expiring authenticator.

1.1 Odwołania

1.2 Zidentyfikowane wymagania

1.3 Powiązane regulacje

2. Zidentyfikowane wymagania

Wymagania

3. Powiązane regulacje

Regulacje
  • 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.