(57)【特許請求の範囲】
【請求項１】
委譲元主体から、委譲先主体に、リソースへアクセスする権利を委譲された、委譲先主体による前記リソースへのアクセスの許可を判定する方法であって、
コンピューティングデバイスが、前記委譲先主体が前記リソースにアクセスする要求を受信することであって、
前記要求は、前記委譲先主体が前記リソースにアクセスできるように前記委譲先主体に対して発行されたセキュリティトークンを含み、
前記セキュリティトークンは、権限委譲アサーションを含み、
前記権限委譲アサーションは、委譲のターゲットとなるべきリソースと、前記リソースにアクセスする権利を転送する委譲元主体と、前記委譲元主体から前記リソースにアクセスする前記権利を受け取る委譲先主体と、前記リソースにアクセスする前記権利を表す動詞句と、委譲−指令動詞と、委譲連鎖の許容し得る深度を示す委譲深度とを使用して作成されることと、
前記コンピューティングデバイスが、前記セキュリティトークンから前記権限委譲アサーションを取得することと、
前記コンピューティングデバイスが、アサーション・コンテクストに前記権限委譲アサーションと、少なくとも前記リソース、前記動詞句、および前記委譲先主体を含む委譲許可アサーションとを結合することと、
前記コンピューティングデバイスが、前記アサーション・コンテクストを使用して前記委譲先が前記リソースにアクセスする許可を判定することと
を含むことを特徴とする方法。
【請求項２】
前記コンピューティングデバイスにおいて、前記権限委譲アサーションを信頼−許可ポリシーに追加することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記権限委譲アサーションは、
アサータ部分、述べる部分、主体１部分、委譲−指令動詞、「主体２、動詞句、リソース、事実修飾詞１．．．ｆ、」、場合、事実１、事実２、．．．事実ｎ、ｃ１．．．ｍ
というフォームであって、前記少なくとも１の事実１．．．ｎは表現部分及び動詞句を含み、前記動詞句はａ）述語部分、ｂ）アサートできる部分と事実部分、ｃ）エイリアス部分と表現部分のうちのひとつを含み、前記「ｆ」、「ｍ」、及び「ｎ」は整数であり、「ｃ」は制限を表す、フォームの中の英文であることを特徴とする請求項１に記載の方法。
【請求項４】
前記権限委譲アサーションは、前記リソースに関する前記権利に対する少なくとも１つの環境上の制限を示す事実修飾子をさらに含み、前記作成することは、前記事実修飾子を使用して前記権限委譲アサーションを作成することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項５】
第１の主体が、第２の主体が少なくとも１つのアサーションを行うように、該第２の主体に権利を委譲することができるようにする委譲機構のためのＡＰＩ（アプリケーション・プログラミング・インターフェース）を備えるプログラムを実行するデバイスであって、
プロセッサと、
前記プロセッサに結合され、コンピュータ実行可能命令を記憶したメモリであって、前記コンピュータ実行可能命令は、前記プロセッサにより実行されたときに、
第２の主体からリソースにアクセスする要求を受信することであって、前記要求は、第１の主体から第２の主体へリソースに関する権利を委譲する権限委譲アサーションを含む少なくとも１のセキュリティトークンを含み、前記権限委譲アサーションは、前記リソース、前記リソースにアクセスする前記権利を表す動詞句、前記第１の主体、前記第２の主体、委譲−指令動詞、及び委譲連鎖の許容し得る深度を示す委譲深度を含み、前記セキュリティトークンは前記第２の主体に対して発行され、前記第２の主体が前記リソースにアクセスすることを可能にすることと、
前記少なくとも１のセキュリティトークンから前記権限委譲アサーションを取得し、
アサーション・コンテクストに前記権限委譲アサーションと、少なくとも前記リソース、前記動詞句、および前記委譲先主体を含む委譲許可アサーションとを結合し、
前記アサーション・コンテクストを使用して、前記委譲先が前記リソースにアクセスする許可を判定することと
を前記プロセッサにさせる、メモリと
を含むことを特徴とするコンピューティングデバイス。
【請求項６】
前記委譲に対する制御は、アサータが、前記第１の主体が、前記少なくとも１つのアサーションを行う前記権利を委譲することができるには、前記第１の主体が有すべき少なくとも１つの属性を指定する能力を含むことを特徴とする請求項５に記載のデバイス。
【請求項７】
前記委譲に対する制御は、アサータが、前記第１の主体がある特定のリソースに関してある能力を有する場合に限って、前記第１の主体が、前記少なくとも１つのアサーションを行う前記権利を委譲することができることを指定する能力を含むことを特徴とする請求項５に記載のデバイス。
【請求項８】
前記委譲に対する制御は、アサータが、前記第２の主体が前記少なくとも１つのアサーションを行うことを許されるには、前記第２の主体が有すべき少なくとも１つの属性を指定する能力を含むことを特徴とする請求項５に記載のデバイス。
【請求項９】
前記委譲に対する制御は、アサータが、前記第２の主体がある特定のリソースに関してある能力を有する場合に限って、前記第２の主体が、前記少なくとも１つのアサーションを行うことを許されることを指定する能力を含むことを特徴とする請求項５に記載のデバイス。
【請求項１０】
前記委譲に対する制御は、アサータが、前記委譲または前記権利が執行されることが可能な仕方を制限する少なくとも１つの事実修飾子を指定する能力を含むことを特徴とする請求項５に記載のデバイス。
【請求項１１】
前記少なくとも１つの事実修飾子は、時間制限、ロケーション制限、ネットワーク接続機構制限、および取消し検査頻度制限を備える環境パラメータのグループから選択された少なくとも１つの環境パラメータを備えることを特徴とする請求項１０に記載のデバイス。
【請求項１２】
前記委譲に対する制御は、アサータが、許される推移的連鎖深度を指定する能力を含むことを特徴とする請求項５に記載のデバイス。
【請求項１３】
前記推移的連鎖深度は、連鎖深度標識、または複数の委譲−指令動詞の入れ子の表現の少なくともいずれかを使用して制御されることを特徴とする請求項１２に記載のデバイス。
【請求項１４】
前記権限委譲アサーションは、アサータ部分、述べる部分、主体１部分、委譲−指令動詞、「主体２、動詞句、リソース、事実修飾詞１．．．ｆ、」、場合、事実１、事実２、．．．事実ｎ、ｃ１．．．ｍという形態に適合し、前記「ｆ」、「ｎ」、および「ｍ」は、任意の整数であり、前記「ｃ」は制約を表し、事実修飾詞１．．．ｆ、事実１、事実２、．．．事実ｎ、およびｃ１．．．ｍは、任意の所与のアサーションにおけるオプションの部分であることを特徴とする請求項５に記載のデバイス。
【請求項１５】
プロセッサと、
前記プロセッサに結合され、コンピュータ可読命令を含むメモリであって、前記コンピュータ可読命令は、前記プロセッサにより実行されたときに、
権利を主体に委譲する際、許される推移的連鎖深度の制御を可能にする連鎖型委譲機構を備えるセキュリティ・スキームを実装することであって、前記制御は、推移的連鎖をまったく許さない第１の委譲−指令動詞と、無制限の推移的連鎖を許す第２の委譲−指令動詞とを備え、前記制御は、入れ子にされた、ある数の前記第１の委譲−指令動詞をさらに備えて、前記数が、０ではないが、有界である、許される推移的連鎖深度を確立するようにすることと、
リソースにアクセスする権利をあらわす動詞句を特定する連鎖型委譲機構を実装することと、
委譲先主体である少なくとも１の主体に権利を委譲するための権限委譲アサーションを形成することであって、前記権限委譲アサーションは、委譲元主体、前記委譲先主体、前記リソース、前記動詞句、および委譲−指令動詞を含むことと、
前記委譲先主体から前記リソースへアクセスする要求を受信することであって、前記要求は前記委譲元主体から前記委譲先主体へ発行された、前記リソースにアクセスするための少なくとも１のセキュリティトークンを含み、前記少なくとも１のセキュリティトークンは、前記権限委譲アサーションを含むことと、
前記少なくとも１のセキュリティトークンからアサーション・コンテクストを取得することと、
前記アサーション・コンテクストに前記権限委譲アサーションと、少なくとも前記リソース、前記動詞句、および前記委譲先主体を含む委譲許可アサーションとを結合することと、
前記プロセッサにより、前記アサーション・コンテクストを使用して、前記委譲先が前記リソースにアクセスする許可を判定することと
を前記プロセッサにさせる、メモリと
を含むことを特徴とするシステム。
【請求項１６】
前記第１の委譲−指令動詞は、０の値を割り当てられた連鎖深度標識に関連付けられた委譲−指令動詞を備え、前記第２の委譲−指令動詞は、無限の値を割り当てられた連鎖深度標識に関連付けられた委譲−指令動詞を備えることを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記許される推移的連鎖深度の強制は、委譲を含むアサーションの条件付き事実に伝播させられることを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記第１の委譲−指令動詞、および前記第２の委譲−指令動詞は、「Ｄ」が、ゼロ（０）または無限（∞）に設定された「ｃａｎ  ａｓｓｅｒｔD」または「ｃａｎ  ｓａｙD」を備えることを特徴とする請求項１５に記載のシステム。
【請求項１９】
前記制御は、少なくとも任意の正の整数値が割り当てられることが可能な連鎖深度標識に関連付けられた委譲−指令動詞をさらに備えることを特徴とする請求項１５に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
コンピュータ、およびその他の電子デバイスが、人々の職業生活および個人生活に浸透している。職業環境において、人々は、プロジェクト共同作業中に機密情報を交換し、共有する。個人環境において、人々は、電子商取引、および個人情報の伝送に関与する。これら、および他の多数の事例において、電子セキュリティが、重要であると考えられる。
【０００２】
電子セキュリティ・パラダイムは、職業情報を機密に保ち、個人情報をプライベート（非公開）に保つことができる。電子セキュリティ・パラダイムには、何らかのレベルの暗号化、および／またはウイルス、ワーム、およびスパイ・ウェアなどのマルウェア（malware）からの保護を必要とする可能性がある。情報の暗号化と、マルウェアからの保護はともに、これまでに、特にここ数年、大きな注目を集めてきている。
【０００３】
しかし、情報へのアクセスを制御することも、電子情報の安全を確保する同等に重要な側面である。このことは、電子情報の共有および／または転送から利益が引き出されるシナリオに関して特に当てはまる。そのようなシナリオにおいて、ある人々は、アクセスを許可されるべきである一方で、他の人々は、排除されるべきである。
【０００４】
アクセス制御は、初期の頃の時間分割システム以来、共有されるコンピュータおよびアプリケーション・サーバの一般的な特徴である。それには、いくつかの異なるアプローチが存在し、情報へのアクセスを制御するのに使用されてきた。これらのアプローチは、共通の基礎（基盤）を、何らかのリソースへのアクセスを要求するエンティティの認証を許されるアクセスに対して許可を与える機構と組み合わせる際に、共有する。認証機構には、パスワード、ケルベロス（Kerberos）、およびｘ．５０９証明書が含まれる。これらの機構の目的は、リソースを制御するエンティティが、要求元のエンティティ（requesting entity）を、またはリソース制御エンティティが必要とする、このエンティティについての情報を、確実に識別することを可能にすることである。
【０００５】
許可の例には、ＡＣＬ（access control lists；アクセス制御リスト）、ならびにＸＡＣＭＬ（extensible Access Control Markup Language；拡張アクセス制御マークアップ言語）またはＰＥＲＭＩＳ（PrivilEge and Role Management Infrastructure）などのポリシーベースの機構が含まれる。これらの機構は、いずれのエンティティが、ファイル・システムにおけるファイル、ハードウェア・デバイス、データベース情報などの所与のリソースにアクセスすることができるかを規定する。これらの機構は、要求側についての認証された情報と、リソースへの許されるアクセスとの間のマッピングを提供することによって、この許可を実行する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
コンピュータ・システムが、インターネットなどの大きなネットワークを介して、より、全世界的に接続されるようになってきたので、これらの機構は、アクセス制御要件を進化させようとする場合に、多少、限界があり、柔軟性を欠くことが分かってきた。地理的に散らばったユーザおよびコンピュータリソースのシステムは、複数の管理ドメインにまたがるシステムを含め、特に、いくつかの難題をもたらし、これらの難題は、現在展開されている技術において十分に対処されていない。
【課題を解決するための手段】
【０００７】
概要
権利の委譲（delegation of rights）は、いくつかの仕方で制御されることが可能である。例示的な実施形態において、権限委譲アサーション（delegation authority assertion）は、委譲元主体（delegator principal）、委譲先主体（delegatee principal）、動詞句（verb phrase）、リソース、および委譲−指令動詞（directive verb）を使用して策定される。別の例示的な実施形態において、アサータ（assertor）、第１の主体（first principal）、および第２の主体（second principal）が関与する委譲機構（delegation mechanism）が、委譲が、具体的に制御されることを可能にする。さらに別の例示的な実施形態において、連鎖型委譲機構（chained delegation mechanism）が、許された推移的連鎖深度（permitted transitive chaining depth）の明示的な制御を可能にする。
【０００８】
この概要は、詳細な説明において後段でさらに説明される概念の選択を、簡略化された形態で概説するために与えられる。この概要は、特許請求される主題の重要な特徴、または不可欠な特徴を特定することは意図しておらず、特許請求される主題の範囲を確定する助けとして使用されることも意図していない。さらに、他の方法、システム、スキーム、装置、デバイス、媒体、プロシージャ、ＡＰＩ、構成、プロトコルなどの実装が、本明細書で説明される。
【０００９】
同一の符号が、すべての図面において、同様の、及び／または対応する態様、特徴、および構成要素を指すように使用される。
【図面の簡単な説明】
【００１０】
【図１】例示的なセキュリティ・スキームが実施されることが可能である、例示的な一般的な環境を示すブロック図である。
【図２】２つのデバイスと、いくつかの例示的なセキュリティ関連の構成要素とを有する例示的なセキュリティ環境を示すブロック図である。
【図３】例示的なセキュリティ関連のデータが、セキュリティ関連の構成要素の間で交換される図２の例示的なセキュリティ環境を示すブロック図である。
【図４】本明細書で説明されるセキュリティ関連の実装のために使用されることが可能である例示的なデバイスを示すブロック図である。
【図５】一般的なセキュリティ・スキームに関する例示的なアサーション・フォーマットを示すブロック図である。
【図６】機能の見地からの、権限委譲アサーションを含む、例示的な委譲機構を、例示的な委譲シナリオととともに示すブロック図である。
【図７】論理的見地からの例示的な委譲機構を、例示的な委譲タイプとともに示すブロック図である。
【図８】委譲機構の権限委譲アサーションに関する例示的な表明フォーマットを示すブロック図である。
【図９】機能の見地からの例示的な連鎖型委譲機構を、例示的な連鎖型委譲シナリオとともに示すブロック図である。
【図１０】連鎖型委譲機構に関する２つの例示的なフォーマット・アプローチを示すブロック図である。
【図１１】権限委譲表明を作成するための方法の実施例を示す流れ図である。
【発明を実施するための形態】
【００１１】
例示的なセキュリティ環境
図１は、例示的なセキュリティ・スキーム１００が実装されることが可能である、例示的な一般的な環境を示すブロック図である。セキュリティ・スキーム１００は、セキュリティへの統合されたアプローチを表す。図示されるとおり、セキュリティ・スキーム１００は、いくつかのセキュリティ概念、すなわち、セキュリティ・トークン１００（Ａ）、セキュリティ・ポリシー１００（Ｂ）、および評価エンジン１００（Ｃ）を含む。一般に、セキュリティ・トークン１００（Ａ）とセキュリティ・ポリシー１００（Ｂ）は共同で、評価エンジン１００（Ｃ）に入力を与える。評価エンジン１００（Ｃ）は、これらの入力を受け入れ、何らかのリソースへのアクセスが許されるべきか、拒否されるべきかを示す許可出力（authorization output）を生成する。
【００１２】
説明される実施形態では、セキュリティ・スキーム１００は、ハードウェア、ソフトウェア、ファームウェア、これらの幾つかの組合せ、などから成ることが可能な、１つまたは複数のデバイス１０２に、オーバーレイ（overlay）され、および／または、組み込まれることが可能である。図示されるとおり、「ｄ」が何らかの整数である「ｄ」個のデバイスが、１つまたは複数のネットワーク１０４を介して互いに接続される。より具体的には、デバイス１０２（１）、デバイス１０２（２）、デバイス１０２（３）．．．デバイス１０２（ｄ）が、ネットワーク１０４を介して通信することができる。
【００１３】
各デバイス１０２は、セキュリティ・スキームの少なくとも一部分を実装することができる任意のデバイスであることが可能である。そのようなデバイスの例には、コンピュータ（例えば、クライアント・コンピュータ、サーバ・コンピュータ、パーソナル・コンピュータ、ワークステーション、デスクトップ、ラップトップ、パームトップなど）、ゲーム機（例えば、コンソール、ポータブル・ゲーム・デバイスなど）、セットトップボックス、テレビ、家庭用電子機器（例えば、ＤＶＤプレーヤ／レコーダ、カム・コーダ、ＤＶＲ（デジタル・ビデオ・レコーダ）など）、ＰＤＡ（パーソナル・デジタル・アシスタント）、移動電話機、ポータブル・メディア・プレーヤ、以上の何らかの組合せなどが含まれるが、以上には限定されない。例示的な電子デバイスが、図４を特に参照して、本明細書の後段で説明される。
【００１４】
ネットワーク１０４が、一緒にリンクされ、及び／または互いの上に重ねられた任意の１つまたは複数のネットワークから形成されることが可能である。ネットワーク１０４の例には、インターネット、電話網、イーサネット（登録商標）、ＬＡＮ（ローカル・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）、ケーブル・ネットワーク、ファイバ・ネットワーク、ＤＳＬ（デジタル加入者線）ネットワーク、セルラーネットワーク、Ｗｉ−Ｆｉ（登録商標）ネットワーク、ＷｉＭＡＸ（登録商標）ネットワーク、ＶＰＮ（仮想プライベート・ネットワーク）、これらの幾つかの組合せ、などが含まれるが、以上には限定されない。ネットワーク１０４は、複数のドメイン、１つまたは複数のＧｒｉｄネットワークなどを含むことが可能である。これらのネットワークのそれぞれ、またはネットワークの組合せは、任意のネットワーキング標準に従って動作することが可能である。
【００１５】
図示されるとおり、デバイス１０２（１）が、デバイス１０２（１）と対話しているユーザ１０６に対応する。デバイス１０２（２）が、デバイス１０２（２）上で実行されているサービス１０８に対応する。デバイス１０２（３）が、リソース１１０に関連付けられている。リソース１１０は、デバイス１０２（３）の一部であっても、デバイス１０２（３）とは別個であってもよい。
【００１６】
ユーザ１０６、サービス１０８、ならびに任意の所与のデバイス１０２などのマシンが、例示的なエンティティの、網羅的でないリストを形成する。これらのエンティティは、時々、リソース１１０にアクセスすることを望む可能性がある。セキュリティ・スキーム１００が、適切に認証され、許可されたエンティティが、リソース１１０にアクセスすることを許す一方で、他のエンティティが、リソース１１０にアクセスするのを防止することを確実にする。
【００１７】
図２は、２つのデバイス１０２（Ａ）および１０２（Ｂ）と、いくつかの例示的なセキュリティ関連の構成要素とを有する例示的なセキュリティ環境２００を示すブロック図である。セキュリティ環境２００は、ＳＴＳ（セキュリティ・トークン・サービス）オーソリティ（authority）などのオーソリティ２０２も含む。デバイス１０２（Ａ）は、エンティティ２０８に対応する。デバイス１０２（Ｂ）は、リソース１１０に関連付けられている。セキュリティ・スキーム１００は、より複雑な環境において実装されることも可能であるものの、この比較的単純な２デバイス・セキュリティ環境２００を使用して、例示的なセキュリティ関連の構成要素が説明される。
【００１８】
図示されるとおり、デバイス１０２（Ａ）は、２つのセキュリティ関連の構成要素、すなわち、セキュリティ・トークン２０４およびアプリケーション２１０を含む。セキュリティ・トークン２０４は、１つまたは複数のアサーション２０６を含む。デバイス１０２（Ｂ）は、５つのセキュリティ関連の構成要素、すなわち、許可コンテクスト（authorization context）２１２、リソース・ガード（resource guard）２１４、監査ログ（audit log）２１６、許可エンジン２１８、およびセキュリティ・ポリシー２２０を含む。セキュリティ・ポリシー２２０は、信頼−許可ポリシー（trust and authorization policy）２２２、許可照会（authorization query）テーブル２２４、および監査ポリシー（audit policy）２２６を含む。
【００１９】
各デバイス１０２は、異なる仕方で構成されることが可能であり、それでも、セキュリティ・スキーム１００のすべて、または一部分を実装することができる。例えば、デバイス１０２（Ａ）が、複数のセキュリティ・トークン２０４および／またはアプリケーション２１０を有することが可能である。別の例として、デバイス１０２（Ｂ）が、監査ログ２１６または監査ポリシー２２６を含まないことが可能である。また、他の構成も可能である。
【００２０】
説明される実施形態において、オーソリティ２０２が、アサーション２０６を有するセキュリティ・トークン２０４をエンティティ２０８に発行する。アサーション２０６は、本明細書の後段で説明され、「セキュリティ・ポリシー・アサーション言語の特性例（Security Policy Assertion Language Example Characteristics）」という名称のセクションを含む。したがって、エンティティ２０８は、セキュリティ・トークン２０４に関連付けられる。動作において、エンティティ２０８は、アプリケーション２１０を使用して、セキュリティ・トークン２０４の効力を使用してリソース１１０にアクセスすることを望む。
【００２１】
リソース・ガード２１４は、リソース１１０にアクセスする要求を受信し、デバイス１０２（Ｂ）のその他のセキュリティ関連の構成要素を使用して、認証−許可プロセスを事実上、管理する。信頼−許可ポリシー２２２は、名前が暗示するとおり、セキュリティ環境２００内で、エンティティを信頼し、およびアクションを許可することに向けられたポリシーを含む。信頼−許可ポリシー２２２は、例えば、セキュリティ・ポリシー・アサーション（図２に明示せず）を含むことが可能である。許可照会テーブル２２４は、アクセス要求などの要求されたアクションを、適切な許可照会にマップする。監査ポリシー２２６は、セキュリティ環境２００におけるセキュリティ・スキーム１００を実装することと関係する監査責任（audit responsibilities）および監査タスクを定義する。
【００２２】
許可コンテクスト２１２は、要求元のエンティティ（requesting entity）を認証するのに使用される、セキュリティ・トークン２０４からのアサーション２０６、ならびに信頼−許可ポリシー２２２からのセキュリティ・ポリシー・アサーション、を収集する。許可コンテクスト２１２における、これらの収集されたアサーションは、アサーション・コンテクストを形成する。このため、許可コンテクスト２１２は、様々なアサーションに加え、他の情報も含むことが可能である。
【００２３】
許可コンテクスト２１２からのアサーション・コンテクスト、および許可照会テーブル２２４からの許可照会が、許可エンジン２１８に供給される。このアサーション・コンテクストおよび許可照会を使用して、許可エンジン２１８は、許可判定（authorization decision）を行う。リソース・ガード２１４は、この許可判定に基づいて、アクセス要求に応答する。監査ログ２１６は、例えば、要求されたリソース１１０のＩＤ、および／または許可エンジン２１８によって実行されるアルゴリズム評価論理、などの監査情報を含む。
【００２４】
図３は、例示的なセキュリティ関連のデータが、セキュリティ関連の構成要素の間で交換される、例示的なセキュリティ環境２００を示すブロック図である。セキュリティ関連のデータは、例示的なアクセス要求動作の支援を目的に交換される。この例示的なアクセス要求動作において、エンティティ２０８が、アプリケーション２１０を使用してリソース１１０にアクセスすることを望み、アクセスすることの許可を、セキュリティ・トークン２０４で知らせる。このため、アプリケーション２１０は、アクセス要求*をリソース・ガード２１４に送信する。図３についてのこの説明において、アスタリスク（すなわち、「*」）は、説明されるセキュリティ関連のデータが、図３に明示されていることを示す。
【００２５】
説明される実施形態において、エンティティ２０８は、トークン*、セキュリティ・トークン２０４で自らをリソース・ガード２１４に認証*する。リソース・ガード２１４は、トークン・アサーション*を許可コンテクスト２１２に転送する。これらのトークン・アサーションは、セキュリティ・トークン２０４のアサーション２０６（図２の）である。セキュリティ・ポリシー２２０が、許可照会テーブル*をリソース・ガード２１４に供給する。許可照会テーブルは、許可照会テーブル・モジュール２２４に由来する。リソース・ガード２１４に送信される許可照会テーブルは、現在のアクセス要求と直接に関係する１つまたは複数の部分に限定されることが可能である。
【００２６】
ポリシー・アサーションが、セキュリティ・ポリシー２２０によって信頼−許可ポリシー２２２から抽出される。このポリシー・アサーションには、信頼関連のアサーションと許可関連のアサーションがともに含まれることが可能である。セキュリティ・ポリシー２２０は、ポリシー・アサーション*を許可コンテクスト２１２に転送する。許可コンテクスト２１２は、トークン・アサーションとポリシー・アサーションを組み合わせて、アサーション・コンテクストにする。このアサーション・コンテクスト*は、丸で囲まれた「Ａ」によって示されるとおり、許可コンテクスト２１２から許可エンジン２１８に供給される。
【００２７】
許可照会が、許可照会テーブルから確認される。リソース・ガード２１４が、この許可照会（ａｕｔｈ．ｑｕｅｒｙ*）を許可エンジン２１８に供給する。許可エンジン２１８は、評価アルゴリズムにおいて、この許可照会およびアサーション・コンテクストを使用して、許可判定を作り出す。この許可判定（ａｕｔｈ．ｄｃｎ．*）が、リソース・ガード２１４に戻される。エンティティ２０８が、リソース・ガード２１４によってリソース１１０へのアクセス*を許可されるかどうかは、この許可判定に依存する。この許可判定が肯定的である場合、アクセスは許可される。反対に、許可エンジン２１８によって発行された許可判定が否定的である場合、リソース・ガード２１４は、リソース１１０へのアクセスをエンティティ２０８に許可しない。
【００２８】
また、許可プロセスは、許可プロセスを補完するセマンティクスを使用して監査されることも可能である。この監査は、許可プロセスの監視、および／または、例えば、許可エンジン２１８によって論理的に実行される評価アルゴリズムの、中間結果および／または最終結果の格納を、引き起こす可能性がある。その目的で、セキュリティ・ポリシー２２０が、監査ポリシー２２６からの監査ポリシー*を許可エンジン２２８に供給する。少なくとも、監査が要求されると、監査情報を有する監査レコード*が、許可エンジン２１８から監査ログ２１６に転送されることが可能である。代替として、監査情報は、例えば、許可判定の一環として、または別個に、リソース・ガード２１４を介して監査ログ２１６にルーティングされてもよい。
【００２９】
図４は、本明細書で説明されるセキュリティ関連の実施形態のために使用されることが可能である例示的なデバイス１０２のブロック図である。複数のデバイス１０２が、１つまたは複数のネットワーク１０４を介して通信することができる。図示されるとおり、２つのデバイス１０２（Ａ／Ｂ）および１０２（ｄ）が、ネットワーク１０４を介する通信交換を行うことが可能である。２つのデバイス１０２が特に示されているものの、１つまたは２つ以上のデバイス１０２が、実施形態に依存して、使用されることが可能である。
【００３０】
一般に、デバイス１０２は、クライアント・デバイスまたはサーバ・デバイス、ワークステーション、または他の汎用コンピュータ・デバイス、ＰＤＡ、移動電話機、ゲーム・プラットフォーム、エンターテイメント・デバイス、図１に関連して前段で列挙したデバイスの１つ、以上の何らかの組合せなどの、任意のコンピュータ・デバイスまたは処理対応のデバイスを表すことが可能である。図示されるとおり、デバイス１０２は、１つまたは複数のＩ／Ｏ（入出力）インターフェース４０４、少なくとも１つのプロセッサ４０６、および１つまたは複数の媒体４０８を含む。媒体４０８は、プロセッサ実行可能命令４１０を含む。
【００３１】
デバイス１０２の説明される実施形態において、Ｉ／Ｏインターフェース４０４には、（ｉ）ネットワーク１０４を介して通信するためのネットワーク・インターフェース、（ｉｉ）ディスプレイ・スクリーン上で情報を表示するためのディスプレイ・デバイス・インターフェース、および（ｉｉｉ）１つまたは複数のマン−マシン・インターフェースなどが含まれることが可能である。（ｉ）ネットワーク・インターフェースの例には、ネットワークカード、モデム、１つまたは複数のポートなどが含まれる。（ｉｉ）ディスプレイ・デバイス・インターフェースの例には、グラフィックス・ドライバ、グラフィックス・カード、スクリーンまたはモニタに関するハードウェア・ドライバまたはソフトウェア・ドライバなどが含まれる。印刷デバイス・インターフェースも同様に、Ｉ／Ｏインターフェース４０４の一部として含まれることが可能である。（ｉｉｉ）マン−マシン・インターフェースの例には、マン−マシン・インターフェース・デバイス４０２（例えば、キーボード、リモート、マウス、または他のグラフィカル・ポインティング・デバイスなど）に有線または無線で通信するインターフェースが含まれる。
【００３２】
一般に、プロセッサ４０６は、プロセッサ実行可能命令４１０などの、プロセッサ実行可能命令を実行する、遂行する、および／または、達成することができる。媒体４０８は、１つまたは複数のプロセッサ・アクセス可能媒体から成る。つまり、媒体４０８は、デバイス１０２による機能の実行を実現するようにプロセッサ４０６によって実行可能であるプロセッサ実行可能命令４１０を含むことが可能である。
【００３３】
このため、セキュリティ関連の実施形態に関する実現は、プロセッサ実行可能命令の一般的な文脈において説明されることが可能である。一般に、プロセッサ実行可能命令には、特定のタスクを実行し、及び／または可能にし、及び／または特定の抽象データ型を実装する、ルーチン、プログラム、アプリケーション、コーディング、モジュール、プロトコル、オブジェクト、構成要素、メタデータおよびメタデータの定義、データ構造、ＡＰＩ（アプリケーション・プログラミング・インターフェース）、スキーマなどが含まれる。プロセッサ実行可能命令は、別個の記憶媒体の中に配置されること、異なるプロセッサによって実行されること、および／または様々な伝送媒体を介して伝搬されること、または様々な伝送媒体上に存在することが可能である。
【００３４】
プロセッサ４０６は、任意の適用可能な製造可能技術を使用して実装されることが可能である。媒体４０８は、デバイス１０２の一部として含まれる、及び／またはデバイス１０２がアクセスすることができる任意の利用可能な媒体であることが可能である。媒体４０８には、揮発性媒体と不揮発性媒体、リムーバブルな媒体とリムーバブルでない媒体、ならびに記憶媒体と伝送媒体（例えば、無線通信チャネルまたは有線通信チャネル）が含まれる。例えば、媒体４０８には、プロセッサ実行可能命令４１０の、より長期の大容量格納のためのディスク／フラッシュ・メモリ／光媒体のアレイ、現在、実行されている命令の、より短期の格納のためのＲＡＭ（ランダム・アクセス・メモリ）、通信（例えば、セキュリティ関連のデータ）を伝送するためのネットワーク１０４上のリンクなどが含まれることが可能である。
【００３５】
特に図示されるとおり、媒体４０８は、少なくともプロセッサ実行可能命令４１０を備える。一般に、プロセッサ実行可能命令４１０は、プロセッサ４０６によって実行されると、デバイス１０２が、様々な流れ図に示されるアクションを含め、本明細書で説明される様々な機能を実行することを可能にする。単に例として、プロセッサ実行可能命令４１０には、セキュリティ・トークン２０４、アサーション２０６の少なくとも１つ、許可コンテクスト・モジュール２１２、リソース・ガード２１４、監査ログ２１６、許可エンジン２１８、セキュリティ・ポリシー２２０（例えば、信頼−許可ポリシー２２２、許可照会テーブル２２４、および／または監査ポリシー２２６など）、以上の何らかの組合せなどが含まれることが可能である。図４に明示されないものの、プロセッサ実行可能命令４１０には、アプリケーション２１０および／またはリソース１１０が含まれることも可能である。
【００３６】
セキュリティ・ポリシー・アサーション言語の特性例
このセクションは、セキュリティ・ポリシー・アサーション言語（ＳｅｃＰＡＬ）の実施形態の例示的な特性を説明する。このセクションのＳｅｃＰＡＬ実施形態は、比較的インフォーマルな仕方で、単に例として説明される。このＳｅｃＰＡＬ実施形態は、エンド・ツー・エンド・ソリューションを作成することにおける、セキュリティ・ポリシーおよびセキュリティ・トークンのオブリゲーション（obligation；義務）の広い範囲に対処する能力を有する。これらのセキュリティ・ポリシーおよびセキュリティ・トークンのオブリゲーションには、例として、限定としてではなく、明示的な信頼関係を記述すること、セキュリティ・トークン発行ポリシーを表現すること、ＩＤ、属性、能力、および／または委譲ポリシーを含むセキュリティ・トークンを提供すること、リソース許可ポリシーおよび委譲ポリシーを表現することなどが含まれる。
【００３７】
説明される実施形態では、ＳｅｃＰＡＬは、セキュリティを、柔軟性があり、扱いやすい仕方で表現するための宣言型の論理ベースの言語である。ＳｅｃＰＡＬは、包括的であることが可能であり、さらに、ＳｅｃＰＡＬは、信頼関係、許可ポリシー、委譲ポリシー、ＩＤアサーションおよび属性アサーション、能力アサーション、取消し、監査要件などを表現するための、一定の方式に従う機構（uniform mechanism）を提供することができる。この一定の方式により、セキュリティ・スキームを理解可能にし、解析可能にするという点で具体的な利点がもたらされる。また、この一定の方式に従う機構は、異種のセキュリティ技術間のセマンティクス変換および調整の必要性を回避することによって、または少なくとも大幅に減らすことを可能にすることによって、セキュリティの確実性も向上させる。
【００３８】
ＳｅｃＰＡＬ実施形態は、以下の例示的な特性のいずれを含むことも可能である。すなわち、［１］ＳｅｃＰＡＬは、比較的理解するのが容易であり得る。ＳｅｃＰＡＬは、ＳｅｃＰＡＬのアサーションが、英語の文として読み取られることを可能にする定義シンタックスを使用することが可能である。また、ＳｅｃＰＡＬの文法は、制限的であり、したがって、ユーザが、明確に定義されたセマンティクスを有する少数の主語−動詞−目的語（例えば、主語−動詞句）構文だけを理解することしか要求しない。最後に、アサーションのコレクションに基づいて、推測可能な事実を評価するためのアルゴリズムは、少数の比較的単純な規則に依存することが可能である。
【００３９】
［２］ＳｅｃＰＡＬは、ＳｅｃＰＡＬの実施形態における業界標準のインフラストラクチャを活用して、ＳｅｃＰＡＬの採用、および既存のシステムへの統合を容易にすることができる。例えば、形式的なモデルからの単純明快なマッピングであるＸＭＬ（拡張マークアップ言語）シンタックスが使用されることが可能である。このことにより、標準のパーサおよびシンタックス正確性検証ツールの使用が可能になる。また、このことにより、完全性、発信元の証拠、および機密性に関して、Ｗ３Ｃ  ＸＭＬのデジタル署名標準および暗号化標準の使用も可能になる。
【００４０】
［３］ＳｅｃＰＡＬは、分散ポリシー作成および分散ポリシー構成をサポートすることによって、分散ポリシー管理を可能にすることができる。このことにより、ポリシー、またはポリシーの諸部分が、割り当てられた管理責務に基づいて、どこで作成されるかを支配する様々な動作モデルへの柔軟性のある適合が可能になる。ポリシー・オブジェクトにデジタル署名し、ポリシー・オブジェクトを暗号化する標準のアプローチの使用により、これらのオブジェクトのセキュアな配信が可能になる。［４］ＳｅｃＰＡＬは、効率的で、安全な評価を可能にする。評価が終了し、正しい答えをもたらすことを確実にするのに、入力に対する簡単なシンタックス検査で十分である。
【００４１】
［５］ＳｅｃＰＡＬは、ＩＤ管理のために、要求されるポリシー、許可判定、監査、およびＰＫＩ（公開鍵インフラストラクチャ）をサポートするアクセス制御要件のための完全なソリューションを提供することができる。これに対して、他のほとんどのアプローチは、これらの広範なセキュリティ問題の１つのサブセットに的を絞り、対処することをなんとかやり遂げるだけである。［６］ＳｅｃＰＡＬは、Ｇｒｉｄ環境、およびその他のタイプの分散システムに関するセキュリティ問題を扱うことを含むが、これには限定されない、いくつかの目的に十分なだけ表現豊かである可能性がある。特定のシステムのニーズへの適合を許しながら、言語セマンティクスおよび評価プロパティを維持する仕方で、拡張性が可能にされる。
【００４２】
図５は、一般的なセキュリティ・スキームに関する例示的なアサーション・フォーマット５００を示すブロック図である。本明細書で別に説明される実施形態において使用されるセキュリティ・スキーム・アサーションは、例示的なアサーション・フォーマット５００とは異なる可能性がある。しかし、アサーション・フォーマット５００は、セキュリティ・スキーム・アサーションに関する１つの例示的なフォーマットの基本的な例示であり、一般的なセキュリティ・スキームの様々な態様の例示的な説明される実施形態を理解するための基礎を提供する。
【００４３】
アサーション・フォーマット５００の一番上の行に示されるとおり、一般的なレベルにおける例示的なアサーションは、主体（principal）部分５０２、述べる（say）部分５０４、および主張（claim）部分５０６を含む。原文どおりに、アサーション・フォーマット５００の一般的なレベルは、主体が主張を述べる（ｐｒｉｎｃｉｐａｌ  ｓａｙｓ  ｃｌａｉｍ）と表されることが可能である。
【００４４】
アサーション・フォーマット５００の次の行で、主張部分５０６が、例示的な構成部分に分離されている。このため、例示的な主張部分５０６は、事実部分５０８、場合部分５１０、「ｎ」個の条件付き事実1...n部分５０８（１．．．ｎ）、およびｃ部分５１２を含む。添え字「ｎ」は、何らかの整数値を表す。凡例５２４に示されるとおり、ｃ部分５１２は、制約部分を表す。単一の制約だけしか図示されていないものの、ｃ部分５１２は、実際には、複数の制約（例えば、ｃ1．．．ｃm）を表すことが可能である。場合部分５１０の右側の条件付き事実部分５０８（１．．．ｎ）および制約５１２（１．．．ｍ）のセットは、先行詞（ａｎｔｅｃｅｄｅｎｔ）と呼ばれることが可能である。
【００４５】
原文どおりに、主張部分５０６は、以下によって表されることが可能である。すなわち、事実1．．．、事実n、ｃの場合、事実（ｆａｃｔ  ｉｆ  ｆａｃｔ1，．．．，ｆａｃｔn，ｃ）。このため、全体的なアサーション・フォーマット５００は、テキストで以下のように表されることが可能である。すなわち、事実1、．．．、事実n、ｃの場合、主体が、事実を述べる（ｐｒｉｎｃｉｐａｌ  ｓａｙｓ  ｆａｃｔ  ｉｆ  ｆａｃｔ1，．．．，ｆａｃｔn，ｃ）。しかし、アサーションは、以下の程度に単純であることも可能である。すなわち、主体が、事実を述べる。アサーションの、この省略された３部分バージョンにおいて、場合部分５１０で始まり、ｃ部分５１２まで続く条件付き部分は、省略される。
【００４６】
また、各事実部分５０８は、構成部分にさらに細分されることも可能である。例示的な構成部分は、ｅ部分５１４および動詞句部分５１６である。凡例５２４によって示されるとおり、ｅ部分５１４は、表現部分を表す。原文どおりに、事実部分５０８は、以下によって表されることが可能である。すなわち、ｅ  ｖｅｒｂｐｈｒａｓｅ。
【００４７】
各ｅ部分、つまり、表現部分５１４は、２つの例示的なオプションの１つをとることが可能である。これら２つの例示的な表現オプションは、定数５１４（ｃ）および変数５１４（ｖ）である。主体は、定数５１４（ｃ）および／または変数５１４（ｖ）に含まれることが可能である。
【００４８】
また、各動詞句部分５１６は、３つの例示的なオプションの１つをとることも可能である。これら３つの例示的な動詞句オプションは、述語部分５１８と、その後に続く１つまたは複数のｅ1...n部分５１４（１．．．ｎ）、アサートすることができる部分５２０と、その後に続く事実部分５０８、およびエイリアス部分５２２と、その後に続く表現部分５１４である。テキストの点で、これら３つの動詞句オプションは、以下によって表現されることが可能である。すなわち、それぞれ、述語ｅ1．．．ｅn、事実をアサートする（assert）ことができる、およびエイリアスｅである。整数「ｎ」は、事実５０８（１．．．ｎ）および表現５１４（１．．．ｎ）に関して様々な値をとることが可能である。
【００４９】
一般に、ＳｅｃＰＡＬステートメントは、セキュリティ主体によって行われるアサーションの形態である。セキュリティ主体は、通常、暗号鍵によって識別され、したがって、セキュリティ主体は、システム境界にまたがって認証されることが可能である。最も単純な形態において、アサーションは、主体が、ある事実が有効である（例えば、事実部分５０８を含む主張５０６によって表されるような）と信じることを言明する。また、アサーションは、他の１つまたは複数の事実が有効であり、何らかの条件セットが満たされる場合（例えば、事実部分５０８から、場合部分５１０、条件付き事実部分５０８（１．．．ｎ）を経てｃ部分５１２まで続く主張５０６によって表されるとおり）、ある事実が有効であることを言明することも可能である。また、まったく制約５１２を伴わない条件付き事実５１８（１．．．ｎ）、および／または、まったく条件付き事実５０８（１．．．ｎ）を伴わない制約５１２が存在することも可能である。
【００５０】
説明される実施形態において、事実は、主体についてのステートメントである。４つの例示的なタイプの事実ステートメントが、このセクションにおいて、この場合、説明される。第１に、ある事実が、ある「アクション動詞」で、あるリソースに対してあるアクションを実行する権利を、ある主体が有することを言明することが可能である。例示的なアクション動詞には、呼び出す、送信する、読む、リストアップする、実行する、書き込む、変更する、付加する、削除する、インストールする、所有するなどが含まれるが、以上には限定されない。リソースは、ＵＲＩ（ユニバーサル・リソース・インジケータ）、または他の任意のアプローチによって識別されることが可能である。
【００５１】
第２に、ある事実が、「有する」動詞を使用して、主体識別子と１つまたは複数の属性との間の結び付きを表現することが可能である。例示的な属性には、電子メール名、一般名、グループ名、役割タイトル、アカウント名、ＤＮＳ（ドメイン・ネーム・サーバ／サービス）名、ＩＰ（インターネット・プロトコル）アドレス、デバイス名、アプリケーション名、組織名、サービス名、アカウントＩＤ（識別／識別子）などが含まれるが、以上には限定されない。例示的な第３のタイプの事実は、２つの主体識別子が、「エイリアス」動詞を使用して、同一の主体を表すように定義されることが可能であることである。
【００５２】
「修飾子」または事実修飾子が、前述の３つの事実タイプのいずれかの一部として含められることが可能である。修飾子は、事実が有効であると考えられるとするなら、成立しなければならないとアサータ（assertor）が信じる環境パラメータ（例えば、時間、主体ロケーションなど）を、アサータが示すことを可能にする。そのようなステートメントは、これらの修飾子値に基づいて、アサータと、依拠する相手の有効性検査との間で、きれいに分離されることが可能である。
【００５３】
例示的な第４のタイプの事実は、「アサートできる（can assert）」動詞によって定義される。この「アサートできる」動詞は、信頼関係および委譲を表現するための、柔軟性のある、強力な機構を提供する。例えば、この「アサートできる」動詞は、１つの主体（Ａ）が、第２の主体（Ｂ）によってアサート（表明）される、いくつかのタイプの事実を信じる意思を言明することを可能にする。例えば、「Ｂが、事実（）をアサートできると、Ａが述べる」および「Ｂが、事実（）を述べる」というアサーションが与えられると、Ａが事実（）を有効であると信じる、と結論付けることができ、したがって、「Ａが事実（）を述べる」と推論されることが可能である。
【００５４】
そのような信頼アサーションおよび委譲アサーション明は、（ｉ）非有界であり、推移的であって、下流の委譲を許す、または（ｉｉ）有界であり、下流の委譲を除外することが可能である。修飾子は、「アサートできる」タイプの事実に適用されることが可能であるものの、これらの「アサートできる」タイプの事実に対する修飾子のサポートを省くことにより、所与のセキュリティ・スキームのセマンティクスおよび評価安全性特性が大幅に簡略化される。
【００５５】
説明される実施形態において、変数を使用して、具体的な事実が言明されることが可能であり、あるいはポリシー表現が書かれることが可能である。これらの変数は、型付きであり、無制限である（例えば、正しい型の任意の具体的な値とマッチすることを許される）ことも、制限されている（例えば、指定されたパターンに基づく具体的な値のサブセットとマッチすることを要求される）ことも可能である。
【００５６】
セキュリティ許可判定は、該当するセキュリティ・ポリシー（例えば、セキュリティ・ポリシー２２０）およびセキュリティ・トークン（例えば、１つまたは複数のセキュリティ・トークン２０４）からのアサーション（例えば、アサーション・コンテクスト）のコレクションに対する許可照会の評価アルゴリズム（例えば、許可エンジン２１８において行われることが可能な）に基づく。許可照会は、事実および／または条件を組み合わせる、極めて複雑になることが可能な論理的表現である。これらの論理的表現には、付帯的な条件および／または制約を伴う、または伴わない、例えば、事実に対するＡＮＤ論理演算、ＯＲ論理演算、および／またはＮＯＴ論理演算が含まれることが可能である。
【００５７】
許可照会のこのアプローチは、所与のアクションが許可される前に、何が知られており、有効でなければならないかを定義するための柔軟性のある機構を提供する。照会テンプレート（例えば、許可照会テーブル２２４からの）が、全体的なセキュリティ・スキームの一部分を形成し、適切な許可照会が、様々なタイプのアクセス要求、およびその他の動作／アクションに関して宣言的に言明されることを許す。
【００５８】
権利の委譲を制御するための例示的な実施形態  
最新のシステム、特に分散システムは、権利が、エンティティ間で委譲されることが可能である場合、しばしば、より効果的に機能する。このことは、多種多様な機能状況において明らかになる。例示的な状況には、以下が含まれるが、以下には限定されない。すなわち、  
ユーザが、ユーザのために実行されているアプリケーションに、ユーザのリソース・アクセス権利の一部（some portion）を委譲する能力、  
管理者が、部下または仲間に、管理者のリソース・アクセス権利の一部を委譲する能力、および  
実行されるアプリケーションが、別のアプリケーションに、実行されるアプリケーションのリソース・アクセス権利を委譲する能力。
【００５９】
これらのタイプの委譲は、通常、多くの様々な仕方の１つまたは複数で制御されなければならない。例えば、これらのタイプの委譲は、限られた期間にわたってのみ、許されることが可能であり、さらに、委譲先が、目的の機能を実行するのに必要とする特定のリソースに限定される必要がある可能性がある。また、権利の下流の委譲を許す能力に対する有効な制御が、有益である可能性もある。つまり、委譲先が、その委譲先に与えられているアクセス権利の一部またはすべてを下流にさらに委譲することが、有益である可能性がある。
【００６０】
既存のシステムは、制御された委譲をサポートする限られた能力を提供する。ほとんどのシステムにおいて、この能力は、実行されるプログラムが、ユーザに成り済ますことを許すことに限られる。成り済まし（Impersonation）は、委譲先が、委譲元の完全なアクセス権利を執行する能力を表す。この成り済ましに関して、何らかの時間制限ぐらいしか存在しないが、この制限は、通常、時間単位で計られる、デフォルトのシステム値であり、対話ごとに制御されることは可能でない。Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）ケルベロス実施形態は、ユーザのために要求を処理している際に、サービスが委譲権（delegation rights）を有する能力をさらにサポートする。これにより、サービスが、ユーザに成り済ます権利を別のサービスに渡すことが可能になるが、この能力の使用を制約するための有効な制御は、まったく、もたらされない。その結果、これらの既存のシステムのユーザは、委譲先が、成り済ましの権利を濫用しないことを完全に信頼しなければならない。
【００６１】
Ｇｒｉｄコミュニティは、Ｘ．５０９プロキシ証明書に基づく委譲アプローチを開発した。また、これらも、委譲を制御する非常に限られた能力しかもたらさない。これらは、特定の委譲に対する時間制限の設定を許すものの、それでもやはり、委譲先が、アクセス要求を行う際に、委譲元のＩＤおよび属性を使用することを許す。プロキシ証明書を定義する標準の開発者は、制御された委譲の必要性を認識せず、制御された委譲のポリシーが証明書に挿入されることが可能であった箇所にプレースホルダを置いた。しかし、開発者は、そのような制御を表現する、または強いる機構をまったく定義しなかった。
【００６２】
図６は、機能の見地からの例示的な委譲機構６００を、例示的な委譲シナリオとともに示すブロック図である。図示されるとおり、例示的な委譲シナリオは、アサータ６０２、主体＃１  ６０４、および主体＃２  ６０６を含む。また、権利付与能力６０８、権利６１０、および２つの転送６１２（１）および６１２（２）も存在する。例示的な委譲機構６００は、権限委譲アサーション６１４、ならびに、いくつかの実施形態において、委譲許可アサーション６１６を含む。
【００６３】
図６の例示的な委譲シナリオに関する説明される実施形態において、アサータ６０２は、あるオーソリティに相当し、主体＃１  ６０４は、委譲元に相当し、主体＃２  ６０６は、委譲先に相当する。アサータ６０２は、権利付与能力６０８を有する。権限委譲アサーション６１４の転送６１２（１）を介して、権利付与能力６０８が、アサータ６０２から主体＃１  ６０４に委譲される。
【００６４】
このため、主体＃１  ６０４は、権限委譲アサーション６１４の結果、権利付与能力６０８を得る。主体＃１  ６０４は、権利６１０を有する。権限委譲アサーション６１４のため、主体＃１  ６０４は、主体＃２  ６０６などの、他の１つまたは複数の主体に権利６１０を与えることができる。委譲先主体、与えられる権利の性質、および／または与えられた権利が、どのように執行されることが可能であるかは、権限委譲アサーション６１４によって制御可能である。委譲許可表明６１６の転送６１２（２）を介して、権利６１０が、主体＃１  ６０４から主体＃２  ６０６に与えられる。転送６１２（１）は、暗黙であることが可能であること、および権限委譲アサーション６１４は、セキュリティ・ポリシーを介してリソース・ガード２１４（図２の）に知らされることが可能であることを理解されたい。権利６１０および委譲許可アサーション６１６に基づくリソース・アクセスを強いるのは、リソース・ガード２１４である。
【００６５】
このため、委譲機構６００は、少なくとも権限委譲アサーション６１４を含み、さらに、完全な委譲プロセスを完了させる委譲許可アサーション６１６を含むことが可能である。権限委譲アサーション６１４および委譲許可アサーション６１６の例示的な実施形態は、本明細書の後段でさらに説明される。
【００６６】
図７は、論理的見地からの例示的な委譲機構６００を、例示的な委譲タイプ７１４とともに示すブロック図である。図示されるとおり、例示的な委譲機構６００は、権利の委譲を制御するのに使用されることが可能な、いくつかの例示的な因子（factor）７０２〜７１２を含む。これらの例示的な因子には、例として、限定としてではなく、主体７０２、動詞句７０４、リソース７０６、事実修飾子７０８、属性７１０、推移的連鎖７１２などが含まれる。
【００６７】
委譲機構６００は、いくつかの異なるタイプの委譲制御を実装することができる。図示されるとおり、これらの例示的な委譲制御タイプには、属性ベース（attributed-based）の委譲７１４（１）、制約された委譲７１４（２）、深度有界の委譲７１４（３）、および幅有界の委譲７１４（４）が含まれるが、以上には限定されない。これら４つの特定の例示的なタイプの制御された委譲は、一般的な制御される委譲の概念および実施形態のさらなる説明の後、後段でより詳細に説明される。他の委譲タイプ７１４（Ｔ）によって表されるとおり、委譲機構６００は、他の多くのタイプの制御された委譲を実装することができる可能性がある。
【００６８】
説明される実施形態において、ブロック７０２〜７１０のそれぞれが、示される因子に関する委譲を制御する委譲機構６００の能力を論理的に表す。したがって、委譲機構６００は、識別された１つまたは複数の主体７０２、ある動詞句７０４、ある特定のリソース７０６、示される１つまたは複数の事実修飾子７０８、少なくとも１つの所与の属性７１０、および／または許された推移的連鎖（深度）７１２によって委譲を制御することが可能である。単に例として、委譲機構６００は、少なくとも、７０２〜７１２の因子を使用して委譲を制御するのに使用されることが可能なＡＰＩ（アプリケーション・プログラミング・インターフェース）として実現されることが可能である。
【００６９】
本明細書で前述したとおり、事実修飾子は、時間／期間、ロケーション、ネットワーク接続機構、取消し検査頻度（revocation check frequency）などの環境上の制限を含む。属性とは、属性名−属性値ペアを指し、これらのペアにおいて、主体は、１つまたは複数の属性を有することが可能である。
【００７０】
これらの因子のいずれも、主体＃１  ６０４および／または主体＃２  ６０６と関係することが可能である。つまり、単に例として、委譲機構６００は、どのリソース７０６にどのアクセス（例えば、動詞句７０４による）が、主体＃１  ６０４によって主体＃２  ６０６に委譲されることが可能であるかを制御することができる。委譲機構６００は、いずれの主体が、主体＃２  ６０６として適格であるかを制御することができる。さらに、委譲機構６００は、志望者である主体＃２  ６０６が、所与の属性７１０を有することを要求することが可能である。さらに、委譲に対する制限的な環境上の制御が、事実修飾子７０８を介して（例えば、条件付き制約に関連して）実施されることが可能である。これら、およびその他の可能性は、本明細書の後段でさらに明らかにされる。
【００７１】
また、委譲機構６００は、推移的連鎖委譲が有効にされるかどうか、さらに、有効にされる場合、どの程度、またはどのような深度の推移的連鎖委譲が、推移的連鎖因子７１２によって許されるかを制御することも可能である。推移的連鎖とは、主体＃１  ６０４が、権利付与能力６０８を主体＃２  ６０６にさらに転送する、または委譲することを許されるかどうかを指す。さらに委譲する、または委譲することが許される場合、主体＃１  ６０４は、主体＃２  ６０６に権限委譲アサーション６１４を発行することを可能にされる。すると、主体＃２  ６０６は、何らかの第３の主体に委譲許可アサーション６１６を発行することを可能にされる。この推移的連鎖委譲は、図９および図１０を特に参照して、本明細書の後段でさらに説明される。
【００７２】
図８は、委譲機構の権限委譲アサーションに関する例示的なアサーションフォーマット８００を示すブロック図である。権限委譲アサーション６１４の概念は、委譲機構６００の一部として前段で概説され、説明された（図６を参照して）。権限委譲アサーション６１４が、アサータから第１の主体になど、ある側から別の側に権利付与能力６０８を転送することによって、委譲を開始する。
【００７３】
図５の例示的なアサーション・フォーマットの一部分が、図８に再現されている。しかし、主体部分５０２は、アサータ部分８０２で置き換えられ、複数の、つまり、「ｍ」個の制約５１２に関する容量が明示されている。「アサータ」、「主体＃１」、および「主体＃２」という命名法は、委譲シナリオにおけるそれぞれのパーティの区別を容易にするように本明細書で利用されることに留意されたい。しかし、各パーティは、説明されるセキュリティ言語の全体的なスキームにおいて、基本的に、事実上、主体であると見なされることが可能である。
【００７４】
このため、説明される実施形態において、例示的なアサーション・フォーマット８００は、アサータ部分８０２、述べる部分５０４、事実部分５０８、場合部分５１０、「ｎ」個の条件付き事実1...n部分５０８（１．．．ｎ）、および「ｍ」個の制約1...m部分５１２（１．．．ｍ）を含む。事実５０８は、委譲−指令動詞５２０を含めることによって委譲事実として実現される。例には、例として、限定としてではなく、「アサートできる」、「述べることができる」、「公言できる」、「主張できる」などが含まれた。本明細書の後段で説明される一部の委譲関連の表明の例は、一般性を失うことなしに、「アサートできる」という特定の例を使用する。
【００７５】
委譲事実５０８は、主体＃１部分５０２（１）、委譲−指令動詞５２０、および委譲された事実部分５０８（Ｄ）を含む。委譲された事実５０８（Ｄ）は、主体＃２部分５０２（２）、動詞句部分５１６、リソース部分８０４、および事実修飾子1...f部分８０６（１．．．ｆ）を含む。このため、例示的なアサーション・フォーマット８００は、以下の形態に適合することが可能である。すなわち、  
事実1、事実2、．．．、事実n、制約1...mの場合、アサータが、「主体２  動詞−句  リソース  事実−修飾子1...f」という主体１  委譲−指令−動詞を述べる（assertor says principal1 delegation-directive-verb "principal2 verb-phrase resource fact-qualifier1...f" if fact1,fact2, ..., factn,constraint1...m）。
【００７６】
このため、説明される実施形態において、プログラムは、委譲機構のためのＡＰＩ（アプリケーション・プログラミング・インターフェース）を含むことが可能である。委譲機構は、アサータによって開始され、第２の主体が少なくとも１つのアサーションを行うように、第１の主体が、第２の主体にある権利を委譲することを可能にする。委譲機構は、この委譲が、特に制御されることを可能にする。例えば、委譲機構は、委譲が、因子７０２〜７１２のいずれかを使用して制御されることを可能にすることができる。
【００７７】
例えば、委譲機構６００は、アサータが、第１の主体があるアサーションを行う権利を委譲することができるようにするには、第１の主体が有すべき少なくとも１つの属性を指定すること、および／または第２の主体があるアサーションを行うことを許されるようにするには、第２の主体が有すべき少なくとも１つの属性を指定することを可能にすることができる。例えば、権限委譲アサーション６１４が、「主体１が、（属性名、属性値）を有する、または主体２が、（属性名、属性値）を有する」などの、条件付き事実５０８（１）を含むことが可能である。
【００７８】
別の例として、委譲機構６００は、アサータが、第１の主体がある特定のリソースに関してある能力を有する場合だけにしか、第１の主体があるアサーションを行う権利を委譲することができないこと、および／または第２の主体がある特定のリソースに関してある能力を有する場合だけにしか、第２の主体があるアサーションを行うことを許されないことを指定できるようにすることが可能である。例えば、権限委譲アサーション６１４が、以下のような条件付き事実５０８（１）を含むことが可能である。すなわち、主体１が、リソース＿ａを読む（ｐｒｉｎｃｉｐａｌ１  ｒｅａｄ  ｒｅｓｏｕｒｃｅ＿ａ）、または主体２  動詞  Ｆｏｏ（ｐｒｉｎｃｉｐａｌ２  ｖｅｒｂ  Ｆｏｏ）。
【００７９】
さらに別の例として、委譲機構６００は、アサータが、委譲または権利が執行されることが可能な仕方を制限する少なくとも１つの事実修飾子を指定することを可能にすることができる。例えば、権限委譲アサーション６１４が、以下のような委譲された事実５０８（Ｄ）を含むことが可能である。すなわち、接続性＿機構＝ＬＡＮ（ｃｏｎｎｅｃｔｉｖｉｔｙ＿ｍｅｃｈａｎｉｓｍ＝ＬＡＮ）などの制約５１２を伴う、「主体２が、リソース＿ｂ［接続性＿機構］を書き込む（"principal2 write resource_b[connectivity_mechanism]"）」。
【００８０】
このため、説明される実施形態において、一般的な機構は、委譲されたアクセス権に対してきめ細かい制御が表現されることを可能にする。例として、限定としてではなく、委譲されたアクセス権に対するきめ細かい制御は、以下に関連して表現されることが可能である。すなわち、  
アクセスの委譲が行われているリソース、  
それらのリソースに対して執行されることが可能な権利、  
それらの権利が委譲されている主体、  
委譲先が、それらのアクセス権、またはそれらのアクセス権のサブセットを（例えば、推移的連鎖を介して）さらに委譲する能力、および  
委譲されたアクセス権の執行に対する（例えば、事実修飾子を介した）環境上の制限（例えば、期間、ロケーションなど）。
【００８１】
本明細書で説明される委譲機構は、委譲ポリシーと委譲権の両方の指定を許す、一定の方式の宣言型の表現（uniform declarative representation）を使用して、これらの委譲制御因子を表現することができる。図５および図８に示され、前述したとおり、セキュリティ・アサーションの一般的な形態を活用して、制御された委譲ポリシーの表現を可能にする権限委譲アサーション６１４に関する例示的な形態が作成される。例示的なフォーマットが、便利な参照のために以下に繰り返される。すなわち、
事実1、事実2、．．．、事実n、制約1...mの場合、アサータが、「主体２  動詞−句  リソース  事実−修飾子1...f」という主体１  委譲−指令−動詞を述べる（assertor says principal1 delegation-directive-verb "principal2 verb-phrase resource fact-qualifier1...f" if fact1,fact2, ..., factn,constraint1...m）。
【００８２】
この形態において、アサータは、行われるべき委譲を許可するオーソリティであり、主体１が、委譲を行うことができる可能な委譲元であり、主体２は、委譲先である。
【００８３】
いくつかの例示的な委譲ポリシーには、以下が含まれる。すなわち、  
（１）Ｂが、８時間にわたる、ファイルＦｏｏに対する読取りアクセスを、任意の主体に委譲する権利が、以下のように表現されることが可能である。すなわち、  
（ｔ２−ｔ１）≦８時間である場合、Ｂが、「ｘは、Ｆｏｏ［ｔ１，ｔ２］を読む」とアサートできる、とＡが述べる。  
変数「ｘ」が結び付くことが可能な値を制御することによって、委譲先となることが可能な主体のセットは、制限されることが可能である。等式制約および不等式制約が、変数「ｘ」に適用されることが可能である。  
（２）主体ｐが、主体ｐがリソースＦｏｏに対して保持する権利を、他の主体に委譲する権利が、以下のように表現されることが可能である。すなわち、  
ｐ  ｖ  Ｆｏｏである場合、ｐが、「ｘ  ｖ  Ｆｏｏ」とアサートできる、とＡが述べる。  
Ｂが、Ｆｏｏ読む｜書き込む（Ｂ  ｒｅａｄ｜ｗｒｉｔｅ  Ｆｏｏ）が真である場合、前述の委譲ポリシーは、Ｂが、「ｘがＦｏｏを読む｜書き込む（ｘ  ｒｅａｄ｜ｗｒｉｔｅ  Ｆｏｏ）」とアサートできる、とＡが述べることを暗示する（意味する）。
【００８４】
前述の例などの、委譲ポリシーが、アサートされる能力と組み合わされて、完全な委譲が作成される。図６の例示的なシナリオでは、委譲許可アサーション６１６が、アサートされる能力である。前述のポリシー（１）が与えられる、「Ｃが、Ｆｏｏ［０８００，１２００］を読む、とＢが述べる（Ｂ  ｓａｙｓ  Ｃ  ｒｅａｄ  Ｆｏｏ  ［０８００，１２００］）」と、Ｂがアサートする場合、Ｃが、示された期間中、Ｆｏｏを読むことを許されるものと、Ａは信じることになる。同様に、前述のポリシー（２）、および２つのアサーション、「ＢがＦｏｏを読む、とＡが述べる（Ａ  ｓａｙｓ  Ｂ  ｒｅａｄ  Ｆｏｏ）」および「ＣがＦｏｏを読む、とＢが述べる（Ｂ  ｓａｙｓ  Ｃ  ｒｅａｄ  Ｆｏｏ）」を所与として、Ｃが、Ｆｏｏを読むことを許されるものと、Ａは信じることになる。
【００８５】
委譲権の推移的連鎖に関して、委譲先が、委譲先に与えられているアクセス権をさらに委譲する能力を制御するための機構も説明される。アサーションの以下の例示的なセットが、この概念を説明するのに提示される。すなわち、
（３）Ｂが、「ｘが、Ｆｏｏを読む」とアサートできる、とＡが述べる（Ａ  ｓａｙｓ  Ｂ  ｃａｎ  ａｓｓｅｒｔ“ｘ  ｒｅａｄ  Ｆｏｏ”）、
（４）Ｃが、「ｘが、Ｆｏｏを読む」とアサートできる、とＢが述べる（Ｂ  ｓａｙｓ  Ｃ  ｃａｎ  ａｓｓｅｒｔ“ｘ  ｒｅａｄ  Ｆｏｏ”）、および
（５）Ｄが、Ｆｏｏを読む、とＣが述べる（Ｃ  ｓａｙｓ  Ｄ  ｒｅａｄ  Ｆｏｏ）。
【００８６】
問題は、Ｂが、Ｆｏｏに対する読取りアクセスを委譲する権利を有するとだけ言明するアサーション（３）に基づいて、Ｄが、Ｆｏｏを読むことを許可されるとＡが信じるか否かである。しかし、この例において、Ｂは、（４）Ｃが、Ｆｏｏに対する読取りアクセスを委譲する権利を有するとアサートしている。
【００８７】
制御されていない連鎖を許す場合、これらのステートメントに基づく論理的推論を介して、その問題に対する答えは、「はい（yes）」である。この肯定的な答えは、アサーション（４）および表明（５）を使用する推論により、「Ｄが、Ｆｏｏを読む、とＢが述べる（Ｂ  ｓａｙｓ  Ｄ  ｒｅａｄ  Ｆｏｏ）」が有効であると結論付けることができるためである。その推論、およびアサーション（３）に基づき、「Ｄが、Ｆｏｏを読む、とＡが述べる」が有効であると結論付けることができる。反対に、推論される事実を介した論理的連鎖を許さない場合、この問題への答えは、「いいえ」である。連鎖が許されない場合、アサーション（３）と、アサーション（４）またはアサーション（５）との直接の組合せを介して、ただし、（４）と（５）の両方を介してではなく、結論に達することしかできない。
【００８８】
説明される実施形態において、例示的な連鎖型委譲機構は、委譲−指令動詞（例えば、表明できる）を変更する「深度」標識または「深度」パラメータを導入することによって、このタイプの論理的連鎖に対する正確な制御を可能にする。論理的連鎖を許さないことを所望する場合、深度標識は、０という値を有し、表明（３）は、以下のように書き直される。すなわち、  
（３．１）Ｂが、「ｘが、Ｆｏｏを読む」と表明0できる、とＡが述べる（Ａ  ｓａｙｓ  Ｂ  ｃａｎ  ａｓｓｅｒｔ0“ｘ  ｒｅａｄ  Ｆｏｏ”）。
【００８９】
代替として、Ｂが、もう１つだけの主体に委譲を渡すことを明示的に許すことを所望する場合、アサーション（３）、（４）、および（５）は、１という値を有する深度標識を使用して、以下のように書き直される。すなわち、
（３．２）Ｂが、「ｘが、Ｆｏｏを読む」と表明1できる、とＡが述べる（Ａ  ｓａｙｓ  Ｂ  ｃａｎ  ａｓｓｅｒｔ1“ｘ  ｒｅａｄ  Ｆｏｏ”）、
（４．２）Ｃが、「ｘが、Ｆｏｏを読む」と表明0できる、とＢが述べる（Ｂ  ｓａｙｓ  Ｃ  ｃａｎ  ａｓｓｅｒｔ0“ｘ  ｒｅａｄ  Ｆｏｏ”）、および
（５．２）Ｄが、Ｆｏｏを読む、とＣが述べる（Ｃ  ｓａｙｓ  Ｄ  ｒｅａｄ  Ｆｏｏ）。
深度標識は、アサーション（４．２）において０という値に設定されて、Ｃが、Ｃに委譲されているアクセス権を渡すことを許されないことを強いる。Ｃが、そうすることを許されるとすると、アサーション（３．２）に関してアサーションが有効であることを確立するのに必要とされる論理的推論の連鎖は、１という、示された、許された深度を超えることになる。このアプローチでは、委譲されたアクセス権を他の主体に渡す非有界の能力を可能にするのに、無限という深度標識値が、使用されることが可能である。
【００９０】
このため、例示的な実施形態において、深度標識は、０、無限、または任意の正の整数に設定されることが可能である。例示的な対応するシンタックスは、それぞれ、アサート0できる（can assert0）、アサート∞できる（can assert∞）、およびアサートnできる（can assertn）である。このことにより、非有界の委譲（例えば、無限を使用して）、または所望される任意の推移的連鎖深度（例えば、０、１、２．．．）への正確な設定を使用して有界の委譲、が可能になる。
【００９１】
しかし、別の例示的な実施形態では、深度標識は、０または無限にだけ設定されることが可能である。このことにより、（ｉ）委譲連鎖の完全な防止（例えば、０値を使用して）、または（ｉｉ）非有界の委譲が可能になる。この代替の例示的な実施形態において、有界であるが、０ではない連鎖は、後段で説明される、入れ子の委譲−指令動詞を使用して、可能にされことになる。
【００９２】
より具体的には、「アサートできる」実施形態を使用して、連鎖型委譲が、以下の形態に適合するアサーションを使用する入れ子構成を使用して、実装されることが可能である。すなわち、  
ｚが、グループ名＝ｇを有する、とｙがアサート0することができる、とｘがアサート0することができる、とＢがアサート0することができる、とＡが述べる（A says B can assert0 x can assert0 y can assert0 z possesses group name=g）。  
この先行する例は、明示的な３レベルの委譲である。委譲−指令された動詞の数、つまり、入れ子構成のレベルが、連鎖深度を確立する。深度標識の使用を減らすのに、明示的な指示が存在しない場合、連鎖なし、または非有界の連鎖が、デフォルトの推移的連鎖と考えられることが可能である。また、入れ子構成が、正の整数値の深度標識と一緒に使用されることも可能である。他の組合せ、または派生形態が実装されることも可能である。
【００９３】
図９は、機能の見地からの例示的な連鎖型委譲機構６００Ｃを、例示的な連鎖型委譲シナリオとともに示すブロック図である。図示されるとおり、例示的な連鎖型委譲シナリオは、アサータ６０２、主体＃１  ６０４（１）、主体＃２  ６０４（２）、．．．、主体＃ｄ  ６０４（ｄ）を含む。変数「ｄ」は、連鎖深度に対応する整数である。また、この委譲シナリオは、主体６０６、権利付与能力６０８、および権利６１０も含む。
【００９４】
説明される実施形態において、アサータ６０２が、権利付与能力６０８を主体＃１  ６０４（１）に委譲する。主体＃１  ６０４（１）は、権利付与能力６０８を主体＃２  ６０４（２）に委譲する。主体＃２  ６０４（２）は、場合により、省略記号で示されるとおり、他の中間の主体６０４を介して、権利付与能力６０８を主体＃ｄ  ６０４（ｄ）に委譲する。すると、主体＃ｄ  ６０４（ｄ）は、権利６１０を主体６０６に与える。連鎖型委譲機構６００Ｃを可能にするセキュリティ言語実施形態の例示的な一般的なアプローチは、本明細書の前段で説明した（例えば、前段の推移的連鎖の説明および例、ならびに一般的な権限委譲アサーション・フォーマット８００）。連鎖型委譲機構に特有である例示的なフォーマット・アプローチが、図１０を参照して後段で説明される。
【００９５】
図１０は、連鎖型委譲機構に関する２つの例示的なフォーマット・アプローチ１０００を示すブロック図である。フォーマット１０００（１）は、ある深度標識を有するある委譲フォーマットを例示し、フォーマット１０００（２）は、入れ子構成を利用する委譲フォーマットを例示する。単に例として、委譲−指令動詞は、例示的なフォーマット・アプローチ１０００における「アサートできる」実施形態を使用して実現される。
【００９６】
より具体的には、フォーマット１０００（１）は、主体＃１部分５０２（１）、アサートできる部分５２０、および委譲された事実部分５０８（Ｄ）を含む。また、フォーマット１０００（１）は、連鎖深度標識１００２も含む。連鎖深度標識１００２は、アサートできる部分５２０に関連付けられる。連鎖深度標識１００２は、許された推移的連鎖深度を確立する任意の値をとることができる。前段からの例には、０、無限、および正の整数が含まれる。
【００９７】
フォーマット１０００（２）は、主体＃１部分５０２（１）、アサートできる部分５２０、主体＃２部分５０２（２）、アサートできる部分５２０、主体＃３部分５０２（３）、表明できる部分５２０、および委譲された事実部分５０８（Ｄ）を含む。図示されていないものの、フォーマット１０００（２）の各アサートできる部分５２０は、連鎖深度標識１００２に関連付けられることも可能である。例えば、そのような連鎖深度標識１００２が、０に設定されて、フォーマット１０００（２）のそれぞれの個別のアサートできる部分５２０が、推移的連鎖を（例えば、入れ子構成によって許される連鎖を超えて）許さないことが示されることが可能である。
【００９８】
図１１は、権限委譲アサーションを作成するための方法の例を示す流れ図１１００である。流れ図１１００は、７つのブロック１１０２〜１１１４を含む。流れ図１１００のアクションは、他の環境において、様々なハードウェア／ソフトウェア／ファームウェアの組合せで実行されることが可能であるももの、図１〜図１０の特徴、構成要素、および態様のいくつかを使用して、この方法の例が示される。
【００９９】
説明される実施形態において、ブロック１１０２で、委譲元主体および委譲先主体が指定される。例えば、主体＃１  ６０４および主体＃２  ６０６が、委譲機構６００の主体因子７０２で識別されることが可能である。
【０１００】
ブロック１１０４で、ある動詞句が指定される。例えば、ある動詞句が、動詞句因子７０４で指定されることが可能である。ブロック１１０６で、あるリソースが指定される。例えば、ある特定のリソース１１０が、リソース因子７０６で指定されることが可能である。この動詞句とリソースが組み合わされて、主体＃１  ６０４から主体＃３  ６０６に与えられることが可能な権利が表されることが可能である。
【０１０１】
ブロック１１０８で、ある連鎖深度が指定される。例えば、推移的連鎖因子７１２によれば、連鎖深度は、連鎖深度標識１００２（アサーション・フォーマット・アプローチ１０００（１）に適合して）、および／または複数の委譲−指令動詞の入れ子の表現（アサーション・フォーマット・アプローチ１０００（２）に適合して）によって指定されることが可能である。
【０１０２】
ブロック１１１０で、ある事実修飾子が指定される。例えば、少なくとも１つの環境上の制限、または他の事実修飾子因子７０８が、リソースに関する任意の権利に適用されるように示されることが可能である。図１１に示されていないものの、いずれか、または両方の主体に関する所与の属性が、指定される（さらに、ブロック１１１２の権限委譲アサーションに組み込まれる）ことも可能である。例えば、ある委譲が、属性因子７１０で許されるのに、主体＃１  ６０４および／または主体＃２  ６０６が、所与の属性を有さなければならないことが、指定されることが可能である。
【０１０３】
ブロック１１１２で、指定された因子を有する権限委譲アサーションが、委譲−指令動詞を使用して作成される。例えば、アサーション・フォーマット８００に適合し、委譲−指令動詞部分５２０を含む権限委譲アサーション６１４が、指定された因子７０２〜７１２のいずれかを使用して作成されることが可能である。例えば、主体＃１部分５０２（１）、主体＃２部分５０２（２）、動詞句部分５１６、リソース部分８０４、および事実修飾子1...f部分８０６（１．．．ｆ）がそれぞれ、権限委譲アサーション６１４の一部として含められることが可能である。所与の属性が、１つまたは複数の条件付き事実1...n５０８（１．．．ｎ）を使用する、識別された主体が有する必要があるものとして、指定されることが可能である。
【０１０４】
ブロック１１１４で、権限委譲アサーションが、信頼−許可ポリシーに追加される。例えば、権限委譲アサーション６１４が、信頼−許可ポリシー２２２に追加されることが可能である。その後、委譲許可アサーション６１６、および／または他の任意の妥当なアサーションが組み合わされて、許可コンテクスト２１２内のアサーション・コンテクストにされることが可能である。
【０１０５】
説明される実施形態において、委譲許可アサーション６１６は、委譲が適切に実施されるのに、少なくとも、特定のリソース、ある動詞句、ならびに対応する委譲された事実５０８（Ｄ）（図８の）の中で指定された委譲先主体を、委譲許可アサーション６１６の中にやはり含む。次に、許可照会テーブル２２４からの許可照会が、許可エンジン２１８の中でアサーション・コンテクストに関連して評価されて、その特定のリソース１１０に関する許可判定が決定される。
【０１０６】
４つの例示的な委譲関連のポリシーイディオムが、以下に提示される。各イディオムは、例示的な委譲タイプ７１４（図７の）に対応する。具体的には、属性ベースの委譲７１４（１）例、制約された委譲７１４（２）例、深度有界の委譲７１４（３）例、および幅有界の委譲７１４（４）例が、提示される。
【０１０７】
属性ベースの委譲タイプ７１４（１）：属性ベース（ＩＤベースではなく）の許可は、ＩＤが、互いに最初に知られていないパーティ間の共同作業を可能にする。次に、ある対象が、ある属性（学生であるなどの）を保持するとアサートするオーソリティが、他のパーティに委譲されることが可能であり、これらのパーティは、ＩＤによってではなく、属性によって特徴付けられることが可能である。
【０１０８】
以下の例において、学生は、割引を受ける資格がある。この学生属性の有効期限日が、ある制約に対して検査されることが可能である。この学生属性に対するオーソリティが、大学属性の保持者に委譲され、この大学属性に対するオーソリティが、知られている主体である教育委員会に委譲される。  
Ａｄｍｉｎは、  
ｘが、ｄａｔｅまで学生であり、  
ｃｕｒｒｅｎｔＴｉｍｅ（）≦ｄａｔｅである場合、  
ｘが、割引を受ける資格があると述べる（Admin says x is entitled to discount if
x is a student till date,  
currentTime()≦date）  
Ａｄｍｉｎは、  
ｕｎｉｖが、大学である場合、  
ｕｎｉｖが、ｘが、ｄａｔｅまで学生であるとアサート∞できると述べる（Admin says univ can assert∞ x is student till date if  
univ is a university）  
Ａｄｍｉｎは、ＢｏａｒｄＯｆＥｄｕｃａｔｉｏｎが、ｕｎｉｖが、大学であるとアサート∞できると述べる（Admin says BoardOfEducation can assert∞ univ is a university）
【０１０９】
制約された委譲タイプ７１４（２）：委譲元が、委譲された事実のパラメータを制限することを所望することが可能である。このことは、制約を使用して行われることが可能である。以下の例において、ＳＴＳに、８時間を超えない指定された有効期間にわたって何らかのリソースにアクセスするためのチケットを発行する権利が与えられる。  
Ａｄｍｉｎは、ｔ２−ｔ１≦８時間である場合、ＳＴＳが、ｘが、ｔ１からｔ２までアクセスを有するとアサート∞できると述べる（Admin says STS can assert∞ x has access from t1 till t2 if t2-t1≦8 hours）
前段のアサーションの中で指定される委譲深度は、無制限であり、したがって、ＳＴＳは、同一の権利を何らかのＳＴＳ２に委譲することができる。以下の、ＳＴＳのアサーションでは、Ａｄｍｉｎは、せいぜい８時間の有効期間を有する、ＳＴＳ２によって発行されたチケットを受け入れ、ただし、開始日は、０１／０１／２００７より後である。
ＳＴＳは、ｔ１≧０１／０１／２００７である場合、ＳＴＳ２が、ｘが、ｔ１からｔ２までアクセスを有するとアサート0できると述べる（STS says STS2 can assert0 x has access from t1 till t2 if t1≧01/01/2007）
【０１１０】
深度有界の委譲タイプ７１４（３）：説明される実施形態において、表明できるキーワードの委譲深度添え字は、０（再委譲なし）または∞（無制限の再委譲）であることしか可能でない。それでも、そのような例示的なセキュリティ言語は、表明できるを入れ子にすることによって、任意の固定の整数委譲深度を表現することができる。以下の例において、アリスが、友人である事実に対する権限をボブに委譲し、ボブが、さらに１レベル、再委譲することを許す。  
アリスは、ボブが、ｘが、友人であると表明0できると述べる（Alice says Bob can assert0 x is a friend）  
アリスは、ボブが、ｘが、ｙが、友人であると表明0できると表明0できると述べる（Alice says Bob can assert0 x can assert0 y is a friend）
【０１１１】
ボブが、「ボブは、チャーリーが、ｘが、友人であると表明∞できると述べる（Bob says Charlie can assert∞ x is a friend）」という表明で、チャーリーに再委譲するものと想定されたい。すると、「アリスは、イブが、友人であると述べる（Alice says Eve is a friend）」が、「チャーリーは、イブが、友人であると述べる（Charlie says Eve is a friend）」の当然の帰結となる。アリスは、これ以上長い連鎖をまったく承認しないので、アリスは（ボブとは異なり）、チャーリーが、  
チャーリーは、ドリスが、ｘが、友人であると表明0できると述べる（Charlie says Doris can assert0 x is a friend）  
を使用して、再委譲することを許さない。
【０１１２】
さらに、チャーリーは、委譲深度制限が、条件付き事実にも適用されるため、以下のトリックを使用して、この制限を回避することもできない。  
チャーリーは、ｘが、ドリスの友人である場合、ｘが、友人であると述べる（Charlie says x is a friend if x is Doris' friend）  
チャーリーは、ドリスが、ｘが、ドリスの友人であると表明0できると述べる（Charlie says Doris can assert0 x is Doris' friend）
【０１１３】
したがって、ｘが、友人であるという動詞句に言及するアリスおよびボブによるアサーションが、前段で列挙される表明だけであるものと想定される場合、アリスが、ｘが、友人であると述べる（Alice says x is a friend）という照会の結果は、チャーリーの表明だけに依存し、例えば、ドリスのアサーションには依存しないことが示されることが可能である。
【０１１４】
幅有界の委譲タイプ７１４（４）：アリスが、友人である事実に対する権限をボブに委譲することを望むものと想定されたい。アリスは、委譲連鎖の長さは気にしないが、連鎖におけるすべての委譲元が、何らかの特性を満たすこと、例えば、ｆａｂｒｉｋａｍ．ｃｏｍからの電子メール・アドレスを有することを要求する。以下の表明は、０という添え字を有する表明できるキーワードを使用して、制御された推移的委譲を符号化することによって、このポリシーを実装する。委譲元である属性を有する主体は、アリスによって、友人である事実を表明すること、およびこの属性を推移的に再委譲することを許可されるが、ただし、マッチする電子メール・アドレスを有する主体の間に限って許可される。
【０１１５】
アリスは、ｘが、委譲元である場合、ｘが、ｙが、友人であると表明0できると述べる（Alice says x can assert0 y is a friend if x is a delegator）  
アリスは、ボブが、委譲元であると述べる（Alice says Bob is a delegtor）  
アリスは、  
ｘが、委譲元であり、  
ｙが、電子メール、ｅｍａｉｌを有し、  
ｅｍａｉｌが、*＠ｆａｂｒｉｋａｍ．ｃｏｍとマッチする場合、  
ｘが、ｙが、委譲元であると表明0できると述べる（Alice says x can assert0 y is a delegator if  
x is a delegator,  
y possesses Email email,  
email matches *@fabrikam.com）
【０１１６】
図１〜図１１のデバイス、アクション、態様、特徴、機能、プロシージャ、モジュール、データ構造、プロトコル、構成要素などは、複数のブロックに分割された図において示される。しかし、図１〜図１１が説明され、及び／または示される順序、相互接続、相互関係、レイアウトなどは、限定として解釈されることを意図しておらず、いくつものブロックが、権利の委譲を制御するための１つまたは複数のシステム、方法、デバイス、プロシージャ、媒体、装置、ＡＰＩ、プロトコル、構成などを実装する任意の仕方で、変更される、組み合わされる、再構成される、増補される、省かれることなどが可能である。
【０１１７】
システム、媒体、デバイス、方法、プロシージャ、装置、機構、スキーム、アプローチ、プロセス、構成、およびその他の実施形態が、構造上、論理上、アルゴリズム上、および機能上の特徴および／または図に特有の言葉で説明されてきたが、添付の特許請求の範囲において規定される本発明は、前述した特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、前述した特定の特徴および動作は、特許請求の範囲を実装する例示的な形態として開示される。
【図１】
0005535631.tif 000002
【図２】
0005535631.tif 000003
【図３】
0005535631.tif 000004
【図４】
0005535631.tif 000005
【図５】
0005535631.tif 000006
【図６】
0005535631.tif 000007
【図７】
0005535631.tif 000008
【図８】
0005535631.tif 000009
【図９】
0005535631.tif 000010
【図１０】
0005535631.tif 000011
【図１１】
0005535631.tif 000012