Skip to content
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

LoA(Level of Assurance)

概要

NIST(米国国立標準技術研究所)の公式ドキュメント、
SP 800-63-3 で要求事項を具体的に定めている。

LoA定義

LoA IAL AAL FAL
1 1 1 1
2 2 2 or 3 2
3 2 2 or 3 2
4 3 3 4

移行メモ(重要): この対応表は 「旧 SP 800-63-2 の LoA 1〜4」を 「SP 800-63-3 の IAL / AAL / FAL」に読み替えるための参考表である。

SP 800-63-3(2017 年)では、 単一の LoA という考え方そのものが廃止され、 IAL / AAL / FAL を独立に選ぶ方式に変わった。 「LoA 2 相当」といった言い方は既に非標準なので、 新規の設計では IAL/AAL/FAL をそれぞれ指定すること。

廃止された理由は、実務上 「本人確認は厳格にしたいが、認証は使いやすくしたい」 といった非対称な要件が普通に存在し、 1 本の尺度では表現できなかったためである。

詳細

保証タイプ

# レベル 略号 段階
1 Identity Assurance Level IAL Lv.1 – Lv.3 までの 3 段階
2 Authenticator Assurance Level AAL Lv.1 – Lv.3 までの 3 段階
3 Federation Assurance Level FAL Lv.1 – Lv.4 までの 4 段階

移行メモ(正誤): FAL は Lv.1 – Lv.3 の 3 段階である。 4 段階としているのは、旧 FICAM の LoA 4 段階との混同と思われる。 後述の「Lv.4 = Holder-of-Key」も、 SP 800-63-3 では FAL 3 に相当する。

Identity Assurance Level (IAL)

ユーザが申請者(Applicant)として新規登録(SignUp)する際に、
CSP(Credential Service Provider)が行う
本人確認(Identity Proofing)の厳密さ、強度を示す。

Lv 説明
1 本人確認不要、自己申告での登録でよい
2 サービス内容により識別に用いられる属性をリモートまたは対面で確認する必要あり
3 識別に用いられる属性を対面で確認する必要があり、確認書類の検証担当者は有資格者

Authenticator Assurance Level (AAL)

登録済みユーザ(Claimant)がログインする際の認証プロセス
(単要素認証 or 多要素認証、認証手段)の強度を示す。

Lv 説明
1 単要素認証で OK
2 2 要素認証が必要、2 要素目の認証手段はソフトウェアベースのものでOK
3 2 要素認証が必要、かつ 2 要素目の認証手段はハードウェアを用いたもの(ハードウェアトークン等)

補足: AAL 3 は単に「ハードウェア」であればよいのではなく、 フィッシング耐性(verifier impersonation resistance) が要求される。 したがって ワンタイム・パスワード の ハードウェア トークン(SecurID 等)では AAL 3 を満たさず、 FIDO2 セキュリティ キーや PIV カードのような 「接続先のオリジンに鍵が紐づく」方式が必要になる。

Federation Assurance Level (FAL)

米国連邦政府 Federal Identity Credential and Access Management (FICAM)
信頼フレームワークによって規定される保証。

  • Assertion と Federation Protocol の特徴をカテゴリ分類し、
    それらの組み合わせによって FAL を定義している。
  • ID トークンや SAML Assertion 等、
    Assertion のフォーマットやデータやり取りの仕方の強度を示す。
Lv 説明
1 Assertion(RP に送る IdP での認証結果データ)への署名
2 署名に加え、対象 RP のみが復号可能な暗号化
3 Lv.2 に加え、Holder-of-Key Assertion の利用
ユーザごとの鍵と IdP が発行した Assertion を紐づけて RP に送り、
RP はユーザがその Assertion に紐づいた鍵を持っているかを確認

移行メモ(正誤): 元表は 4 段階で、 Lv.1 と Lv.2 が同一の説明(いずれも「署名」)になっていた。 SP 800-63-3 の FAL は 3 段階であり、

  • FAL 1: 署名された Assertion(Bearer)
  • FAL 2: 署名+ RP 向けの暗号化
  • FAL 3: さらに Holder-of-Key

であるため、上表のとおり整理した。

保証レベル

移行メモ: 以下は旧 SP 800-63-2 に基づく LoA の記述である。 前述のとおり現行の SP 800-63-3 では廃止されているが、 既存システムの要件定義書に「LoA 2 準拠」等の記載が残ることは多いため、 参照用として残す。

LoA 1

  • 最も基本的な第 1 保証レベル

    • 使用されるたびに特定の資格が同じ人物を表すという合理的な保証を提供。
    • 一般的なインターネットのアイデンティティに関連するおおまかな信頼。
  • 定義: IAL 1 / AAL 1 / FAL 1

  • 識別子: urn:mace:incommon:iap:bronze

LoA 2

  • 基本的な金融取引に適合する第 2 保証レベル

    • 個人の身元を合理的に保証する身元証明要件を持つ。
    • 基本的な金融取引におおよそ適切なセキュリティレベルを提供。
  • 定義: IAL 2 / AAL 2 or 3 / FAL 2

  • 識別子: urn:mace:incommon:iap:silver

LoA 3

2 との違いは・・・。

  • 定義: IAL 2 / AAL 2 or 3 / FAL 2
  • 識別子: 発見できず。

補足: 「LoA 2 と LoA 3 の違いが表からは読み取れない」という 作者の疑問はもっともである。 冒頭の対応表は 旧 LoA を新 IAL/AAL/FAL に写像した際の近似であり、 写像の結果 LoA 2 と LoA 3 が同じ組み合わせになってしまっている。

旧 SP 800-63-2 では、LoA 3 は 「多要素認証が必須、かつ暗号鍵の所持証明が必要」 という点で LoA 2(単要素でも可)と区別されていた。 この違いが、新体系では AAL の中に吸収されている。 これも「単一の LoA では表現しきれない」ことの一例と言える。

アプリケーションからの参照

補足: 実際のプロトコルでは、 保証レベルは acr(Authentication Context Class Reference) として トークンに載る。

  • OpenID Connect — ID トークンの acr クレーム、 要求時は acr_values パラメータ
  • SAMLAuthnContextClassRef

RP 側は「AAL 2 以上でなければ再認証させる」といった判断を このクレームで行う。 Microsoft Entra ID の条件付きアクセス Microsoft Entra ID の条件付きアクセス も、 実質的にこの考え方(要求されるレベルに応じて認証を強める)である。

参考


Tags: IT国際標準, 認証基盤

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally