尊敬する國領先生にお題を頂いたので、ちょっと時間がかかりましたが、ブログにまとめてみました。
まずは結論から。
(1) 識別子 → Identity Register+RA
(2) 本人確認基盤 → IdP+CSP
(3) 属性 → IIA/IIP
(4) サービス → RP/SP
と読み替えるならば、このように分割して分別管理するのが良さそう、ということになります。
以下、その解説です。
IdMの基本は、当該ユーザの識別です。識別とは、その存在を母集団の中の他の存在から一意に区別するということです。わたしたちは、存在を直接的には観測できないので、これは、その存在に紐付いている属性の値の集合が一意になるまで集めるということに他なりません。この状態では、その属性の値の集合が「識別子」になっています。ただし、値はどんどん変わり得て、別の時点では識別性がなくなるかもしれないので、識別された時点でユニークかつ不変な文字列を振っておかないと管理上困ったことになります。この目的のためにふられる識別子のことを、ISO/IEC 24760-1では reference identifier、この識別子を生成する機能のことをreference identifier generatorといいます。
識別には属性の値を使っているので、その識別の信頼性は属性の値の信頼性に依存します。この属性の値の集合の信頼性を測ることをIdentity Proofing といいます。Identity = ある主体に関係する属性の集合と定義されているので、Identity Proofing は「ある主体に関係する属性の集合を確かめること」ということになります。日本でいう「本人確認」は、基本的にはこの特殊系～属性が基本４情報～であると考えて良いです。この属性の集合の値の信頼度をISO/IEC 29115では４つに分けることを提唱しています。
Identity管理(IdM)では、識別された主体のidentityを管理していきます。そのために、Identity Register と呼ばれるレジストリに登録します。この際、Identity Proofingを行ってIdentity Registerに登録する人のことをRegistration Authority (RA)といいます。
Identityはライフサイクルを持っています。ISO/IEC 24760-1では、ライフサイクルを不明、確立済み、有効、停止、保管の５つのフェーズに分けて管理することを提唱しています。
一旦こうして識別された主体がオンラインサービスを利用するには、自分を代理させるidentityをオンライン上に生成して使います。このidentityは、本人しか作ることができなくて、かつ他者から見た時に本人が制御しているということの確認ができなければなりません。本人しか作ることができないようにするために使われる情報のことを「クレデンシャル」と呼びます。これは、本人しか作ることができないものです。代表的なものにパスワードがあります。本人は、このクレデンシャルを「確認者（verifier）」とか「Credential Service Provider(CSP)」とか呼ばれる機構に提示して、今そこにいるのは本人であることを証明します。このことを認証（Authentication）といいます。この認証を経て作られた、他者から見た時に本人が制御しているということが確認できるidentityのことを認証済みidentity（Authenticated Identity）といいます。
この認証済みidentityの信頼性は、使われたクレデンシャルの信頼性に依存しています。そしてこの信頼性は、クレデンシャルの発行～交付～有効化～利用～停止～削除までを通じたライフサイクル管理がどれだけ信頼性高く行われているかによってきます。そして、出来上がった認証済みアイデンティティの信頼性は、それに含まれる属性（クレデンシャルを使って認証したという情報も属性の一つです）の信頼性ですから、Identity Proofing で確認された属性の信頼性と、クレデンシャルの信頼性の両方に依存するということになります。
一方、属性には、識別のために使ったもの以外にもたくさんあります。Identity registerも属性を保存していますが、その属性の範囲は、Identity Proofing に必要な範囲です。それ以外もそこに突っ込んでしまうという運用も多く見られますが、必ずしもそうである必要は無く、独立した属性プロバイダーを想定することができます。ISO/IEC 24760-1では、これのことをIdentity Information Provider (IIP)と呼んでいます。一般には、属性プロバイダー（Attribute Provider）という名称のほうが使われますね。IIP中で、Authoritativeな情報を出せるもののことを、Identity Information Authority（IIA)と呼びます。情報の鮮度・正確性の観点からは、情報は常にIIAからとったほうが良いことになります。ただし、こうするとどこにその情報を提出したのかがIIAに分かってしまうので、それを回避するためにわざと他のIIPを経由して取りに行くこともあります。この辺りは、プライバシーと情報の正確性のバランスで決めるところになります。なお、認証済みアイデンティティを作成して提供する機関もIIPの一種であることに注意してください。このようなIIPのことを、業界ではIdPと呼ぶことが多いです。
なお、Identity Register はクレデンシャルやら本人による認証を通じた認証済みアイデンティティの作成やらとは完全に独立して存在しうることに注意してください。たとえば、顧客データベースなどというものは、典型的なIdentity Registerです。これの管理も広義のアイデンティティ管理の範疇に属します。
一方、こうして作られた認証済みアイデンティティを利用するひとも居ます。他者にidentity情報を依存するので、Relying Party(RP)と呼ばれます。また、これが、本人や第三者に対してサービスを提供するということに着目した場合には、Service Provider(SP)とも呼ばれます。RPは受け取った認証済みアイデンティティの信頼性や有効性を署名などから確認してから利用します。
IIPとRPの間で情報の要求・応答を行うプロトコルのことを、Identity Federation Protocol といいます。わたしが仕様策定をしていたOpenID Connectは、Identity Federation Protocol の代表例になります。OpenID Connectでは、都度、必要最低限の属性情報を要求して、本人の許可のもとに、RPが利用できるようになっています。
さて、これで、アイデンティティ管理と連携をするための機能が揃いました。（ざっくりですが。細かく言うと、PDPとかPEPとかいろいろありますが、それは別の機会に譲りましょう。）問題は、この機能をどのように配置するかです。効率性、セキュリティ、プライバシー、それぞれの観点がありますが、ここではプライバシーの観点から考えたいと思います。
プライバシーの観点から考慮すべきものをまとめたものに、いわゆる「プライバシー原則」というものがあります。OECD８原則や米国のFIPPSなどが有名ですが、ここではISO/IEC 29100の原則を使って考えたいと思います。
ISO/IEC 29100の原則は以下の11個になります。
1. 同意と選択
2. 目的の正当性と規定
3. 収集の制限
4. データ最小化
5. 利用、保持、開示の制限
6. 正確性と品質
7. オープンさ、透明性、通知
8. 個人の参加とアクセス
9. 説明責任
10. 情報セキュリティ
11. プライバシー法令遵守
この中で、配置に関係してくるのが、3. 収集の制限、5. 利用、保持、開示の制限、6. 正確性と品質、です。
「3. 収集の制限」は、当該業務を行う上で必要最低限の情報しか集めてはいけないという要求です。これに合わせようとすると、identity registerに、登録の際に必要になる情報以外を集めるのは良くないということになります。したがって、identity register とその他のIIPは独立させたほうが良いということになります。一方で、reference identifier generator とidentity registerは別管理にすることも可能ではありますが、どの道identity registerにはreference identifier が入ってしまうので、同一組織で運用したほうが効率的でしょう。一方で、Identity proofing を行い、その結果をidentity registerに登録するRegistration Authority (RA)は、Identity Registerとは別組織が運営することは多いです。Identity Registerには、Identity Proofing に使った一部の情報しか収録しないような場合には、収集の制限の原則からすると分けたほうが良さそうです。ただし、Identity Lifecycleを考えると、Identity RegisterとRAはかなり緊密に運営されるべきとなります。そして、ここの緊密な関係が維持されないと、意図されない開示だとか、他のプライバシーリスクが上がってくることが想定されます。こうした観点に鑑みて、個人的にはRAとIdentity Registerは一体運営しても良いと思っています。
「5.利用、保持、開示の制限」は、データの利用は、取得した時に許可を得た目的に沿ってしか使ってはいけない、必要な範囲でしか保持してはいけない、そして同意を受けた範囲にしか開示をしてはいけないということを言っています。ということは、データは利用目的と同意に紐づけて管理されなければならないということになります。そう考えると、異なる目的のために取得したデータをごった煮にして管理するのは、なかなか難しいということになります。したがって、RPもいたずらに統合せずに、管理負荷が大きくなり過ぎないように分割して管理したほうが良いということになります。
最後に「6. 正確性と品質」です。これは、効率上可能な限り、IIAからリアルタイムに情報をとったほうが良いですね。これもまた、いたずらにIdPに情報を集めないほうが良い理由の一つになります。なので、属性はIIA毎に管理するのが良いということになるでしょう。
最後に残ったのがCSPです。CSPはIdentity Registerと一体運営するということは十分考えられます。その場合のプライバシー影響には何があるかということですが、そんなに大きなものは即座には思いつきません。一方で、柔軟性という観点では分離することも十分ありえます。分離すれば、Identity Registerが複数のCSPを使ったり、CSPが複数のidentity registerにサービス提供したりがありえるからです。
というわけで、やっとご質問への回答です。
(1) 識別子 → Identity Register+RA
(2) 本人確認基盤 → IdP+CSP
(3) 属性 → IIA/IIP
(4) サービス → RP/SP
と読み替えるならば、このように分割して分別管理するのが良さそう、ということになります。