【要点抽出】NIST SP800-63C-4（前編）
SP800-63シリーズの最後、63Cを読みます。
はじめに
本noteでは、OpenIDファウンデーションジャパンによる翻訳版を読んでいます。ただ、翻訳版ではあえて正確に伝えるために単語を英語のまま表記しているのに対し、本noteでは読みやすさのために私なりの便宜的な日本語をあてはめています。
そうした箇所は、「身元確認（Identity Proofing）」といった形で、便宜的な日本語+括弧書きで元の英語 という形で記しています。
何の本？
63CはフェデレーションにおいてIdPとRPに求められる要件がまとまった本です。
構成は？
本書は、SP800-63シリーズの中でも第3版からの改訂が最も激しいように思います。章立ては大きく変わっていないものの、各セクション内に新しい記載がかなり増えています。
私は本書を読むのが初めてなので第3版との比較はしませんが、変更点は以下に分かりやすく書いてくださっています。
内容は全12セクションです。このうち1～3の前置き部分と、8～11のSecurity、Privacy、Usability、Equity(SP800-63で掲げられた4つの観点）をそれぞれ掘り下げる構成は63A、63Bと共通です。
真ん中の4～7が本書が扱うフェデレーションならではのセクションであり、Normativeな内容です。（12はSAMLやケルベロスの紹介程度です）
また、本書では4.セクションに本題としての各FALの要件が定められていますが、それを理解するためには先に5.セクション以降を読んでおいたほうがよさそうです。
前提知識
本書ではフェデレーションを以下のように説明しています。
Federation とは, Authentication イベントに関する Attribute および Subscriber に関する Attribute を Network 化されたシステム間で伝播することを可能とするプロセスである.
フェデレーションはIdP・RP・登録済利用者（Subscriber）の間でやりとりされるものであり、要はSubscriberがIdP（認証システム的）に対して認証し、その後RP（サービス提供システム）からサービスを受けるというものです。それぞれの意味はこちらを参照ください。
RPは登録済利用者（Subscriber）をFederated Identifierという識別子を用いて識別します。この識別子は、IdPが提示するSubject Identifier + IdP自身を識別する識別子の組み合わせです。
IdPが登録済利用者（Subscriber）を認証した後に、IdPからRPへモロモロの情報を連携することをアサーションと言います。
アサーションにはFederated IdentifierやAttributeと呼ばれる登録済利用者（Subscriber）の各種属性情報を含みます。
こうした情報は、Attribute-based Access Control (ABAC) におけるアクセス権の決定やRPのサービス提供に用いられます。
IdPは登録済利用者アカウント（Subscriber Account）を管理しますが、RP側でも登録済利用者アカウント（Subscriber Account）を持つ場合があります。これはRP Subscriber Accountと呼ばれます。IdPから連携された情報や、RP自身に閉じた情報を含みます。
５．Federation
（１）全体の流れ
今回も63Bと同様に、FALを定めた4.セクションに入る前に5～7.セクションを読みます。
IdPとRP間でフェデレーションを行うには、以下の段階を踏みます。
①IdPとRPが「僕たち連携しようね」的な約束（Trust Agreement）に合意する
②IdPとRPが「僕たちが連携する時の合言葉はこれだよ」的な約束（Registration）を行う
③IdPとRPが「僕たちこんな内容を連携しようね」的な取り決めを行う
＃①の中で済ませる場合もあります④登録済利用者（Subscriber）がIdPに対して認証し、IdPがRPにアサーションを連携する。
⑤RPはアサーションを確認し、RP側の登録済利用者アカウント（RP Subscriber Account）を作成し、Attributeを紐づける（Provisioning）
#このアカウントは認証前に作られる場合もあります⑥RPが登録済利用者（Subscriber）との間に認証済セッションを確立する。
（２）Trust Agreement
①のTrust Agreement（本書では5.1セクション）は第4版から登場したようです。Agreementの中で以下の内容を取り決めます（SHALL）。
IdPがRPに開示できるAttributeのリスト
IdPがアサーションを生成できる登録済利用者アカウント（Subscriber Account）の母集団
RPがIdPから受け取りたいAttributeのリストと各利用目的
Attributeの開示に関する意思決定の責務を負うヒトや組織（Authorized Party）
RPにどのAttributeが連携されるかについて、登録済利用者（Subscriber）が知る手段
IdPが提供できるxAL
RPが必要とするxAL
登録済利用者アカウント（RP Subscriber Account）の紐づけ（Provisioning）方法
RPがIdPのProvisioning APIへのAccessをいつ与えらえるか
Trust Agreementの締結方法には、StaticとDynamicの２種類があります。
Static Trust Agreementは、上記の箇条書きの内容を契約等を通じて事前にIdPとRP間で取り決めます。
この際、上の箇条書きにある「Authorized Partyは誰か」という論点があるのですが、これは「IdPが登録済利用者（Subscriber）のAttributeの開示先をどのように決めるか」によって異なります。
1つの方法は、IdPが開示先のRPを事前に決めておくというものです。IdPはいちいち登録済利用者（Subscriber）に対して「このRPにアナタの情報を開示していいですか？」とは聞かず、事前に作ったAllowlistに記載のRPに対して開示します。この場合、Authorized PartyはIdPの管理組織となります。
もう１つの方法は、IdPが都度、登録済利用者（Subscriber）に対してAttributeの開示先を確認する（IdP Runtime Decisions）ものです。この場合、Authorized Partyは登録済利用者（Subscriber）自身となります。
Dynamic Trust Agreementは、登録済利用者（Subscriber）がログインする際にIdPとRP間でモロモロを締結するやり方です。
この場合、IdPは都度、登録済利用者（Subscriber）に対してAttributeの開示先を確認せねばならず（SHALL）、Authorized Partyは登録済利用者（Subscriber）一択です。
Static、Dynamicいずれにせよ、IdPとRP間の取り決め内容は登録済利用者（Subscriber）に開示する必要があります（SHALL）。
また別の切り口として、複数のIdP-RPのペアが存在する際に、Trust Agreementをどう結ぶかという論点もあります。
これは二者間（Bilateral）、多者間（Multilateral）の2種類があります。
二者間とは、IdP-RPの各ペアがそれぞれ相互にAgreementを締結する方法です。
多者間とは、Federation Authorityという仕切り屋が登場し、複数のIdPやRPを審査し、それぞれのxALの充足状況を確認します。
更に、話のつながりが分かりにくいですが、本書ではProxied Federationという方式が紹介されています。
これはIdPとRPが直接通信せずに、間にFederation Proxyと呼ばれるものを挟みます。
こうすることでRPとIdP間の連携を共通化したり、双方が相手に対して隠したい情報の秘匿（例えばユーザのプライバシー保護等）を行うことができます。
一方で、通常のIdPとRPの関係に比べて登場人物が増えるため、全体の中で最も低いFALが適用される（SHALL）点に注意が必要です。
（３）Registration
②のRegistration（本書では5.2セクション）は、IdPからRPにアサーションを送る際に確認に用いる暗号鍵、システムの識別子、サービスエンドポイント URL、必要なアクセス権などを取り決めておきます。
これをIdPとRPの担当者がそれぞれ手動で登録するManual Registrationと、相互に通信しながら登録するDynamic Registrationがあります。
いずれにせよ、相手方を確認するための暗号鍵等の受け渡し方が肝心であり、これをセキュアな手法で行うことが求められます（SHALL）。
なお、Dynamic Registrationの場合は、以下2点が求められます（それぞれSHOULD）。
RPに対してPairwise Pseudonymous Subject Identifier（PPI）を発行する。
PPIとは、IdPがAさんの情報をRP1とRP2に送る際、各RPに対してAさんを意味する識別子を別々に割り振ることで、RP1と2の間で情報を組み合わせてもAさんのことをトラッキングしづらくするための方法です。RPに対してSoftware Statementを付与する。
Software Statementとは、IdPやFederation AutorityによるRPソフトウェアについての署名です。
このTrust AgreementとRegistrationを通じてIdPとRPが連携可能となります。
（４）Provisioning
⑤のProvisioningは、RPの登録済利用者アカウント（RP Subscriber Account）に登録済利用者（Subscriber）のAttributeを紐づけることですが、様々な方法があります（本書では5.4セクション）。
以下のどのプロビジョニングモデルであっても、IdPとRP間でやりとりする情報はプライバシーに直結するので、プライバシーリスクアセスメントや適切な保護が必要です（SHALL）。
Just-In-Time Provisioning
登録済利用者（Subscriber）がIdPに認証し、RPが初めてそのユーザのアサーションを受け取った時にプロビジョニングを行うPre-provisioning
登録済利用者（Subscriber）の認証前に、IdPとRP間で連携してプロビジョニングを済ませておくEphemeral
Just-In-Timeとほぼ同じだが、ユーザのセッションが終了した後にRPは登録済利用者アカウント（RP Subscriber Account）を削除する
#ほぼ使われません
こうしたフェデレーションの中でやりとりされる登録済利用者（Subscriber）についてのAttributeは、常にIdpとRPの間で同期がとれているとは限りません。
この情報の鮮度差を防ぐために、以下が求められます。
IdPはRPへ提供したAttributeに更新があった場合、RPにシグナルを送る（SHOULD）
IdPは登録済利用者アカウント（Subscriber account）が解約・終了（Terminate）されたり、RPへのアクセスが無効化された場合、RPにシグナルを送る（SHOULD）
このシグナルについては5.7セクションで詳述されており、IdPとRPが互いにどういうシグナルを送るのかはTrust Agreementに規定し、プライバシーレビューの対象とすることを求めています（SHALL）。
シグナルは以下のタイミングで送ることが考えられます（MAY）。
登録済利用者アカウント（Subscriber Account）に以下の変更が生じた際にIdPが送る
アカウントが解約・終了（Terminate）された
アカウントが侵害された恐れがある
アカウントのAttributeに変更が生じた（メアドの変更など）
アカウントに適用されうるxALの範囲に変更が生じた
RPの登録済利用者アカウント（RP Subscriber Account）に以下の変更が生じた際にRPが送る
アカウントが解約・終了（Terminate）された
アカウントが侵害された恐れがある
RPが管理するBound Authenticator（後編で解説）が追加・削除された
この他、5.4セクションではIdPが提供する「Provisioning API」を用いた登録済利用者（Subscriber）のAttributeの受け渡しや、RPがIdP以外からAttributeを集める「Attribute Collection」、一定期間RPにユーザからのアクセスが無かった場合にRP側の登録済利用者アカウント（RP Subscriber Account）を削除する「Time-based Removal of RP Subscriber Accounts」について触れていますが、ここでは割愛します（ただし、全て第4版から初登場のようです）。
（５）Reauthentication
⑥のRP－登録済利用者（Subscriber）間の認証済セッションとIdP－Subscriber間のセッションは互いに独立しています。
つまり、登録済利用者（Subscriber）がIdPに認証した後、RPからサービスを受けるまでの間が必ず連続しているとは限りません。
これを踏まえ、RPは、許容できる認証有効期間をIdPに指定します (SHALL）。
登録済利用者（Subscriber）が最後に認証した後に、RPが示す有効期間を超えて認証がなされなかった場合は、IdPはSubscriberに対して再認証を求める必要があります（SHALL）。
IdPは、認証イベント時刻をRPに伝える必要があります（SHALL）。
（６）Privacy
最後にプライバシーについてです。
フェデレーションにおいては複数の登場人物の間を登録済利用者（Subscriber）のプライバシーにかかわる情報がやりとりされます。
仮にIdPが悪意をもった場合、登録済利用者（Subscriber）がどのRP達とやりとりしているのかを調べることで、特定のユーザの情報をトラッキングできます。あるいは、目的外の用途にSubscriberの情報を活用することも考えられます。
これを防ぐために、IdPはユーザに通知をする、同意を得る、開示可能なAttributeを選ばせるなど、ユーザが自分の情報をどう扱われるかを知り・管理できる術を提供することを求めています（SHALL）。
また、その同意がないとIdentity Serviceは提供しないよ！みたいな同意の強要を禁止しています（SHALL NOT）。
仮にRPが悪意をもった場合、複数のRP同士が共謀することで、登録済利用者（Subscriber）の情報をトラッキングできます。
ここは上記②でも記載したPairwise Pseudonymous Identifier（PPI）やプライバシーを向上させる暗号プロトコルを使うことで対策するべき（SHOULD）としています。
５．セクションだけで随分長くなってしまいました。
残りは６．７．４．セクションは後編とします。
SP800-63-4：こちら
SP800-63A-4：こちら
SP800-63B-4（前編）：こちら
SP800-63B-4（後編）：こちら
SP800-63C-4（前編）：こちら（この記事）
SP800-63C-4（後編）：こちら
＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら
この記事が気に入ったらサポートをしてみませんか？