競輪補助事業 平成１９年度 Web 資源有効活用を推進する情報基盤 の標準化調査研究補助事業 アイデンティティ管理 技術の標準化調査研究 成 果 報 告 書 平成２０年３月 財団法人 日本規格協会 情報技術標準化研究センター 平成 19 年度アイデンティティ管理技術の標準化調査研究報告書 目 次 まえがき ············································································· 1 1. 調査研究の概要 ··································································· 2 1.1 序文············································································ 2 1.2 目的············································································ 2 1.3 委員会構成とテーマ ······························································ 3 1.4 委員会名簿 ······································································ 3 1.5 委員会実施状況 ·································································· 4 1.6 成果一覧········································································ 5 2. 委員会の活動報告 ································································· 6 2.1 背景と目的 ······································································ 6 2.2 活動内容········································································ 6 2.3 成果············································································ 7 2.4 今後の課題 ······································································ 7 3. WG１の活動報告 ··································································· 8 3.1 背景と目的 ······································································ 8 3.2 活動内容········································································ 8 3.3 成果··········································································· 24 3.4 今後の課題 ····································································· 24 4. WG2 の活動報告 ·································································· 25 4.1 背景と目的 ····································································· 25 4.2 活動内容······································································· 27 4.3 成果··········································································· 56 4.4 今後の課題 ····································································· 57 5. 今後の展望と課題 ································································ 58 附属資料 アイデンティティ管理技術の標準化動向 ······································ 59 A. ISO/IEC JTC1/SC27 WG5 におけるアイデンティティ管理技術標準化活動 B. リバティアライアンスにおけるアイデンティティ管理技術標準化活動 C. マイクロソフト社におけるアイデンティティ管理技術の展開 D. ベリサイン社におけるアイデンティティ管理技術の展開 (ⅰ) まえがき この報告書は、、自転車等機械工業振興事業に関する補助事業の選定の基準及び補助の方法に関す る規程により日本自転車振興会殿から交付を受けた補助金に基づいて INSTAC が実施した補助事業、 平成 19 年度 Web 資源有効活用を推進する情報基盤の標準化調査研究のうち、アイデンティティ管理 技術の標準化調査研究の成果を報告するものである。 行政などの公的機関により、あるいは様々の企業により、Web 資源を活用する多様な情報サービス 事業が企画され、あるいは既に実施されている。Web 資源の活用技術が社会の様々な場面に普及する に伴って、Web 資源の提供者、Web 資源の利用者双方にとって、アイデンティティ管理に係わる種々 の課題が認識されるようになった。 様々な Web 資源活用事業を推進し、提供される Web 資源を有効に活用するためには、アイデンティ ティ管理に関連して認識されている課題の解決が必要であり、そのための有効な手段としての、アイ デンティティ管理技術の普及が要請されている。 本調査研究では、アイデンティティ管理技術を標準化し、普及をはかるために、その標準化動向を 調査した。その結果を報告する。 2008 年 3 月 1 日 アイデンティティ管理技術の標準化調査研究委員会 - 1 - 1. 調査研究の概要 1.1 序文 アイデンティティ管理技術の標準化は INSTAC が試行している標準化テーマ調査活動において、平 成 17 年度に提案された調査研究テーマである。平成 18 年度の予備的検討の後、本年度に調査研究活 動を実施した。 1.2 目的 情報技術（IT）におけるアイデンティティ管理技術とは、高度に発展を続ける情報ネットワークの 中で、実在するもの（たとえば人、モノなど）と同一性を示す数値や識別子を管理、認証する技術で あり、バーチャルなネットワークを介した相手側に存在するリアルな存在を、ネットワークを通して 効率的に認識するための技術である。高度ネットワークを活用して場所や時間を超越した社会の様々 な活動は、企業内・企業間の電子化に始まり、最近では行政の電子化と関連して、年金・医療・介護 保険制度などの公共サービス部門でもその必要性が訴えられており、これら現代の IT インフラスト ラクチャにとって、アイデンティティ管理技術は、なくてはならない重要な技術である。 IT インフラストラクチャの中でも代表的なウェブシステムを例に取ると、利用者のアカウント管理 に関して次の課題が意識されるようになってきた。利用者にとって、利用するすべてのアカウント情 報を管理し、使い分けるのは、利用するウェブサイトが増加するに伴い煩雑となる。またウェブサー ビス提供者にとっては、利用者の新規申請、資格の更新・削除が利用者の増加に伴って煩雑となる。 この課題に対応するための技術としてアイデンティティ管理技術が必要となる。 アイデンティティ管理技術は、利用者のアカウント登録から削除までの間に発生するさまざまな事 象に対するサービスを提供する。例えば「認証」に関連するサービスには次がある。利用者がアクセ スを要求している情報の提供者からの要請に応じて、利用者のアイデンティティ（電子メールアドレ スのような所有権の確認、クレジットカードのような一意なオブジェクト表現の提示、パスワードの ような秘密情報の用意といったもの）を検索し、返信する。この返信を利用することで、情報提供者 は、利用者からのアカウント提示を省いて当該情報へのアクセスを許可することができる。利用者の アカウントが登録され削除されるまでの期間を指してアイデンティティのライフサイクルと言うこ とがあるが、この期間に発生する様々な事象に誤りなく対応するためには、利用者ごとに管理システ ムに登録されたアイデンティティと実際の利用者のアイデンティティとの一貫性を制御することが 要請される。この要請に対応するサービスは、「アイデンティティのライフサイクル管理」と呼ばれ ることがある。 「アイデンティティのライフサイクル管理」によりサービス提供者のアカウント管理 が煩雑化する課題を解決する。アイデンティティ管理技術が提供するサービスには、以上述べたとお り、アイデンティティのライフサイクルに発生する事象に対応するサービス提供と、アイデンティテ ィのライフサイクル管理との二つの相がある。 IT インフラストラクチャの発展拡大に伴って、このアイデンティティ管理技術はますますその必要 性が高まってきた。本調査研究においては、このアイデンティティ管理技術の普及という社会的要請 に向けた課題分析を目的とする。技術シーズからの分析アプローチと、社会的なニーズからの分析ア プローチにより、課題を抽出する。その上で、標準化項目の抽出を行い、標準化の実践につなげて行 く。 - 2 - 1.3 委員会構成とテーマ アイデンティティ管理技術の動向及びアイデンティティ管理技術の利用に関する要件を調査する。 調査結果をとりまとめて、アイデンティティ管理技術の普及のための標準化要件をとりまとめる。こ の目的を達成するために、次の委員会を構成する。 委員会構成 アイデンティティ管理技術標準化調査研究委員会 WG1（要件調査） WG2（標準化動向調査） 1.4 委員会名簿 本委員会 氏 名 所 属 委員長 安田 浩 東京電機大学 幹事 川村 直毅 (株)NTT データ 委員 朝倉 敬喜 日本電気(株) 委員 飯島 正 慶應義塾大学 委員 五十嵐 達治 富士通(株) 委員 岩崎 弘利 (株)デンソーアイティーラボラトリ 委員 岩下 直行 日本銀行金融研究所 委員 遠藤 直樹 (株)東芝ソリューション 委員 影井 良貴 日本電信電話(株) 委員 古原 和邦 (独)産業技術総合研究所 情報セキュリティ研究センター 委員 篠田 英範 保健医療福祉情報システム工業会 委員 豊内 順一 内閣府情報セキュリティセンタ 委員 戸邉 照雄 ニフティ(株) 委員 平野 芳行 日本電気(株) 委員 平山 光則 NAA 成田国際空港(株) IT 推進室 委員 本多 義則 (株)日立製作所 委員 松尾 真一郎 (株)NTT データ 技術開発本部 委員 木田 正文 日本 IC カードシステム利用促進協議会 関係者 小林 秀司 経済産業省 産業技術環境局 情報電子標準化推進室 事務局 木村 高久 (財)日本規格協会情報技術標準化研究センター主任研究員 事務局 宮古 牧子 (財)日本規格協会情報技術標準化研究センター 中央研究所標準化推進本部 WG1 氏 名 所 属 - 3 - 主査 古原 和邦 (独)産業技術総合研究所 情報セキュリティ研究センター 幹事 川村 直毅 (株)NTT データ 委員 遠藤 直樹 (株)東芝ソリューション 委員 影井 良貴 日本電信電話(株) 委員 小出 信介 富士通(株) 委員 戸邉 照雄 ニフティ(株) 委員 平野 芳行 日本電気(株) 委員 本多 義則 (株)日立製作所 委員 松尾 真一郎 (株)NTT データ 技術開発本部 経済省 小林 秀司 経済産業省 産業技術環境局 情報電子標準化推進室 事務局 木村 高久 (財)日本規格協会情報技術標準化研究センター主任研究員 事務局 宮古 牧子 (財)日本規格協会情報技術標準化研究センター 中央研究所標準化推進本部 WG2 氏 名 所 属 主査 飯島 正 慶應義塾大学 幹事 川村 直毅 (株)NTT データ 委員 五十嵐 達治 富士通(株) 委員 岩崎 弘利 (株)デンソーアイティーラボラトリ 委員 篠田 英範 保健医療福祉情報システム工業会 委員 杉山 和弘 (株)NTT ソフトウェア 委員 豊内 順一 内閣府情報セキュリティセンタ 経済省 小林 秀司 経済産業省 産業技術環境局 情報電子標準化推進室 事務局 木村 高久 (財)日本規格協会情報技術標準化研究センター主任研究員 事務局 宮古 牧子 (財)日本規格協会情報技術標準化研究センター 1.5 委員会実施状況 本委員会ならびに各 WG に加えて、WG 間の情報共有を目的として、委員長、幹事、WG 主査による本 委員会アドホックを開催した。 アイデンティティ管理技術標準化調査研究委員会（本委員会） 回数 開催日時 開催場所 第１回 ２００７年５月２３日(水) 規格協会本部ビル４階２０２会議室 第２回 ２００７年９月 2７日(木) 規格協会本部ビル４階２０３会議室 第３回 ２００８年２月 規格協会本部ビル４階２０３会議室 ５日(火) - 4 - アイデンティティ管理技術標準化調査研究委員会（本委員会アドホック） 第１回 ２００７年 ６月１２日(火) 赤坂エイトワンビル応接室５ 第２回 ２００７年 ７月１０日(火) 赤坂エイトワンビル８０２会議室 第３回 ２００７年 ８月 ３日(金) 赤坂エイトワンビル応接室５ 第４回 ２００７年１２月１４日(金) 赤坂エイトワンビル８０１会議室 アイデンティティ管理技術標準化調査研究委員会（WG１） 第１回 ２００７年 ７月１０日(火) 赤坂エイトワンビル８０２会議室 第２回 ２００７年 ８月 ８日(水) 赤坂エイトワンビル８０１会議室 第３回 ２００７年 ９月２７日(木) 規格協会本部ビル４階２０３会議室 第４回 ２００７年１０月１８日(木) 赤坂エイトワンビル８０１会議室 第５回 ２００７年１２月１３日(木) 赤坂エイトワンビル８０１会議室 第６回 ２００８年 １月２８日(月) 規格協会本部ビル４階小講堂 アイデンティティ管理技術標準化調査研究委員会（WG２） 第１回 ２００７年 ７月１０日(火) 赤坂エイトワンビル８０２会議室 第２回 ２００７年 ９月 ７日(金) 規格協会本部ビル４階２０２会議室 第３回 ２００７年 ９月２７日(木) 規格協会本部ビル４階２０３会議室 第４回 ２００７年１０月１９日(金) 赤坂エイトワンビル８０１会議室 第５回 ２００７年１１月 ９日(金) 赤坂エイトワンビル８０１会議室 第６回 ２００７年１２月 ７日(金) 規格協会本部ビル４階２０２会議室 第７回 ２００７年１２月２１日(金) 規格協会本部ビル４階２０１会議室 第８回 ２００８年 １月１８日(金) 規格協会本部ビル４階２０２会議室 第９回 ２００８年 ２月２２日(金) 赤坂エイトワンビル８０１会議室 1.6 成果一覧 IdM 技術の標準化動向を調査し、標準化の進め方を検討した。技術的な側面からの調査と、IdM 技 術を利用する側面からの調査とを行った。技術的な側面からは、代表的な IdM 技術を三つ選定し、概 要を調査した。IdM 技術を利用する側面からは、人の ID と物の ID とを含む、ID 利用場面を検討し、 IdM に対する要件を検討した。以上をとりまとめた報告書を作成した。 - 5 - 2. 委員会の活動報告 2.1 背景と目的 ウェッブ資源の利用技術は情報社会の基盤技術として社会の各所で利用されている。既に企業の情 報共有に利用されているが、最近では行政の電子化と関連して、年金・医療・介護保険制度などの公 共サービス部門でも適用が検討されている。 ウェッブ資源の利用技術が普及するに伴い、ユーザアカウント管理に関連して次の課題が意識され るようになった。利用者にとって、利用するすべてのウェッブサイトに関するアカウント情報を管理 し、使い分けるのは、利用するサイトが増加するに伴い煩雑となる。ウェッブサイト管理者にとって、 利用者の新規申請、資格の更新（社内システムの場合、昇進、異動などに伴う情報アクセス資格更新） 、 退会などに伴って発生するアカウント情報の管理が煩雑となる。この課題に対応するための技術とし て、アイデンティティ管理(以下 IdM)技術が注目されている。 IdM 技術は、ウェッブ資源提供者（情報提供者、以下 IP）に次のサービスを提供する。利用者に関 連する情報を管理し、利用者がウェッブ資源にアクセスするごとに、IP からの要求に答えて IP に当 該利用者に関する情報を提供する。この、利用者に関する情報の集まりを、アイデンティティ (identity、以下 ID)と呼ぶ。 IdM は次の二種類のサービスを提供する。第一のサービスは、IP からの要請に対応して、利用者の ID を返信するものである。この返信を利用して IP は、利用者からのアカウント情報提示を省いて、 ウェッブ資源へのアクセスを許可することができる。これにより、利用者のアカウント管理が煩雑化 する課題を解決する。第二のサービスは、IdM に登録された ID と実際の ID との間で一貫性を制御す る。これにより、サービス提供者のアカウント管理が煩雑化する課題を解決する。 IdM 技術は、PassportTM（マイクロソフト社の規格）と、これに続いてリバティアライアンス（サ ンマイクロシステムズ社他からなるコンソーシアム）により提唱された規格（以下リバティ規格）と に始まる。現在有力な規格としては、このリバティアライアンスの規格の他に、マイクロソフト社の Card SpaceTM、オープンアイディコンソーシアムの規格（以下 openID 規格）などがある。国際規格 策定の動きは、ISO IEC JTC1/SC27、ITU-T ほかに見られる。 Web 資源の効率的な利用には、ID の連携が必要と言われている。これを実現するには、連携する ID を管理する IdM システムが相互に連携する仕組みが必要になる。この目的を達成するためには IdM シ ステムに関する標準化を行うことが必要になる。本委員会では、ID 連携を達成するために IdM システ ムに要請される標準化の方向を明らかにすることを目的として、IdM 技術の標準化動向を調査する。 2.2 活動内容 IｄM 技術の標準化動向を調査し、代表的な IdM 技術を抽出する活動を行い、また ID を利用する場面 からの ID に対する要件を抽出する活動を行う。それぞれのために作業部会を設置し、関係者との議 論を行って、調査資料の作成を試みた。 - 6 - 2.3 成果 ・ IdM 技術に関する標準化項目を抽出するための作業部会を設置した。 ・ ID 技術の利用場面を分析し、ID に対する要件を抽出するための作業部会を設置した。 各作業部会ＷＧでの検討、またＷＧ間の連携を取りつつ検討を進めた結果、IdM 技術として注目さ れている「ID 連携」について、利用場面の分析からも注目されるべき対象であることが抽出されてき た。そこでさらに各作業部会において、 「ID 連携」について絞り込んだ議論を行い、技術標準化項目 としての注目対象技術として Liberty Aliance や OpenID が存在すること、またその利用場面におけ るモデル化の可能性を見出すことができた。 2.4 今後の課題 ID 連携などを具体化するためには IdM システムの機能が明確化していることが前提になる。そのた めに様々な利用場面からの機能のモデル化の推進と、また現状技術との適用範囲の精査が大きな課題 となる。これらの課題を整理することで、標準化に向けた方向性が明確になると考えられる。 - 7 - 3. WG１の活動報告 3.1 背景と目的 WG1 の目的は、ID とその管理に関連するシーズ技術を調査することにある。それらは大別すると、 １）ID と利用者（およびその属性情報）を結びつける認証技術、２）ID からそれに関連する情報を 発見するディスカバリ技術、３）利用者とサービスを結びつける ID 連携技術などがある。中でも ID 連携技術は、サービス提供者から利用者認証や属性管理の手間を取り除くことができ、また、利用者 もサービス提供者毎に利用者登録や登録情報の更新などを行わなくてもよくなることからその必要 性は次第に高まりつつある。そこで、WG1 では ID 連携技術（および各仕様間の互換性を確保するため のディスカバリ技術）に焦点を当て、その技術動向を調査すると共に課題の抽出を行うことを目的と した。 3.2 活動内容 ID 連携に関連する仕様やプロジェクトの調査を行った結果、主要な方式はいくつかの局に集約され つつあることが明らかとなった。具体的な局としては、仕組みが単純で近年急速に普及し始めている OpenID、リバティアライアンスで定める方式、マイクロソフト社が進める Card Space などがある。 さらに、OpenID、リバティアライアンスで定める方式、Card Space 間の互換性を確保するために、 Concordia というプロジェクトが立ち上っていたり、OpenID や LID などとの間の互換性を確保するた めに Yadis という仕様が策定されていたり、各仕様間の互換性を確保するための活動も盛んになりつ つある。そこで本節では、3.2.1 小節から 3.2.5 小節において、それらの概要についてまとめると共 に、3.2.6 節と 3.2.7 節において、より高度なサービスを提供する際に重要となる ID 管理のライフサ イクルマネージメントと認証コンテキストについてまとめる。 3.2.1 OpenID OpenID とは、URL を使ってインターネット上の WEB サイトへの認証をシングルサインオン的に行う 仕組みである。 現在、インターネット上には数多くの WEB サイトがあるが、ユーザ登録がサービス利用時の障壁にな っていることが多い。ユーザ登録においては ID とパスワードを登録するが、これを数多くの WEB サ イトで登録することは以下の点で問題がある。 z 多くの異なる ID とパスワードの管理が困難であること z サービス提供のために必ずしも必要とは思われない住所、氏名などの個人情報の登録を要求され ることもあるため個人情報保護の観点から懸念があること z それらの個人情報の入力の手間のためにサービスを利用することを躊躇する可能性があること 上記課題はいわゆるシングルサインオン技術が解決する。 代表的な技術として SAML が挙げられるが、 SAML では認証サーバを利用できるサービスを事前に決めておく必要があり、新しいサイトが次々と出 現しているインターネットの WEB サイトには不向きである。 これに対して OpenID は認証サーバと認証を受ける WEB サイトの間で事前の信頼関係の構築が不要で あり、両サーバの関係はアドホックに構築されるため、インターネット上のサービスでの利用に適し ている。従来より Microsoft は Passport、現在は Windows Live ID と呼ばれるインターネット向けシ ングサインオンサービスを展開しているが、これは Microsoft がアカウント情報を集中管理するモデ ルである。一方 OpenID は認証サーバを誰でも運営できること、エンドユーザは自分で認証サーバを 選択して ID（これも OpenID と呼ばれる）を発行してもらうことができる。このため OpenID は分散型 の認証システムともいえる。 図を用いて OpenID の利用方法を説明する。 ① End User は任意の OpenID Provider(OpenID 認証サーバ）に依頼して OpenID を取得する。OpenID Provider が provider_name.ne.jp の場合、OpenID は例えば user_name.provider_name.ne.jp とい う URL の形式をとる。ID が URL のためユニークな ID を割り当てることができる。 ② End User は Relying Party(OpenID を受け入れる WEB サイト)へログインするために OpenID を入 力する。 ③ Relying Party は OpenID を認証してくれる OpenID Provider を探し、 End User をリダイレクトし、 OpenID Provider へ認証を要求する。 ④ OpenID Provider は End User に対して「どこどこのサイトでログイン要求されているが認証する か」と問い、パスワードを入力させる。 ⑤ ブラウザは再び Relying Party にリダイレクトされ、Relying Party は認証結果を確認する。 ここで、Relying Party のメリットはユーザのパスワードを管理しなくて良い点である。End User の メリットは Web サイトごとに ID とパスワードを決めたり覚えたりする必要がないことである。さら に End User 個人の Web サイトを OpenID とする delegate 機能を使うことにより、OpenID Provider が運営を中止した場合も、違う OpenID Provider を使用することにより ID を変更する必要がない。 - 9 - これが分散型認証システムのメリットである。 OpenID の限界は OpenID Provider は誰でも作れるため、すべての OpenID Provider が信頼できるとい うわけではないことである。つまりオレオレ OpenID Provider が存在しうる。Relying Party がどの OpenID Provider を信頼すればよいかについては OpenID のみでは解決しないため、例えばホワイトリ ストなどの別の仕組みが必要である。 また信頼のおける OpenID Provider のユーザであってもユーザ自身が悪意のあるユーザである可能性 がある。これについてもユーザの信頼性を評価する仕組みが別途必要ではないかという議論がある。 したがって現状では OpenID はブログなどへのコメントを書くなど、セキュリティをそれほど気にし ない場面での使用が想定されており、E コマースなどの信用を必要とするアプリケーションには単体 では使えるものではない。 End User は標準的な HTTP をサポートするブラウザ以外は必要ない。 OpenID の仕様は公開されており、2007 年 6 月に設立された OpenID Foundation(OIDF)が OpenID の技 術とコミュニティのプロモーションを行っている。2007 年 12 月に発表された OpenID 2.0 が最新であ る。2008 年 2 月現在以下の仕様書が最終版として公開されている。 z OpenID Authentication 2.0 基本仕様 z OpenID Attribute Exchange 1.0 属性交換用の拡張 z OpenID Simple Registration Extension 1.0 プロファイル取得用の拡張 また各種言語で OpenID Provider 用と Relying Party 用のライブラリが公開されている。 OpenID 2.0 では OpenID として URL のほかに XRI i-name をサポートするようになった。また OpenID が URL の場合は Relying Party が OpenID provider を探すための Discovery において Yadis プロトコ ルをサポートするようになった。 OpenID Foundation の Community Board Member には Vidoop、Six Apart、Sxip、Wikia、NetMesh など の OpenID コミュニティの代表者が名を連ねている。 2008 年 2 月には、 Google、IBM、Microsoft、 VeriSign、 Yahoo!が Corporate Board Member となった。このことにより、今後 OpenID が ID 管理分野でますま す注目されることが予想されている。 OpenID Provider は米国では、OpenID(http://openid.net)やなどがあり、日本語サイトでは、 OpenID.ne.jp や livedoor Auth がある。また Relying Party は米国を中心に 2008 年 1 月現在で 1 万 サイトあるという報告がある。ブログや SNS といった Web2.0 サービスでの採用が多い。 2007 年 2 月に Microsoft が OpenID のサポートを発表した。2008 年 1 月には Yahoo が OpenID に対応 すると発表（OpenID Provider として）した。 - 10 - ID 管理のライフサイクルマネージメントについては、OpenID Provider では ID の登録のみをカバー しており、変更、廃棄などはカバーしていない。Relying Party では特に規定されていない。 認証コンテキストの扱いについては、本人確認、技術的保護、運用上の保護、認証手段、適用する契 約などのコンテキストは存在しない。 3.2.2 リバティアライアンスにおけるアイデンティティ管理技術 リバティアライアンスにおけるアイデンティティ管理技術は附属資料 A に詳細が示されている。ここ では概要を示す。 リバティアライアンスはアイデンティティ管理及びサービスのための公開標準仕様の確立を目的と する団体であり、2001 年 9 月に設立された。 リバティアライアンスが提供する仕様は、SAML(Security Assertion Markup Language)、SOAP(Simple Object Access Protocol)、WSS(Web Service Security)、XML などの既存の標準仕様に準拠して構成 される。リバティ仕様の構成概要を次に示す。 リバティ・アイデンティティ連携フレームワーク リバティ・アイデンティティサービス・インター (ID-FF/SAML) フェース仕様(ID-SIS) アイデンティティ連携及び管理に関する。 アイデンティティサービスに関する。 特徴 例 ・ アイデンティティ／アカウントリンケージ ・ パーソナルプロファイルサービス ・ シングルサインオン ・ アラートサービス ・ セッション管理等 ・ カレンダーサービス ・ ウォレットサービス ・ コンタクトサービス ・ 位置情報サービス ・ プレゼンスサービス等 リバティ・アイデンティティ Web サービス・フレ ームワーク(ID-WSF) 次を作製・構築するためのフレームワーク ・ 相互接続可能なアイデンティティサービス ・ 許可ベースの属性共有 ・ アイデンティティサービス記述 ・ ディスカバリ及び関係するセキュリティプロ ファイル 既存の標準仕様準拠部分 アイデンティティ管理システムは、アイデンティティが作製されて削除されるまでの間、アイデンテ ィティを登録した利用者にサービスを提供する。アイデンティティが作製されて削除されるまでの期 - 11 - 間には、アイデンティティの作製・変更・認証・連携・シングルサインオン・アクセスの履歴管理・ アクセス制御・属性共有・削除などの事象が発生する。アイデンティティの作製から削除までの一連 の事象をアイデンティティのライフサイクルと言う。リバティアライアンス仕様は、アイデンティテ ィ連携あるいはシングルサインオンなど、アイデンティティのライフサイクルに沿って派生する個々 の事象に対応するための仕様に加えて、ライフサイクル全般にわたる包括的なサポート(アイデンテ ィティのプロビジョニングとよばれる)を意図した開発作業が進められている。 アイデンティティ管理技術には、リバティアライアンスの仕様が定めるもの以外、openID フォーラム が公開している技術、マイクロソフト社が開発を進めている Card Space TM を含む技術がある。アイ デンティティのライフサイクル全般に渡るサービスの提供は、他の規格ないし技術と比べて、リバテ ィアライアンス仕様の特徴的な要素である。 リバティアライアンスの仕様に関する最新の情報は、次のホームページから得ることができる。 リバティアライアンス JapanSIG http://wiki.projectliberty.org/index.php/JapanSIG 3.2.3 Concordia（コンコーディア）プロジェクト Concordia は、ローマ神話に出てくる合意、理解、夫婦間の調和の女神で、各種 ID 管理技術の相互 運用確立を目指して組織されたプロジェクト。ブロードバンドインターネットが普及し社会インフラ 化するにつれ、あらゆるリアルな経済・社会サービスがネットワークを通して利用できるようになろ うとしている。利用者は、これらの Web サービスを、自分の ID に基づき、安全・安心に、かつ統一 的に使えることを望んでいるが、現状は、各種規格が並存し、希望は実現されていない。利用者の利 益のために、この問題を解決するには、ベンダーが協力して当たるしかない、という認識のもとに、 Liberty Alliance が中心になって設立した。組織はオープンで、Liberty Alliance とは独立してい る。現在、メンバーには、代表的な ID 管理技術である Liberty Alliance、OpenID、CardSpace に関 係するベンダーとその利用者が参加している。 【主要メンバー】 y 利用者：GM、Boeing、AOL、米一般調達局 (GSA)、ﾌﾞﾘﾃｨｯｼｭ ｺﾛﾝﾋﾞｱ州政府(加) y ベンダー：Intel、Microsoft、VeriSign、Sun Microsystems プライバシを考慮したアイデンティティ管理体系の開発を目標として 2007.6 より公の場¹⁾で活動を 開始、現在、利用シーンに基づく相互運用技術を検討している。²⁾ 注 1)Burton Group 主催 IT 会議『Catalyst』に先立つ事前イベント 2) RSA Coference 2008 でデモを計画 - 12 - 【主要 ID 管理技術の比較】 図 3.2.3-1 異なる技術仕様の比較 出典：2007 年 6 月 14 日「リバティ・アライアンス」記者説明会資料 ～最新の技術動向や採用事例のご紹介と日本 SIG の公開化による新たな国内での運営方針～ URL= http://wiki.projectliberty.org/images/b/b5/JapanSIG_070614_Briefing.pdf - 13 - 【主な利用シーン】 ① OpenID でシングルサインオンし、Liberty ID-WSF(Identity Web Service Framework) で個人属性情報を交換する(図 3.2.3-2 参照) ② CardSpace で認証し、SAML または WS-Federation でシングルサインオンする ③ SAML と WS-Federation を連携させて、シングルサインオンする Concordia の利用シナリオ 異なるアイデンティティ管理仕様のプロトコル間の相互乗り入れ接続 Liberty ID-WSFと OpenIDの接続の一例 OpenIDベースでSSO（シングルサインオン）した後、 Liberty ID-WSFベースで 個人属性情報を交換。 アイデンティティ・プロバイ ダ（ OpenID対応） （認証局） (1) ユーザ認証 (5) ユーザの属性情報を要求・返信 サービス・ プロバイダ （Liber ty ID-WSF対応） (3) OpenID の認証情報を送付 ユー ザ (2) サー ビスにアクセス要求 (4) 認証情報をもとに SSO ＊Liberty ID-WSF (Identity Web Service Framework): Libertyの個人情報交換のための Webサービス仕様群 OpenID: URIベ ースのシンプルな認証と属性交換システム NTT Copyr ights 2007. Al l rights r eserved. 図 3.2.3-2 3.2.4 OpenID と Liberty ID-WSF 接続の 1 例 Yaddis プロジェクト 概要 Yadis は、認証、説明責任、プライバシが制御されたデータ交換等に対する識別子を使ったあらゆ るサービスの第１段階を提供するものである。 Yadis は、Identity の利用者やメンバーサイトのような複数の関係者間に信頼関係を可能とするサー ビスディスカバリー・システムである。 このようなサービスの例は次の通りである。 ・Web サイト間のシングルサインオン ・プロファイル交換及びフォームの記入 ・Blog のアンチ・スパム Yadis は、OpenID の一種で、ID 連携の分類にされる。 また、Web2.0 のための本人特定及び説明が 可能となる基盤技術である。 ID となる識別子として用いられるのは、通常の WEB サイトに使われる URL か、 （人又はサービスを示 - 14 - す）Yadis 文書かである。 Yadis の仕様では、以下の内容を提供する。 ・ある種のサービスね使うことのできる人とその他のエンティティのための一般目的の識別子 ・識別子及び文書要素のインタープリテーションを使って利用可能なサービスを特定するリソース記 述文書のシンタックス ・その識別子を与えるリソース記述文書を得るためのプロトコル 経緯 Yadis は LID プロジェクトと OpenID プロジェクトの指導者により開始された。 2005 年 10 月の Internet Identity Workshop (URL= https://www.socialtext.net/iiw2005/index.cgi )の Yadis セッション以降、 i-names (URL= http://en.wikipedia.org/wiki/iname )で活動している XRI (URL= http://en.wikipedia.org/wiki/XRI )関係者がその成果に合流した。Yadis は URL ベースのどのよう なアイデンティティシステムにも適用可能である。 この例には、Sxip（URL= http://www.sxip.com/ ） 、 mlDm (URL= http://www.downes.ca/midm.htm )がある。また、Open ID、LID、XRI には何もせず繋が ることができる。 仕様について。 Yadis の仕様書は、ver1.0 が、以下の URL に掲載されている。 http://yadis.org/wiki/Main_Page Yadis の仕様では、以下の内容を提供している。 ・ある種のサービスを使うことのできる人とその他のエンティティのための一般目的の識別子 ・識別子及び文書要素の解釈を使って利用可能なサービスを特定するリソース記述文書のシンタック ス ・その識別子を与えるリソース記述文書を得るためのプロトコル 同じ URI を用いた識別手段である以上、その URI が OpenID の識別 URI なのか LID や iName の識別 URI なのかを意識すること なく相互運用できるよ うに、URI からその対応する識別プロトコル を Auto-Discovery する手順を標準化することになる。 そのような Auto-Discovery 手段の仕様が YADIS という。 実際に ID として使う識別 URL と、その URL が対応する識別プロトコルを定義する YADIS 文書の 2 つを用意して、 次の操作が行われる。 識別 URL: 識 別 ク ラ イ ア ン ト 側 か ら ア ク セ ス を 受 け る と 、 値 と し て YADIS 文 書 の URL を 設 定 し た 、 X-YADIS-Location という拡張ヘッダを HTTP ヘッダに加え、レスポンスを返す。 YADIS 文書の URL の指定方法は、HTTP ヘッダによる指定の他、HTML ヘッダでの、http-equiv を X-YADIS-Location に設定した<meta>タグでもよい。 - 15 - 識別クライアント側は、X-YADIS-Location で YADIS 文書の URL を受け取ると、その URL に制御を移し YADIS 文書を取得する。 YADIS 文書: YADIS 文書は、Content-Type として application/xrds+xml を返す。 YADIS 文書の書式は以下のようになる。 <?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://openid.net/signon/1.0</Type> <URI>http://www.myopenid.com/server</URI> <openid:Delegate>http://xxxx.myopenid.com/</openid:Delegate> </Service> </XRD> </xrds:XRDS> <Service>要素で対応する識別プロトコルを定義する。 属性 priority は Service を複数定義した際 の優先度。小さいものほど優先される。 子要素の<Type>は必須。この要素で、対応する識別プロトコルやそのバージョンを一意に識別する。 現状では、OpenID なら http://openid.net/signon/1.0、TypeKey なら http://www.sixapart.com/typekey/sso/1.0、LID の Ver.2.0 なら http://lid.netmesh.org/sso/2.0 という形になる。 子要素の<URI>は、識別サーバのエンドポイントの URI を指定する。省略すれば識別 URL の値が設定 される。よって、識別 URL と識別サーバのエンドポイントが等しい、 （Delegation を行わない場合の） LID や、非分散型なので何を設定してもエンドポイントは一意な TypeKey 等では設定不要であり、 OpenID では必須である。 以上の YADIS の持つ要素以外に、識別プロトコルによっては追加の要素が必要になる場合がある。そ の場合はプロトコル毎の別名前空間を準備し、それにより修飾された要素で必要事項を設定する。こ の名前空間は、OpenID の場合には http://openid.net/xmlns/1.0、TypeKey の場合には http://www.sixapart.com/typekey/xmlns/1.0 といった形になると思われる。 このような拡張要素の例としては、OpenID の場合、Delegation 仕様を用いているために識別 URL と エンドポイントの理解できる元識別 URL が異なる場合、元識別 URL の方を OpenID 名前空間で修飾さ れた Delegate 要素で設定してやる必要がある。 - 16 - 同様に、TypeKey の場合、ユーザ名を指定する、TypeKey 名前空間で修飾された MemberName 要素が必 要になる。 このような仕様の利点は“異なる識別プロトコルの運用共通化”が実現されることにある。 これまで、色々なサービスがあると、各サービスの物理的境界で分断されて、サービス間を直接移る ことがむずかしかったのが、サービスのアカウントが集約され、サービス間の橋渡しをするような機 能の実装が可能となり、インターネット全体がある識別 URL で識別される個人に対し一貫したサービ スを一つの窓口から提供できる可能性がでてくることになる。SNS のオープン化も可能性がある。 3.2.5 Windows Card Space におけるアイデンティティ管理技術 Windows Card Space は Microsoft 社の個人向け Identity 関連技術である。製品としては、NET Framework 3.0 以降の一部機能として提供されている。独自技術中心ではあるが、インターネット上 に存在する様々な形式、方式のデジタル ID の処理、管理技術との相互運用性、連携性の向上も狙っ ている。旧技術コードネームは InfoCard。 Microsoft 社では ID の付与、提供、利用を 3 種にモデル化している。 User :デジタル ID が関連付けられたエンティティ。人、組織、アプリケーション、コンピュータな どがデジタル ID の付与 対象となる。Card space は人の認証を主対象にしている。 Identity Provider : ユーザーにデジタル ID を提供するもの。他のモデルの Idp と考えられる。 Relying Parties（証明書利用者 ）: 証明書利用者とは、任意の方法でデジタル ID を利用するアプ リケーション。他のモデルの SP(Service Provider)の個人認証、アクセス制御部分に対応すると考 えられる。証明書利用者は、 ID (この ID のセキュリティ トークンを構成する要求に含まれる情報) を使用してユーザーを認証し、そのユーザーに特定の情報へのアクセスを許可する。 図 3.2.5-1 ID 管理、利用の相互関係 (Microsoft 社 Card Space 紹介資料より) - 17 - Microsoft 社の個人向け ID 管理システムには他に Windows Live ID がある。が、Windows Live ID が アカウント情報を Microsoft 社が集中管理するモデル(独立モデル)であるのに対し、Card Space は、 個人ユーザーが Id 管理に関与できるところに特徴がある。3 種のアイデンティティ管理モデルのなか では OpenID、SAML とともにユーザセントリックモデル(附属資料 B 参照)に属する。 Windows Card SpaceTM は Microsoft 社の次世代のアイデンティティ管理技術のビジョンである Identity Metasystem をベースとしている。Microsoft 社は以前は pasport とう独自技術中心に Idm を展開していたが、1990 年代後半以降、企業内ネットワーク、インターネットでは既に多くのオープ ン、独自の技術が採用されている。 Identity Metasystem は世の中に存在する各種の Identity サービスの抽象化を行い、独自の技術 の提供を行うと同時に、任意のデジタル ID システムのサポート、存在するオープンな各種デジタル ID 形式(X.509 証明書、Kerberos ティケット、SAML トークンなど)、今後の新デジタル ID 技術にも一 貫した方法で処理することをねらっている。 この他 Windows Card SpaceTM の特徴には以下がある。 ① 標準プロトコルを利用 他システムとの相互運用を行うプロトコルとして WS-*を提案している。オープンな SOAP、XML をベースにした WS-Trust（セキュリティートークン取得） 、WS-Security(証明書利用者への配 信)WS-ScurityPolicy(証明書利用者のセキュリテリー記述)などがある。 Microsoft 社以外の製品を使用している SP(Service Provider) 、Idp(Id provider)は http を 含む標準準拠のソフトを使えば、Card Space との連携が可能となっている。 ② PC 画面上では利用する IC カードを選択するイメージの簡易な操作性 画面上にはリモートの各種 Idp が発行した複数のセキュリティトークン、Card Space が独自に ローカルに発行したセキュリティトークンがカードイメージでビジュアルに表示される。ユー ザはデジタル ID の相違によらない一貫した直感的操作により、特定のカードを選択できる。 これにより、ユーザは自分に付与されたデジタル ID について使い方を適切に判断できると同時 に、一貫性あるデジタル ID 管理が可能になる。 - 18 - 図 3.2.5-2 複数 カード選択と認証のシナリオ (Microsoft 社 Card Space 紹介資料より) ③ パスワードを使わず、セキュリティトークン注１を使用。 セキュリティ上、安全性が十分でない場合があるパスワードに代わりに、信頼できる Idp が発行する 安全なセキュリティトークンを個人識別の中心技術として採用している。フィッシングサイトでのパ スワード、個人情報の漏洩防護などに有効になる。 Card space の自己発行のセキュリティトークンの場合は、ローカルな Idp によりユーザがカード登録 した情報を含めた SAML トークンが生成され、公開キー、暗号キーにより電子署名処理を行ったうえ で SP/証明利用者に送付される。オープンでセキュアーな標準技術を組み合わせることによりセキュ リティの向上を図っているようだ。 注 1:セキュリティ トークンとは、デジタル ID の情報を表す一連のバイト列で 1 つ以上の "要求" から構成されます。それぞれの要求には、この ID について伝達される情報の一部が格納されます。 単純なセキュリティ トークンであればユーザー名を含んだ要求のみが格納され、複雑なセキュリテ ィ トークンになるとユーザーの姓、名、自宅住所などを含んだ複数の要求が格納される場合があり ます。一部のデジタル ID のセキュリティ トークンには、クレジット カード番号などの秘密情報を 含んだ要求が格納される場合もあります。((Microsoft 社 Card Space 紹介資料より) ④ ID 管理のライフサイクルマネージメント Microsoft 社は Identity Lifecycle Manager という製品で Card Space 以外の ID 管理製品含めた - 19 - ID 管理のライフサイクルマネージメント機能を提供している。 Card Space と特に関連が深いのはセキュリティトークンの自己発行にかかわる電子証明書スマート カード機能と思われるが、Identity Lifecycle Manager は企業向け ID 統合製品に位置づけられてい るため詳細は不明。(附属資料 B 参照) ・ ID 同期 システム全体でのユーザの情報の同期、整合性の確保機能 ・ ユーザプロビジョニング ユーザの作成、削除作業の自動化、パスワードの同期 ・ 電子証明書スマートカード 証明書ベースの認証の簡易化、証明書の発行、廃止の自動化、スマートカードの管理の 簡単化 3.2.6 ID 管理のライフサイクルマネージメント 情報システムにおけるアイデンティティを管理するにあたっては、アイデンティティのライフサイ クルを考慮する必要がある。これは、ある情報システムとその利用者の関係（状況や立場）が常に変 わる可能性があるからである。 例えば、ある利用者がある組織に新たに所属し、情報システムの利用権を得る際には、この利用者 のアイデンティティをシステムに登録する必要がある。また、システムにおける利用権は状況の変化 （異動など）により変化する。また、この利用者が組織を離れる際には、アイデンティティをシステ ムから削除する必要がある。 情報システムにおいて、アイデンティティのライフサイクルを扱うにあたっては、一般的には以下 のようなライフサイクルマネジメントモデルが想定される。 (1)アイデンティティの確立 システム利用者（実体）と、システム上の ID を結びつけて登録する。 (2)アイデンティティの利用 (2-1)システム利用者に適用可能な属性をアイデンティティに割り当てる。 (2-2)システム利用者の属性が変更された際に、アイデンティティに割り当てる属性を変更する。 (3)アイデンティティの破棄 システム上から ID を削除するなどの方法により、システム利用者とシステム上の ID の結びつきを断 ち切る。 上記は、ある 1 つのシステムに閉じた形でのライフサイクルマネジメントを前提としている。しか し、アイデンティティ管理においては、複数のシステムの連携を前提とすることが一般的であり、連 携時のライフサイクルを考慮する必要がある。 連携時には、一般的に以下のようなライフサイクル管理が考えられる。 - 20 - (1)アカウント連携 システム利用者の同意を得て、複数のシステムの間のアイデンティティを結びつける。 (2)連携の実行 連携したシステム間で、結びつけられたアイデンティティ間のシングルサインオンなどを実行する。 この実行は連携が解除されるまで行われる。 (3)連携の解除 システム利用者の同意を得て、複数のアイデンティティ間の結びつきを解除する。連携を行わない 時以外にも、あるシステムでアイデンティティが破棄された際に実行する。 以上のアイデンティティのライフサイクル管理を行うために、プロビジョニングシステムを利用シ ステムが存在する。プロビジョニングシステムは、アイデンティティ管理を行う製品に多く搭載され ているシステムで、ユーザの立場が変化する度に、アカウントとアクセス権限を適切に付与、剥奪す るシステムである。 Liberty Alliance においては、アイデンティティライフサイクルのサポートが規定されている。こ の中では、アイデンティティの確立としての「作成」 、アイデンティティの破棄としての「削除」 、ア イデンティティの利用としての「変更」、「認証」 、 「連携」、「SSO」、「履歴」 、「アクセス制御」、「属性 共有」などが定義されている。 具体的な製品では、以下のような実装例がある。 (1) Sun Java System Identity Manager Sun Java System Identity Manager は、アイデンティティのライフサイクル管理機能とアイデンテ ィティ監査の機能から構成されている。プロビジョニングシステムを備え、ライフサイクル機能とし て「新規ユーザ」 、 「変更処理およびユーザサポート」 、 「担当変更」などの機能を持つ。 (2) Oracle Identity Manager Oracle Identity Manager は、アプリケーションやディレクトリに対して、アイデンティティや属 性の追加、更新、削除機能を持つ。また、これらの機能を自動化するプロビジョニングシステムおよ び管理ソリューションを備えている。 アイデンティティのライフサイクル管理の現状の課題は、すでに記述したような連携モデルが定義 されているものの、個別のアイデンティティの状態を、分散されたライフサイクル管理システムにお いて矛盾無く扱うための統一的な仕組みの検討が必要な点である。個別のアイデンティティのライフ サイクル情報を交換できる仕組みなどの検討、標準化が必要となる。また、先行している Liberty Alliance と、OpenID、CardSpace とのライフサイクルに関する連携の仕組みが未整備であり、今後の 技術的検討や標準化の必要性があると考えられる。 - 21 - 3.2.7 認証コンテキスト 認証コンテキストは、ID プロバイダ等からサービスプロバイダに伝えられる、認証プロセスや結果 の背景情報を指す。サービスプロバイダは、認証結果の信頼性の判断材料にこれを用いることができ る。 認証コンテキストに含まれる情報は、おおむね下記の様なものとされる。 １）本人確認状況 ユーザ情報登録時にどのように本人確認をしたかに関する記述。例えば、対面で免許証を確認した、 など。 ２）技術的保護状況 ユーザ認証に用いられる秘密情報（パスワード、秘密鍵等）がどのように保護されていたかに関す る記述。例えば、IC カードのセキュアな記憶領域に格納されていた、など。 ３）運用上の保護状況 関係する組織でのセキュリティ運用に関する記述。例えば、セキュリティ監査状況など。 ４）認証手段の状況 認証プロセスで利用される認証手段に関する記述。例えば、パスワード、ＰＫＩなど。 ５）適用される契約等の状況 認証に適用される契約に関する記述。例えば、保証責任の範囲など。 ６）装置（ソフトウェアを含む）の信頼性状況 装置の品質や精度、データ処理の安全性に関する記述。 ７）１）から６）の情報の正当性状況 これらの情報を誰が正当と認めたかに関する記述。 現在、ISO/IEC JTC1/SC27 WG5 において、日本が提案した生体認証の認証コンテキストに関する国 際標準化 1)が進められている。ここでは、上記の認証コンテキスト一般論を考慮しつつ、標準化の内 容を生体認証に限らない形に一般化して、要件を具体的に記述する。 基本的な課題は、ネットワーク越しに行われた認証の結果をどう検証するか、にある。検証者とし てのサービスプロバイダは、認証結果が OK であると報告を受けたときに、その裏に潜む様々なリス クに直面することとなる。例えば、ユーザ登録時に設定された秘密情報が不正に変更されていないか、 品質の悪い装置が誤った結果を出していないか、入力された秘密情報が成りすましされたものではな いか、等である。このため、認証プロセスや結果の信頼性を判断する材料を検証者に提供できること が必要となる。 ユーザがサービスを利用するときの認証プロセスを考えると、いくつかのサブプロセスに分割でき ることがわかる。それらは、下記の通りである。 １）ユーザが ID と秘密情報を入力する。 ２）入力された情報を処理して認証される情報に変換する。 ３）変換された情報を、あらかじめ登録され何らかの記憶装置に格納されている認証リファレンス情 報（登録済み ID とパスワード、または、その暗号学的変換結果など）と照合する。 - 22 - ４）照合結果に基づいて認証がされたかを決定する。 ５）認証結果がサービス要求とともにサービスプロバイダに伝えられる。 検証者としてのサービスプロバイダは、伝えられた認証結果が正当であるかを判断しなければなら ない。このためには、①各サブプロセスがセキュアに実行されたか、②各サブプロセスは十分な品質 や精度で実行されたといえるか、③正当な認証リファレンス情報が利用されているか、④各サブプロ セス間でデータが正しく受け渡されているか、⑤各データの信頼性を主張するエンティティは誰か、 などを知る必要がある。 現在の標準化案では、いくつかのポイントで、信頼できる第三者による評価・認証が考慮されてい る。例えば、認証リファレンス情報の評価・認証組織、装置（ソフトウェアを含む）の評価・認証組 織などである。 また、認証コンテキストは元々上記２つの組織からの証明書を含めて ID プロバイダがその原形を 生成するが、装置が処理を進める過程で追記されることとなる。追記される内容は、装置が行った処 理内容や結果の有効性・正当性を確認できる情報、および、装置が実行したサブプロセスに関する情 報である。つまり、ID プロバイダの生成したコンテキストと装置が新たに生成したコンテキストが検 証者に送られ、検証者はこの内容を見て認証結果の信頼性を判断する。 標準化案で用いられる認証コンテキストは、主に４つのブロックからなる。第一ブロックは、装置 を識別し確認するためのデータであり、認証リファレンス情報の証明書、耐タンパ性などセキュリテ ィ機能、サブプロセスの品質や精度を表す。第二ブロックは、当該コンテキストが検証者であるサー ビスプロバイダの要求に対して生成されたものであることを検証するためのデータである。第三ブロ ックは、装置上で実行された各サブプロセスの処理結果の整合性を確認するためのデータであり、各 サブプロセスの入力/出力データの無矛盾性を確認する。第四ブロックはコンテキストの真正性を検 証するためのデータで、装置による電子署名である。 認証リファレンス情報を評価・認証する組織は、同情報の証明書を発行するが、この証明書は上記 第一ブロックに含まれる。この証明書には、認証リファレンス情報の正当性のほか、登録時に利用し た機器の精度、品質、セキュリティ機能レベルなどが記載されている。 装置を評価・認証する組織は、装置に関する証明書を発行するが、この証明書も上記第一ブロック に含まれる。この証明書には、装置の正当性のほか、精度、品質、セキュリティ機能レベルなどが記 載されている。 このように認証コンテキストを活用することで、ネットワーク環境における認証プロセスの相互運 用性が向上すると期待される。特定の装置やソフトウェアに依存せず、正しい認証結果かを判断でき るようになる。また、取引内容に応じて、要求する認証装置やセキュリティレベルを使い分けること も可能になると考えられる。装置等の証明書により、取引の可否が判断できる。さらには、サービス プロバイダ側の検証ポリシーの変更に対応可能な認証システムが構築できる。装置の証明書に含まれ る情報に基づき、セキュリティ問題が生じた装置を排除することも可能となる。 以上をまとめると、認証コンテキストの活用で、ユーザ側は認証結果の有効性を主張でき、サービ スプロバイダはその有効性を検証してサービス提供の可否を判断できる。ネットワーク越しの認証プ - 23 - ロセス全般にわたって、より信頼性の高い認証フレームワークが実現できるようになる。このように、 認証コンテキストに関する国際標準化は、ネットワークをベースとした国際的ビジネスの活性化に重 要であると考えられる。 3.3 成果 ・ID 連携技術（および互換性を確保するためのディスカバリ技術）の動向を調査した。各仕様間の互 換性の確保が進みつつある一方、手軽に導入できる OpenID がここ数年で急速に普及している。 ・主要な ID 連携方式の概要について調査しまとめた。利用者が認証された／拒絶された以外の情報 のやり取りや、属性情報等の管理についてはばらつきがある。 ・利用者が認証された／拒絶された以外の情報として認証コンテキストについて、利用者の属性情報 の管理手法として ID 管理のライフサイクルマネージメントについて調査しまとめた。 3.4 今後の課題 前節でも述べたとおり、OpenID はその手軽さによりここ数年で急速な普及を見せている。しかしな がら、仕組みの簡潔さにこだわる OpenID では、より高度な機能（例えば、認証コンテキストや属性 情報の受け渡しや管理、認証提供者の信頼度の評価方法など）は別のメカニズムで提供する必要があ る。よって、この部分の整備および標準化が今後の課題となりえる。また、ID 連携全般の問題点とし て、（特別な保護メカニズムが入っていない限り）認証提供者が利用者の利用しているサービスを知 りえるという問題もある。そのため、利用者のプライバシ保護も今後の課題となりえる。 - 24 - 4. WG2 の活動報告 4.1 背景と目的 本年度の各 WG の活動としては、ID とその管理に関して、 WG1 は、シーズ技術の観点から技術調査を行い、 WG2 は、ニーズの観点から必要とされる技術の調査を行う という作業分担で、活動を実施した。そこで、WG2 では、メンバである各委員が分担して、複数のド メインに対して、 具体的な利用シーンを想定することで ID の表現、ID のライフサイクルと管理、利用例 を検討し、そこで必要とされる共通のモデルを抽出することを目標に据え、活動を進めてきた。 対象ドメインの選定にあたっては、ID を付与する対象をヒトとモノに分け、ヒト単独、ヒトとヒト の結びつけ、モノ単独、モノとモノの結びつけ、ヒトとモノの結びつけ、といった観点から見通しを 立てた上で、具体的な選定は各担当委員に任せて、各自の造詣の深い分野を中心に以下のように選定 された。 表 4.1 担当表 節 対象ドメイン 担当者 所属名 名 4.2.1 電子カルテのアクセス制御 飯島 慶應義塾大学 4.2.2 製造業における物流の追跡 (同上) (同上) 4.2.3 公的個人認証の各国動向 豊内 内閣官房情報セキュリテ ィセンター/日立製作所 4.2.4 コンテンツ流通 五十嵐 富士通 4.2.5 空港・入出国管理における人流・物流の追跡 川村 NTT データ 4.2.6 RFID を実装した品物を携帯する人の、 杉山 NTT ソフトウェア 岩崎 デンソーIT ラボ 移動履歴情報の流通 4.2.7 プローブ情報を利用した車への情報推薦サービス 各担当委員による、個々のドメインに対する記述は、次節(4.2 節)に示す。記述項目は下記のよう に統一した。 [1] 概要 ・アプリケーションドメインの説明と、そこでの ID 管理の説明。 [2] 詳細記述 ・以下の表の形式で、各アプリケーションドメインにおける ID とその管理の各種属性を 整理する。 - 25 - 表 4.1.1 詳細記述表のテンプレート (1-a) [Target] ID が必要なもの（人、物、サービス、他）は何か？何に ID をつけたいか？ (1) [What/Target] (1-b) 粒度(ID を付ける単位の大きさ) [Granularity] (1-c) [Lifecycle] ID のライフサイクルと、その管理 (2-a) なぜ ID が必要か？ID をつけて何をしたいか（アプリケー [Application] ション）？特に、サービスの連携におけるその ID の役割 は何か？ (2-b) [Goal Type] (2) [Why/Goal] ID の目的はどのようなタイプか？ たとえば、Accountability/Traceability、 Matching、 (Access)Control 、 Discovery 、 Location (Optimal Relocation)、Resource Optimization、Load Balancing、 など (3) [How/Usage] (4) [Who] (2-c) [Scenario] 利用事例 (3-a) [Usage] ID をどのようにつかって、そのアプリケーションを実現 するか？ (3-b) [Feature] そのためにどのような性質をもった ID が必要か (4-a) 誰が ID を必要とするか？あるいは、ID に関与するか？ス [Stakeholder] テークホルダー (4-b) [Who⇔ その ID を持つことによって、どのステークホルダーがど Merit] (4-c) [Who⇔ Demerit/Risk] のようなメリットを享受するか？ その ID を持つことによって、どのステークホルダーがど のようなデメリットを蒙るか？ ※詳細記述表の各項目に対し補足説明がある場合には、簡潔に付記する [3] ID 管理に関して、解決すべき重要な問題点・課題 ・技術的な問題点、並びに運用上の問題点の両方を含む （記述上、両者の区別がつくことが望ましい） [4] [3]で指摘した問題点・課題に対する解決策の提言と理想像(To Be) ・技術的解決と運用的解決の両面を含んでいてよい ・完全なものでなくてもよく、方向性の提示で構わない [5] 今後の課題 ・これは数年以内の作業課題 ・この作業課題の遂行担当は、必ずしも当委員会ではなくともよい - 26 - 4.2 活動内容 前節に記載した担当表と記述項目に基づき、以下に、本年度 WG2 の活動として実施した技術調査内 容を記載する。 4.2.1 電子カルテのアクセス制御【担当委員：飯島（慶應義塾大学） 】 4.2.1.1 概要 医療情報の広範囲の流通は、救急医療、公衆衛生といった面からも、国内外を問わず、きわめて重 要な課題である。緊急時に既往症など特定の個人の様々な医療情報が速やかに入手できるか否かは、 救急医療において生死を分けるものとなりうる。また、セカンド・オピニオンの取得、地域医療機関・ 福祉機関の連携などのためにも、検査結果や投薬情報など医療情報の共有が求められている。さらに、 個人の医療情報のみならず、匿名化・統計化した大量の医療情報の速やかな共有は、感染症の動態把 握などを通して政策的な観点からも有用である。しかし、医療情報は個人情報の中でも厳重な保護を 要するものの一つといえる。プライバシ保護の観点からは、そのアクセスには厳重かつ精細な可制御 性が求められており、医療裁判（医事訴訟）の観点からは、改竄防止が求められている。また、従来、 個々の医療機関・福祉機関において局所的に取り扱われてきた情報管理を、整合性を保ちつつ広域化 するにあたっては、ID の連携、用語（オントロジー）の調整といった点で、多くの問題が発生しうる。 ここでは、医療情報の流通・共有のための仕組みに対して、ID 連携の観点から具体的に検討する。 4.2.1.2 詳細記述 (1-a) [Target] 電子カルテ（医療情報、検査結果、写真など） (1-b) 医療機関 ID、 カルテ ID、 記述項目 ID、 [Granularity] 患者 ID、 医療従事者 ID、 患者関係者 ID、 検査 ID、 処置 ID、 医薬品 ID、 医療器具 ID、 病床 (1) [What/Target] ID、 等 (1-c) [Lifecycle] ・電子カルテのライフサイクル： 生成⇒記入⇒追記⇒保管⇒廃棄 (但し、廃棄後も ID の再利用はできない) ・アクセス権限属性は ポリシー記述により追加、削除、更新される (2-a) ・診療/検査/投薬/会計のための参照/更新 [Application] (read/write)、 ・医療研究のための参照(匿名化、 統計化を伴う) (2) [Why/Goal] (2-b) [Goal Type] Accountability/Traceability 、 Matching 、 (Access)Control (2-c) [Scenario] 電子カルテ参照時のアクセス制御 ・ID 連携とシングルサインオン ・緊急時のアクセス権限の動的変更 (3-a) [Usage] 役割（担当医、救急医など） 、関係（患者本人、保護者） 、 年齢による制御など (3) [How/Usage] (3-b) [Feature] 属性に基づく識別性、 - 27 - ID 連携によるシングルサインオン、 緊急時のアクセス権限の動的変更 (4-a) 患者、医療従事者（医師、看護師、救急隊員を含めてよ [Stakeholder] いか？） 、保護者、 医院長およびなどの救急医療行為に対する同意・承認代 行者（法的な問題は？患者本人もしくは保護者による事 前承認が必要か？） (4-b) [Who⇔ (4) [Who] Merit] 患者・医療従事者⇔記述の簡潔化、 患者・医療従事者⇔シングルサインオンによる 手続きの煩雑さの軽減、 患者・医療従事者⇔緊急時のアクセス権限の動的変更 患者⇔医療訴訟時のカルテの改竄防止 自治体⇔地域医療の充実、 研究者・為政者等⇔感染症の動態把握による対策立案 (4-c) [Who⇔ 患者⇔個人情報の漏えい Demerit/Risk] (2-c) [Scenario] 電子カルテ参照時のアクセス制御 [1] ID 連携によるシングルサインオン 医師が電子カルテを参照するための認証の流れ。認証サービスが発行する証明書（アサーション） に基づくことで、シングルサインオンも実現可能である。 - 28 - 図 4.2.1.1 認証サービスに基づく電子カルテへのアクセス 4.2.1.3 ID 管理に関して、解決すべき重要な問題点・課題 (1)技術面： (1-a) 医療機関のセキュアな相互接続基盤ができていない ・実装メカニズム自体は医療機関特有のものは必要ない。セキュリティの確保さえ実現 できれば、既存の実現メカニズム(たとえば Web サービス)で構わない（むしろその方 が、各種情報システムとの相互運用を考慮すると望ましい） 。 ・すなわち、 ID 管理以前に Web 情報資源としての整備の課題が残されており （次項、参照） 、ID 管理技術はその一部に含まれる。 (1-b) 医療機関の規範となる EA(エンタープライズアーキテクチャ)の整備が不十分。 ・この(1-b)医療機関自体のサービスアーキテクチャを整理すること（共通部分は標準 化し、個別部分は独自性を維持すること）と、前項(1-a)相互接続基盤を普及させるこ とは表裏一体をなしており、強力な推進力で推し進めなければ、一方が不十分である ことを理由に、もう一方が進まないという悪循環を起こすことになってしまう。 ・すなわち、ID 管理以前に Web 情報資源としての整備の課題が残されており （前項、参照） 、ID 管理技術はその一部に含まれる。 ・医療機関ごとにオントロジーやポリシーに差異がある。 用語、組織体系、運用方針が異なる管理組織にまたがった運用管理は、問題を複雑 にする。オントロジー共通化の努力は進めるべきであるが、どうしても共通化しが たい部分や、共通化できない部分は残らざるを得ない。共通化できない部分は、個 別化したままで、安全性を維持した相互変換の自動化を進めるなど、相互運用をで きるだけ簡素な手続きで行えることが望ましい。 (1-c) 標準的な ID 連携技術がない ・管理組織の異なる複数の局所的 ID の相互運用の必要性 病院ごとの ID（たとえば患者 ID=診察券番号など）を発行するために、毎回、共通 - 29 - 的な ID 発行機関に問い合せることは、効率面で現実的ではない。また、これまで 使われてきた既存の ID を廃止し過去に遡って一元化 ID に再編するコストは莫大な ものとなるため、既存 ID との併用も不可欠である。したがって、管理組織の異な る複数の局所的な ID を相互運用することはどうしても必要となる。また、仮に共 通的な一元化 ID を併用するとしても、既に運用されている ID との関連付けが必要 となる。 ・いろいろな種類の ID の存在と情報流通の整理 患者 ID、医師/看護師/臨床検査技師/理学療法士/薬剤師等の医療従事者 ID など ヒトに対応する ID だけではなく、検査機器、病床、薬剤、給食など幅広いものに ID が付与される。それぞれ固有のライフサイクルを持ち、連携する情報システムも それぞれ異なっている。これらの相互の関連を、ID という観点から整理することが 必要である。 また、地域の枠組みを越えて複数の医院/病院で診察を受ける患者や、流動化が 進む医療従事者の勤務先の異動をも踏まえた情報流通（プライバシを配慮した病歴 情報、投薬情報、信頼性を保証した資格や診療経験等の情報の流通）も望まれる。 これには、プライバシ保護のための本人の意思に基づく属性フィルタリングならび に、医療訴訟のような際のトラブル原因特定には不可欠な信頼性保証/元本性保証 のための改ざん防止技術といった技術面と、それらが適切に適用される運用面の両 面での充実が必要である。 ・アクセス権限行使の拠り所となる ID の取扱い（権限認定のメカニズム）が決して、 十分ではない。 医療行為の場合、救急措置が生死を分けることがある。そうした緊急時の一時的な 権限委譲や、その認定といった多様な要素が業務モデルに追加された場合、それら の要素を安全に追加できるような裏付けをもった技術の整備が必要である。 (2) 運用面： (2-a) 医療情報の相互運用に関する法的問題のチェック ・医療情報の相互運用に関して法的問題の有無を調査・検討し、必要があれば解消の努 力を図らねばならない。 4.2.1.4 前節で指摘した問題点・課題に対する解決策の提言と理想像(To Be) (1) 技術面： (1-a) 医療機関のセキュアな相互接続基盤の構築を強力に推進する。 (1-b) 医療機関のための EA(エンタープライズアーキテクチャ)整備を強力に推進する。 (1-c) 標準的な ID 連携技術の確立 ・共通オントロジーの構築と、局所オントロジーの相互変換技術の確立 ・シングルサインオンのためのアドホック ID の発行と属性情報交換のための 管理機関（認証センター）の設置 (2) 運用面： (2-a) 医療情報の相互運用に関する法的整備 ・例えば、緊急性を伴う救急医療行為に関するアクセス権限動的変更に対する法的整備 - 30 - 4.2.1.5 今後の課題 ・医療機関同士のセキュアな相互接続基盤が構築に既存技術を適用するとなると、技術面では、 特に ID 連携のための仕組みの整備と普及が急務である。医療機関同士のセキュアな相互接 続基盤が構築されてから、この整備に乗り出したのでは、十分にメリットを引き出すことが できないままとなってしまう。 - 31 - 4.2.2 製造業における物流の追跡【担当委員：飯島（慶應義塾大学） 】 4.2.2.1 概要 部品/完成品の工場内物流において、RFID 等の ID タグの利用が増えている。これには、単一工場内 における在庫管理（賞味期限をもつものを含む）から、複数の部品工場ならびに組み立て工場をつな ぐ大域的なサプライチェーン管理までをも含む。本来は、製造過程だけでなく問屋や最終顧客の手元 まで含めて、製品や部品、製品や部品のコンテナ、及び製造工場や製造ライン、装置などのトレース （追跡）を可能にするものである。 RFID の読み取り距離は周波数帯によって異なるが、ID 以外の属 性の読み書き、さらには、温度等のセンサを内蔵し、各種センサ情報を読み取ることができるものも ある。 4.2.2.2 詳細記述 (1-a) [Target] 部品／部材単位、中間品、完成品、輸送単位(箱、パッ ケージ） 、車両単位 (1) (1-b) [What/Target] [Granularity] 部品、部材、中間品、完成品 (1-c) [Lifecycle] RFID などによるトレース、 在庫管理と位置管理→再配置と最適化、 (2-a) 箱を開けずに内部情報を取得 [Application] （温度センサ付き ID タグなど） (2-b) [Goal Type] Accountability/Traceability、 Matching、 (2) [Why/Goal] (Access)Control、Discovery、 Location Management(Optimal Relocation)、 Resource Optimization、 Load Balancing、 (3) [How/Usage] (2-c) [Scenario] Supply-Chain-Management (3-a) [Usage] part-of 関係にある部品 ID と完成品 ID の対応付け (3-b) [Feature] 入れ子構造を内包する ID (4-a) 部品調達者、工場内関係者、品質管理/生産管理担当者 [Stakeholder] (4) [Who] (4-b) [Who⇔ Merit] (4-c) [Who⇔ Demerit/Risk] 4.2.2.3 管理者⇒梱包を解かずに、内部情報を取得できる８ 管理者⇒流通過程で外部から情報を取得される危険が ある ID 管理に関して、解決すべき重要な問題点・課題 主な用途は、製品や部品の管理（トレースを含む）である。本来、製造過程だけでなく、流通過程 さらには、最終顧客の手元までをもカバーすることも化のであるが、最終顧客の元における最終製品 の ID の読み出しを可能にすることはトレーサビリティの確保に重要であり、最終顧客の元での物品 管理にも活用できるが、一方で、プライバシに関わる問題をも引き起こしかねない。 ID の寿命は、いつくか考えられる。工場内や工場間の運搬だけでつかわれる梱包やコンテナなどに - 32 - ID を付与する場合は時限的な ID でよいとも考えられるが、そうした ID を廃棄した場合、トレーサビ リティは損なわれる。したがって、単一の工場内での利便性だけを考慮することなく、ライフサイク ル全体にわたって大局的なデザインが必要となる。 RFID では、組み立て品の各部品や、梱包にそれぞれ ID を付与した場合、それらの情報が同時に読 み取られることがありうる。必要な時点で、必要な情報を混乱なく取得できなければならない。 4.2.2.4 前節で指摘した問題点・課題に対する解決策の提言と理想像(To Be) 製品自体にも製造から廃棄までのライフサイクルがあるが、それを越えて、製品ならびにその部品 のそれぞれに ID を付与し、トレースを可能にすることが望まれる。またタグのもつ ID 情報のセキュ リティ（アクセス制御）に関しては、その製品のライフサイクルに応じた対応が必要で、改竄防止属 性、プライバシ防止のための無効化の可否、後工程の管理者（最終的には最終顧客）による管理のた めの追記の可否などに関しての検討が必要とされる。 4.2.2.5 今後の課題 部品段階から税品段階のライフサイクル全体を考えた、ID のデザインが必要となる。また、部品や 製品だけでなく、製造者、検査員、製造装置、検査装置等の ID との結びつけも重要である。 - 33 - 4.2.3 公的個人認証の各国動向【担当委員：豊内（内閣官房情報セキュリティセンター/日立製作所） 】 4.2.3.1 概要 電子政府の先進国においては、国民が政府や自治体における電子申請などの電子政府サービスを利 用する際の本人確認として、公的な個人認証システムが利用されている。個人認証システムの方式は 当然各国で異なり、また、電子政府サービスの内容や、電子証明書に含まれる個人の属性情報などに、 国ごとの特徴がある。さらに、受けたいサービスのレベルに応じて、必要なトークン（認証に用いる 情報やデバイス）のレベルを変えている国も少なくない。 しかしながら、詳細な方式の差異や管理する情報の多寡はあっても、電子政府に関する概念や情報 サービスシステムとしての基本設計のレベルでは、各国の方式は共通点が多い。具体的には、個人認 証システムは、国民にユニークな ID（識別情報）を割り振り、ID と属性情報などを含んだ電子証明 書を記録した IC カードなどの媒体を配布し、PKI（公開鍵暗号基盤）を用いてその証明書を認証する という方式が一般的である。 ここでは、各国の電子政府サービスシステムの動向調査を、主に個人認証の視点から俯瞰した結果 をふまえ、ID 管理の現状と課題を抽出する。なお、各国の公的個人認証の動向や、比較の調査結果は、 巻末に付録として掲載する。 4.2.3.2 詳細記述 (1) [What/Target] (1-a) [Target] 住民（公共サービスの利用者） (1-b) 個人 [Granularity] (1-c) [Lifecycle] 生涯（国によっては、開始時期が、誕生時／成人 時／申請時などの差がある） (2) [Why/Goal] (2-a) 公的サービス（主に行政サービス）の申請のため [Application] の、個人認証および属性認証。サービス利用の可 否判定、課金にも活用。 (2-b) [Goal Type] (Access)Control、Matching (2-c) [Scenario] 行政機関における申請手続きにおいて、申請内容 やその重要度に応じて、認証のレベルと内容を制 御する。具体的には、住民が事前の申請によって、 認証局が発行するトークンと証明書を取得して おく。住民が行政サービス提供者にサービス利用 の申請をする際に、申請者が本人であるか（個人 認証）と、その個人が申請できる立場にあるか（属 性認証）、および必要に応じて認証レベル（精度） を認証する。さらに、そのレベルを満たすために、 複数の認証方式を連携させる場合もある（認証の 仕組みはシステムとは限らず、従来通りの書類の 確認なども含まれる） 。（図 4.2.3.1 参照） - 34 - (3) [How/Usage] (3-a) [Usage] ID は個人を認証し、個人の属性と結びつけられる (3-b) [Feature] 住民：国民、県民、市民などのサービス利用者 サービス提供者：国、地方自体、または委託を受 けた民間のサービス提供者 (4) [Who] (4-a) 住民（ユーザ） 、行政サービスの提供者（処理者） [Stakeholder] (4-b) [Who ⇔ Merit] 住民：申請手続きの簡略化／ワンストップ化、課 金処理の明確化 サービス提供者：サービス利用者の認証の容易化 及びサービス提供の可否の判断の容易化 (4-c) [Who ⇔ Demerit/Risk] 住民：事前の登録手続きやコンピュータ・リテラ シの必要性、コストの負担 サービス提供者：システム開発の負荷、既存の認 証手続きとの共存による業務の煩雑化 政府発行の写真つきID （申請者の国籍／住所がわかるもの） ・パスポート ・運転免許書 ID発行機関、信用情報機関への照会 ※レベル４認証では２種類のＩＤ書類提示 バイオメトリクス（写真、指紋）の登録 公開鍵基盤（ＰＫＩ）のデジタル証明書による認証 登録局 （RA:Registration Authority） 認証局 ブリッジ認証局 ①申請 認証局 (CSP: Certification Service Provider) ②トークン ・証明書発行 加入者 認証局 ユーザ情報 ③行政アプリケーション／ 利用可能な認証サービスの選択 ⑤SSLまたはTLSを使用して RPに対して直接アクセス・認証 認証 検証サービス ポータル リライングパーティ ④加入者を RPへリダイレクト ⑥サービス提供 図 4.2.3.1 FPKI 認証局 RPs CSs 4.2.3.3 認証局 行政アプリケーション ・サービス提供者 （RP: Relying Party） アプリケーション 証明書に基づく認証のシナリオ例 ID 管理に関して、解決すべき重要な問題点・課題 ・複雑な運用シナリオ：住民による行政サービス利用の可否は、申請を行った住民の属性値に 基づき判断がなされることが、先ずは大前提である。 しかし、現実の行政サービスの場においては、 「住民を世帯の一員として取り扱うケース」 、 - 35 - 「 （登記や所得などにかかわるような）慎重な運用が求められる行政サービスの際には、厳し い本人認証が要求されるなど、認証のレベルに差がある」、 「複数の証明書を用いて、本人認 証を行うことで、レベルの制御を行う」、「委任状を持参すれば、本来ならばその権利が無い 利用者でも、代理人としてサービスの申請ができる」、 「サービス提供の可否を、前後に利用 したサービスの内容で判定する（先に、あるサービスを利用した者だけ、次のサービスの利 用申請ができる） 」など、多種多様な運用が行われている。 即ち、サービスの提供とそのための個人認証にも、これらの場面に文脈（コンテキスト） や認証レベルを扱えることが求められる。さもないと、システムでカバーできない部分は、 現場の職員の判断や運用に依存することになり、業務の効率化や行政サービスの公平性が侵 される危険もある。 ・グループ管理／代理申請：住民は一個人であるとともに、家族の一員である場合が多い。自 分向けのサービスの申請のみならず、家族の代理あるいは家族を代表してサービスを申請す る運用も一般的であるため、グループ管理／代理申請の仕組が重要となる。 4.2.3.4 上の問題点・課題に対する解決策の提言と理想像(To Be) 北欧やアメリカなどの電子政府先進国においても、電子化されていない書類や ID カード（紙 やプラスチック製）は依然、大きな割合で活用されている。コンピュータ・システムのみで はカバーできない部分の処理や、認証レベルの確保などに際して、これらの非デジタルのメ ディアが補完的な役割を果たしている場合も多く、今後もこれら既存の非デジタルの手段と の共存、連携を図っていかねばならない。 それらの「既存の手段」を一気にデジタル化することは、コストや運用の面から見ても現 実的ではない。また、老若男女の住民や職員のコンピュータ・リテラシが急速に向上するこ とも期待できないことから、先ず求められるのは既存のオンライン、オフラインを問わず、 既存のシステムやメディアの連携の効率化や高付加価値化を図ることであろう。具体的には、 住民が望むメディアによって、オンラインでも紙でも、あるいはそれらの組み合わせでも、 柔軟に行政サービスの申請や利用ができる仕組みを整えるような取組みが望まれる。それに よって、サービスの質の向上や、また同時に現場の職員や利用者の負担も減って、ミスの発 生率や処理時間の低減を実現できると考える。 なお、認証のレベルの制御に関しては、オーストラリアにおける、複数の認証を併せて用 いる「100 ポイント・チェック」1)のような方式が参考になると考える。 注 1) 100 ポイント・チェック 政府系機関や銀行などでの申請の際の身分証明方式。書類毎にポイントが決められ、合計 100 ポイント以上の書類を揃えないと、本人であると認められない。外国人の場合は、入国後の 経過期間によってポイントの値が変化する。具体的な値は以下の通り。 パスポート／100 ポイント＜入国後、6 週間以内の場合＞ 70 ポイント＜入国後、6 週間以降の場合＞ オーストラリアの運転免許証／40 ポイント 母国の運転免許証または顔写真入りの身分証明書／25 ポイント クレジットカード／25 ポイント 居住地が証明できる書類（光熱費等の請求書等）／25 ポイント - 36 - 4.2.3.5 今後の課題 行政サービスシステムにおいても、特定目的のみのクローズドなシステムならば、ID 管理に 関する機能の仕様の明確化や、相互運用性の確保、さらに標準化などは必須ではない。しか し、複数の独立した行政サービスシステムの強調や、将来的な民間サービスとの連携による、 住民へのワンストップ・サービスの提供も考慮に入れるならば、以下の項目に関して、相互 運用を前提とした標準化が大きな意味を持つと考える。 ・認証コンテキストの管理：サービス提供者が、住民のサービス利用の可否を判断する際に、 住民の静的な属性情報のみならず、動的な属性値や利用履歴などを判断の材料とすることが でき、またサービスの重要度によって、認証のレベルを制御するための機能。 具体的には、動的なデータや履歴、利用シナリオなどを記述するための言語とそれを交換 するためのプロトコルが必要と考える。加えて、サービスの重要度や認証のレベルを定量的 に表記する方法。さらには、複数の ID の認証情報を用いて認証のレベルを上げる（あるいは 状況に応じて下げる）ための機構も必要となる。 ・ライフサイクル・マネジメント：ID は住民の誕生、成人あるいは申請などのタイミングで生 成され、権利が付与される。ID 自体は一般的には生涯不変で、有効である。ただし、成人や 結婚などのイベントに応じて、属性値や属すグループが動的に変化し、結果的に付与された 権利も変化していくことなどに対応する必要がある。 具体的には、グループの概念の導入、代理や代表という形態での申請などが実施できる必 要がある。また同じ家族でも、税金や健康保険など、異なるサービスの場合には、異なるグ ループ管理が必要となるので、複数のグループ設定ができることも必須である。 - 37 - 4.2.4 コンテンツ流通における著作権管理【担当委員：五十嵐（富士通） 】 4.2.4.1 概要 音楽、映画のようなコンテンツを配信する場合の ID 管理について記述する。 図 4.2.4.1 コンテンツ流通概念図 上図にコンテンツの生成から消費までを概念図で示す。 楽曲の例を取ると、作曲家が曲を作り、作詞家が詞を乗せて音楽が生まれ、演奏されて CD と なる。この時、作曲家・作詞家・演奏者は、この楽曲に対する権利者となり、個人識別のため に ID が必要となる。更に、配信業者や利用者も楽曲に関する権利を持つので、ID が必要であ る。 また、演奏されて出来た原盤にもコンテンツとしての ID が付与される。アルバムのように内 部にいくつかの楽曲を含む場合構造体になっている場合は、全体に ID が振られるだけでなく、 個別の楽曲にも ID が付与される。 コンテンツの不正利用を防ぐために、DRM(Digital Rights Management)が使われるが、コン テンツ ID は、このキーとも関係付けて利用される。 また、コンテンツを保護するには、利用者の信頼性を確認するだけでなく、利用機器が信頼 出来るものであることが重要であり、管理のために ID が付与される。これらの利用者、機器が 正しく信頼できるものであることを示すために、認証局が証明書を発行する。この証明書も固 有の ID に紐付けされたものである。 なお、利用者も保有する権利により、別の利用者にコンテンツを譲与したり、貸与したりす ることがある。 これら、コンテンツの流通には、支払いが伴う事も多く、ID は課金の流れも利用される。 - 38 - 4.2.4.2 詳細記述 (1) (1-a) [Target] ・ コンテンツ権利者(作詩家、作曲家、演奏者、 [What/Target] 出演者、監督、等)、 編集者、配信者、利用者 ・ コンテンツ 映画原盤、音楽アルバム原盤、 DVD 等の配布媒体毎、音楽アルバム内楽曲 ・ 受信機、格納媒体、 (1-b) コンテンツ全体。また構造体の場合は、各部分、 [Granularity] 映像の場合:シーン毎に ID が必要になる可能性あ り。 権利者：国・業界・団体・個人名（国籍も？）、 コンテンツ：データ種別・生成データ等を利用。 (1-c) [Lifecycle] 著作権が発生するタイミングから始まり、廃棄さ れるまで。 (2) [Why/Goal] (2-a) 権利伝播と利用形態。詳細下記 [Application] コンテンツの利用をトレース、課金にも活用。 (2-b) [Goal Type] Accountability/Traceability 、 (Access)Control 、Matching、Discovery (3) [How/Usage] (2-c) [Scenario] 利用事例（添付スライド）参照 (3-a) [Usage] 権利者明示、利用許可 ID を DRM のキーと結びつけ (3-b) [Feature] 図の説明以外にも、不正利用に対する権利停止な どの強制(Enforcement)等でも利用される。 (4) [Who] (4-a) 音楽の例では、作詞家・作曲家・演奏者・原盤作 [Stakeholder] 成者・データ保持者・配信業者などの権利者、及 び CD を買って聞く人・ダウンロードする人・友 人に貸す/借りるなどの利用者。 (4-b) [Who ⇔ Merit] 権利者：DRM による権利保護、課金処理の明確化 利用者：必要なコンテンツ部分を明示して利用、 貸し借りなどの明確化 (4-c) [Who Demerit/Risk] ⇔ 権利者：処理の煩雑化 利用者：無断コピーなどの防止、管理が行われる。 (1) [What/Target] (1-a) [Target]：コンテンツに関する権利者、利用者、及びコンテンツ (1-b) [Granularity]：権利者は個人あるいは団体。コンテンツは、利用形態により各 部分にもＩＤ付与が必要。また、物の ID についても、音楽アルバム CD に対して付 与されるものと、中の個別楽曲にも区別のための ID 付与が行われる。 (1-c) [Lifecycle]：権利発生から廃棄まで。ただし市場に CD 等が存在している可能性 もあり、ID 廃棄は困難と考えられる。 - 39 - (2) [Why/Goal] (2-a) [Application]：権利の及ぶ範囲と権利内容を明確にする意図あり。ID が示す対 象毎に利用時の制限や対価などの条件を決める。 コンテンツ流通においては、多くの権利者・利用者の間でデータが受け渡され、コ ンテンツや権利者を明確化が必要である。また、コンテンツの利用をトレースし、 課金にも活用。 (3) [How/Usage] (3-a) [Usage]：誰がどんな権利を持つか、誰に何を許可するかは、ビジネス構築の基 本である。この情報を示すのに ID を利用し、また ID を DRM のキーと結びつける。 (3-b) [Feature]：ID の基本であるユニーク性を示すのに、人であれば国・業界・団体・ 個人名（国籍も？） 、コンテンツではデータ種別・生成データ等を利用。 4.2.4.3 ID 管理に関して、解決すべき重要な問題点・課題 ・市販のパッケージメディア（CD、DVD 等）では、利用者(購入者)は不特定多数であり管理さ れていない。今後、オンライン配信による販売が増加するに従い、支払いのためだけでなく、 不正利用防止、 また個人毎の利用条件設定の観点から利用者の ID 管理が重要になる。 現状は、 配信システム毎に ID 取得をするので、ID や PSWD の管理が煩雑になりつつある。 ・考え方によるが、コンテンツは与えられる権利が異なると別物と考えられる場合もあり(利用 のみ・編集可能、等)、また配信者の権利やルートを明確にするためにも配信者 ID が付与さ れて流通する事もある。更に、トレース情報、課金情報(支払い条件、他)や加工情報などの 応用に関するデータの扱いも考慮する必要もある。 ・一般的ではあるが、ID 付与体系は分野・業務・サービス等で異なっており、同じ分野でもサ ービス提供者により異なる事が多く、標準化が急がれる。 4.2.4.4 上の問題点・課題に対する解決策の提言と理想像(To Be) ・一般利用者を対象にした SSO が ID や PSWD の管理に利用できるか。セキュリティの問題無く、 このようなサービスが行えるか。 ・ID の付与を複雑にせず、利用権の設定で、課金処理を含めた単純化の検討が必要。 ・コンテンツ流通において”超流通”システムで適切な対価でコンテンツ利用権を購入し、い つでも、どこでも、機器機能に応じて、対価に見合う利用が出来るようにする。 4.2.4.5 今後の課題 ・ID の標準化では、各分野で検討されているが、横通しの議論も重要である。特に個人に付与 される ID は、単なる番号であっても既に多くの ID を持っており、セキュリティが考慮され た上記 SSO が必須になる。 ・情報家電を利用したコンテンツ流通が増加していることもあり、人・物に付与する ID に対し て、権利等の関連属性を含めた標準化が、IEC TC100/TA8 で進んでいる。今後も多くの分野で 同様の標準化が出てくると思われる。上記の人に対する SSO だけでなく、物の ID 連携検討も 重要である。 4.2.5 空港・出入国管理における人流・物流の追跡【担当委員：川村（NTT データ） 】 - 40 - 4.2.5.1 概要 近年、全世界的なグローバル化の動向に伴って、航空運輸事業の需要が急速に伸びている。航空機 は空港を起点に発着を行い、旅客運輸や貨物運輸を実施するために、空港は人流、物流の集積地とな る。航空運輸事業の需要が増せば増すほど、しっかりとした追跡管理や、また仕分け管理が必要とな り、ここに ID 管理による、より高度な効率化の必要性が生じている。 空港における旅客（人流）管理の観点で見てみると、旅客は航空機に搭乗するためには航空会社か ら航空券を購入するとともに、国際線を利用する場合は法務省による出入国管理下に置かれ、また伝 染病などの検疫管理の必要性から厚生労働省の管理下にも置かれる。さらに、免税、課税の対象とし ての人物特定も必要であり、各省庁横断とともに民間航空会社を含めた人の管理が必要となり、各組 織が管理対象とする人の ID 連携が必要となる。 航空貨物（物流）の場合は、米国の DHL 社、Fedex 社あるいは国内の佐川急便などインテグレータ ーと呼ばれる業者（航空機、宅配トラックなどを自社で保有し、荷物の出発口から航空輸送を含めて 届け口までを１社で引き受ける業者）は別にして、宅配業者、航空会社などを荷物が転々流通し、ま た国際貨物の場合には税関を通過して運送が実現する場合、１つの荷物に、会社・行政機関ごとに ID 体系で管理されている現状から、ID 連携のシステムが切望される。 このように、空港においては人流・物流、それぞれにおいて ID 連携の仕組みが必要であり、ここ ではその観点から具体的に検討する。 4.2.5.2 詳細記述 (1) [What/Target] (1-a) [Target] 国際空港内の旅客および航空貨物 (1-b) 旅客 ID、貨物 ID [Granularity] (1-c) [Lifecycle]・人：例えばパスポートは有効期限が 5 年 10 年 物：１旅程ごと (2-a) 出入国管理業務や輸出入管理業務、効率的な管理業務 [Application] 管理者が多岐にわたり、それぞれ別の管理体系下にあ る。 （人：法務省、警察庁、厚生労働省、財務省、国土 交通省、外務省、航空会社 ／ 物：財務省、国土交通 (2) [Why/Goal] 省、航空会社） (2-b) [Goal Type] Accountability/Traceability 、 Matching 、 (Access)Control (3) [How/Usage] (2-c) [Scenario] 出入国時の総合的な処理 (3-a) [Usage] 各機関が保有する複数のデータベースとの照合による アクセスコントロール、関連データとの紐付け (3-b) [Feature] 属性に基づく識別 緊急時のアクセス権の動的変更 (4) [Who] (4-a) 人：法務省、警察庁、厚生労働省、財務省、国土交通省、 - 41 - [Stakeholder] 外務省、航空会社 物：財務省、国土交通省、航空会社 (4-b) [Who⇔ Merit] 官公庁：出入国管理業務における厳格性の確保 航空会社：効率的な旅客処理 旅客：待ち時間の短縮 (4-c) [Who⇔ Demerit/Risk] 官公庁：個人情報保護観点でのデータ保持 航空会社：個人情報保護観点でのデータ保持 旅客：－ (1) [What/Target] (1-a) [Target] ・国際空港内の旅客および航空貨物 (1-b) [Granularity] ・旅客 ID、貨物 ID (1-c) [Lifecycle] ・人：例えばパスポートは有効期限が 5 年 10 年 物：１旅程ごと (2) [Why/Goal] (2-a) [Application] ・出入国管理業務や輸出入管理業務、旅客案内業務 スーツケースなどの手荷物の場合は、人流と物流の接点も必要で、その連携も考慮 する必要がある。管理者が多岐にわたり、それぞれ別の管理体系下にある。 （人：法 務省、警察庁、厚生労働省、財務省、国土交通省、外務省、航空会社 ／ 物：財 務省、国土交通省、航空会社） (2-b) [Goal Type] ・Accountability/Traceability、 Matching、 (Access)Control (2-c) [Scenario] ・出入国時の総合的な処理 (3) [How/Usage] (3-a) [Usage] ・各機関が保有する複数のデータベースとの照合によるアクセスコントロール、関 連データとの紐付け (3-b) [Feature] ・属性に基づく識別 緊急時のアクセス権の動的変更 (4) [Who] (4-a) [Stakeholder] ・人：法務省、警察庁、厚生労働省、財務省、国土交通省、航空会社 ・物：財務省、国土交通省、航空会社 - 42 - (4-b) [Who⇔Merit] ・官公庁：出入国管理業務における厳格性の確保 ・航空会社：効率的な旅客処理 ・旅客：待ち時間の短縮 (4-c) [Who⇔Demerit/Risk] ・官公庁：個人情報保護観点からのデータ保持 ・航空会社：個人情報保護観点からのデータ保持 ・旅客：－ 4.2.5.3 ID 管理に関して、解決すべき重要な問題点・課題 ・各機関で保有する ID の連携実現 ・個人情報保護観点からの個人 ID の安全性確保と緊急時の対応 4.2.5.4 前節で指摘した問題点・課題に対する解決策の提言と理想像(To Be) ・関係各機関の間で統一的な ID を付与するか、あるいは各機関が個別に持つ ID を連携させる 仕組みにより解決する。すでに各機関での ID 付与が進んでいることから後者（ID 連携の仕 組みづくり）の方式を採用するべきである。 ・各機関における ID 関連情報のセキュリティレベルが異なることより、属性に基づく情報開 示レベルの把握や、事件／事故時にはレベルを動的に変更できるような仕組みとすべき。 4.2.5.5 今後の課題 ・国際空港に関連した各機関の ID を連携させることによる人、物の流通輸送管理は、空港の ような関連機関が多く存在する中においては、各機関の目的を果たしつつ効率的な移動を実 現するための有効な手立てとなる。今後は、この物流に関するデータを活用する、例えば空 港の混雑度を把握し、移動に掛かる時間をはじき出すなどの、ID を個として認識するだけ でなく、一つの大きな集団としての取り扱い技術の活用が望まれる。 - 43 - 4.2.6 RFID を実装した品物を携帯する人の、移動履歴情報の流通【担当委員：杉山（NTT ソフトウ ェア） 】 4.2.6.1 概要 RFID を実装した各種カード／商品／等を携帯する人に組織 ID や匿名化した個人 ID を付与し、RFID RFID 情報受信設備をはじめとする種々の位置検知手段で取得した移動履歴情報を、ID 管理センタで 収集し、組織 ID や匿名化した個人 ID をキーとして名寄せ・編集・加工し、統計情報として移動履歴 情報を流通することにより、組織横断的に、エリアマーケティングや、リアルタイムな人流分析や、 安心・安全管理等に活用する。 本節で定義する ID は、監視される人／トレースされる人に付ける ID であり、アクセス権限には該 当しない。 Identifier ＝ Identity 4.2.6.2 人 ＝ 性別、年齢層、 ・・・といった、個人情報を匿名化した、人に関する属性情報 詳細記述 RFID を実装した品物を携帯する人の、移動履歴情報の流通に関する詳細を、表 4.2.6.2-1 に示す。 - 44 - RFID を実装した品物を携帯する人の移動履歴情報の流通に関する詳細 項目 (1) [What/Targe t] 内容 [Target] IDが必要なもの（人，物，サービス，他）は何か？ ⇒ 組織（企業、団体、等）、および個人（その人の所有物も含む） 何にIDをつけたいか？ ⇒ ①組織（会社、企業、団体等の移動履歴情報を扱う単位） ②人（複数のRFIDカードを携帯／所有している場合も１つの同一IDとして扱う） (2) [Why/Goal] [Granuarity] 粒度(IDを付ける単位の大きさ) [Lifecycle] ⇒ 原則として、特定組織に対して、組織横断的にユニークなIDだけを付与する。 特定個人には、その組織内でユニークなIDを付与する。 IDのライフサイクルと，その管理 [Applicatoin] ⇒ その組織、およびその組織内でその人の情報の有効期間内（社員期間、会員期間 等） なぜIDが必要か？IDをつけて何をしたいか？（アプリケーション） ⇒ 特定人物の移動履歴情報であるが、具体的な人物特定を不可能とするため。 エリア・マーケティング等の各種マーケティング分析に必要な情報を、業界 横断的に流通することにより、現在位置や曜日や時間帯や個人嗜好等に基づいた、 より高度なエリアマーケティングやより高度な企業間連携サービス提供を可能と するため。 特に，サービスの連携におけるそのIDの役割は何か？ ⇒ 個人情報保護を担保した上で、個人の移動履歴情報を業界横断的に名寄せ・匿名化 して、エリアマーケティング等に有効なリアルタイム統計情報として流通させるため。 [Goal Type] IDの目的はどのようなタイプか？ たとえば，Accountability/Tracability, Matching, (Access)Control，Discovery， Location(Optimal Relocation)，Resource Optimization,Load Balancing， ⇒ 特定個人の移動履歴／行動パターンを業界横断的に時間軸と空間軸の両方で トレースするため。 [Scenario] 利用事例 ⇒ 定期券による入札・出札履歴情報と、クレジットカードの利用履歴をIDで統合 することにより、ある特定の個人（個人名は特定できないが、性別・年齢層等の 属性情報は取得可能）の時間軸・空間軸の移動履歴・購買履歴等を統合し、出店 計画策定といったマーケティングに活用する。 - 45 - (3) [How/Usage ] [Usage] ⇒ 別々の組織で獲得した移動履歴情報（位置情報の軌跡）を、IDで名寄せし、 そのIDに関連した各種の匿名化された 属性情報（年齢層、性別、居住地域、・・・ ⇒ この情報をどこまで匿名化し売買するかは 企業間で 個別に調整、ここがビジネスとなる） を取得することにより、上記アプリケーションを実現する。 [Feature]] (4) [Who] IDをどのようにつかって，そのアプリケーションを実現するか？ 図4.2.6..1に、RFIDを実装した品物を携帯する人の移動履歴情報の管理・運用・利用イ メージを示す。 [Stakeholder] 誰がIDを必要とするか？あるいは，IDに関与するか？ステークホルダー ⇒ 種々の業種で取得した移動履歴情報を名寄せして、新しいサービスをクリエ イトしたい企業。および移動履歴情報を取得・他業種に販売したい企業 [Who⇔Merit] (whyと重複するかもしれません．) そのIDを持つことによって，どのステークホルダーがどのようなメリットを享受するか？ ⇒ 移動履歴情報を提供する組織が、組織間で移動履歴情報を共有することによって、 お互いの利害を意識することなく、個人情報を匿名化した状態で流通できると同時に、異 業種にまたがってIDをキーとして名寄せできるため、リアルタイムでタイムリーな移動履 歴情報と抽象化された個人嗜好情報を活用して、新しいサービスが創造できる。 ⇒ 多種多様な組織から入手した移動履歴情報に基づいて、エリアマーケティング、配送 管理の効率化、新サービス創造等のビジネスが、よりタイムリーなデータに基づいて、分 析･構築できる。 [Who⇔ そのIDを持つことによって，どのステークホルダーがどのようなデメリットを蒙るか？ Demerit/Risk] ⇒ 移動履歴情報の提供レベルをどの程度に設定するかに依存するが、競合他社に有 益となる自社の情報を流出してしまう結果となり、移動履歴情報提供元企業が、自社の 折角のビジネスチャンスを逸してしまう（競合他社に奪われてしまう）危険性がある。 - 46 - ・利用事例（シナリオ） RFID を実装した品物を携帯する人の、移動履歴情報の管理・運用・利用イメージを、図 4.2.6.1.に 示す。 警備保障会社 自治体 ビル運営会社 鉄道会社 街頭防犯 （RFIDアンテナ） ホームセキュリティ （RFID／家電センサー等） 出勤 出勤 携帯電話会社 ビルのセキュリティゲート （RFID／ICカード） 駅の改札 （RFIDカード） 出社 外勤 位置情報サービス （GPSケータイ） 飲料会社 外出 帰宅 寄道 駐車場／料金所 （ETC／RFID等） 道 寄 運輸会社 飲料会社 動態管理システム （GPS） 店舗 買い物 （RFID／ICカード） 駐車場運営企業 自動販売機 （RFIDカード） 退社 自動販売機 （RFIDカード） 買物 飲料会社 自動販売機 （RFIDカード） 店舗 リアルタイム・エリアマーケティグ情報（曜 日別／時間帯別／年齢層別／男女別／ エリア別の移動履歴／立寄履歴／購買 履歴／・・・） ID管理センタ 買い物 （RFID／ICカード） IDの名寄せ・ 仮想ID付与・ 移動履歴編集・ 匿名化・ 社間横断的 移動履歴情報の合成 ＜移動履歴情報の登 録（初期登録）＞ ①組織ID ②匿名個人ID 図 4.2.6.1. ＜移動履歴情報の提供（運用中）＞ ③移動履歴情報（個人ID単位） 組織IDと匿名個人IDと 移動履歴情報の 対応関係管理 ク＞ バッ 計情報 ド ィー 歴 統 ＜フ 動履 移 ④ ＜ビジネス：サービス向上・業務効率化＞ 仮想ID ＋ 匿名化した 移動履歴 の販売・提供 広域リアルタイム交通渋滞情報の提供 運送会社間での荷物輸送効率化 ・・・ ＜防災・防犯・安全・行政サービスの高度化＞ 災害発生時の避難／移動状況の把握 ①組織ID-DB ②個人ID-DB ③移動履歴 情報-DB 迷子探し・・・ RFID を実装した品物を携帯する人の移動履歴情報の管理・運用・利用イメージ ・利用事例における、ID の詳細、使われ方、ID の管理 ［ID 管理センタの役割］ ID 管理センタは、企業 ID／センサ ID／匿名化個人 ID の付与、ID の名寄せ・仮想 ID 付与・移動履歴 編集・匿名化・社間横断的移動履歴情報の合成等を実施し、企業や個人のセキュエイティ／プライバ シを保護した状態で、収集した移動履歴情報を統計情報として加工・編集し、匿名化した移動履歴情 報を、必要とする企業に販売・提供する機能を有する。 ［RFID 情報の初期登録］ ID 管理センタは、RFID 情報受信設備をユニークに特定可能とするために、企業 ID と、企業内ユニー クなセンサ ID を付与する。この二つの ID は仮想 ID であり、企業や RFID 情報受信設備を特定するこ とはできない。 RFID 情報受信設備を設置した組織に関する情報を、 図 4.2.6..2. に示す組織 ID 登録フォーマットで、 - 47 - 組織 ID／センサ ID を対にして、初期登録する。RFID 情報受信設備の設置位置としては、センサ位置 Ｘ／Ｙ座標、住所（郵便番号） 、住所（都道府県名＋市区町村名＋字） 、住所（丁目）、住所（番地号） 、 ビル名／マンション名／施設名／駅名、企業名、店舗名／改札口名のいづれか、またはいくつかの組 合せで指定する。これにより、企業情報の匿名化レベル及び RFID 情報受信設備の設置位置の匿名化 レベルが選択できるようにする。 また、位置情報検知位置職業分類と、企業個別属性の登録は、オプションとする。 ①組織ID 項 目 企業ID 必須 必須 ／オプ 属性 int サイズ 格 納 内 容 8B セン セン サー位 サー位 住所 セン 置情報 置情報 （郵便 サーID （Ｘ座 （Ｙ座 番号） 標） 標） 必須 住所（都道府県名＋市区町村名＋ 字） 住所（丁目） OP1-1 OP1-2 OP2-1 住所（番地 ビル名／マンション 号） 名／施設名／駅名 企業名 店舗名／改札口名 検知位置職業 分類（大分類） 検知位置職業分類（中分 類） 企業個 企業個 企業個 企業個 検知位置職業分類（小分 別属性 別属性 別属性 別属性 類） １ ２ ３ ４ OP2-2 OP2-3 OP2-4 OP3-1 必須 OP3-2 OP6-1 OP6-2 OP6-3 int int int char char char char char int char char char char 8B 4B 4B 8B 200B 10B 20B 50B 200B 50B 10B 10B ■ 飲食業 ■ 小売業 ■ 運輸業 ■ サービス業 ■ 不動産業 ■ 金融・保険 業 ■ 官公庁 ■ 電気・ガス・ 水道業 ■ 卸売業 ■ 建設業 ■ 製造業 ■ 農林水産業 ■ 鉱業 ■飲食業 ⇒ 食堂・レスト ラン 専門料理店 ■小売業 ⇒ 飲食飲料 繊維・衣服 日用品雑貨・ 文化品 ■運輸業 ⇒ 陸運業 水 運業 航空運輸業 倉庫業 ■サービス業 ⇒ 情報・通 信産業 生活関連サービス レジャー産業 ■不動産業 ⇒ 不動産開 発・分譲 不動産賃貸 ■金融・保険業 ⇒ 銀行・ 金融機関 貸金業 証券 業・商品先物取引業 ■官公庁 ⇒ 国家公務 地方公務 外国公務 GPS／ GPS付 携帯電 話で取 得時 GPS／ GPS付 携帯電 話で取 得時 郵便番号で表現可能な住所 図 4.2.6.2. OP7-1 OP7-2 OP7-3 OP7-4 ・・・ 企業個 別属性 ｎ OP7-n char char char char char 10B 100B ■食堂・レストラン ⇒ ・飲食店 ・カジュアルレス トラン ・食堂 ・定食店 ・ドライブイン ・ド ライブイン・道の駅 ・ファミリーレストラン ・道 の駅 ・洋食店 ・洋食レストラン ・リストラ ンテ ・レストラン ・和食レストラン ■陸運業 ⇒ ・自動車運輸業 ・自動車 運送業 ・その他の道路貨 物運送業 ・鉄道業 ・路面電車 ・地下 鉄 ・モノレール ・ケーブル カー ・リフト ・ロープウェー ・トローリー バス 100B 100B 100B 100B 組織 ID 登録フォーマット（例） ID 管理センタは、RFID を実装した品物を携帯する人をユニークに特定可能とするために、ユニーク な個人 ID を付与する。この個人 ID は仮想 ID であり、個人を特定することはできない。 RFID を実装した品物を携帯する人の個人情報は、性別と年齢層のみを登録し、個人が特定できないよ うに匿名化して登録する。個人情報そのものは登録しない。個別属性の登録は、オプションとする。 図 4.2.6.3.に、匿名個人 ID 登録フォーマットを示す。 ②匿名個人ID 項 目 個人ID 必須 必須 ／オプ 属性 int サイズ 格 納 内 容 4B 個別属 個別属 個別属 個別属 性１ 性２ 性３ 性４ 年齢層 必須 必須 任意 任意 任意 任意 任意 char char char char char char char 2B 10B 00～10 10～20 20～30 30～40 40～50 50～60 60～70 70～80 80～90 90～ 100B 100B 100B 100B 100B 個人の 特定は 不可 能、同 （男／ 一ID名 女） 寄せで 異動履 歴合成 図 4.2.6.3. ・・・ 個別属 性ｎ 性別 匿名個人 ID 登録フォーマット（例） - 48 - ［移動履歴情報の提供（ID 管理センタへの送信・収集） ］ 運用中は、RFID 情報受信設備で受信した、RFID を実装した品物を携帯する人の移動履歴情報と位置 情報取得時刻を対にして、図 4.2.6.4.に示す移動履歴情報の通信フォーマットで、ID 管理センタに 送信する。このフォーマットで送信することにより、企業情報、RFID 情報受信設備情報、および個人 情報そのものは送信されないため、通信時の盗聴防止等、個人情報の保護が担保できる。 ③移動履歴情報 項 目 企業ID 必須 必須 ／オプ 属性 int サイズ 4B 格 納 内 容 図 4.2.6.4. 個人ID 位置情 位置情 位置座 位置情 セン （各社 報（緯 報（軽 標取得 報取得 サーID 独自） 度） 度） 年月日 時刻 必須 必須 OP1-1 OP1-2 int int int 4B 4B 4B 個人の 特定は 不可 能、同 一ID名 寄せで 異動履 歴合成 GPS／ GPS付 携帯電 話で取 得時 必須 必須 int date time 4B 8B 6B GPS／ GPS付 YYYYM HHMM 携帯電 MDD SS 話で取 得時 移動履歴情報の通信フォーマット（例） ［移動履歴情報の名寄せ、統計情報への編集・提供］ ID 管理センタでは、初期登録された、組織 ID と匿名個人 ID に基づいて、サービス運用中に収集した 移動履歴情報を名寄せし、社間横断的な移動履歴情報として合成する。図 4.2.6.5.に、特定個人に着 目した移動履歴統計情報の配信フォーマット、図 4.2.6.5.に、特定場所に着目した移動履歴統計情報 の配信フォーマットを示す。 - 49 - ③移動履歴統計情報（特定個人に着目） 項 目 個人ID （各社 性別 独自） 必須 必須 ／オプ 属性 int サイズ 格 納 内 容 移動履 位置情 位置座標取 立寄場 歴情報 報取得 得年月日 所 個数 時刻 年齢層 必須 必須 必須 OP1-1 必須 char char date int time 4B 6B 4B 2B 10B 8B 00～10 10～20 個人の 20～30 特定は 30～40 不可 能、同 （男／ 40～50 YYYYMMDD 一ID名 女） 50～60 60～70 寄せで 70～80 異動履 80～90 歴合成 90～ 図 4.2.6.5. HHMM SS 特定個人に着目した移動履歴統計情報 ③移動履歴統計情報（特定場所に着目） 項 目 個人ID 測定場 通過年 通過時 （各社 性別 所 月日 刻 独自） 必須 OP1-1 ／オプ 属性 int サイズ 4B 格 納 内 容 図 4.2.6.5. 年齢層 必須 必須 必須 int char char 4B 2B 10B 00～10 10～20 20～30 30～40 （男／ 40～50 女） 50～60 60～70 70～80 80～90 90～ 個人の 特定は 不可 能、同 一ID名 寄せで 異動履 歴合成 特定場所に着目した移動履歴統計情報 これらの、移動履歴統計情報は、次のようなビジネス・シーンで活用されることを想定している。 ＜ビジネス：サービス向上・業務効率化＞ ・リアルタイム・エリアマーケティグ情報（曜日別／時間帯別／年齢層別／男女別／エリア別の移 動履歴／立寄履歴／購買履歴／・・・） ・広域リアルタイム交通渋滞情報の提供 ＜防災・防犯・安全・行政サービスの高度化＞ ・災害発生時の避難／移動状況の把握 ・迷子探し・・・ - 50 - 4.2.6.3 ID 管理に関して、解決すべき重要な問題点・課題 (1)複数組織が管理する匿名化個人 ID を連携し、組織横断的に移動履歴情報の名寄せを実現す るための条件の明確化 (2)個人 ID 管理の安全性確保方式の検討・具体化 (3)個人情報開示・契約基準の検討・具体化・制度化 4.2.6.4 上の問題点・課題に対する解決策の提言と理想像(To Be) ・ 大規模な移動履歴情報を収集･管理している企業を巻き込んだ、企業 ID／センサ ID／匿名化個 人 ID 通信プロトコル（交換フォーマット）と、移動履歴情報通信プロトコル（交換フォーマ ット）の具体化・標準化の推進 ・ 大規模な移動履歴情報を収集･管理している企業を巻き込んだ、官庁主導による ID 管理センタ の設立と試行運用の実施 ・ 個人情報保護の観点から見た移動履歴情報流通の安全性の評価の実施 ・ 組織横断的な移動履歴情報流通ビジネスの観点から見たビジネス性の評価の実施 4.2.6.5 今後の検討課題 (1)プライバシ保護の必要十分性の検証 ⇒ 匿名化個人 ID は住民基本台帳番号よりもずっと、プライバシ情報に近そうである。現在、 氏名や電話番号をキーにして、いろいろな個人情報の名寄せができてしまいそうにも関わら ず、それでも「漠然とした不安感」から、住民基本台帳ネットワーク反対を声高に叫ぶ反対 派が根強い。 （反対派が反対しているのは、 「単一の個人特定 ID を導入する」ことではなく、 それを「国が管理する」というところにあるのかもしれません） 、その反発に備える意味で、 十分な検討が必要である。 (2) 匿名化個人情報の提供と、安全と便利のトレードオフの検証 ⇒ 国民感情は、「便利」が「不安」を上回れば、極端から極端へ、簡単にサーっと流れてしま う可能性があるように思われます。今後は、移動履歴情報を故人が提供し、それを組織横断 的に流通・活用することによるメリットの具体化（高齢化社会における安心・安全・企業提 供サービスの向上、企業利益の向上、等）と、個人ひとりひとりが教授できる利益・不安の 解消の具体化と、これらのメリットに対する安全と便利のトレードオフレベルの検証が必要 である。 - 51 - 4.2.7 プローブ情報を利用した車への情報推薦サービス【担当委員：岩崎（デンソーIT ラボ） 】 4.2.7.1 概要 近年、渋滞などの道路交通情報を検出し、利用者に提供する手段としてプローブ情報システムが、 国内外で注目されている．プローブ情報システムは、自動車のもつ位置や速度などのセンサ情報を、 携帯電話通信網などを利用してセンタに集め、統計処理をすることで、交通情報などの各種情報を生 成し、生成した情報を利用者に提供するシステムである。センサとなる自動車をプローブカーと呼ぶ。 道路に設置された検知器を利用する Vehicle Information and Communication System（VICS）に比べ、 検出できる道路が多くなる利点がある。国内では、経済産業省とソフトウェアエンジニアリング （COSE）技術研究組合の共同プロジェクトによるタクシーなどの商用車の情報を利用するシステムな どの研究プロジェクトが進められており、また、各自動車メーカーの情報サービスに加入した一般車 の情報を利用するシステムが運用されている。 プローブ情報システムの主たる検出対象は渋滞などのドライバを特定しないでもよい交通情報で ある。ただし、プローブの情報は、ドライバがいつ、どこへ行くかというような情報であるため、個 人情報として取り扱う必要がある。そのため、個人情報を適切に保護するために、ISO/TC204/WG16 にて、 「プローブ情報システムにおける個人情報の保護」を検討されている。さらに、プローブ情報 システムを応用すると、時間、位置、速度からドライバの行動自体を検出できるため、これを積極的 に利用することで、ドライバの嗜好に基づくコンテンツ提供などが可能になる。検出対象が渋滞であ れば、個々の車を特定できないようにシステム構築することになるが、嗜好に基づく情報提供であれ ば、サービス提供先の特定、課金などのためにある程度の個人特定が必要になる。こうした場合の個 人情報の保護や管理や利用を行うためには、ID 連携が必要になる。 4.2.7.2 詳細記述 (1) [What/Target] (1-a) [Target] 車（プローブカー） 、またはドライバ (1-b) 車両 ID（VID） 、ユーザ（ドライバ）ID（UID） [Granularity] (1-c) [Lifecycle] ・車両 ID のライフサイクル 確立→利用（認証）→破棄 ・ユーザ ID のライフサイクル 確立→利用（認証、連携他）→破棄 (2) [Why/Goal] (2-a) 車における、パーソナル情報推薦サービス [Application] ID は、プローブカー、情報利用者の個人情報を保 護や、契約に基づく位置情報に連動したサービス を実施に用いる (2-b) [Goal Type] Matching 、Traceability、Control、Discovery (2-c) [Scenario] 利用事例 ・場所や嗜好にあった広告配信 ・場所や嗜好にあった情報推薦 (3) [How/Usage] (3-a) [Usage] ・プローブカー、情報利用者の個人情報を保護 ・契約に基づく位置情報に連動したサービス（属 性と行動の紐付け） - 52 - (3-b) [Feature] 属性に基づく識別性 ID 連携によるシングルサインオン 属性情報の交換・利用 (4) [Who] (4-a) ドライバ、テレマティックスプロバイダ、プロー [Stakeholder] ブ情報センター、サービスプロバイダ (4-b) [Who ⇔ Merit] ドライバ: シングルサインオンによる手続きの 軽減 テレマティックスプロバイダ、プローブ情報プロ バイダ：加入者増 サービスプロバイダ：有効な広告配信、最適なコ ンテンツ推薦、不正アクセス防止 プローブ情報プロバイダ：加入者増 (4-c) [Who ⇔ Demerit/Risk] ドライバ: 不要情報の受信、不要タイミングで の受信、情報漏洩 サービスプロバイダ： 機会損失の可能性 テレマティックスプロバイダ、プローブ情報プロ バイダ： 運用費 (1) [What/Target] (1-a) [Target] ID が必要なものは、プローブカーとなる車、さらにその車のドライバである。 (1-b) [Granularity] 粒度は、プローブカー単位（VID）または、ドライバ単位（UID) (1-c) [Lifecycle] VID: 確立（作成）→利用（認証、変更）→破棄（削除） UID: 確立（作成）→利用（認証、変更、連携、SSO、属性）→破棄（削除） ID の権限は、ポリシー記述で追加、削除、更新 (2) [Why/Goal] (2-a) [Application] 車における、パーソナル情報推薦サービス サービス利用者に場所や状況に応じた嗜好にあう情報をサービスする、位置連動型 の広告配信 VID：プローブカーの ID UID：サービス利用者の特定用 UID１：特定のサービスプロバイダ１の扱う利用者の特定用 (2-b) [Goal Type] VID、UID、UID1 については Matching UID１については、契約対象のサービスに対する Control、Discovery、 行動に関する Traceability (2-c) [Scenario] ・場所や嗜好にあった広告配信 - 53 - 昼時になれば、車の近くや目的地までの経路に沿ったレストラン情報配信。 行動範囲に対する、イベント情報配信。 ・場所や嗜好にあった情報推薦 歴史に興味がある人の場合は、歴史情報の配信。 スポーツに興味がある人の場合は、スポーツ情報の配信。 プローブ情報 プロバイダ 交通情報 プローブ 処理 テレマティックス プロバイダ UID プローブ 収集 車（プローブカー） VID VID プローブデータ ユーザ属性 UID VID プローブデータ (サービス要求) サービス エリア情報データ要求 エリア情報 データ プローブデータ ユーザ属性 ユーザ エリア情報データ 交通情報 サービス 認証業者 VID 認証サービス 認証アサーション UID1 ログイン UID1 認証アサーション サービスプロバイダ１ UID1サービス要求 テレマティクス サービス サービス UID コンテンツ推薦 サービス UID1 コンテンツ ユーザ属性 属性提供業者 登録 ユーザ属性 属性情報 サービス 図 4.2.7.1 パーソナル情報推薦サービス (3) [How/Usage] (3-a) [Usage] VID：テレマティックスプロバイダにおいて、プローブカーの特定、認証に用いる UID：テレマティックスプロバイダにおいて、ユーザの特定、認証に用いる UID１：サービスプロバイダ１の扱う利用者の特定用、プローブセンターとサービ スプロバイダの間でやりとりする ID。ID の属性（年齢、性別、車のタイプなど）に対するサービス 対象である行動の紐付けを行う。 (3-b) [Feature] ・属性に基づく識別性 ・ID 連携によるシングルサインオン：車両からでは、運転中など操作できないタイ ミングが多いため、テレマティックスプロバイダがユーザから委譲をうけて、シングルサイ ンオンを実現する必要がある ・属性情報の交換・利用：操作できないドライバの代わりに、属性提供業者を利用 して、交換、利用を行う。また、ID から属性に変換することで個人特定を防ぐ - 54 - 4.2.7.3 ID 管理に関して、解決すべき重要な問題点・課題 技術的な問題点は、ID 保護や管理において。まずは、連携上での情報漏洩を防止するための安全な 通信路の構築が必要である。また、エリア情報データの作成、利用に関して、プロバイダにおける個 人の匿名化処理技術が必要である。さらに、サービスプロバイダが、個人の匿名性を確保しつつ、プ ローブ情報を活用できるような連携方法（プロトコル、情報内容）の確立が必要である。 また、運用上の問題点は、ISO/TC204/WG16 にて、 「プローブ情報システムにおける個人情報の保護」 を検討されており、こうした標準に則った管理が行われているかについて、第３者による検証体制が 必要であろう。また、テレマティックスプロバイダと多くのサービスプロバイダとの間の連携方法に ついての標準化も必要となる。 4.2.7.4 上の問題点・課題に対する解決策の提言と理想像(To Be) 技術的な問題点は、安全な通信路、匿名化処理技術については、ISO/TC204/WG16 にて、 「プローブ 情報システムにおける個人情報の保護」に則り、無線通信やインターネットやイントラネットにおけ る技術を導入することが基本となるであろう。また、連携方法については、情報のフィルタ推薦など のサービスに制約を与えないレベルでの情報流通基盤技術として開発する必要がある。 運用上の問題点については、検証体制についてのガイドラインの構築が必要となる。また、連携方 法の標準については、サービスプロバイダの競争領域になりうる、情報フィルタ技術やコンテンツに 関わるため、サービスに制約を与えないような標準化が必要となる。 4.2.7.5 今後の課題 以下のような課題がある ・連携方法について、情報のフィルタ推薦などのサービスに制約を与えないレベルでの情報流通基盤 技術の開発 ・個人情報保護に対する検証体制についてのガイドライン作成 ・連携に関して、サービスに制約を与えないような標準作成 - 55 - 4.3 成果 前節で示したように、当 WG では、医療情報アクセス制御、物流におけるモノの移動情報の追跡と流 れの管理・制御、公的な個人認証（ヒトの認証とサービス利用権限の認定）、コンテンツ流通におけ る著作権管理、空港。入出国管理におけるヒトとモノの移動情報管理と流れの制御、国内での人の移 動情報に基づく情報流通、自動車からの情報収集とその情報による推薦（情報流通）といった事例を 通して、いろいろな場面において、望まれる ID 管理の在り方に関して検討し、レビューすることで、 その要素抽出を試みてきた。その多様な要素を整理し、モデルとしてまとめ上げる作業の多くは、今 後の課題とするが、現段階で何点か見出すことのできた共通要素もある。 まず、取り上げた各事例の中では、ID を付与する対象(主体)は、ヒトやモノといった物理的実在物 もあれば、サービスや役割といった抽象的カテゴリないし論理的存在もある。さらには、ひとつの対 象が、人が複数の役割を兼ねていて観点・様相（アスペクト）によって異なる側面を見せることがあ る。たとえば、同じヒトが、アクセスする資源・サービスごとに異なる ID を使用しなければならな いといったこともあれば、共通の ID で複数のサービスを利用することができることもある。また、 製品が部品から組み立てられるような階層構造を有しているときにどの階層で対象をとらえるか、あ るいは、グループ化した集合をどのような粒度でとらえるかによって違うものとして捉えられるため、 それぞれ適切な ID を振り分ける、もしくは、ID をグループ化することが必要になる。こうした、対 象(主体)と ID との関係づけは、現実世界では、複雑なものとなっているということである。一つ分 かりやすい例をあげれば、ある一人のヒトは、A 病院では A 病院の診察券に書き込まれた ID-A という 患者番号を、別の B 病院では、B 病院の診察券に書き込まれた ID-B という患者番号を使い、薬局では、 また薬局独自の「お薬手帳」に書かれた管理番号を使用するといった具合である。この「お薬手帳」 を１冊しか持っていなければ、この手帳の上で、この患者への投薬情報は集約され一元化できるが、 必ずしもそうであるとはいえない。 こうした背景を踏まえて、第一に挙げられる各事例の共通要素は ID 連携の必要性である。情報漏 洩に対するセキュリティ上のリスクを排除することさえできれば、あらゆるサービスでこうした ID を一元化することは、覚えなければならない ID や認証に必要な証拠（診察券やパスワード）を減ら すことにつながり、サービスの利便性向上のために望ましい。しかし、既に複数の独立な管理組織の 下でばらばらに運用されている（一種の乱立状態にあるとも言える）ID を統合することは実質上、き わめて困難である。そこで、既存の ID 体系を保持しつつ相互連携を図ることが望まれる。もっとも、 単に ID 連携と言っても、たとえば上位サービスとして、いわゆるワンストップサービスのような統 合サービスを実現し、管理者がドメイン毎に ID の相互変換ができればよいものか、統合サービスを 設けず、利用者が個別サービスを連動させながら利用していくトランザクションのためのシングルサ インオン(SSO)が望まれるのか、といったバリエーションはありえる。ID の一元化においても、複数 の既存 ID を廃止して、一元化 ID に置き換えるのではなく、個別の ID 体系を束ねる上位の ID を設け るといった手段もある。これも ID 連携の一つのパターンといえよう。 第二に、個別の主体から収集した情報をもとに新たな価値ある情報を生成し、個々の主体に対しフ ィードバックするといったアプリケーションも、事例のうちに複数見出された。たとえば、4.2.6 節 のヒトの移動情報収集や、4.2.7 節の自動車からの各種情報収集によって、情報源の中の特定の個人 や、関心を持つ他のヒトに対して、価値ある情報を提示したり、推薦したりすることが可能となる。 このとき、いろいろなセンサ、メディアを通した情報収集の中で、同一主体であることを認識し追跡 するためには、別々の管理組織で管理されている ID を連携させる必要がありうる。また、収集した - 56 - 情報に意味を持たせるために属性に基づいてフィルタリングを施したり、プライバシ保護のために匿 名化する必要が生じるが、そうした措置を施した上で、情報の利用者/提供者の同意した契約に基づ いて集約情報を流通させることができなくてはならない。 このようなパターンの ID 連携に関しても、 明確なモデル化が必要である。 第三に、ID 連携において、複数の認証強度（信頼性・確信性の度合い）が混在することがありうる という点を挙げる。利用者がネットワーク越しであるか否かによらず情報やサービスにアクセスする 場合、そのアクセス権限を有する主体かどうかの認証が行われる。しかし、要求される認証強度（信 頼性・確信性の度合い）は、アクセスしようとする情報やサービスごとに異なる。ID 連携の際には、 そうした要求される認証強度の変更を必要とし、そのために、権利保有者であることの認証強度を向 上させるための証拠の追加提示を求め、それらの証拠を組み合わせて、一つの権限を認定することが できるといったケースがありうる。 このような認証強度を意識した ID 連携の仕組みも必要とされる。 証拠には、各種の証明書や、認証・認定の対象となる主体の行動履歴などがありうる。 以上まとめると、乱立する複数の ID 体系の混在による煩雑さから、利用者を解放し利便性を向上 させるために、(1) 「一つの ID を元に複数のサービスにアクセスすることを可能にし、サービスを 組み合わせるサービス連携を実現する ID 連携技術」 、ID 連携の下で、(2)「プライバシを保護しつつ 独立した複数組織で収集した情報を集約し、新たな価値を生み出して再配布するような情報流通技 術」 、および、ID 連携において、(3) 「必要とする認証強度が異なるような多様なサービスに対応す るための認証強度を意識した ID 連携技術」の三つの技術が、本年度調査した 7 つの事例から見出せ た、実現が望まれる共通要素である。 【WG2 主査】 4.4 今後の課題 調査した各事例に関して、より詳細に要素を抽出しモデル化していくことが、次に実施すべき課題 である。さらに、本年度 WG1 が実施した「シーズの観点からの技術調査」の結果が、本年度の WG2 で 調査してきた事例に対して、どのように適用でき、そこに、技術的に不足な点、過剰な点があるかど うかを評価していくことも、本年度の成果に引き続いて実施すべき課題と言える。 【WG2 主査】 - 57 - 5. 今後の展望と課題 本調査研究においては、アイデンティティ管理技術について、その技術動向の調査とともにアイデ ンティティ管理技術を利用する側からのニーズを広く調査することにより、アイデンティティ管理技 術が普及するための課題の分析を行った。 その結果、アイデンティティ管理技術のなかでも、 「ID 連携」についての社会的なニーズが存在す るとともに、それを支える技術としてリバティアライアンス規格、openID 規格などの展開、あるいは 相互連携に注目が集まっており、ここに大きな課題が存在することが分かってきた。具体的には次の 三つの課題を、検討が必須である事項として抽出した。 ・ 高度な機能である認証コンテキストや属性情報の受渡しや管理、認証提供者の信頼度の評価方 法などについて、今後整備が必要になってくると考えられる部分。 ・ この部分が様々な利用シーンからのモデル化要素としても抽出できるか否かについての検証。 ・ 「ID 連携」の側面からのプライバシィ問題の検証。 高度化、拡大化する IT ネットワークインフラストラクチャにおいては、従来の社会活動の効率化 を目的にポイント・トゥ・ポイントで表現される単なる一対の情報のやり取りの段階を乗り越え、次 の世代となる、まさにネットワークという言葉で表現される“連携”で新たな価値を見出す段階に来 ており、その際に必要となる ID 連携技術の規格化による提供サービスの安定供給は社会にとって重 要な施策になる。 本年度の活動としては、上述したようにアイデンティティ管理技術について広く捉えるところから 始まり、中でも ID 連携に注目することにより、その中で具体的な課題の抽出を行うところまで実施 することができた。次年度以降、この技術的整備の必要な部分についての精査とニーズ検証が必要で ある。そして、これらの課題の整理を通して、INSTAC として JIS 化への提言をまとめて行くことが必 要である。 - 58 - 附属資料 アイデンティティ管理技術の標準化動向 この報告書には、次にしめす附属資料がある。これらの附属資料は、当該分野における代表的な例を 解説するためのものであり、特定の製品を推奨するものではない。 A. ISO/IEC JTC1/SC27 WG5 におけるアイデンティティ管理技術標準化活動 B. リバティアライアンスにおけるアイデンティティ管理技術標準化活動 C. マイクロソフト社におけるアイデンティティ管理技術の展開 D. ベリサイン社におけるアイデンティティ管理技術の展開 附属資料 A では、国際標準化団体 ISO/IEC JTC1/SC27 WG5 で現在行われている、アイデンティティ管 理技術の標準化活動に関する標準化動向について報告する。附属資料 B では、アイデンティティ管理 標準化団体リバティアライアンスにおける標準化活動を中心として、主要なアイデンティティ管理技 術の標準化動向を解説する。附属資料 C では、マイクロソフト社における、サーバ系及びクライアン ト系の機器に対するアイデンティティ管理技術の展開について解説する。附属資料 D では、ベリサイ ン社における、アイデンティティ管理のための認証技術の展開について解説する。 - 59 - 附属資料 A. ISO/IEC JTC1/SC27 WG5 におけるアイデンティティ管理技術標準化活動 ISO/IEC JTC1/SC27 は、国際標準化団体 ISO/IEC において情報技術関係の標準化を担当する技術委員 会 JTC1 に所属する専門委員会の一つである。情報セキュリティ技術を担当し、その配下で現在次の 五つの小委員会 WG が活動している。アイデンティティ管理は WG５が担当している。 ・ SC27/WG1 セキュリティ要求条件、セキュリティサービスとそのガイドライン ・ SC27/WG2 セキュリティ技術とメカニズム ・ SC27/WG3 セキュリティ評価基準 ・ SC27/WG4 セキュリティ管理とサービス ・ SC27/WG5 ID 管理とプライバシ技術 アイデンティティ管理に関連する課題を扱う専門委員会には、ISO/IEC JTC1 の次の SC がある。 ・ SC17 カードと個人識別 ・ SC37 バイオメトリクス SC27/WG5 は 2006 年 11 月に、プライバシ管理を課題として活動を開始した。附属資料 A は、2007 年 5 月のモスクワ会議における、アイデンティティ管理の枠組み(Framework for identity management) に関する議論を紹介している。 現在審議されている課題は、資料に述べられている３課題、ISO/IEC24760 Framework for identity management、ISO/IEC29100 Privacy Framework、ISO/IEC29101 Privacy Reference Architecture に SC27WG2 から移動された課題、新規に提案された課題などを含め、次の 11 課題となっている。 （日本 語訳は説明のためのものであり、正式な訳語という訳ではない。） ・ アイデンティティ管理の枠組み(Framework for identity management) ・ 生体認証テンプレートの保護(Biometric Template Protection) ・ 生体認証のための認証コンテクスト(Authentication context for biometrics (ACBio)) ・ プライバシの枠組み(Privacy Framework) ・ プライバシ参照アーキテクチャ(Privacy Reference Architecture) ・ 実体認証の保障(Entity authentication assurance) ・ アクセス管理の枠組み(A framework on access management) ・ プライバシの公式文書の参照リスト(Official Privacy Documents References List) ・ WG5 Road Map (WG5 SD1) ・ アクセス管理の機構(Access Control Mechanisms) ・ プライバシの能力成熟モデル(Privacy Capability Maturity Model) 現在、アイデンティティ管理標準化は、SC17、SC37 など JTC1 の他の専門委員会において、あるいは ITU-T (International Telecommunication Union Telecommunication Standardization Sector)、リ バティアライアンス、FIDIS(Future of Identity in the Information Society)などの標準化団体に おいてなど、様々な機関で標準化活動が進んでいる。その中で SC27WG5 が扱うべき適用分野を決め、 標準化を進めるために、他の標準化機関との連携を図りながら規格内容に関する議論が進められてい る。 参考 JTC1 http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/customview.html?func=ll&obj Id=327993 ITU-T http://www.itu.int/ITU-T/ FIDIS http://www.fidis.net/ 文責 事務局 Identity Managementの審議状況 2005/09/20 平野 芳行 日本電気(株) 前回のAdhoc Meeting 日時：2005/4/14 16:00-17:30 場所：ON 103会議室 出席者：司会 M.D.Soete（Vice Cahir), Fumy(Chair)他２０名 米４，独１、ポーランド１，ベルギー２、韓国１、南アフリカ１，日４ （苗村、山田、古屋、平野） 配付資料 ・agenda N4557 ・各国からの寄書 N4377（独）、N4448（ベルギー）、N4458（米） ・ラポータのノミネーション N4391 ・NP案の書式は米国文書のANNEXにあり。 議事概要(1) １．P.GriffinからStudy periodの報告があった。 米、独、ベルギーの３カ国からの寄書 ２．各国からの寄書の説明 ・独 K.Rannenbergがプレゼン N4377で、frameworkを提言。Liberty Allianceなどprivacyなどを含めた 発表があった。 ・US P.Griffinがプレゼン N4458の資料。INCITS-359 RBAC、the Open Groupなどプロトコルより の提案。 NPIに関する文書案も提出された。 ・ベルギー C.Stenuitが説明 N4448について、ユーザーのアクセスコントロールは必要。 議事概要(2) ３．ラポータへのノミネート ・独 Dr. Kai Rannenberg（Mobile Commerce & Multilateral Security Goethe University Frankfurt） ・The U.S. Mr. Phillip Griffin ・寄書を出したベルギーを含めて３名でラポータをつとめることにした。 （Soeteの配慮のよう） ４．今後の予定に関する議論。 ・今回はラポータが共同して、IDMのframeworkのposition paper とNPI文 書を 作成。来週のPLENARYに提出することになった。 ・1stのWDを準備し、８月末までにNBのコメント募集をする。 ・１１月のＫＬ会議に合わせて、別途Adhoc Groupをやることが話された。 所感 独と米とでは、かなり離れた内容の提案であ るように思うが、Scopeがきちっとされないま ま、NPIの提案が合意されたような形である。 来週のPlenaryの提出案を待ちたい。 NP提案 • • • • • “ A Framework for identity management” 投票結果 ２４カ国中２３カ国がQ1 ｙｅｓ. 24国ともPJ承認 審議参加１１カ国。 Editorには、ベルギー（C.Stenuit）、独 (K.Rannenberg)。 • 寄書はドイツから。 http://www.fidis.net/のもの。 • さらに、米から追加の予定。 モスクワ会議（2007/05)報告 WG5結果報告 ●ISO/IEC24760：Framework for identity management （佐藤、平野） コメント処理は100程度で、Editor’s noteに対応して 提出された追加文章を多く取り込んでいるため、再度 2ndWDを作成し、コメント募集することになった。 ●ISO/IEC29100：Privacy Framework（佐藤、山田、 平野） コメント処理50個程度を行った。これも再度2ndWD を作成することになった。 ●ISO/IEC29101：Privacy Reference Architecture 寄書を募集したが、提出がなく再度募集を行うことに なった。 ISO/IEC JTC 1/SC27 N 5869 Japanese NB prepared this contribution in order to improve the figure proposed by Australian NB at AU comment No.34 in SC27 N 5662. How to use this slide is; to review if the lifecycle is well designed and defined by knowing about the things happened behind the lifecycle. We already understood that the following things from the meeting in Russia. -There is a concept of distinguish between create and activate. -“Suspend” is an optional stage of the lifecycle. -“Archive” is an optional stage of the lifecycle. By looking at and revising this slide, it is expected that more than those things are found out. Although this is not our final proposal for the figure and it is not confident one, Japanese NB hopes this slide helps all NBs to consider more about the lifecycle of identity and improve the figure for it at the next meeting. ISO/IEC JTC 1/SC27 N 5869 NOTE: Left side part is drawn just for understanding about activities. It is disappeared finally. Technical Activities to be taken Lifecycle of Identity State of Identification? Create Create as inactive Establish Created Established Activate Mark as active Activated something like Mark as inactive (OPTIONAL) Suspend Inactivate Inactivated Repository Not established Mark as active Suspended Reactivate Terminate Terminate??? (Junction) Mark as not-reusable Delete Terminated (OPTIONAL) Archive Maintained? Deleted (OPTIONAL) Trail Archived ISO/IEC JTC 1/SC27 N 5869 What we can learn from that slide in the previous page are Q1: What terminology is good for “sｔate”? (ex. “Identification” is temporally used here.) NOTE: Left side part is drawn just for understanding about activities. It is disappeared finally. Technical Activities to be taken State of Identification? Create as inactive Create Lifecycle of Identity Not established Establish Created Established Q2: Is “Suspended” a stage of the lifecycle even it is an optional one? Is it enough that “OPTIONAL” was added? Activate Mark as active Activated something like Mark as inactive Inactivate Inactivated Repository Mark as active Suspended Q3: What is good word for this action? (ex. Is “Terminate” good one? Reactivate Terminate??? (Junction) Mark as not-reusable Delete Maintained? (OPTIONAL) Trail (OPTIONAL) Suspend Deleted Terminate Terminated (OPTIONAL) Archive Q4: If “Archived” is an optional stage, then do not we need any mandatory stage? Therefore, “Terminated” is tried to be added between “Suspended” and “Archived”. Right? Archived Q5: Is “Archived” a stage of the lifecycle as one time matter? It may be a set of “actions” taken whenever any kinds of changes to identity were occurred. ISO/IEC JTC 1/SC27 N 5869 What we can learn from that slide in the previous page are Activated Inactivated something like Repository Terminate??? (Junction) Mark as not-reusable Delete Maintained? Deleted (OPTIONAL) Trail Q6: The decision is depending on organization’s identity management policy. If the identification after terminated may be reused for other identity in the future, then it can be “deleted” from something of repository. Otherwise, it must be maintained within someplace in order to avoid reuse of it. The reuse of identification should not be recommended in the identity management guideline, but since this document is the “framework” of it, this of “reuse” needs to be assumed and explained. ISO/IEC JTC 1/SC27 N 5869 What we can learn from that slide in the previous page are Lifecycle of Identity Create Option 1 Created Not established Establish Established Activate Activated Inactivate Inactivated Reactivate Option 2 (OPTIONAL) Suspend Suspended Q7: When does the stage of “Established” start from? Is it started from the time of creating the identification (Option 1)? There may be another idea that it starts from the time when identification was activated (Option 2)? In the other point of view, Is “Establish” is a set of “Create and Activate” (it makes “Established” Option 2)? Or “Establish” is just for “Create” (it makes “Established” Option 1)? ISO/IEC JTC 1/SC27 N 5869 Q8: Although the left side of the picture is gone finally, Is this Although the left useful sidetoofknow the picture about the is gone difference finally, Is this between useful identity to knowand about the identification difference between or something? identity and identification or something? and more… NOTE: Left side part is drawn just for understanding about activities. It is disappeared finally. Technical Activities to be taken State of Identification? Create as inactive Create Lifecycle of Identity Not established Establish Created Established Activate Mark as active Activated something like Mark as inactive Inactivate Inactivated Repository Mark as active Suspended Reactivate Terminate??? (Junction) Mark as not-reusable Delete Maintained? Deleted (OPTIONAL) Trail (OPTIONAL) Suspend Terminate Terminated (OPTIONAL) Archive Q9: There terminologies can be defined and used within the framework document and other documents regarding to identity management which may be developed in the future also. Archived Q10: We may need the left side of the figure as an entire picture of the identity management separately from the lifecycle. ISO/IEC JTC 1/SC27 N 5869 and more… Q11: The left side of the figure is being drawn by assuming implementation of something like ID and password. However, if certification based technology is assumed, then other kind of picture might be drawn. It may be interested in drawing some kinds of implementation technologies of identity management. NOTE: Left side part is drawn just for understanding about activities. It is disappeared finally. Technical Activities to be taken State of Identification? Create as inactive Create Lifecycle of Identity Not established Establish Created Established Activate Mark as active Activated something like Mark as inactive Inactivate Inactivated Repository Mark as active Reactivate Terminate??? (Junction) Mark as not-reusable Delete Maintained? (OPTIONAL) Trail (OPTIONAL) Suspend Suspended Deleted Terminate Terminated (OPTIONAL) Archive Archived 附属資料 B. リバティアライアンスにおけるアイデンティティ管理技術標準化活動 附属資料 B では、リバティアライアンスの活動を中心として見たアイデンティティ管理技術の標準化 動向を解説する。スライド 6～スライド 9 では、アイデンティティ管理を巡る代表的な動きとして、 CardSpace、リバティアライアンス、openID の三つを挙げ、アイデンティティ情報提供者とサービス 提供者との連携という観点からこの三つの関連を述べる。スライド 10～スライド 36 では、リバティ アライアンスのアイデンティティ管理技術について説明する。スライド 37～スライド 51 では、リバ ティアライアンスのアイデンティティ管理技術の適用事例を説明している。スライド 52 以降では、 リバティアライアンスのアイデンティティ管理技術と他のアイデンティティ管理技術との連携につ いて説明している。まず、スライド 52～スライド 54 では CardSpace について説明している。スライ ド 55 とスライド 56 で、openID について説明している。スライド 57 とスライド 58 で、この三つのア イデンティティ管理技術の連携機構の実現を目的とする Concordia プロジェクトを紹介する。スライ ド 59 からスライド 61 までに結論が示されている。 附属資料 B 目次 1) トップページ 2) 裸のセキュリティ表示 3) 高まるアイデンティティ管理の重要性 4) アイデンティティ管理とは？ 5) ネットの競争軸はアイデンティティへ 6) アイデンティティ管理をめぐる 3 つの動き 7) 3 つのアイデンティティ管理モデル 8) 識別子の体系 9) ３つの技術と関連団体 10) Federated Identity Model:連携アイデンティティモデル 11) リバティアライアンス 12) Liberty Alliance の主な参加企業 13) リバティ・アライアンス組織体系 14) Liberty 仕様のアーキテクチャ概要 15) SAML(Security Assertion Markup Language)の変遷 16) リバティアライアンスにおけるアイデンティティライフサイクルの包括的サポート 17) アイデンティティ連携ライフサイクル 18) SAML v2.0: アイデンティティ連携技術仕様 Security Assertion Markup Language v2.0 19) 仮名を使ったアカウント連携 20) シングルサインオン 21) SSO のメッセージの流れ （アーティファクトプロファイル利用時） 22) シングルログアウト 23) ブラウザ以外への対応 24) Liberty Alliance、SAML 技術仕様の構成 25) 認証アサーション 26) 認証コンテキスト 27) SAMLv2.0 の機能 28) Liberty ID-WSF： 属性情報の安全な交換・利用 29) ID-WSF の機能 30) ID-WSF People Service 31) Liberty Advanced Client 32) ID 情報の配布・管理の仕組み 33) オフラインＳＳＯの仕組み 34) TM Minting シーケンス 35) Identity Governance Framework 36) Identity Assurance Framework 37) リバティ適合性試験 38) マーケット・トピック別の取り組み - Special Interest Groups 39) リバティ仕様と日本の個人情報保護法 40) 海外の具体的事例（B2E、 B2B、 B2C） 41) 海外での具体的事例（公共系） 42) 日本国内での具体的事例 43) 適用事例：マスターＩＤと gooID との連携 44) マスターＩＤ⇔gooID 連携のシステム構成 45) 参考：IDDY 2007 賞 46) 新たな適用分野：デジタル TV 47) 新たな適用分野： モバイル (3GPP GAA) 48) ３GPP GAA と Liberty Alliance 仕様の連携 49) NTT 研究開発の取組み SAML によるユーザセントリック型技術(SASSO) 50) NTT における研究開発の取組み認証連携プラットフォーム 51) ＮＴＴにおける研究開発の取り組み ODP(On Demand Pass)技術 52) CardSpace とは？ 53) “The Laws of Identity” 54) CardSpace の基本動作 55) OpenID 2.0 とは？ 56) OpenID 2.0 の認証機能の基本動作 57) Concordia プロジェクト 58) Concordia の利用シナリオ 59) まとめ 60) For more information c 61) 参考：ACM Workshop on Digital Identity Management 文責 事務局 アイデンティティ管理技術の最新動向 ～ Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅを中心に ～ 2007年12月13日 情報流通プラットフォーム研究所 高橋健司 1 NTT Copyrights 2007. All rights reserved. 裸のセキュリティ表示？ オンラインバンキング利用者についての実験結果 HTTPSの表示をなくしても、パスワードを入力 →100% さらに、サイト認証用画像を省いても、パスワー ドを入力 →92% さらに、セキュリティ警告画面を出しても、パス ワードを入力 →53% S. Schechter et al, “The Emperor's New Security Indicators,” Proc. IEEE Symp. Security and Privacy, 2007 2 高まるアイデンティティ管理の重要性 セキュリティ被害の深刻化、規制強化や、個人向け オンラインサービスの複雑化・分散化のトレンドを背 景に、「アイデンティティ管理」の重要度が高まる Ｍ＆Ａ 内部統制 監査 証跡 個人情報保護法 プライバシ 規制による 認証強化 米国FFIEC 金融庁他「情報セキュ リティに関する検討会」 従業員／顧客 情報の統合 アイデンティティ 管理 ＩＤ盗難 ユーザ情報分散管理 システム広域分散化 情報漏洩 Phishing (米＄64億被害額, DoJ 2006） アウトソーシング SNS等 パーソナル化 Web2.0 パスワード管理 コスト増大 (年200ドル Forrester 2002) 3 アイデンティティ管理とは？ アイデンティティとは？ ある個人やグループ、組織・企業を特定する情報の総体 個人の場合：氏名、住所、生年月日、アカウント名、免許証、保険証、 クレジットカード番号、信用情報、所属、役職、人間関係など。 企業の場合：企業名、代表者名、所在地、ロゴ、定款、格付け情報、 東証コード等 アイデンティティ管理とは？ 様々なサービスやシステム上で、アイデンティティに関する 情報を、安心安全・簡単に活用すること 多要素認証 属性情報交換 シングルサインオン ＩＤ連携 ユーザセントリック アクセス認可 匿名化 ＩＤライフサイクル管理 フィッシング対策 4 ネットの競争軸はアイデンティティへ •現在、PC・インターネットの世界では、広告ビジネス等のユーザのアテ ンションの奪い合いが主戦場となり、Googleがリーダとして君臨 •2010年代にはユーザがネット上の自分の存在を生かし主体的にアク ションを起こす「アイデンティティ」の時代が到来する？ •アテンションエコノミ（ユーザ受身）⇔アイデンティティ（ユーザ主導） • • • • 80年代： 90年代： 00年代： 10年代： 競争軸 OS ブラウザ アテンション アイデンティティ プレーヤ MS ⇔ Apple MS ⇔ Netscape Google ⇔ MS他 ？？ マス向け：ブログ、SNS, Wikipedia, VRM, Second Life, Twitter… 法人・公共向け： 内部統制、個人情報保護法、テロ対策… 5 アイデンティティ管理をめぐる3つの動き CardSpace 「カード」のメタファでアイデンティティ情報を管理する技術の総称 IE7に標準装備。オープンソース版もある 主なプレーヤ： Microsoft, Novell, IBM他 Liberty Alliance/SAML 「連携」モデルに基づくアイデンティティ管理の技術仕様 主なプレーヤ： Liberty Alliance参加メンバ(Oracle, Sun, GSA, Citigroup, NEC, NHK, NTT他） OpenID URLをID(個人識別子)として用いるｱｲﾃﾞﾝﾃｨﾃｨ管理技術仕様 主なプレーヤ： OpenID Foundation参加メンバ（Microsoft, Verisign, IBM, Yahoo!, Google, Six Apart等） 6 3つのアイデンティティ管理モデル トラスト SP: サービス提供者 IdP: アイデンティティ情報提供者 データ 連携モデル 独立モデル SP IdP/SP IdP ユーザセントリックモデル SP SP SP SP IdP １アイデンティティ→１ＳＰ １アイデンティティ→多ＳＰ （IdP/ＳＰ間の事前連携あり） LA/SAML 多アイデンティティ→多SP (IdP/SP間の事前連携なし） OpenID, CardSpace, LA/SAML 識別子の体系 User Centric Identity系 IdPとＳＰで共通のグローバル識別子を利用。ユーザ自身がＳＰ 毎に識別子を使い分ける等して、名寄せの危険性を回避。 Address-based Identity URIやXRI(*)等のインターネット上のアドレスを識別子として用いる。 例： Open ID (*) eXtensible Resource Identifier Card-based Identity 個人情報の各まとまり（会社用、学校用等）を「カード」として整理分 類し、識別子として用いる。 例： CardSpace Federated Identity系 ＳＰ毎に異なる識別子をIdPの識別子と仮名連携。名寄せの危険 性回避策を織り込んだ体系。識別子自身のフォーマットは特に 規定しない。 例: SAML2.0 8 7 ３つの技術と関連団体 OpenID Foundation オープン ソース Bandit Higgins 放送系 OpenID ETSI/ TV-Anytime Open Liberty Liberty Alliance 3GPP テレコム系 OpenSSO Concordia Project SAML2.0を勧告化 (X.1141) ITU-T OSIS Card Space (含 SAML) OMA Inernet 2 OATH 教育 認証 OASIS XML 9 Federated Identity Model: 連携アイデンティティモデル アイデンティティ集約型モデル 単一レポジトリにおけるアイ デンティティ情報 の管理 集中コントロール 一点の障害がシステム全体 に波及 類似システムのみ連携 Central Provider アイデンティティ連携型モデル 様々なロケーションでのアイデ ンティティ情報の管理 非集中コントロール 一点の障害によってシステムが 機能しなくなることは無い 類似 / 異種システムと連携 In su ran ce Ban k Travel Airlin e Yo u ISP 10 リバティアライアンス ビジネス・アライアンスとして2001年9月に設立。アイデンティティ 管理およびサービスのための公開標準仕様確立を目指す 世界各国から150以上のメンバーが参加 政府組織・産業界・消費者団体等 取組内容 様々なネットワークやデバイスに対応した公開標準仕様、ビジネスガイドラ イン、規制対応に関する白書等の提供 分散的な認証・認可を実現する、オープンかつセキュアな技術標準の提供 個人または企業が、安全に、かつ、柔軟に個人情報を管理する事を実現 安全かつ利便性の高いサービス連携のための技術仕様を提供 The purpose of the Liberty Alliance is to realize the vision of a networked world in which individuals, businesses, governments and other organizations can more easily conduct identity-enabled transactions while protecting the privacy of individuals (consumers, citizens, employees) and security of identity information by fostering a ubiquitous, interoperable, privacy-respecting identity layer for the Internet. 11 Liberty Allianceの主な参加企業 Board members Sponsor members 12 リバティ・アライアンス組織体系 Management Board Business Marketing Technology Public Policy Strong AuthN Identity Assurance Service Contact Book LDAP CSM BIP ID-Theft Japan Geo Location SIG(Special Interest Group) Health IDM Payment eGov 13 Liberty仕様のアーキテクチャ概要 リバティ・アイデンティティ 連携フレームワーク (ID-FF/SAML) アイデンティティ／アカウントリ ンケージ、シングルサインオ ン、およびセッション管理等の 特徴を持つアイデンティティ連 携と管理が可能 リバティ・アイデンティティサービス・インターフェース 仕様(ID-SIS) パーソナルプロファイルサービス、アラートサービス、カレン ダーサービス、ウォレットサービス、コンタクトサービス、位置情 報サービス、プレゼンスサービス等のアイデンティティサービス が可能 リバティ・アイデンティティWebサービス・ フレームワーク(ID-WSF) 相互接続可能なアイデンティティサービス、許可ベースの属性 共有、アイデンティティサービス記述、ディスカバリ、および関 係するセキュリティプロファイルを作成・構築するためのフレー ムワークを提供 リバティ仕様は既存の標準仕様に準拠 (SAML, SOAP, WSS, XML, etc.) 14 SAML(Security Assertion Markup Language)の変遷 (Source: Liberty Alliance Project) 15 リバティアライアンスにおける アイデンティティライフサイクルの包括的サポート Advanced Client (端末系） ID Provisioning （サーバ系) 変更 作成 削除 SAML2.0 相 互 運 用 履歴 性 認 定 属性 共有 アクセス 制御 ID Governance 連携 SSO ID-WSF People Service 認証 Identity Assurance EG 16 アイデンティティ連携ライフサイクル ユーザの立場から見たアイデンティティ連携の流れ １セッション アカウント 連携 シングル サインオン サービス 利用 シングル ログアウト 主体者の同意 1. 2. 3. 4. 5. 6. 7. 連携解除 主体者の同意 ユーザがIdPとSPにそれぞれアカウントを開設。 ユーザが上記両アカウントを連携することを同意。 IdPとSPがアカウントの連携を確立。 ユーザがSSOし、SPのサービスを利用。 ユーザがSPのサービス利用終了時に、ログアウト。 その後、ユーザが上記アカウント連携の解除を要求。 IdPとSP間の連携が解除。 (Source: Liberty Alliance Project 2006) 17 SAML v2.0: アイデンティティ連携技術仕様 Security Assertion Markup Language v2.0 認証情報を安全に送付し、アカウント連携とSSO（シングルサ インオン）を実現 標準化団体(Liberty Alliance, OASIS)で仕様化され、公開中 IdP (Identity Provider、認証業者） アカウント連携 ユーザA@idp IdPへアクセスし、 初期認証 連携 ユーザA@sp1 SP1 ユーザの同意に基づき、独立に管理され るアカウントを関連付け ユーザA@sp2 SP2 SP (Service Provider、サービス業者） サインオン ユーザA シングルサインオン IdPへの一度の認証手続きだけで、 複数のSPのサービスが利用可能 (Source: Liberty Alliance Project 2006) 18 仮名を使ったアカウント連携 ユーザに関して、IdPとSP間でのみ有効で、ユーザ個人を 特定不能な仮名の利用 グローバルIDの必要性を排除、実際のアカウント名の流出を防止 名寄せによるプライバシー情報漏洩を防止 SP1 IdP アカウント: john@idp SP1 アカウント: Lennon1@sp1 IdP 連携アカウント 連携 仮名： pqrs ドメイン： idp.com 名前： abcd 連携アカウント 仮名： abcd ドメイン： sp1.com 名前： pqrs 連携 仮名： efgh ドメイン： sp2.com 名前： wxyz SP2 アカウント: Lennon2@sp2 連携アカウント SP2 仮名： wxyz ドメイン： idp.com 名前： efgh (Source: Liberty Alliance Project 2006) 19 シングルサインオン IDPで一度認証されれば、再度サインオンなしで複数のサービスを利用 認証結果情報(assertion)の受け渡しには様々な方法を利用可能 Assertionに属性情報や認可情報も含むことが可能 サービス提供者(SP) IDPでの認証情報を信頼 してユーザにサービスを 提供する ⑤Assertionを検証 ⑥サービス提供 ①サービス要求 ID提供者(IdP) ④IDPでの認証情報を含む Assertion返却 ②認証要求 ③IDPへログイン ユーザ ⑦サービス要求/サービス提供 (①から⑥と同様の動作。ただ しIDPへのログインは不要) サービス提供者(SP) ログイン操作はIDPに対して のみ一度だけ行えばよい 20 SSOのメッセージの流れ （アーティファクトプロファイル利用時） 認証アサーションをブラウザ経由で渡さないようにするため に、ＳＰは、まず引き換え券（アーティファクト）を取得して、そ の引き換えに認証アサーションを取得する。 ユーザのアクセス帯域が小さい場合など IdP (3) アーティファクトと アサーションの作成 (0) 初期認証 (2) 認証要求 (5) 認証アサーション 要求 （SOAP） アーティファクト (4) アーティファクトの 返送 リダイレクト 認証アサーション アーティファクト (6)認証アサーション発行 （SOAP） (4) アーティファクトの返送 アーティファクト ユーザ SP (2） 認証要求 (1) SPのサービスにアクセス要求 (7) 認証アサーション確認 (8) サービスの提供 (アーティファクト： アサーション取得のための引き換え券） (Source: Liberty Alliance Project 2006) 21 シングルログアウト シングルサインオンによってログインしたアカウントは、一回のシン グルログアウト(SLO:Single Logout)要求を行うことにより、全ての SPからログアウトすることができる。ユーザは個々のSPごとにログア ウトする必要がない。 ⑧ログアウト処理 サービス提供者 (SP) ②SLO要求 ①SLO要求 ⑥ログアウト処理 ⑨処理結果の通知 ⑦SLO応答 各サイトごとに ログアウトする必要なし ユーザ ID提供者 (IdP) ⑤SLO応答 ④ログアウト処理 ③SLO要求 すべてのSPにシングル ログアウト要求が届く サービス提供者 (SP) 22 ブラウザ以外への対応 Enhanced Client/Proxy SSO ブラウザ以外のクライアント（Enhanced Client)を利用する場合や、直接プロ バイダと通信できない場合の代替手段（Enhanced Proxy)を提供 Enhanced Client 高機能のクライアントを用いて、IdPやSPとのメッセージのやりとりを直接行 う。クライアント内に蓄積した情報を送るなどが可能になる。 Enhanced Proxy プロキシとしてクライアントのIDP/SP間の通信を介在し、シングルサインオンを 実現。クライアントの機能が貧弱（例:HTTP Redirectに非対応)でユーザが直 接プロバイダと通信できない場合などに用いることができる。 ① Enhanced Proxy経由でSPへ サービス要求 SP ②ユーザの代わりに Enhanced シングルサインオン Proxy を実行 ユーザ ③Enhanced Proxy経 由でSPからサービス IDP 適用例：移動 を提供 網用ゲート ウェイ 23 Liberty Alliance,SAML技術仕様の構成 様々な用途や利用環境に対応できるように、構 成要素を選択し組み合わせて用いることが可能 Profiles ProtocolsとBindingsの組み合わせによる各種機能の実現方法 (WebSSO, SLO, ECP等) Bindings Protocolsで定義されているメッセージの通信方式 (HTTP Artifact, HTTP Redirect, PAOS等) Metadata プロバイダの定義情報 Protocols Assertionを取得、送信するための、 Request/Responseのペア Assertions AuthnContext 認証方式 認証、属性、認可の情報 24 認証アサーション 認証アサーション アサーションID 発行者 発行日時(タイムスタンプ) 有効期間 アサーションを利用できるSP 認証に関する記述 (Assertion Statement) 認証コンテキスト 認証手段, 本人確認経緯、ｸﾚﾃﾞﾝｼｬﾙ保護手段等 ユーザ情報へのリファレンス IdPやSPにおける仮名 SAML (Security Assertion Markup Language) を用いて 表現。 IdPとSP間でのみ有 効な仮名を使って ユーザ個人を参照 認証結果以外 (IdP→SPの場合)に も、認証要求の条件 （SP→IdP)も規定で きる その他（タイムスタンプ等） アサーションの電子署名 (Source: Liberty Alliance Project 2006) 25 認証コンテキスト Authentication Context 認証コンテキストは、IdPからSPに伝える認証結果の背景 情報。ＳＰは、これを認証結果の確かさの判断材料に使う。 以下の内容を記述することができる 本人確認（Identification) – ユーザ情報登録時の本人確 認手段に関する記述 (例： 対面で免許証を確認） 技術的保護 (Technical Protection) – ユーザ認証のため の秘密（パスワードや秘密鍵等）がどのように保護されて いたかの記述 (例： ICカードに格納） 運用上の保護 (Operational Protection) – IdP側でのセ キュリティ運用に関する記述 (例：セキュリティ監査） 認証手段 (Authentication Method) – IdPにおけるユーザ の（初期)認証手段に関する記述 (例：パスワード、PKI等） 適用する契約 (Governing Agreements) – 認証に適用され る契約に関する記述 (例：保証責任の範囲) 26 SAMLv2.0 の機能 セキュリティとプライバシーのバランスを考慮し、策定 機能 内容 シングルサインオンと連携 ユーザのSPとIdPで管理されたアカウントの関連を確立する。また、そ の連携が確立後、一度のIdPへのサインオンだけで、SP のサイトが 利用可。匿名アクセス機能もあり。 名前の識別子登録 SPとIdP が主体者に関して互いに交信する際に利用する仮名の識別 子(Name Identifier)を登録、変更する仕組み。 連携の解除 SPとIdPが、あるユーザに関して、一旦確立したアイデンティティ連携 を解除する仕組み。 シングルログアウト IdPによって認証された，ある主体者に関する全てのセッションを一括 してログアウトを行う仕組み． IdPの照会 SPとIdPが、どのIdPをユーザが利用しているのかを検索する仕組み。 名前の識別子マッピング あるユーザに関するIdPとSP間で交換される仮名を、他のSPが入手 する仕組み。 名前の識別子の暗号化 SPとIdP間で交換されるユーザの名前識別子情報を暗号化する仕組 み。 (Source: Liberty Alliance Project 2006) 27 Liberty ID-WSF： 属性情報の安全な交換・利用 サーバに登録されている属性情報をサービス業者間で直接交換し、 ユーザのサービス登録や利用時の手間を省いたり、サービスのパー ソナライズを図る。 業界団体(Liberty Alliance）で仕様化され、公開中 IdP（認証業者） （0） 個人情報Webサービスと 公開対象を登録 個人情報 (2) ユーザ情報への アクセス情報検索要求 (1) シングルサインオンし、 サービス要求 (3) ユーザ情報への アクセス情報送付 ユーザ情報 (4) ユーザ情報 要求 (6) ユーザ情報提供 (7) サービス提供 SP（サービス業者） ユーザ AP（Attribute Provider, 属性提供業者） 氏名 住所 銀行口座番号 クレジットカード番号 … (5) SPへのユーザ情報提供の許可（同意）を取得 (Source: Liberty Alliance Project 2006) 28 ID-WSF の機能 アイデンティティサービス（ユーザ情報公開サービス）の登 録・検索 IDサービスは、IdPで登録、管理され、不特定多数への公開を防止 認証へのインターフェース ID-FFのような SSOを利用し、ID-WSFを発動。 SOAPによるSASL (Simple Authentication & Security Layer) ベー スの認証サービス仕様も規定。 データへの統一的なアクセスフォーマット ユーザ情報へアクセスするためのプロトコルとスキーマを規定。 オンデマンドなユーザ許可取得 ユーザからオンデマンドで、情報提供に関する許可を取得可能。 ユーザをプライバシー侵害から保護。 アイデンティティサービスへのアクセス ユーザ情報へのアクセスは、アイデンティティをキーとしてサービス 呼び出しを行う機構を提供。アクセス要求者の認証を確実に行うの で、厳密かつ柔軟なアクセス制御が可能。 変更の通知 ユーザ情報の変更を、事前に登録しておいたサービスに自動通知 (Source: Liberty Alliance Project 2006) する 29 ID-WSF People Service ユーザのグループ情報（家族メンバか否か等）を管理・活用するため のプロトコルを規定 Liberty Allianceで仕様化し、公開中 People Serviceを利用 して、グループ 情報を参照/取 得して、活用。 グループ情報 例： 住所録、プッ シュトークのグ ループ、 バディリスト等 グループ情報 写真共有サービスプロバイダ 住所録の家族グループと 写真を共有しよう グループ情報 住所録サービスプロバイダ ブログサービスプロバイダ 住所録の家族グループにだ けブログを公開しよう 30 Liberty Advanced Client 端末上のTrusted Module (SIMカード、ＩＣカード、ＴＰＭ等）内の ユーザ情報を、様々なサービス提供者が活用するための仕組み (代理)ＩＤ管理機能を端末上に配備し、ID情報の配布・管理、オフラインSSO, オフライン属性交換などを実現 仕様公開中 端末 ID提供者 (IdP) 権限委譲 Trusted Module (認証情報, 属性情報等) (代理) ＩＤ 管理 機能 ・IdP機能 サービス 提供者 ・AP機能 … 権限委譲 同期 属性提供者 (AP) 31 ＩＤ情報の配布・管理の仕組み 端末上の格納モジュール（TPM, ICカード等）に安全にＩＤ情報 （クレデンシャル等）を配布・管理（チェック・変更・削除）できる モジュール管理者（ＩＣカード発行者等）およびＩＤ情報管理者 （ショッピングサイト等）との役割分担を実現 Browser +plug-in 端末 3.ハンドル （仕様範囲外） クライアント アプリケーション ReqS (ID情報提供者） （Requesting Service）ex. IdP 4. ハンドル 1. ＩＤ情報 Provisioned Module Manager PMM 7. ＩＤ情報を インストール 2. ハンドル 5. ハンドル 6. ＩＤ情報 （クレデンシャル、プログラム等） 8. 状態通知 PM ProvS (モジュール管理者） （Provisioning Service） Provisioned Module（TPM, ICカード、SIM等） 32 オフラインＳＳＯの仕組み IdPがオフラインでもSSO可能 端末が認証アサーションの発行権限を委譲されて、利用す る仕組みを規定 利用対象のＳＰ等を制限 Minting Assertion 権限委譲 （トークン発行権限委譲証明書） MING IDP （Identity Provider） TM サービス利用 端末 MED MING Trusted Module （セキュアな論理モジュール ソフトウェアでも可） Minted Assertion SP （認証アサーション） （Service Provider） 33 TM Minting シーケンス 権限委譲 サービス利用 TM IDP TM SP サービス要求 認証 トークン要求 鍵ペア生成 公開鍵 MED生成 MNG生成 MNG（Minting Assertion） MED（Minted Assertion） サービス Minting Assertion Minted Assertion 対象となるSPのID 対象となるSPのID TMの公開鍵 Minting Assertion IDPの署名 TMの署名 34 Identity Governance Framework アイデンティティ情報の提供側と利用側でポリシーをやりとりするための枠組み CARML: 利用側が必要なＩＤ情報と利用目的や方法を記述 AAPML：提供側がＩＤ情報の利用に関する条件を記述 AAPML (Attribute Authority Policy Markup Language) CARML (Client Application Requirements Markup Language) (Source: “An Overview of the Id Governance 35 Framework”, Liberty Alliance 2007) Identity Assurance Framework アイデンティティ情報の確かさをレベル分けし、各レベルを達成する ための手順（運用プロセス）を既定 •米国連邦政府一般調達庁や銀行等が積極的に推進 •リバティアライアンスで認定プログラムを実施する予定 Assurance Level: アイデンティティ情報の確からしさについて、4つのレベルを定義 レベル１： 全く信頼おけない 例：単純なパスワードによる無料ウェブサイトへの登録 レベル２： ある程度の信頼をおける 例： ＰＣに保存した証明書による認証で、ウェブ上で生命保険の住所を変更する レベル３： 高い信頼をおける 例： ＰＣに保存した証明書とパスワードによる認証で、ウェブ上で弁理士が特許を出願 レベル４： 非常に高い信頼をおける 例： ＩＣカードとパスワードによる認証で、警察官が犯罪情報にアクセスする Service Assurance Criteria : サービス提供者(IdP/SP)のアイデンティティ情報管 理において守るべき手順を上記の4レベル毎に以下の側面から規定 Credential Credential Credential Credential Credential Operating Environment Issuing Revocation Status Management Verification/Authentication 36 リバティ適合性試験 各企業が製品を持ち寄って、仕様への適合性と相互運用性 を検証する試験を実施。合格製品に対して認定ロゴを交付。 合格製品がすぐに利用可能な相互運用性を持ち、導入から 運用開始までの時間を短縮できる。 SAML 2.0 向け適合性試験も実施中。 米国連邦政府一般調達庁(GSA)が調達の必須条件に指定 37 マーケット・トピック別の取り組み - Special Interest Groups •メーリングリストや会合を通じて、マーケットやトピック別 に議論する場を提供 •誰でも（非会員でも）、参加可能 Health Identity Management SIG： 医療・ヘルスケア分野 ID Theft Prevention SIG: ID盗難の防止 Japan SIG： 日本における普及促進 http://wiki.projectliberty.org/index.php/JapanSIG eGovernment SIG: 電子政府分野 Identity Assurance SIG: アイデンティティ保証の検討 38 リバティ仕様と日本の個人情報保護法 個人情報取扱事業者の義務（第15条～第36条）の明記内容と リバティ仕様での取り組みの対応関係を整理。 個人情報保護法要件 リバティ・プライバシー勧告 リバティ仕様 0) 本人同意の原則 a) Notice（通知） b) Choice（選択） 本人同意に基づくアイデンティティ連携／シングルサインオン(ID-FF)や インタラクションサービス (ID-WSF)など 1) 利用目的の明示・順守 a) Notice（通知） e) Relevance（妥当性） f) Timeliness（適時性） 用途指示子(Usage Directives, ID-WSF)など 2) 不正取得の禁止 - - 3) 適正管理 d) Quality（品質） h) Security（セキュリティ） 暗号鍵サイズの推奨や通信トランスポートにおけるSSL/TLS使用の推奨、 Security Profiles(ID-WSF)など 4) 授受制限 直接対応する項目はないため、本人同意 の原則に基づき対応 0) 本人同意の原則や1)利用目的の明示・順守の項を参照 5) 情報公開 a) Notice（通知） - 6) 本人アクセスの提供 c) Principal Access to PII（主体者による個 人識別情報へのアクセス） - 7) 苦情処理 g) Complaint Resolution（クレーム解決） - 8) 行政機関への対応 - - リバティ技術の採用は個人情報保護法と干渉しない。 リバティ技術の採用だけでは個人情報保護法を充足しない。 リバティ技術の採用により個人情報保護を強化できる。 39 海外の具体的事例（B2E, B2B, B2C） 企業内・企業間システム Fidelity Investments, American Express, GM, Intel, HP, Sun, Star Alliance 従業員向けに、企業内およびパートナー企業との業務効率化のための ポータルを提供。顧客向けのサービスへの展開も検討中。 モバイル＆テレコム事業者 Vodafone, Orange/France Telecom, T-Online, Telefonica Moviles（南米）, TeliaSonera/Telenor（北欧）, Bluewin(Swiss Telecom) 外部サービス事業者連携や自社内のオペレーションコスト削減 T-Online（独テレコムの小会社）： 1200万のISPユーザに対し、SSO、アグリゲーション、個人情報管理、年齢証 明サービスを実現。 Nokia 主力の携帯電話シリーズにリバティアライアンス標準対応のOSを組み込 んで発売中 AOL 外部アプリケーション連携のためのプラットフォームとして導入。例えば、 インターネットラジオサービス(AOL Radio)の個人カスタマイズ機能に適用 40 海外での具体的事例（公共系） 英国：各種電子政府システムへのシングルサインオン（SSO）を 実現。登録済IDは800万。 → 電子政府の各サイトへの国民の誘導と、各サイトでのユーザ登録シ ステムとの連携とを狙う。 米国：EduTechシステムによりNY州の公立学校（約７００校）シ ステムのSSOを実現。教師1万人が登録済。 他にも、一般調達局(GSA)で政府システム間の連携標準技術として採用 フィンランド: オンライン納税や公的文書の一元管理 ノルウェー：個人情報にアクセスする政府系マイページポータル をLiberty対応に移行へ。 イタリア：運転免許更新サイトへのSSOを提供。 オーストリア：市民認証カードによるオンラインバンキングの ユーザ認証をLiberty対応に移行へ。 41 日本国内での具体的事例 NTT データ イントラネット(２万ＩＤ、２００システム）とグループ企業ネットワーク(３万２ 千ID、２０ ｼｽﾃﾑ)との連携によるシングルサインオン JAL ONLINE と出張旅費申請システムとの連携によるシングルサイン オン NTT コミュニケーションズ シングルサインオンサービス（マスターＩＤ）をＯＣＮユーザに提供中。 NHK NTTと共同で、サーバ型放送向けのＳＳＯを共同研究。 公共系 経産省、NiCT等の研究開発プロジェクトにおけるＳＳＯに利用。 コンビニで源泉徴収などが印刷できるサービス実験を実施 EduMart (G(B)toC) 総務省実証実験。教育コンテンツの流通システムへのシングルサインオン 42 適用事例：マスターＩＤとgooIDとの連携 ＮＴＴコミュニケーションズ ＮＴＴレゾナント 43 マスターＩＤ⇔gooID連携のシステム構成 44 参考：IDDY 2007賞 ＮＺ政府 GOAAMS (Government Online Attribute Assertion Meta System)という 政府保証の属性情報をＳＡＭＬで提供 （将来的にはID-WSFへの移行も検討中） Reardon Commerce 個人や企業ががオンラインサービスを探し料金を支払う場合の支援サ ービス（Reardon Personal Assistant）を提供。シングルサインオン機能を ＳＡＭLで実現。一種のSaaS。 約600社で50万人以上が利用。利用対象のSaaSは137000社。 eBIZmobility OneTouch online purchasingという料金重畳サービスをSaaS的に提供 移動網、固定網、ＩＳＰのアカウントにデジタルコンテンツの代金を重畳できる MySpaceやMTVが利用 アカウントリンキングにＳＡＭＬを利用 NTT SASSO 携帯電話上にIdPを実現 45 新たな適用分野：デジタルTV 多様な端末から多様なコンテンツとサービスへ の簡単アクセス（シングルサインオン） プライバシを尊重した視聴属性情報の活用 放送形態の多様 化 ﾃﾞｼﾞﾀﾙ放送 地デジ ⇒Liberty Alliance, OASISで標準化中 ⇒Liberty Alliance, ETSI, ARIBで標準化済 放送と通信の連携 ユーザ IP放送 ﾜﾝｾｸﾞ 情報 VODｻｰﾋﾞｽ ユーザ 情報 Tコマース 視聴属性情報 連携型ID管理 ユーザ 情報 通信ｻｰﾋﾞｽ ユーザ 情報 シングルサインオン ﾃﾞｼﾞﾀﾙTV DVR 携帯ｹﾞｰﾑ パソコン 携帯電話 視聴端末の多様化 （双方向性、コンテンツ共有、ユビキタス） 車載機器 46 新たな適用分野： モバイル (3GPP GAA) General Authentication Architecture •加入者情報をベースに、外部アプリケーション用の証明書を生成 •3GPP Release 8で仕様策定中(TS 33.220, TS 33.221) AV: AUTN,RAND, XRES,IK,CK 相互認証後、BSFは、NAF の求めに応じ、加入者プロ ファイルとトランザクションID。 セッションキーを送信 (Diameterプロトコル) Subscriber profile K,SQN Home Subscriber System HSSは、 BSFからの 求めに応じ、AV, 加入者プロファイルを 送信 (Diameterプロトコル) PKIポータル （アプリケーション用証明書を発行） Bootstrapping Server Functionality トランザクションID： セッションキーKS：（IK,CK) AKAによる相互認証とトランザク ションIDとセッションキーの配布 (HTTP Digest AKAプロトコル) Operator-controlled Network Application Functionality アプリケーションプロトコル であり、セッションキーによ る暗号通信路を構築する (HTTP Digestプロトコル) K,SQN User Equipment 47 AKA： Authentication and Key Agreement ３GPP GAAとLiberty Alliance仕様の連携 3GPP GAAのNAF⇔SAMLv2.0のIdPという対応付けにより、両者を連携させる 3GPP Rel.8で仕様検討中 (TR33.980) ３GPP GAAの仕組み SAML v2.0の仕組み 48 NTT研究開発の取組み SAMLによるユーザセントリック型技術(SASSO) 携帯電話上にSAML IdPを実装し強固認証をどこでも簡単に利用 ユーザセントリックで使い勝手のよいアーキテクチャ 大きな拡張性。携帯電話の持つ認証機能を汎用的に利用可能 例：NTTドコモの認証サービス(FirstPass) 高いユーザビリティ。携帯電話さえあれば、ＰＣ等にインストール不要 強化されたプライバシ。仮名ＩＤ連携による名寄せの防止。 強固な認証 (PKI, 生体認証, etc.) 携帯電話上 のIdP 中継サーバ SIM 一般の ブラウザ Service provider AuthnRequest SAML Assertion インストール、ケーブル不 要 SAML準拠 49 49 NTTにおける研究開発の取組み 認証連携プラットフォーム - アクセス回線識別情報の活用 - ｻｰﾋﾞｽ事業者毎の認証手段 とアクセス回線識別結果とを 組み合せて認証を強化 （川添他、「次世代ネットワークを利用したプラットフォーム・アプリケーション技術」、NTT技術ジャーナル、Vol.19, No. 4）より 50 ＮＴＴにおける研究開発の取り組み ODP(On Demand Pass)技術 認証結果をノマディック環境でも利用可能にする 利用毎、目的別に短寿命の証明書を発行し利用 既存の認証 システム 企業内ＮＷ 連携 ODP 発 行サーバ e IPs PN c-V ODP ODP 初期認証 (例：回線識結 果) ウェブアプリケーション PN SSL-V ODP 証明書 ストア 802.1x ODP 公衆無線ＬＡＮ ユーザ端末 AP 51 CardSpaceとは？ 「カード」を選択する感覚で、アイデンティティ情報を管理 Microsoft Vista／IE7に標準搭載のＩＤ管理機能 SAMLをセキュリティトークンとして利用することも可能 Web Services Security SAML Token Profile v 1.0 and REL Token Profile v1.0 <http://www.oasis-open.org/specs/index.php#wssprofilesv1.0> 関連仕様をOASIS等で標準化中 WS-SecureConversation, WS-SecurityPolicy, WS-Security, WS-Transaction, WS-Trust, WS-Federation オープンソース版も開発中 OSIS (Open Source Identity System) Bandit, Higgins, OpenSSO等 Firefoxでも利用可能 52 “The Laws of Identity” Kim Cameron氏（Microsoft社）が提唱。CardSpace設計 の指針 1. User control and consent 2. Minimal disclosure for a defined use 3. Justifiable parties 4. Directional identity 5. Pluralism of operators and technologies 6. Human integration 7. Consistent experience across contexts 53 CardSpaceの基本動作 CardSpace対応ブラウザ CardSpace対応ブラウザ ①サービス 要求 ② 認証 要求 ③認証手段 の選択 ⑥利用 開始 ⑤ユーザ情報 を提供 ④ ユーザ情報 を取得 SAML形式も可 (④, ⑤のやり取りでは、WS-Trust, WS-Policy, WS-Metadata Exchangeプロトコルを利用） Security Token Server (STS) (IdP相当。自前も可 (IdP相当。自前も可)) Relying Party (SP相当） (SP相当） 54 OpenID 2.0とは？ ＵＲＬをＩＤとして利用。個人が自分のホームページ を持ちアイデンティティ情報を管理 アドレスベースのＩＤを用いたアイデン ティティ管理技術。OSISで仕様を策定中。 OpenID 2.0 Versign, Sxip, JanRain, Sxi Apartらが提 案 OpenID1.1 OpenID Foundation LID Yadis Netmesh Co. OASIS XRI/i-names OASIS Sxip 属 性 交 換 機 能 ユーザがあるアドレスを保有しているこ とを証明することにより、認証を行う 「軽い」実装を目標に設計 SOAPを使わない。メッセージ形式も簡便 化 現在は、ブログやＳＮＳでの利用がメイン 複数のアドレスベース技術仕様 (OpenID1.1, Yadis, XRI等）を統合。 アドレスとして、URI及びXRIが利用可能。 Sxip Networks Co. XRI: eXtensible Resource Identifier シングルサインオン機能及び属性交換 機能を規定。 OpenID 2.0の認証機能の基本動作 ユーザ 求 要 用 利 ス 入 ビ )投 ー サ RL ① (U ID 用 ザ 利 ス ビ ー サ ⑧ ⑤認証要求 ー ユ ⑥認証 ② ⑦認証 結果通知 ④IdP発見 ③IdP発見要求 OpenID Provider (IdP相当) ユーザＩＤ対応サイト Relying Party (SP相当) 56 55 Concordiaプロジェクト 概要 リバティアライアンス(SAML, ID-WSF)、OpenID、CardSpace(WS-*)の相 互運用の実現を目指すプロジェクト。 参加メンバ 誰でも参加可能。リバティ・アライアンスとは独立した組織。 Microsoft, 米連邦政府一般調達庁、カナダ州政府機関、 Boeing, GM, AOL, Chevron, Internet 2, Sun Microsystems等 現在取り組んでいるユースケース OpenID SAML WS-Fed Cardspace WS-Trust ID-WSF OpenID - 4 1 2 1 1 SAML - - 1 4 1 1 WS-Fed - - - 1 - 1 Cardspace - - - - - 1 WS-Trust - - - - - 1 57 Concordia の利用シナリオ 異なるアイデンティティ管理仕様のプロトコル間の相互乗り入れ接続 Liberty ID-WSFと OpenIDの接続の一例 OpenIDベースでSSO（シングルサインオン）した後、Liberty ID-WSFベースで 個人属性情報を交換。 アイデンティティ・プロバイダ（OpenID対応） （認証局） (1) ユーザ認証 (5) ユーザの属性情報を要求・返信 (3) OpenID の認証情報を送付 ユーザ (2) サービスにアクセス要求 サービス・プロバイダ （Liberty ID-WSF対応） (4) 認証情報をもとにSSO ＊Liberty ID-WSF (Identity Web Service Framework): Libertyの個人情報交換のためのWebサービス仕様群 OpenID: URIベースのシンプルな認証と属性交換システム 58 まとめ アイデンティティ管理は、ＩＴ基盤の核であり、様々な利用 シーンで重要度が増している。 アイデンティティ管理では、ライフサイクル全体にわたる サポートが必要 アイデンティティ管理には、グローバルなスタンダード作 りが重要。代表的な存在として、以下の３つがあり、さら なる普及に向けて、統合化が進められている Liberty Alliance/SAML OpenID CardSpace 59 For more information… CardSpace http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx Concordia Project http://projectconcordia.org Liberty Alliance http://www.projectliberty.org http://wiki.projectliberty.org/index.php/JapanSIG OpenID http://openid.net OSIS http//osis.idcommons.net 60 参考：ACM Workshop on Digital Identity Management アイデンティティ管理に関する国際ワークショップ 今年で3回目 ACM CCSと併設 http://www2.pflab.ecl.ntt.co.jp/dim2007/ 61 附属資料 C. マイクロソフト社におけるアイデンティティ管理技術の展開 アイデンティティ管理技術が認識されるきっかけは、マイクロソフト社による PassportTM サービスの 提供であった。附属資料 C ではマイクロソフト社におけるアイデンティティ管理技術の展開が示され る。内容は、アイデンティティ関連技術相互の位置づけ、技術と製品、及びアイデンティティ管理の 将来像としての Identity MetaSystem である。技術と製品の項目では、Active Directory、Identity Lifecycle Manager、Active Directory Federation Services、Windows Card Space、Windows Live ID が取り上げられている。 文責 事務局 Microsoft भ Identity ঢ়৴ॸॡঀট४ ঐॖॡট९ইॺઙૄভ © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. ॔४ख़থॲ Identity ঢ়৴ૼभਜ਼઼હऐ ૼؚଲષ Active Directory Identity Lifecycle Manager Active Directory Federation Services Windows Card Space Windows Live ID Identity Metasystem 1 Identity ঢ়৴ૼभਜ਼઼હऐ ੫ऐ Active Directory Active Directory Federation Services ID৴ IDଁ় Windows Live ID Identity Lifecycle Manager IDীങ Windows CardSpace যऐ ॉੌाभ॔উটॳش ঘش२شඝਙ؞৫ऐॶشঝ ID&॔ॡ७५ଵ৶ਃચ উছॵॺইज़ش ఁਙ 2 ঐॖॡট९ইॺऋघॊૼ Microsoft Office Web ࣏࣮ࢱࣝ Windows Rights Management Services Active Directory Federation Services Active Directory & Microsoft Identity Integration Server BizTalk .NET Visual Studio 20ਰभ॥ॿॡॱش ঘش२ش ৫ ID&॔ॡ७५ ଵ৶ଲષ ঃشॼॺش Identity Lifecycle Manager 2007 Certificate Services Visual Studio উছॵॺ ইज़ش MIIS SDK WS-* ఁਙ ইज़شढ़५ग़জ॔ Microsoft Office Web ࣏࣮ࢱࣝ Windows Identity Lifecycle Manager 2007 Visual Studio ঃشॼॺش ঘش२ش ৫ ID&॔ॡ७५ ଵ৶ଲષ ইज़شढ़५ग़জ॔ ॹॕঞॡॺজ १شঅ५ IDছॖই१ॖॡঝ ଵ৶ Certificate Services Rights Management Services Active Directory Federation Services Active Directory & Microsoft Identity Integration Server BizTalk .NET Visual Studio উছॵॺ ইज़ش ੲਾभ৳૧ IDभইख़ॹঞش३ঙথ ৴؞SSO MIIS SDK ਘৡऩੳ 20ਰभ॥ॿॡॱش WS-* ఁਙ 3 Identity ঢ়৴ૼभਜ਼઼હऐ ੫ऐ Active Directory Active Directory Federation Services Identity Lifecycle Manager ID৴ IDଁ় Windows Live ID IDীങ Windows CardSpace যऐ Active Directory Windows Servers Windows Clients Network Resources File Shares Printers Policies Configuration Security Quarantine Policies Windows Users Edge Security Account Information Privileges Profiles/ Policies Single Sign-On Configuration Security Policy VPN & Remote Access Single Sign-On Other Systems Network Devices Directories Databases Mainframes UNIX Configuration Quality of Service Security Policies Single Sign-On Live Services Federation Federated Identity Federated Identity Security Token Services Office, SharePoint, … 3rd Party Applications Product Information Privileges Profiles/Policies Automated deployment Single Sign-On Automated deployment Configuration App-specific data Windows ॿॵॺডشॡ॑রੱधखञॹॕঞॡॺজ३५ॸ ID&॔ॡ७५भরఙଵ৶ਃଡ ॥॔ૼपKerberos, LDAP ॑ਹ৷ؚ౮ਃர৴૭ચ 4 Identity ঢ়৴ૼभਜ਼઼હऐ ੫ऐ Active Directory Active Directory Federation Services Identity Lifecycle Manager ID৴ IDଁ় Windows Live ID IDীങ Windows CardSpace যऐ Identity Lifecycle Manager 2007 IDभ ३५ॸ৸৬दঘش२شभੲਾ॑ ३५ॸदੲਾभତ়ਙ॑৳ण ঘش२ش উটঅ४ঙॽথॢ ঘش२شभਛؚచभ৴भ॑ঽ৲ ID&॔ॡ७५पঢ়घॊ॥থউছॖ॔থ५॑ලಞ৲ ঃ५ডॻشभ ਗ਼છ ५ঐॺشढ़ॻش છঋش५भੳ॑ලप છभষؚఀૃ॑ঽ৲ ५ঐॺشढ़ॻشभଵ৶॑ලप 5 IDभ ใோभॖথইছ॑ଁ় IDੲਾ॑ਈৗपؚ ३५ॸदभତ়ਙ॑৳ण औऽकऽऩ३५ॸषभமਢ Identity ঢ়৴ૼभਜ਼઼હऐ ੫ऐ Active Directory Active Directory Federation Services ID৴ IDଁ় Windows Live ID Identity Lifecycle Manager IDীങ Windows CardSpace যऐ 6 Active Directory Federation Services IDभ৴पेॉ ੫भ३থॢঝ१ॖথड़থ॑ৰਠ WS-Federation ঋش५ َॡঞشُঋش५भੳؚੳ૭ ਠ Web ॔উজॣش३ঙথपৌૢ ॔উজॣش३ঙথঞॖখشभ৴ ADFSभইটش 䜰䜹䜴䞁䝖ഃ 䝸䝋䞊䝇ഃ Agent k Application 1* j c d Agent Application 2* e AD f ADAM i h Claims ADFS g ADFS AD ADAM *IIS 6 Web Server 7 Identity ঢ়৴ૼभਜ਼઼હऐ ੫ऐ Active Directory Active Directory Federation Services Identity Lifecycle Manager ID৴ IDଁ় Windows Live ID IDীങ Windows CardSpace যऐ Windows CardSpace Identity Metasystem भઅइ఼্॑৷ َढ़ُ॑ॻش৭උघॊඝਙ Ѝ ঃ५ড॑ॻشઞॎऩः ইॕॵ३থॢऊैभଆ౪ WS-* ॑ਹ৷ 8 Windows CardSpace ইটش Browser w/ CardSpace 1 HTTP(S) GET (Protected Page) Æ 2 HTTP(S) GET (Login Page) Æ Web Site Å Redirect to Login Page 7 Å Login Page (w/ InfoCard Tag) HTTPS GET + Cookie Æ Å HTML Content 6 3 HTTPS POST (w/ Token ) Æ Å Cookie + Browser Redirect Web Site Front End CardSpace lights up User selects card 5 CardSpace delivers token to browser 4 Relying Party WS-Trust RST/RSTR Authenticate user to STS and get token Security Token Service (STS) Identity Provider (Managed or Self-Issued) CardSpace भ્ඉ जोझोभঃॶشऋোो౹इ૭ચ IDউটংॖॲ؟Security Token Service ढ़ॻش७ঞॡॱ জ९ش५ડ؟Web १شংؚইঞشডشॡ (CardSpace पखऩः) Information Card ॑ંघુৢট० 9 Internet Identity Workshop 2007 A ॖথইज़ওش३ঙথढ़ॻشभॖথॱشड़ঌছঅ জॸॕ॑ৰୡघॊডشॡ३ঙॵউ (2007/5/15) ਸ੫شॳ؞ ढ़ॻش७ঞॡॱ f Relying Party (IDਹ৷ડ) f Ian Brown’s Safari Plugin, XMLDAP, Windows CardSpace, Higgins IdA H2 (Native), H3 (Java) Bandit, PamelaWare, CA, XMLDAP, Windows , Oracle RP, Identityblog RP UW/Shibboleth Identity Provider f Higgins, Bandit, XMLDAP, UW/Shibboleth, Livelabs, HumanPresent, Identityblog Identity ঢ়৴ૼभਜ਼઼હऐ ੫ऐ Active Directory Active Directory Federation Services ID৴ IDଁ় Windows Live ID Identity Lifecycle Manager IDীങ Windows CardSpace যऐ 10 Windows Live ID Windows Live १شঅ५भુৢॖথইছ SDKपेॉਹ৷૭ ઃংش४ঙথदम Windows CardSpace धभ৴ ADFS धभ৴ SAML ૄभॺشॡথ॑ਹ৷ অ४ঙথ – Identity Metasystem ঘش२ش ฮखञ ඝਙ ৫ ુৢभঃছॲॖ IT Pro ളහऔभೄ Identity Metasystem SAML ঃ५ডॻش X.509 Kerberos ऒोऊैभ ૼ… 11 ऒोऊैभ Web @ Home Identity Providers @ Work Sites & Applications Identity Metasystem Identity १شঅ५भྴ৲ ॡঞش॑੭घॊ३५ॸ ঘش२ؚش৫भฮखञ ളਯभॸॡঀট४॑ش१এॺشघॊਝੑ य़ش॥থ७উॺ ॔উজॣش३ঙথमএজ३ஂ॑شखथ ॡঞش॑੭ ॡঞشम७य़গজॸॕॺشॡথप ढ़উ७ঝ৲खथ ॡছॖ॔থॺमॡঞش॑ ७य़গজॸॕॺشॡথ१شঅ५ऊै੭ 12 WS-* Identity Metasystem 1.१شঅ५এজ३ش੭ (WS-MetadataExchange) ਏऩॡঞشभজ५ॺ ७य़গজॸॕ ॺشॡথ १شঅ५ १شঅ५ ॡছॖ॔থॺ 2. ७य़গজॸॕ ॺشॡথ੭ (WS-Trust) ॺشॡথपमॡঞشऋ োढथःॊ 3. ७य़গজॸॕॺشॡথ ॑ઞ৷ (WS-Security) ॔উজॣش३ঙথ ওॵ७ش४ध ॺشॡথ॑ঢ়৴હऐ ঐॖॡট९ইॺपेॊৰಎ 1.१شঅ५এজ३ش੭ (WS-MetadataExchange) ਏऩॡঞشभজ५ॺ Active Directory / Federation Services 2. ७य़গজॸॕ ॺشॡথ੭ (WS-Trust) ॺشॡথपमॡঞشऋ োढथःॊ Windows CardSpace WCF, ASP.Net 3. ७य़গজॸॕॺشॡথ ॑ઞ৷ (WS-Security) ॔উজॣش३ঙথ ওॵ७ش४ध ॺشॡথ॑ঢ়৴હऐ 13 Ubiquitous Identity! ॥গॽॸॕ Web १ॖॺ ॥গॽॸॕ ਗ਼ਵভ ISP ड़থছॖথ ३ঙॵউ ઇਃঢ় ৾ૅ ਁુ१شঅ५ ਁਃঢ় স१شঅ५ সਃঢ় অ४ॿ५ ঃشॼॺش ඐਜ Identity উটংॖॲ ঘش२ش ॔উজॣش३ঙথ 14 附属資料 D. ベリサイン社におけるアイデンティティ管理技術の展開 ベリサイン社は公開鍵基盤(PKI Public Key Infrastructure)を利用した認証サービスを中心に事業 を展開してきた企業である。ネットワーク環境の普及に伴って認証に係わる需要が多様化してきたこ とに対応して、ワンタイムパスワード認証に関する「ベリサイン ユニファイドオーセンティケーシ ョン」を発表し、さらにこれを発展させた「ベリサイン アイデンティティプロテクション(VIP)」 を発表した。VIP は、複数のオンライン取引用に 1 つのトークンもしくはアイデンティティを共用す ることのできる共通認証基盤の上で「ストロングオーセンティケーションサービス」と「オンライン 詐欺検出サービス」との二つのサービスを提供する。スライド６に VIP の全体像を示す。スライド 7 に共通認証基盤の特徴を示し、スライド 8 に認証サービスの概要を示す。スライド 9 にはオンライン 詐欺検出サービス(FDS Fraud Detection Service)の概要を示す。 附属資料 D 索引 1) 日本ベリサインのアイデンティティ管理技術に関する取り組み 2) Federated ID: A Brief VeriSign History (2002-2006) 3) OATH (Initiative for Open AuTHentication) 4) OpenID 5) ベリサインの 認証サービスへの取り組みと ロードマップ 6) ベリサインアイデンティティプロテクション(VIP)の全体像 7) VIP ネットワークのコンセプト 8) VIP Authentication サービス 9) オンライン詐欺検出サービス（FDS） 文責 事務局 日本ベリサインのアイデンティティ管理技術 に関する取り組み 日本ベリサイン株式会社 マーケティング部 坂本健太郎 Federated ID: A Brief VeriSign History (2002-2006) 2006: Launch of VeriSign Identity protection with PayPal, Schwab and Yahoo! at RSA conference SAML VIP 2002: Founder of Liberty Alliance CardSpace 2002-2007: Co-author of SAML 1.0 & 2.0 Specifications 2006: OpenID & VeriSign launches PIP (Beta) OATH (Initiative for Open AuTHentication) + 60社以上のアクティブな会員 + 15種類の相互運用可能な製品が出荷 OpenID OpenID started as a grass roots effort to meet the needs of the user generated content eco-system. + Simple, lightweight, and open source – sites can be OpenID enabled with two lines of HTML in 5 minutes! + Pragmatic – No built-in trust model + Decentralized – no single OpenID authority, OpenID providers co-exist. + Convenient – enables single sign-on and mobile identities + Portable – users can own their OpenID and switch OpenID providers. + Users in Control – users decide what personal information to share with whom. They can be their own IDP. + Secure - protocols allow an OpenID provider to use any authentication credentials including crypto or biometrics depending on assurance level needed. + Extensible – any identity attributes can be exchanged using OpenID protocols ベリサインの認証サービスへの取り組みとロードマップ + 多様化する「認証」のニーズに対応 ベリサイン アイデンティティプロテクションサービス（VIP） + 2006 広範囲なオンラインサービスに向けた高信頼性・ 高付加価値の認証基盤を提供 ▪ ▪ ▪ ユーザーは1つの携帯電話/トークンで金融・ショッピ ングなど複数のオンラインサービスを強固な二要素 認証と共に利用可能 オンラインサービスプロバイダをトークン管理・認証 システム運用から開放 オンライン詐欺検出による詐欺行為の防止 ユニファイドオーセンティケーションサービス（UA） 2005 + PKIソリューション 業界標準（OATH）に準拠したワンタイムパスワード認証の ASPサービスを提供 ▪ ▪ セキュアなリモートアクセス環境をより多くのユーザーに トークンベンダー各社はOATH規格に準拠することで対応製品 を開発可能 ※OATH = The Initiative for Open AuTHentication: ベリサイン、BEA Systems、CheckPoint、Cisco Systems、 Hewlett-Packard、IBM、Sun Microsystems などの主要ベンダー50社による認証の標準化を推進する団体 ベリサインアイデンティティプロテクション(VIP)の全体像 + ユーザのIDの保護を実現する包括的プラットフォーム 選択肢 インテグレーション + 複数の認証方法（ハードウェア、 ソフトウェア、out-of-band、相互） + 単一ネットワークインフラ ユーザおよびサイト ストロング オーセンティケーション フィッシング対策 オンライン詐欺検出 VIPネットワークインフラストラクチャ 2つの関連サービスが「ネットワーク効果」により相乗効果を生みだす 柔軟性 + 単品注文又はバイキング形式 アクティブ認証とパッシブ認証 オープン標準 + OATH（60メンバー、16ソリューション） VIPネットワークのコンセプト + 電子商取引 オンラインバンキング オンライン株取引 コミュニケーション 共通認証ネットワーク ▪ 様々なオンライン取引利用シーンで ▪ 複数のインタラクションでシングルトー クン・１つのアイデンティティを供用 ▪ 供用のメリット（使用性＆コスト） ▪ 拡張可能、高可用、セキュアなインフラ ▪ 主要なサイトで採用 共通認証ネットワーク 公共サービス インターネット 決済 医療 VIP Authentication サービス 認証要求サイト ポータルサイト ID taro オンラインバンキン グ 口座No 01-5599 ショッピングサイト 会員No VIPへOTPの検 証依頼 VeriSignサイト taro PWD ******* PWD ******* PWD ******* OTP 035673 OTP 035673 OTP 035673 Webサービス で接続 VIP 認証 サービス 認証/同期 トークンメンテナンス等 トークンに表示 されたOTPを入 力 トークンスト ア SharedSecre t User トークンベンダ管理サイ ト VIP プロビジョニング サービス シェアードシークレッ ト オンライン詐欺検出サービス（FDS） + 基本機能 ▪ ▪ 詐欺検出ルールエンジンに基づく詐欺行動の検知 行動分析エンジンによるユーザ行動パターンの自動学習と異常パターンの検知 コンビニや無人ATMでも コンビニや無人ATMでも もちろん様々なオンラインサービスで もちろん様々なオンラインサービスで + + バンキング・トレード・ショッピング・オーク ションなどインターネットを利用した取引 で、より強固な本人認証を実現 ID/パスワード + ワンタイムパスワードな どの組み合わせ + 深夜、または多額のキャッシュカード / ク レジットカードの利用時にもワンタイムパ スワードや本人だけが知っている質問な どを付加 + オンライン以外での利用の可能性 この事業は、競輪の補助金を受けて 実施したものです。 http://ringring-keirin.jp/ 財団法人 日本自転車振興会 競輪補助事業 平成 19 年度 Web 資源有効活用を推進する情報基盤の標準化調査研究補助事業 「アイデンティティ管理技術の標準化調査研究」 成果報告書 発行 印刷 平成 20 年 3 月 財団法人 日 本 規 格 協 会 情報技術標準化研究センター 〒100-0014 東京都千代田区永田町 2-13-5 電話（03）3592-1408 株式会社 スタンダード・ワークス 〒107-8440 東京都港区赤坂 4-1-24 日本規格協会ビル内 電話（03）3585-4558 －禁無断転載―
© Copyright 2024 Paperzz
