Windows CardSpace 概要 Part.2


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

image

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

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

[Windows CardSpace をサポートする Web サイトの動き]

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

image

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

image

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

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

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

image

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

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

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

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

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

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

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

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

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

image

① 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 ランタイムを開くと、カードの管理画面が出てきますが、この中の「マネージカードのインストール」を選択してカードをインストールします。

image

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

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

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

image

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

image

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

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

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

image 

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

# この説明だけ読むと、カードの偽造や捏造ができるのでは? というふうに読めると思いますが、その辺のリスクは公開鍵暗号などによって担保されています。なので 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 を使った認証システムの構築には、下図のような機能が必要になります。

image

ところが、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 などの最新プラットフォームの普及に伴い、徐々に使いやすい環境が整ってくることになるはずなので、概要とその狙いはぜひ知っておいていただければ、と思います。

Comments (9)

  1. ugaya says:

    webクライアントが.net3.0に依存してしまうのは現状だと大きなデメリットがある気がします。

    それだったらClickOnceやSilverlightでいいような気もしてます。

    ただ考え方自体は素敵なので、どちらかといえば標準化されてほしい技術です^^。

  2. aetos says:

    気になった点をいくつか。

    まず、IPはユーザーがどんなRPを利用しようとしているかがすべてわかるのか、ということです。

    ユーザーの行動履歴はその気になれば悪用できますから、ユーザーはIPが信頼できるかどうかを見極めなければなりませんね。

    それから、RPが要求する Claim は標準化されているのか? というのも気になりました。

    各々のRPが、必要とする Claim を好き勝手な名前で呼んでいたら困りますね。

    最後に、RPはIPをどうやって信頼するのだろうか、という疑問が。

    よろしかったら答えてやってください。

  3. nakama says:

    > ugaya さん

    すみません、コメント頂いていたことに気付いてませんでした;。

    > webクライアントが.net3.0に依存してしまうのは現状だと大きなデメリットがある気がします。

    IE に関して言えばその通りですが、例えば Safari 用の CardSpace などについては .NET 3.0 とは無関係な世界で作られているわけで、依存性という意味でいうと .NET 3.0 への依存ではなく、認証システムとしての CardSpace への依存、というのが正しい表現ですね。なので、ClickOnce や Silverlight などは対抗馬にはならないかと思います。(これらはクライアント開発技術であって、認証システム技術ではないので。)

    どちらにしても、考え方自体はよくできているので、もっと普及してほしい技術ではありますね^^。

    > aetos さん

    こんにちは。ざっとご質問に答えてみますね。

    > まず、IPはユーザーがどんなRPを利用しようとしているかがすべてわかるのか、ということです。

    クライアントは、特定の RP 向けのセキュリティトークン発行を IP にオンラインで要求しますので、そのタイミングで、自分の発行したカードがどこの RP に向けて使われようとしているのかを把握することができます。

    > ユーザーの行動履歴はその気になれば悪用できますから、ユーザーはIPが信頼できるかどうかを見極めなければなりませんね。

    もちろんその通りです。これは現実世界でも当たり前のことで、例えば区役所などは信頼しうる IP となりますが、その辺の怪しげなお店から発行された会員カードの場合、そこは信頼しうる IP とはならないでしょうし、そこから発行されたカードを RP が受け付けることもないでしょう。

    > それから、RPが要求する Claim は標準化されているのか? というのも気になりました。

    いえ、標準化はされていません。これはある意味当たり前のことで、例えば現実世界において、クレジットカードと運転免許証と健康保険証では、載っている Claim は異なります。つまり、Claim は標準化されていません。(ちなみに、現実のクレジットカード業界においてはどのカード会社でもこの Claim は載せる、といった具合に標準の記載事項が定義されているわけですが、これと同様のことは CardSpace の世界ではまだ行われていません。)

    これは重要なことですが、CardSpace で規定しているのは、セキュリティトークンのやり取りの「手順」であって、セキュリティトークンの「フォーマット」ではない、という点です。つまり、CardSpace の世界では「カードのフォーマット」や「記載内容」といったものを一切定めていません。これらの決定は、CardSpace という仕組みを使おうとする IP や RP 側に委ねています。というわけで、

    > 各々のRPが、必要とする Claim を好き勝手な名前で呼んでいたら困りますね。

    いえ、これは問題にはなりません。実際のシステムでは、RP 側は次のようなことを行います。(すでに IP が存在する場合)

    ・どこの IP から発行されたカードを使うかを決める。

    ・IP に対して、(その IP が取り決めている)セキュリティトークンのフォーマットや、入手可能な Claim 情報、セキュリティトークンを解読するための公開鍵などを入手する。

    ・IP から発行されたセキュリティトークンの解読プログラムを開発し、RP のサイトに組み込む。

    > 最後に、RPはIPをどうやって信頼するのだろうか、という疑問が。

    これも現実世界に準えて考えてみると分かりやすいです。現実世界では、酒屋さんは、

    ・運転免許証とパスポートは受け付ける。

    ・けれども社員証は受け付けない。

    といった「決め」を自分で行います。これと同じように、RP サイトは、まずどの IP から発行されたトークンだったら受け付けるのかを決定するわけです。

    ちなみに、RP サイト側がセキュリティトークンを受け取る際、当然、ねつ造されたものでないか否かを確認する必要があるのですが、通常ここは公開鍵暗号などの方式によってチェックを行います。つまり、① RP はまず事前に IP から公開鍵を受けとっておく。② ユーザは IP から、IP の秘密鍵で暗号化されたセキュリティトークンを受けとって、RP に提示する。③ RP はユーザから受け取ったセキュリティトークンを、事前に IP から受け取った公開鍵で解読してみてチェックする。という流れです。(この辺は一般的な公開鍵暗号系の考え方そのものなので、一般的な書籍などを調べてみるとよいと思います。)

  4. aetos says:

    > これは現実世界でも当たり前のことで、例えば区役所などは信頼しうる IP となりますが、その辺の怪しげなお店から発行された会員カードの場合、そこは信頼しうる IP とはならないでしょうし、そこから発行されたカードを RP が受け付けることもないでしょう。

    現実では、怪しげなお店の会員カードをどこかで提示しても、そのことを怪しげなお店が知ることはできない、という違いがあります。

    「信頼できる IP か?」は、RP にとってと、ユーザーにとっての2つの視点があります。

    従来は、ユーザーは「信頼できる RP か?」だけ気にしていればよかったのが、今度は IP についても気にする必要が出てくるということです。

    > 各々のRPが、必要とする Claim を好き勝手な名前で呼んでいたら困りますね。

    今のところ、自己発行カードしかもってないので、他のカードの使い勝手がわからないのですが、自己発行カードには、住所や電話番号を記載することもできますよね。

    これは、認証以外の、例えば通販サイトでの送付先入力を簡単にするような目的にも使えるんじゃないだろうかと思っています。

    その際、RP である通販サイトは「住所」という Claim を要求しているのに、カードには「自宅住所」とか「勤務先住所」という Claim は載っていても「住所」という Claim が載っていないと面倒なことになりそうだな、と思ったわけです。

    どうもまだ、自分の中で、情報カードは何であって何でないのかということが、いまひとつ整理しきれずに、いろいろごっちゃになっているようです。

    例えば、CardSpace は、Web 上でのシングルサインオンを実装する手助けにはならなそうですね。

  5. nakama says:

    > aetos さん

    うーん、なんかまだちょっと微妙に誤解されているところがありそうな気配。説明が分かりにくくて申し訳ないです;。

    > 「信頼できる IP か?」は、RP にとってと、ユーザーにとっての2つの視点があります。

    > 従来は、ユーザーは「信頼できる RP か?」だけ気にしていればよかったのが、今度は IP についても気にする必要が出てくるということです。

    IP についても気にする必要が出てくる、というのは、ある意味現実世界であっても同じ話かと思います。たとえば仮に、信頼できないクレジットカード会社からカードを発行してもらい、それを適当なお店で使ったらどうなるか? そのカードの利用履歴はクレジットカード会社に行くわけですが、カード会社はその人の行動履歴を情報収集することができてしまう、ということになります。

    CardSpace と現実世界のカードの大きな違いは、「世間的に十分信頼された IP がすでに存在しているか否か?」という点です。現実世界のカードの場合には、クレジットカード会社(IP)のことを信頼しているので、履歴が IP にバレても問題ないや、ということで安心してカードを使えるわけですが、CardSpace の場合には、そのような IP がまだ存在しません。このために、ユーザ側が「この IP は信用してもいいのか?」ということに気を払わなければならない、ということになります。

    なので、aetos さんがおっしゃっている問題は、世間的によく名の知れた、信頼のある会社が IP となってカードを発行することによって解決されていく問題と考えます。CardSpace の仕組み的な(=技術的な)問題ではなくて、現時点での普及度によって発生している問題、ですね。

    > これは、認証以外の、例えば通販サイトでの送付先入力を簡単にするような目的にも使えるんじゃないだろうかと思っています。

    Claim 情報が汎用化・共通化されていれば、そうしたことも実現可能なのでしょうが、現実的にはそこは難しいところですね。というのも、もともと Claim 情報を共通化しよう、という動きは昔からあるのですが、こうしたデジタルデータの標準フォーマットを決定するというのは、業界やユーザの賛同を得にくい、という現実もあります。

    > 例えば、CardSpace は、Web 上でのシングルサインオンを実装する手助けにはならなそうですね。

    いえ、なりますよ?(もちろん、シングルサインオンのシナリオ次第ではありますが。)

    同一のカードを複数のサイトに見せることは可能なので、あるカードを受け付けてくれる RP が複数ある場合には、シングルサインオンができる形になります。これは、Windows LiveID が一つのパスワードで複数のサイトにアクセスできるようになっている、というのと似たようなものだと思っていただくとわかりやすいかも。

  6. aetos says:

    > 信頼できないクレジットカード会社からカードを発行してもらい、それを適当なお店で使ったらどうなるか?

    クレジットカードは、IP に行動履歴がわかる数少ない例かと思います。

    > もともと Claim 情報を共通化しよう、という動きは昔からあるのですが、こうしたデジタルデータの標準フォーマットを決定するというのは、業界やユーザの賛同を得にくい、という現実もあります。

    そうだろうな、と思います。

    > 同一のカードを複数のサイトに見せることは可能なので、あるカードを受け付けてくれる RP が複数ある場合には、シングルサインオンができる形になります。

    すいません、言葉が足りませんでした。

    ここでシングルサインオンとは、プロファイル情報を複数サイトで共有することを含めて言ってます。

    CardSpace では同じカードでもサイトごとにトークンが違うので、RP 側では他の RP と同じカードが提示されたかどうかはわからないわけですよね。

    そうすると、情報共有のためには何か別の仕組みが必要だと思います。

    もともと、情報流出の問題に触れられているあたり、プロファイル共有自体を問題視しているのかもしれませんが。

  7. nakama says:

    > クレジットカードは、IP に行動履歴がわかる数少ない例かと思います。

    ですね。ただ、IP 側でカードの利用方法について検知できるというのはデメリットばかりでもないです。特に、目的特化型で発行しているカードについては、他の目的で使われたくないケースもよくあります。例えば taspo(たばこカード)はたばこ販売時の成人識別のためのカードですが、では例えばこのカードはロトくじやお酒を購入する場合にも成人であることを証明する目的で使えるのか? もしそうだとすると、taspo の発行プロセスはパスポートなどと同程度のセキュアな発行プロセスを経なければならないのか? など、厄介な問題も出てきたりします。(この辺まで議論すると、一般的な公的カード発行とは何ぞや?という話をしなければならなくなりますが。)

    > CardSpace では同じカードでもサイトごとにトークンが違うので、RP 側では他の RP と同じカードが提示されたかどうかはわからないわけですよね。

    いえ、トークンが違うことと、同一のカードが提示されたかどうかというのは直結しないです。多分、自己発行カードにおいてはサイトアドレスがくっついたトークンが取り扱われる、というあたりの仕組みからの誤解かなと思うのですが、RP 側では、他のサイトに提示されたカードと同一のカードであることをちゃんと識別できますが、提示されたカードを捏造して別のサイトになり済ましアクセスすることはできないようになっています(正確には、提示されたセキュリティトークンから、他のサイトになり済ましアクセスするためのセキュリティトークンを捏造できない、が正しい表現)。

    ただ、それ以前の話として、

    > ここでシングルサインオンとは、プロファイル情報を複数サイトで共有することを含めて言ってます。

    というか、CardSpace の場合には共有できるプロファイル情報にかなり制限があるのです。例えば、suica みたいなカードは、それ自体に情報を読み書きさせる機能がついていますが、CardSpace のカードにはそのような機能が備わっていません。こうした情報は、認証した結果を元に、IP に対して問い合わせを行ったりする必要があります。つまり、CardSpace は認証の仕組みであって、そこに「おまけで」プロファイル情報が載ってくる、と考えた方が分かりやすいのではないかと思います。

  8. aetos says:

    > 特に、目的特化型で発行しているカードについては、他の目的で使われたくないケースもよくあります。

    なるほど。

    「他の目的に使われたくないケース」っていうのがいまひとつ想像できませんでしたが、納得しました。

    > CardSpace の場合には共有できるプロファイル情報にかなり制限があるのです。

    すいません。

    関係ない話題を一緒に書いたので混乱させてしまったようです。

    ここで言う「プロファイル共有」とは、その前に言っていた「通販サイト等でのプロファイル入力支援」とは別件で、従来通り、サーバ側で管理されているプロファイルのことです。

    「同じカードが提示された」ことがわかるなら可能ですね。

  9. えムナウ says:

    Windows Card Space のダイアログが表示されるのが遅い。

    送信を押しても反応が遅い。

    ログインするだけでタバコが吸えます。orz

Skip to main content