とあるコンサルタントのつぶやき : WCS

Windows CardSpace 概要 Part.2

nakama — Thu, 04 Dec 2008 10:35:50 GMT

さて、前回は Windows CardSpace の理解をするために必要な前提知識として、そもそも現実世界におけるカード認証の仕組みについて解説しました。キーポイントとなる考え方はこれです。

自分のお財布の中には、公的機関や企業などから発行された、各種の名刺が入っている。（場合によっては自分がねつ造した自前の名刺が入っていることも！）
お酒を買おうとするときは、酒屋さんから指定されたカードを、お財布の中からチョイスして提示する。

Windows CardSpace は、この現実世界におけるカード認証の動きを、コンピュータシステムの世界の中で実現しようとするものです。

［Windows CardSpace をサポートする Web サイトの動き］

では、まず Windows CardSpace による認証をサポートする Web サイトが、どのようなものになるのかのイメージを見てみます。

通常の Web サイトでは、ユーザ名／パスワードによるログイン認証画面が用意されています。
Windows CardSpace をサポートしているサイトでは、さらにこれに加えて、CardSpace ログインボタンが用意されています。
このボタンをクリックすると、ブラウザから ActiveX コントロール経由で、クライアント PC 内にあるカードセレクタがポップアップとして起動します。（※ .NET Framework 3.0 がインストールされていない PC ではエラーになります。）

このカードセレクタは、簡単にいえば「当該 PC の中にあるお財布」です。
この中に入っているカード（これを情報カード（Information Card）と呼びます）のうち、当該 Web サイトに対して提示可能なカードが表示されます。提示不可能なカードについてはグレーアウトされます。（先の酒屋さんの例で言うと、パスポートや健康保険証のみが提示可能なカードとして取り扱われ、その他の社員証カードなどについてはグレーアウトすることになります。）
カードをダブルクリックすると、Web サイトへのログインが完了します。

……と、このように、まさに「現実世界におけるカードの提示」と同じような方法で Web サイトにログインできることになります。

ちなみに現実世界の場合、お財布の中にカードがあふれかえっている人は少なくないと思いますが（自分もそうですが；）、コントロールパネルの "Windows CardSpace" という項目から、この PC のお財布の中に入っているカードを管理（追加・削除など）することができます。

※ さらにこの画面では、自分でカードを自作することもできる（自作名刺を作ることもできる）のですが、これについては後述します。

［情報カードとセキュリティトークンの違い］

さて、上記の動作だけ見ると、Windows CardSpace は現実世界のカードシステムをそのままコンピュータシステム上に投影したもののように見えます。しかし、実は現実世界のカードと Windows CardSpace の情報カードには決定的な違いがあります。それは、

「CardSpace では、情報カードそのものを身分証明や身元証明に利用できない。」

という点です。これだけだと分かりにくいので、ちょっと説明を加えます。

まず、現実世界の場合には、カードそのものを身分証明や身元証明に利用できます。例えば、免許証や健康保険証を提示すれば、そのままで年齢確認をしてもらえます。しかし、この方法では以下のようなリスクがあります。

カードが盗難されたものだった場合に、RP 側（Relying Party、Web サイト側）がそれをチェックすることができません。例えば、提示されたカードが実は盗難されたものであることに気付かずに、本来のカードの持ち主以外にお酒を売ってしまったり会員カードを発行してしまったりするリスクがあります。
実は誤った人にカードを発行してしまっていた場合や、カードが盗難にあった場合に、IP 側（Identity Provider、カードの発行元）がこれを即座に差し止めることができません。
また、IP 側（Identity Provider）の想定外の用途にカードを使われる危険性もあります。

こうした理由から、現実世界では健康保険証や運転免許証をなくしたりするととんでもないことになるのですが、同様のことが CardSpace で発生すると大きな問題になります（PC とか紛失するととんでもないことに、となっては困るわけです）。

このため、Windows CardSpace では、クライアント（Principal）から Web サイト（RP）に対してカードを提示しようとするつど、カード発行元（IP）から、セキュリティトークンをオンラインで取り寄せます。セキュリティトークンとは、簡単にいえば「ワンタイムパスワード」のようなもので、一回だけ有効なアクセスチケット、だと思っていただけると分かりやすいでしょう。具体的な処理の流れは以下のようになります。

① Web サイト（RP）がユーザに対してカードの提示を要求する。

実際に RP からクライアントに対して要求されているのは、カードそのものの提示ではなく、セキュリティトークンの提示が要求されています。
より詳細には、利用可能なカード（IP）の種類と、必要な Claim リスト（例えばユーザ名と年齢情報が欲しい、など）がサーバから指定されます。

② Web ブラウザから、カードセレクタが起動し、カードを選択する。

情報カードを選択すると、あたかもカードそのものを Web サイトに送信しているかのようにみえる（＆そのように書いてある）のですが、実際にはカードそのものは Web サイトに送信されていません。
このカードの中には、発行元の IP の情報が書かれており、まず IP に対してこのカードを送信し、セキュリティトークン（RP にアクセスするためのチケット）の発行を求めます。
ちなみに、IP 側が持っている、オンラインでセキュリティトークンを発行することのできるサービスのことを STS （Security Token Issuing Service、セキュリティトークン発行サービス）と呼びます。

③ IP 側の STS は、送られてきたカードの情報をチェックし、セキュリティトークンを発行する。

STS は、情報カードが偽物でないかどうか、どの RP に対してどんな Claim を持つセキュリティトークンを必要としているのか、そもそも当該ユーザに対するトークン発行の差し止めは行われていないか、などのチェックを行った上で、セキュリティトークンを発行します。
セキュリティトークン上には、必要最小限の Claim だけが記載されています。（このため、RP 側が必要としていない Claim 情報についてはそもそも RP に対して送信されません。）

④ セキュリティトークンを RP に送信し、Web サイトにログインする。

RP 側では、送信されてきたセキュリティトークンが、本当に IP から発行されたものかどうかをデジタル署名などによりチェックし、正しいことが確認できた場合には、送信されてきた Claim 情報を信用して使います。

つまり、この流れからわかるように、

セキュリティトークンが、実際に身分や身元を証明するためのデータになる。
情報カードそのものには、セキュリティトークンが含まれていない。
セキュリティトークンは、オンラインでそのつど取り寄せなければならない。

ということになります。このセキュリティトークンと情報カードの関係は、現実世界になぞらえていうと、

CardSpace の情報カード＝印鑑カードや住基カード
印鑑カードや住基カードそのものは、印鑑の証明には使えない。
セキュリティトークン＝実際の印鑑証明書
印鑑証明書は、印鑑カードや住基カードを持っていくとすぐに発行してくれる。

のような関係にあります。（……ってかえってわかりにくい？；）重要なのは、情報カードそのものは、アクセスチケットを入手するためのものであって、それ自体がアクセスチケットになっているわけではない、という点です。このようにすることにより、IP 側が、オンライン上でのアクセスチケット（セキュリティトークン）発行の即時差し止めをすることができるようになっている（＝PC が盗難された場合のリスクを低減している）わけです。

※ なお、STS から発行される Claim の中には、ユーザのパスワード情報が含まれているわけではありません。STS から発行される Claim の中に含まれる情報の例としては、名前、年齢、生年月日、e-mail アドレスなどの、個人の属性情報などがあります。RP 側は、IP のことを信頼しているので、STS が当該 IP から発行されたものだと確認できれば、そこに書かれている情報（名前や年齢、生年月日など）はすべて信用することになります。

［マネージカードと自己発行カード］

さて、Windows CardSpace を理解する上でもう一つ欠かせない概念が、自己発行カード（Self-issued Information Card、個人用カード）です。

一般的に、Windows CardSpace で取り扱うカードは、IP から発行されたものを自分の PC にインストールする、という形式で使います。コントロールパネルから Windows CardSpace ランタイムを開くと、カードの管理画面が出てきますが、この中の「マネージカードのインストール」を選択してカードをインストールします。

ちなみに Windows CardSpace の情報カードは、拡張子 .crd のファイル（中身は XML 形式で書かれたファイル）です。.crd ファイルの入手方法自体は CardSpace では規定されていませんが、オンラインで発行してもらうパターンや、ディスクや CD-ROM 媒体にコピーして受け取る方法などがあります。

このように、IP が発行する情報カードのことを、一般に「マネージカード」（Managed Card）と呼びます。（現在のところ、マネージカードを発行してくれる企業や IP は残念ながらほとんどないのですが；。）

しかし、Windows CardSpace の情報カードにはもう一つ、自己発行カード（個人用カード）と呼ばれるものがあります。これは簡単に言うと、自分で名刺を自作する、というもので、Part.1 で解説した、ボトルキープのケースに該当するものです。上記の画面から個人用カードの作成ボタンを押すと、自前の名刺を作ることができます。

この自己発行カードはどういうときに使うのかというと、Part.1 で解説した、「通常のパスワード認証を使っている Web サイト」のケースで利用します。通常の多くのサイトでは、新規ユーザ登録時に、自分で決めたパスワードを登録しておくわけですが、このパスワードのかわりに、自作した名刺（自己発行カード）を登録しておきます。

このようにすると、当該ユーザがその Web サイトにアクセスするときに、パスワードを入力するかわりにカード（＝自分の作った自己発行カード）を提示してログインをすることができるようになります。

※ 個人用カード、という用語が分かりにくいと思うのですが、これは個人用というよりも自作の名刺を意味している、と考えたほうがよいと思います。（というか、カードが個人用なのは当たり前なのでw）

ちなみに自己発行カードを使う場合のシステム的な動作を示したのが下図になります。この場合には、当該 PC にインストールされている Windows CardSpace ランタイムそのものが IP になります。この IP のことを自己発行プロバイダ（Self-Issue Provider）と呼びます。RP （Web サイト）では、パスワード情報のかわりにカードに関する情報を登録しておくことになり、パスワード確認のかわりにカード情報（＝本人のカードかどうか、前回提示されたカードと同一のものかどうか）を確認することになります。

自己発行プロバイダによって作成した自己発行カード（個人用カード）は、自分の公的な身元証明目的で利用することはできませんが、パスワードがわりに利用するには十分、ということになります。

＃この説明だけ読むと、カードの偽造や捏造ができるのでは？というふうに読めると思いますが、その辺のリスクは公開鍵暗号などによって担保されています。なので PC が盗難されない限り、他の人が同一のカードを捏造したりすることはできないように設計されています。（この辺は書くと長くなるので今回は割愛しますが）

ちなみに、この自己発行カードの登録機能を持っている代表的な Web サイトの一つが、Windows Live です。こちらのアドレスからログインしようとすると、情報カード（自己発行カード）によるログインができるようになっています。（※ 実際に使う場合には、一度普通のパスワードでログインしたあとで、自己発行カードをパスワードのかわりとして登録しておく作業が必要になります。）詳細な情報はこちらのアドレスを見てもらうとよいと思います。（日本語だとここが分かりやすいです）

［パスワードのかわりに情報カードを登録するメリット］

さて、CardSpace を使うと現実世界のように「カードを見せる」ことによるログインができるようになるわけですが、とはいえこれだけのメリットだと、なかなか現在慣れ親しんでいるパスワード方式から乗り換えるメリットが見えづらい、と思います。しかし、Windows CardSpace を使うことには、以下のようなメリットもあります。

ユーザが、サイトごとに複雑なパスワードを使い分けなくても済むようになります。
クラッキングのリスクを避けるためにはサイトごとに複雑なパスワードを使い分ける必要がありますが、実際にはこれは非常に困難で、多くのユーザはそもそも単純な文字列をパスワードとして使ってしまっているでしょう。しかし、Windows CardSpace を使う場合には、そもそもパスワードを利用する必要がありません。
あるサイトでユーザ情報 DB がクラックされても、他サイトまで影響が及ぶリスクが低くなります。
多くのユーザは複数のサイトで共通のパスワードを使うため、ひとつのサイトがクラックされると他のサイトもクラックされる、というリスクが発生します（＝どこか一つでも情報漏洩が発生すると、自分が使っているすべてのサイトでリスクが生じる）。しかし、CardSpace では同一のカードを使っていてもサイトごとに送信されるセキュリティトークンが変化するように設計されているため、クラッキングリスクが低減します。
フィッシングのリスクを低減させることができます。
サイトに対して初めてカードを送信するときには警告メッセージが表示されるようになっているために、フィッシングされたときに誤ってカードを送信するリスクが減ります。また、EV 証明書と呼ばれる高保障証明書を利用することもできるため、サイトの正当性を保証しやすくなっています。

［プラットフォーム中立性］

なお、Windows CardSpace は以下のようなプラットフォーム中立性を持っています。

マルチブラウザ対応
IE 7.0, FireFox 1.5, 2.0 をサポート（ただし .NET Fx 3.0 が必要）。Java で動作する CardSpace や Apple/Safari、Linux/FireFox で動作する CardSpace なども 3rd party やオープンソースで開発されています。また、ポート 80 のみで動作可能です。
可能な限り、オープンな仕様に基づいて設計されている
情報カードのフォーマット（.crd ファイルのスキーマ）は現時点では独自（標準仕様が存在しないため）ですが、STS からのトークン発行などにはオープンな WS-* を利用しています。
単一の ID プロバイダを必要としない
Live ID （Passport）などと異なり、ID 情報そのものの囲い込みを目的としていません。あくまで、CardSpace は、「ネットワーク空間の中でカード情報をやり取りする枠組み」のみを定義しています。（実はセキュリティトークンのフォーマットも規定していないため、IP が複数存在していても全く問題なく運用することができる仕組みを採っています）

［現状で CardSpace を利用する場合の注意点］

さて、このように様々なメリットを持った Windows CardSpace ですが、実際に Windows CardSpace に対応した Web サイトを開発しようとした場合には、実は結構厄介な話があります。それは、.NET Framework 3.0 に含まれる WCS ランタイムだけでは、CardSpace 対応のシステム全体を構築できない、という点です。

Windows CardSpace を使った認証システムの構築には、下図のような機能が必要になります。

ところが、WCS ランタイムの含まれている機能は、クライアント機能、すなわちカードストア、セレクタ、自己発行 IP の 3 つのみです。実際に WCS 対応システムを作るためには、IP, STS, RP の実装が必要になるのですが、これらの実装はそんなに簡単ではありません。具体的には、以下のような機能実装が必要になります。

IP （Identity Provider）：カード発行に必要な一連の機能
ユーザ管理、マネージカード発行／再発行、失効、リニューアル、etc.
STS （Security Token Service） : トークン発行に必要な機能
マネージカードの内容確認、セキュリティトークン発行、失効管理、etc.
RP （Relying Parties） : トークン受付に必要な機能
クライアントへのトークン提示要求、受信したトークンの解析機能、etc.

実は、WCS 自身はカードの中身や暗号化ロジック、トークンの形式を一切規定していないため、自由度が高い半面、自力での実装が必要です。こうした問題を踏まえ、IP, STS, RP の実装を簡素化するためのフレームワークを開発しています。それが Codename "Geneva" と呼ばれるものです。今回はこちらの詳細には触れませんが（というかごめんなさい、白状すると私もちゃんと調べきれてないのです＞＜）、Geneva の開発チームの blog がこちらにありますので、興味がある方はぜひ読んでみてください。

［まとめ］

というわけで、2 回にわたって Windows CardSpace について解説してきましたが、全体像を振り返りながらまとめると以下のようになります。

CardSpace では、以下の 3 者がカードやセキュリティトークンの情報をやり取りする。

RP （Relying Parties） : カード情報の提示を求めるサイト
Principal : エンドユーザ
IP （Identity Provider） : カードを発行するサイト

CardSpace では、カードとセキュリティトークンが区別される。

カード（情報カード）
IP からセキュリティトークンを発行してもらうためのカード。STS（セキュリティトークンサービス）の URL、記載可能な Claim 一覧などが記載されている。
セキュリティトークン
IP の STS から必要のつど発行してもらう、実際の「身元証明」情報。必要最小限の Claim のみが記載された形で発行され、これを RP に提示することで、RP に対し、身元証明を行う。

Windows CardSpace は、現在のところ IP, RP, STS などの実装の困難性、そしてランタイムの普及率などの問題からなかなか流行っていないのが実情だと思いますが、エンドユーザにとっても非常にメリットのある、わかりやすい技術であることには間違いがありません。今後、Geneva などの正式リリース、あるいは Vista や .NET Framework 3.0 などの最新プラットフォームの普及に伴い、徐々に使いやすい環境が整ってくることになるはずなので、概要とその狙いはぜひ知っておいていただければ、と思います。

Windows CardSpace 概要 Part.1

nakama — Thu, 27 Nov 2008 06:02:42 GMT

さて、次は何のネタ書くかなぁ……と思っていたのですが、ちょっと寄り道して Windows CardSpace （WCS）の話題にしてみようかと思ったり。

Windows CardSpace というのは、.NET Framework 3.0 に含まれるコンポーネントの一つで、

WPF (Windows Presentation Foundation)
WCF (Windows Communication Foundation)
WF (Windows Workflow Foundation)
WCS (Windows CardSpace)

と、.NET Framework 3.0 の一角を占める重要なコンポーネント…なのですが、これがびっくりするほど知られていません。確かに私も実際の案件で使ったことがあるテクノロジではなく、また現時点で利用しようと思うとハードルの高い技術なのですが、考え方は非常に単純であり、概要については知っておいて損はない技術の一つです。特にセキュリティがらみの技術は、実際にそれを使うにせよ使わないにせよ、設計概念を理解しておくと、実際のシステム開発ではその類推で設計できることが結構あります。幸い、概念レベルで見ると非常に面白い技術なので、今回は気楽にエントリを読んでもらえると嬉しいです。

Windows CardSpace とはどんなものか？
現実世界のカード身分証明との比較
コンピュータシステムとの比較

1. Windows CardSpace とはどんなものか？

Windows CardSpace は、.NET Framework 3.0 に同梱されているコンポーネントです。このため、Windows Vista には最初からインストールされており、XP などでも .NET 3.0 をインストールすることで利用することができるようになります。ちなみに、どこにインストールされているのかというと、コントロールパネルの項目の中に「Windows CardSpace」という項目があり、これを選択すると起動します。

とはいえ、この画面だけだと「いったいこれはなに？？」となると思います。この画面は、この PC の中にある「お財布」と、そこに含まれる「カード」なのですが、この説明でもさっぱりわからないと思いますので、ちょっと PC の世界を離れて、現実世界の話をしてみたいと思います。

2. 現実世界のカード身分証明との比較

もともと Windows CardSpace は、ID メタシステムのためのコンポーネントとして開発されました。ID メタシステムとは、エンドユーザの身分証明・身元証明（ID 証明）の方法に関する汎用的なフレームワークのことなのですが、そもそも現実世界の中では、一般的にどのような形で身分証明が行われているのかを考えてみます。

例えば、私がお酒を買う場合を考えてみます。お酒を買うまでの流れは以下のようなものでしょう。

~~私は非常に若く見えるので~~、お酒屋さんから年齢確認を求められます。
私は財布を開き、大量のカードの中から適切なカード（例えば健康保険証やパスポートなど）を一枚取り出して酒屋さんに見せます。
すると、酒屋さんはカードの内容を確認し、お酒を売ってくれます。
もちろん、提示するカードが年齢証明に使えないようなカード（例えばヨドバシカメラのポイントカードなど）だったら、お酒を売るのを拒否されてしまいます。

さて、この一連の流れでは、以下の 3 つのロールが存在します。

IP （Identity Provider） : 身分証明書を発行する立場の人、あるいは組織
例：外務省（パスポート）、警視庁（免許証）、健康保険組合（健康保険証）、企業（社員証）、ビデオレンタル会員証（ビデオレンタル店）、etc.
Principal : 身分証明書を使って何かをしようと思っている人
例：エンドユーザ
RP （Relying Parties） : 身分証明書による確認を求める立場の人
例：酒屋さん（年齢確認のため）、警備員（社員のみを入館させるため）、etc.

※ 上述した 3 つの用語（IP, Principal, RP）はセキュリティの専門用語で、いろんなところで出てくるのでぜひ覚えてください。わかりにくければ、上のイラストになぞらえて覚えておくとよいでしょう。

実は、現実世界におけるカードの身分証明の動きを見ると、必ず IP, Principal, RP の三者が介在した動きをしています。いくつか例を取り上げてみます。

例1. 酒屋さんでお酒を買うとき

さきほどの例です。この場合、お酒を買う場合には、年齢証明が必要なため、パスポートや免許証、健康保険証などの提示が求められます。IP, Principal, RP がどれに対応するのかはいうまでもないでしょう。このケースには、以下のような特徴があります。

提示するカードを Principal が選ぶことができるが、なんでもよいというわけではない。
「公的機関から発行されている信頼されたカード」であることが必要であり、社員証などは通常却下されます。通常は、RP （酒屋）から利用可能なカードの選択肢が示され、手持ちのカードの中から適切なものをチョイスして見せることになります。
提示するカードを全部見せる必要は必ずしもない。
見せなければいけない情報は「生年月日」（年齢に関する情報）だけであり、カードに載っている氏名や住所、電話番号などまで見せる必要性は本来はありません。

後者に関して少し補足すると、酒屋さんが本当に知りたい情報は、年齢に関する情報だけであり、それ以外の項目は「隠してしまっても」本来は問題ありません。実際には面倒なのでまるごと見せてしまうことが多いでしょうが、原則論からいえば、必ずしも名前や住所などを酒屋さん見せる必要性はないわけです。

なお、カード上に記載された「生年月日」のような、カード上に記載されている情報のことを、セキュリティ用語で "Claim" （主張）と呼びます。

※ 日本語で「主張」というと、opinion （オピニオン）みたいなニュアンスを感じますが、そういった意味はとりあえずないと思ってもらって OK なのですが、MSDN などのドキュメントを読む際、「主張」という訳語であるがゆえに「？」となってしまうことがしばしばあります。このような場合には、それが "Claim" （カード上の情報項目）のことを指している、と思って読むとよいと思います。私は誤解を避けるために、「主張」と呼ばずに「クレイム」と呼んでいます。

例2. 病院にかかるとき

病院で診察を受けるときには、健康保険証の提示を求められます。この場合の IP, Principal, RP も言うまでもないでしょうが、病院での診察のケースでは非常に面白いところがあります。それは健康保険証の提示は、初回 1 回だけ行えばよい、という点です。

通常、初回に健康保険証を提示すると、病院から診察券が発行され、その後の診察ではこの診察券を使って受診することになります。

こうなると、実は最初のときは RP であった病院自身が、診察券に関する IP の役割を担うことになるわけです。つまり、その病院の診察券については、病院が IP と RP の両方を兼ねる、ということになります。

実はこの RP が IP の役割を兼ねる、というケースは現実世界では極めてよくあります。いわゆるほとんどの会員カードの類はこれに準じており、初回のみ公的機関発行のカードの提示を求めたあと、以降は自社で発行したカードを使う仕組みになっているはず。このようなものは、RP が IP を兼ねることになります。

例3. バーのボトルキープ

最後の例として、バーでのボトルキープの例を考えてみたいと思います。バーに行くと、キープされたボトルに名刺が輪ゴムでかかっている光景がよく見られます（……いや最近はそんな光景ないかもしれませんが、一応そういうことにしといてください（笑））。このとき、普通に考えると、

企業が IP。
お客さんが Principal。
バーが RP。

ということになる……のですが、チョイ悪オヤジの場合、まさかここで会社のいつもの名刺を真っ向切って出すわけにはいきません。そこで、チョイ悪オヤジは偽の名刺や自作した名刺をこっそり作っておき、ベンチャー企業の社長の肩書の偽名刺を出すわけです。（例が悪いとかいうツッコミはなしで^^）バーの側からしても、別にその人の肩書きを暴く必要はなく、本人を一意識別できさえすればよい。つまり、本物の名刺である必要性はなく（＝本人の身元保証を取る必要はなく）、偽の名刺だろうが自作した名刺だろうが、本人を一意識別できさえすればよい、ということになります。

実はこのシナリオは非常に重要です。というのも、実際にみなさんにも以下のような心当たりがないでしょうか？

物販サイトでのユーザ登録で、年齢のサバを読んで登録した。
オンラインゲームのユーザ登録に、偽名を使った。

多くの場合、物販サイトやオンラインゲームのユーザ登録では、厳密に正しいユーザ情報を取得するよりも、気軽に登録してもらうことの方が重要なケースが多々あり、このような場合には偽名の登録でも実質的に問題なし、としているケースも少なからずあります（罰則規定などはあるにせよ）。現実のシステムでは、このようなシナリオもきちんとサポートできなければならない、ということがいえます。

ちなみにこのような偽造名刺シナリオの場合には、Principal （自分自身）が IP を兼ねることになります。自分自身が「こうだ！」と決めたものが、そのまま正しいものとして RP に示される、というわけです。

3. コンピュータシステムとの比較

さて、CardSpace を利用する・しないにかかわらず、ユーザ認証を行うコンピュータシステムでは、必ず RP, Principal, IP に相当する役割の人たちが存在します。具体例をいくつか見てみます。

例1. Windows 統合認証を利用するイントラネット Web システム

この場合には、IP = Active Directory、RP = Windows 統合認証を要求する Web システム、利用する身分証明用のカード = Kerberos チケット、となります。

例2. Windows LiveID 認証を求めるインターネット Web システム

いわゆる Hotmail や MSDN サイトなどは、LiveID （昔の Passport）を使った認証を行っています。

この場合には、以下のような役割分担になります。（実際には、RP サイト上でログインを行うと、IP サイトへのリダイレクトが行われ、クッキーなどを介して LiveID 認証サーバから RP サイトへ認証情報が引き継がれます。）

例3. 通常のパスワード認証を使っている Web サイト

さて、では次のような場合はどうでしょうか？

一般的な Web サイトでは、新規ユーザ登録時にパスワードを自分で決めて ID 登録を行います。そのあと、このパスワードを使って Web サイトにアクセスしますが、この場合の IP, RP はそれぞれどれに対応するでしょうか？

正解は以下の通り。

この場合の IP は、Web サイト側ではないことに注意してください。確かにパスワード確認をしているのは Web サイトなのですが、そもそも正しいパスワードが何かを決めたのは、Web サイトではなく、ユーザ側です。つまり、本人であることの証明用のデータ（パスワード＝自分を証明するカード）を自分自身で作り出していることになるため、このケースでは IP = Principal となるわけです。

ここまでのまとめ

では、ここまでの話をまとめておきます。

ユーザ認証がかかわるシステムでは、必ず IP, Principal, RP の 3 者が存在する。
IP （Identity Provider） : 身分証明書を発行する立場の人、あるいは組織
Principal : 身分証明書を使って何かをしようと思っている人
RP （Relying Parties） : 身分証明書による確認を求める立場の人
カード上に記載されている、その人に関する情報項目のことを Claim （主張）と呼ぶ。
カード上のすべての情報が必要なわけではなく、一部の Claim のみで十分なことも多い。
会員カード方式では、RP が会員カードの発行元（IP）になる。
初回のみ公的機関発行のカードを確認し、二回目以降は RP が発行した会員カードを確認するような場合には、RP が IP を兼ねることになる。
自分で決定したパスワードを登録するようなシステムでは、Principal が IP となる。

引き続き次回は、ここまでの話が Windows CardSpace にどのように反映されているのか、という話をしたいと思います。