(57)【要約】【課題】関係者の様々な要求に適合できる、完全な相互運用性を備えた、信頼性が高くかつ効率的なアイデンティティ管理を提供すること。【解決手段】これを実現するため、ユーザについてのアイデンティティ関連情報を要求エンティティに提供するための方法およびシステムが提示される。この方法は、アイデンティティ関連情報を保有するロケーション・エンティティに対応するロケーション情報をクライアント・アプリケーションに要求するために要求エンティティによって開始されるロケーション要求ステップと、アイデンティティ関連情報を要求エンティティに転送するようロケーション・エンティティに命令するためにクライアント・アプリケーションをロケーション・エンティティに接続するためのリダイレクト・ステップと、アイデンティティ関連情報を取得するための獲得ステップとを含む。
2005528679.tif 000002
【特許請求の範囲】
【請求項１】
アイデンティティ関連情報（ＩＲＩ）を要求エンティティ（５０）に提供するための方法であって、
前記アイデンティティ関連情報（ＩＲＩ）を保有するロケーション・エンティティ（４０）に対応するロケーション情報（ＬＩ）をクライアント・アプリケーション（３０）に要求するために前記要求エンティティ（５０）によって開始されるロケーション要求ステップ（ＩＩ）と、
前記アイデンティティ関連情報（ＩＲＩ）を前記要求エンティティ（５０）に転送するよう前記ロケーション・エンティティ（４０）に命令するために前記クライアント・アプリケーション（３０）を前記ロケーション・エンティティ（４０）に接続するためのリダイレクト・ステップ（ＩＩＩ）と、
前記アイデンティティ関連情報（ＩＲＩ）を取得するための獲得ステップ（ＩＶ）であって、
前記ロケーション・エンティティ（４０）が前記要求エンティティ（５０）にコンタクトするコンタクト・ステップ（ＩＶａ）と、
前記要求エンティティ（５０）が前記アイデンティティ関連情報（ＩＲＩ）を要求する要求ステップ（ＩＶｃ）と、
前記要求エンティティ（５０）が前記アイデンティティ関連情報（ＩＲＩ）を前記ロケーション・エンティティ（４０）から受信する応答ステップ（ＩＶｅ）とを含む獲得ステップ（ＩＶ）とを含む方法。
【請求項２】
前記獲得ステップ（ＩＶ）が、前記ロケーション・エンティティ（４０）を前記クライアント・アプリケーション（３０）を介して前記要求エンティティ（５０）にリダイレクトし、それによって前記アイデンティティ関連情報（ＩＲＩ）を前記要求エンティティ（５０）に送信するリダイレクト・サブステップ（ＩＶｇ）だけを含む、請求項１に記載の方法。
【請求項３】
ＵＲＬ（ユニフォーム・リソース・ロケータ）に入れられる情報の長さに基づいて前記コンタクト・ステップ（ＩＶａ）が実行されるかどうかを決定する決定ステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記要求エンティティ（５０）と前記クライアント・アプリケーション（３０）の間、および前記ロケーション・エンティティ（４０）と前記クライアント・アプリケーション（３０）の間で使用されるトランスポート・プロトコルが、セキュリティ保護されたハイパー・テキスト転送プロトコル（ＨＴＴＰＳ）である、請求項１ないし３のいずれかに記載の方法。
【請求項５】
返される前記ロケーション情報（ＬＩ）が、前記クライアント・アプリケーション（３０）のロケーションに関連する、請求項１ないし４のいずれかに記載の方法。
【請求項６】
前記要求エンティティ（５０）が、偽名を用いている前記ロケーション・エンティティ（４０）から前記アイデンティティ関連情報（ＩＲＩ）を認証と共に受け取るステップをさらに含み、前記アイデンティティ関連情報（ＩＲＩ）は、人（２０）の個人的な偽名に対応に対応する、請求項１ないし５のいずれかに記載の方法。
【請求項７】
前記要求エンティティ（５０）が、前記アイデンティティ関連情報（ＩＲＩ）を使用するためのサーバ・ポリシー（ＰＰｓ）を送信するステップをさらに含む、請求項１ないし６のいずれかに記載の方法。
【請求項８】
ロケーション・エンティティ（４０）上でホストされるアイデンティティ関連情報（ＩＲＩ）を要求エンティティ（５０）に転送するための方法であって、
前記アイデンティティ関連情報（ＩＲＩ）を前記要求エンティティ（５０）に転送するための命令情報をクライアント・アプリケーション（３０）から受信するためのリダイレクト・ステップ（ＩＩＩ）と、
前記アイデンティティ関連情報（ＩＲＩ）を前記要求エンティティ（５０）に転送するための転送ステップ（ＩＶ）であって、
前記ロケーション・エンティティ（４０）が前記要求エンティティ（５０）にコンタクトするコンタクト・ステップ（ＩＶａ）と、
前記要求エンティティ（５０）が前記アイデンティティ関連情報（ＩＲＩ）を要求する要求ステップ（ＩＶｃ）と、
前記ロケーション・エンティティ（４０）が前記アイデンティティ関連情報（ＩＲＩ）を前記要求エンティティ（５０）に送信する応答ステップ（ＩＶｅ）とを含む転送ステップ（ＩＶ）とを含む方法。
【請求項９】
前記転送ステップ（ＩＶ）が、前記要求ステップ（ＩＶｃ）で要求された前記アイデンティティ関連情報（ＩＲＩ）のどの部分を転送するかを前記ロケーション・エンティティ（４０）が事前定義されたポリシー（ＰＯ）に基づいて決定するステップをさらに含む、請求項８に記載の方法。
【請求項１０】
前記応答ステップ（ＩＶｅ）が、前記ロケーション・エンティティ（４０）が前記事前定義されたポリシー（ＰＯ）の一部を送信するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
前記ロケーション・エンティティ（４０）が、前記転送ステップ（ＩＶ）中に人（２０）と対話するため、前記リダイレクト・ステップ（ＩＩＩ）において前記クライアント・アプリケーション（３０）から前記ロケーション・エンティティ（４０）へと確立されたコネクションを使用する、請求項８ないし１０のいずれかに記載の方法。
【請求項１２】
個人情報の前記要求エンティティ（５０）への公開が、
前記要求エンティティ（５０）についての情報を提示するステップと、
前記ロケーション・エンティティ（４０）が知っている事前認可された属性値または事前認可されていない属性値あるいはその両方を提示し、または知らない属性値については各属性値を入力するための空フィールドに付された属性名を提示し、あるいはその両方を行うステップと、
前記属性値を編集するよう要求するステップと、
前記編集された属性値を前記要求エンティティ（５０）に送信するステップとを含む、請求項８ないし１１のいずれかに記載の方法。
【請求項１３】
異なる属性値が、異なる仕方で、好ましくは異なる色で提示される、請求項１２に記載の方法。
【請求項１４】
前記転送ステップ（ＩＶ）が、
前記ロケーション・エンティティ（４０）がランダム値（ｋ）を生成するステップと、
前記ランダム値（ｋ）を前記要求エンティティ（５０）に前記アイデンティティ関連情報（ＩＲＩ）の場合と同じコネクションで送信するステップと、
前記クライアント・アプリケーション（３０）が前記アイデンティティ関連情報（ＩＲＩ）に関するその本人性を前記要求エンティティ（５０）に対して証明できるように、前記ランダム値（ｋ）を前記クライアント・アプリケーション（３０）に送信するステップとを含む、請求項８ないし１１のいずれかに記載の方法。
【請求項１５】
コンピュータ・プログラム要素であって、前記プログラムがコンピュータ上で実行された際に、請求項１ないし１４のいずれか一項に記載の方法を実行するプログラム・コード手段を含むコンピュータ・プログラム要素。
【請求項１６】
コンピュータ使用可能媒体に格納されたコンピュータ・プログラム製品であって、コンピュータに請求項１ないし１４のいずれか一項に記載の方法を実行させるコンピュータ可読プログラム手段を含むコンピュータ・プログラム製品。
【請求項１７】
アイデンティティ関連情報（ＩＲＩ）を提供するためのシステムであって、
前記アイデンティティ関連情報（ＩＲＩ）を保有するロケーション・エンティティ（４０）と、
前記ロケーション・エンティティ（４０）に接続可能なクライアント・アプリケーション（３０）と、
前記アイデンティティ関連情報（ＩＲＩ）を保有する前記ロケーション・エンティティ（４０）に対応するロケーション情報（ＬＩ）を前記クライアント・アプリケーション（３０）に要求するように適合された要求エンティティ（５０）とを含み、前記アイデンティティ関連情報（ＩＲＩ）を前記要求エンティティ（５０）に転送するよう前記ロケーション・エンティティ（４０）に命令するため、前記要求に対する応答に基づき前記クライアント・アプリケーション（３０）が前記ロケーション・エンティティ（４０）にリダイレクトされ、前記ロケーション・エンティティ（４０）が前記要求エンティティ（５０）にコンタクトし、前記要求エンティティ（５０）が前記アイデンティティ関連情報（ＩＲＩ）を要求し、前記要求エンティティ（５０）が前記アイデンティティ関連情報（ＩＲＩ）を前記ロケーション・エンティティ（４０）から受信するシステム。
【請求項１８】
１つのクライアント・アプリケーション（３０）が、複数のロケーション・エンティティ（４０、４２）と対話する、請求項１７に記載のシステム。
【請求項１９】
前記アイデンティティ関連情報（ＩＲＩ）が、別のロケーション・エンティティ（４２）によって提供され、前記ロケーション・エンティティ（４０）を介して前記要求エンティティ（５０）によって取得可能であり、前記別のロケーション・エンティティ（４２）のロケーション情報（ＬＩ）が、前記ロケーション・エンティティ（４０）に保存される、請求項１７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ある人についてのアイデンティティ関連情報（identity-relatedinformation）を要求エンティティ（requesting entity）に提供するための方法およびシステムに関する。さらに、本発明は、ウォレット（wallet）とも呼ばれるロケーション・エンティティ（locationentity）上でホストされるアイデンティティ関連情報を、要求エンティティに転送するための方法に関する。
【背景技術】
【０００２】
最も広い意味で、アイデンティティ管理（identity management）とは、少なくともある人のすべてのデジタル関係（digitalrelation）を含む、その人についてのすべての個人情報の管理のことである。次の１０年にわたり、この広い意味でのアイデンティティ管理システムは、発展していくものと思われる。短期的には、アイデンティティ管理と言う場合は一般に、ある人についての少量のデータの転送を伴うウェブのシングル・サインオン（singlesign-on）のことを指す。
【０００３】
主要なビジネス事例が、全般的に電子ビジネスを後押ししている。アイデンティティ管理は、インターネットやウェブ標準のような標準がほとんどすべての関係者に恩恵を与える、インフラストラクチャ問題である。
【０００４】
シングル・サインオンによって、人またはユーザは、どの組織にも他の組織に対してその人に扮することを許可することなく、同一パスワードを直接すべての組織に対して使用するのと同じくらい簡単に、１つのパスワードを覚えているだけで異なる組織にログインすることができる。
【０００５】
アイデンティティ管理、特にシングル・サインオンは、最近では、例えば、図書館連合（LibraryAlliance）（URL: http://www.projectlibrary.org）またはマイクロソフト・コーポレーションのパスポート・システム（URL:http://www.passport.com）によって有名である。いわゆるパスポート・システム、またはマイクロソフト・コーポレーションのショート・パスポート（shortpassport）は、ユーザがウェブ・サイトにサイン・インし、電子商取引を行えるようにする、専らマイクロソフト・コーポレーションによって運営されるウェブ・サービスである。より排他性の低い運用が約束されているが、まだ実現していない。現在、パスポートには、認証サービス、子供専用の認証サービス、およびエクスプレス・パーチェイス・サービス（expresspurchase service）が含まれている。
【０００６】
アイデンティティ管理関連のより古いタイプのシステムには、古典的なシングル・サインオン製品、公開鍵インフラストラクチャ（public-key infrastracture）、およびフォーム入力アシスト（form filler）がある。
【０００７】
しかし、周知の製品および提案の中には、グローバル情報社会および汎用的な電子ビジネスで特に必要とされる相互運用可能なやり方で、この情報社会および電子ビジネスにおける様々な関係者が有する異なる要件のすべてに適合し得るものは１つもない。特に、従来製品および提案はどれも、以下でより詳しく説明する次に示す要件の少なくとも１つを満たすことができない。
【０００８】
１．ある人についてのアイデンティティ関連情報を保有するロケーション・エンティティを適切に自由選択できること。ロケーション・エンティティには、個々のユーザ自身の物理的制御下にあるロケーション・エンティティ、いわゆるローカル・ウォレットが含まれる。また複数のロケーション・エンティティによって、１人の人の情報を保有できるようにすることも含まれる。
【０００９】
２．すべてのユーザ・メッセージの内容を確認できるプロキシの役割を担うロケーション・エンティティを介してすべてのブラウジングを行う必要なしに、ブラウザだけのクライアントおよびユーザが、様々なブラウザを介してシステムに適切にアクセスできること。明らかに、ブラウザだけのユーザとローカル・ウォレットをもつユーザは同じでなく、サーバの方法は両者を同時に処理できなければならないという要件が存在する。
【００１０】
３．認証情報とその他のアイデンティティ関連情報の両方を適切に転送できること。ただし、後者の情報は、ユーザの好みなど、ユーザによって自由に選択される情報であることもあり、または第三者の確認に必要な情報であることもある。
【００１１】
４．ユーザの好みや人口統計情報など、一部のアイデンティティ関連情報は依然として転送可能としながら、匿名性の維持を望むユーザに適切に対処できること。
【００１２】
５．アイデンティティ関連情報を公開するに際してプライバシ・ポリシーを柔軟に適用できること。
【００１３】
上記の要件を満たすアイデンティティ管理システムの利点を説明する際に便利なように、以降、要件をＲｅｑ．と略記する。Ｒｅｑ．１は、少なくともビジネス関連の関係において、従業員や顧客のロケーション・エンティティとして機能することを望む、雇用主や銀行などの企業からの要請による。さらに、人がアイデンティティ管理を自主的に受け入れるかどうかは、そう信じさせられているほど明らかではない。現在、「すべての卵を１つの籠に盛る」ことに対する危惧、ならびにプライバシおよび信用に対する懸念は、シングル・サインオンおよび大多数の人向けの簡略化フォーム入力について認識されている利点よりも勝っている。この場合もやはり、Ｒｅｑ．１の自由選択が、特に、ユーザの真に個人的な情報のための「ローカル」ロケーション・エンティティを可能とする助けとなり得る。この後者の懸念は、Ｒｅｑ．４の動機にもなる。Ｒｅｑ．２は、実用性のためであり、これは、多くのユーザには追加のソフトウェアをインストールさせられないのに、一部のユーザは様々なインターネット・キオスクその他から情報社会インフラストラクチャを使用するためである。インターネット・キオスクによって、例えば、インターネット・カフェ内にある公衆コンピュータが企図されている。Ｒｅｑ．３は、例えば、１つのシステムだけで、所定の情報および所定の操作に対するアクセスを所定のユーザだけに制限できるようにし、また住所や発送先情報などをビジネス相手に転送できるようにする、汎用的な適用性およびユーザフレンドリネスのためである。Ｒｅｑ．３の後の部分とＲｅｑ．５の利点は、次のことから理解できる。少量のデータの転送は、標準的な電子商取引アプリケーションを目的としており、発送および請求情報などのデータはしばしば必要とされ、通信相手とはまったく無関係である。書籍や旅行の好みなど、より特殊なデータに拡張した場合は、相手をよりよく区別しなければならない。長期的で総合的なソリューションは、第三者の確認を必要とするデータを含み、取引相手から取得した受領書などの取引データを管理し、これらの受領書を利用する税金申告などのその他の個人アプリケーションと統合される。さらに、長期的なソリューションは、カレンダ共有などの個人間アプリケーション、および雇用主が申し込んだアクセス・サービスなどの企業間アプリケーションを統合する。
【００１４】
古典的なシングル・サインオン方式および製品は、多くのアプリケーション用に様々なログイン・スクリプトまたはパスワードを含む。例えば、米国特許第５，９４４，８２４号は、複数のネットワーク要素にシングル・サインオンするためのシステムおよび方法を開示する。同発明では、ブラウザだけのクライアントは、プロキシを利用しない限り許されない（Ｒｅｑ．２を参照）。さらに、同発明は認証情報だけに対応し、その他のアイデンティティ関連情報には対応しておらず（Ｒｅｑ．３を参照）、したがって、プライバシ・ポリシーにも対応していない（Ｒｅｑ．５）。
【００１５】
Ｘ５０９が最も有名な、古典的な公開鍵インフラストラクチャ（ＰＫＩ）は、基本的に認証情報だけを考慮する（Ｒｅｑ．３を参照）。情報は固定の証明書によって伝送されるので、その他のアイデンティティ関連情報が含まれる場合、この情報は固定されており、これはＲｅｑ．５と相容れない。専用のクライアント・ソフトウェアであれば、例えば、属性証明書に入れて、別個にその他の属性を送信する方法を容易に設計することができるが、このようにすると、ブラウザだけのクライアントとの互換性が保てず（Ｒｅｑ．２）、特に、様々なブラウザを使用するための相互運用可能な方法が存在しない（やはりＲｅｑ．２）。
【００１６】
電子商取引において個人データを転送するための古典的な製品は、フォーム入力アシストである。これは、属性をフォーム内のフィールドにドラッグアンドドロップするのにブラウザと緊密に対話し、またはフォーム内のフィールドを解釈するのに強力なツールを使用する。フォーム入力アシストは一般に、複雑なクライアント・ソフトウェアとしてのみ、さもなければプロキシとしてのみ機能し、これはＲｅｑ．２と相容れない。さらに、フォーム入力アシストは、情報を要求するサーバ用の対応する方法がないため、完全な相互運用性を提供しない。
【００１７】
マイクロソフトのパスポートは、１つの固定したロケーション・エンティティを仮定するか、または少なくとも１組だけのエンティティを仮定して、その全体で一定のドメイン内のユーザについての情報を保有する。すなわち、例えば、ロケーション・エンティティとしてユーザの取引銀行を選択するなど、ユーザによる選択やその他のビジネス関係に基づく選択の余地はなく、これはＲｅｑ．１と相容れない。サーバはどのロケーション・エンティティに接続すべきかをアプリオリに知っているものと仮定されているため、これはこのシステムに本質的に備わった性質であり、異なる使用法や実施形態によって変更可能なものではない。いわゆるフェデレーション（federation）への拡張が検討中であるが、その拡張システムは、以下のシステムのように、別の不都合の一部をもち続けることになりそうである。パスポートは、第三者の確認に必要な情報をまだ区別しない（Ｒｅｑ．３を参照）。さらに、パスポートは、本当の匿名性を許さない。グローバル・ユーザ識別子があり、複数のアカウントをもち、異なる管理を受けることによってのみ、ユーザはこれを無効にすることができる。さらに、ロケーション・エンティティは、ユーザの通信相手を記憶する（Ｒｅｑ．４を参照）。柔軟なプライバシ・ポリシーも存在しない（Ｒｅｑ．５）。さらに、パスポートは、長いデータを安全に転送するには必須の、サーバとロケーション・エンティティの間の直接コンタクトを許さず、フェデレーション環境において、上記の要件をすべて満たすように、これが実現されるかどうかは自明なことではない。
【００１８】
米国特許第６，２２６，７５２号は、認証を行うためのシステムおよび装置を開示する。同発明は、パスポートと同じ理由で、ユーザによるロケーション・エンティティの選択を許さない（Ｒｅｑ．１を参照）。同発明は、認証情報だけを考慮し（Ｒｅｑ．３を参照）、したがって、プライバシ・ポリシーを考慮せず（Ｒｅｑ．５）、匿名性のための方法も考慮しない（Ｒｅｑ．４）。
【００１９】
インターネット２／ＭＡＣＥ（教育向けミドルウェア・アーキテクチャ評議会（MiddlewareArchitecture Committee for Education））のプロジェクトであるShibboleth（http://middleware.internet2.edu/shibboleth）は、アクセス制御の対象となるウェブ・リソースの団体間での共有を支援するための、アーキテクチャ、フレームワーク、および技術を開発している。Shibbolethは、いわゆる大学エンティティを見つけるための方法を含み、したがって、Ｒｅｑ．１を部分的に満たす。サーバは、関係大学エンティティのユーザフレンドリな名前をユーザに尋ね、各大学エンティティの「名前とロケーションを知っている」ＷＡＹＦと呼ばれる別のエンティティを用いてその名前を変換する。このロケーションへのリダイレクションは、認証のためだけに行われ、大学エンティティは、大学エンティティの第２のアドレスを有するサーバにユーザを元通りリダイレクトする。サーバは、この別のアドレスを用いて、大学エンティティへの直接的なコンタクトを確立し、それを介して要求を送信し、応答を受信する。このプロトコルは、匿名性とともに（Ｒｅｑ．４）、ローカル・ウォレットも許さないが（Ｒｅｑ．１）、それはとりわけ、第２のアドレスが、ローカル・ウォレットにとってはユーザの場所となる、大学エンティティの場所を特定するためである。このアドレスを相対化する、すなわち、「私のマシン上」とだけしか言わない周知の方法は現れていない。第１のアドレスも、相対的になるよう意図することはできす、それは、ローカル・ウォレットのすべての名前およびロケーションの知識が、この目的を挫折させるためである。Shibbolethにおけるすべての「アサーション」、すなわち、送信アイデンティティ関連情報が、大学エンティティのドメイン名を含まなければならない点もまた、ローカル・ウォレットと匿名性との組合せと互換性をもたない。さらに、Shibbolethはプライバシ・ポリシーを含むが、要求はサーバによるプライバシ保証（privacypromise）を含まないので、望まれるほどには柔軟性がない（Ｒｅｑ．５を参照）。最後に、ユーザが大学エンティティに情報の公開を事前許可していない要求の場合、ブラウザ・フォーカス（すなわち、ユーザへの質問の仕方）を別のリダイレクトによって再確立しなければならず、その後にはサーバへのさらに別のリダイレクトが続くため、Shibbolethは非効率なフローを有する。
【特許文献１】米国特許第５，９４４，８２４号
【特許文献２】米国特許第６，２２６，７５２号
【発明の開示】
【発明が解決しようとする課題】
【００２０】
上記のことから、人と組織の間の交換プロトコルを含む改良されたアイデンティティ管理システムが当技術分野において依然として必要とされていることが分かる。
【課題を解決するための手段】
【００２１】
本発明は、完全な相互運用性を備え、特に認証情報およびその他のアイデンティティ関連情報の転送、あるユーザだけが所有するブラウザまたはより強力なソフトウェアのバージョン、ユーザについての情報を保有するウォレットとも呼ばれる異なるロケーション・エンティティ、匿名ユーザおよび識別ユーザ、ならびに統合されたプライバシ・ポリシーなど、関係者の様々な要件に適合できる、信頼性が高く効率的なアイデンティティ管理を可能にする。言い換えると、本発明は、例えば、電子ビジネスなど、ウェブ・ベースのサービスのエンド・ユーザが、シングル・サインオンを実行し、サービス・プロバイダとプロファイル情報の制御された交換を行えるようにする。本発明は有利には、一般に中心的なユーザ・インタフェースを提供する、標準的なＨＴＴＰ（ハイパー・テキスト転送プロトコル）ブラウザと共に機能する。提示される方法およびシステムは、ゼロ・フットプリント（zero footprint）・バージョンをサポートする。すなわち、その他のソフトウェアは、Java（Ｒ）script、Java（Ｒ）、またはActiveXのようなアクティブ・コンテンツですらも必要としない（Java（Ｒ）scriptおよびJava（Ｒ）は、サン・マイクロシステムズ・インコーポレイテッドの商標、ActiveXは、マイクロソフト・コーポレーションの商標である）。さらに、本発明は、複数の権限機関（authority）を許容し、どのような単一点障害でも回避できるようにする。すなわち、複数の権限機関がサポートされ、ユーザにはそれらの中から自由に選択する機会が与えられる。その際、ユーザは他の権限機関を信任する必要はない。さらに、権限機関は、パスポートやケルベロスのような公知のソリューションでの場合と異なり、互いに信任する必要はない。ケルベロスは、秘密鍵暗号を用いてクライアント／サーバ・アプリケーションに認証を提供する、ネットワーク認証プロトコルである。
【００２２】
本発明によれば、アイデンティティ関連情報を要求エンティティに提供するための方法が提示され、この方法は、
アイデンティティ関連情報を保有するロケーション・エンティティに対応するロケーション情報をクライアント・アプリケーションに要求するために要求エンティティによって開始されるロケーション要求ステップと、
アイデンティティ関連情報を要求エンティティに転送するようロケーション・エンティティに命令するためにクライアント・アプリケーションをロケーション・エンティティに接続するためのリダイレクト・ステップと、
アイデンティティ関連情報を取得するための獲得ステップとを含み、獲得ステップは、
ロケーション・エンティティが要求エンティティにコンタクトするコンタクト・ステップと、
要求エンティティがアイデンティティ関連情報を要求する要求ステップと、
要求エンティティがアイデンティティ関連情報をロケーション・エンティティから受信する応答ステップとを含む。
【００２３】
この方法は、ロケーション・エンティティがリモートに存在すること、またはそのアイデンティティに関心がもたれている人もしくはユーザのローカル制御下にあることを可能とし、またこの人のロケーションをサーバであり得る要求エンティティに知られないままにしておくことを可能とする。これはまた、アイデンティティ関連情報がロケーション・エンティティから（ａ）クライアント・アプリケーションを介して、または（ｂ）ロケーション・エンティティから直接に、ロケーション・エンティティが要求エンティティに接触して転送されるときにも当てはまる。
【００２４】
獲得ステップはまた、ロケーション・エンティティをクライアント・アプリケーションを介して要求エンティティにリダイレクトし、それによって、アイデンティティ関連情報を要求エンティティに送信するためのリダイレクト・サブステップだけを含むことができる。これは、上記のサブステップよりも高速であるという点で有利であるが、アイデンティティ関連情報が短い場合だけ安全に実行することができる。
【００２５】
この方法はさらに、ＵＲＬ（ユニフォーム・リソース・ロケータ）に入れられる情報の長さに基づいてコンタクト・ステップを実行するかどうかを決定する決定ステップを含むことができる。これは、ＨＴＴＰ１．０ルータおよびプロキシを転送パス上にもつことを可能とする。通常、最長２５５バイトのＵＲＬ全体に至るアイデンティティ関連情報は、容易に利用可能であるべきである。決定ステップは、要求エンティティによって実行することができ、要求エンティティは、要求したアイデンティティ関連情報が十分に短いことを知った場合は、リダイレクト・ステップでコンタクト・アドレスを送信せず、一方、長い応答を受け取る場合、または長い応答を予想する場合は、コンタクト・アドレスだけを送信する。要求エンティティがどちらのケースでも情報を送信する場合は、決定ステップは、ロケーション・エンティティによって実行することができる。
【００２６】
要求エンティティとクライアント・アプリケーションの間、およびクライアント・アプリケーションとロケーション・エンティティの間で使用されるトランスポート・プロトコルが、セキュリティ保護されたハイパー・テキスト転送プロトコル（ＨＴＴＰＳ）であれば、セキュリティ保護された情報転送を保証することができるので有利である。そのようなセキュリティ保護されたチャネルを用いることによって、いわゆる中間攻撃者（man in the middle attack）による攻撃を防ぐことができる。
【００２７】
返されたロケーション情報は、クライアント・アプリケーションのロケーションに対して相対的なものとすることができる。リダイレクト・ステップでのロケーション情報は、相対的なものである場合、「ローカルホスト（localhost）」を示し、絶対的なものである場合、ロケーション情報は、ＵＲＬ（ユニフォーム・リソース・ロケータ）か、またはロケーション・エンティティを識別するその他の情報とすることができ、要求エンティティは、通常のアドレス変換をローカルに行って、またはディレクトリを介して、そうした情報からＵＲＬを導き出す。要求エンティティが適切なロケーション・エンティティのＵＲＬを導き出すのに、関係する人を識別する情報を用いることもでき、その際、人およびそのロケーション・エンティティを一覧にした特別のディレクトリを使用する。
【００２８】
リダイレクト・ステップは、ハイパー・テキスト転送プロトコルのリダイレクトによって、またはローカルホストもしくは導き出されたＵＲＬへのショートＨＴＴＰリダイレクトによって実行することができ、実際の転送命令と戻りアドレス、またはコンタクト・アドレスと、場合によっては転送命令と戻りアドレスを、ロケーション・エンティティに送信する。これによって、獲得ステップは、より柔軟なトランスポート・プロトコルをもつことができ、クライアント・アプリケーションがブラウザの場合、ＰＵＳＨ動作を開始したり、スクリプトを有効にしたりするために、ユーザの手を煩わせて「送信」ボタンを押してもらうようクライアント・アプリケーションに求めずにすますことができる。
【００２９】
この方法はさらに、要求エンティティが偽名を用いているロケーション・エンティティから認証と共にアイデンティティ関連情報を受け取るステップを含むことができ、アイデンティティ関連情報は人の個人的な偽名に対応する。これには、人の匿名性を高い信頼性で保護できる点で利点がある。明らかに、この方法は、通常の非匿名のロケーション・エンティティのアイデンティティおよび個人的なアイデンティティを含む。
【００３０】
この方法はさらに、要求エンティティがアイデンティティ関連情報を使用するためのサーバ・ポリシーを送信するステップを含む。具体的には、要求エンティティまたはサーバは、要求されたアイデンティティ関連情報のための約束したプライバシ・ポリシー、またはプライバシ選択、例えば、プライバシ選択用プラットフォーム（Ｐ３Ｐ）を、例えば、転送命令の中に参照によって、または直接に含むことができる。要求エンティティまたはサーバは、例えば、セキュリティ保護されたストレージについてなど、別のセキュリティ関連ポリシーを含むこともできる。ロケーション・エンティティからのアイデンティティ関連情報はまた、所定のプライバシまたはその他のセキュリティ・ポリシーを含むこともでき、または参照することもできる。これには、例えば、異なる程度の個人化を提供することによって、要求エンティティが最適化された方法で人および異なるポリシーをもつロケーション・エンティティと対話できるという利点がある。要求エンティティは、最低限の情報が提供されない限り、アプリケーション依存の対話の継続を自由に拒否することができる。これは、あるクラスの権限機関による確認、新しさ、または確認者の責任など、情報についてのその他の要件または情報の質と同様に、要求の中で指示することができる。
【００３１】
本発明の第２の態様によれば、ロケーション・エンティティ上でホストされるアイデンティティ関連情報を要求エンティティに転送するための方法が提示され、この方法は、
アイデンティティ関連情報を要求エンティティに転送するための命令情報をクライアント・アプリケーションから受信するためのリダイレクト・ステップであって、リダイレクト・ステップに先立ち、要求エンティティが、ロケーション要求ステップで、アイデンティティ関連情報を保有するロケーション・エンティティに対応するロケーション情報をクライアント・アプリケーションに要求するリダイレクト・ステップと、
アイデンティティ関連情報を要求エンティティに転送するための転送ステップを含み、転送ステップは、
ロケーション・エンティティが要求エンティティにコンタクトするコンタクト・ステップと、
要求エンティティがアイデンティティ関連情報を要求する要求ステップと、
ロケーション・エンティティがアイデンティティ関連情報を要求エンティティに送信する応答ステップとを含む。
【００３２】
転送ステップはさらに、要求ステップで要求されるアイデンティティ関連情報のどの部分を転送すべきかを、事前定義されたポリシーに基づいてロケーション・エンティティが決定するステップを含むことができる。これには、要求エンティティは、役に立つかもしれないすべての情報を求める全般的な要求を行えるが、実際にその情報のうちのどれを、例えば、マーケティング、個人化、または統計目的のために提供したいかを、ロケーション・エンティティに独自のまたはユーザのポリシーに基づいて決定させることができるという利点がある。
【００３３】
応答ステップはさらに、ロケーション・エンティティが事前定義されたポリシーの一部を転送するステップを含むことができる。これには、ロケーション・エンティティが要求エンティティに、アイデンティティ関連情報に関して一定の仕方で動作するよう、例えば、それをさらに転送しないよう、またはそれをしばらく削除しないよう、またはそれを一定期間削除しないよう命令できるという利点がある。
【００３４】
ロケーション・エンティティは、リダイレクト・ステップでクライアント・アプリケーションからロケーション・エンティティに確立されたコネクションを、転送ステップ中の人との対話のために用いることができる。人と対話する利点は、人を認証でき、事前定義されたポリシーに追加できることであり、（獲得ステップの前にコネクションを解放するのとは対照的に）コネクションを再使用する利点は、遅延なしに対話が可能になることである。
【００３５】
要求エンティティへのアイデンティティ関連情報の公開は、次のステップ、すなわち、要求エンティティについての情報を提示するステップと、ロケーション・エンティティが知っている事前認可された属性値を提示し（ここで、事前認可されたとは、事前定義されたポリシーが要求エンティティへの公開を許可していることを意味する）、またはロケーション・エンティティが知っている事前認可されていない属性値を提示し、またはロケーション・エンティティが知らない値については個々の属性値を入力するための空フィールドに付された属性名を提示し、あるいはこれらを組み合わせた提示を行うステップと、属性値の編集を要求するステップと、編集された属性値を要求エンティティに送信するステップとを含むことができる。こうすることによって、ユーザは、知られていない属性値の入力と、事前認可されていない値についてのイエス／ノーの判断だけしか要求されない。これによって、手順が簡略化され、ユーザは、要求エンティティが要求する個人情報を完全に制御できる。
【００３６】
異なる属性値を異なる仕方で、好ましくは異なる色で提示することができる。こうすることで、ユーザへの明瞭な情報提示が可能となり、ユーザはどの情報を入力し、削除し、修正し、または変更せず送信するかを決定することができる。
【００３７】
転送ステップはさらに、ロケーション・エンティティによってランダム値ｋを生成するステップと、ランダム値ｋをアイデンティティ関連情報と同じコネクションを介して要求エンティティに送信するステップと、ランダム値ｋをクライアント・アプリケーションに送信して、クライアント・アプリケーションがアイデンティティ関連情報に関するその本人性を要求エンティティに対して証明できるようにするステップとを含むことができる。これには、アイデンティティ関連情報を転送した後、ユーザの所で動作するクライアント・アプリケーションに、要求エンティティによって追加の特権を与えることができるという利点がある。
【００３８】
本発明の第３の態様によれば、アイデンティティ関連情報を提供するためのシステムが提示され、このシステムは、アイデンティティ関連情報を保有するロケーション・エンティティと、ロケーション・エンティティに接続可能なクライアント・アプリケーションと、アイデンティティ関連情報を保有するロケーション・エンティティに対応するロケーション情報をクライアント・アプリケーションに要求するように適合された要求エンティティとを含み、要求に対する応答の後、クライアント・アプリケーションは、アイデンティティ関連情報を要求エンティティに転送するようロケーション・エンティティに命令するため、ロケーション・エンティティにリダイレクトされ、ロケーション・エンティティは要求エンティティにコンタクトし、要求エンティティはアイデンティティ関連情報を要求し、要求エンティティはアイデンティティ関連情報をロケーション・エンティティから受信する。
【００３９】
このシステムは、第三者にコンタクトする必要なく、ユーザのための関連する権限機関、すなわち、ロケーション・エンティティを容易に識別できるようにし、したがって、従来技術のソリューションに存在したプライバシおよび性能問題は回避される。
【００４０】
このシステムは、ＳＳＬ対応のＨＴＴＰブラウザ、すなわち、セキュア・ソケット・レイヤ対応のハイパー・テキスト転送プロトコル・ブラウザと共に機能し、例えば、クッキーなどの追加の情報、またはJava（Ｒ）script、Java（Ｒ）、ActiveXなどのアクティブ・コンテンツのようなソフトウェアをマシンにインストールすることを受け入れるようユーザに要求するどのような機能も必要としない。同時に、このシステムは、追加の情報を保存できる場合に、効率性の改良を可能とする。
【００４１】
このシステムは、例えば、中間攻撃者の攻撃など、何らかの攻撃に対して、周知のソリューションで提供されるものよりも強力なセキュリティを提供する。
【００４２】
別の例においては、クライアント・アプリケーションは複数のロケーション・エンティティと対話する。これは、異なる場所または同じ場所に、ユーザが複数のロケーション・エンティティをもち得ることを意味し、クライアント・アプリケーションは、人またはユーザと一緒に、ロケーション情報を求める要求に応じて適切なロケーション・エンティティを選択する。したがって、ロケーション・エンティティは、ローカルともリモートともすることができる。そのような構成の利点は、人のために単一点障害を回避し、異なるロケーション・エンティティの中からプライバシを有効にできることである。
【００４３】
アイデンティティ関連情報は、別のロケーション・エンティティによって提供することができる。その場合、要求エンティティは、ロケーション・エンティティを介して、アイデンティティ関連情報を取得することができる。別のロケーション・エンティティのロケーション情報は、ロケーション・エンティティに保存される。そのような構成の利点は、異なるタイプのアイデンティティ関連情報を異なるロケーション・エンティティに保存できるのに、クライアント・アプリケーションまたは人は、ロケーション・エンティティの中から選択しなくてもよいようになることである。
【００４４】
本発明の好ましい実施形態を、添付の概略図を参照しながら、例としてのみ以下で詳しく説明する。
【発明を実施するための最良の形態】
【００４５】
図面は説明の目的で提供されるに過ぎず、必ずしも本発明の実際的な例を実寸に比例させて表すものではない。
【００４６】
用語解説
説明の理解を助けるため、以下に非公式な定義を示す。
【００４７】
人：アイデンティティが管理されるエンティティ。人が行為すると、その人はユーザとなる。一般に、人またはユーザは個人であるが、少なくとも小規模事業体は、例えば、旅行予約や情報収集において、他の事業体としばしば個人のように対話する。
【００４８】
要求エンティティ：例えば、サーバによって表される組織など、人の名前や属性を知りたいと思うエンティティ。初期の組織は、容易に配置可能な登録システムの確実性が低いため、主にインターネット・ショップであろう。長い目で見れば、組織には、銀行、医者、同僚、家族など、人が通信を行うすべての通信相手が含まれる。「組織」としての同僚および家族は、例えば、インスタント・メッセージやカレンダなどのアイデンティティ管理に、連絡先またはロケーション情報を含めたい場合に特に関係する。
【００４９】
ロケーション・エンティティ：人に関するアイデンティティ関連情報を保存するエンティティ。ロケーション・エンティティは、ウォレットとも呼ばれる。ロケーション・エンティティまたはウォレットは、人に関する個人情報を保存し、処理するコンポーネント、一般にソフトウェアを意味する。ロケーション・エンティティ保有者は、人自身または人に委任された第三者とすることができる。事業的なロケーション・エンティティ保有者となるには、プライバシおよびセキュリティ保証、ならびに適切な保護手段などの前提条件を満たす必要がある。一次ロケーション・エンティティ保有者は、人のシングル・サインオン用パスワードを保有し、より一般には、別のエンティティの助けを借りることなく人を認識することができる。したがって、人は、複数のパスワードを記憶していられるのなら、それぞれ異なるタイプの情報を保存する複数の一次ロケーション・エンティティをもつことができる。ローカル・ロケーション・エンティティは、当該の人のコンピュータに存在する。リモート・ロケーション・エンティティは、別のロケーション・エンティティ保有者、一般には事業的なロケーション・エンティティ保有者のコンピュータまたはサーバに存在する。ロケーション・エンティティは、当該の保有者の所に存在する他のロケーション・エンティティと統合することができる。
【００５０】
フェデレーション：一般に、フェデレーションとは、事業的なロケーション・エンティティ保有者およびロケーション・エンティティ製作者のグループのことである。このグループはまた、広く満足できる標準の策定を支援する人および組織の代表を含むこともできるが、人および組織は数百万あることがあり、一方、事業的なロケーション・エンティティ保有に関連するエンティティは、例えば、銀行、ＣＡ（認証局）、ＩＳＰ（インターネット・サービス・プロバイダ）、大規模雇用者など、数万あることがある。
【００５１】
法的エンティティまたは組織は、上で説明した複数の役割を担って行為する。
【００５２】
コンピュータという語には、ＰＣなどの装置が含まれるが、ブラウジング機能を備える携帯情報端末およびモバイル電話も含まれる。
【００５３】
図１を参照すると、本発明を利用し得る通信環境の全体的レイアウトが示されている。図面において、同一参照符号は、同一または類似部分を示すのに使用される。図１には、ユーザ２０として行為する人Ｐが示されている。ユーザ２０は、自分のコンピュータで、例えば、ウェブ・ブラウザなど、クライアント・アプリケーション３０を実行する。クライアント・アプリケーション３０は、アプリケーション依存の対話を行うため、例えば、サービスを提供する企業または銀行のサーバなど、要求エンティティ５０に接続される。クライアント・アプリケーション３０と要求エンティティ５０は、当技術分野で周知の通信線５を介して接続される。通信線５は通常、インターネットなどのネットワークによって提供される。クライアント・アプリケーション３０はさらに、ウォレットとも呼ばれるロケーション・エンティティ４０にも接続されるが、ロケーション・エンティティ４０は、ローカル・エンティティ、すなわち、ユーザ２０のコンピュータに存在するエンティティとすることもでき、あるいはリモート・エンティティ、すなわち、外部サーバその他に存在するエンティティとすることもできる。ロケーション・エンティティ４０はまた、アイデンティティ関連情報ＩＲＩを送信するため、要求エンティティ５０とも接続可能である。アイデンティティ関連情報ＩＲＩという用語によって、人またはユーザに関連する任意の情報が指示されるものとする。アイデンティティ関連情報ＩＲＩには、名前、住所、団体への帰属関係、許可証明書、人口統計データ、個人的な嗜好、カレンダ入力、医療および財務情報、ならびに人についてまたはユーザ名の下でデジタル化して保存可能なその他すべての情報が含まれる。要求エンティティ５０は、アクセス制御、許可、個人化、認証、ログイン、商業もしくは医療もしくは行政問題、またはアイデンティティ関連情報ＩＲＩに基づき動作するその他の任意のアプリケーションのため、アイデンティティ関連情報ＩＲＩを求めることができる。図１のシナリオは、アイデンティティ関連情報ＩＲＩを要求エンティティ５０に提供する以下のフローの説明を容易にするために示されている。
【００５４】
図２には、本発明の第１の実施形態によるメッセージ・フローの概略図が示されている。この図では、クライアント・アプリケーション３０とロケーション・エンティティ４０と要求エンティティ５０の間のフローは、ローマ数字がそれぞれ振られた説明付きの矢印で示される。さらに、ステップまたはサブステップは、円の中のローマ数字によって示される。このフローは、大きくなるローマ数字が示すように、上から下に向って順々に実行されるものと理解されたい。ステップＩでは、アプリケーション依存の対話が、クライアント・アプリケーション３０と要求エンティティ５０の間で実行される。（サブステップＩＩａで）要求エンティティ５０によって開始されるロケーション要求ステップＩＩでは、要求エンティティ５０が、アイデンティティ関連情報ＩＲＩを保有するロケーション・エンティティ４０に対応するロケーション情報ＬＩをクライアント・アプリケーションに要求する。ロケーション情報ＬＩは、サブステップＩＩｃで要求エンティティ５０に送信される。サブステップＩＩｂにおいて、クライアント・アプリケーション３０は、例えば、ユーザ２０にまたは内部的に問い合わせを行うなど、様々な異なる方法の中から任意に選択した方法でロケーション情報ＬＩを取り出すことができる。フローは、（サブステップＩＩＩａで）リダイレクト命令を発行するリダイレクト・ステップＩＩＩに進み、（サブステップＩＩＩｂで）最終的に、クライアント・アプリケーション３０が、ロケーション・エンティティ４０に接続される。その結果、ロケーション・エンティティ４０は、アイデンティティ関連情報ＩＲＩを要求エンティティ５０に転送するよう命令を受ける。獲得ステップＩＶにおいて、要求エンティティ５０は、次のようにしてアイデンティティ関連情報ＩＲＩを取得する。まず、コンタクト・ステップＩＶａが実行されて、ロケーション・エンティティ４０は要求エンティティ５０にコンタクトする。次に、要求ステップＩＶｃが実行されて、要求エンティティ５０がアイデンティティ関連情報ＩＲＩをロケーション・エンティティ４０に要求する。最後に、応答ステップＩＶｅで、要求エンティティ５０はアイデンティティ関連情報ＩＲＩをロケーション・エンティティ４０から受信する。要求は、サブステップＩＶｂによって示される様々な異なる方法で、例えば、リダイレクト・ステップＩＩＩでは要求エンティティ５０に含まれ、コンタクト・ステップＩＶａではロケーション・エンティティ４０に含まれるセッション識別子によって取り出すことができる。さらに、ロケーション・エンティティ４０は、要求のすべてに応答するかどうかを、また要求のどの部分に応答するかを、サブステップＩＶｄによって示されるユーザ認証、ポリシーその他によって決定することができる。応答は、内部情報を用いて、場合によっては外部情報を用いて準備することができる。サブステップＩＶｆは、より多くのアイデンティティ関連情報ＩＲＩを取得するため、またはエラーを回復するために実行される可能性のある要求ステップＩＶｃと応答ステップＩＶｅの繰り返し、および当該の交換について送信される可能性のある終了メッセージを示す。サブステップＩＶｇに示すように、ロケーション・エンティティ４０から（リダイレクト復元ステップＩＶｇ．ｉ）クライアント・アプリケーション３０を介した要求エンティティ５０へのリダイレクトを接続復元ステップＩＶｇ．ｉｉで実行することができる。その後、ステップＶで示すように、クライアント・アプリケーション３０と要求エンティティ５０の間で、再びアプリケーション依存の対話が可能となる。
【００５５】
図３には、第１の実施形態と比べてよく似ているが、コンタクト・ステップＩＶａ、要求ステップＩＶｃ、および応答ステップＩＶｅなしに獲得ステップＩＶが実行される点が異なる、第２の実施形態のメッセージ・フローの概略図が示されている。代わりに、ロケーション・エンティティ４０がクライアント・アプリケーション３０を介して要求エンティティ５０に接続されるリダイレクト・サブステップＩＶｇで、アイデンティティ関連情報ＩＲＩが転送されるようにする。このシナリオでは、ロケーション・エンティティ４０は、サブステップＩＶｄでユーザ２０と対話を行い、ユーザ２０は自分自身を認証する。ある場合には、ロケーション・エンティティ４０が自力で要求エンティティ５０を認識できないので、ユーザ２０は、サブステップＩＶｄで要求エンティティ５０のアイデンティティも確認すべきである。
【００５６】
図４には、セキュリティ保護されたハイパー・テキスト転送プロトコル（ＨＴＴＰＳ）によって提供し得るようなセキュリティ保護されたチャネルを仮定する、第３の実施形態のメッセージ・フローの概略図が示されている。セキュリティ保護されたチャネルは、要求エンティティ５０とクライアント・アプリケーション３０の間に仮定される（図示せず）。第３の実施形態はブラウザに特化される。すなわち、この図では、クライアント・アプリケーション３０は、ユーザ２０によって制御されるブラウザ３０である。したがって、図４には、図の左サイドにさらに１列が追加され、行為ユーザ２０であることを暗示して人２０と表記されている。ユーザ２０はブラウザ３０と対話するよう求められる。ステップＩで、ユーザ２０は要求エンティティ５０を閲覧している。ロケーション要求ステップＩＩは、ブラウザ３０が前に要求エンティティ５０にアクセスしたことがあり、まだセッションがオープンしているか、あるいは要求エンティティ５０がクッキーを設定し、ブラウザ３０がクッキーを受け取っているか、あるいはブラウザ３０が自動的に一定のユーザ設定を転送する場合、周知のソリューションでの場合と同様に省略可能な場合がある。サブステップＩＩａで、ロケーション問い合わせを含むフォームが、要求エンティティ５０からブラウザ３０に送信され、ユーザ２０に提示される。この提示は、図５に示すような仕方で行われ、ユーザ２０は選択肢を用いて、アイデンティティ関連情報ＩＲＩを保有するロケーション情報ＬＩを送信する。ロケーション情報ＬＩは、サブステップＩＩｃで、ロケーション・エンティティ４０がローカルに存在することを示す「ローカルホスト」、またはアドレスとして要求エンティティ５０に送信される。サブステップＩＩａおよびサブステップＩＩｃでは、リダイレクト・ステップＩＩＩに備えて、ロケーション・エンティティ４０が見つけられる。すべてのロケーション・エンティティ４０（この図には１つだけ示されている）がローカル・エンティティである場合、固定ポートに「ローカルホスト」でリダイレクトすることができ、同様に、リモート・ロケーション・エンティティ保有者が１つだけの場合、そのロケーション・エンティティ保有者に直接リダイレクトすることができる。しかし、異なるリモート・ロケーション・エンティティ４０は区別しなければならず、１人のユーザ２０であっても、複数のロケーション・エンティティ４０をもつことができる。これらのステップに関する全体的なユーザ対話を確立する最も簡単な方法は、図５に示すように、上記のフォームを画面上に表示してユーザに提示することである。リダイレクト・ステップＩＩＩは、この例ではＨＴＴＰリダイレクトである、コンタクト・アドレスを要求エンティティ５０からブラウザ３０に送信するサブステップＩＩＩａと、ブラウザ３０をロケーション・エンティティ４０に接続するサブステップＩＩＩｂとを含む。コンタクト・アドレスは、プロトコル・バインディングを含み、プロトコル・バインディングは、ＨＴＴＰバインディングとすることができるが、ＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）バインディングなど別のプロトコルのバインディングとすることもできる。さらに、セッション識別子ＳＩＤが、サブステップＩＩＩｂで使用するため転送される。ステップＩで最後に要求されたＵＲＬなど、その他の情報の転送も可能だが、ロケーション・エンティティ４０に対するユーザのプライバシを侵害する場合もあるので、あまり勧められない。要求エンティティ５０は、所望のアイデンティティ関連情報ＩＲＩが短いと推測すれば、正確な要求と（サブステップＩＶｇで使用可能な）リターン・アドレスを直に含むことができる。それが確かならば、コンタクト情報を省略することさえできる。「短い」を安全に定義するならば、サブステップＩＶｇで結果として返される全体的なＵＲＬが２５５バイトを超えないことと定義される。サブステップＩＩＩｂで接続メッセージを取得することによって、ロケーション・エンティティ４０は、アイデンティティ関連情報ＩＲＩを要求エンティティ５０に転送するよう命令を受ける。獲得ステップＩＶにおいて、要求エンティティ５０は、次のようにしてアイデンティティ関連情報ＩＲＩを取得する。フローが図３を参照して説明したように進行するのでなければ、コンタクト・ステップＩＶａで、ロケーション・エンティティ４０は、コンタクト・アドレスに含まれるプロトコルを用いて、コンタクト・アドレス、すなわち、要求エンティティ５０に接続される。要求ステップＩＶｃが実行され、要求エンティティ５０が、コンタクト・ステップＩＶａで確立されたコネクションを介して、アイデンティティ関連情報ＩＲＩをロケーション・エンティティ４０に要求し、セッション識別子ＳＩＤに従って適切な要求を取り出す。要求は、例えば、同意済みの拡張マークアップ言語（ＸＭＬ）スキーマなど、任意の周知の形式をとることができる。要求エンティティ５０は、応答ステップＩＶｅで、アイデンティティ関連情報ＩＲＩをロケーション・エンティティ４０から受信する。応答は、要求形式に対応する周知の形式、例えば、対応する応答ＸＭＬスキーマの形式をとることができる。ロケーション・エンティティ４０は、要求のすべてに応答するかどうかを、また要求のどの部分に応答するかを、例えば、サブステップＩＶｄによって示すように、ユーザ認証、ポリシー、要求エンティティ５０が要求と共に送信した認証および証明書、ユーザ２０によるリアルタイム・リリース、その他を評価することによって決定することができる。サブステップＩＶｆ．ｉは、戻りアドレスが、例えば、最初に要求されたリソースの異なる個人化バージョンなど、受信された応答に依存する場合があることを示す。次に、戻りアドレスが、サブステップＩＶｆ．ｉｉに示すように、要求エンティティ５０によってロケーション・エンティティ４０に送信される。次に、サブステップＩＶｇに示すように、リダイレクトが実行される。このサブステップでは、戻りアドレスが、サブステップＩＶｇ．ｉで、ロケーション・エンティティ４０からクライアント・アプリケーション３０に送信され、さらにクライアント・アプリケーション３０が、接続復元サブステップＩＶｇ．ｉｉで、戻りアドレス、すなわち、要求エンティティ５０に接続する。このステップでは、以下で図６を参照して説明するように、例えば、ブラウザ３０を認証するための追加の情報を運ぶこともできる。サブステップＩＶｈでは、要求エンティティ５０は、接続ブラウザ３０のために応答ステップＩＶｅで受信した適切な応答を任意の周知の方法で検索し、このブラウザ３０とのさらなる対話でその応答を用いることができる。ＨＴＴＰＳの使用は、このためにセキュリティ保護されたセッションを提供し、セッションはその他の周知のセッション維持機構によって増大する場合もある。その後、ユーザ２０によって実行される、ブラウザ３０と要求エンティティ５０の間のブラウジングが、ステップＶで示されるように、再び実行可能になる。
【００５７】
図５には、図４のロケーション要求ステップＩＩで提示可能なロケーション問い合わせを含む、潜在的ユーザに提示されるフォームまたは画面例の図が示されている。これを現実的なものにするため、識別の拒否、ならびにユーザ名およびパスワードによる従来の認証に加えて、ユーザ２０がどのように入力するかを判断する材料となり得る、要求エンティティ５０、例えば、組織についての情報へのリンクも示されている。「○」はラジオ・ボタンであり、フィールドはテキスト入力用である。「連合アイデンティティ（federated identity）」という語は、選択されるブランド名を表すことができる。「私自身のウォレット」を選択した場合、「ローカルホスト」、すなわち、ローカルに存在するロケーション・エンティティ４０にリダイレクトされる。「ウォレット保有者」を入力した場合、リモート・ロケーション・エンティティ４０のロケーションまたはサーバ・アドレスにリダイレクトされる。検索を選択した場合、要求エンティティ５０は、「私の名前は」の後のフィールドに入力された名前をグローバル・ディレクトリの中から探し出す。この選択肢はプライバシの低下を招くが、中にはロケーション・エンティティのアドレスを忘れてしまう人もいるかもしれない。ユーザ２０は、「私たちについて」をクリックすることで、要求エンティティ５０について知ることができ、「プライバシ・ポリシー」をクリックすることで、ポリシーについて知ることができる。「送信」ボタンをクリックすることで、情報を送信することができる。常にロケーション・エンティティ４０へのコンタクトを許可する場合は、図４を参照しながら説明したように、ユーザがこのような画面を回避するための複数の方法が存在する。
【００５８】
図６には、図４に示す第３の実施形態を、特にサブステップＩＶｄの実施形態、すなわち、応答の導出に関して拡張した形態の概略図が示されている。フローの関連部分のみが示されている。サブステップＩＩＩｂにおいて、ブラウザ３０はロケーション・エンティティ４０に接続する。獲得ステップＩＶにおいて、要求エンティティ５０はアイデンティティ関連情報ＩＲＩを取得する。このステップでは、サブステップＩＶｄ．ｉにおいて、人の認証が実行される。このサブステップＩＶｄ．ｉはまた、コンタクト・ステップＩＶａおよび要求ステップＩＶｃが実行されているときに並列して実行することができる。サブステップＩＶｄ．ｉは、周期の機構によるセキュリティ保護されたセッションが維持されている場合は、省略することができる。次に、サブステップＩＶｄ．ｉｉｉで、部分的に入力されたフォームがユーザ２０に提示される。サブステップＩＶｄ．ｉｉでは、事前定義されたポリシーを用いながら、できる限り応答が準備され、要求−応答フォーマットからユーザフレンドリなフォームへの変換が行われる。サブステップＩＶｄ．ｉｖで、ユーザ２０は、フォームの内容を変更し、その後、サブステップＩＶｄ．ｖで、入力完了フォームである応答が、ブラウザ３０からロケーション・エンティティ４０に送信され、サブステップＩＶｅで、ロケーション・エンティティ４０は、応答を要求−応答フォーマットに再び変換して要求エンティティ５０に転送する。
【００５９】
図７には、図６のサブステップＩＶｄ．ｉｉｉでユーザ２０に提示される、部分的に入力されたフォームの図が示されている。最初のテキストはフォームについて説明し、誰が当該の情報を要求しているかを示している。すなわち、＜名前＞の部分には、コンタクト・ステップＩＶａ中の要求エンティティ５０の認証においてロケーション・エンティティ４０が取得する、要求エンティティ５０の名前が入る。別の実施形態で、そのような認証が応答ステップＩＶｅに先行して行われない場合、こうしたフォームのこの行は、しかるべく異なる形に定型化され、例えば、ユーザ２０は、ステップＩにおいて、ＨＴＴＰＳコネクションのサーバ証明書をチェックするよう求められるべきである。「名前」、「発送先住所」、「国ＩＤ番号」、および「あなたの収入」は、属性または属性名の例である。「名前」、「発送先住所」、および「国ＩＤ番号」にそれぞれ対応する属性値は、この例ではロケーション・エンティティ４０がそれらを知っていると仮定されているので、すでに入力されている。「あなたの収入」は、ロケーション・エンティティ４０に知られていないので、空白である。知られている属性のうち、「名前」と「発送先住所」は、事前に許可されていると仮定されているが、「国ＩＤ番号」はそうではない。したがって、それらの属性値は、どの情報が機密情報であり、どの情報がそうでないかをユーザ２０が一目で分かるように、異なるユーザ・インタフェースのスタイルで、例えば、異なる色で提示される。ユーザ２０は、与えられた属性値をまったく自由に編集し、削除することができ、未入力の属性値を入力することができる。任意選択で、どれが送信要または確認要の項目であるかについて、「＊」などのマークによってユーザ２０に指示を与えてもよい。すなわち、提示の中にはさらに、受信エンティティ５０の観点から見て、属性を必須または任意属性として特徴付ける要素が含まれる。ユーザ・インタフェース要素およびマークの意味が、この例では、「赤：」および「＊：」で始まる行で説明される。「送信」ボタンは、フォーム中の情報の送信を許可する。別の例では、サブステップＩＶｄ．ｉｉｉからＩＶｄ．ｖを繰り返し実行することができ、その際、サブステップＩＶｄ．ｉｉｉの繰り返しにおいて、属性が、例えば、エラー・メッセージなど、ロケーション・エンティティ４０による追加の注釈と共に提示され、要求エンティティ５０への応答は、サブステップＩＶｄ．ｖにおける発信の最後の繰り返しの後、１回だけ行われる。提示は、属性用の編集可能フィールドを含む通常のウェブ・フォームとして実行することができる。別の例では、ユーザ２０が編集フェーズを終えた後、または必須属性が未入力である旨の特定の注釈が示されたステップを適当な回数繰り返した後、未入力または未許可の必須属性が１つでもある場合は、属性は発信されない。
【００６０】
図８には、サブステップＩＶｇでブラウザ３０の本人性を提供するように、第１または第３の実施形態を拡張した形態の概略図が示されている。ロケーション・エンティティ４０から見た場合、この図における獲得ステップＩＶは、転送ステップＩＶと呼ばれる。図８は、リダイレクト・ステップＩＩＩの第２パートである、クライアント・アプリケーション３０がロケーション・エンティティ４０に接続するサブステップＩＩＩｂから始まっている。コンタクト・ステップＩＶａは、ロケーション・エンティティ４０が要求エンティティ５０にコンタクトする際に実行される。次に、要求ステップＩＶｃが、要求エンティティ５０がアイデンティティ関連情報ＩＲＩをロケーション・エンティティ４０に要求する際に実行される。サブステップＩＶｄにおいて、ランダム値ｋがロケーション・エンティティ４０によって生成される。応答ステップＩＶｅにおいて、ランダム値ｋと共に応答が要求エンティティ５０に送信される。サブステップＩＶｆ．ｉｉは、要求エンティティ５０からロケーション・エンティティ４０への戻りアドレスの送信を示す。次に、サブステップＩＶｇに示されるリダイレクトが実行される。このステップでは、ランダム値ｋを伴う戻りアドレスが、サブステップＩＶｇ．ｉにおいて、ロケーション・エンティティ４０からクライアント・アプリケーション３０に送信され、さらにクライアント・アプリケーション３０が、接続復元サブステップＩＶｇ．ｉｉに示すように、戻りアドレス、すなわち、ランダム値ｋを受信する要求エンティティ５０に接続される。サブステップＩＶｈにおいて、要求エンティティ５０は、受信したランダム値ｋを用いて、同じランダム値ｋが発生した応答ステップＩＶｅで受信した応答を検索する。要求エンティティ５０によって開始された、クライアント・アプリケーション３０と要求エンティティ５０の間のアプリケーション依存の対話が、ステップＶに示すように再び実行可能になる。ランダム値ｋをクライアント・アプリケーション３０に送信することによって、クライアント・アプリケーション３０は、アイデンティティ関連情報ＩＲＩに関するその本人性を要求エンティティ５０に対して証明することができる。別の例では、値ｋは疑似ランダムであるに過ぎず、あるいは部分的にしか疑似ランダムであるに過ぎない。しかし、値ｋは、すべての適正な例において、実質的には推定不可能であるべきである。
【００６１】
図９には、図１を参照しながら説明した通信環境を拡張した環境の概略図が示されている。第２のロケーション・エンティティ４２が、図１に追加されて配置されている。第２のロケーション・エンティティ４２は、ローカルに存在することも、リモートに存在することもでき、通信線５を介して、クライアント・アプリケーション３０および要求エンティティ５０と接続可能である。一般に、１つのクライアント・アプリケーション３０、すなわち、１つのブラウザ３０は、この例では、複数のロケーション・エンティティ４０、４２と対話し、ロケーション要求ステップＩＩにおいて適切な一方を選択する。
【００６２】
図１０には、図１または図９を参照しながら説明した通信環境の別の構成の概略図が示されている。この例では、アイデンティティ関連情報ＩＲＩは、追加されたロケーション・エンティティ、すなわち、第２のロケーション・エンティティ４２によって提供される。要求エンティティ５０は、以降、第１のロケーション・エンティティ４０とも呼ばれる、ロケーション・エンティティ４０を介して、アイデンティティ関連情報ＩＲＩを取得することができる。したがって、第２のロケーション・エンティティ４２のロケーション情報ＬＩは、第２のロケーション・エンティティ４２がどのようなアイデンティティ関連情報ＩＲＩを保有しているかを示す指示と共に、第１のロケーション・エンティティ４０に保存される。したがって、クライアント・アプリケーション３０は、ロケーション要求ステップＩＩにおいて、常に第１のロケーション・エンティティ４０を選択する。この例では、第２のロケーション・エンティティ４２は、第１のロケーション・エンティティ４０とだけ接続され、第１のロケーション・エンティティ４０が、サブステップＩＶｄにおいて、アイデンティティ関連情報ＩＲＩを第２のロケーション・エンティティ４２から直接取り出す実施形態が示されている。アイデンティティ関連は、認証またはその他のセキュリティ属性を第２のロケーション・エンティティ４２から運ぶことができる。別の例では、第１のロケーション・エンティティ４０が、サブステップＩＶｄにおいて、クライアント・アプリケーション３０を第２のロケーション・エンティティ４２にリダイレクトすることができ、第２のロケーション・エンティティ４２もユーザ２０と対話することが可能になる。さらに別の例では、第２のロケーション・エンティティ４２は、要求エンティティ５０のコンタクト情報を第２のロケーション・エンティティ４２に転送することができ、その結果、第２のロケーション・エンティティ４２は、アイデンティティ関連情報ＩＲＩを要求エンティティ５０に直接転送することができる。
【００６３】
図面に示すすべての例では、要求エンティティ５０とロケーション・エンティティ４０（または４２）が直接互いに認証し合うことができると仮定された。これは、周知の技法、例えば、それぞれのフェデレーションで同意されたルート権限機関の共通の組を有する公開鍵証明書を用いて容易に達成することができる。例えば、コネクションがＨＴＴＰＳまたはＴＣＰ（伝送制御プロトコル）を利用するその他のプロトコルを用いている場合、要求エンティティ５０は、コンタクト・ステップＩＶａにおいて、セキュア・ソケット・レイヤ（ＳＳＬ）サーバ証明書を用いて、ロケーション・エンティティ４０に対して認証することができる。匿名性を可能にするため、例えば、自由に選択可能なアイデンティティ関連情報ＩＲＩだけが要求されている場合には、ロケーション・エンティティ４０は、このような証明書をいつでも使用すべきではない。アイデンティティ関連情報ＩＲＩが、（図１０の第１のロケーション・エンティティ４０および第２のロケーション・エンティティ４２でもよい）周知の権限機関による確認を必要とする場合、例えば、Ｘ５０９証明書に関するＸＭＬ署名によって確認することができる。別の例では、要求エンティティ５０とロケーション・エンティティ４０（または４２）は、事前に特別な鍵を交換し、それらを使用することができる。さらに別の例では、（少なくともＨＴＴＰＳの他に）対称鍵だけは使用してよいが、要求エンティティ５０とロケーション・エンティティ４０は、鍵をアプリオリに交換しない。これも可能であるが、いくぶん匿名性を低下させ、より強固な相手エンティティの信用を互いに必要とする。具体的に、図２を参照すると、コンタクト・ステップＩＶａは、ロケーション・エンティティ４０と要求エンティティ５０のために、一連の中間物を介してケルベロス鍵交換プロトコルによって拡張することができる。図３を参照すると、ロケーション・エンティティ４０は、同じプロトコルを開始することができ、あるいはクライアント・アプリケーション３０は、一連の中間物を介してリダイレクトすることができ、各中間物は、アイデンティティ関連情報ＩＲＩ（ここでは一般に認証情報）を有する新しい「チケット」を、ケルベロスと同様な、しかし鍵交換としてでなくＨＴＴＰ内の前のチケットに基づいてクライアント・アプリケーションに付与する。
【００６４】
開示された実施形態はいずれも、図示または説明あるいはその両方を行った、１つまたは複数の他の実施形態と結合させることができる。実施形態の１つまたは複数の機能についても結合が可能である。
【００６５】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現することができる。どのようなタイプのコンピュータ・システムでも、または本明細書に記載の方法を実行するよう適合させたその他のどのようなタイプの装置でも、適している。ハードウェアとソフトウェアの一般的な組合せは、ロードされて実行された際に本明細書に記載の方法が実行されるようにコンピュータ・システムを制御するコンピュータ・プログラムを有する、汎用コンピュータ・システムとすることができる。本発明はまた、本明細書に記載の方法の実施を可能にするすべての機能を含み、コンピュータ・システムにロードされた際にこれらの機能を実行できる、コンピュータ・プログラム製品に組み込むこともできる。
【００６６】
コンピュータ・プログラム手段またはコンピュータ・プログラムとは、本明細書の文脈では、特定の機能を実行する情報処理能力をシステムに直接に、またはａ）別の言語、コード、もしくは表記への変換、ｂ）異なる材料形態による複製のうちの一方もしくは両方の後にもたせることを目的とした命令の組からなる、任意の言語、コード、または表記による、表現のことである。
【図面の簡単な説明】
【００６７】
【図１】本発明によるシステムの概略図である。
【図２】本発明による第１の実施形態のメッセージ・フローを示した概略図である。
【図３】第２の実施形態のメッセージ・フローを示した概略図である。
【図４】第３の実施形態のメッセージ・フローを示した概略図である。
【図５】図４のステップＩＩで送信されるロケーション問い合わせを含む、潜在的ユーザに提示されるフォームの図である。
【図６】図４に示す第３の実施形態を拡張した形態の概略図である。
【図７】部分的に入力された、ユーザに提示される別のフォームの図である。
【図８】クライアント・アプリケーションの本人性の証明を可能とするように、第１または第３の実施形態を拡張した形態の概略図である。
【図９】１つのクライアント・アプリケーションが複数のロケーション・エンティティと対話するシステムの概略図である。
【図１０】アイデンティティ関連情報が追加ロケーション・エンティティによって提供され、ロケーション・エンティティを介して要求エンティティによって取得可能となるシステムの概略図である。
【図１】
2005528679.tif 000003
【図２】
2005528679.tif 000004
【図３】
2005528679.tif 000005
【図４】
2005528679.tif 000006
【図５】
2005528679.tif 000007
【図６】
2005528679.tif 000008
【図７】
2005528679.tif 000009
【図８】
2005528679.tif 000010
【図９】
2005528679.tif 000011
【図１０】
2005528679.tif 000012
【国際調査報告】
2005528679.tif 000013
2005528679.tif 000014
2005528679.tif 000015