JP2006254464A - アクセス管理システム等におけるリソース等にアクセスする権限の委任 - Google Patents

Abstract

【課題】第１の組織のリソースが、そのリソースへのアクセスを第２の組織の要求者に提供する方法を提供すること。
【解決手段】第１の組織の第１の管理者は、第１の信用情報を第２の組織の第２の管理者に発行する。この第１の信用情報には、第２の管理者が第１の管理者に代わって第２の信用情報を要求者に発行することができるというポリシーが含まれる。第２の管理者は、発行された第１の信用情報を含む第２の信用情報を要求者に発行する。要求者はリソースへのアクセスを要求し、その要求に発行された第１および第２の信用情報を含める。リソースは、発行された第１の信用情報が第１の管理者を第２の管理者に結びつけ、発行された第２の信用情報が第２の管理者を要求者に結びつけるものであることを検証する。したがってリソースは、要求が、第１の管理者から第２の管理者を経由して要求者に委任された権限に基づくものであることを確認することができる。
【選択図】図４

Description

本発明は、デジタルコンテンツあるいはデジタルサービスなどのリソースへのアクセスが、例えばデジタルライセンスまたは証明書の形で表すことができる対応するアクセス許可のみに従って提供されるアクセス管理システムに関する。より詳細には、本発明はアクセス許可の委任に関する詳細な事前の知識がなくてもリソースへのアクセスが許可されるような方法で、そのリソースにアクセスする権限を委任することに関する。

アクセス管理は、デジタルオーディオ、デジタルビデオ、デジタルテキスト、デジタルデータ、デジタルマルチメディア等を含むことができるデジタルサービスまたはデジタルコンテンツなどのデジタルリソースへのアクセスを許可することに関して非常に望ましいものである。リソースは、ユーザがアクセスしたいと望む情報を含む前述のコンテンツ等、コンテンツ等のライブラリを含むサーバ等、または他の任意のデジタルリポジトリなどのことがあり、例えば電子メールサーバ、ゲームサーバ、ネットワークアクセスサーバもしくはアクセスポイントなどのことがある。さらにリソースは、プリンタ、コンパイラ、レンダラなどのサービスのこともある。

一般に、アクセス管理の環境では、要求者がその要求者を識別する信用情報が含まれた要求を提示したときに、その要求者にリソースへのアクセスが許可される。例えば信用情報には、要求者に発行されその要求者を識別するためのデジタル証明書を含めることができる。いずれにしても、信用情報は一般に、リソースに認識されかつリソースによって信頼されている発行者によって発行される。例えば、ある組織の環境の中では、リソースとはデータサーバによって管理されたデータファイルであることがあり、発行者とは組織の各メンバーに識別のための信用情報を提供するように管理者によって設定された識別サーバのことがある。

信用情報およびおそらくは他の情報に基づいて、要求されたリソースにアクセスする資格を要求者が実際に有していることが示された場合には、リソースは要求されたアクセスを提供する。例えば、要求がリソースのデータファイルである場合には、リソースはそのデータファイルを提供し、要求がリソースで使用できる情報を調査することである場合には、リソースは要求者が実際にその様な情報を調査することを可能にする。

特に、少なくともいくつかの実例では、リソースはデータを要求者に提供している。その場合リソースは、要求者は解読することができるが、他の人々は解読できない形式に従ってデータを暗号化することを選択することができる。例えば、要求者によって提示される信用情報は、要求者に関する公開鍵を含むデジタル証明書のことがあり、その場合リソースは、提示された信用情報の公開鍵に従って提供するデータを暗号化する。したがって、要求者はデジタル証明書に関連する対応する秘密鍵を暗号化されたデータに適用してそのデータを復号することができる。

特にまた、リソースは要求者が従わなければならない条件を暗号化されたデータに添付することを選択することもできる。その場合には、ここでも要求者の提示した信用情報がその要求者に関する公開鍵を含むデジタル証明書であると想定すると、リソースは、提供するデータを選択された対称鍵に従って暗号化し、その対称鍵を提示された信用情報の公開鍵に従って暗号化し、さらに暗号化された対称鍵と条件をデジタルライセンスに含めることができる。したがって要求者は、当然のことながらライセンスの条件がそのことを許可していると想定してのことであるが、デジタル証明書に関連する対応する秘密鍵をライセンスの暗号化された対称鍵に適用してその対称鍵を復号し、次いで解読された対称鍵を暗号化されたデータに適用してそのデータを復号することができる。

一般にリソースは、要求者または少なくともその要求者の信用情報を提供する管理者についての事前の知識を持っていることが想定されており、従ってその事前の知識に基づいて要求者にアクセスを提供する。例えばリソースは、そのリソースにとって既知である特定の組の要求者にだけアクセスを許可するか、またはそのリソースにとって既知である特定の管理者からの信用情報を提供する要求者だけにアクセスを提供するというルールに従うことができる。要求者がこの様なグループに属していない場合には、このルールに従って、リソースはその要求者にはアクセスを提供しない。

しかし、リソースにとって未知の要求者であるか、またはリソースが従うべきルール、すなわち特定の組の要求者であるかもしくは特定の管理者からの信用情報を有している要求者であることというルールの範囲外の要求者であっても、その要求者にアクセスを提供しなければならない状況が存在する。例えば、組織ＡＢＣ内部のリソースは、各従業員がＡＢＣの管理者からの適切な信用情報を所有していることが示されるＡＢＣのすべての従業員にアクセスを提供するというアクセスルールに従うように設定することができる。それでもやはり、ＡＢＣがＸＹＺの契約者を雇用し、そのＸＹＺの契約者もまたリソースにアクセスしなければならないことがある。

このような場合、従来技術では、このようなＸＹＺの各契約者にＡＢＣの管理者からＡＢＣの信用情報を与えることによって、ＸＹＺの契約者にＡＢＣのリソースへのアクセスを提供することが可能である。しかし、特に、このようなＡＢＣ信用情報によって、ＸＹＺの契約者をＡＢＣの従業員と同様に扱う効果を持たせることになる場合や、ＸＹＺの契約者が他のＡＢＣのリソースに不正にアクセスすることが可能になる場合には、ＡＢＣの管理者がＸＹＺの各契約者にＡＢＣの信用情報を与えることを嫌がることがある。

別法として、やはり従来技術において、ＡＢＣのリソースへのアクセスルールを変更することによって、ＸＹＺの契約者にＡＢＣのリソースへのアクセスを提供することも可能である。例えば、このようなアクセスルールを変更して、ＸＹＺの契約者がＸＹＺの管理者からの信用情報を有していることに基づいて、ＡＢＣのリソースがＸＹＺの契約者の特定の組にアクセスを提供することを可能にすることもできる。しかし、リソースへのアクセスルールを変更することは、特にアクセスルールをアクセスポリシーの変更に従って絶えず継続的に変更しなければならない場合には、厄介であり重荷になり得ることを理解されたい。さらに、特定の組織内に存在し得る多くのリソースの各々に対するアクセスルールを変更することは、容易に膨大なタスクになり得ることを理解されたい。

同様に、ＡＢＣの従業員の一部だけが所与のリソースにアクセスすることが許可される場合もある。長い間には、他の従業員にリソースへの一時的なアクセスを許可することが必要になることもある。例えば、許可されたアクセス権を有する従業員の旅行中に、部下に一時的なアクセスを許可する必要が生じることがある。アシスタントにアクセスを許可して、アシスタントが特定のビジネス処理のために彼らの代理を務めることができるようにすることが望まれる場合もあり得る。

したがって従来技術においては、通常はあるリソースへのアクセス権を有していないＡＢＣの従業員に、もともと許可されていた従業員と同様のリソースへのアクセス権を与えることになる。このことが、新しい信用情報の発行または新しいアカウント属性の設定を必要とする場合には、特にそうすることによって、従業員に望ましいアクセス権以上のアクセス権を許可することになり、あるいはそのアクセス権が不要になったときに、そのアクセス権を削除するために追加の管理動作を行うことが必要になるなどの影響が生じ得る場合には、ＡＢＣの管理者はそうすることを嫌がることがある。

したがって、リソースが、それまでそのリソースに知られていなかった要求者に、アクセスルールなどに従ってアクセスを提供できる方法および機構が必要とされている。具体的には、例えば管理者など定義された信頼できるソースだけに注目して、アクセスを要求者に提供すべきかどうかを決定することができる方法および機構が求められている。さらに、要求者が定義された信頼できるソースが属する組織の内部にいるのか外部にいるのかにかかわらず、定義された信頼できるソースによって要求者にアクセスを提供するかどうかを識別することができる方法および機構が求められている。

前述のニーズの少なくとも一部は、第１の組織のリソースがそのリソースへのアクセスを第２の組織の要求者に提供する方法を提供する本発明によって満たされる。第１の組織はリソースによって信頼された第１の管理者を有し、第２の組織は第２の管理者を有しており、第１および第２の各管理者は各エンティティに信用情報を発行する。管理者がエンティティに発行した各信用情報はエンティティを発行元の管理者に結びつけ、そのエンティティと発行元の管理者の間の関係を明示する。

この方法では、第１の管理者は第２の管理者に第１の信用情報を発行し、この発行された第１の信用情報には、第２の管理者が第１の管理者に代わって第２の信用情報を発行することができるというポリシーが記載される。第２の管理者は、第１の管理者に代わって第２の信用情報を実際に要求者に発行し、この発行された第２の信用情報は、発行された第１の信用情報を含むかまたはそれを参照することができる。第２の組織の要求者は、後ほど第１の組織のリソースへのアクセスを要求し、その際、その要求に発行された第１の信用情報と第２の信用情報を含める。

リソースは要求を受信し、発行された第１の信用情報を検証して、その発行された第１の信用情報が信頼できる第１の管理者を第２の管理者に結びつけるものであることを確認し、また、この発行された第１の信用情報のポリシーにより第２の管理者が第２の信用情報を要求者に発行することが許可されていることを確認する。リソースはまた、発行された第２の信用情報を検証して、発行された第２の信用情報が第２の管理者を要求者に結びつけるものであることも確認する。この検証に成功したと想定して、リソースは、その要求者からのその要求が、信頼された第１の管理者から第２の管理者を経由して要求者に委任された権限に基づくものであることを認識し、リソースへのアクセス要求の処理を進める。したがって、第１の組織の信頼できる第１の管理者からその要求者に信用情報が全く発行されていない場合でも、第１の組織のリソースは第２の組織の要求者へのアクセスを認識し許可することができる。

同様に、エンドユーザがその権限の一部または全てを他のエンドユーザに委任することも可能である。この方法では、第１の管理者は第１のエンドユーザに第１の信用情報を発行し、発行される第１の信用情報には、リソースに対する第１のエンドユーザの権限を決定するために必要な情報が含まれ、また第１のエンドユーザが第１の管理者の代わりに第２の信用情報を要求者に発行することができるというポリシーが記載される。第１のエンドユーザは、第１の管理者に代わって第２の信用情報を要求者に実際に発行し、発行される第２の信用情報は発行された第１の信用情報を含むか、またはそれを参照することができる。要求者は、後ほどリソースへのアクセスを要求し、その際、その要求に発行された第１の信用情報と第２の信用情報を含める。次にリソースは、これらの信用情報を前述と同様に検証するとともに使用して、アクセスを許可すべきかどうかを決定することができる。

前述の要約、ならびに以下の本発明の実施形態についての詳細な説明は、添付の図面と併せて読むことによってより良く理解できるはずである。本発明の例示のために、図面には現在好ましい実施形態が示されている。しかし、本発明が、図示された構成や手段そのものに制限されるものではないことを理解されたい。

［コンピュータ環境］
図１および以下の議論は、本発明を実装することができる適切なコンピュータ環境についての簡潔で一般的な説明を提供することを意図したものである。しかし、ハンドヘルド、ポータブル、および他のあらゆる種類のコンピュータ装置が、本発明とともに使用されることが企図されていることを理解されたい。以下では汎用コンピュータについて説明しているが、これは一例に過ぎず、本発明はネットワークサーバとの相互接続および対話が可能なシンクライアントだけを必要とする。したがって、本発明は、例えばクライアント装置が単なるブラウザまたはワールドワイドウェブへのインタフェースとしてだけ機能するネットワーク環境など、非常に少ないまたは最小のクライアントリソースを意味するネットワークホストサービスの環境に実装することができる。

必須ではないが、本発明は、開発者による使用のためにアプリケーションプログラムインタフェース（ＡＰＩ）を介して実装することおよび／またはネットワークブラウジングソフトウェア内に含めることが可能であり、クライアントワークステーション、サーバ、その他の装置など、１つまたは複数のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能な命令の一般的な環境で説明される。一般に、プログラムモジュールは特定のタスクを実施するかまたは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。一般に、プログラムモジュールの機能を、必要に応じて様々な実施形態の形に組み合わせるかまたは分散させることができる。さらに、当業者ならば、本発明を他のコンピュータシステム構成を用いて実施できることが理解されよう。本発明とともに使用するのに適した他の周知のコンピュータシステム、環境、および／または構成には、これらに限られるものではないが、パーソナルコンピュータ（ＰＣ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドもしくはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明を分散コンピュータ環境においても実施することができ、その場合は、各タスクが通信ネットワークまたは他のデータ通信媒体を介してリンクされたリモート処理装置によって実行される。分散コンピュータ環境では、各プログラムモジュールをローカルおよびリモートの両方のコンピュータ記憶媒体、例えばメモリ記憶装置などに配置することができる。

したがって図１は、本発明を実装することができる適切なコンピュータシステム環境１００の一例を示したものである。先に明示したように、コンピュータシステム環境１００は適切なコンピュータ環境の一例に過ぎず、本発明の使用または機能の範囲に関するいかなる制限を示唆することを意図したものでもない。またコンピュータ環境１００を、例示の動作環境１００に示されたコンポーネントのいずれかまたはそれらの組合せに関して、何らかの依存性または要件を有するものと解釈すべきものでもない。

図１を参照すると、本発明を実装するための例示的システムには、コンピュータ１１０の形の汎用コンピュータ装置が含まれている。コンピュータ１１０のコンポーネントは、これらに限られるものではないが、処理ユニット１２０、システムメモリ１３０、システムメモリなど様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１などを含むことができる。システムバス１２１は、メモリバスもしくはメモリコントローラ、ペリフェラルバス、様々なバスアーキテクチャのいずれかを使用するローカルバスなど、いくつかの種類のバス構造のうちの任意のものを使用することができる。限定の意味ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、（メザニンバスとも呼ばれる）ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスなどが含まれる。

コンピュータ１１０は一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセス可能な任意の使用可能媒体であってよく、揮発性および不揮発性媒体、リムーバブルおよび固定の両方の媒体を含む。限定の意味ではなく例として、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実装された、揮発性／不揮発性、リムーバブル／固定の両方の媒体を含む。コンピュータ記憶媒体は、これらに限られるものではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術製品、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋｓ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、あるいは所望の情報を格納するために使用できかつコンピュータ１１０によってアクセス可能な他の任意の媒体を含む。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータを、搬送波や他の伝送機構などの被変調データ信号の形で実施するとともに、いずれかの情報送達媒体を含む。「被変調データ信号」という用語は、情報を信号中に符号化するような方法で設定または変更された、１つまたは複数の信号特性セットを含む信号を意味する。限定の意味ではなく例として、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外、その他の無線媒体などの無線媒体を含む。上記の任意の組合せもコンピュータ可読媒体の範囲に含まれるものとする。

システムメモリ１３０は、ＲＯＭ（読み出し専用メモリ）１３１やＲＡＭ（ランダムアクセスメモリ）１３２など揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。基本入／出力システム（ＢＩＯＳ）１３３は、例えば起動の間などに、コンピュータ１１０内の各要素間の情報転送を支援する基本ルーチンを含み、通常はＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、処理ユニット１２０によって即時にアクセス可能かつ／または現在実行中の、データおよび／またはプログラムモジュールを含む。限定の意味ではなく例として、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が示されている。

コンピュータ１１０はまた、他のリムーバブル／固定、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。単なる例示として、図１には固定な不揮発性の磁気媒体に読み書きするハードディスクドライブ１４１、リムーバブルな不揮発性磁気ディスク１５２に読み書きする磁気ディスクドライブ１５１、ならびにＣＤ−ＲＯＭや他の光媒体などリムーバブルで不揮発性の光ディスク１５６に読み書きする光ディスクドライブ１５５が示されている。例示の動作環境で使用できる他のリムーバブル／固定、揮発性／不揮発性のコンピュータ記憶媒体には、これらに限られるものではないが、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は一般に、インタフェース１４０などの固定メモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インタフェース１５０などのリムーバブルメモリインタフェースによってシステムバス１２１に接続される。

上で論じ図１に示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読命令、データ構造、プログラムモジュール、他のデータなどの記憶を提供する。図１において、例えばハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するように図示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一であっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくともそれらが異なるコピーであることを示すために、図１では異なる番号が付与されている。ユーザはキーボード１６２、および一般にマウス、トラックボール、またはタッチパッドなどを意味するポインティング装置１６１などの入力装置を介してコンピュータ１１０に命令または情報を入力することができる。他の入力装置（図示せず）として、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含むことができる。これらおよび他の入力装置は、システムバス１２１に結合されたユーザ入力インタフェース１６０を介して処理ユニット１２０に接続されることが多いが、例えばパラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）など、他のインタフェースやバス構造によって接続することもできる。

モニタ１９１または他の種類の表示装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。ノースブリッジ（Ｎｏｒｔｈｂｒｉｄｇｅ）などのグラフィックインタフェース１８２もまたシステムバス１２１に接続することができる。ノースブリッジは、ＣＰＵ、またはホスト処理ユニット１２０と通信するチップセットであり、ＡＧＰ（ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ）通信の役割を担う。１つまたは複数のグラフィック処理ユニット（ＧＰＵ）１８４はグラフィックインタフェース１８２と通信することができる。この関連で、ＧＰＵ１８４は一般に、レジスタ記憶装置などのオンチップメモリ記憶装置を含み、ＧＰＵ１８４はビデオメモリ１８６と通信する。しかし、ＧＰＵ１８４はコプロセッサの一例に過ぎず、従ってコンピュータ１１０には様々なコプロセッサ装置を含めることができる。モニタ１９１または他の種類の表示装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続することができ、またビデオメモリ１８６とも同様に通信することができる。モニタ１９１に加え、コンピュータはスピーカ１９７やプリンタ１９６などの他の周辺出力装置を含むこともできるが、これらの装置は出力ペリフェラルインタフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードであってもよい。また、図１にはメモリ記憶装置１８１だけが示されているが、リモートコンピュータ１８０は一般に、コンピュータ１１０に関連して上で説明した諸要素の多くまたはすべてを含むことができる。図１に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーク環境は、オフィス、企業内コンピュータネットワーク、イントラネット、インターネットにおいて一般的なものである。

ＬＡＮネットワーク環境で使用されるときには、コンピュータ１１０はネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境で使用されるときには、コンピュータ１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２、その他の手段を含む。モデム１７２は内蔵でも外付けでもよいが、ユーザ入力インタフェース１６０または他の適切な機構によってシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関連して示されたプログラムモジュールまたはその一部を、リモートのメモリ記憶装置に格納することができる。限定の意味ではなく例として、図１では、リモートのアプリケーションプログラム１８５がメモリ装置１８１上に存在するように示されている。図示のネットワーク接続が例示的なものであり、コンピュータ間通信リンクを確立する他の手段が使用できることが理解されよう。

当業者ならば、コンピュータ１１０または他のクライアント装置をコンピュータネットワークの一部として配置できることが理解できよう。これに関して、本発明は、任意の数のメモリまたは記憶ユニットを備え、任意の数の記憶ユニットまたはボリュームに渡って存在する任意の数のアプリケーションおよびプロセスを備えた任意のコンピュータシステムに適するものである。本発明は、サーバコンピュータおよびクライアントコンピュータがネットワーク環境に配置されリモートまたはローカルの記憶装置を備える環境に適用することができる。本発明はまた、プログラミング言語機能、解釈および実行機能を有するスタンドアロンコンピュータ装置にも適用することができる。

分散コンピューティングでは、コンピュータ装置とシステムの間の直接交換によってコンピュータリソースおよびサービスの共用が容易になる。このようなリソースおよびサービスには、情報の交換、キャッシュ記憶装置、ファイル用のディスク記憶装置などが含まれる。分散コンピューティングは、ネットワーク接続性を活用し、各クライアントがその集合的な力を利用して企業全体の利益に貢献することを可能にするものである。その際、様々な装置は、信頼できるグラフィックスパイプラインのための本発明の認証技術を結びつけるために相互に対話することができるアプリケーション、オブジェクト、またはリソースを備えることができる。

図２は、例示的なネットワークまたは分散コンピューティング環境の概略構成図を示す。分散コンピューティング環境はコンピューティングオブジェクト１０ａ、１０ｂ等、ならびにコンピューティングオブジェクトまたは装置１１０ａ、１１０ｂ、１１０ｃ等を含む。これらのオブジェクトは、プログラム、メソッド、データストア、プログラマブルロジックなどを含むことができる。オブジェクトはそれらの一部、またはＰＤＡ、ＴＶ、ＭＰ３プレーヤ、ＴＶ、パーソナルコンピュータなどの異なる装置を含むことができる。各オブジェクトは、通信ネットワーク１４によって他のオブジェクトと対話することができる。このネットワークは、それ自体に図２のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピュータ装置を含むことができる。本発明の一態様によれば、各オブジェクト１０または１１０は、信頼できるグラフィックパイプラインのために本発明の認証技術を必要とする可能性があるアプリケーションを含むことができる。

１１０ｃなどのオブジェクトは他のコンピュータ装置１０、１１０のホストになり得ることも理解できよう。したがって、図示の物理環境はコンピュータとして接続された各装置を表すことができるが、この図は単なる例示であり、物理環境はその代わりにＰＤＡ、ＴＶ、ＭＰ３プレーヤなどの様々なデジタル装置、インタフェースなどのソフトウェアオブジェクト、ＣＯＭオブジェクトなどを含むように図示または記述することができる。

分散コンピューティング環境をサポートする様々なシステム、コンポーネント、およびネットワーク構成が存在する。例えば、コンピュータシステムを有線または無線システムによって、あるいはローカルネットワークまたは広域分散ネットワークによって相互に接続することができる。現在、多くのネットワークはインターネットに結合され、インターネットは広域分散コンピューティングのインフラストラクチャを提供し、多くの異なるネットワークを包含する。

ホームネットワーク環境では、少なくとも４つの異種のネットワーク伝送媒体が存在し、その各々が、電力線（Ｐｏｗｅｒ ｌｉｎｅ）、データ（無線および有線の両方）、音声（例えば、電話）、娯楽メディアなどの独自のプロトコルをサポートすることができる。照明スイッチや電気器具など、ほとんどの家庭用制御機器は接続のために電力線を使用することができる。データサービスは、ブロードバンド（例えば、ＤＳＬまたはケーブルモデム）として家庭内に取り込むことができ、家庭内では無線（例えば、ＨｏｍｅＲＦまたは８０２．１１ｂ）または有線（例えば、ＨｏｍｅＰＮＡ、Ｃａｔ ５、電源ラインなど）接続を使用してアクセスすることができる。音声トラフィックは有線（例えば、Ｃａｔ ３）または無線（例えば、携帯電話）で家庭内に取り込むことができ、家庭内ではＣａｔ ３配線を使用して分配される。娯楽メディアは衛星またはケーブルを介して家庭内に取り込むことができ、一般に同軸ケーブルを使用して家庭内で分配される。ＩＥＥＥ １３９４およびＤＶＩもまた、一群のメディア装置のためのデジタル相互接続として登場してきた。プロトコル標準として出現し得るこれらおよび他のネットワーク環境はすべて、相互接続してインターネット経由で外部世界に接続できるイントラネットを形成することができる。要するに、データの記憶および送信のために様々な異種のソースが存在しており、したがって、さらに進んで、コンピュータ装置は、データ処理パイプラインのすべての部分でコンテンツを保護する方法を必要とすることになる。

「インターネット」は一般に、コンピュータネットワークの分野でよく知られたＴＣＰ／ＩＰプロトコルスイートを使用するネットワークおよびゲートウェイの集まりを意味する。ＴＣＰ／ＩＰは「Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｆａｃｅ Ｐｒｏｇｒａｍ（伝送制御プロトコル／インタフェースプログラム）」の頭字語である。インターネットは、ユーザがネットワークを介して対話し情報を共用することを可能にするネットワークプロトコルを実行するコンピュータによって相互接続された地理的に分散したリモートコンピュータネットワークからなるシステムとして説明される。このような広範囲に及ぶ情報共有のために、インターネットなどのリモートネットワークはこれまで一般に、開発者が基本的には制限なしに専用の動作またはサービスを実施するためのソフトウェアアプリケーションを設計することができるオープンシステムへと発展してきた。

したがって、ネットワークインフラストラクチャは、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャなど多くのネットワークトポロジーを可能にする。「クライアント」とは、それが関係していない他のクラスまたはグループのサービスを使用する、あるクラスまたはグループのメンバーのことである。したがって、コンピュータの使用におけるクライアントとは、他のプログラムによって提供されるサービスを要求するプロセス、すなわち１組の命令またはタスクなどのことである。クライアントプロセスは、他のプログラムまたはサービスそのものについての動作詳細をまったく「知る」必要なしに、要求したサービスを使用する。クライアント／サーバアーキテクチャ、特にネットワークシステムにおいては、クライアントは一般に、例えばサーバなど他のコンピュータによって提供される共用ネットワークリソースにアクセスするコンピュータのことである。図２の例では、コンピュータ１１０ａ、１１０ｂ等はクライアント見なされ、コンピュータ１０ａ、１０ｂ等はサーバと見なされる。この場合、サーバ１０ａ、１０ｂ等がデータを維持しており、そのデータはクライアントコンピュータ１１０ａ、１１０ｂ等に複製される。

サーバは一般に、インターネットなどのリモートネットワークを介してアクセス可能なリモートコンピュータシステムのことである。クライアントプロセスを第１のコンピュータシステムでアクティブにし、サーバプロセスを第２のコンピュータシステムでアクティブにし、通信媒体を介して相互に通信させることにより、結果として分散機能が提供され、複数のクライアントがサーバの情報収集機能を利用することが可能になる。

クライアントとサーバはプロトコルレイヤによって提供される機能を使用して相互に通信する。例えば、ＨＴＴＰ（ハイパーテキスト転送プロトコル）はＷＷＷ（ワールドワイドウェブ）とともに使用することができる共通プロトコルである。一般に、サーバまたはクライアントコンピュータを相互に識別するためには、ＵＲＬ（ユニバーサルリソースロケータ）またはＩＰ（インターネットプロトコル）アドレスなどのコンピュータネットワークアドレスが使用される。ネットワークアドレスはＵＲＬアドレスとして参照することができる。例えば、通信は通信媒体を介して提供することができる。具体的には、クライアントとサーバは大容量通信のためのＴＣＰ／ＩＰ接続を介して相互に結合することができる。

したがって図２は、本発明を使用することができる例示的ネットワークまたは分散環境を示すものであり、サーバはネットワーク／バスを介してクライアントコンピュータと通信する。より詳細には、本発明に従って、いくつかのサーバ１０ａ、１０ｂ等が、例えばＬＡＮ、ＷＡＮ、イントラネット、インターネット等の通信ネットワーク／バス１４を介して、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、情報家電、またはその他の装置、例えばＶＣＲ、ＴＶ、オーブン、照明、ヒータなど、いくつかのクライアントまたはリモートコンピュータ装置１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅ等と相互接続される。したがって本発明は、信頼できるソースからの安全なコンテンツを処理し、格納し、描画することが望ましい任意のコンピュータ装置に適用できることが企図される。

通信ネットワーク／バス１４がインターネットであるネットワーク環境では、例えばサーバ１０は、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅ等がＨＴＴＰなどいくつかの既知のプロトコルのいずれかによって対話するＷｅｂサーバであってもよい。サーバ１０はまた、分散コンピューティング環境の特徴として、クライアント１１０としての機能を果たすこともできる。通信は、必要に応じて有線でも無線でもよい。クライアント装置１１０は、通信ネットワーク／バス１４を介して通信してもしなくてもよく、各クライアントに関連する個別の通信を行うこともできる。例えば、ＴＶまたはＶＣＲの場合には、それらの制御に関するネットワーク態様が存在することもあるし、存在しないこともある。各クライアントコンピュータ１１０およびサーバコンピュータ１０は、様々なアプリケーションプログラムモジュールまたはオブジェクト１３５を備えることができ、また様々な種類の記憶要素またはオブジェクトへの接続またはアクセスを備えることができる。また、それらを介してファイルを格納することができ、あるいはそれらにファイルの一部をダウンロードまたは移動させることができる。したがって本発明は、コンピュータネットワーク／バス１４にアクセスしそれと対話することができるクライアントコンピュータ１１０ａ、１１０ｂ等と、クライアントコンピュータ１１０ａ、１１０ｂ等、および他の装置１１１、ならびにデータベース２０と対話することができるサーバコンピュータ１０ａ、１０ｂ等とを備えたコンピュータネットワーク環境で使用することができる。

［アクセス管理概観］
次に図３を参照すると、よく知られているように、デジタル情報に適用されるアクセス管理では、組織１０の環境の内部等で、組織１０のリソース３１４に情報を要求する組織１０の内部の要求者１２は信用情報１６をリソース３１４に提示しなければならない。信用情報１６は、要求者１２を識別するものであり、例えば組織１０に対する要求者１２の関係を含むことができる。

よく知られているように、本発明の趣旨および範囲を逸脱することなく、組織１０は任意の適切な種類の組織とすることができる。例えば組織１０は、公共団体、民間企業、行政体、非営利の慈善団体、研究財団等であってもよい。やはりよく知られているように、組織１０内部の要求者１２は、やはり本発明の趣旨および範囲を逸脱することなく、任意の適切な要求者とすることができる。例えば、要求者１２は一般従業員、管理者、監督者、役員等のいずれであってもよい。

一般に、リソース３１４はデジタル情報またはサービスへのアクセスを求める要求を受信し、予め定められたルールに従ってそのアクセスを提供する。このようなデジタル情報はデジタルコンテンツまたはデータなどを含むことができ、デジタルサービスは印刷サービス、描画サービス、データ変換サービスなどを含むことができる。したがって、このようなリソース３１４およびデジタル情報は、本発明の趣旨および範囲を逸脱することなく、任意の適切なデジタルリソースおよびデジタル情報とすることができる。

要求者１２にアクセスを提供する際にリソース３１４が従う予め定められたルールは、本発明の趣旨および範囲を逸脱することなく、任意のルールとすることができる。本発明の環境では、このようなルールは、少なくとも暗黙的に要求者１２がリソース３１４に信用情報１６を提示することを要求すること、信用情報１６の中に記載することもできるが要求者１２が組織１０内で少なくともあるレベルの地位を有することを要求すること、やはり信用情報１６等の中に記載することもできるが要求者１２がリソース３１４にアクセスする権限を有することなどを要求することができる。例えば、このようなルールはまた、要求者１２からの要求が１日のうちの特定の時間に受信されるように要求すること、要求者１２が特定の種類の接続等によってリソース３１４にアクセスすることなどを要求することもできる。

要求者１２によって提示され、要求者１２を表す信用情報１６は、本発明の趣旨および範囲を逸脱することなく、任意の適切な信用情報とすることができる。一般に、信用情報１６は、リソース３１４によって信頼された組織１０の管理者１８によって要求者１２に発行されたデジタル証明書であるが、他の任意の形の識別証明とすることができる。信用情報１６が実際にはデジタル証明書１６であると想定すると、このようなデジタル証明書１６には、要求者１２を識別するのに適切であるような情報をその中に含めることができる。例えば、デジタル証明書１６には、要求者１２の名前、組織内での要求者１２の地位、組織１０内の要求者の権限、有効期間などを含めることができる。一般に、このようなデジタル証明書１６は、そのコンテンツに基づいて、公開／秘密鍵ペアの秘密鍵によって署名され、対応する公開鍵を含む添付された一連の証明書に従って検証することができる。

デジタル証明書１６は、証明書１６中に公開鍵を含める形で、それ自体を公開／秘密鍵ペアと関連づけることができる。したがって、リソース３１４は、その要求者１２の証明書１６の公開鍵に従って直接または間接に暗号化されたデータを要求者１２に返すことができる。したがって、要求者１２は、証明書１６の対応する秘密鍵の適切な適用によってそのデータにアクセスすることができる。

管理者１８は、本発明の趣旨および範囲を逸脱することなく、アクセスの決定を行う際にリソース３１４によって信頼される任意の適切な管理者とすることができる。当然のことながら管理者１８は、要求者１２に信用情報／証明書１６を発行する機能を有するものと想定している。おそらく、リソース３１４のルールは、任意の要求者からの任意の要求が、その要求者からの信用情報／証明書１６を含めることによって信頼できる管理者１８に結びつけられていることを必要とする。

［リソース３１４にアクセスする権限の委任］
上述のように、組織１０内部のリソース３１４は一般に、要求者１２にアクセス権を提供するかどうかを決定する際に、要求者１２によって提供される信用情報１６を調査し、信用情報１６が組織１０の信頼できる管理者１８に結びつけられていることを確認する。しかし重要なことは、要求者１２が適切な信用情報１６をしばしば欠いており、提供された信用情報１６だけに基づいてはリソース３１４へのアクセスが許可されないことがあり得るが、それでもなお、他の信頼できるエンティティによる判断に基づいてリソース３１４へのアクセスを許可すべきことが多いことである。さらに、要求者１２が組織１０にしばしば属しておらず、組織１０からの信用情報１６を有していない場合もあるが、それでもやはり、組織のリソース３１４へのアクセスを許可すべきことも多い。

より一般的には、アプリケーションが、複層的（ｍｕｌｔｉ−ｔｉｅｒｅｄ）であり、複数の組織１０に渡って分散され、複数の管理境界にまたがり、かつ／または動的な関係で複数のエンティティに関係し得る場合には、そのようなアプリケーションの動作に従うリソース３１４へのアクセスは、必然的に各管理環境を含む境界を横切ることが必要になる。したがって、第１の組織１０のリソース３１４は、第１の組織１０の信頼できる管理者１８によって信用情報を与えられていない第２の組織１０の要求者１２を認識し、アクセスを許可することが必要になる。しかし一方では、第１の組織１０のリソース３１４はやはり、少なくとも第２の組織１０の要求者１２が第１の組織１０の信頼できる管理者１８への何らかの結びつきを確立することを求める必要がある。

第１の組織１０のリソース３１４のためのルールを定期的に更新して特定の要求者の権限を変更するかまたは第２の組織１０の要求者１２の第１の組織１０の管理者１８への結びつきを明示することによって、そのリソース３１４に誰がアクセスできるのかを変更することができるが、その様な更新は厄介で、重荷になり、リスクを伴い、セキュリティリスクの原因になるものである。したがって、本発明の一実施形態では、第１の組織１０のリソース３１４のためのルールは、第２の組織１０の要求者１２が、リソース３１４にアクセスする権限を第１の組織１０の管理者１８から直接または間接に委任されていることだけを必要とする。このような委任は、デジタル証明書１６などの信用情報１６における委任ポリシーとして実施することができる。重要なことは、このような信用情報／証明書１６によって委任を要求することにより、証明書１６にはリソース３１４に関して要求者１２が有する権限を限定または制限する制約を備えることができることである。

次に、図４を参照すると、２つの組織４１０ａ、４１０ｂがそれぞれ管理者１８ａ、１８ｂを有し、リソース１４ａが組織４１０ａおよび信頼できる管理者１８ａとのみ関連しており、要求者１２ｂが組織４１０ｂに関連しているものと想定すると、本発明は、図５に示されているように次のように達成することができる。予め、組織４１０ａの管理者１８ａは、組織４１０ｂの管理者１８ｂが組織４１０ａの管理者１８ａに代わって組織４１０ａの１つまたは複数のリソース１４ａに関する信用情報１６ｂを発行することができるという趣旨のポリシーを記載した信用情報１６ａを組織４１０ｂの管理者１８ｂに送信する（ステップ５０１）。次に、この信用情報１６ａは、組織４１０ａの管理者１８ａの組織４１０ｂの管理者１８ｂへの発行権限の委任になる。信用情報１６ａが、組織４１０ｂの管理者１８ｂが組織４１０ｂの特定の要求者１２ｂに信用情報１６ｂを発行できることを記載できること、またはそのような要求者１２ｂの特定の組を指定することができること、または組織４１０ｂのすべての要求者１２ｂを指定することができることに留意されたい。

ともかく、組織４１０ｂの管理者１８ｂは、組織４１０ａの管理者１８ａからの委任された信用情報１６ａを有しており、それに基づいて、委任された信用情報１６ｂを実際に組織４１０ｂの要求者１２ｂに発行する。重要なことは、本発明の一実施形態において、信用情報１６ｂは要求者１２ｂを管理者１６ｂに結びつけており、信用情報１６ａは管理者１８ｂを管理者１８ａに結びつけていることである。例えば、信用情報１６ａ、１６ｂがデジタル証明書１６ａ、１６ｂであり、図４に示したように、各管理者１８ａ、１８ｂが公開／秘密鍵（ＰＵ−Ａ、ＰＵ−Ｂ、ＰＲ−Ａ、ＰＲ−Ｂ）を有する場合は、信用情報１６ａは管理者１８ｂの公開鍵（ＰＵ−Ｂ）を含み、かつ管理者１８ａの秘密鍵（ＰＲ−Ａ）によって署名され、信用情報１６ｂは管理者１８ｂの秘密鍵（ＰＲ−Ｂ）によって署名される。

したがって、委任された信用情報／証明書１６ｂを管理者１８ｂが要求者１２ｂに発行するとき、管理者１８ｂは、委任された証明書１６ａを証明書の連鎖の方法で証明書１６ｂに含める（ステップ５０３）。その後、ある時点で要求者１２ｂは実際にリソース１４ａにアクセスを要求し、その際、要求に一連の証明書１６ａ、１６ｂを含める（ステップ５０５）。要求を受信したとき、リソース１４ａは、その要求を受け入れるかどうかの判断の一部として、証明書の連鎖１６ａ、１６ｂを検証して、実際にリソース１４ａにアクセスする権限を信頼できる管理者１８ａが管理者１８ｂを経由して要求者１２ｂに委任したことを確認する。具体的には、想定された（ＰＵ−Ａ）に関する知識に基づいて、リソース１４ａは（ＰＵ−Ａ）を委任された証明書１６ａの（Ｓ（ＰＲ−Ａ））に適用してその証明書を検証し（ステップ５０７）、その検証に成功したと想定して、次いで委任された証明書１６ａから（ＰＵ−Ｂ）を取得し（ステップ５０９）、その（ＰＵ−Ｂ）を委任された証明書１６ｂの（Ｓ（ＰＲ−Ｂ））に適用してその証明書を検証する（ステップ５１１）。ここで、その検証に成功したと想定して、要求者１２ｂからの要求が信頼できる管理者１８ａから管理者１８ｂを経由して委任された権限に基づくものであるという知識がリソース１４ａによって確認され、要求の処理を進めることができる（ステップ５１３）。

ここまで述べてきたように、委任の連鎖は信頼できる管理者１８ａから管理者１８ｂに、さらに管理者１８ｂから要求者１２ｂへ与えられる。しかし重要なことは、すべて本発明の趣旨および範囲を逸脱することなく、リソース１４ａによって受け入れられた信頼されるソースから複数のリンクに委任を与えることができ、さらに複数の分岐によって複数の要求者１２ｂに委任を与えることができることである。さらに、本発明の一実施形態では、信用情報１６を使用してリンクを確立し、その各信用情報１６に、リソース１４ａが要求者１２ｂにアクセスを提供する前に要求者１２ｂが満たさなければならないポリシーを含めることもできる。

したがって、信用情報１６を適切に発行するために以下のような分配ポリシーを作成することができる。

− 組織４１０ａ内部のリソース１４ａは、誰が信用情報１６を発行できるのかを判断するために組織４１０ａの管理者１８ａを信頼する。

− 管理者１８ａは信用情報１６によって、組織４１０ｂの管理者１８ｂがその組織４１０ｂの要求者１２ｂに信用情報１６を発行することを許可する。

− 管理者１８ａは信用情報１６によって、組織１０ｃの管理者１８ｃが購入者または評論家としての役割を果たすその組織１０ｃの要求者１２ｃ（図示せず）に信用情報１６を発行することを許可し、さらに管理者１８ｃがその機能をその組織１０ｃ内の副管理者１８に委任できることも許可する。

− 管理者１８ｃは信用情報１６によって、その購入副管理者１８ｃ１が組織１０ｃの購入要求者１２ｃ１に信用情報１６を発行することを許可する。

したがって、リソース１４ａが、管理者１８ａ、１８ｃ、および１８ｃ１からの一連の信用情報１６が添付されたアクセス要求を要求者１２ｃ１から受信したとき、リソース１４ａはそのすべての信用情報１６の中に記載されたポリシーを使用してアクセスを許可するかどうかを決定することができる。より一般的には、信用情報１６によって示される各リンクは、リソース１４ａへのアクセスを獲得することができる要求者１２を識別する権限の制約された委任を表し、各リンクはまた、そのアクセスが提供される前に要求者１２が従わなければならないポリシーを宣言する信頼できるステートメントも提供する。重要なことは、各信用情報１６にこのようなポリシーを格納することによって、リソース１４ａはポリシーに関する特定の中央レポジトリ（ｃｅｎｔｒａｌ ｒｅｐｏｓｉｔｏｒｙ）を参照する必要がなく、また要求者１２、あるいは１８ａ以外のどの管理者１８についての事前知識も持つ必要がなくなることである。その代わりとして、リソース１４ａは一連の信用情報１６のポリシーを受け入れる。なぜならば、連鎖は信頼できるポイントである管理者１８ａで始まり、リソース１４ａへのアクセスを要求する要求者１２で終るからであり、また連鎖中の各信用情報１６が、各信用情報の検証された署名によって要求者１２を信頼できる管理者１８ａに結びつけるからである。

信用情報１６の中に記載されるポリシーは、本発明の趣旨および範囲を逸脱することなく、任意のポリシーであってもよいことを理解されたい。例えばポリシーは、信用情報１６の所有者に組織４１０ａのすべてのリソースに１４ａにアクセスするフルの権限を提供することができる。あるいは、ポリシーは、信用情報１６に基づいて要求することができる特定の要求者１２に関する制限、信用情報１６に基づいてアクセスされ得る特定のリソース１４ａ、時間制限、地理的制限、有効期限、アクセス権の制限、通信プロトコルに関する制限などを設定することもできる。信用情報１６内のポリシーはまた、信用情報１６が取り消されていないことを確認するために、リソース１４ａに取消しリストをチェックするよう求めることもできる。ポリシーはさらに、リンクされる信用情報１６の最大数、権限の使用に先立つ条件、または権限の使用の後で実施しなければならない動作などを指定することができる。あるいは、ポリシーはさらに、追加のポリシーが置かれている１つまたは複数の外部位置を参照することもできる。

信用情報内１６のポリシーを、本発明の趣旨および範囲を逸脱することなしに、任意の適切な方法で表現することができる。例えば、ポリシーは次の形のポリシーステートメントで表現することができる。

プリンシパル Ｐ
表明する権限
表明のマッチング Ａ^*
委任先プリンシパルの種類 Ｐ^*
従う条件 Ｃ^*
発行元 Ｉ
有効期限 Ｄ
上記ポリシーステートメントにおいて、
− Ｐは、委任が許可されている特定のプリンシパルの参照名である。

− 表明する権限は明示的でも暗黙的でもよいが、Ｐが委任許可の制約を満たす表明を作成できることを示すものである。この表明はＰによって署名された信用情報１６の形で符合化される。

− Ａ^*は、全ての有効な委任表明がマッチしなければならない１つまたは複数のパターンである。例えば、「ｅｍａｉｌＮａｍｅ＝＊＠ｘｚｙ．ｃｏｍ ｐｏｓｓｅｓｓ ｐｒｏｐｅｒｔｙ ｒｏｌｅ＝ｐｕｒｃｈａｓｅｒ」の形のパターンは、ｘｙｚ．ｃｏｍドメインの電子メールアドレスを有するエンティティが購入者の役割を持つことをＰが表明できることを示す。また、「ｅｍａｉｌＮａｍｅ＝＊＠ｘｚｙ．ｃｏｍ ｒｅａｄ ｆｉｌｅ＝＼＼ｍｙｓｙｓ＼ｆｏｏ．ｔｘｔ」の形のパターンにより、ｘｙｚ．ｃｏｍドメインの電子メールアドレスを有するエンティティが指定されたファイルを読むことができることを、Ｐは表明することができる。

− Ｐ^*は、Ｐが委任することができる値エンティティを識別する１つまたは複数のパターンである。例えば、Ｘ．５０９証明書を保有するＸＹＺ社の従業員だけが有効な委任対象となる。あるいは、ＸＹＺ社ドメインのメンバーだけが有効な対象となる。

− Ｃ^*は、Ｐによる任意の委任の有効性に影響を与えるゼロまたはいくつかの条件である。これらの条件には、委任を継続することができる最大継続時間、委任許可取消しのために調べるべき要件などの一時的な制約が含まれる。

− Ｉは、発行元を提示し完全性を保証するデジタル署名付きのポリシーを発行するエンティティの参照名を示す。

− Ｄは、委任許可が有効である期間を示す。

上述のポリシーステートメントを、本発明の趣旨および範囲を逸脱することなく、任意の適切な方法で符号化することができる。例えば、ポリシーステートメントを、Ｘ．５０９証明書またはケルベロスチケット（Ｋｅｒｂｅｒｏｓ ｔｉｃｋｅｔ）への統合のためにＡＳＮ．１構造で符号化することができる。しかし、全ての符号化と構造がこのようなポリシーステートメントを完全にサポートできるとは限らないことを認識し、本発明の一実施形態では、ポリシーステートメントおよびそれに含まれる信用情報１６は、国際標準化機構（ＩＳＯ）によって承認されたＭＰＥＧ ＲＥＬ（ＭＰＥＧ Ｒｉｇｈｔｓ Ｅｘｐｒｅｓｓｉｏｎ Ｌａｎｇｕａｇｅ）などの標準を定義するＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）に従って構築される。なお、ＭＰＥＧ ＲＥＬには必要な構文上の形式がもとから組み込まれている。

ここまで本発明を、２人の管理者１８からの１対のリンクされた信用情報１６を有する要求者１２に関して説明してきたが、信用情報１６の連鎖を任意の数の管理者１８を表す任意の数のリンク、および任意の数の他の要求者１２にまで拡張できることに留意されたい。おそらく、信用情報１６の特定の連鎖を有し、それに基づいてリソース３１４にアクセスしたいと望む要求者１２は実際にそのリソース３１４にアクセスすることができるが、それは信用情報１６の連鎖がそのリソースによって認識された信頼できるルートにまでさかのぼることができる場合に限られ、かつ各信用情報１６内のポリシーが実際にそのアクセスを許可する場合に限られることを理解されたい。

したがって、重要なことは、信用情報１６に記載できるポリシーの１つが、リンクされた信用情報１６の発行によって信用情報１６の権限を特定の要求者１２に委任することができるかどうかということである。例えば、特定のリソース３１４にアクセスするための第１の信用情報１６を有する第１の要求者１２は、その第１の信用情報１６内の特定のポリシーによって、特定のリソース３１４にアクセスする機能を第２の信用情報１６を第１の要求者１２から第２の要求者１２に発行することによって第２の要求者１２に委任することができる場合がある。さらに、第１の要求者１２は、第２の信用情報１６によって第２の要求者１２に委任することができるが、第１の信用情報１６内の委任ポリシーによってその委任が権限の特定のサブセットに制限されることもある。

したがって、上述の本発明に関して、第１の信用情報１６を有する第１の要求者１２は、所与のリソース３１４にアクセスする権限を、第２の要求者１２に第２の信用情報１６を発行することによって委任することができるが、それは、第１の要求者１２が、第１の信用情報１６内に記載されたポリシーによってリソース３１４へのアクセスが許可されている場合に限られることを理解されたい。おそらく、第２の要求者１２は、第２の要求者１２が所有する他のどの信用情報１６に基づいても、リソース３１４にアクセスすることはできないはずである。

一般に、このような委任において、リソース３１４に認識されている第１の管理者１８は、許可されているリソースへのアクセスを識別し、場合によってはそれを指示する第１の信用情報１６を第１の要求者１２に発行する。重要なことは、第１の要求者１２が仲介者として動作することができ、したがってリソース３１４にアクセスするために第１の要求者１２に代わって動作する権限を第２の要求者１２に許可するという旨のポリシーも、第１の管理者１８が第１の信用情報１６の中に記載することである。あるいは、第１の信用情報１６を参照する補助の信用情報１６の中にポリシーを記載することもできる。次いで、第１の要求者１２は第２の信用情報１６を第２の要求者１２に発行する。この場合、第２の信用情報１６には、リソース３１４にアクセスする際に第２の要求者１２が持つことになる権限に関するポリシーが記載される。前と同様に、第２の信用情報１６は、第１の信用情報１６を含むかまたはそれを参照する。その後、第２の要求者１２は、リソース３１４にアクセスを要求し、その際第１および第２の信用情報１６をその要求に含めることよって、リソース３１４がアクセスを判断できるようにする。

具体的には、前と同様に、リソース３１４は要求を受信し、発行された第２の信用情報１６を検証してその発行が第１の信用情報１６の所有者によるものであることを確認し、また発行された第１の信用情報１６を検証してその発行が第１の管理者１８によるものであることも確認する。次に、リソース３１４は、第２の信用情報１６中で委任された権限が、第１の信用情報１６中のポリシーに従うものであることをチェックする。このような検証およびポリシーチェックに成功したと想定して、リソース３１４は、第２の要求者１２からのその要求が第１の要求者１２から適切に委任された権限に基づくものであることを確認してアクセス要求の処理を進める。したがって、リソース３１４へのアクセスを認める信用情報１６が第１の管理者１８から第２の要求者１２に直接発行されていない場合でも、リソース３１４はやはり、第２の要求者１２を認識しそのアクセスを許可することができる。

［結論］
本開示は、特定の動作を実施するリソース３１４に関して述べているが、実際にはリソースマネージャがリソース３１４に代わってそのような動作を実施する場合もあることを理解されたい。よく知られているように、実際にはリソースマネージャがリソース３１４を管理し、リソース３１４に対するアクセス制御の決定を行うことも良くある。いずれにしても、特に区別する必要がない場合は、動作を実施するリソース３１４は、リソース３１４に代わって動作を実施するリソースマネージャの均等物と見なすことができ、その逆も同様である。

本発明に関して実施されるプロセスを実現するのに必要なプログラミングは、比較的簡単なものであり、関連するプログラマにとっては明らかなものである。したがって、このようなプログラミングに関しては本明細書には添付しない。したがって、本発明を実現するために、本発明の趣旨および範囲を逸脱することなく任意のプログラミングを使用することができる。

本発明においては、あるリソース３１４が、アクセスルールなどに基づいて、そのリソース３１４にとって未知の要求者１２にアクセスを提供することができる方法および機構が提供される。その代わりとして、リソース３１４は、要求者１２にアクセスを提供すべきかどうかを決定するために、管理者１８など定義された信頼できるソースに注目することだけが必要になる。定義された信頼できるソースは、要求者１２が、定義された信頼できるソースが属する組織１０の内部にいるか外部にいるかに関わらず、その要求者１２にアクセスを提供すべきかどうかを識別することができる。これは、発行された信用情報１６によってその要求者１２に権限を委任することによって行われる。

本発明の概念の趣旨および範囲を逸脱することなく、上述の実施形態に変更を加えることができることを理解されたい。したがって本発明が、開示した特定の実施形態に限定されるものではなく、添付の特許請求の範囲によって定義された本発明の趣旨および範囲に含まれる修正形態を含むことを意図したものであることも理解されたい。

本発明を実装することができるコンピュータ環境を限定の意味ではなく例示として示す構成図である。 本発明を実装することができる様々なコンピュータ装置を含む例示的なネットワーク環境を示す構成図である。 組織がリソースを有し、管理者がリソースによって信頼され、かつ要求者が管理者からの信用情報に基づいてリソースへのアクセスを要求するアーキテクチャを示す構成図である。 すべて本発明の一実施形態に従って、第１の組織がリソースとそのリソースによって信頼される第１の管理者を有し、第２の組織が要求者と第２の管理者を有し、第２の組織の要求者が、第１の組織の管理者から第２の組織の管理者に委任された信用情報と第２の組織の管理者から要求者に委任された信用情報とに基づいて第１の組織のリソースにアクセスを要求するアーキテクチャを示す構成図である。 本発明の一実施形態に従って、図４に示されたエンティティによって実施される主要なステップを示す流れ図である。

符号の説明

１０ａ サーバオブジェクト
１０ｂ サーバオブジェクト
１０ｃ 組織
１２ 要求者
１２ｂ 要求者
１２ｃ 要求者
１２ｃ１ 購入要求者
１４ 通信ネットワーク／バス
１４ａ リソース
１６ 信用情報
１６ａ 信用情報
１６ｂ 信用情報
１８ 管理者
１８ａ 管理者
１８ｂ 管理者
１８ｃ 管理者
１８ｃ１ 購入副管理者
２０ データベース
１００ コンピュータ環境
１１０ａ コンピュータ装置
１１０ｂ コンピュータ装置
１１０ｃ コンピュータ装置
１１０ｄ コンピュータ装置
１１０ｅ コンピュータ装置
１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３１ （ＲＯＭ）
１３２ （ＲＡＭ）
１３３ ＢＩＯＳ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定不揮発メモリインタフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ リムーバブル不揮発メモリインタフェース
１６０ ユーザ入力インタフェース
１６１ マウス
１６２ キーボード１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８２ グラフィックインタフェース
１８４ ＧＰＵ
１８５ リモートアプリケーションプログラム
１８６ ビデオメモリ
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力ペリフェラルインタフェース
１９６ プリンタ
１９７ スピーカ
３１４ リソース
４１０ａ 組織
４１０ｂ 組織
５０１ 管理者１８Ａは委任信用情報１６Ａを管理者１８Ｂに送る。委任信用情報１６Ａは、管理者１８Ｂが委任信用情報１６Ｂを管理者１８Ａの代わりに発行することができるというポリシーを含む
５０３ 管理者１８Ｂは、委任信用情報１６Ａを含む委任信用情報１６Ｂを要求者１２Ｂに発行する
５０５ 要求者１２Ｂは、信用情報１６Ａ，１６Ｂを含むアクセスをリソース１４Ａに要求する
５０７ リソース１４Ａは、委任信用情報１６Ａの（Ｓ（ＰＲ−Ａ））に（ＰＵ−Ａ）を適用して検証する
５０９ 委任信用情報１６Ａから（ＰＵ−Ｂ）を取得する
５１１ 委任信用情報１６Ｂの（Ｓ（ＰＲ−Ｂ））に（ＰＵ−Ｂ）を適用して検証する
５１３ 全ての署名が有効な場合は、要求の処理を進める

Claims (21)

1. 第１の組織のリソースが前記リソースへのアクセスを第２の組織の要求者に提供する方法であって、前記第１の組織は前記リソースによって信頼された第１の管理者を有し、前記第２の組織は第２の管理者を有し、前記第１および第２の各管理者は各エンティティに信用情報を発行し、管理者によってエンティティに発行された各信用情報は前記エンティティを前記発行元管理者に結びつけるとともに前記エンティティと前記発行元管理者の間の関係を明示し、さらに前記方法は、
   前記第１の管理者が前記第２の管理者に第１の信用情報を発行し、前記発行された第１の信用情報は前記第２の管理者が前記第１の管理者の代わりに第２の信用情報を前記要求者に発行することができるというポリシーを記載し、前記第２の管理者は前記第１の管理者の代わりに前記第２の信用情報を前記要求者に実際に発行し、前記発行された第２の信用情報は前記発行された第１の信用情報を含み、前記第２の組織の前記要求者は後ほど前記第１の組織の前記リソースにアクセスを要求し、その要求の際に前記発行された第１の信用情報および前記発行された第２の信用情報を前記要求に含めるステップと、
   前記リソースが、前記発行された第１の信用情報および前記発行された第２の信用情報を含む前記要求を前記要求者から受信するステップと、
   前記リソースが、前記発行された第１の信用情報を検証して前記発行された第１の信用情報が前記信頼される第１の管理者を前記第２の管理者に結びつけていることを確認し、また前記発行された第１の信用情報の前記ポリシーにより前記第２の管理者が前記第２の信用情報を前記要求者に発行することが許可されていることを確認するステップと、
   前記リソースが、前記発行された第２の信用情報を検証して前記発行された第２の信用情報が前記第２の管理者を前記要求者に結びつけていることを確認するステップと、
   前記検証に成功したと想定して、前記リソースが、前記要求者からの前記要求が前記信頼される第１の管理者から前記第２の管理者を経由して前記要求者に委任された権限に基づくものであることを認識することにより、前記リソースへの前記要求の処理を進めるステップと
   を備え、
   それによって、前記第１の組織の前記信頼される第１の管理者により前記要求者に信用情報が全く発行されていない場合でも、前記第１の組織の前記リソースは前記第２の組織の前記要求者を認識しアクセスを許可することができることを特徴とする方法。
2. 前記第１の管理者は、前記第２の管理者が前記要求者を含むエンティティの特定の組に前記第２の信用情報を発行することができるというポリシーを記載した前記第１の信用情報を、前記第２の管理者に発行することを特徴とする請求項１に記載の方法。
3. 前記第１の管理者は、前記リソースに関して前記要求者が有する権限を制限するというポリシーをさらに記載した前記第１の信用情報を、前記第２の管理者に発行することを特徴とする請求項１に記載の方法。
4. 前記第１の管理者は公開／秘密鍵ペア（ＰＵ−Ａ，ＰＲ−Ａ）を有し、前記第２の管理者は公開／秘密鍵ペア（ＰＵ−Ｂ，ＰＲ−Ｂ）を有し、前記第１の管理者は、前記第２の管理者の前記公開鍵（ＰＵ−Ｂ）と、前記第１の管理者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ａ））とを含む前記第１の信用情報を前記第２の管理者に発行し、前記第２の管理者は、前記第２の管理者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ｂ））を含む前記第２の信用情報を前記要求者に発行することを特徴とする請求項１に記載の方法。
5. 前記リソースは（ＰＵ−Ａ）に関する知識を有しており、前記方法は、
   前記リソースが前記発行された第１の信用情報の（Ｓ（ＰＲ−Ａ））に（ＰＵ−Ａ）を適用して前記第１の信用情報を検証するステップと、
   前記検証に成功したと想定して、次に前記リソースが前記検証された第１の信用情報から（ＰＵ−Ｂ）を取得し、前記発行された第２の信用情報の（Ｓ（ＰＲ−Ｂ））に前記（ＰＵ−Ｂ）を適用して前記第２の信用情報を検証するステップと
   を備えることを特徴とする請求項４に記載の方法。
6. 前記第１の管理者は、前記要求者が前記リソースにアクセスすることを許可するというポリシーをさらに記載した第１の信用情報を前記第２の管理者に発行し、前記第２の管理者は、前記第１の管理者に代わって前記第２の信用情報を前記要求者に発行するとともに前記要求者が前記リソースにアクセスすることを許可するというポリシーを含めるステップと、
   前記リソースはさらに、前記発行された第１の信用情報を検証して、前記発行された第１の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと、
   前記リソースはさらに、前記発行された第２の信用情報を検証して、前記発行された第２の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと
   を備えることを特徴とする請求項１に記載の方法。
7. 各ポリシーを含むように各信用情報を発行するステップであって、前記各ポリシーは以下のように指定され、
   プリンシパル Ｐ
   表明する権限
   表明のマッチング Ａ^*
   委任先プリンシパルの種類 Ｐ^*
   従う条件 Ｃ^*
   発行元 Ｉ
   有効期間 Ｄ
   上記ポリシーにおいて、Ｐは委任が許可されている特定のプリンシパルを表し、Ａ^*は全ての有効な委任表明がマッチすべき１つまたは複数のパターンであり、Ｐ^*はＰが委任することができる値エンティティを識別する１つまたは複数のパターンであり、Ｃ^*はＰによる任意の委任に関するゼロまたはいくつかの条件であり、Ｉは前記ポリシーを発行する前記エンティティであり、Ｄは前記委任許可が有効である期間を示すステップを備えることを特徴とする請求項１に記載の方法。
8. 第１の組織のリソースが前記リソースへのアクセスを第３の組織を経由して第２の組織の要求者に提供する方法であって、前記第１の組織は前記リソースによって信頼された第１の管理者を有し、前記第２の組織は第２の管理者を有し、前記第３の組織は第３の管理者を有し、各管理者は各エンティティに信用情報を発行し、管理者によってエンティティに発行された各信用情報は前記エンティティを前記発行元管理者に結びつけるとともに前記エンティティと前記発行元管理者の間の関係を明示し、さらに前記方法は、
   前記第１の管理者が前記第３の管理者に第１の信用情報を発行し、前記発行された第１の信用情報は、前記第３の管理者が前記第１の管理者の代わりに第２の信用情報を前記第２の管理者に発行することができかつ前記第２の管理者が前記第１の管理者の代わりに第３の信用情報を前記要求者に発行することができるというポリシーを記載し、前記第３の管理者は前記第１の管理者の代わりに前記第２の信用情報を実際に前記第２の管理者に発行しかつ前記第２の管理者は前記第１の管理者の代わりに第３の信用情報を前記要求者に実際に発行し、前記発行された第２の信用情報は前記発行された第１の信用情報を含み、前記発行された第３の信用情報は前記発行された第１の信用情報および前記発行された第２の信用情報を含み、前記第２の組織の前記要求者は後ほど前記第１の組織の前記リソースにアクセスを要求し、その要求の際に前記発行された第１の信用情報および前記発行された第２の信用情報および前記発行された第３の信用情報を前記要求に含めるステップと、
   前記リソースが、前記発行された第１の信用情報および前記発行された第２の信用情報および前記発行された第３の信用情報を含む前記要求を前記要求者から受信するステップと、
   前記リソースが、前記発行された第１の信用情報を検証して前記発行された第１の信用情報が前記信頼された第１の管理者を前記第３の管理者に結びつけていることを確認し、また前記発行された第１の信用情報の前記ポリシーにより前記第３の管理者が前記第２の信用情報を前記第２の管理者に発行することが許可されていることおよび前記発行された第１の信用情報の前記ポリシーにより前記第２の管理者が前記第３の信用情報を前記要求者に発行することも許可されていることを確認するステップと、
   前記リソースが、前記発行された第２の信用情報を検証して前記発行された第２の信用情報が前記第３の管理者を前記第２の管理者に結びつけていることを確認し、また前記発行された第２の信用情報の前記ポリシーにより前記第２の管理者が前記第３の信用情報を前記要求者に発行することが許可されていることを確認するステップと、
   前記リソースが、前記発行された第３の信用情報を検証して前記発行された第３の信用情報が前記第２の管理者を前記要求者に結びつけていることを確認するステップと、
   前記検証に成功したと想定して、前記リソースが、前記要求者からの前記要求が前記信頼される第１の管理者から前記第３の管理者および前記第２の管理者を経由して前記要求者に委任された権限に基づくものであることを認識することにより、前記リソースへの前記要求の処理を進めるステップと
   を備え、
   それによって、前記第１の組織の前記信頼される第１の管理者により前記要求者に信用情報が全く発行されていない場合でも、前記第１の組織の前記リソースは前記第２の組織の前記要求者を認識しアクセスを許可することができることを特徴とする方法。
9. 前記第１の管理者は、前記第２の管理者が前記要求者を含む特定の組のエンティティに前記第３の信用情報を発行することができるというポリシーを記載する前記第１の信用情報を、前記第３の管理者に発行することを特徴とする請求項８に記載の方法。
10. 前記第１の管理者は、前記リソースに関して前記要求者が有している権限を制限するというポリシーをさらに記載する前記第１の信用情報を前記第３の管理者に発行することを特徴とする請求項８に記載の方法。
11. 前記第１の管理者は公開／秘密鍵ペア（ＰＵ−Ａ，ＰＲ−Ａ）を有し、前記第２の管理者は公開／秘密鍵ペア（ＰＵ−Ｂ，ＰＲ−Ｂ）を有し、前記第３の管理者は公開／秘密鍵ペア（ＰＵ−Ｃ，ＰＲ−Ｃ）を有し、前記第１の管理者は、前記第３の管理者の前記公開鍵（ＰＵ−Ｃ）と、前記第１の管理者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ａ））とを含む前記第１の信用情報を前記第３の管理者に発行し、前記第３の管理者は、前記第２の管理者の前記公開鍵（ＰＵ−Ｂ）と、前記第３管理者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ｃ））とを含む前記第２の信用情報を前記第２の管理者に発行し、前記第２の管理者は、前記第２の管理者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ｂ））を含む前記第３の信用情報を前記要求者に発行することを特徴とする請求項８に記載の方法。
12. 前記リソースは（ＰＵ−Ａ）に関する知識を有しており、前記方法は、
    前記リソースが前記発行された第１の信用情報の（Ｓ（ＰＲ−Ａ））に（ＰＵ−Ａ）を適用して前記第１の信用情報を検証するステップと、
    前記検証に成功したと想定して、次に前記リソースが前記検証された第１の信用情報から（ＰＵ−Ｃ）を取得し、前記発行された第２の信用情報の（Ｓ（ＰＲ−Ｃ））に前記（ＰＵ−Ｃ）を適用して前記第２の信用情報を検証するステップと、
    前記検証に成功したと想定して、次に前記リソースが前記検証された第２の信用情報から（ＰＵ−Ｂ）を取得し、前記発行された第３の信用情報の（Ｓ（ＰＲ−Ｂ））に前記（ＰＵ−Ｂ）を適用して前記第３の信用情報を検証するステップと
    を備えることを特徴とする請求項１１に記載の方法。
13. 前記第１の管理者は、前記要求者が前記リソースにアクセスすることを許可するというポリシーをさらに記載した第１の信用情報を前記第３の管理者に発行し、前記第３の管理者は、前記第１の管理者に代わって前記第２の信用情報を前記第２の管理者に発行するとともに前記要求者が前記リソースにアクセスすることを許可するというポリシーを含め、前記第２の管理者は、前記第１の管理者に代わって前記第３の信用情報を前記要求者に発行するとともに前記要求者が前記リソースにアクセスすることを許可するというポリシーを含めるステップと、
    前記リソースはさらに、前記発行された第１の信用情報を検証して、前記発行された第１の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと、
    前記リソースはさらに、前記発行された第２の信用情報を検証して、前記発行された第２の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと、
    前記リソースはさらに、前記発行された第３の信用情報を検証して、前記発行された第３の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと
    を備えることを特徴とする請求項８に記載の方法。
14. 各ポリシーを含むように各信用情報を発行するステップであって、前記各ポリシーは以下のように指定され、
    プリンシパル Ｐ
    表明する権限
    表明のマッチング Ａ^*
    委任先プリンシパルの種類 Ｐ^*
    従う条件 Ｃ^*
    発行元 Ｉ
    有効期間 Ｄ
    上記ポリシーにおいて、Ｐは委任が許可されている特定のプリンシパルを表し、Ａ^*は全ての有効な委任表明がマッチすべき１つまたは複数のパターンであり、Ｐ^*はＰが委任することができる値エンティティを識別する１つまたは複数のパターンであり、Ｃ^*はＰによる任意の委任に関するゼロまたはいくつかの条件であり、Ｉは前記ポリシーを発行する前記エンティティであり、Ｄは前記委任許可が有効である期間を示すステップを含むことを特徴とする請求項８に記載の方法。
15. 組織のリソースがそのリソースへのアクセスを、仲介者を経由して要求者に提供する方法であって、前記組織は前記リソースによって信頼される管理者を有しており、さらに前記方法は、
    前記管理者が前記仲介者に第１の信用情報を発行し、前記発行された第１の信用情報は前記仲介者が前記管理者の代わりに第２の信用情報を前記要求者に発行することができるというポリシーを記載し、前記仲介者は前記管理者の代わりに前記第２の信用情報を前記要求者に実際に発行し、前記発行された第２の信用情報は前記発行された第１の信用情報を含み、前記要求者は後ほど前記組織の前記リソースにアクセスを要求し、また要求の際に前記要求に前記発行された第１の信用情報および前記発行された第２の信用情報を含めるステップと、
    前記リソースが、前記発行された第１の信用情報および前記発行された第２の信用情報を含む前記要求を前記要求者から受信するステップと、
    前記リソースが、前記発行された第１の信用情報を検証して前記発行された第１の信用情報が前記信頼される管理者を前記仲介者に結びつけていることを確認し、また前記発行された第１の信用情報の前記ポリシーにより前記仲介者が前記第２の信用情報を前記要求者に発行することが許可されていることを確認するステップと、
    前記リソースが、前記発行された第２の信用情報を検証して前記発行された第２の信用情報が前記仲介者を前記要求者に結びつけていることを確認するステップと、
    前記検証に成功したと想定して、前記リソースが、前記要求者からの前記要求が前記信頼される管理者から前記仲介者を経由して前記要求者に委任された権限に基づくものであることを認識することにより、前記リソースへの前記要求の処理を進めるステップと
    を含み、
    それによって、前記組織の前記信頼される管理者によって前記要求者に信用情報が全く発行されていない場合でも、前記組織の前記リソースは、前記要求者を認識しアクセスを許可することができることを特徴とする方法。
16. 前記管理者は、前記仲介者が前記要求者を含む特定の組のエンティティに前記第２の信用情報を発行することができるというポリシーを記載する前記第１の信用情報を、前記仲介者に発行することを特徴とする請求項１５に記載の方法。
17. 前記管理者は、前記リソースに関して前記要求者が有している権限を制限するというポリシーをさらに記載する前記第１の信用情報を、前記仲介者に発行することを特徴とする請求項１５に記載の方法。
18. 前記管理者は公開／秘密鍵ペア（ＰＵ−Ａ，ＰＲ−Ａ）を有し、前記仲介者は公開／秘密鍵ペア（ＰＵ−Ｂ，ＰＲ−Ｂ）を有し、前記管理者は、前記仲介者の前記公開鍵（ＰＵ−Ｂ）と、前記管理者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ａ））とを含む前記第１の信用情報を前記仲介者に発行し、前記仲介者は、前記仲介者の前記秘密鍵に基づくデジタル署名（Ｓ（ＰＲ−Ｂ））を含む前記第２の信用情報を前記要求者に発行することを特徴とする請求項１５に記載の方法。
19. 前記リソースは（ＰＵ−Ａ）に関する知識を有しており、前記方法は、
    前記リソースが前記発行された第１の信用情報の（Ｓ（ＰＲ−Ａ））に（ＰＵ−Ａ）を適用して前記第１の信用情報を検証するステップと、
    前記検証に成功したと想定して、次に前記リソースが前記検証された第１の信用情報から（ＰＵ−Ｂ）を取得し、前記発行された第２の信用情報の（Ｓ（ＰＲ−Ｂ））に前記（ＰＵ−Ｂ）を適用して前記第２の信用情報を検証するステップと
    を備えることを特徴とする請求項１８に記載の方法。
20. 前記管理者は、前記要求者が前記リソースにアクセスすることを許可するというポリシーをさらに記載した第１の信用情報を前記仲介者に発行し、前記仲介者は、前記管理者に代わって前記第２の信用情報を前記要求者に発行するとともに前記要求者が前記リソースにアクセスすることを許可するというポリシーを含めるステップと、
    前記リソースはさらに、前記発行された第１の信用情報を検証して、前記発行された第１の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと、
    前記リソースはさらに、前記発行された第２の信用情報を検証して、前記発行された第２の信用情報により前記要求者が前記リソースにアクセスすることが許可されていることを確認するステップと
    を備えることを特徴とする請求項１５に記載の方法。
21. 各ポリシーを含むように各信用情報を発行するステップであって、前記各ポリシーは以下のように指定され、
    プリンシパル Ｐ
    表明する権限
    表明のマッチング Ａ^*
    委任先プリンシパルの種類 Ｐ^*
    従う条件 Ｃ^*
    発行元 Ｉ
    有効期間 Ｄ
    上記ポリシーにおいて、Ｐは委任が許可されている特定のプリンシパルを表し、Ａ^*は全ての有効な委任表明がマッチすべき１つまたは複数のパターンであり、Ｐ^*はＰが委任することができる値エンティティを識別する１つまたは複数のパターンであり、Ｃ^*はＰによる任意の委任に関するゼロまたはいくつかの条件であり、Ｉは前記ポリシーを発行する前記エンティティであり、Ｄは前記委任許可が有効である期間を示すステップを備えることを特徴とする請求項１５に記載の方法。
    

Images