(57)【要約】本出願において、アイデンティティ管理及び認証のためのシステム及び方法が提供される。本発明は、信頼関係の責任がユーザーに依存するアイデンティティ管理システムにおける実行主体のメンバーシップを証明するためにシャドウ・ドメインを採用する。本発明は、さらに、アイデンティティ管理ネットワークにおいて第三者によって行われる表明の認証のための二重署名証明書送信を教示する。
2005529392.tif 000002
【特許請求の範囲】
【請求項１】
ユーザーの認証をメンバーサイトに与えるためのアイデンティティ管理システムであり、該アイデンティティ管理システムが、
ユーザーと関連付けられるグローバル一意識別子を記憶するためのユーザー・データベースを有するルート・サーバーであり、該ルート・サーバーが、前記ユーザーをシャドウ・ドメインに属するホームサイトに関連付けられる名前にリダイレクトすると、前記メンバーサイトにアクセスする実行主体を前記グローバル一意識別子と関連付けられるユーザーとして前記ホームサイトが認証できるようにするために、前記ユーザーに前記グローバル一意識別子を与えるため、及びドメインネーム・サーバーに与えるために前記シャドウ・ドメインにおける名前に関連付けられるネットワーク・アドレスのリストを維持するための手段を有し、前記名前がアイデンティティ管理ネットワークに属する前記メンバーサイトあるいはホームサイトに関連付けられる、ルート・サーバー、
を含む、アイデンティティ管理システム。
【請求項２】
該アイデンティティ管理システムにおいて、前記ルート・サーバーが、前記実行主体を前記グローバル一意識別子と関連付けられるユーザーとして認証するためのホームサイトの権限の認証を前記メンバーサイトに与えるためのホームサイト認証メッセージを含む、請求項１に記載のアイデンティティ管理システム。
【請求項３】
さらに、前記ルート・サーバーと通信し、かつユーザー・プロフィル・データベース、ユーザー認証エンジン及びシャドウ・ドメインのネームスペースにドメイン名を有するホームサイトを含み、前記ユーザー・プロフィル・データベースが前記ユーザーに関連付けられる前記グローバル一意識別子及び認証情報の両方を記憶するためのものであり、前記認証エンジンが、前記ホームサイトが前記ユーザーのアイデンティティを認証できるようにする、請求項１又は２の請求項に記載のアイデンティティ管理システム。
【請求項４】
該アイデンティティ管理システムにおいて、前記認証情報がユーザーＩＤとパスワードの組み合わせである、請求項３に記載のアイデンティティ管理システム。
【請求項５】
該アイデンティティ管理システムにおいて、前記ユーザー・プロフィル・データベースがさらに前記ユーザーに関連付けられるアイデンティティ情報を記憶し、前記認証エンジンが、前記ユーザーの認証時に前記アイデンティティ情報のサブセットを前記メンバーサイトに提供する手段を含む、請求項３又は４の請求項に記載のアイデンティティ管理システム。
【請求項６】
該アイデンティティ管理システムにおいて、前記認証エンジンが、前記メンバーサイトによって読み取り可能な認証情報を含むクッキーを前記ユーザーに与えかつ前記ユーザーを前記メンバーサイトにリダイレクトすることによって、前記認証されたユーザー・アイデンティティを前記メンバーサイトに与える、請求項３、４及び５のうちいずれか１つの請求項に記載のアイデンティティ管理システム。
【請求項７】
該アイデンティティ管理システムにおいて、前記クッキーが前記ホームサイトの署名入りであり、かつ前記ホームサイトが前記グローバル一意識別子を認証する権限を有することの前記ルート・サーバーによる表示を含む、請求項６に記載のアイデンティティ管理システム。
【請求項８】
該アイデンティティ管理システムにおいて、前記認証エンジンが、前記ユーザーを認証符号化ユニバーサル・ソース・ロケータにリダイレクトすることによってか、あるいは前記メンバーサイトによって読み取り可能な認証情報を含むクッキーを前記ユーザーに与えて前記ユーザーを前記メンバーサイトにリダイレクトすることによって、前記ユーザーに関連付けられる前記アイデンティティ情報を前記メンバーサイトに提供する、請求項５に記載のアイデンティティ管理システム。
【請求項９】
アイデンティティ管理ネットワークにおいてホームサイトからユーザー認証を取得する方法であり、該方法が、
ホームサイトに既知のユーザー認証情報に基づいてユーザー認証を与えることができるホームサイトの名前を前記ユーザーから取得するステップと、
前記ユーザーを前記アイデンティティ管理ネットワークに関連付けられるシャドウ・ドメインにおける前記ホームサイトに前記ユーザーをリダイレクトすることによって、前記ホームサイトに認証要求を与えるステップと、
前記ホームサイトが前記既知の認証情報を前記ユーザーから受け取るのに応答して前記ホームサイトから前記ユーザーの認証を取得するステップであり、前記認証が前記ユーザーに関連付けられるグローバル一意識別子を含む、ステップと、
を含む、方法。
【請求項１０】
該方法において、前記ホームサイトの名前を前記ユーザーから取得するステップが、前記メンバーサイトが前記ユーザーによって与えられるクッキーを調べるステップを含む、請求項９に記載の方法。
【請求項１１】
該方法において、前記ホームサイトに認証要求を与えるステップが、前記ユーザーが前記シャドウ・ドメインにおける前記ホームサイトに関連付けられる名前をネットワーク・アドレスに転換するステップを含む、請求項９に記載の方法。
【請求項１２】
該方法において、前記ホームサイトに認証要求を与えるステップが、前記メンバーサイトが前記ホームサイトによって読み取り可能で前記ユーザーの認証要求を含むクッキーを前記ユーザーに与えるステップを含む、請求項９に記載の方法。
【請求項１３】
該方法において、前記ホームサイトがユーザー認証情報及びユーザー・アイデンティティ情報の両方を提供でき、前記ホームサイトに認証要求を与えるステップが、さらに、前記メンバーサイトが前記ホームサイトにアイデンティティ情報要求を与えるステップを含む、請求項９に記載の方法。
【請求項１４】
該方法において、前記認証を取得するステップが、さらに、前記ホームサイトが前記ユーザーから前記既知の認証情報を受け取るのに応答して識別情報を取得するステップを含む、請求項１３に記載の方法。
【請求項１５】
さらに、
前記ホームサイトによって提供されないアイデンティティ情報を取得するステップと、
前記ユーザーを前記シャドウ・ドメインにおける前記ホームサイトにリダイレクトすることによって、前記取得されたアイデンティティ情報を前記ホームサイトに提供するステップと、
を含む、請求項１３に記載の方法。
【請求項１６】
該方法において、前記ホームサイトによって提供されない前記アイデンティティ情報が前記ユーザーから取得される、請求項１５に記載の方法。
【請求項１７】
請求項２に記載のシステムを用いてアイデンティティ管理ネットワークに属するホームサイトでユーザー認証を行う方法であり、該方法が、
メンバーサイトのために認証を与えるよう求める要求をユーザーから受け取るステップと、
既知の認証情報を受け取るのに応答して、前記アイデンティティ管理ネットワークに関連付けられるシャドウ・ドメインにおける前記メンバーサイトに前記ユーザーをリダイレクトすることによって前記ユーザーの認証を前記メンバーサイトに与えるステップと、
を含む、方法。
【請求項１８】
該方法において、前記メンバーサイトに前記ユーザーの認証を与えるステップが、前記ユーザーから前記ユーザーの前記グローバル一意識別子と関連付けられるユーザーＩＤとパスワードの組み合わせを受け取るステップを含む、請求項１７に記載の方法。
【請求項１９】
該方法において、前記メンバーサイトに前記ユーザーの認証を与えるステップが、前記ユーザーが、前記シャドウ・ドメインにおける前記メンバーサイトに関連付けられる名前をネットワーク・アドレスに転換するステップを含む、請求項１７に記載の方法。
【請求項２０】
該方法において、前記ユーザーの認証を与えるステップが、前記ホームサイトが前記メンバーサイトによって読み取り可能で前記ユーザーの認証及び前記ユーザーに関連付けられる前記グローバル一意識別子を含むクッキーを前記ユーザーに与えるステップを含む、請求項１７に記載の方法。
【請求項２１】
該方法において、前記認証情報を提供するよう求める要求を受け取るステップが、アイデンティティ情報の要求を受け取るステップを含む、請求項１７に記載の方法。
【請求項２２】
該方法において、前記認証を与えるステップが、前記ユーザーから前記既知の認証情報を受け取った後前記メンバーサイトに識別情報を提供するステップを含む、請求項２１に記載の方法。
【請求項２３】
該方法において、前記メンバーサイトに識別情報を与えるステップの前に、前記要求される識別情報を前記メンバーサイトに転送するためにユーザーの許可を取得するステップを含む、請求項２２に記載の方法。
【請求項２４】
さらに、
前記メンバーサイトによって取得されるアイデンティティ情報を前記ユーザーから受け取るステップと、
前記転送されるアイデンティティ情報をユーザー・プロフィル・データベースに記憶するステップと、
を含む、請求項２１に記載の方法。
【請求項２５】
請求項２に記載のシステムを用いて、ユーザーに関連付けるためにグローバル一意識別子を取得する方法であり、該方法が、
グローバル一意識別子をｅメール・アドレスに関連付けるよう求める要求を前記ユーザーから受け取るステップと、
前記ユーザーｅメール・アドレスに関連付けられるグローバル一意識別子の割り当てをルート・サーバーに要求するステップと、
前記ユーザーが前記ｅメール・アドレスに送られる誰何に対する応答を前記ルートに与えるのに応答して前記ｅメール・アドレスに関連付けられるグローバル一意識別子を取得するステップと、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に言ってアイデンティティ管理のための方法及びシステムに関するものである。特に、本発明は、分散コンピュータ・ネットワークにおいて使用される場合の階層的分散アイデンティティ・システム及び方法に関するものである。
【背景技術】
【０００２】
電子商取引の分野において、アイデンティティ・ベースの情報を管理あるいは認証するためのシステム及び方法が求められていることは広く認知されている。当業者の間では、アイデンティティ・ベースの情報の認証とはユーザーが自分を何者と言っているかの保証に関するものではない、ということは認知されている。そうではなく、アイデンティティの認証とは、以前にアイデンティティが表明されたとき提示されたのと同じ資格証明書をユーザーが提示したことの認証に限定される。この微妙な差を理解するための単純な方法は、ユーザーが、関連パスワードが存在するユーザーＩＤによって識別される状況を考えることである。電子システムは、アカウントが初期設定されるときユーザーが誰なのか決定する方法を持たない。しかし、アカウントが初期設定された後は、ユーザーＩＤとパスワードの組み合わせの提示を、以前にサービス登録をしてこの資格証明書を提出したのと同じ者である証拠として見なすことができる。ユーザーＩＤ及びパスワードの提示は、そのユーザーがある特定の個人であることを証明しない。
【０００３】
アイデンティティ管理は、電子商取引ベンダーまたはサービス・プロバイダがユーザーに特製のサービスを提供できるようにし、さらにベンダーがユーザーの行動を追跡できるようにするので、電子商取引の分野において大きな関心事である。ユーザーの立場から見ると、アイデンティティ管理によって、ユーザーは以前に記憶された識別情報を検索することができる。アイデンティティ管理システムがなければ、サービスの利用ごとに以後のセッションにおいては保存できない一連の設定を選択しなければならない。例えば、オンライン購入の場合、アイデンティティ管理システムがないと、購入ごとにクレジットカード番号、請求先及び出荷先住所を含めて全ての識別情報を提出するようユーザーに要求する必要がある。これは、顧客にとっては一般にわずらわしく感じるものであり、オンライン商取引にとって有害となる。
【０００４】
以下の説明が一般的にアイデンティティ管理の電子商取引への応用に関するものであるが、ニュース・サイトのカスタマイズ、新聞へのアクセス登録及び電子討論サイト用の望みの表示構成の維持など他の非商取引関連サービスがアイデンティティ管理を使用することが、当業者には分かるだろう。これらのサービスの場合、ユーザーが複数のサービスについてシングル・サインオンできることが最優先される。
【０００５】
図１は、第一世代のアイデンティティ管理システムを示している。ユーザー１００は、インターネット１０２を通じて、一般にＥテイラーと呼ばれる電子小売業者１０４に接続される。Ｅテイラー１０４には、一般に、ハイパーテキスト転送プロトコル（HTTP）セッションを用いてアクセスする。Ｅテイラー１０４がホストとなるサイトを最初にアクセスするとき、ユーザー１００はユーザーＩＤ及びパスワードを含むユーザー・プロフィルを作成する。ユーザーＩＤ及びパスワードは、おそらくクレジットカード番号、出荷先及び請求先住所及び表示嗜好を含む他の関連情報と一緒に、ユーザー・プロフィル・データベース１０６に記憶される。ユーザー・プロフィル・データベース１０６は、機密ユーザー情報を保護するために、インターネット１０２に接続される一般コンピュータにはアクセス不能であることが望ましい。ユーザー・プロフィル・データベース１０６にユーザー・プロフィルを作成した後は、ユーザー１００は、単に自分のアイデンティティを証明するために証明書を提示することによってＥテイラー１０４へのその後の訪問を単純化することができる。一般に、この資格証明書は、ユーザーＩＤとパスワードの組み合わせである。この資格証明書が提示されると、Ｅテイラー１０４は、ユーザー・プロフィル・データベース１０６を調べて、ユーザーが有効なアイデンティティ証明書を提示したかどうか確認する。このチェックに合格したら、ユーザー１００は、既知の情報を提出するために入力要求されない。Ｅテイラー１０４の立場から見ると、このシステムは、ユーザー１００がユーザー・プロフィル・データベース１０６に記憶できる、トランザクションに必要な全ての情報を確実に提供するようにする。この情報を、多数のセッションまたはトランザクションを通じて相関して、ユーザー・プロフィル・トレンドを生成することができる。ユーザーの立場から見ると、このシステムは、Ｅテイラー１０４との間で単純化された取引を行えるようにする。ただし、このシステムの欠点が図２に示されている。
【０００６】
図２は、インターネット１０２を用いて２つの異なるＥテイラーであるＥテイラー１０４ａ及びＥテイラー１０４ｂに接続するユーザー１００のネットワーク・モデルを示している。各Ｅテイラーは、それぞれ自身のユーザー・プロフィル・データベースであるデータベース１０６ａ及び１０６ｂを有する。ユーザーＩＤ及びパスワードはユーザー１００のアイデンティティを認証するために使用されるので、Ｅテイラーは、一般に、各ユーザーＩＤは一意であることを主張する。従って、ユーザー１００は、図には示されていないが他のＥテイラーでの別のユーザーＩＤに加えてＥテイラー１０４ａと１０４ｂにおいて異なるユーザーＩＤを持つことが考えられる。ユーザーの立場から見ると、複数のユーザーＩＤは管理が難しい。さらに、ユーザー情報が変わる場合、例えば、ユーザー１００が移転したりクレジットカード情報を変更したりする場合、各ユーザー情報データベース１０６ａ及び１０６ｂを個別に更新しなければならない。小規模であればこれは単に面倒なだけであるが、多様なＥテイラーをしばしば訪れる多くのユーザーにとってこれは大きな迷惑になる可能性がある。さらに、ユーザー・データを繰り返し入力することは、ユーザーが不正確な情報をうっかり提供する確率を高め、Ｅテイラーにとって害となる。従って、多数のデータベースのデータ・インテグリティを保証する責任と、複数のユーザーＩＤに伴う面倒とを考えると、このモデルのアイデンティティ管理は、多くのユーザーの目からは不備に見える。
【０００７】
ユーザーＩＤを確実に一意にするために、多くのＥテイラーはユーザーＩＤの代わりにユーザー１００のeメール・アドレスを使用する。しかし、ユーザーが提供するｅメール・アドレスは、長期間変化しないと言う保証はない。多くの場合、ユーザーは、雇用者、インターネット・サービス・プロバイダまたは無料eメール・プロバイダによってeメール・アドレスが与えられる。これらの場合、職場の変更、インターネット・サービス・プロバイダの変更または単純な気まぐれによってｅメール・アドレスを変更しないという保証はない。その結果、ユーザーは、そのeメール・アドレスが変わるときＥテイラーに再び申し込む必要がある。
【０００８】
ユーザーが複数のサービスに単一のユーザーＩＤを使用できるようにするため、及び技術上一般に「シングル・サインイン」と呼ばれるものを提供するために、第二世代のアイデンティティ管理及び認証法が創られた。この解決法は、一般に階層的アイデンティティ管理システムと呼ばれ、その代表は、ＭｉｃｒｏｓｏｆｔのＰａｓｓｐｏｒｔTMサービスである。このモデルの概要が図３に示されている。
【０００９】
図３は、望ましくはインターネット１０２を通じてアイデンティティ・プロバイダ１０８（ＩＤＰ）への接続を有するユーザー１００を示している。ユーザー１００は、一意のユーザーＩＤとパスワードの組み合わせに関連付けられるアイデンティティ・ベースの１組の情報をＩＤＰ１０８に提供する。この情報はユーザー・プロフィル・データベース１１０に記憶される。ユーザー１００がＩＤＰ１０８と提携するＥテイラーに接続するとき、ユーザー１００は、アイデンティティ証明書をＥテイラー１１２に提出し、これが、ユーザー１００を認証するためにＩＤＰ１０８に送られる。一般に、ユーザー１００がＥテイラー１１２を通じてＩＤＰ１０８に提出する証明書はユーザーＩＤとパスワードの組み合わせである。ユーザー１００を認証すると、ＩＤＰ１０８は、Ｅテイラー１１２に記憶されているアイデンティティ情報を提供する。一般にＩＤＰ１０８がＥテイラー１１２に提供する情報は、ＩＤＰ１０８が記憶する情報のうち厳格に定義されるサブセットであるか、ユーザー・プロフィル・データベース１１０にＩＤＰ１０８が記憶するユーザー１００に関連するデータ全体である。ＩＤＰ１０８はＩＤＰが提携する複数のEテイラーがアクセスできる情報を記憶するので、ＩＤＰ１０８は、一般に、ユーザーが特定のサイトについて表明した嗜好などサイト固有の情報を記憶せず、また特定のEテイラーからユーザー１００が購入した商品の履歴を記憶するためにユーザー嗜好データベース１１０を使用しない。その結果、Eテイラー１１２は、別個にユーザー嗜好データベース１１４を維持しなければならない。ユーザー嗜好データベース１１４の中の情報は、ユーザー１００のパターンを追跡するため、及びユーザー１００の購入または申し込み履歴を維持するために使用される。
【００１０】
このモデルにおけるトランザクションの例の場合、ユーザー１００はインターネット１０２を通じてＨＴＴＰリンクを用いてＥテイラー１１２にウェブ・ページを要求する。このＨＴＴＰセッション中、ユーザー１００は、いくつかの商品を購入したいことを知らせる。チェックアウト式のプロシージャ中、Ｅテイラー１１２はユーザー１００にアイデンティティを認証することを求める。ＩＤＰ１０８から認証を受けるために、Ｅテイラー１１２は、認証のために必要な証明書をユーザー１００に要求し、これを受け取る。証明書はＩＤＰ１０８に送られて、認証される。代替実施態様においては、ユーザー１００はＥテイラー１１２に認証情報を提供しない。その代わりに、Ｅテイラー１１２がアイデンティティの認証を要求するとき、Ｅテイラーはユーザー１００をＩＤＰ１０８にリダイレクトして、この転送が完了したら、ユーザー１００はＩＤＰ１０８に必要な認証情報を提供する。ユーザー１００の認証に成功したら、ＩＤＰ１０８はユーザー１００をＥテイラー１１２にリダイレクトして戻す。同じまたは異なるデータ通信チャネルを用いて、ＩＤＰ１０８は、ユーザー・プロフィル・データベース１１０に記憶される情報をＥテイラー１１２に提供する。この情報は、ユーザー１００が履歴情報にアクセスできるようにするためにユーザー嗜好データベース１１４に記憶される情報と相関される。
【００１１】
このモデルのアイデンティティ管理は、第一のモデルのアイデンティティ管理に伴うシングル・サインインの問題に対処しているが、他の多数の問題が生じる。第一の問題は、ＩＤＰを運営する実行主体の信頼性である。この実行主体は、Ｅテイラー１１４及びユーザー１００の両方から信頼されなければならない。ＩＤＰ１０８は、情報を保護し、ユーザー１００が承認する実行主体にのみ情報を提供するものとユーザー１００によって信頼されなければならない。Ｅテイラー１１２は、ＩＤＰ１０８が信頼できるサービス、正確なデータを提供し、略奪的行為をしないものと信頼できなければならない。Ｅテイラー１１２がＩＤＰ１０８を運営する実行主体が提供するサービスと競合するサービスを提供するサービス・プロバイダである場合、Ｅテイラー１１２は、一般にあまり高い信頼をＩＤＰ１０８に持たないだろう。
【００１２】
ユーザーの間では多くのプライバシーに関する懸念があるので、Ｍｉｃｒｏｓｏｆｔ  ＰａｓｓｗａｒｄTMサービスは、ユーザーがＥテイラー１１２にアイデンティティ認証情報を提供することを決して要求されないように実現される。代わりに、安全な接続を通じてユーザーをＥテイラー１１２からＩＤＰ１０８に渡すためにリダイレクト・コマンドが使用される。この安全な接続を通じて、ユーザー１００はＩＤＰ１０８にアイデンティティ認証情報を提供する。ユーザー１００を認証したら、ＩＤＰ１０８は、安全なバック・チャネルでユーザー１００をＥテイラー１１２に戻して、Ｅテイラー１１２に認証及びユーザー情報を与える。異なるサイトで単一のユーザー１００に関する情報を２つのＥテイラーが相関できないようにするために、ＩＤＰ１０８は、Ｅテイラーが２つのサイトの間でユーザーを相関するためにアイデンティティ・コーディング・インデクスを使用するのを防止するＥテイラー固有のアイデンティティ・コーディングを行う。ただし、Ｅテイラー１１４が、一般にユーザー１００と関連付けられるクレジットカード番号を知っているので、情報を共有する気のある２つのＥテイラーは、クレジットカード情報、ｅメール・アドレスまたは自宅住所を相互参照フィールドとして用いて、自身のデータベースを相関させることができることが、当業者には分かるだろう。
【００１３】
Ｍｉｃｒｏｓｏｆｔ  ＰａｓｓｐｏｒｔTMシステムの現在の実施態様は、電子商取引市場において第一世代のアイデンティティ管理システムを押しのけるのに充分な牽引力を得ることができなかった。その一つの理由は、ユーザー・プロフィル・データベース１１０など集中エユーザー・プロフィル・データベースが一般に静的データ構造を有することにある。すなわち、このデータベースは事前に定義された情報セットを記憶する。しかし、異なるＥテイラーは、一般にユーザーに異なる情報セットを要求する。集中ユーザー・プロフィル・データベース１１０は、多様なＥテイラーが要求する全ての情報を記憶するように設計されないので、Ｍｉｃｒｏｓｏｆｔ  ＰａｓｓｐｏｒｔTMサービスが提供するような集中ユーザー・プロフィル・データベース１１０に移行しても採算が取れないと、多くのＥテイラーが判断した。ＰａｓｓｐｏｒｔTMサービスが第一世代のアイデンティティ管理システムに取って代われなかったもう１つの理由は、単一の実行主体に膨大な量のアイデンティティ情報を提供することをユーザーが警戒したことである。ユーザーがこのような情報量を提供するのに充分な信頼をＩＤＰに対して持つためには、既存の信頼関係及びデータの機密保護に関するユーザーの前提が存在しなければならない。多くのユーザーがＭｉｃｒｏｓｏｆｔとの間にこの種の歴史的な関係を持っていなかったので、多くのユーザーがこの情報を提供したがらなかった。
【００１４】
多くの人々の間でもう１つ懸念されたことは、階層的アイデンティティ管理システムが独占主義的傾向を促進することである。この懸念に対処するために、第三世代モデルのアイデンティティ管理システムがＬｉｂｅｒｙ  Ａｌｌｉａｎｃｅによって創られた。このモデルは、分散アイデンティティ管理システムとして説明するのが最も妥当である。この種のシステムが図４に示されている。
【００１５】
図４は、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅが提案する分散アイデンティティ管理システムを示している。この仕様は、図においてはそれぞれユーザー・プロフィル・データベースＵＰＤ１  １１８、ＵＤＰ２  １２２及びＵＰＤ３  １２６を有するＩＤＰ１  １１６、ＩＤＰ２  １２０及びＩＤＰ３  １２４として示される複数のアイデンティティ・プロバイダについて説明している。全てのＩＤＰは、信頼のウェブ１２８の中に存在し、各ＩＤＰは、他の全てのＩＤＰと信頼関係を有する。信頼関係は点線で示されている。データの機密保護のために、信頼のウェブ１２８におけるＩＤＰ間の通信は、非対称暗号化を用いて行われる。このように、図４の例においては、ＩＤＰ１  １１６は、これと関連付けられる公開暗号化キーと秘密暗号化キーを有し、ＩＤＰ２  １２０及びＩＤＰ３  １２４も同様である。ＩＤＰ１  １１６は、また、ＩＤＰ２  １２０及びＩＤＰ３  １２４の公開キーも有する。このようにして、２つのＩＤＰの間で送られる全ての要求は、宛先ＩＤＰの公開キーを用いて暗号化することができ、送信側ＩＤＰの秘密キーを用いて署名することができる。このようにして、ＩＤＰ１  １１６がＩＤＰ２  １２０と通信する必要がある場合、ＩＤＰ２  １２０に割り当てられる公開キーを用いて要求を暗号化し、自身の秘密キーを用いて暗号化されたメッセージに署名する。ＩＤＰ２  １２０は暗号化されたメッセージを自身の秘密キーを用いて復号化し、ＩＤＰ２  １２０に記憶されるＩＤＰ１  １１６に割り当てられる公開キーを用いてＩＤＰ１  １１６の署名を確認することができる。これによって、信頼のウェブ１２８に属する各ＩＤＰは、ＩＤＰ間のデータデータ・チャネルが危険にさらされているのではないかと心配することなく信頼のウェブに属する他のＩＤＰと通信することができる。ユーザー１００は、信頼のウェブ１２８に属するＩＤＰのうちの１つに登録する。図４において、ユーザーはＩＤＰ３  １２４と関係する。ＩＤＰ３  １２４は、ユーザー１００によって提供されるアイデンティティ情報を、アイデンティティ証明書と一緒にＵＰＤ３  １２６に記憶する。ユーザー１００が信頼のウェブ１２８に属するＩＤＰのうちいずれかと関係するＥテイラー、例えばＥテイラーＢ  １３２との間にセッションを確立すると、ユーザー１００は、ＥテイラーＢにアイデンティティ証明書を提出し、証明書はその後信頼のウェブ１２８に属するシステムのうち１つに与えられる。図４に示される通り、ＥテイラーＢ  １３２はＩＤＰ２  １２０と提携している。従って、ユーザー１００のＩＤ証明書はＥテイラーＢに提示され、ＥテイラーＢがこれをＩＤＰ２  １２０に中継する。ユーザー１００のユーザー資格証明書を認証するために、ＩＤＰ２  １２０は、ユーザー１００がＩＤＰ３  １２４に加入していると判定して、公開キー及び秘密キーを用いて自身とＩＤＰ３  １２４との間に安全なデータ接続を確立する。このデータ接続は、ユーザー１００によって与えられるアイデンティティ証明書を認証するために使用される。ユーザー１００を認証したら、ＩＤＰ３  １２４はＩＤＰ２  １２０にアイデンティティ情報を提供し、これが中継されてＥテイラー１３２に返される。
【００１６】
このシステムは、ユーザー１００にシングル・サインオン機能を与え、ＩＤＰの独占主義的傾向に関する懸念に対処する。各ＩＤＰは、他のＩＤＰから独立しているので、情報の地球規模の貯蔵庫とは見なされない。従って、あるＩＤＰの機密保護が侵害されても、そのＩＤＰのユーザー・プロフィル・データベースに関係する情報のみが危険にさらされる。これは、ユーザー・プロフィル・データベースの危険がシステムの全てのユーザーに及ぶ階層的モデルに比べて有利である。
【００１７】
ただし、Ｌｉｂｅｔｒｙ  Ａｌｌｉａｎｃｅの仕様によれば、ＩＤＰには限定されたユーザー・アイデンティティ情報のセットしか記憶されない。従って、Ｅテイラーは、やはり、ＩＤＰに記憶されない情報についてユーザー１００に質問しなければならない。さらに、公開及び秘密暗号化キーは、各々のＩＤＰが、データ要求ごとに膨大な計算集約的タスクを行えることを要求する。さらに、信頼のウェブの規模が増大するにつれて、高度なキー管理システムを採用しなければならない。図４は３つのＩＤＰしか示していないが、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ仕様が提案するモデルはこれに限定されない。信頼のウェブに属するＩＤＰの数が無限に拡大できないことが、当業者には分かるだろう。ＩＤＰの数が小さいときには各ＩＤＰが他のＩＤＰを信頼できるシステムを実現することが可能であるが、ＩＤＰの数が数万にもなるとこの種のシステムは信頼できる形で実現できそうもない。
【００１８】
ユーザー１００の立場から見ると、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅが提示するモデルは、多数の欠点を有する。ユーザーのシングル・サインオン機能は多少限定的である。ユーザーには、ユーザーをユーザーが選択したＩＤＰに結びつける一意のユーザーＩＤが割り当てられる。ユーザーが信頼のウェブに属するあるＩＤＰによって認証されると、Ｅテイラーには２つ１組の一意の識別子（ＰＵＩＤ）が与えられ、将来ユーザーを識別するためにこれを使用することができる。ＰＵＩＤが２つ１組の一意なので、同じユーザーに関して２つのＥテイラーに割り当てられるＰＵＩＤは、ユーザーの購入またはアクティビティの相互相関を防止するために異なる。ユーザーに関係するＩＤＰのみがＥテイラーに与えられるＰＵＩＤを保持するので、１つのＩＤＰから別のＩＤＰへの移行はできない。ユーザーがＩＤＰ３  １２４からＩＤＰ２  １２０へ移動したい場合、全く新しいアイデンティティを作らなければならず、ＩＤＰ３  １２４に記憶される全ての情報を、ユーザーはＩＤＰ２  １２０に記憶するために再び入力しなければならない。多くのユーザーはこれを、まだ試験されていないシステムにユーザーを拘束するものであると見ている。その結果、多くのユーザーはこのサービスに登録するのを非常に躊躇している。Ｅテイラー及び潜在的ＩＤＰにとっては、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅへの参加は、ユーザー情報をどのように記憶すべきか、また統計またはマーケティングのためにどのようにユーザー情報を使用できるかを含めて、事業戦略へのある種の制約に合意することを含む。このような制約は、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅに参加したいと思う者の数を制限していると思われる。
【００１９】
ＰａｓｓｐｏｒｔTMもＬｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅも、Ｅテイラー及びユーザーの認証を必要とするその他のサイトにＰＵＩＤを与える。ＰＵＩＤは、Ｅテイラーが情報を記憶して、ユーザーに関するプロフィルを構築できるようにする一方で、２人のＥテイラーがそのデータベースを簡単に相関させて、ユーザーのアクティビティ及びパターンを判定するのを妨げる。Ｌｉｂｅｒｔｙ  ＡｌｌｉａｎｃｅにおけるＰＵＩＤは、ユーザー・プロフィルを保持するＩＤＰによって割り当てられるものであり、他のＩＤＰがこれをユーザー・アカウントと結びつけることはできないので、ユーザーがＩＤＰを変えようとするとき、各Ｅテイラーにおける全てのサイト固有の設定は全て失われる。これはユーザーを１つのＩＤＰに拘束することになり、ほとんどのユーザーにとってＰａｓｓｐｏｒｔTMが与える単一ソース以上の移植の機会を与えない。さらに、ＰａｓｓｐｏｒｔTMあるいはＬｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅによって割り当てられるＰＵＩＤの目的は、クレジットカード情報など他の情報と相関させることによって、既述の通り達成することができる。
【００２０】
現在のアイデンティティ管理システムはどれも、シングル・サインオン・サービス、多くのＥテイラーが必要とする専門情報、アイデンティティ情報の移植性を提供することができないので、どのサービスもこれまで他のサービスに取って代わることができなかった。従って、動的ユーザー情報セットを提供し、縮小拡大し、グローバル・データ記憶に依存しないアイデンティティ管理システムを提供することが望ましい。
【発明の開示】
【００２１】
（発明の概要）
これまでのアイデンティティ管理システムの少なくとも１つの不利点を除去または緩和することが本発明の１つの目的である。
【００２２】
本発明の第一の態様においては、メンバーサイトにユーザーの認証を与えるためのアイデンティティ管理システムが提供される。このアイデンティティ管理システムは、ユーザーに関連付けられるグローバル一意識別子を記憶するためのユーザー・データベースを有するルート・サーバーを含む。ルート・サーバーは、ユーザーにグローバル一意識別子を与えるための手段、及びドメインネーム・サーバーに与えるためにシャドウ・ドメインの名前と関連付けられるネットワーク・アドレスのリストを維持するための手段を有し、各名前はアイデンティティ管理ネットワークに属するメンバーサイトかホームサイトに関連付けられる。ルート・サーバーは、ユーザーがシャドウ・ドメインにおけるホームサイトに関連付けられる名前にリダイレクトされるとき、ホームサイトが、メンバーサイトにアクセスする実行主体をグローバル一意識別子に関連付けられるユーザーとして認証できるようにする。ルート・サーバーは、任意に、グローバル一意識別子に関連付けられるユーザーとして実行主体を認証するためのホームサイトの権限の認証をメンバーサイトに与えるためのホームサイト認証メッセージを含むことができる。
【００２３】
本発明の第一の態様の１つの実施態様においては、アイデンティティ管理システムは、ルート・サーバーと通信しかつユーザー・プロフィル・データベース、ユーザー認証エンジン及びシャドウ・ドメインのネームスペースにドメイン名を有するホームサイトを含む。ユーザー・プロフィル・データベースは、ユーザーに関連付けられるグローバル一意識別子及び認証情報の両方を記憶する。認証エンジンは、ホームサイトがユーザーのアイデンティティを認証できるようにする。認証情報は、任意に、ユーザーＩＤとパスワードの組み合わせである。別の実施態様においては、ユーザー・プロフィル・データベースは、さらに、ユーザーに関連付けられるアイデンティティ情報を記憶し、認証エンジンは、ユーザーを認証するときアイデンティティ情報のサブセットをメンバーサイトに提供するための手段を含む。本発明のさらなる実施態様においては、認証エンジンは、メンバーサイトによって読み取り可能な認証情報を含むクッキーをユーザーに与えかつユーザーをメンバーサイトにリダイレクトすることによって、認証されたユーザー・アイデンティティをメンバーサイトに与える。クッキーは、任意にホームサイトの署名入りであり、そのホームサイトがグローバル一意識別子を認証する権限を有することのルート・サーバーからの表示を含む。表示は、任意に、ルート・サーバーの署名入り表明である。別の実施態様においては、認証エンジンは、認証符号化ユニバーサル・リソース・ロケータにユーザーをリダイレクトすることによって、あるいはメンバーサイトによって読み取り可能な認証情報を含むクッキーをユーザーに与えかつユーザーをメンバーサイトにリダイレクトすることによって、ユーザーに関連付けられるアイデンティティ情報をメンバーサイトに提供する。
【００２４】
本発明の第二の態様においては、アイデンティティ管理ネットワークのメンバーサイトにユーザー認証を与える方法が提供される。この方法は、ホームサイトの名前を取得するステップ、ホームサイトに認証要求を与えるステップ、及びホームサイトからユーザーの認証を取得するステップを含む。ホームサイトの名前を取得するステップは、ホームサイトにとって既知のユーザー認証情報に基づいてユーザー認証を与えることができるホームサイトの名前をユーザーから取得するステップを含む。ホームサイトに認証要求を与えるステップは、アイデンティティ管理ネットワークに関連付けられるシャドウ・ドメインにおけるホームサイトにユーザーをリダイレクトするステップを含む。認証を取得するステップは、ホームサイトがユーザーから既知の認証情報を受け取るのに応答してホームサイトからユーザーの認証を取得するステップを含む。認証情報は、ユーザーに関連付けられるグローバル一意識別子を含む。第二の態様の１つの実施態様においては、ユーザーからホームサイトの名前を取得するステップは、メンバーサイトがユーザーによって与えられるクッキーを検査するステップを含む。別の実施態様においては、ホームサイトに認証要求を与えるステップは、ユーザーがシャドウ・ドメインにおけるホームサイトに関連付けられる名前をネットワーク・アドレスに転換するステップを含む。さらに別の実施態様においては、ホームサイトに認証要求を与えるステップは、メンバーサイトが、ホームサイトによって読み取り可能なユーザー認証要求を含むクッキーをユーザーに与えるステップを含む。さらに別の実施態様においては、ホームサイトは、ユーザー認証情報及びユーザー・アイデンティティ情報の両方を提供することができ、ホームサイトに認証要求を与えるステップは、さらに、メンバーサイトがホームサイトにアイデンティティ情報要求を与えるステップを含み、一方、認証を取得するステップは、さらに、ホームサイトがユーザーから既知の認証情報を受け取るのに応答して識別情報を取得するステップを含む。さらなる実施態様においては、この方法は、ホームサイトが提供するのではないアイデンティティ情報を取得するステップ、及びユーザーをシャドウ・ドメインにおけるホームサイトにリダイレクトすることによって取得されたアイデンティティ情報をホームサイトに提供するステップを含み、ホームサイトによって提供されるのではないアイデンティティ情報は、ユーザーから取得する。
【００２５】
本発明の第三の態様においては、アイデンティティ管理ネットワークに属するホームサイトにおいてユーザー認証を行う方法が提供される。この方法は、グローバル一意識別子及び既知の認証情報を有するユーザーからメンバーサイトのために認証を与えるよう求める要求を受け取るステップ、及び既知の認証情報の受け取りに応答して、アイデンティティ管理ネットワークに関連付けられるシャドウ・ドメインにおけるメンバーサイトにユーザーをリダイレクトすることによってメンバーサイトにユーザーの認証を与えるステップを含む。第三の態様の１つの実施態様において、メンバーサイトにユーザーの認証を与えるステップは、ユーザーのグローバル一意識別子に関連付けられるユーザーＩＤとパスワードの組み合わせをユーザーから受け取るステップを含む。別の実施態様において、メンバーサイトにユーザーの認証を与えるステップは、ユーザーがシャドウ・ドメインにおけるメンバーサイトに関連付けられる名前をネットワーク・アドレスに転換するステップを含み、さらに、ユーザーの認証を与えるステップは、任意に、ホームサイトが、メンバーサイトによって読み取り可能な、ユーザーの認証及びユーザーに関連付けられるグローバル一意識別子を含むクッキーをユーザーに与えるステップを含む。他の実施態様において、認証情報を与えるよう求める要求を受け取るステップは、アイデンティティ情報要求を受け取るステップを含み、認証を与えるステップは、既知の認証情報をユーザーから受け取ったらメンバーサイトに識別情報を与えるステップを含み、またメンバーサイトに識別情報を与えるステップの前に、要求される識別情報をメンバーサイトに転送するためのユーザーの許可を取得するステップが含まれる。別の実施態様において、この方法は、メンバーサイトから取得したアイデンティティ情報をユーザーから受け取るステップ、及び転送されたアイデンティティ情報をユーザー・プロフィル・データベースに記憶するステップを含む。
【００２６】
本発明の別の態様においては、ｅメール・アドレスを有するユーザーに関連付けられるグローバル一意識別子を取得する方法が提供される。この方法は、グローバル一意識別子をｅメール・アドレスと関連付けるよう求める要求をユーザーから受け取るステップ、グローバル一意識別子をｅメール・アドレスと関連付けるルート・サーバーにユーザーのｅメール・アドレスに関連付けられるグローバル一意識別子の割り当てを要求するステップ、及びユーザーがｅメール・アドレスに送られる誰何に対する応答をルートに与えるのに応答してｅメール・アドレスに関連付けられるグローバル一意識別子を取得するステップを含む。
【００２７】
本発明の他の態様及び特徴は、添付図面と一緒に本発明の特定の実施態様に関する以下の説明を読むことによって、当業者には明らかになるだろう。
【発明を実施するための最良の形態】
【００２８】
（詳細な説明）
一般的に言って、本発明は、アイデンティティ管理のための方法及びシステムを提供する。
【００２９】
アイデンティティ管理システムが成功するためには、ユーザーが、その個人情報を記憶する実行主体を信頼しなければならず、また、ユーザーにシステムの使用を促す一連の特性が与えられなければならない。充分なユーザー・ベースがなければ、アイデンティティ管理システムはサービス・プロバイダを惹きつけることができないので、成功しない。
【００３０】
ユーザーの立場から見ると、システムは、信頼できる実行主体への単純な登録プロセスを提供しなければならない。登録後、単一のログインを用いてサービスにログインする単純な方法がユーザーに提供されなければならず、また、これらのサービスに登録するために単純なメカニズムが提供されなければならない。ユーザーには、信頼される実行主体に追加情報を提供するための単純なメカニズムが提供されなければならない。最後に、ベンダー/サービス・プロバイダと信頼される実行主体との間の対話が、ほとんどユーザーにとって透明でなければならない。
【００３１】
ベンダーまたはサービス・プロバイダの立場から見ると、伝統的なアイデンティティ管理システムは、ベンダーと認証機関との間に高度の信頼が要求されるので、これまで問題があった。この信頼の問題は、本発明においては、ユーザーに信頼責任を委譲することによって解決される。ユーザーがある実行主体を信頼して自分の個人情報を保持させ認証機関としての機能を果たさせるなら、ベンダーは、ユーザーがその信頼関係に満足していると納得できるので、ベンダーは認証機関を信頼できる。この信頼関係は、認証機関がアイデンティティ管理ネットワーク内にとどまる限り充分なものである。
【００３２】
認証機関の立場から見ると、ユーザーとの間に結ばれる合意は、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅの場合のように中央団体によって指示されるのではなく、認証機関の業務上のニーズに役立つように考案することができる。さらに、認証メカニズムは、認証機関とユーザーの合意に委ねられる。従って、それぞれの認証機関が、ユーザーＩＤとパスワードの組み合わせ、スマート・カード、バイオメトリック・サンプリング及びその他の既知のユーザー認証法などそれぞれの認証メカニズムを採用することができる。ユーザーが、認証機関が提供する認証メカニズムあるいはサービスに幻滅したら、ユーザーはアイデンティティ情報を記憶し認証するために使用される認証機関を変更することができる。
【００３３】
ネットワークを運営するために、中央機関が確立される。この中央機関は、ユーザー・アイデンティティ情報を記憶するために認証機関が使用するスキーマを定義する。これによって、アイデンティティ管理ネットワークに属するベンダーは事前定義フィールドに情報を要求することができる。中央機関は、また、ベンダー及び認証機関の両方に、通信相手がアイデンティティ管理ネットワークの一部であることを保証するメカニズムを提供する。
【００３４】
インターネットなど公衆通信網に接続される全てのコンピュータ・システムは、割り当て数字ネットワーク・アドレスを有する。このアドレスは、一意識別子として役立ち、さらに、あるネットワーク・ノード向けのパケットをこの指定されるノードに効果的にルート指定できるようにルーティング情報を与える。ネットワークと人間との対話のためのアドレス指定を単純化するために、英数字ドメイン名がノードに割り当てられ、英数字ドメイン名を数字アドレスに変換できるようにするために一般にドメインネーム・サーバー（ＤＮＳ）を通じてルックアップ機能が与えられる。これらの技法は当業者には周知である。ドメイン名システムのもう１つの既知の使用は、ドメイン内のシステムへのアクセスを制限するためのものである。英数字ドメイン名を用いて送信をアドレス指定するだけで、送信側システムは、その英数字ドメイン名で指定されるドメイン外のシステムがパケットを受け取るのを制限することができる。ＤＮＳシステムの相対的機密保護は、世界的に悪意のリダイレクトがないと、ほぼインターネット全体から信頼されている。本出願において言及される場合、シャドウ・ドメインとは、中央機関のネームスペースの下でインターネットにおいて生成されるドメインである。アイデンティティ管理ネットワークに属する全ての実行主体は、シャドウ・ドメインにおいて名前の割り当てを受けることができ、この名前はその実行主体に関連付けられる数字アドレスに転換される。このようにして、ベンダーは、その一次ドメインと同じ数字アドレスに転換されるシャドウ・ドメイン・アドレスを持つか、または一次ドメインとは異なるがベンダーが支配するその他のシステムに関連付けられる数字アドレスに転換することができるシャドウ・ドメイン・アドレスを持つことができる。ベンダー及び認証機関の両方が確実にアイデンティティ管理ネットワークに属するようにするために、本発明においてシャドウ・ドメインを用いる技法を使用することが望ましい。
【００３５】
以下の説明は、アイデンティティ管理ネットワークのアーキテクチャ及び各実行主体の役割の概要であり、このアーキテクチャが、どのようにしてユーザーのアイデンティティ管理ネットワークへの登録、シングル・サインオン機能、認証機関が記憶するユーザー情報を必要とするサービスのための単純化された登録、認証機関がユーザー・データを記憶するために使用するスキーマを更新するためのメカニズム、ベンダーまたはサービス・プロバイダがユーザー情報を認証機関にバックフィルするためのメカニズム、ユーザーが全てのサインインを維持したまま既に記憶されている情報を提供することなく認証機関を変更するためのメカニズムを提供するか、を示す。さらに、このアーキテクチャから生じる機密保護の特性及び証明書の署名及びキーのための新しい信頼の鎖が、本発明のアーキテクチャ及び方法のその他の利点と一緒に紹介される。
【００３６】
以下の説明において、中央認証機関は階層的分散アイデンティティ管理ネットワークのルートまたは単にルートと呼ばれる。認証機関は、ユーザー・データのホームを提供するのでホームサイト（ＨＳ）と呼ばれる。ユーザー認証あるいはユーザー・アイデンティティ情報を要求するサイトはメンバーサイト（ＭＳ）と呼ばれる。ユーザーはそのままユーザーと呼ばれる。
【００３７】
図５は、本発明の階層的分散アイデンティティ管理システムに使用されるアーキテクチャを示している。図５には４つの実行主体、すなわちユーザー２００、ホームサイト（ＨＳ）２０２、メンバーサイト（ＭＳ）２０６及びルート２１０が示されている。認証及びアイデンティティ管理において果たす役割に関連して各実行主体について説明する。図５は単なる例なので、付加的なホームサイト及びメンバーサイトが存在するかもしれないが、これらは図には示されていない。
【００３８】
ユーザー２００は、インターネットなど一般公衆通信網への接続を有するユーザーである。ユーザー２００は、住所、請求書発行情報及びカレンダー・ベースの情報などその他の個人情報など、自身のアイデンティティに関連する情報を有する。ユーザー２００は、このアイデンティティ情報を記憶してシングル・サインオン・サービスのためにアイデンティティ認証を与えるためのホームサイト（ＨＳ）２０２を選択する。
【００３９】
ＨＳ２０２は、ユーザー２００に関するアイデンティティ情報を記憶するために使用されるユーザー・プロフィル・データベース（図には示されていない）を含む。ＨＳは、また、グローバル一意識別子（ＧＵＩＤ）をユーザー２００のアイデンティティ情報と関連付ける。ＧＵＩＤは、ルート２１０によってＨＳ２０２に割り当てられるグローバル一意識別子であり、その方法については後で説明する。ＨＳ２０２は、一意のネットワーク・アドレス、及び図においてはhomesite.comとして示されるこのアドレスと関連付けられるドメイン名２０４を有する。従って、ＨＳ２０２にアクセスするために、ユーザー２００はウェブ・ブラウザをwww.homesite.comに導くことができ、ドメインネーム・サーバー（ＤＮＳ）を通じてアドレスはＨＳ２０２のアドレスに転換される。
【００４０】
メンバーサイト２０６（ＭＳ）は、そのネットワーク・アドレスと関連付けられるドメイン２０８membersite.comを有する公衆インターネット１０２上のノードである。ＭＳ２０６は、ユーザー２００が申し込むサービスを提供するか、またはユーザー２００が購入したい製品を販売する。ユーザー２００がサインインできるようにするために、またはユーザー２００に関する個人情報を取得するために、ＭＳ２０６は、ユーザー２００の認証かまたはユーザー２００に関する１組の情報を要求する。
【００４１】
ユーザー２００は、ホームサイト２０２（ＨＳ）にアイデンティティ情報を提供する。ユーザー２００によってＨＳ２０２に提供される情報に１組の身元証明書が関連付けられる。以下の説明において、ユーザー証明書はユーザーＩＤとパスワードの組み合わせとして示される。しかし、バイオメトリック読み取り、スタティックＩＰトレース及びスマート・カード派生情報を含めて他のいくつの認証方法でも、ユーザーＩＤとパスワードの組み合わせの代わりに使用することができることが、当業者には分かるだろう。
【００４２】
ＨＳ２０２は、従来のドメイン名システムを通じてそのＩＰアドレスと関連付けられる一次ドメイン２０６homesite.comを有する。ユーザー２００またはネットワーク上のその他のシステムは、数字ＩＰアドレスを通じてもＩＰアドレスに関連付けられるドメイン名を通じても、ＨＳ２０２にアクセスすることができる。ＭＳ２０６にも、一意の数字ＩＰアドレス、またはそのＩＰアドレスに関連付けられるドメインを用いてアクセスすることができる。インターネット１０２（図には示されていない）において一次ドメインを有するだけでなく、ＨＳ２０２もＭＳ２０６も、ルート２１０が管理するシャドウ・ドメインを通じて相互に接続される。ルート２１０は、アイデンティティ管理ネットワーク２１２に関連付けられるシャドウ・ドメインを管理する。このようにして、ユーザー２００はＨＳ２０２にその一次ドメインhomesite.comでアクセスでき、またＭＳ２０６にその一次ドメインmembersite.comでアクセスでき、ＨＳ及びＭＳには、シャドウ・ドメインにおいてそれぞれhomesite.com.root.net及びmembersite.com.root.netでアクセスすることができる。一次ドメイン名及びシャドウ・ドメイン名の対は、必ずしも同じアドレスではないが、どちらも同じ実行主体に帰着することが、当業者には分かるだろう。ルート２１０が管理するシャドウ・ドメインは、アイデンティティ管理ネットワーク２１２として図に示されている。図５のモデルにおいては、アイデンティティ管理及び認証は、階層的分離アイデンティティ管理システムによって与えられる。このシステムにおいては、メンバーサイトは、ユーザーの認証を同じシャドウ・ドメインの任意のホームサイトに依存する。以前のアイデンティティ管理システムにおいてはＩＤＰとＥテイラーとの間に一定の信頼が存在しなければならないのでＥテイラーまたはその他のサービス・プロバイダからの抵抗があったが、本発明のモデルはその必要をなくす。ＭＳ２０６は、ユーザー２００であることを主張するユーザー２００が以前提出したのと同じ証明書を認証のために提出したことを認証するためにのみ、ＨＳ２０２に依存する。ＨＳ２０２のインテグリティ、商行為倫理及びユーザー２００の情報をどのように取り扱うかについては、もはやメンバーサイト２０６にとって関係なく、ＭＳ２０６は、ＨＳ２０２が信頼に足るか否かの判断はユーザー２００に委ねる。このモデルにおいてあるホームサイトが信頼に足りないと複数のユーザーが判断する場合、ユーザーはそのホームサイトを使用せず、ルート２１０がそのホームサイトをインターネットから除くように要請することができる。このように、ホームサイトの取り締まりは、ベンダーではなくユーザーに割り当てられる義務である。さらに、ネットワークは分散されるので、メンバーサイトが同時にホームサイトになりえないと言う主張による制限はない。その結果、メンバーサイトが同時にホームサイトとして行動できるようにすることによって、ＩＤＰが事業を不法に使用して顧客を盗むのではないかという恐れに対処することができる。メンバーサイトまたはホームサイトに課せられる唯一の要件は、シャドウ・ドメインの一部であることである。
【００４３】
ＨＳ２０２においてアイデンティティ・プロフィルを確立するために、ユーザー２００は、プロフィル情報及びユーザーＩＤ及びパスワードなどの証明書を提出し、ユーザーがＨＳ２０２の認証を受けられることを示すトークンを受け取る。現在望ましい実施態様においては、トークンはホームサイト・クッキーと呼ばれるクッキーである。このトークンは、シャドウ・ドメインに属するどのような実行主体にもアクセス可能である。ユーザー２００がＭＳ２０６を訪れるとき、ユーザーはシャドウ・ドメインにリダイレクトされる場合のみこのトークンを提示する。これを行うために、ＭＳは、アイデンティティ管理ネットワーム２１２にアイデンティティ情報が記憶されている全てのユーザーは登録か認証のためにクリックするよう指示するリンクを与えることができる。このリンクは、ホームサイト・クッキーを検索することができるようにユーザーをシャドウ・ドメイン２０８にリダイレクトする。次に、ユーザーは第二のクッキーを与えられ、一次ドメインかシャドウ・ドメインにおけるＨＳ２０２に導かれることができる。その代わりに、ＭＳ２０６を訪れるとき、ユーザー２００はシャドウ・ドメイン２１６にリダイレクトされ、その後ログイン要求の前にクッキーが検索されるように一次ドメイン２０８に戻される。ＨＳ２０２を通じての認証を要求するとき、ＭＳ２０６はユーザー２００に第二のクッキーを与えることができる。第二のクッキーは、認証を要求し、署名を必要とする誰何（チャレンジ）をＨＳ２０２に与えるために、使用することができる。これはＨＳ２０２がアイデンティティ管理ネットワーク２１２に属しかつユーザー２００を認証する権限を有することを保証するために使用することができる。このリダイレクトは、ユーザーに対して透明に行うことができる。ユーザー２００はアイデンティティ管理ネットワーク２１２に相当するシャドウ・ドメインを起点とする要求に対してしかクッキーを与えることができないので、ＨＳ２０２およびＭＳ２０６がアイデンティティ管理ネットワーク２１２内にあると言う確認は、要求が遂行されることによって得られる。認証及び情報転送がどのように行われるかについてのより詳細な説明を下に示す。
【００４４】
ルート２１０は、ＨＳ２０２およびＭＳ２０６のためにそれぞれシャドウ・ドメインhomesite.com.root.net２１４及びmembersite.com.root.net２１６を生成することによって、ＨＳ２０２及びＭＳ２０６がアイデンティティ管理ネットワーク２１２に加盟していることを確認できるようにするためにシャドウ・ドメインを管理する。ルート２１０は、また、ＨＳ２０２との対話によってグローバル一意識別子（ＧＵＩＤ）をユーザーに割り当てる機能及び標準化された方法でメンバーサイトが複数のホームサイトに情報を要求できるようにする情報スキーマを定義する機能を含めてその他の多数の機能を果たす。ルート２１０は、また、ＭＳ２０６がＨＳ２０２から暗号化証明書を取得しその信憑性の保証を受けるためのメカニズムを用意する。ルート２１０は、ドメインroot.netを管理するので、アイデンティティ管理ネットワーク２１２に実行主体を含めたり除外したりするためにＤＮＳルックアップ項目を追加及び除外することができる。このように、シャドウ・ドメインは、メンバーサイト及びホームサイトが、認証または情報交換の相手がネットワーク内に留まっていることを確認できるようにするために、アイデンティティ管理ネットワーク２１２においてルート２１０によって管理される。ルート２１０は、また、ユーザーの認証と一緒にメンバーサイトに与えるために、ユーザーを認証する権限を有するホームサイトを識別する署名つき表明をＨＳ２０２に与えることが望ましい。
【００４５】
ＩＤＰ間の信頼関係を除外することによってこのモデルに伴うスケーラビリティの問題の多くを除外することが、当業者には容易に分かるだろう。単一のルート２１０は多数のホームサイトを受け入れるのに充分な大きさのドメインを管理することができ、これによって、シャドウ・ドメインに属する各メンバーサイトが、各ホームサイトでユーザー情報を認証できるようにする。
【００４６】
階層的分散構造がどのように動作するかを理解するために、次にいくつかの標準動作について説明する。これらの方法は単なる例であり、本発明の範囲を限定するものとして見るべきではないことが、当業者には分かるだろう。
【００４７】
当業者には分かる通り、アイデンティティ管理システム２１２は、一意識別子で各ユーザーを識別することが望ましい。以前のアイデンティティ管理システムは、ＰＵＩＤを割り当てていたが、本発明の現在望ましい実施態様は、ユーザーＩＤを、単一のＨＳと関連付けられかつ別のＨＳに動かすことができるように移植可能なグローバル一意とすることができる。このために、各ユーザーには、ルート２１０によって割り当てられ、ルート２１０によってユーザー及びＨＳの両方に関連付けられるグローバル一意識別子（ＧＵＩＤ）が割り当てられる。ユーザーがその後ホームサイトを変更したい場合、ルート２１０は、その要求を認証し、ユーザーに関する全ての情報を新しいＨＳに転送するように現在のＨＳの指示することができる。ユーザーがＭＳにサービスを申し込むときまたはトランザクションを完了するとき、ＭＳにＧＵＩＤが与えられるので、ＭＳは、ＨＳが変わった後でも容易にユーザーを識別できる。ユーザーとＨＳとの対話において、ＨＳは、識別を容易にするためにユーザーが先行技術のユーザーＩＤのようなユーザーが使いやすい識別子をＧＵＩＤと関連付けられるようにする。ある一意のユーザーＩＤとパスワードの組み合わせまたはその他のユーザー認証メカニズムによって、ＨＳ２０２はユーザー２００を認証し、ＨＳ２０２がユーザーを認証する権限を有すると言うルートの署名入り表明と一緒に、関連するＧＵＩＤをＭＳ２０６に与えることができる。このようにして、ユーザー２００は、使いやすいユーザーＩＤを用いてＨＳ２０２と対話するが、アイデンティティ管理ネットワーク２１２の他の全てのシステムにとっては、ユーザー２００はＧＵＩＤによって表される。ＧＵＩＤは、ルート２１０によって割り当てられるものであり、ＨＳ２０２がルート２１０によって確認できる有効なｅメール・アドレスをユーザー２００のために用意できる場合のみＧＵＩＤが割り当てられることが望ましい。ＨＳ２０２が、アイデンティティ管理システム２１２に関心のないユーザーのために不適切にＧＵＩＤを要求したりこれを生成したりしないようにするために、ｅメール・アドレスの有効性を確認することが望ましい。
【００４８】
図６は、アイデンティティ管理ネットワークにおけるユーザー２００の登録に使用されるステップを示すフローチャートである。各ＧＵＩＤは、ホームサイト及びホームサイト固有のユーザー識別子と関連付けられるので、各ホームサイトは、各ユーザーに適切なユーザーＩＤを決定する独自の方法を採用することができる。ＧＵＩＤは、ネットワーク全体を通じて一意であるようにするために、またホームサイトがネットワーク内に架空のユーザーを創造しないようにするために、ルート２１０によって割り当てられる。ステップ２２０において、ユーザー２００は、ホームサイト２０２に登録して、ホームサイト固有のユーザーＩＤを要求する。このユーザーＩＤにＧＵＩＤが関連付けられる。この要求を行う際、ユーザー２００はホームサイトに２０２に有効なｅメール・アドレスを示す。ステップ２２２において、ホームサイト２０２は、ＧＵＩＤを取得する前に、ユーザーのｅメール・アドレスをルート２１０に知らせて、このユーザーｅメール・アドレスにＧＵＩＤを割り当てるように要求する。ホームサイト２０２からＧＵＩＤ割り当て要求を受け取ると、ステップ２２４において、ルート２１０は、このｅメール・アドレスに認証チャレンジを送ることによってｅメール・アドレスの有効性を確認する。ユーザー２００は、送信されるｅメールにおいて認証チャレンジを受け取り、ステップ２２６において、ｅメール・アドレスの有効性を証明するためにルート２１０及びホームサイト２０２の両方と通信する。チャレンジ応答の受け取りに成功したら、ルート２１０は、このeメール・アドレスにＧＵＩＤを割り当て、このＧＵＩＤを有効なｅメール・アドレス及びＧＵＩＤを要求したホームサイトに関連付けられるホームサイト識別子の両方と関連付ける。ＧＵＩＤは、ＨＳ２０２がＧＵＩＤを認証する権限を有することをＭＳに証明するためにＨＳ２０２をＧＵＩＤに関連付ける、ルート２１０の署名入り表明においてＨＳ２０２によって記憶されることが望ましい。ＧＵＩＤとｅメール・アドレスを関連付ける同様の表明も記憶することができる。これらの表明は、ユーザーがそのＧＵＩＤを別のＨＳに移した後にＨＳ２０２がユーザーを認証できないようにするために、署名入りで、満了日が示されることが望ましい。別の実施態様においては、ある実行主体がアイデンティティ管理ネットワーク２１２にホームサイトとして参加するとき、このホームサイトは、既存のアカウントのｅメール・アドレスが有効であることをルート２１０が納得するように立証することができ、ルートは、ｅメール・アドレスにチャレンジを送ることなく、各既存のアカウントのためにＧＵＩＤを発行することができる。これによって、既存のユーザー・ベースを有するホームサイトは、既存の各ユーザーにチャレンジｅメールへ応答させることなく、アイデンティティ管理ネットワーク２１２に参加することができる。ｅメール・アドレスの有効性をルート２１０に立証するために、ホームサイトは、ｅメール・アドレスの有効性の証拠としてユーザーへの以前の送信の証拠を提出することができる。
【００４９】
信頼関係は、ユーザー２００とＨＳ２０２との間のことなので、チャレンジｅメールは、ＨＳ２０２のアイデンティティの刻印が押されることが望ましいかも知れない。このために、ＧＵＩＤの要求と一緒に、ＨＳ２０２は、チャレンジと一緒に使用するためのｅメール・テンプレートをルート２１０に提供することができる。このようにして、提供されたテンプレートを用いて、ルート２１０はＨＳ２０２のブランドのｅメールを送ることができる。テンプレートによって、ＨＳ２０２は、確実にユーザーにＨＳ２０２のロゴ入りのチャレンジｅメールを与えることができ、またチャレンジｅメールがＨＳ２０２によって指定される言語で与えられるようにすることができる。これによって、サインイン・プロセスはユーザーにとってはシームレスである。
【００５０】
現在望ましい実施態様において、ステップ２２４のｅメール・メッセージでチャレンジを送るステップは、チャレンジ符号化ＵＲＬをユーザーに送ることによって行われる。ステップ２２６において、ユーザーはＵＲＬをクリックすることによってチャレンジに応答し、宛先アドレスに導かれる。リンクを通じてユーザー２００がクリックすることができることは、有効なユーザーがｅメール・メッセージを受け取ったことの充分な証拠と見なされる。ルート２１０は、ユーザーがクリックスルーしたことの確認を受け取るまでは、ＨＳ２０２にＧＵＩＤを発行しない。これは、チャレンジＵＲＬがユーザー２００をルート２１０に導くようにし、ルートがその後ＧＵＩＤと一緒にユーザー２００をＨＳ２０２にリダイレクトすることによって行うか、あるいはチャレンジはユーザー２００をＨＳ２０２に導き、ユーザー２００の代わりにルート２１０に与えるためにＨＳ２０２にチャレンジ応答を与えることができる。ＵＲＬは、ＨＳ２０２の従来のアドレスかあるいはＨＳ２０２がアイデンティティ管理ネットワーク２１２に属することのさらなる保証として役立つようにそのシャドウ・ドメイン・アドレスに導くことができる。
【００５１】
現在望ましい実施態様においては、ルート２１０かホームサイト２０２は、ユーザー２００を確認すると、ホームサイト、メンバーサイト及びルート２１０から成るシャドウ・ドメインのどのメンバーにもアクセス可能なクッキーをユーザー２００に与える。クッキーの授与は任意のステップ２２８である。このクッキーは、ＨＳクッキーと呼ばれることが望ましく、ユーザーを認証するために使用されるべきホームサイトを識別する。現在望ましい実施態様においては、ユーザーに与えられるホームサイト・クッキーは、ユーザーをリダイレクトすべきロケーションをＭＳ２０６に与え、さらにＨＳの証明書を取得できるロケーションをＭＳ２０６に与えるｈｔｔｐ  ＵＲＬを与えることによって、ホームサイトを識別する。別の実施態様において、ホームサイト・クッキーは、ユーザーをどこにリダイレクトすべきかを示すＵＲＬ及びＭＳ２０６がホームサイトから証明書を取得できるところを示すＵＲＬを含めて多数のＵＲＬを与えることができる。ＨＳ証明書を取得することは、下に説明する通り署名の確認のために重要である。別の望ましい実施態様において、クッキーは、ホームサイト２０２を識別し、かつ識別されたホームサイトがユーザーを認証できるホームサイトであるというルート２１０による表明を含む。ＭＳ２０６がコマンドＵＲＬと呼ばれるものからユーザーをリダイレクトすべきところに関する情報を取得しながら、ＨＳ証明書を取得する場所に関する情報を証明書ＵＲＬから取得できることが、当業者には分かるだろう。これらのＵＲＬはどちらも、ホームサイト・クッキーの中に含めることができ、ＤＮＳシステムにおいて与えることができ、さらにＨＳ証明書においてコマンドＵＲＬを与えることができる。このように、ホームサイト・クッキーは証明書を取得できるロケーションを参照でき、証明書において、ＭＳ２０６は、ＨＳ２０２のロケーションを見つけるか、あるいは、ＵＲＬの一部のみがクッキーの中にあり、このＵＲＬの断片に基づいて、ＭＳ２０６は、既知の接頭辞及び接尾辞を付け足して、コマンドＵＲＬ及び証明書ＵＲＬの両方を生成する。
【００５２】
上述の登録プロセスについて、次に３つの立場、すなわちユーザー２００、ホームサイト２０２及びルート２１０の立場から説明する。ユーザー２００の立場から見ると、ユーザー２００はホームサイト２０２を訪問して、アイデンティティ管理アカウントを要求する。この要求を行う際、ユーザー２００は、有効なｅメール・アドレスを提供し、プロセスを完了するためにｅメール・メッセージが提供されたｅメール・アドレスに送られることを知らされる。このｅメール・メッセージを受け取ったら、ユーザー２００は、望ましくはＵＲＬをクリックしてｅメール・アドレスの有効性を確認することによって、このチャレンジに応答する。この時点で、ユーザー２００は、直接的あるいは間接的に、ホームサイト２０２に接続されて、アイデンティティ管理アカウントが確立される。従って、ユーザー２００の立場から見ると、アカウントの登録は、ルートが透明に関わっているのでユーザー２００がルート２１０を信頼するかどうかに全く依存しない単純なプロセスである。その代わりに、信頼の問題は全てユーザー２００がホームサイト２０２を信頼するかどうかに関係する。ホームサイト２０２の立場から見ると、ホームサイト２０２は、ユーザー２００から新規のアイデンティティ管理アカウントの要求を受ける。この要求にはｅメール・アドレスが添付される。ｅメール・アドレスは、次に、ＧＵＩＤ割り当ての要求と一緒にルート２１０に転送される。ホームサイト２０２は、チャレンジの応答に成功すると、ＧＵＩＤを受け取る。現在望ましい１つの実施態様においては、チャレンジへの応答は、リダイレクトＵＲＬを通じてユーザー２００によってホームサイト２０２に与えられる。このチャレンジ応答は、次にホームサイト２０２によってルート２１０に送られ、これに応答して、ルート２１０はホームサイト２０２にユーザー２００と関連付けるためのＧＵＩＤを与える。代替実施態様においては、チャレンジ応答は、ユーザー２００からルート２１０に直接与えられ、ホームサイト２０２は、ルート２１０によってユーザー２００がホームサイト２０２にリダイレクトされるときにＧＵＩＤを受け取る。実際のルートＧＵＩＤを送信するためのルート２１０とホームサイト２０２との間の通信は、ユーザーにとって透明であるように行われることが望ましいことが、当業者には分かるだろう。当業者には明らかな通り、ルート２１０とＨＳ２０２との間で透明に情報を送るのは、リダイレクトにおいて符号化ＵＲＬを使用し、ポスト・ベースのＨＴＴＰ要求と一緒にユーザーをリダイレクトし、転送メカニズムとしてクッキーと一緒にユーザーをリダイレクトし、特にバック・チャネル通信を使用することによって行うことができる。このチャネルを、後にホームサイトとメンバーサイトとの間の通信に使用することができる。
【００５３】
ルート２１０の立場から見ると、ルート２１０は、新規のＧＵＩＤを提供されたｅメール・アドレスと関連付けるよう求める要求をホームサイト２０２から受ける。ｅメール・アカウントが有効であることを確認するために、ルート２１０はチャレンジを含むｅメール・メッセージをｅメール・アカウントに送る。チャレンジは符号化ＵＲＬであることが望ましく、ユーザー２００はこれをクリックする。ユーザー２００がチャレンジ符号化ＵＲＬをクリックしたら、ルート２１０は、ユーザー２００かホームサイト２０２からチャレンジ応答を受け取る。このチャレンジ応答を受け取ったら、ルートはこのｅメール・アドレスにＧＵＩＤを割り当て、これをホームサイト２０２と関連付ける。このＧＵＩＤは、既知の技法を用いてホームサイト２０２に送信される。
【００５４】
このプロセスは、ルートが有効な理由なくホームサイトにＧＵＩＤを割り当てないようにすることが、当業者には分かるだろう。これによって、アイデンティティ管理システムのインテグリティが維持される。
【００５５】
ＧＵＩＤを割り当てる他にルート２１０のもう１つの役割は、ＨＳ２０２がアイデンティティ・データを記憶するために使用するスキーマの定義である。スキーマが定義されることによって、ＭＳ２０６はユーザー情報のサブセットを要求することができ、適切な応答を得るために事前定義されたフィールド名を用いてどのような要求でも行うことができる。現在望ましい実施態様において、ＨＳ２０２がスキーマ全体を記憶する必要はなく、ＨＳが記憶していないユーザーに関する情報を提供するよう求められる場合、ＨＳ２０２は要求された情報を記憶していないことをユーザー２００に知らせて、これを提出するようユーザーを促して、その後記憶され取得された情報をＭＳ２０２に送るか、または要求される情報のうち記憶されるサブセットをＭＳ２０６に提供して、それ以上の情報をユーザー２００に求めることはＭＳ２０６に委ねる。ユーザーに関するスキーマ全体を記憶することをＨＳ２０２に求めない結果として、ルートは、定期的な間隔でスキーマに新しいフィールドを追加することができる。これにより、ルート２１０は、新規の報奨プログラムまたはメンバーサイトからの予期せぬ要求に関する情報を記憶するために新しいフィールドを加えることができる。先行技術のシステムにおいては、スキーマは一度定義されると固定的になり、新しいフィールドをスキーマに加えることは不可能ではないにしても、困難であった。ホームサイト２０２にスキーマ全体を記憶することを強要しないことによって、ルート２１０は、いつでもスキーマを更新でき、ホームサイトが自身の都合で新しいスキーマに接続しこれを要求するのに任せることができる。このようにして、ホームサイト２０２は、決められた定期的な間隔で、新規のＧＵＩＤが要求されるとき、またはルート２１０との他のトランザクションに伴って、またはホームサイト２０２が定義するその他のスケジュールを用いて、新しいスキーマをチェックすることができる。現在望ましい実施態様においては、スキーマは多様な情報を取得するために問い合わせできる拡張可能メイクアップ言語として記憶される。
【００５６】
図７は、ホームサイト２０２がルート２１０から更新スキーマを取得するための方法を示している。ステップ２３０において、ホームサイトはスキーマ更新要求をルート２１０に送る。ホームサイト２０２からのスキーマ更新要求の受け取りに応答して、ルート２１０は、ステップ２３２において、最後に送信されたスキーマを判定することが望ましい。このステップは、送信された更新要求を分析することによって最後に送信されたスキーマの日付を判定するステップを含むことが望ましい。ステップ２３４において、ルート２１０は、更新要求を送ったホームサイト２０２に新しいスキーマを送信する。現在望ましい実施態様においては、ルート２１０は、判定された最後に送られたスキーマを用いて、スキーマ全体を送らずに、スキーマへの変更を含めて更新された情報リストのみを送信する。ステップ２３６において、ホームサイト２０２は、送信された新しいスキーマ情報を受け取り、新しいスキーマ・エレメントを採用して、新しいスキーマ・エレメントの各々に対応する未実装フィールドを各ユーザー・アカウントに関連付ける。新しいフィールドを実装するためには多数の既知の技法のうちどれを使用しても良く、以下の例は単なる例示に過ぎず網羅的なものでないことが、当業者には分かるだろう。１つの実施態様においては、新しいスキーマを受け取ると、ホームサイト２０２は、ユーザー・ファイルに追加情報を記憶できることを知らせるｅメールをユーザーに送る。代替実施態様においては、ユーザーが次にホームサイト２０２にログインするときに、新しいスキーマ・フィールドがあることをユーザーに知らせ、ユーザーが新しいフィールドを実装できるようにするリンクをクリックするよう促す。
【００５７】
同様の多くの技法が新しいスキーマをメンバーサイトに送るために使用可能であることが、当業者には分かるであろう。しかし、メンバーサイトは、新しいスキーマを受け取るとき、新しいスキーマに含まれる情報を求める要求を組み込むためにオペレータとの対話を必要とするかも知れない。
【００５８】
メンバーサイトがユーザーの認証を要求する方法が図８に示されている。ユーザーにシングル・サインオン機能を与えるために、本発明のアイデンティティ管理システムは、図６のステップ２２８においてユーザー２００に与えられるホームサイト・クッキーを採用することが望ましい。このクッキーは、ＧＵＩＤに関連付けられるホームサイトを識別することが望ましい。この情報がアイデンティティ管理ネットワーク２１２の全てのサイトに利用可能であるようにするために、クッキーは、ドメインroot.netのサイトによって読み取り可能であることが望ましい。このようにすることによって、メンバーサイトがクッキーにアクセスしようとし、このメンバーサイトがシャドウ・ドメインに属さない場合、クッキーを読み取ろうとする試みは阻止される。しかし、メンバーサイト２０６がシャドウ・ドメインの一員である場合、メンバーサイトは、ステップ２３８においてＧＵＩＤ及びＧＵＩＤに関連付けられるホームサイトの表示を取得する。既述の通り、ＭＳ２０６はクッキーを検索するためにシャドウ・ドメインにリダイレクトしなければならない。これは、ユーザーがリンクをクリックすることによってまたはそれ以前に行うことができる。ホームサイト・クッキーは、ユーザー２００を認証できるホームサイトを識別する。ホームサイト２０２がホームサイト・クッキーにおいて識別されると判定すると、メンバーサイト２０６は、ステップ２４０において、認証要求と一緒にユーザーをホームサイト２０２にリダイレクトする。認証要求を検索するためには、ＨＳ２０２はシャドウ・ドメインに属さなければならない。このようにして、ＭＳ２０６はシャドウ・ドメイン２１４または一次ドメイン２０４においてＨＳ２０２にユーザーをリダイレクトすることができる。ＨＳ２０２が一次ドメイン２０４においてユーザー２００を受け入れる場合、ＨＳは認証要求を検索できるようにユーザー２００をシャドウ・ドメイン２１４にリダイレクトする。ホームサイト２０２がもうシャドウ・ドメインに属さない場合、クッキーを検索するためのリダイレクトは有効なアドレスに転換されないので、動作は失敗する。しかし、ホームサイト２０２がアイデンティティ管理ネットワーク２１２に属する場合、リダイレクト要求は、シャドウ・ドメイン・アドレス２１４を、結果としてユーザー２００をホームサイト２０２に転送する際のアドレスに転換できるようにする。ステップ２４２において、ユーザーはホームサイト２０２に認証証明書を提出する。認証が完了すると、ホームサイト２０２は、ステップ２４４において、ユーザーをシャドウ・ドメイン２１６あるいは一次ドメインにおけるメンバーサイト２０６にリダイレクトし、シャドウ・ドメイン２１６においてアクセス可能なユーザー認証情報をメンバーサイト２０６に提供する。このように、ＨＳ２０２によって与えられるリダイレクトによっては、ＭＳ２０６は、ユーザー２００をシャドウ・ドメイン２１６にリダイレクトする必要がある場合がある。ユーザーの認証及びリダイレクトを受け取ったら、ステップ２４６において、メンバーサイト２０６は、ユーザー２００のログインを認める。現在望ましい実施態様においては、認証はＨＳ２０２の署名入���であり、ＨＳ２０２がＧＵＩＤを認証する権限を有すると言うルート２１０の署名入り表明が添付される。
【００５９】
ホームサイト２０２とメンバーサイト２０６との間の通信は多様な方法のいずれでも実施できることが当業者には容易に分かるだろう。現在望ましい実施態様においては、メンバーサイト２０６は、ホームサイト・クッキーを検出すると、ステップ２４０において説明されるとおり、ユーザーをシャドウ・ドメインにおけるホームサイト２０２にリダイレクトして、ユーザーがメンバーサイト２０６にログインできるようにするために必要とされるスキーマのフィールドを識別するために第二のクッキーをユーザー２００に与えることによって、情報を要求する。ステップ２４４においてリダイレクトされたユーザーを受け入れてその後認証したら、ホームサイト２０２は、ステップ２４４において、認証されたユーザーをシャドウ・ドメインにおけるメンバーサイト２０６にリダイレクトして、クッキーまたはその他の既知の技法を通じて認証情報を与えることが望ましい。
【００６０】
上述の方法を、次に、ユーザー、メンバーサイト、ホームサイトそしてルートの立場から説明する。ユーザーの立場から見ると、ユーザーは、メンバーサイトを訪れて、メンバーサイトがアイデンティティ管理ネットワークの一部であることを示すリンクをクリックすることが望ましい。このリンクは、ユーザーをホームサイト２０２にリダイレクトし、ここで、アイデンティティを確認するために証明書が提示される。アイデンティティの認証に成功したら、ユーザーはメンバーサイト２０６に戻されて、ログインが認められる。
【００６１】
メンバーサイトの立場から見ると、メンバーサイト２０６は、アイデンティティ管理ネットワークに属するホームサイトに登録していると言うユーザーからの表示を受け取る。メンバーサイト２０６は、ユーザー２００にクッキーを要求し、シャドウ・ドメインにおいてこれを受け取る。クッキーは認証を行うことができるホームサイトとしてホームサイト２０２を識別する。メンバーサイト２０６は、ユーザー２００をホームサイト２０２にリダイレクトして、ユーザー２００を認証して、認証後ユーザーをメンバーサイト２０６に戻すようにホームサイト２０２に要求する。メンバーサイト２０６は、リダイレクトＵＲＬを通じてユーザーを受け取り、さらに、ユーザーが認証されたと言う表示を受け取る。この表示は、シャドウ・ドメイン２１６においてアクセス可能であることが望ましく、上述の通りルートの署名入りの表明が添付される。
【００６２】
ホームサイト２０２の立場から見ると、ユーザー２００は、メンバーサイト２０６からのリダイレクトの結果として接続を確立する。ユーザー２００は、一般に、ユーザーのアイデンティティを認証し、認証したらユーザーをメンバーサイト２０６に戻すよう求めるメンバーサイト２０６からの要求を提出する。一般に、この認証及びリダイレクトの要求は、ユーザーによって与えられるクッキーに記憶される。ホームサイト２０２は、次にアイデンティティを認証するために証明書を提出するようユーザーに要求する。この証明書を受け取り、提示された証明書に基づいてユーザー２００のアイデンティティを認証したら、ホームサイト２０２はユーザーをメンバーサイト２０６にリダイレクトして、ユーザーが認証されたと言う表示をメンバーサイト２０６に与える。
【００６３】
ルート２１０は、このプロセス中２回呼び出される。どちらの場合にも、ルート２１０との対話は、ユーザーがシャドウ・ドメイン名にリダイレクトされるようにするために行われる。このようにして、メンバーサイト２０６がユーザーをシャドウ・ドメインにおけるホームサイト２０２にリダイレクトするとき、ルート２１０は、シャドウ・ドメイン名転換の要求を受ける。この要求を受け取ったら、ルート２１０は、このシャドウ・ドメイン・エンティティの現状を判定する。シャドウ・ドメイン・エンティティの現状に基づいて、ルート２１０は、シャドウ・ドメイン名をアドレスに転換する。このようにして、ホームサイト２０２が現在アイデンティティ管理ネットワークの一部であれば、そのシャドウ・ドメイン名は、その実際のドメイン名が転換されるのと同じＩＰアドレスに転換される。しかし、ホームサイト２０２がアイデンティティ管理ネットワークから既に除かれている場合、ドメイン名の転換は、エラーとなるか、ホームサイト２０２がもはやアイデンティティ管理ネットワークの一部ではないことをユーザーに説明するページにリダイレクトする。同様に、ホームサイト２０２がユーザーをメンバーサイト２０６にリダイレクトするとき、ルート２１０はシャドウ・ドメイン名転換要求を受け取り、このシャドウ・ドメイン・エンティティの現状を判定し、判定された現状に基づいて、シャドウ・ドメイン名をアドレスに転換する。
【００６４】
ルート２１０によるシャドウ・ドメインの管理はroot.netドメインの下にサブドメインを維持することによって行われることが、当業者には容易に分かるだろう。従って、アイデンティティ管理ネットワークにメンバーサイトかホームサイトを追加する場合、ルート２１０は、ＩＰアドレスまたはドメイン名をシャドウ・ドメイン名と関連付けるためにドメインネーム・サーバー・ルックアップ・テーブルを修正する。インターネットなど公衆通信網上でドメインネーム・サーバーが同期化されるおかげで、ドメイン名の転換におけるルート２１０の役割は、ルートからデータを受信する多数のドメインネーム・サーバーによって行うこともできることが、当業者には分かるであろう。しかし、ドメインネーム・サーバーの同期化のため論理的には全てのシャドウ・ドメイン転換要求がルート２１０によって転換されると見なすことができることが、当業者には分かるだろう。
【００６５】
シングル・サインオン機能を与える他に、本発明は、ユーザーがＨＳ２０２に識別情報を記憶するため及びＭＳ２０６が提供するサービスへの登録を容易にするためにＨＳ２０２にこの情報をＭＳ２０６に提供させるためのメカニズムを提供する。この機能は、ユーザー２００にとってはフォーム記入機能のように見える。
【００６６】
図９は、ＨＳ２０２によって記憶されるアイデンティティ情報をＭＳ２０６に提供する方法を示している。この方法を使って、ユーザー２００はＭＳ２０６においてサインアップ・プロシージャを開始して、ＨＳ２０２に、該当する記憶値がある登録フォームのフィールドに記入させることができる。図８の方法によって与えられるシングル・サインオン機能と同様、本発明のフォーム記入方法は、ユーザー２００が、アイデンティティ管理ネットワークに属するホームサイトが識別情報を提供できることをＭＳ２０６に表示するステップから始まる。この表示は、ホームサイトに加盟していることを示すハイパーテキスト・リンクをクリックする形を取ることが望ましい。ユーザーの通知を受け取った後、ＭＳ２０６は、ステップ２４８において、シャドウ・ドメイン２１６においてユーザー２００が提供したクッキーを検索して、ユーザー２００のホームサイトを判定する。その後、ステップ２５０において、ユーザー２００は情報要求と一緒にＨＳ２０２にリダイレクトされる。情報要求は、フォームのフィールドに記入するために必要な情報の要求を含み、必ずしもフォームの全ての情報の要求を含む必要はなく、ＨＳ２０２が記憶する全ての情報を要求する必要はないので、ＭＳ２０６は、ＨＳ２０２が記憶する情報のサブセットを要求することができる。ＨＳ２０２は、誰も悪用目的でユーザー２００の情報を要求しないようにするために、ステップ２５２において、リダイレクトを受けてからユーザー２００を認証することが望ましい。認証を受けたら、ユーザー２００は、ＭＳ２０６に要求される情報を転送するための許可をＨＳ２０２に与える。このステップも、ＨＳ２０２とユーザー２００との間で合意されるサービス条件によるので、望ましくはあるが、任意と見なされる。その後、ＨＳ２０２は、ＭＳ２０６が確実にアイデンティティ管理ネットワーク２１２に属するようにするために望ましくはシャドウ・ドメインにおけるＭＳ２０６にユーザー２００をリダイレクトする。リダイレクトと同時に、ＨＳ２０２は、ステップ２５４において、要求される情報をＭＳ２０６に提供する。ステップ２５６において、ＭＳ２０６は、ＨＳ２０２からリダイレクトされたユーザー２００及び要求した情報の両方を受け取る。ＨＳ２０２が以前にユーザー２００を認証したことがある場合、ＨＳはユーザー２００を再認証しないかも知れず、その代わりに単にユーザー２００が認証されたことがあることを確認する。
【００６７】
ＨＳ２０２によって記憶されるデータをＭＳ２０６は多様な方法で要求できることが、当業者には分かるだろう。単純問い合わせの場合、ＭＳ２０６は、ＭＳ２０６が望みの順序で情報を受け取れるようにするフォーマットでＨＳ２０２が応答を与えることができるように名前と値の対をＨＳ２０２に要求することができる。さらに、ＭＳ２０６は、ＨＳ２０２に対する構造化問い合わせを用いて情報を要求することができる。この構造化問い合わせに対しては、他の既知の技法の構造化応答を与えることができるが、一般にはＸＭＬベースの結果を用いて応答される。問い合わせは、また、ＨＳ２０２が動的に決定する情報、または直接ＨＳ２０２がホストとならずＨＳ２０２がその間にリンクを維持する第三者をホストとする情報についても行うことができる。名前-値の対をベースとする単純問い合わせの場合、ＭＳ２０６は、ＭＳ２０６によって使用されるフォーム・ベースの名前を用いてＭＳ２０６によって与えられるフォームに１つの名前の下でスキーマに記憶される値を返すことができるように、値と一緒に帰される名前を指定することができる。これによって、先在データ収集システムを持つメンバーサイトは、ホームサイトに情報を要求して、自身のＨＴＭＬフォームにフィールドを実装するためにＰＯＳＴ動作を通じてデータを受け取ることができる。これによって、ＭＳ２０６は、自身の既存のページへの修正を最小限に抑えてアイデンティティ管理ネットワークに参加することができる。さらに、現在望ましい実施態様においては、ＨＳ２０２がＭＳ２０６のデータ収集フェーズの次のページにユーザー２００をリダイレクトできるように、単純問い合わせはリダイレクトＵＲＬ値を含む。自動フォーム記入を可能にするために、ＨＳ２０２は、任意に要求される順序で、提供された名前に関連する要求される情報をＭＳに与え、提供されるデータを自動的にＭＳ２０６に掲示するリダイレクトＵＲＬを与えることによって、サインイン・プロシージャの次のページにユーザー２００をリダイレクトする。構造化問い合わせの場合、ＨＳ２０２は、望ましくはＸＭＬファイルの形で、要求される構造化データを与えるＰＯＳＴ動作によってユーザー２００をＭＳ２０６にリダイレクトすることが望ましい。ＨＳ２０２は、ユーザーの写真など機械読み取り可能なデータを記憶することができ、ＭＳ２０６からの問い合わせに応答してこれを提供することができる。動的データは、最終認証からの経過時間の長さなどのデータを含むことができ、単純問い合わせか構造化問い合わせに応答して提供することができる。上述の通り、ＨＳ２０２は別のサイトへの参照としてデータを記憶することができるので、例えば、ユーザー２００は、第三者にカレンダー・データを記憶させ、ＨＳ２０２がこれに対するリンクを記憶することができる。ＭＳ２０６が、フライトの予定を立てるためにある日のユーザー２００の利用可能性に関するＸＭＬベースのレポートを取得するために構造化問い合わせを行う航空会社であるとする。ＨＳ２０２はカレンダー・サイトへの参照を示すか、またはカレンダー・サイトに問い合わせて、結果を取得し、これをＭＳ２０６に提供することができる。カレンダー・サイトなど第三��との通信は、定義済みプロトコルを用いて行われることが望ましい。
【００６８】
問い合わせに応答して提供することができるその他のデータには、ＧＵＩＤと関連付けられる第三者表明が含まれる。表明については、ホームサイトがＧＵＩＤを認証する権限を有することを表明するルート２１０による署名入り表明に関して前に説明したが、表明は他の実行主体も与えることができる。ＭＳ２０６が、ユーザー２００がある一定の年齢を越えていることの署名入り表明を信頼できる機関から受けられるように、政府機関は誕生日をＧＵＩＤと関連付ける表明を与えることができる。表明を認証するための証明書または公開キーをＭＳ２０６が取得するためのメカニズムについて、下に説明する。その他の表明には、例えば、ユーザーが報奨プログラムでプレミアム・サービス・レベルに達したという表示が含まれる。この表明を使って、メンバーサイトは、プレミアム会員制度に基づく割引きサービスをユーザー２００に提供することができる。その他の第三者の署名入りの表明は、当業者には明らかであろう。表明は、ＨＳ２０２によって記憶されるか、ＭＳ２０６が第三者からの表明を直接検索できるようにするためにＨＳ２０２によってリンクとして記憶される。
【００６９】
単純問い合わせは、一般にＵＲＬ符号化を通じて応答されるが、拡張可能問い合わせは、ＨＴＴＰポスト動作を通じてＭＳ２０６に情報を渡すことによって応答されることが望ましい。
【００７０】
ユーザー情報を記憶するために使用されるスキーマは動的なので、初期サインアップ後ユーザー情報を取得するためのメカニズムが必要である。ＨＳ２０２が認証または情報要求中情報を追加するよう２００を促すことができると考えられるが、本発明は、ＨＳ２０２が記憶するためにユーザー情報を取得する新規の方法を提供する。この方法が図１０のフローチャートに示されている。
【００７１】
本発明のアーキテクチャは、ユーザーが、加盟メンバーサイト２０６からスキーマ・フィールドを実装したり、ホームサイト２０２によって記憶される既存の情報を修正したりできるようにする。この方法が図１０に示されている。ホームサイト２０２にユーザーに関する情報を要求し、これを受け取ったら、メンバーサイト２０６は、ステップ２５８において、もっと情報が必要であると判定して、この情報を入力するようにユーザー２００を促す。代替実施態様においては、ＭＳ２０６は、ＨＳ２０２によって提供される情報を確認するようユーザーに求める。ステップ２５０において、ユーザーはメンバーサイト２０６に情報を提供し、望ましくはハイパーテキスト・リンクをクリックすることによって、この情報をホームサイト２０２に送り返すよう指示する。この時点で、メンバーサイト２０６は、シャドウ・ドメイン・アドレスを用いてユーザーをホームサイト２０２にリダイレクトして、ユーザーによって提供された情報をホームサイト２０２に転送する。ユーザーによって提供された情報の転送は、バック・チャネル通信、単純問い合わせの形の符号化ＵＲＬまたはユーザーによって伝えられるクッキーを用いて行うことができる。リダイレクトされたユーザー及び送信された情報の両方を受け取ったら、ホームサイト２０２は、ユーザーに情報を提示して、情報の承認を求める。ステップ２５４においてユーザー２００から情報の承認を受けたら、ホームサイト２０２は、情報をスキーマに記憶する。この時点で、ユーザーは、ステップ２５６においてメンバーサイト２０６に戻される。別の実施態様においては、ＭＳ２０６は、ユーザー２００との対話の結果として新しい情報が入手可能であり、これをＨＳ２０２に提供すべきであると判断する。ＭＳ２０６は、ステップ２６０と同様、ＨＳ２０２にデータを送り返すための許可をユーザーに要求し、上述の通りプロセスが続けられる。代替実施態様の例として、ＭＳ２０６は、ユーザー２００のためにフライトを予約した航空会社とする。ＭＳ２０６は、ユーザー２００のカレンダーに記憶するためにＨＳ２０２に提供されるべき構造化情報を持っている。構造化データは、フライト番号、目的地、離陸及び着陸時間及びその他の関連情報を含むＸＭＬファイルとして転送されることが望ましい。ＨＳ２０２は、ＨＳがユーザー２００のためのカレンダーのホストである場合はデータを記憶することによって、カレンダー・プロバイダが第三者である場合にはカレンダー・プロバイダに情報をリダイレクトすることによって、または情報を送るべき相手のアドレスをＭＳ２０６に提供することによって、更新に応答することができる。このように、ＨＳ２０２に提供される情報は、構造化情報でも単純情報でもよく、また記憶データでも参照データでも良い。現在望ましい実施態様においては、ＭＳ２０６は、ＨＳ２０２情報の全ての更新についてユーザーの許可を求めない。上述の航空会社の予約の例において、フライトが遅れる場合、ＭＳ２０６は、ユーザーの承認なしに自動的にＨＳ２０２を更新できることが望ましい。
【００７２】
既述の通り、本発明の利点の１つは、ホームサイトによって記憶される情報が別のホームサイトに移植可能であることである。コスト、ホームサイトが記憶しようとする情報の量及びホームサイトのサービス条件を含めてユーザーが１つのホームサイトから別のホームサイトにデータを移したい理由は無数にあるだろう。先行技術のシステムにおいては、データを移すのに同等のものがなかったり、データが移植可能でなかったりしたが、本発明のシステムは、ユーザー２００に一意のＧＵＩＤを割り当てて、定義されたスキーマでユーザー情報を記憶することをＨＳ２０２に要求することによって、ユーザー情報の移植可能性を保証する。このように、ホームサイトを変更するために、ユーザー２００は、第二のホームサイトを訪れて、新しいアカウントを既存のＧＵＩＤと関連付けるように要求する。同じＧＵＩＤを維持することによって、ユーザーは、識別子としてＧＵＩＤを用いて情報を記録しているメンバーサイトのアカウントを維持することができる。登録プロセスとほとんど同様に、ルート２１０は、ユーザーにチャレンジを発して、不正を働くホームサイトがユーザーを別のホームサイトから奪おうとしているのではないことを確かめるために、チャレンジに応答するようユーザーに要求する。登録プロセスの転送は、チャレンジ応答フェーズと同じであり、チャレンジ応答に成功したら、ルート２１０は全てのスキーマ関連の情報を新しいホームサイトに転送するよう求める指令を現在のホームサイトに発する。これは、バック・チャネル通信またはＵＲＬ符号化を用いて、または望ましくはルート２１０が、元のホームサイトにユーザー２００をリダイレクトし、元のホームサイトに記憶する全ての個人情報を含むクッキーをユーザー２００に与えさせ、その後新しいホームサイトにユーザー２００をリダイレクトさせることによって、行うことができる。第一のホームサイトから第二のホームサイトへのリダイレクトは、ユーザーがどこに行ったか元のホームサイトが分からないようにユーザー２００をルート２１０にリダイレクトすることによって行うことができる。直接的にまたは間接的に新しいホームサイトにリダイレクトされたら、ユーザー２００は、全てのスキーマ関連の情報を記憶するクッキーを提供して、ＧＵＩＤを確認しかつ新しいホームサイトがＧＵＩＤに関連付けられるサイトであることを示す新しいクッキーを受け取る。
【００７３】
現在望ましい実施態様において、チャレンジｅメールを再送信する必要をなくすために、新たに選ばれたホームサイトは、認証のためにユーザーを最初のホームサイトに導くことができる。この認証に成功したら、ルート２１０は、これをユーザーがＧＵＩＤを別のホームサイトに転送する権限を有する証拠と見なすことができる。
【００７４】
先行技術のアイデンティティ管理の方法は、メンバーサイトにＰＵＩＤを与えたが、本発明は、そのグローバルな性質のために第三者表明を得るために使用することができるＧＵＩＤを与える。ＰＵＩＤは、ＩＤＰが第三者とＰＵＩＤマッピングを共有することなく従ってＰＵＩＤの目的を否定することなく第三者表明をサポートすることはできない。ユーザー２００にＰＵＩＤによって与えられる利点を提供するために、ＨＳ２０２は、ユーザーが複数のＧＵＩＤを取得できるようにすることができる。複数のＧＵＩＤを取得することによって、ユーザー２００は、異なるメンバーサイトがオンラインで行動を相関できないように、複数のオンライン・ペルソナを創造することができる。これによって、ユーザー２００は、ＧＵＩＤの利点を保持しながらＰＵＩＤの機密保護を取得する選択肢が与えられる。複数のＧＵＩＤを管理できるようにするために、ユーザー２００は、認証時に、メンバーサイトにどのＧＵＩＤを与えるかについてＨＳ２０２の催促を受ける。これによって、ユーザーは、一組の情報をＨＳ２０２に与え、ＧＵＩＤごとに異なるプロフィルを構成させることができる。このようにして、あるＧＵＩＤを有する仕事ベースのペルソナは、メンバーサイトが電話番号と住所を要求するときデフォルトで勤務先の電話番号と住所を与え、異なるＧＵＩＤを有する家庭ベースのペルソナは電話番号と住所が要求されるときデフォルトで自宅の電話番号と住所を与えることができる。
【００７５】
上述の通り、表明は、ＨＳ２０２がＧＵＩＤを認証する権限を有することの証明をメンバーサイトに与えるために、ルート２１０によって与えられることが望ましい。この表明は、秘密キーまたは証明書を用いて署名入りであり、署名は、公開キーまたは証明書を用いて確認することができることが望ましい。証明書は、安全なデータ・チャネルを通じてルート２１０との通信によって取得できることが望ましい。証明書が改竄されていないことを保証するために、ルート２１０の証明書は、第一の証明機関（ＣＡ）の署名を受け、第二の異なるＣＡによって署名されるＳＳＬリンクを通じて要求側当事者に送られることが望ましい。この署名のダブル・チェーンは、第一のＣＡ及び第二のＣＡの両方が、悪意の者がルート２１０を詐称できるため危険にさらされるのを阻むために必要である。ホームサイトによって与えられる認証情報は、これも証明書であるように、このホームサイトの署名入りであることが望ましい。この情報は、改竄されていないことまたはホームサイトが第三者によって詐称されていることをメンバーサイトが確信できるように、ホームサイトの署名入りであることが望ましい。ホームサイトによる表明を確認するために、メンバーサイトは、ルートの署名入りのホームサイト証明書と一緒に、ＣＡの署名入りのＳＳＬ接続を通じてホームサイトから証明書を取得することができる。ＣＡ及びルートは別個のものなので、もう１つの機密保護のダブル・チェーンがあり、ＣＡ及びルートの両方で機密保護の違反を阻むために必要である。第三者表明は、ＳＳＬ接続を通じて入手できる証明書、ルートまたはＣＡの署名入り証明書及び証明書に署名したのとは異なるＣＡの署名入り接続による署名入りであることが望ましい。アイデンティティ・ネットワーク２１２において送信される証明書を確認するためには、上記の二重署名送信が望ましい。
【００７６】
現在望ましい実施態様において、署名入り表明が提示されるとき、ＭＳ２０６は、署名を確認するために使用される証明書を取得し、証明書をキャッシュ・メモリに入れる。この証明書を使用する次の署名確認において、ＭＳ２０６は、再び証明書を要求する必要はないが、証明書が最新のものであることを確かめなければならない。このために、ＭＳ２０６は、証明書所持者のシャドウ・ドメイン名についてＤＮＳ ｔｘｔルックアップを行う。ルート２１０は、シャドウ・ドメインのためにＤＮＳサービスを提供する際、各実行主体のｔｘｔＤＮＳフィールドにその証明書番号を維持する。ＤＮＳルックアップから返される値が証明書番号と同じであれば、ＭＳ２０６は署名を確認でき、証明書番号が異なる場合、ＭＳ２０６はキャッシュ・メモリに入れられた証明書を廃棄して、新しい証明書を要求する。
【００７７】
メンバーサイトがキー管理を可能にするスクリプト機能を加えることなく、またシャドウ・ドメイン移行することなく、アイデンティティ管理ネットワーク２１２に参加できるようにするために、ＭＳ２０６は、そのシャドウ・ドメイン２１６をホームサイト・クッキーの読み取り、ＨＳ２０２へのリダイレクト及びＨＳ２０２によって与えられるデータの提供を処理する第三者と関連付けさせることができる。さらに、この第三者は、受信データのインテグリティを確認する単に必要な署名チェックを処理することができる。単一の実行主体が多数のメンバーサイトのためにこの機能を提供できることが、当業者には分かるだろう。
【００７８】
既存のシングル・サインイン・サービスにおいて一般に求められるのは、シングル・サインアウト機能の提供である。このために、ユーザーのサインインを認めたメンバーサイトは、ユーザー２００によって伝えられるクッキーを修正することが望ましい。このクッキーは、ユーザーがログインするメンバーサイトを追跡する。現在望ましい実施態様において、クッキーはユーザーがログアウトできるようにするＵＲＬを与える。サービスからサインアウトするために、ユーザー２００は自分のホームサイト２０２に戻って、全てのサービスまたはそのサブセットからログアウトしたいことを知らせる。ホームサイト２０２は、ユーザーがシングル・クリックでサインオフできるようにするためにクッキーにおいて与えられるＵＲＬを通じて処理することができる。その代わりに、ＭＳ２０６は、ＭＳ２０６からユーザー２００をログアウトしてクッキー内のメンバーサイトの参照を取り除くか、あるいは上述のログアウト・プロセスをたどれるようにユーザー２００をＨＳ２０２にリダイレクトすることができるログアウト・リンクをユーザー２００に与えることができる。別の実施態様においては、ＨＳ２０２がＭＳ２０６のためにユーザー２００を認証するとき、ＨＳ２０２は、ユーザー・プロフィル・データベースにＭＳ２０６に関するログアウトＵＲＬを記憶することができる。従って、ユーザー２００は、ログアウトするために、ＨＳ２０２を訪れて、現在のログイン・サイトのリストを要求する。このリストは任意のまたは全てのメンバーサイトからログアウトする機能をユーザーに与えることが望ましい。
【００７９】
本発明は、メンバーサイトへの単純化されたサインイン及び登録をユーザーに提供して、ユーザーがメンバーサイトを訪れて、ユーザーがアイデンティティ管理ネットワークの一部であることを示せるようにする。これは、サインイン・ページのアイコンかリンクをクリックすることによって行われることが望ましい。このリンクがクリックされると、ＭＳ２０６は、ユーザー２００を識別するクッキーを検索して、ユーザー２００をＨＳ２０２にリダイレクトする。ＭＳ２０６への単純なサインインの場合、以前に登録が行われていれば、ＨＳ２０２へのリダイレクトは単に認証のためだけである。ユーザー２００が以前にＭＳ２０６に登録されていない場合、ＨＳ２０２へのリダイレクトは認証及び情報要求の両方のためである。ＭＳ２０６は、単純なＵＲＬ符号化リダイレクトを用いてＨＳ２０２に記憶される情報のサブセットを要求するか、あるいは、ユーザー２００によって伝えられるクッキーに記憶される問い合わせを使用することによって拡張可能な情報を要求することができる。ユーザー２０をＨＳ２０２にリダイレクトすると、ＨＳ２０２がアイデンティティ管理ネットワークに依然として属することを保証するために、ユーザー２００はＨＳ２０２のシャドウ・ドメインに送られる。ＨＳ２０２に認証証明書及びデータ転送のために要求される許可を与えた後、ユーザー２００は、ＭＳ２０６にリダイレクトされる。ＭＳ２０６及びＨＳ２０２の両方がシャドウ・ドメインに属すること、従ってアイデンティティ管理システムにおいて活動中であることの確認は、ユーザーには透明に行われ、ユーザーはログイン及び登録のために単純化されたプロセスを利用することができる。ＭＳ２０６はＨＳ２０２に情報を送り返すことができるので、ユーザー２００には、ＨＳ２０２が更新された新しい情報を有することを保証するための単純化されたメカニズムが与えられる。
【００８０】
ユーザー２００はＭＳ２０６からリダイレクトされた後ＨＳ２０２で認証されるので、ユーザー２００は、一般に、ブラウザ・ウィンドウのナビゲーションまたはロケーション・バーにあるＵＲＬをチェックすることによって正確なリダイレクトが行われたことを確認する必要がある。付加的機密保護のために、ＨＳ２０２は、ユーザーのインターフェイス及び経験を定義するユーザー２００から入手した一連のユーザー嗜好を記憶することができる。これらの嗜好は、ユーザーが定義するバックグラウンド・ページ・カラー、カスタマイズされたアイコン・セット、ユーザー定義のグリーティング及びユーザー選択の言語インターフェイスを含むことができる。これらの嗜好は、登録時にユーザー２００から取得し、ユーザー・プロフィル・データベースに記憶して、ユーザー２００が認証のためにリダイレクトされるときに検索することができる。悪意の者がＨＳ２０２を詐称しようとするとき、ユーザー定義の嗜好は入手不能なので、ユーザー２００は間違ったサイトにリダイレクトされたことにすぐに気が付くだろう。
【００８１】
本発明の階層的構造は、単一のポイントから機密保護違反に対処できる一方、ホームサイトの分散的性質は、ユーザー情報を解放する単一障害発生ポイントを排除する。ルート２１０のインテグリティが危険にさらされる場合、ＤＮＳ機関に連絡することによって簡単に全てのｒｏｏｔ．ｎｅｔドメインを取り除くことができる。ＤＮＳ機関は、アイデンティティ管理ネットワーク２１２全体をシャットダウンする。これによって、ユーザー情報の解放を防止し、架空ホームサイトがユーザーを詐称できないようにする。ルート２１０が危険にさらされる場合、ＰａｓｓｐｏｒｔTMモデルと異なりユーザー固有のデータが解放されることはない。単一のホームサイトが危険にさらされる場合、そのユーザー・データは解放されるが、このホームサイトをシャドウ・ドメインから除外することによって、シャドウ・ドメインからクッキーを検索することができないので、不適切な認証を与えることが阻止される。このように、アドレス更新がＤＮＳネットワーク全体に伝播するのにかかる時間内に、危険にさらされるホームサイトを効果的にネットワークから取り除くことができる。単一障害発生ポイントをもたらさないＬｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅモデルにおいては、信頼のウェブにおけるキー・リングが複雑なため危険にさらされるＩＤＰをウェブから取り除くための単純な方法がない。従って、本発明は、その構造を通じて、ユーザー・データの解放を可能にする単一障害発生ポイントを排除し、ユーザー詐称を防止するために危険にさらされるホームサイトを隔離するためのメカニズムを提供する。
【００８２】
本発明の上述の実施態様は、単なる例とする。本明細書に添付されるクレームによってのみ定義される本発明の範囲から逸脱することなく、当業者は変更、修正及び変化を加えることができる。
【図面の簡単な説明】
【００８３】
本発明の実施態様は、下記の添付図面を参照して、例としてのみ説明されている。
【図１】図１は、先行技術のアイデンティティ管理システムのブロック図である。
【図２】図２は、先行技術のアイデンティティ管理システムのブロック図である。
【図３】図３は、先行技術の階層的アイデンティティ管理システムのブロック図である。
【図４】図４は、先行技術の分散アイデンティティ管理システムのブロック図である。
【図５】図５は、本発明の階層的分散アイデンティティ管理システムのブロック図である。
【図６】図６は、本発明の方法を示すフローチャートである。
【図７】図７は、本発明の方法を示すフローチャートである。
【図８】図８は、本発明の方法を示すフローチャートである。
【図９】図９は、本発明の方法を示すフローチャートである。
【図１０】図１０は、本発明の方法を示すフローチャートである。
【図１】
2005529392.tif 000003
【図２】
2005529392.tif 000004
【図３】
2005529392.tif 000005
【図４】
2005529392.tif 000006
【図５】
2005529392.tif 000007
【図６】
2005529392.tif 000008
【図７】
2005529392.tif 000009
【図８】
2005529392.tif 000010
【図９】
2005529392.tif 000011
【図１０】
2005529392.tif 000012
【国際調査報告】
2005529392.tif 000013
2005529392.tif 000014
2005529392.tif 000015