認証連携の導入
従来はひとつのシステムの中で行われていたID（アカウント）の管理とサービスの提供を分離する事例が増えてきています。インターネットではFacebook, Twitter等のログイン機能を利用するサービスが増えてきていますし、企業でも企業内の認証基盤で認証した後、Salesforce.com, Office 365, Google Appsなどのクラウドサービスを利用する事例が増えてきています。このようにあるシステム（以降ID提供システム）が行った認証の結果を他のシステムに提供し、受け取ったシステム（以降サービス提供システム）はその認証結果に基づいてサービスを提供することを認証連携と呼び、SAML, OpenIDなどの技術が用いられています。
例えば、インターネット上におけるコンシューマーを対象としたサービスでは、Facebook, Twitter等のサービスと認証連携をすることで
- ユーザーへシングルサインオンを提供することができる
- ID管理の負担（ID作成、パスワードリセットなど）が減る
- より多くのユーザーにサービスを利用してもらうチャンスが増える
- 認証に関するセキュリティ攻撃（パスワードリスト攻撃など）への対応を自ら実施する必要がない
などのメリットがあり、さらに普及が進むことが予想されます。
認証連携普及時の阻害
一方、認証連携は技術だけで実現することはできません。図1に示すように、ID提供システムとサービス提供システムはそれぞれ相手に対する不安を持つことが普通です。そのため認証連携を実施する際は、
- ID情報の正しさ（例：名前が間違っていないか、すでに存在しない利用者でないか？）
- 認証結果の正しさ（例：パスワードは適切に管理されているか？成りすましの危険性はないか？）
- ID情報・認証結果の利用方法（ID情報、認証結果を他のサービスに渡さないか？）
- サービスレベル（認証サービスは常に利用可能か？）
などに関しての取り決め・契約が行われます。認証連携が少ないうちはこれらの取り決めを個別に実施すればよいのですが、多数行われるようになると、ID提供システムとサービス提供システムが個別に取り決めを行い、必要に応じてシステムの機能、運用方法などを変更するなどの必要が出てきます。これは大きな負担となり、認証連携の普及に対して大きな阻害要因となる可能性があります（図2）。
図1：認証連携時の相互の不安
図2：信頼フレームワークにより相互の取り決めが容易になる
信頼フレームワーク（Trust Framework）
この阻害要因を解決するために用意されたのが、相互が信頼するための仕組みである、信頼フレームワーク（Trust Framework）です。
信頼フレームワークはサービス提供システムが提供するサービスの内容（重要度）に応じてID情報の信頼度（LOA：Level of Assurance）を4つにレベル分けし、レベルごとにID提供システム、サービス提供システムそれぞれが準拠すべき機能的、運用的な基準・ルールを定めます。
ルールの例としては
- ID提供システムを提供する企業が法人格を有すること
- ID提供システムを提供する企業は財務的に長期間サービスを提供可能な見通しがあること
- ID提供システムは認証機能を停止する場合に管理する情報を適切に廃棄すること
といった企業の信頼性にかかわるものから
- パスワードは1012以上の組み合わせがあること（LOA1）
- パスワードは1024以上の組み合わせがあること（LOA2）
- パスワードだけではなく、2要素以上を用いてユーザー認証をすること（LOA3）
といった技術的な面、
- IDを作成する場合は、同時に電話番号、メールアドレスなどを入手し、それらと連絡可能であることを確認すること（LOA1）
- IDを作成する場合は公的な証明書により名前、住所などの記載内容が正しいことを確認すること（LOA2）
といった本人確認の方法なども含まれています。
現在米国のOpen Identity Exchange, Kantara Initiativeなどの組織は監査法人と連携して、ID提供システムへ信頼フレームワークに基づく認証の付与を始めており、すでにGoogle, PayPal, VerizonなどのシステムがID提供システムとして認証を取得しています。
図3：Open Identity Exchangeによる信頼フレームワークのモデル
日本でも信頼フレームワークの仕組みが構築されることで認証連携のいっそうの普及が可能になると思われます。
