3.16 Bound Authenticators

Before · SP 800-63C

After · SP 800-63C-4

Bound Authenticators

Before · SP 800-63C

After · SP 800-63C-4

A bound authenticator ( Fig. 4 ) is an authenticator that is bound to the RP subscriber account and managed by the RP. The IdP SHALL include an indicator in the assertion when the assertion is to be used with a bound authenticator at FAL3. The unique identifier for the authenticator (such as its public key) SHALL be stored in the RP subscriber account. The RP needs to have a reliable basis for evaluating the characteristics of the bound authenticator, such as the inclusion of a signed attestation, as discussed in Sec. 3.2.4 of [SP800-63B] . Bound authenticators are most often used when the authenticator technology is not tied to a PKI trusted by both the IdP and RP, for example when no such PKI exists.

A bound authenticator SHALL be unique per subscriber at the RP such that two subscribers cannot present the same authenticator for their separate RP subscriber accounts. All bound authenticators SHALL use phishing-resistant authentication mechanisms, as defined by Sec. 3.2.5 of [SP800-63B] . Consequently, subscriber- chosen values such as a password cannot be used as bound authenticators. Bound authenticators SHALL be accepted for authentication in the context of processing Primary Authenticator

Bound Authenticator Subscriber IdP / Wallet

RP Assertion
- FAL3
- Bound Authenticator

Fig. 4. Bound authenticators

an FAL3 assertion for a federated transaction. While it is possible for the same authenticator to also be used for direct authentication to the RP (see Sec. 3.8.3 ), such use is not considered a bound authenticator, and the RP SHALL document these as distinct use cases.

The IdP MAY specify types or characteristics for allowable bound authenticators in the trust agreement.

Before an RP can successfully accept an FAL3 assertion, the RP subscriber account SHALL include a reference to a bound authenticator that is to be verified during the FAL3 transaction. These authenticators can be provided by either the RP (as in Sec. 13.15.1 ) or the subscriber (as in Sec. 13.15.2 ), and different requirements apply to the initial binding of the authenticator to the RP subscriber account in each case.

The RP SHALL send a notification to the subscriber via an out-of-band mechanism (e.g., an email to an address previously associated with the subscriber) and SHOULD notify the IdP using a shared signaling system (see Sec. 4.8 ) if any of the following events occur:

• A new bound authenticator is added to the RP subscriber account.

• An existing bound authenticator is removed from the RP subscriber account.

For additional considerations on providing notice to a subscriber about authenticator management events, see Sec. 4.6 of [SP800-63B] .