+9.1 Mapping FALs to Common Federation Protocols

9.1 Mapping FALs to Common Federation Protocols

OpenID Connect [OIDC], SAML [SAML], and various digital wallet technologies provide a variety of capabilities that can be leveraged to reach the requirements at different FALs. Table 6 provides examples of specific options in these protocols that could be deployed to reach a given FAL. It is important to note that this table does not represent a normative mapping to the given FALs, and the entirety of the federation process has to be considered when establishing an FAL. Additionally, each FAL could be reached by processes, deployments, and procedures that are not listed in this table.

Table 6. FAL protocol examples

  OIDC SAML Wallet
FAL1 All core flows in [OIDC] (i.e., Authorization Code, Implicit, and Hybrid) can be configured to require the assertion (i.e., the ID Token) to be signed using JSON Web Signatures. Assertions are presented in a variety of front- and back-channel methods. Each of these flows can be built using both manual and dynamic client registration. Profiles such as [OIDC-Basic] and [OIDC-Implicit] can provide additional guidance for interoperable deployments. The [SAML-WebSSO] profile allows for the signing of assertions using XML D-Sig and the presentation of the assertion using the front channel. SAML deployments are generally set up with a manual registration that can meet the requirements at FAL1 and above. Registration is sometimes managed through a federation authority. The subscriber’s CSP issues an attribute bundle to the subscriber’s chosen wallet software using [OIDC4VCI]. The RP requests an attribute from the subscriber’s wallet using [OIDC4VP], and the RP validates that the assertion and the attribute bundle are properly formed and signed. The RP accepts the assertions based on subscriber-driven interactions and does not have a pre-configured list of CSPs from which it will accept attribute bundles.
FAL2 Flows that present the ID Token in the back channel (e.g., Authorization Code, Hybrid) can provide a level of assertion injection protection. The Artifact Binding of SAML defined in [SAML-Bindings] allows for a back-channel presentation of SAML assertions that can provide a level of assertion injection protection. The RP can be configured to trust a specific set of CSPs from which it will accept attribute bundles for its purposes without knowing ahead of time the wallets that will be used. By using on-device assertion presentation methods, the wallet can provide assertion injection protection.
FAL3 The ID Token can include the necessary claims for holder-of-key and bound authenticator assertion presentations, though there are no industry standard profiles that do so at the time of publication. The SAML Holder-of-Key profile can fit the assertion requirements at this level, if combined with other deployment choices. The RP accepts a trust agreement with a CSP that has a strict process for onboarding any wallets and is managed by a federation authority. In addition to presenting the attribute bundles, the wallet sends proof of possession of an authentication key in its proof, allowing the RP to reach FAL3 using a holder-of-key process. It is also possible to combine an assertion from a subscriber-controlled wallet with a bound authenticator.

For actual deployments, there are additional considerations outside of those that affect the FAL. For OpenID Connect in particular, it is common practice to give access to an identity API (i.e., the UserInfo Endpoint) and additional APIs. While the security of API access is outside of the scope of these guidelines, an OpenID Connect implementation ought to strive to increase the security of all API calls in tandem with the FAL. For example, in addition to requiring a holder-of-key assertion at FAL3, which requires the verification of a subscriber-held signing key, an OpenID Connect system might also require sender-constrained access tokens for API access, which require the verification of a signing key held by the RP for each API call.

1. Panoramica

1.1 Riferimenti

1.2 Requisiti identificati

1.3 Regolamentazioni correlate

2. Requisiti identificati

Requisiti

3. Regolamentazioni correlate

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