(57)【特許請求の範囲】
【請求項１】
第１のコンピューティングデバイスがリソース所有者を表し、第２のコンピューティングデバイスがリソース要求者を表す通信ネットワークにおいて、リソース所有者は、イベントの発生を検出し、イベント発生は、リソース所在地に格納されるリソース所有者の１つまたは複数のリソースにアクセスする要求を表し、
リソース所有者は、イベント発生に応答して、リソース要求者に許可トークンを送信し、許可トークンは、リソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをすること
を含み、
許可トークンは、
リソース要求者を認証するためにリソース所在地によって使用される方法と、リソース要求者を認証するためにリソース所在地によって使用される方法の強度とのうちの少なくとも１つを含む１つ以上のフィールドと、
１つ以上のフィールドにわたって計算され、リソース所有者の秘密鍵を利用して計算されている署名と、
を含む検証可能な構造を備える、方法。
【請求項２】
イベント発生が、リソース要求者およびリソース所有者が、プル通信方法によって要求および応答を交換するような、リソース所有者によるリソース要求者からのリソース要求の受信である、請求項１に記載の方法。
【請求項３】
イベント発生が、リソース要求者とリソース所有者との間の通信方法が、プッシュ通信方法であるような、リソース要求者からの明示的な要求ではなくアプリケーションプログラムに関連するトリガイベントの発生である、請求項１に記載の方法。
【請求項４】
少なくとも別のリソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、別の許可トークンが、少なくとも別のリソース要求者によってリソース所在地に提示し得るように、リソース所有者により委譲される許可の証明が、リソース所有者とさらに通信することなく、リソース要求者から少なくとも別のリソース要求者に譲渡可能である、請求項１に記載の方法。
【請求項５】
許可トークンを取得すること、ならびに、１つもしくは複数の要求されるリソースへのアクセスを得るための許可トークンの提示が、既存のアプリケーションプロトコルに結合される、請求項１に記載の方法。
【請求項６】
メモリと、メモリに結合され、請求項１に記載のステップを実施するように構成されるプロセッサとを備える、リソース所有者を表す第１のコンピューティングデバイスを実施するための、装置。
【請求項７】
第１のコンピューティングデバイスがリソース所有者を表し、第２のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の１つまたは複数のリソースにアクセスする要求を表す通信ネットワークにおいて、
リソース要求者は、イベント発生に応答して、リソース所有者により送信される許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをすることを含み、
許可トークンは、
リソース要求者を認証するためにリソース所在地によって使用される方法と、リソース要求者を認証するためにリソース所在地によって使用される方法の強度とのうちの少なくとも１つを含む１つ以上のフィールドと、
１つ以上のフィールドにわたって計算され、リソース所有者の秘密鍵を利用して計算されている署名と、
を含む検証可能な構造を備える、方法。
【請求項８】
リソース所在地が、リソース要求者が許可トークンをリソース所在地に提示する前、および、リソース要求者が許可トークンをリソース所在地に提示した後の少なくとも１つで、リソース要求者を認証することをさらに含む、請求項７に記載の方法。
【請求項９】
リソース所在地が、１つまたは複数の要求されるリソースに関してアクションを行う前に、リソース要求者により提示される許可トークンを検証することをさらに含む、請求項７に記載の方法。
【請求項１０】
第１のコンピューティングデバイスがリソース所有者を表し、第２のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の１つまたは複数のリソースにアクセスする要求を表し、リソース要求者が、イベント発生に応答して、リソース所有者により送信される許可トークンを受信する通信ネットワークにおいて、
リソース所在地は、許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース所有者によりリソース要求者に委譲される許可の証明の働きをすることを含み、
許可トークンは、
リソース要求者を認証するためにリソース所在地によって使用される方法と、リソース要求者を認証するためにリソース所在地によって使用される方法の強度とのうちの少なくとも１つを含む１つ以上のフィールドと、
１つ以上のフィールドにわたって計算され、リソース所有者の秘密鍵を利用して計算されている署名と、
を含む検証可能な構造を備える、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、通信ネットワークに関し、より詳細には、リソース所有者以外のエンティティによる保護されたリソースへのアクセスを必要とするアプリケーションを使用可能にするための、権限のセキュアな動的委譲のために通信ネットワークで使用するための技法に関する。
【背景技術】
【０００２】
本節では、本発明のより良い理解を容易にするのに役立ち得る態様を紹介する。したがって、本節の記載は、この観点で読まれるべきであり、何が従来技術であるか、または何が従来技術でないかに関する自認と理解されるべきではない。
【０００３】
ワールドワイドウェブなどの通信ネットワークを介して利用可能な様々なファシリティは、ユーザが自分自身のアプリケーションまたはウェブページを作成することを可能にする。一例が、「マッシュアップ」として知られており、それは、新しいサービスまたはアプリケーションを作成するために、２つまたはより多くのソースからのデータまたは機能性を使用する、または組み合わせるウェブページまたはアプリケーションである。
【０００４】
しかしながら、ユーザが、あるソースに対する自分の資格データ（ユーザ名およびパスワード）を別のソースに与えることを要求され、したがって、ソース間で情報を露出し、一方のソースのフルアクセスを他方のソースに与える場合に、問題が生じる。これは、ユーザにとって望ましくない場合がある。
【０００５】
オーオース（ＯＡｕｔｈ）として知られているプロトコルは、この問題に対する解決策を提供しようとするものである。一般に、オーオースプロトコル（ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／を参照）は、ユーザが、自分のパスワードを共有することなく、自分のウェブリソースへのアクセスを第三者に提供することを可能にする。しかしながら、このプロトコルには、いくつかの限界および弱点が存在する。第１に、このプロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に関係するので、非ウェブアプリケーションに適用可能ではない。第２に、このプロトコルは、ＨＴＴＰリダイレクションの使用に依存するので、フィッシング攻撃に対して脆弱である。さらに、このプロトコルは、委譲される許可を取得するために複数の往復を必要とし、アプリケーションの性能のために最適ではない。最後に、このプロトコルは、２つ以上のタイプの委譲証明、および度重なる暗号署名を必要とする証明体系を使用するので、必要以上に複雑である。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、これらおよび他の欠点を克服する権限委譲に対する改善された手法が求められている。
【課題を解決するための手段】
【０００８】
本発明の実施形態は、リソース所有者以外のエンティティによる保護されたリソースへのアクセスを伴う、（例えば、ワールドワイドウェブ、または次世代ネットワーク内の）通信ネットワーク上のアプリケーション（例えば、マッシュアップおよびサードパーティアプリケーション）を使用可能にする、権限の動的委譲のための一般的、効果的、かつセキュアな方法を提供する。
【０００９】
第１の態様では、方法は、以下のステップを含む。第１のコンピューティングデバイスがリソース所有者を表し、第２のコンピューティングデバイスがリソース要求者を表す通信ネットワークにおいて、リソース所有者は、イベントの発生を検出し、イベント発生は、リソース所在地に格納されるリソース所有者の１つまたは複数のリソースにアクセスする要求を表す。リソース所有者は、イベント発生に応答して、リソース要求者に許可トークンを送信し、許可トークンは、リソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをする。
【００１０】
１つまたは複数の実施形態では、イベント発生は、リソース所有者によるリソース要求者からのリソース要求の受信であり得る（例えば、プル方法）。あるいは、イベント発生は、アプリケーションプログラムに関連するトリガイベントの発生であり得る（例えば、プッシュ方法）。リソース所在地は、第３のコンピューティングデバイスに存在し得る、または、それは、第１のコンピューティングデバイスに存在し得る。許可トークンは、検証可能な構造、有限の生存期間の１つまたは複数を有し得るとともに、リソース要求者を認証するための方法、または、リソース要求者を認証するための保証のレベルを指定することができる。検証可能な構造は、リソース所有者のデジタル署名を含み得る。許可トークンは、１つまたは複数の要求されるリソースによって実施されることが認可される、１つまたは複数のアクションを指定することができる。リソース要求者は、１回の往復で、リソース所有者から許可トークンを取得することができる。トークンを取得するための機構は、既存のアプリケーションプロトコルに結合され得る。１つまたは複数の要求されるリソースへのアクセスを得るための許可トークンの提示もまた、既存のアプリケーションプロトコルに結合され得る。
【００１１】
さらに、他のリソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、他のリソース要求者が、別の許可トークンをリソース所在地に提示し得るように、リソース所有者により委譲される許可の証明が、リソース要求者から少なくとも別のリソース要求者に譲渡され得る。他のリソース要求者により取得される他の許可トークンは、リソース要求者によりリソース所有者から直接取得される許可トークン内で指定されるアクション認可範囲のサブセットであるアクション認可範囲を指定することができる。一実施形態では、他のリソース要求者により取得される他の許可トークンは、リソース要求者を認証するための方法、または、リソース要求者を認証するための保証のレベルを変更しない。さらに、他の許可トークンは、最初に受信された許可トークンの修正された形式であり得るとともに、前のリソース要求者が、他のリソース要求者に許可トークンの修正された形式を送信する前に、修正を実施する。
【００１２】
さらに、リソース所有者は、リソース要求者に許可トークンを送信する前に、リソース要求者を認証することができる。
【００１３】
第２の態様では、方法は、以下のステップを含む。第１のコンピューティングデバイスがリソース所有者を表し、第２のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の１つまたは複数のリソースにアクセスする要求を表す通信ネットワークにおいて、リソース要求者は、イベント発生に応答して、リソース所有者により送信される許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをする。
【００１４】
１つまたは複数の実施形態では、リソース所在地は、リソース要求者が許可トークンをリソース所在地に提示する前に、リソース要求者を認証することができる。リソース所在地は、１つまたは複数の要求されるリソースに関してアクションを行う前に、リソース要求者により提示される許可トークンを検証する。さらに、リソース所在地は、リソース要求者が許可トークンをリソース所在地に提示した後に、リソース要求者を認証することができる。リソース要求者はさらに、少なくとも別のリソース要求者に、リソース所有者により委譲される許可の証明を譲渡することができる。そのような譲渡は、他のリソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、他のリソース要求者が、他の許可トークンをリソース所在地に提示し得るように、リソース要求者が、別の許可トークンを他のリソース要求者に送信することを含み得る。
【００１５】
第３の態様では、方法は、以下のステップを含む。第１のコンピューティングデバイスがリソース所有者を表し、第２のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の１つまたは複数のリソースにアクセスする要求を表し、リソース要求者が、イベント発生に応答して、リソース所有者により送信される許可トークンを受信する通信ネットワークにおいて、リソース所在地は、許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される１つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース所有者によりリソース要求者に委譲される許可の証明の働きをする。
【発明の効果】
【００１６】
有利には、本発明の動的権限委譲技法は、ウェブおよび非ウェブのアプリケーションに適用可能である。前記の本発明の技法は、ＨＴＴＰリダイレクションの使用に依存せず、委譲される許可を取得するために複数の往復を必要としない。さらに、前記の本発明の技法は、既存の権限委譲体系より複雑でない。
【００１７】
本発明のこれらおよび他の、目的、特徴および利点が、添付の図面と併せ読むべきその例示的な実施形態の以下の詳細な説明から明らかとなろう。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態による、セキュアな動的権限委譲に関与するエンティティを例示する図である。
【図２】本発明の実施形態による、許可トークンの基本構造の図である。
【図３】本発明の実施形態による、許可トークンを要求するためにリソース要求者により実施される方法の図である。
【図４】本発明の実施形態による、許可トークンに対する要求に応答してリソース所有者により実施される方法の図である。
【図５Ａ】本発明の実施形態による、保護されたリソースにアクセスするためにリソース要求者により実施される方法の図である。
【図５Ｂ】本発明の実施形態による、保護されたリソースにアクセスするためにリソース要求者により実施される方法の図である。
【図６Ａ】本発明の実施形態による、保護されたリソースにアクセスする要求に応答してリソース所在地により実施される方法の図である。
【図６Ｂ】本発明の実施形態による、保護されたリソースにアクセスする要求に応答してリソース所在地により実施される方法の図である。
【図７】本発明の実施形態による、別の許可トークンの構造の図である。
【図８】本発明の実施形態による、セキュアな動的権限委譲を実施するのに適した通信ネットワークのハードウェアアーキテクチャの図である。
【発明を実施するための形態】
【００１９】
本発明は、一例としての通信ネットワークおよび一例としてのアプリケーションに連関して、以下に例示される。しかしながら、本発明は、任意の特定のタイプの通信ネットワークまたはアプリケーションとともに使用することに限定されないことを理解されたい。開示される技法は、ウェブベースおよび非ウェブベースのネットワークを含む多種多様の通信ネットワークを用いた、ならびに、数多くのアプリケーションでの使用に適する。実際、開示される技法は、リソース所有者以外のエンティティによる保護されたリソースへのアクセスを伴う、通信ネットワーク上のアプリケーションを使用可能にするための、権限の動的委譲を提供することが望ましいことになる、任意の適した通信ネットワークにおいて、任意の適したアプリケーションとともに実施され得る。
【００２０】
本明細書では、「権限委譲」は、一般には、何らかのアイテムへのアクセスを有するある当事者が、別の当事者にそのアイテムにアクセスする認可を与えることを指す。例として、以下の実施形態では、リソース所有者は、許可トークンを使用して、何らかのリソースにアクセスする認可をリソース要求者に与える。その動作は、委譲が、プロビジョニングによってではなく、必要に応じてリアルタイムに行われるという意味で「動的」とみなされる。
【００２１】
本明細書では、「トークン」は、一般には、検証可能である、または認証され得る、アクセス制御の基準および動作を表す、データオブジェクトまたは構造を指す。
【００２２】
本明細書では、「リソース」は、一般には、通信ネットワークを介してアクセス可能であり得る任意のアイテム、データ、情報等を指す。
【００２３】
本明細書では、「アプリケーション」は、一般には、ユーザまたはエンティティが、１つまたは複数の具体的なタスクを実施するのに役立つように設計されたコンピュータソフトウェアを指す。
【００２４】
本明細書で解説されるように、本発明の例示的な実施形態は、それによって、リソース要求者が、リソース所有者から直接、リソース所在地内のそのリソースにアクセスする認可を動的に取得することができる技法を提供する。本明細書では、「所在地」は、一般には、通信ネットワークを介してアクセス可能な格納場所を指す。リソース要求者は、リソース所有者により委譲される許可の証明を提示することにより、リソース所在地内の保護されたリソースにアクセスすることができる。証明（すなわち許可トークン）は、検証可能な構造および有限の生存期間を有し、中でも、リソース要求者を認証するための方法または保証のレベルを指定する。リソース要求者は、要求応答ベースであり、既存のアプリケーションプロトコルに結合され得る機構によって、１回の往復で、リソース所有者から動的に許可トークンを取得することができる。例えば、リソーストークンの要求／応答は、メッセージのヘッダまたは本体または両方の一部として、ＨＴＴＰまたはセッション開始プロトコル（ＳＩＰ）によって搬送され得る。保護されたリソースへのアクセスを得るためにリソーストークンを提示するための機構は、要求応答ベースであり、既存のアプリケーションプロトコルに結合され得る。例えば、トークンは、メッセージのヘッダまたは本体の一部として、ＨＴＰＰまたはＳＩＰによって搬送され得る。
【００２５】
図１は、エンティティが、本発明の一実施形態による、セキュアな動的権限委譲に関与するシステム１００を例示する。示されるように、システムは、３つのタイプのアクタ、すなわち、リソース所有者１０２、リソース要求者１０４、およびリソース所在地１０６を必要とする。３つのアクタは、各個が、以下でさらに解説されるように、１つまたは複数のコンピューティングデバイスとして実施され得ることを理解されたい。
【００２６】
リソース所有者１０２は、（エンドユーザの場合では）ユーザエージェントとして、または（サービスプロバイダまたは組織の場合では）許可サーバとして実施され得る。同様に、リソース要求者１０４は、（エンドユーザの場合では）ユーザエージェントとして、または（サービスプロバイダまたは組織の場合では）アプリケーションサーバとして実施され得る。（コンピューティングデバイスＡを操作する）「アリス」が、写真プリントサービスプロバイダに、サーバに格納された自分のモスクワ旅行に関する自分の写真をプリントするように求めるユースケースでは、リソース所有者１０２（アリス）は、ユーザエージェント（例えば、コンピューティングデバイスＡ上で実行するウェブブラウザプログラム）により表されることになり、リソース要求者１０４（写真プリントサービスプロバイダ）は、アプリケーションサーバにより表されることになる。（コンピューティングデバイスＢを操作する）「ボブ」が、オンライン映画サービスの加入者である別のユースケースでは、リソース所有者１０２（オンライン映画サービスプロバイダ）は、許可サーバにより表されることになり、リソース要求者１０４（ボブ）は、ユーザエージェント（例えば、コンピューティングデバイスＢ上で実行するウェブブラウザプログラム）により表されることになる。
【００２７】
リソース所在地１０６内のある決まった保護されたリソースへのアクセスを得るために、リソース要求者１０４は、（以下でさらに考察されることになる）図２に例示的に示されるような基本構造２００を有する許可トークンを、リソース所有者１０２から直接取得する必要がある。その目的のために、２つの方法、すなわちプルおよびプッシュが考えられる。プル方法では、リソース要求者１０４およびリソース所有者１０２は、要求および応答を交換する。トークン要求は、少なくとも、要求者、ならびに目標リソースおよび関連するアクションを特定するものとする。以下で解説される図３および４は、それぞれ、リソース要求者１０４およびリソース所有者１０２の観点からのプル方法を図示する。プッシュ方法では、リソース所有者１０２は、リソース要求者からの明示的な要求ではなく、アプリケーションのトリガの結果として、リソース要求者１０４に許可トークンを発行することができる。
【００２８】
図３は、基本的な許可トークンを要求するための、リソース要求者（例えば、図１での１０４）側に関するプル方法３００を示す。ステップ３０２では、リソース要求者は、要求所有者に対する許可トークン要求を生成かつ送信する。ステップ３０４では、リソース要求者は、それがリソース所有者から受信する第１の応答をチェックし、ステップ３０６では、第１の応答が（それによって、リソース所有者が、所有者が要求者に許可トークンを送信する前に要求者が認証されることを要求している）認証要求を含むかどうか、または、第１の応答が許可トークンを含むかどうかを判定する。
【００２９】
リソース所有者からの第１の応答が、認証要求ではなく、許可トークンを含み、したがって、ステップ３０８（すなわち、以下で説明される失敗トークン応答の受信に対するチェック）が否定をもたらす場合、要求者は、ステップ３１０で、（リソース所在地への後に続く伝送のために）許可トークンを保存する。
【００３０】
これに対して、リソース所有者からの第１の応答が、認証要求である場合、ステップ３１２で、リソース要求者は、リソース所有者に対する認証応答を生成かつ送信する。ステップ３１４では、リソース要求者は、次いで、それがリソース所有者から受信する第２の応答をチェックし、第２の応答が許可トークンを含む（したがって、認証が成功したと推定する）かどうかを判定する。そうである場合、ステップ３０８（失敗トークン応答）が否定をもたらし、要求者は、ステップ３１０で、（リソース所在地への後に続く伝送のために）許可トークンを保存する。これに対して、認証が失敗した場合、リソース所有者から受信される第２の応答は、失敗トークン応答であり、すなわち、リソース所有者が要求者に許可トークンを発行しないことになることを意味する。要求者を認証するために使用される技法は、任意の従来の認証技法を含み得ることを理解されたい。
【００３１】
図４は、トークン要求に対処するための、リソース所有者（例えば、図１での１０２）側に関するプル方法４００を示す。ステップ４０２では、リソース所有者は、（そこからトークン要求が受信された）リソース要求者が認証されているか否かをチェックする。そうでない場合、ステップ４０４で、リソース所有者は、認証要求を生成し、それをリソース要求者に送信する。ステップ４０６では、リソース所有者は、リソース要求者から受信された認証応答をチェックする。ステップ４０８では、認証が成功したかどうかを判定するためにチェックが行われる。いいえである場合、リソース所有者は、ステップ４１０で、要求者に失敗トークン応答を送信する（すなわち、許可トークンは要求者に送信されない）。これに対して、認証が成功した場合、所有者は、ステップ４１２で、要求者は所有者のリソース（複数可）へのアクセスが与えられるべきかどうかを判断し、そうである場合、ステップ４１４で、許可トークンを生成し、それを要求者に送信する。これに対して、アクセスが拒否される場合、ステップ４１０で、失敗トークン応答が送信される。
【００３２】
許可トークンが供給されると、リソース要求者１０４は、次いで、リソース所在地１０６内の保護されたリソースへのアクセスを要求することができる。リソース要求を受信する際に（図１を参照）、リソース所在地１０６は、以下のアクションを行う：
１−  要求に関連するデジタル署名が有効であることを、トークンで指定されたデジタル署名方法に基づいて検証する、
２−  トークンが、時間および使用の最大数に関して失効していないことを検証する、
３−  要求されるリソースおよび実施されるべきアクションが、トークンで指定されたリソースおよび関連する権利のリストの一部であることを検証する、
４−  リソース要求者の名前が、トークン内の要求者の名前と一致することを検証する、ならびに、
５−  トークンで指定された方法または強度レベルの方法を使用して、リソース要求者を認証する。
【００３３】
図５Ａおよび５Ｂは、リソース所在地（例えば、図１での１０６）により保持される、（初期の要求では必ずしも許可トークンを含まない）保護されたリソースへのアクセスのための、リソース要求者（例えば、図１での１０４）側に関する方法５００を示す。
【００３４】
ステップ５０２では、リソース要求者は、要求所在地に対するリソース要求を生成かつ送信する。ステップ５０４では、リソース要求者は、それがリソース所在地から受信する第１の応答をチェックし、ステップ５０６では、第１の応答が（それによって、リソース所在地が、所在地が要求者によるリソースへのアクセスを認可する前に要求者が認証されることを要求している）認証要求を含むかどうか、または、第１の応答が許可トークンを求めているかどうかを判定する。
【００３５】
リソース所在地からの第１の応答が、認証要求ではなく、許可トークンを求めており（以下で説明される５１４）、したがって、ステップ５０８（すなわち、以下で説明される失敗応答の受信に対するチェック）が否定をもたらす場合、要求者は、許可トークンを送信する（以下で説明される５１６）。
【００３６】
これに対して、リソース所在地からの第１の応答が、認証要求である場合、ステップ５１０で、リソース要求者は、リソース所在地に対する認証応答を生成かつ送信する。ステップ５１２では、リソース要求者は、次いで、それがリソース所在地から受信する第２の応答をチェックし、第２の応答が、失敗応答であるか（５０８）、それとも、許可トークンに対する要求であり（５１４）、したがって、認証が成功したと推定するかを判定する。後者場合、要求者は、ステップ５１６で、（それが、図３および４の脈絡において上記で説明されたプロトコルによってリソース所有者から受信した）許可トークンを送信する。
【００３７】
ステップ５１８では、リソース要求者は、次いで、それがリソース所在地から受信する第３の応答をチェックし、第３の応答が、別の認証要求、すなわち、要求者がトークンで規定された方法によって認証されることを確実にするための、所在地による後に続く認証要求であるかどうかを判定する。すなわち、追加的なセキュリティのために、リソース所在地は、トークンが受信されるたびに、要求者を再認証する必要がある場合がある。そうである場合、上記で説明されているステップ５１０、５１２および５０８と同様である、ステップ５２４、５２６および５２８が実施される。ステップ５３０では、要求者は、典型的には要求されるリソースを包含する応答を処理する。
【００３８】
図６Ａおよび６Ｂは、リソース要求者（例えば、図１での１０４）からのリソース要求に対処するための、リソース所在地（例えば、図１での１０６）側に関する方法６００を示す。ステップ６０２では、リソース所在地は、リソース要求者が認証されているかどうかをチェックする。はいである場合、ステップ６０４で、リソース所在地は、要求者がリソース所有者である（その場合には、要求者は、許可トークンを必要としないことになる）かどうかを確認する。はいである場合、ステップ６０６で、所在地は、適切なリソースのアクションを適用し、応答を送信する（例えば、要求されるリソース（複数可）へのアクセスを付与する）。
【００３９】
これに対して、ステップ６０２に戻って、要求者が認証されておらず、許可トークンが要求者によりまだ提供されていない（ステップ６０８）場合、認証処理が、ステップ６１０（要求者に対する要求を生成かつ送信する）、６１２（認証応答をチェックする）、および６１４（認証成功を確認する）で実施される。成功でない場合、ステップ６１６で、失敗応答が要求者に送信される。これに対して、認証が成功した場合、ステップ６０４が実施され（要求者が所有者であるかどうかをチェックする）、肯定的である場合、ステップ６０６（リソースのアクションを適用し、応答を送信する）が実施される。これに対して、（ステップ６１４での）成功した認証、および、（ステップ６０４での）要求者がリソース所有者でないことの検証の後で、所在地は、ステップ６１８で、要求者に許可トークンを求め、ステップ６２０で、それが要求者により提供されたかどうかをチェックする。そうでない場合、ステップ６１６で、失敗応答が送信される。
【００４０】
トークンが受信された後、リソース所在地は、ステップ６２２で、トークンを検証する。例えば、検証は、トークン署名が有効であるかどうか、要求およびトークン内の要求者の名前が一致するかどうか、トークンが失効していないかどうか、要求されるリソースおよびアクションが範囲内である（すなわち、要求者および／または要求されているリソースに対して認可されるものである）かどうかを判定するように実施される。トークンの構造に応じて、より少ない、またはより多い検証が、トークンおよびその内容に対して行われ得ることを理解されたい。トークンの１つまたは複数の構成が検証され得ない場合、ステップ６２４で、失敗応答が要求者に送信され、したがって、リソースは要求者に対して利用可能にされない。これに対して、受信されたトークンのすべての構成が検証される場合、別の認証処理が、トークンで指定された（方法または保証レベルに関する）認証要件によって所在地により要求され得る。これは、ステップ６１０、６１２、および６１４と同様である、ステップ６２６、６２８、６３０および６３２によって行われる。第２の認証が成功していると推定すると、ステップ６３４で、リソースのアクションが適用され、応答が送信される（すなわち、リソースへのアクセスが認可される）。そうでない場合、ステップ６２４で、失敗応答が送信される。
【００４１】
再び図２に戻ると、許可トークンの基本構造は、（名前−値の対に関する）フィールドのリスト、および、発行者の秘密鍵または共有秘密に基づいて、指定された署名アルゴリズム２１０（例えば、ＲＳＡ−ＳＨＡ１およびＨＭＡＣ−ＳＨＡ２５６）を使用して、フィールドにわたって計算された発行者の署名２０２で構成される。一意的トークン識別子２０４は、発行者の名前２０６およびタイムスタンプを連結することにより構築され得る。発行者の証明書または証明書へのポインタのチェーン２０８が、トークンで指定される。このフィールドは、発行者の署名を計算するために使用されるアルゴリズムが秘密鍵ベースである場合に、全体的な性能を向上させるために含まれる必要があるに過ぎないことに留意されたい。フィールド２１２は、リソース要求者の名前（識別情報）を指定する。フィールド２１４は、要求者を認証するための方法または方法の強度を指定する。フィールド２１６は、受信者、すなわち、リソース所在地の働きをするデバイスまたはサーバの名前（識別情報）を指定する。
【００４２】
リソースおよび権利のリスト２１８、失効時間２２０、ならびに使用の最大数２２２の複合的なフィールドが、全体的な委譲範囲を設定する。譲渡可能性の程度２２４は、リソース所有者により発行されるトークンが、最初の要求者から開始して、一連のトークン要求者に至るまで転送され得る程度を指し示す。それは、非負の整数の値をとり得る。譲渡可能性の第０の程度のトークンは、転送され得ない。譲渡可能性の第Ｎの程度のトークンは、最初のトークン要求者により、第２のトークン要求者に、第３の要求者に、以下同様にして、最多で第Ｎの要求者に譲渡され得る。
【００４３】
譲渡可能なトークンを取得した後で、要求者は、新しいトークンを古いものに基づいて、新しい要求者に発行することができる。図７に示されるように、新しいトークン７００は、（前と同じ方法により認証されることになる）新しい要求者７０８の識別情報、および場合によっては、格下げされた委譲範囲７１０を指定する。一実施形態では、新しいトークン７００は、古いトークン７０４（すなわち、図２に示されるトークン構造）、および、前の要求者（今では発行者）の証明書または証明書へのポインタのチェーン７０６をさらに包含する。発行者の署名７０２は、発行者の秘密鍵または共有秘密に基づいて、（古いトークンで指定された署名アルゴリズムと同じであり得る）署名アルゴリズムを使用して、フィールドにわたって計算される。
【００４４】
転送されるトークンを検証する場合に、リソース所在地は、加えて、以下のことをチェックする必要がある：
１−  譲渡可能性の程度が、存在する新しい要求者の数より大きい、
２−  すべての署名が有効である、および、
３−  トークンが転送される際に、範囲が途中で広げられない。
【００４５】
譲渡可能なトークンのユースケースは、以下のようなものである。アリスは、ある決まったコンテンツをコンテンツサーバ上で公表し、自分のコンテンツへの他者によるアクセスに対処するために、関連するコンテンツマネージャを自分のプロキシにする。譲渡可能である、または使用の数が制限されているトークンをサポートするために、リソース所在地は状態を維持する必要があることに留意されたい。
【００４６】
最後に、図８は、本発明の上記で説明された原理による、セキュアな動的権限委譲を実施するのに適した通信ネットワーク８００の一般化されたハードウェアアーキテクチャを例示する。
【００４７】
示されるように、リソース所有者８１０用のコンピューティングデバイス（例えば、図１での１０２）、リソース所在地８２０用のコンピューティングデバイス（例えば、図１での１０６）、およびリソース要求者８３０用のコンピューティングデバイス（例えば、図１での１０４）は、通信ネットワーク媒体８５０を介して動作可能に結合される。ネットワーク媒体は、コンピューティングデバイスが通信することを望む任意のネットワーク媒体であり得る。例として、ネットワーク媒体は、ＩＰパケットをエンドツーエンドで搬送し得るものであり、アクセスネットワークではＵＭＴＳ（ユニバーサル移動体通信システム）もしくはＷｉＦｉもしくはＤＳＬ（デジタル加入者線）を、メトロネットワークではイーサネット（登録商標）を、ならびにバックボーンではＭＰＬＳ（マルチプロトコルラベルスイッチング）を必要とし得る。しかしながら、本発明は、特定のタイプのネットワーク媒体に限定されない。典型的には、各個のコンピューティングデバイスは、実施されている権限委譲のシナリオに応じて、クライアントマシンまたはサーバマシンとして機能し得る。リソース所在地は、別個のコンピューティングデバイスとして示されるが、所在地は、所有者または要求者と同じコンピューティングデバイスの一部であり得ることをさらに理解されたい。さらに、リソース所有者、要求者および所在地は、各個が、１つのコンピューティングデバイスによって実施されているように図８で示されるが、各個は、２つ以上のそのようなコンピューティングデバイスによって実施され得ることを理解されたい。
【００４８】
当業者には容易に明らかとなるように、コンピューティングデバイスは、コンピュータプログラムコードの制御のもとで動作するプログラムされたコンピュータとして実施され得る。コンピュータプログラムコードは、コンピュータ（またはプロセッサまたは機械）可読記憶媒体（例えば、メモリ）に記憶されることになり、コードは、コンピュータのプロセッサにより実行されることになる。本発明の本開示が与えられれば、当業者は、本明細書で説明されたプロトコルを実施するために、適切なコンピュータプログラムコードを容易に生み出すことができる。
【００４９】
それでも、図８は、ネットワーク媒体を介して通信する各個のデバイスに対する一例としてのアーキテクチャを全体的に例示する。示されるように、リソース所有者８１０は、Ｉ／Ｏデバイス８１２、プロセッサ８１４、およびメモリ８１６を備える。リソース所在地８２０は、Ｉ／Ｏデバイス８２２、プロセッサ８２４、およびメモリ８２６を備える。リソース要求者８３０は、Ｉ／Ｏデバイス８３２、プロセッサ８３４、およびメモリ８３６を備える。
【００５０】
本明細書で使用される用語「プロセッサ」は、１つまたは複数の信号プロセッサ、１つまたは複数の集積回路等を含むが、それらに限定されない、中央処理装置（ＣＰＵ）または他の処理回路網を含む、１つまたは複数の処理デバイスを含むことが意図されるということを理解されたい。さらに、本明細書で使用される用語「メモリ」は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えば、ハードドライブ）、またはリムーバブルメモリデバイス（例えば、ディスケットまたはＣＤＲＯＭ）などの、プロセッサまたはＣＰＵと関連するメモリを含むことが意図される。加えて、本明細書で使用される用語「Ｉ／Ｏデバイス」は、データを処理装置に入力するための１つもしくは複数の入力デバイス（例えば、キーボード、マウス）、ならびに、処理装置に関連する結果を提供するための１つもしくは複数の出力デバイス（例えば、ＣＲＴディスプレイ）を含むことが意図される。
【００５１】
したがって、本明細書で説明された、本発明の方法論を実施するためのソフトウェア命令またはコードは、関連するメモリデバイス、例えば、ＲＯＭ、固定メモリまたはリムーバブルメモリの、１つまたは複数に記憶され得るとともに、利用される準備ができた場合に、ＲＡＭにロードされ、ＣＰＵにより実行され得る。すなわち、図８に示される各個のコンピューティングデバイス（８１０、８２０、および８３０）は、図１および７に図示されるプロトコルのそれらのそれぞれのステップを実施するように、個別にプログラムされ得る。
【００５２】
本発明の例示的な実施形態が、添付の図面を参照して本明細書で説明されたが、本発明はそれらのまさにその実施形態に限定されないこと、ならびに、様々な他の変更および修正が、本発明の範囲または趣旨から逸脱することなく、当業者により行われ得ることを理解されたい。
【図１】
0005635133.tif 000002
【図２】
0005635133.tif 000003
【図３】
0005635133.tif 000004
【図４】
0005635133.tif 000005
【図５Ａ】
0005635133.tif 000006
【図５Ｂ】
0005635133.tif 000007
【図６Ａ】
0005635133.tif 000008
【図６Ｂ】
0005635133.tif 000009
【図７】
0005635133.tif 000010
【図８】
0005635133.tif 000011