リソースのデレゲーションを実行する方法およびシステム
リソース、特にサービスのデレゲーションを実行する方法を提供する。ユーザ、すなわちリソース所有者は、サービスプロバイダによって提供されるリソースにアクセス可能であり、該リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲される。本方法は、デレゲートに対してリソースアクセス制限に関する認可規則を規定し、その認可規則をアイデンティティプロバイダに登録することにより、デレゲーション・クレデンシャルを使用するステップと、サービスプロバイダにおいてデレゲートの認証を実行するステップと、認可規則に基づいてアイデンティティプロバイダにおいて前記デレゲートの認可を実行するステップとを備えたことを特徴とする。また、対応するシステムも開示される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース、特にサービスのデレゲーション（delegation）を実行する方法に関する。ここで、ユーザ、すなわちリソース所有者は、サービスプロバイダによって提供されるリソースにアクセス可能であり、リソースは、デレゲーション・クレデンシャル(delegation credentials)を使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲される。
【０００２】
また、本発明は、リソース、特にサービスのデレゲーションを実行するシステムに関する。該システムは、リソースを提供するサービスプロバイダを備え、ユーザ、すなわちリソース所有者は該リソースにアクセス可能であり、リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲される。
【背景技術】
【０００３】
それぞれの個人に関連する基本設定やデータは、ＩＳＰ（インターネットサービスプロバイダ）におけるアカウントと、そのＩＳＰによって提供されるサービスに関連するサブスクリプションとの間の区別をやや困難にしている。個人のプロファイルはサブスクリプションに結合されるので、トランスポート・サブスクリプション（ネットワークアクセス）が共有され、別々のサービスプロバイダ・サブスクリプションが保持されることが比較的普通である。連合アイデンティティ(federated identity)環境では、ユーザのプロファイルは相異なるサブスクリプションに結合される。これは周知の問題であり、リバティ・アライアンス(Liberty Alliance)（http://www.projectliberty.org を参照）やＯｐｅｎＩＤ（http://www.openid.net）で提案されているような解決法が既に存在するが、デレゲーション（delegation, 権限委譲）によるサブスクリプション共有の問題は依然として未解決である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、本発明の目的は、頭書のような、リソースのデレゲーションを実行する方法およびシステムにおいて、ユーザのプライバシーを保護しデレゲーションのプロセスおよび状況に対する厳格な管理を可能にしながら、ユーザがリソースへのアクセスを他者と共有できるように、改良を行うことである。
【課題を解決するための手段】
【０００５】
本発明によれば、上記の目的は、請求項１の構成を有する方法によって達成される。この請求項に記載の通り、本方法は、サービスプロバイダにおいてデレゲートの認証を実行するステップと、認可規則に基づいてアイデンティティプロバイダにおいてデレゲートの認可を実行するステップとを備えたことを特徴とする。
【０００６】
また、上記の目的は、独立請求項１８の構成を有するシステムによって達成される。この請求項に記載の通り、本システムは、前記サービスプロバイダがデレゲートの認証を実行するように構成され、アイデンティティプロバイダが設けられ、認可規則に基づいてデレゲートの認可を実行するように構成されたことを特徴とする。
【０００７】
本発明によって初めて認識されたこととして、従来のメカニズムでは、デレゲーションによるリソース共有が、十分にフレキシブルかつセキュアな形で可能となっていない。本発明は、ユーザが他のユーザに対してサブスクリプションや支払のデレゲーションを行うことができる方法やシステムを構成するために、アイデンティティ管理機能、サービスプロバイダ・サブスクリプション管理、および暗号プリミティブをどのように組み合わせればよいかを扱う。ユーザを認証しデレゲーションを確認する権限をサービスプロバイダに残しながら、アイデンティティプロバイダが、アクセス制御規則、すなわち認可規則に基づいて、アクセスの許可ないし拒否をすることが可能である。このプロセスは、認証(authentication)を認可(authorization)から分離することで、システムにフレキシビリティを付加する。サービスプロバイダは必ずしも認可の規則を知る必要はなく、また、アイデンティティプロバイダは、サービスアクセスのためのユーザ認証に関与しなくてもよい。
【０００８】
また、サービス消費のための認証と認可とを分けることで、サービスプロバイダがデレゲートユーザを知る必要はなく、サブスクライバとの関係だけを知ればよいという、付加的なプライバシー上の利益が得られる。従来技術によれば、同一サブスクリプションの下で複数ユーザをサポートする通常の方法は、サービスプロバイダ側にこの関連づけの情報をもたせるか、あるいは、相異なるユーザ間でクレデンシャルを共有する（したがってそれらのユーザを区別しない）か、のいずれかであった。メッセージや証明書に署名・確認するというような暗号プリミティブの形でデレゲーション・クレデンシャルを使用することにより、本発明による方法およびシステムの健全性およびセキュリティが保証される。
【０００９】
複数のコンフィギュレーションと、相異なるデレゲーションに対するアカウントユーザによる管理を可能にした、フレキシブルなデレゲーションの方法およびシステムが提供される。これは、リソースやサブスクリプションの保持者が、ユーザのクレデンシャルやアイデンティティを単に提供するのではなく、そのサブスクリプションに結合させる新規なクレデンシャルを発行するように、サービスに対して要求することができる、ということを意味する。そして、このようなクレデンシャルは、サービスにアクセスするために、デレゲーションを受けたエンティティによって使用されることが可能である。この新規ユーザはトランザクションに直接には関与していないので、サービスプロバイダは、リソースの保持者あるいはサブスクライバによってその新規ユーザが当該アカウントの使用を許可されていることは知るが、その新規ユーザが誰であるかは必ずしも知らない（責任はサブスクライバ側にある）。
【００１０】
本発明による方法およびシステムは、集中化されたデレゲーション管理を実施する。その結果として、サブスクリプション管理が容易となってユーザ側から見て扱いやすくなるとともに、ユーザのプライバシーが向上し（デレゲートのアイデンティティに関して、強力なセキュリティパラメータを維持しつつ、デレゲートのアイデンティティを保護する）、アイデンティティプロバイダに新規なビジネスモデルを提供するという利点がある。
【００１１】
好ましい実施形態によれば、デレゲートに対して規定される認可規則は、アイデンティティプロバイダに登録されることにより、前記デレゲーション・クレデンシャルを使用する。認可規則は、デレゲートに対して、リソースへの完全アクセスを無制約で許可してもよい。他方、デレゲートに対して規定される認可規則は、リソースアクセス制限を含むことも可能である。
【００１２】
別の好ましい実施形態によれば、リソースへのアクセスは、サービスへのサブスクリプションを保持するリソース所有者によって確立されてもよい。リソース所有者は、例えば、サービスプロバイダによって提供されるサービスに直接に加入していてもよい。
【００１３】
好ましくは、サービスプロバイダによって、デレゲーション・クレデンシャルが発行され、（認証プロセスにおいて）確認される。デレゲーションの際に、デレゲーション・クレデンシャルは、サブスクリプション保持者等のリソース所有者から、デレゲートに渡されてもよい。すなわちこの場合、サービスプロバイダが、認証の権限を保持する。サービスプロバイダは、サービスにアクセスするためにデレゲートによって使用されるクレデンシャルを保持・作成・チェックする。ただし、認可を提供する（その場合にアクセスを許可することができる）アクセス制御ポリシーを別個とし、アイデンティティプロバイダに保存してもよい。その場合、サービスプロバイダは、認可規則（これは通常、サービスプロバイダの領域外にあるグループ、コンテクスト等に基づく）を扱う必要がなく、ユーザの認証と、サブスクリプションへの結合だけを扱うので有利である。
【００１４】
セキュリティを高めるため、サービスプロバイダにおけるデレゲートの認証は、デレゲーション・クレデンシャルに基づいて実行してもよい。別法として、あるいはこれに加えて、デレゲートがサービスプロバイダにおけるサービスを要求した場合、アイデンティティプロバイダにおいて、デレゲーション・クレデンシャルに基づいてデレゲートの認証を実行してもよい。さらに、認可をサービスプロバイダにおいて実行してもよい。その場合、責任に関する利点がある。というのは、認可の部分がサービスプロバイダにおいてなされているので、アイデンティティプロバイダは、ユーザのいかなる違反にも責任を問われないと主張することができるからである。
【００１５】
好ましい実施形態によれば、アイデンティティプロバイダにおいてユーザアカウントを設けてもよい。各アカウントは、ユーザの別のデジタルアイデンティティに結合される。このような場合、デレゲートに対して規定される認可規則は、デジタルアイデンティティごとに固有の方法で規定されてもよい。特に、サービスプロバイダにおけるデレゲートの認証は、デレゲートのデジタルアイデンティティに基づいてもよい。具体的には、あるデジタルアイデンティティで、あるリソース／サービスのアクセスまたは使用を許可し、別のデジタルアイデンティティに対しては、このようなアクセス／使用を拒否してもよい。なおこの点に関して、ユーザのデジタルアイデンティティと、物理的な個人との間が明確に分離されていることに注意すべきである。物理的な一個人は複数のデジタルアイデンティティを有し得るので、場合によっては、あるデジタルアイデンティティではサービスにアクセス不可能だが、別のデジタルアイデンティティでは可能であることが起こり得る。
【００１６】
なお、アイデンティティプロバイダは、同時に複数のサービスに対するアクセス制御を処理するために使用することも可能である。その場合、同じデレゲーションの下で同一ユーザが相異なるサービスにアクセスするために、同じ認可規則を相異なるクレデンシャルの下で使用することができる。他方、複数のデレゲーションに適用可能な一般的な認可規則を指定してもよい。いずれの場合でも、リソース保持者は、サービスプロバイダと交信せずに、デレゲーションの認可を変更することができる。
【００１７】
アクセス制御属性を変えた複数の具体例が可能である。例えば、リソース保持者は、複数の側面に基づいて認可規則を決めることができる。特に、認可規則は、デレゲーションがなされるサービスの種別に基づいてもよい。また、デレゲーションがなされるリソースへのアクセスをデレゲートに許可する時間を指定してもよい。また、ユーザを指定してもよく、その際、ユーザのデジタルアイデンティティを考慮に入れてもよい。さらに、例えば料金限度を指定することで、リソース／サービスのアクセスまたは使用の料金を認可規則内で指定してもよい。なお、列挙した基準は単なる例示と理解すべきである。すなわち、認可規則を規定するために想定される他の基準も考えられるが、個々のニーズや条件に従って指定すればよい。
【００１８】
高度のセキュリティを備え実施の容易な好ましい実施形態によれば、デレゲーション・クレデンシャルは、証明書および秘密鍵を含んでもよい。その場合、デレゲーションにおいて鍵を渡される各エンティティは、デレゲーションがなされたリソースを使用することができる。
【００１９】
認可処理を容易にするため、認可情報をアイデンティティプロバイダに集中化し、その情報を各デレゲートごとに集約してもよい。別法として、あるいはこれに加えて、認可情報を、各サービスごとに集約してアイデンティティプロバイダに集中化してもよい。ただし、認可規則の分散管理も可能である。
【００２０】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および１８に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００２１】
【図１】複数のアイデンティティを有する家庭の例の概略図である。
【図２】本発明による方法が適用可能な種々のデレゲーション例の場面を例示する図である。
【図３】本発明の第１実施形態によるメッセージシーケンスチャートの例を示す図である。
【図４】本発明の実施形態による応用場面を例示する図である。
【図５】デレゲートによるサービスアクセスを模式的に例示する図である。
【図６】ユーザがデレゲーションを設定するセットアップ段階におけるメッセージフローを示す図である。
【図７】デレゲーションがなされたサービスにデレゲートがアクセスするサービス消費段階におけるメッセージフローを示す図である。
【発明を実施するための形態】
【００２２】
以下では、ＩＰＴＶ分野におけるデレゲーションに対する具体的使用例の場面について説明する。想定しているデレゲーションは、サービスへのサブスクリプション共有の特別な場合を扱う。この使用例では、デレゲーション場面におけるアクセス制御を扱う統括エンティティとして、アイデンティティ管理(Identity Management)基盤を導入する。
【００２３】
今日の一般的なＩＰＴＶの利用場面では、サービスに対するユーザごとの認証が存在しないので、通常、基本サービスへのユーザサブスクリプションが共有される。しかしこれは、アイデンティティ管理および個人化サービスの普及に伴って変化するだろうと期待される。これまでは、ユーザがサービスにアクセスするための識別子であったユーザサブスクリプションでは、もはや不十分となるであろう。
【００２４】
ＩＰＴＶは、デジタルテレビによって現在提供されているものをはるかに超えたサービスをサポートする。そのようなサービスとしては、今日のシステムによって既に提供されているものに加えて、ＩＰ電話、ゲームサービスが挙げられ、第三者サービスへのアクセスさえも含まれる。ＩＰＴＶプロバイダと外部サービスとのインタラクションは、以下で詳述する使用例において扱われる重要な側面である。
【００２５】
ユーザは、ＩＰＴＶプロバイダおよびサービスプロバイダへの相異なるサブスクリプションについて、それらが同一事業者によって提供されているか、それとも第三者プロバイダによって提供されているかにかかわらず、それらのすべてのサブスクリプションを管理しなければならない。アイデンティティ管理は、ユーザアカウント管理を容易にする共通の基盤を提供することができる。特に、アイデンティティ管理基盤とやり取りするサービスは通常、アイデンティティの概念にも依存しているので、相異なるデジタルアイデンティティに結合したユーザサブスクリプションの管理は、もう１つの重要な問題となる。
【００２６】
説明する場面では、ユーザとそのデジタル表現、すなわち仮想アイデンティティ（virtual identity, ＶＩＤ）とは別個のエンティティであると仮定する。ユーザはサブスクリプションを保持する。サブスクリプションは、ユーザとそのサービスプロバイダとの間で結ばれる契約であるが、その場合、必要に応じて、そのＶＩＤとサブスクリプションを関連づけることができる。図１は、ある家庭を表しており、本発明による方法の、ＩＰＴＶに関連する実施形態を説明するために用いられる。図１には、契約を締結しサービスへのサブスクリプションを形成することが可能な複数のユーザが、デジタルアイデンティティとともに表されている。デジタルアイデンティティは、ユーザがそれらのサービスにおいて認識され、個人化・履歴情報、およびおそらくは認証クレデンシャルを保持する場合に用いられる。より具体的には、例示した家庭には父親、母親および息子の３人がいる。これらの個人のデジタルアイデンティティは、彼らの家族および職業に関係する。例えば、父親には、（家族的背景に関する）「father」（父親）というデジタルアイデンティティと、（職業的背景に関する）「employee」（会社員）というデジタルアイデンティティが関連づけられる。母親である個人に関しては、「mother」（母親）および「wife」（妻）という２つの家族関連のデジタルアイデンティティが設けられている。なお、図１に示すデジタルアイデンティティは単なる例示の目的で選択されており、さまざまなユーザコンテクスト（会員、スポーツ等）に関係する他の多くのデジタルアイデンティティを想定することができる。
【００２７】
図２に、例えばＩＰＴＶとの関連で出現し得るいくつかのデレゲーション場面を詳細に示す。図２の上部には、３つの相異なるリソースあるいはサービスが示されており、それらは電話サービス（左）、インターネットサービス（中央）およびクレジットカードによる課金や購買のサービス（右）である。課金サービスの場合において、ユーザ（例示したケースでは母親）は、他のサービスや電子商取引の支払に、自己のアカウントを使用する権限を委譲することが考えられる。
【００２８】
サービスの下に、サブスクリプションに責任をもつアカウントの保持者と、主なデジタルアイデンティティが示されている。場合によっては、複数のデジタルアイデンティティがサブスクリプションに直接結合されることもある。サブスクライバは、サブスクリプションの使用を他のデジタルアイデンティティに権限委譲する。その中には、自分自身に属するデジタルアイデンティティと、他の信頼されたエンティティに属するデジタルアイデンティティとがある。図２に例示した使用例では、ユーザがサブスクリプションを形成する形式は、サブスクリプションからデジタルアイデンティティへのマッピングとは比較的独立している。
【００２９】
図２の左に示す例において、父親は、電話サービスのサブスクライバであるが、そのサービスサブスクリプションを母親に完全に権限委譲している。電話サービスに「mother」として認証されると、このユーザはサービスへの完全アクセスを取得し、その場合、父親のアカウントの下で課金されることになる。
【００３０】
デレゲーション問題に対する１つの拡張として、デレゲーションごとに、より複雑なアクセス制御規則を追加することがある。上記の例を用いると、電話サービスへのサブスクライバである「father」は、電話サービスの使用を「son」（息子）に権限委譲するが、ユーザ「son」がそのサービスで使える金額を制限している。もう１つの制限されたデレゲーションとして示されているのは、「employee」として認証された父親に関するものであり、この「employee」は息子に電話することのみが許可される。インターネットサービスに関しては、息子は２つの相異なる制限に服している。sonとしてのアイデンティティにおいて、制限は特定のサービス種別に基づく（この場合、例えば、ある一定のゲームサービスへのアクセスが拒否される）。他方、student（学生）としてのアイデンティティにおいて、制限は時間に基づく（例えば、アクセスは、日中の数時間のみ許可される）。
【００３１】
なお、図２の具体的実施形態によれば、購買サービスに関するデレゲーションは、fatherとしてのアイデンティティにおける父親が、デレゲートとして、さらなるデレゲーションを許可する権利が付与されるように実施される。今度も、sonとしてのアイデンティティにおける息子は、この場合は特定のサービスに関して、制限に服している。
【００３２】
図３に、ＩＰＴＶにおけるデレゲーションの具体例に対するメッセージシーケンスチャートを例示する。このチャートは、セットアップ段階というシーケンスに属するメッセージ（破線の上側に示すメッセージ）と、それに続くサービス使用段階というシーケンスに属するメッセージ（破線の下側）とを含む。サブスクリプション所有者は、ＩＰＴＶプロバイダおよび第三者サービスプロバイダの両方へのサブスクリプションを既に有していると仮定する。
【００３３】
セットアップ段階：
Ａ．１）このステップで、サブスクリプションの所有者が、ＩＰＴＶプロバイダにおけるリンクを作成する。これにより、ＩＰＴＶプロバイダがアイデンティティプロバイダにおけるアクセス制御規則に従う限り、別のユーザが所有者のアカウントを使用することが可能となる。
Ａ．２）第三者サービスプロバイダについて、同様の動作が実行される。
Ａ．３）サブスクリプションの所有者が、アイデンティティプロバイダにおいてアクセス制御規則を設定する。この動作は、デレゲートのプロファイルに「認証済み」情報を付加する、あるいは、デレゲートが自分自身のプロファイルに付加するクレデンシャルをデレゲートに与えるものとみなすことができる。なお、このステップで、ユーザは両方のサービスに影響を及ぼす一般的なアクセス制御ポリシーを設定することができる。これは、アイデンティティ管理システムを用いてアクセス制御を実行する利点の１つである。
【００３４】
サービス消費段階：
Ｂ．１）デレゲートがＩＰＴＶサービスにアクセスする。
Ｂ．２）ＩＰＴＶサービスプロバイダが、アイデンティティプロバイダ（これはＩＰＴＶ事業者のドメイン内にあることも可能である）と交信し、ユーザを認証する。この場合、ユーザはそのアイデンティティプロバイダで既に認証されていると仮定する。そうでない場合には、この時に認証を行うことも可能である。
Ｂ．３）アイデンティティプロバイダは、ユーザが認証されていることが確認できたら、当該デレゲーションを用いた当該サービスへのアクセスに対するアクセス制御の制限を確認する。これに基づいて、サービスへのアクセスを許可または拒否する。
【００３５】
さらに、ＩＰＴＶプロバイダは、ユーザにアクセスを提供する前に、サービスデレゲーションに関する他のアクセス制御クレデンシャルに対するチェックをしてもよい。
【００３６】
ステップＢ．４）、Ｂ．５）およびＢ．６）は、第三者サービスプロバイダに関連する同様の処理を示している。なお、認可制御を主としてアイデンティティ管理システムによって実行し、ポリシーはデレゲーション間で共有することも可能である（ユーザサブスクリプション管理の手間が軽減される）。
【００３７】
図４は、本発明の別の実施形態による応用場面を例示している。最初のステップで、ユーザがサービスに加入し、サービスは、そのユーザのサブスクリプションのアクセスおよび管理のためのクレデンシャルを発行する。ステップ２で、ユーザは、サブスクリプションのデレゲーションをサービスに要求し、サービスプロバイダからクレデンシャルのセット（証明書および秘密鍵）を受け取る。秘密鍵を有する者は誰でも、そのデレゲーションを使用することができる。
【００３８】
ステップ３で、デレゲートまたはサブスクリプション所有者のいずれかが、アイデンティティ管理システムを設定し、このデレゲーションを報告する。これは、このデレゲーションが（本具体例においては）息子に属することが、アイデンティティ管理システムに知らされることを意味する。またステップ３では、所有者が、デレゲーションに対する別個の認可である他のアクセス制御規則を設定してもよい。ステップ４で、所有者は、デレゲートが当該サブスクリプションを用いてサービスにアクセスすることを可能にする秘密鍵をデレゲートに提供する。ステップ５は、サービスがどのようにアクセス可能となるかを示しており、後でさらに詳述する。最後に、サブスクライバは、各デレゲーションおよび自分自身によるサブスクリプションの使用を合算した請求書を受け取る。
【００３９】
図５は、デレゲートによるサービスアクセスを模式的に例示している。すなわち、サービスは、サービスプロバイダＳＰによって提供されるゲームサービスであり、（例えば前述の応用例における）父親は、そのサービスを息子に権限委譲するサブスクリプション保持者である。
【００４０】
サービスプロバイダＳＰは、父親のサブスクリプションに関する情報を保持し、これには、例えば加入後に、サービスプロバイダＳＰによって発行されたデレゲーション・クレデンシャルが含まれる。クレデンシャルを使用することにより、父親は、アイデンティティプロバイダＩｄＰを設定する。図５に示す具体例では、デレゲート「son」を含むエントリがＩｄＰにおいて作成され、デレゲーションの起点を示すリンクが息子と父親の間に作成され、サービス名等を含む証明書がサービスプロバイダＳＰによって発行され、最後に、その証明書に対して規則のセットが設定される。すなわち、ＩｄＰにおいて、デレゲートのデジタルアイデンティティが、サービスと、デレゲーションの証明書とに結合される。
【００４１】
サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰが上記のように設定されると、デレゲーションがアクティブになるので、父親は、デレゲーション・クレデンシャルの秘密鍵を息子に与えることができる。息子がサービスプロバイダＳＰと交信してサービスを要求すると（息子からＳＰへ向かう上側の矢印で示す）、ＳＰはＩｄＰと交信して息子を認証する。このステップについては、図７に関連してさらに詳細に説明する。デレゲーションの証明書に基づいてＳＰに対する認証が成功した後、息子は、サービスへのアクセスが許可され（それにより、ＩｄＰにおいて当該サービスと当該デレゲートに対して設定された認可規則が考慮される）、サービス消費を開始することができる（ＳＰから息子へ向かう下側の矢印で示す）。
【００４２】
図６に、リソース所有者がデレゲーションを設定する際の、セットアップ段階のメッセージフローを示す。まず、リソース所有者は、サービスプロバイダと交信し、自分のクレデンシャルを用いて認証を行う（その手順は本発明の範囲外である）。すると、リソース所有者に対して、クレデンシャルのセット、すなわち証明書および（証明書内の公開鍵に対応する）秘密鍵が発行される。このためには、各サービスプロバイダの独自の（例えばウェブベースの）プロトコルを用いてもよい。その後、２個の暗号鍵を用いて、非対称暗号方式により、デレゲーションにアクセスしようとするユーザの正当性を確認することができる。
【００４３】
所有者は、これらの鍵を取得した後、デレゲートのアイデンティティ管理システムに対して、証明書を送り、その証明書に対する規則のセットを設定することにより、設定を行う。このステップで、所有者は、複数の証明書を提示し、それらのすべてのデレゲーションに対して共通のデレゲーション規則を設定することも可能である。例えば、このためにＳＡＭＬ(Security Assertion Markup Language)やウェブベースのプロトコルを用いてもよい。
【００４４】
なお、これはセキュリティリスクを生じないことに注意すべきである。というのは、攻撃は、デレゲートが望まないサブスクリプションへのデレゲーションを提供するような攻撃であり（これは、デレゲートに対して、プライバシー等の危険をもたらさない）、また、証明書は、サービスプロバイダによって発行され、所有者のアイデンティティを含むので、アイデンティティプロバイダは、ローカルに、あるいは所有者のアイデンティティプロバイダにおいて、所有者を認証した後で、デレゲーション規則の設定を許可することができるからである。この手順もまた、本発明の範囲外である。サービスプロバイダおよびアイデンティティプロバイダが設定されると、デレゲーションがアクティブになるので、所有者は、秘密鍵をデレゲートに（例えば物理的な引き渡しによって）与えることができる。
【００４５】
図７は、デレゲートが、デレゲーションを受けたサービスにアクセスしようとする場合を例示している。最初のステップで、（サービスプロバイダ固有のプロトコルを用いることにより）サービスプロバイダと交信し、サービスを要求する。通常のアイデンティティ管理の場合と同様に、ＳＰは、アイデンティティプロバイダと交信してユーザを認証する。この認証の一部として、ＩｄＰは、デレゲーションを認識し、それに関連する規則がさらに存在するかチェックする。該当する場合には、アイデンティティプロバイダは、デレゲートの認証結果とともに、デレゲーションに対する追加的な制限と、デレゲーションの証明書をＳＰへ送る（ＳＰもまた発行者としてその証明書を保存しているので、このステップは、単に証明書への参照で置き換えてもよい）。
【００４６】
そして、ＳＰはデレゲートと交信し、デレゲートがデレゲーションの証明書に基づいて（２回目の）認証を行うことを要求する。このステップは、デレゲートがデレゲーションを複製しているのではなく、真正なデレゲートであることを保証する。そして、デレゲートは、秘密鍵を用いてＳＰからのチャレンジに応答し、サービス消費を開始することができる。ＳＰはデレゲーションを所有者のアカウントに関連づけることができるので、所有者には、デレゲートによってアクセスされたサービスに対する課金もなされる。
【００４７】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと理解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【技術分野】
【０００１】
本発明は、リソース、特にサービスのデレゲーション（delegation）を実行する方法に関する。ここで、ユーザ、すなわちリソース所有者は、サービスプロバイダによって提供されるリソースにアクセス可能であり、リソースは、デレゲーション・クレデンシャル(delegation credentials)を使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲される。
【０００２】
また、本発明は、リソース、特にサービスのデレゲーションを実行するシステムに関する。該システムは、リソースを提供するサービスプロバイダを備え、ユーザ、すなわちリソース所有者は該リソースにアクセス可能であり、リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲される。
【背景技術】
【０００３】
それぞれの個人に関連する基本設定やデータは、ＩＳＰ（インターネットサービスプロバイダ）におけるアカウントと、そのＩＳＰによって提供されるサービスに関連するサブスクリプションとの間の区別をやや困難にしている。個人のプロファイルはサブスクリプションに結合されるので、トランスポート・サブスクリプション（ネットワークアクセス）が共有され、別々のサービスプロバイダ・サブスクリプションが保持されることが比較的普通である。連合アイデンティティ(federated identity)環境では、ユーザのプロファイルは相異なるサブスクリプションに結合される。これは周知の問題であり、リバティ・アライアンス(Liberty Alliance)（http://www.projectliberty.org を参照）やＯｐｅｎＩＤ（http://www.openid.net）で提案されているような解決法が既に存在するが、デレゲーション（delegation, 権限委譲）によるサブスクリプション共有の問題は依然として未解決である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、本発明の目的は、頭書のような、リソースのデレゲーションを実行する方法およびシステムにおいて、ユーザのプライバシーを保護しデレゲーションのプロセスおよび状況に対する厳格な管理を可能にしながら、ユーザがリソースへのアクセスを他者と共有できるように、改良を行うことである。
【課題を解決するための手段】
【０００５】
本発明によれば、上記の目的は、請求項１の構成を有する方法によって達成される。この請求項に記載の通り、本方法は、サービスプロバイダにおいてデレゲートの認証を実行するステップと、認可規則に基づいてアイデンティティプロバイダにおいてデレゲートの認可を実行するステップとを備えたことを特徴とする。
【０００６】
また、上記の目的は、独立請求項１８の構成を有するシステムによって達成される。この請求項に記載の通り、本システムは、前記サービスプロバイダがデレゲートの認証を実行するように構成され、アイデンティティプロバイダが設けられ、認可規則に基づいてデレゲートの認可を実行するように構成されたことを特徴とする。
【０００７】
本発明によって初めて認識されたこととして、従来のメカニズムでは、デレゲーションによるリソース共有が、十分にフレキシブルかつセキュアな形で可能となっていない。本発明は、ユーザが他のユーザに対してサブスクリプションや支払のデレゲーションを行うことができる方法やシステムを構成するために、アイデンティティ管理機能、サービスプロバイダ・サブスクリプション管理、および暗号プリミティブをどのように組み合わせればよいかを扱う。ユーザを認証しデレゲーションを確認する権限をサービスプロバイダに残しながら、アイデンティティプロバイダが、アクセス制御規則、すなわち認可規則に基づいて、アクセスの許可ないし拒否をすることが可能である。このプロセスは、認証(authentication)を認可(authorization)から分離することで、システムにフレキシビリティを付加する。サービスプロバイダは必ずしも認可の規則を知る必要はなく、また、アイデンティティプロバイダは、サービスアクセスのためのユーザ認証に関与しなくてもよい。
【０００８】
また、サービス消費のための認証と認可とを分けることで、サービスプロバイダがデレゲートユーザを知る必要はなく、サブスクライバとの関係だけを知ればよいという、付加的なプライバシー上の利益が得られる。従来技術によれば、同一サブスクリプションの下で複数ユーザをサポートする通常の方法は、サービスプロバイダ側にこの関連づけの情報をもたせるか、あるいは、相異なるユーザ間でクレデンシャルを共有する（したがってそれらのユーザを区別しない）か、のいずれかであった。メッセージや証明書に署名・確認するというような暗号プリミティブの形でデレゲーション・クレデンシャルを使用することにより、本発明による方法およびシステムの健全性およびセキュリティが保証される。
【０００９】
複数のコンフィギュレーションと、相異なるデレゲーションに対するアカウントユーザによる管理を可能にした、フレキシブルなデレゲーションの方法およびシステムが提供される。これは、リソースやサブスクリプションの保持者が、ユーザのクレデンシャルやアイデンティティを単に提供するのではなく、そのサブスクリプションに結合させる新規なクレデンシャルを発行するように、サービスに対して要求することができる、ということを意味する。そして、このようなクレデンシャルは、サービスにアクセスするために、デレゲーションを受けたエンティティによって使用されることが可能である。この新規ユーザはトランザクションに直接には関与していないので、サービスプロバイダは、リソースの保持者あるいはサブスクライバによってその新規ユーザが当該アカウントの使用を許可されていることは知るが、その新規ユーザが誰であるかは必ずしも知らない（責任はサブスクライバ側にある）。
【００１０】
本発明による方法およびシステムは、集中化されたデレゲーション管理を実施する。その結果として、サブスクリプション管理が容易となってユーザ側から見て扱いやすくなるとともに、ユーザのプライバシーが向上し（デレゲートのアイデンティティに関して、強力なセキュリティパラメータを維持しつつ、デレゲートのアイデンティティを保護する）、アイデンティティプロバイダに新規なビジネスモデルを提供するという利点がある。
【００１１】
好ましい実施形態によれば、デレゲートに対して規定される認可規則は、アイデンティティプロバイダに登録されることにより、前記デレゲーション・クレデンシャルを使用する。認可規則は、デレゲートに対して、リソースへの完全アクセスを無制約で許可してもよい。他方、デレゲートに対して規定される認可規則は、リソースアクセス制限を含むことも可能である。
【００１２】
別の好ましい実施形態によれば、リソースへのアクセスは、サービスへのサブスクリプションを保持するリソース所有者によって確立されてもよい。リソース所有者は、例えば、サービスプロバイダによって提供されるサービスに直接に加入していてもよい。
【００１３】
好ましくは、サービスプロバイダによって、デレゲーション・クレデンシャルが発行され、（認証プロセスにおいて）確認される。デレゲーションの際に、デレゲーション・クレデンシャルは、サブスクリプション保持者等のリソース所有者から、デレゲートに渡されてもよい。すなわちこの場合、サービスプロバイダが、認証の権限を保持する。サービスプロバイダは、サービスにアクセスするためにデレゲートによって使用されるクレデンシャルを保持・作成・チェックする。ただし、認可を提供する（その場合にアクセスを許可することができる）アクセス制御ポリシーを別個とし、アイデンティティプロバイダに保存してもよい。その場合、サービスプロバイダは、認可規則（これは通常、サービスプロバイダの領域外にあるグループ、コンテクスト等に基づく）を扱う必要がなく、ユーザの認証と、サブスクリプションへの結合だけを扱うので有利である。
【００１４】
セキュリティを高めるため、サービスプロバイダにおけるデレゲートの認証は、デレゲーション・クレデンシャルに基づいて実行してもよい。別法として、あるいはこれに加えて、デレゲートがサービスプロバイダにおけるサービスを要求した場合、アイデンティティプロバイダにおいて、デレゲーション・クレデンシャルに基づいてデレゲートの認証を実行してもよい。さらに、認可をサービスプロバイダにおいて実行してもよい。その場合、責任に関する利点がある。というのは、認可の部分がサービスプロバイダにおいてなされているので、アイデンティティプロバイダは、ユーザのいかなる違反にも責任を問われないと主張することができるからである。
【００１５】
好ましい実施形態によれば、アイデンティティプロバイダにおいてユーザアカウントを設けてもよい。各アカウントは、ユーザの別のデジタルアイデンティティに結合される。このような場合、デレゲートに対して規定される認可規則は、デジタルアイデンティティごとに固有の方法で規定されてもよい。特に、サービスプロバイダにおけるデレゲートの認証は、デレゲートのデジタルアイデンティティに基づいてもよい。具体的には、あるデジタルアイデンティティで、あるリソース／サービスのアクセスまたは使用を許可し、別のデジタルアイデンティティに対しては、このようなアクセス／使用を拒否してもよい。なおこの点に関して、ユーザのデジタルアイデンティティと、物理的な個人との間が明確に分離されていることに注意すべきである。物理的な一個人は複数のデジタルアイデンティティを有し得るので、場合によっては、あるデジタルアイデンティティではサービスにアクセス不可能だが、別のデジタルアイデンティティでは可能であることが起こり得る。
【００１６】
なお、アイデンティティプロバイダは、同時に複数のサービスに対するアクセス制御を処理するために使用することも可能である。その場合、同じデレゲーションの下で同一ユーザが相異なるサービスにアクセスするために、同じ認可規則を相異なるクレデンシャルの下で使用することができる。他方、複数のデレゲーションに適用可能な一般的な認可規則を指定してもよい。いずれの場合でも、リソース保持者は、サービスプロバイダと交信せずに、デレゲーションの認可を変更することができる。
【００１７】
アクセス制御属性を変えた複数の具体例が可能である。例えば、リソース保持者は、複数の側面に基づいて認可規則を決めることができる。特に、認可規則は、デレゲーションがなされるサービスの種別に基づいてもよい。また、デレゲーションがなされるリソースへのアクセスをデレゲートに許可する時間を指定してもよい。また、ユーザを指定してもよく、その際、ユーザのデジタルアイデンティティを考慮に入れてもよい。さらに、例えば料金限度を指定することで、リソース／サービスのアクセスまたは使用の料金を認可規則内で指定してもよい。なお、列挙した基準は単なる例示と理解すべきである。すなわち、認可規則を規定するために想定される他の基準も考えられるが、個々のニーズや条件に従って指定すればよい。
【００１８】
高度のセキュリティを備え実施の容易な好ましい実施形態によれば、デレゲーション・クレデンシャルは、証明書および秘密鍵を含んでもよい。その場合、デレゲーションにおいて鍵を渡される各エンティティは、デレゲーションがなされたリソースを使用することができる。
【００１９】
認可処理を容易にするため、認可情報をアイデンティティプロバイダに集中化し、その情報を各デレゲートごとに集約してもよい。別法として、あるいはこれに加えて、認可情報を、各サービスごとに集約してアイデンティティプロバイダに集中化してもよい。ただし、認可規則の分散管理も可能である。
【００２０】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および１８に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００２１】
【図１】複数のアイデンティティを有する家庭の例の概略図である。
【図２】本発明による方法が適用可能な種々のデレゲーション例の場面を例示する図である。
【図３】本発明の第１実施形態によるメッセージシーケンスチャートの例を示す図である。
【図４】本発明の実施形態による応用場面を例示する図である。
【図５】デレゲートによるサービスアクセスを模式的に例示する図である。
【図６】ユーザがデレゲーションを設定するセットアップ段階におけるメッセージフローを示す図である。
【図７】デレゲーションがなされたサービスにデレゲートがアクセスするサービス消費段階におけるメッセージフローを示す図である。
【発明を実施するための形態】
【００２２】
以下では、ＩＰＴＶ分野におけるデレゲーションに対する具体的使用例の場面について説明する。想定しているデレゲーションは、サービスへのサブスクリプション共有の特別な場合を扱う。この使用例では、デレゲーション場面におけるアクセス制御を扱う統括エンティティとして、アイデンティティ管理(Identity Management)基盤を導入する。
【００２３】
今日の一般的なＩＰＴＶの利用場面では、サービスに対するユーザごとの認証が存在しないので、通常、基本サービスへのユーザサブスクリプションが共有される。しかしこれは、アイデンティティ管理および個人化サービスの普及に伴って変化するだろうと期待される。これまでは、ユーザがサービスにアクセスするための識別子であったユーザサブスクリプションでは、もはや不十分となるであろう。
【００２４】
ＩＰＴＶは、デジタルテレビによって現在提供されているものをはるかに超えたサービスをサポートする。そのようなサービスとしては、今日のシステムによって既に提供されているものに加えて、ＩＰ電話、ゲームサービスが挙げられ、第三者サービスへのアクセスさえも含まれる。ＩＰＴＶプロバイダと外部サービスとのインタラクションは、以下で詳述する使用例において扱われる重要な側面である。
【００２５】
ユーザは、ＩＰＴＶプロバイダおよびサービスプロバイダへの相異なるサブスクリプションについて、それらが同一事業者によって提供されているか、それとも第三者プロバイダによって提供されているかにかかわらず、それらのすべてのサブスクリプションを管理しなければならない。アイデンティティ管理は、ユーザアカウント管理を容易にする共通の基盤を提供することができる。特に、アイデンティティ管理基盤とやり取りするサービスは通常、アイデンティティの概念にも依存しているので、相異なるデジタルアイデンティティに結合したユーザサブスクリプションの管理は、もう１つの重要な問題となる。
【００２６】
説明する場面では、ユーザとそのデジタル表現、すなわち仮想アイデンティティ（virtual identity, ＶＩＤ）とは別個のエンティティであると仮定する。ユーザはサブスクリプションを保持する。サブスクリプションは、ユーザとそのサービスプロバイダとの間で結ばれる契約であるが、その場合、必要に応じて、そのＶＩＤとサブスクリプションを関連づけることができる。図１は、ある家庭を表しており、本発明による方法の、ＩＰＴＶに関連する実施形態を説明するために用いられる。図１には、契約を締結しサービスへのサブスクリプションを形成することが可能な複数のユーザが、デジタルアイデンティティとともに表されている。デジタルアイデンティティは、ユーザがそれらのサービスにおいて認識され、個人化・履歴情報、およびおそらくは認証クレデンシャルを保持する場合に用いられる。より具体的には、例示した家庭には父親、母親および息子の３人がいる。これらの個人のデジタルアイデンティティは、彼らの家族および職業に関係する。例えば、父親には、（家族的背景に関する）「father」（父親）というデジタルアイデンティティと、（職業的背景に関する）「employee」（会社員）というデジタルアイデンティティが関連づけられる。母親である個人に関しては、「mother」（母親）および「wife」（妻）という２つの家族関連のデジタルアイデンティティが設けられている。なお、図１に示すデジタルアイデンティティは単なる例示の目的で選択されており、さまざまなユーザコンテクスト（会員、スポーツ等）に関係する他の多くのデジタルアイデンティティを想定することができる。
【００２７】
図２に、例えばＩＰＴＶとの関連で出現し得るいくつかのデレゲーション場面を詳細に示す。図２の上部には、３つの相異なるリソースあるいはサービスが示されており、それらは電話サービス（左）、インターネットサービス（中央）およびクレジットカードによる課金や購買のサービス（右）である。課金サービスの場合において、ユーザ（例示したケースでは母親）は、他のサービスや電子商取引の支払に、自己のアカウントを使用する権限を委譲することが考えられる。
【００２８】
サービスの下に、サブスクリプションに責任をもつアカウントの保持者と、主なデジタルアイデンティティが示されている。場合によっては、複数のデジタルアイデンティティがサブスクリプションに直接結合されることもある。サブスクライバは、サブスクリプションの使用を他のデジタルアイデンティティに権限委譲する。その中には、自分自身に属するデジタルアイデンティティと、他の信頼されたエンティティに属するデジタルアイデンティティとがある。図２に例示した使用例では、ユーザがサブスクリプションを形成する形式は、サブスクリプションからデジタルアイデンティティへのマッピングとは比較的独立している。
【００２９】
図２の左に示す例において、父親は、電話サービスのサブスクライバであるが、そのサービスサブスクリプションを母親に完全に権限委譲している。電話サービスに「mother」として認証されると、このユーザはサービスへの完全アクセスを取得し、その場合、父親のアカウントの下で課金されることになる。
【００３０】
デレゲーション問題に対する１つの拡張として、デレゲーションごとに、より複雑なアクセス制御規則を追加することがある。上記の例を用いると、電話サービスへのサブスクライバである「father」は、電話サービスの使用を「son」（息子）に権限委譲するが、ユーザ「son」がそのサービスで使える金額を制限している。もう１つの制限されたデレゲーションとして示されているのは、「employee」として認証された父親に関するものであり、この「employee」は息子に電話することのみが許可される。インターネットサービスに関しては、息子は２つの相異なる制限に服している。sonとしてのアイデンティティにおいて、制限は特定のサービス種別に基づく（この場合、例えば、ある一定のゲームサービスへのアクセスが拒否される）。他方、student（学生）としてのアイデンティティにおいて、制限は時間に基づく（例えば、アクセスは、日中の数時間のみ許可される）。
【００３１】
なお、図２の具体的実施形態によれば、購買サービスに関するデレゲーションは、fatherとしてのアイデンティティにおける父親が、デレゲートとして、さらなるデレゲーションを許可する権利が付与されるように実施される。今度も、sonとしてのアイデンティティにおける息子は、この場合は特定のサービスに関して、制限に服している。
【００３２】
図３に、ＩＰＴＶにおけるデレゲーションの具体例に対するメッセージシーケンスチャートを例示する。このチャートは、セットアップ段階というシーケンスに属するメッセージ（破線の上側に示すメッセージ）と、それに続くサービス使用段階というシーケンスに属するメッセージ（破線の下側）とを含む。サブスクリプション所有者は、ＩＰＴＶプロバイダおよび第三者サービスプロバイダの両方へのサブスクリプションを既に有していると仮定する。
【００３３】
セットアップ段階：
Ａ．１）このステップで、サブスクリプションの所有者が、ＩＰＴＶプロバイダにおけるリンクを作成する。これにより、ＩＰＴＶプロバイダがアイデンティティプロバイダにおけるアクセス制御規則に従う限り、別のユーザが所有者のアカウントを使用することが可能となる。
Ａ．２）第三者サービスプロバイダについて、同様の動作が実行される。
Ａ．３）サブスクリプションの所有者が、アイデンティティプロバイダにおいてアクセス制御規則を設定する。この動作は、デレゲートのプロファイルに「認証済み」情報を付加する、あるいは、デレゲートが自分自身のプロファイルに付加するクレデンシャルをデレゲートに与えるものとみなすことができる。なお、このステップで、ユーザは両方のサービスに影響を及ぼす一般的なアクセス制御ポリシーを設定することができる。これは、アイデンティティ管理システムを用いてアクセス制御を実行する利点の１つである。
【００３４】
サービス消費段階：
Ｂ．１）デレゲートがＩＰＴＶサービスにアクセスする。
Ｂ．２）ＩＰＴＶサービスプロバイダが、アイデンティティプロバイダ（これはＩＰＴＶ事業者のドメイン内にあることも可能である）と交信し、ユーザを認証する。この場合、ユーザはそのアイデンティティプロバイダで既に認証されていると仮定する。そうでない場合には、この時に認証を行うことも可能である。
Ｂ．３）アイデンティティプロバイダは、ユーザが認証されていることが確認できたら、当該デレゲーションを用いた当該サービスへのアクセスに対するアクセス制御の制限を確認する。これに基づいて、サービスへのアクセスを許可または拒否する。
【００３５】
さらに、ＩＰＴＶプロバイダは、ユーザにアクセスを提供する前に、サービスデレゲーションに関する他のアクセス制御クレデンシャルに対するチェックをしてもよい。
【００３６】
ステップＢ．４）、Ｂ．５）およびＢ．６）は、第三者サービスプロバイダに関連する同様の処理を示している。なお、認可制御を主としてアイデンティティ管理システムによって実行し、ポリシーはデレゲーション間で共有することも可能である（ユーザサブスクリプション管理の手間が軽減される）。
【００３７】
図４は、本発明の別の実施形態による応用場面を例示している。最初のステップで、ユーザがサービスに加入し、サービスは、そのユーザのサブスクリプションのアクセスおよび管理のためのクレデンシャルを発行する。ステップ２で、ユーザは、サブスクリプションのデレゲーションをサービスに要求し、サービスプロバイダからクレデンシャルのセット（証明書および秘密鍵）を受け取る。秘密鍵を有する者は誰でも、そのデレゲーションを使用することができる。
【００３８】
ステップ３で、デレゲートまたはサブスクリプション所有者のいずれかが、アイデンティティ管理システムを設定し、このデレゲーションを報告する。これは、このデレゲーションが（本具体例においては）息子に属することが、アイデンティティ管理システムに知らされることを意味する。またステップ３では、所有者が、デレゲーションに対する別個の認可である他のアクセス制御規則を設定してもよい。ステップ４で、所有者は、デレゲートが当該サブスクリプションを用いてサービスにアクセスすることを可能にする秘密鍵をデレゲートに提供する。ステップ５は、サービスがどのようにアクセス可能となるかを示しており、後でさらに詳述する。最後に、サブスクライバは、各デレゲーションおよび自分自身によるサブスクリプションの使用を合算した請求書を受け取る。
【００３９】
図５は、デレゲートによるサービスアクセスを模式的に例示している。すなわち、サービスは、サービスプロバイダＳＰによって提供されるゲームサービスであり、（例えば前述の応用例における）父親は、そのサービスを息子に権限委譲するサブスクリプション保持者である。
【００４０】
サービスプロバイダＳＰは、父親のサブスクリプションに関する情報を保持し、これには、例えば加入後に、サービスプロバイダＳＰによって発行されたデレゲーション・クレデンシャルが含まれる。クレデンシャルを使用することにより、父親は、アイデンティティプロバイダＩｄＰを設定する。図５に示す具体例では、デレゲート「son」を含むエントリがＩｄＰにおいて作成され、デレゲーションの起点を示すリンクが息子と父親の間に作成され、サービス名等を含む証明書がサービスプロバイダＳＰによって発行され、最後に、その証明書に対して規則のセットが設定される。すなわち、ＩｄＰにおいて、デレゲートのデジタルアイデンティティが、サービスと、デレゲーションの証明書とに結合される。
【００４１】
サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰが上記のように設定されると、デレゲーションがアクティブになるので、父親は、デレゲーション・クレデンシャルの秘密鍵を息子に与えることができる。息子がサービスプロバイダＳＰと交信してサービスを要求すると（息子からＳＰへ向かう上側の矢印で示す）、ＳＰはＩｄＰと交信して息子を認証する。このステップについては、図７に関連してさらに詳細に説明する。デレゲーションの証明書に基づいてＳＰに対する認証が成功した後、息子は、サービスへのアクセスが許可され（それにより、ＩｄＰにおいて当該サービスと当該デレゲートに対して設定された認可規則が考慮される）、サービス消費を開始することができる（ＳＰから息子へ向かう下側の矢印で示す）。
【００４２】
図６に、リソース所有者がデレゲーションを設定する際の、セットアップ段階のメッセージフローを示す。まず、リソース所有者は、サービスプロバイダと交信し、自分のクレデンシャルを用いて認証を行う（その手順は本発明の範囲外である）。すると、リソース所有者に対して、クレデンシャルのセット、すなわち証明書および（証明書内の公開鍵に対応する）秘密鍵が発行される。このためには、各サービスプロバイダの独自の（例えばウェブベースの）プロトコルを用いてもよい。その後、２個の暗号鍵を用いて、非対称暗号方式により、デレゲーションにアクセスしようとするユーザの正当性を確認することができる。
【００４３】
所有者は、これらの鍵を取得した後、デレゲートのアイデンティティ管理システムに対して、証明書を送り、その証明書に対する規則のセットを設定することにより、設定を行う。このステップで、所有者は、複数の証明書を提示し、それらのすべてのデレゲーションに対して共通のデレゲーション規則を設定することも可能である。例えば、このためにＳＡＭＬ(Security Assertion Markup Language)やウェブベースのプロトコルを用いてもよい。
【００４４】
なお、これはセキュリティリスクを生じないことに注意すべきである。というのは、攻撃は、デレゲートが望まないサブスクリプションへのデレゲーションを提供するような攻撃であり（これは、デレゲートに対して、プライバシー等の危険をもたらさない）、また、証明書は、サービスプロバイダによって発行され、所有者のアイデンティティを含むので、アイデンティティプロバイダは、ローカルに、あるいは所有者のアイデンティティプロバイダにおいて、所有者を認証した後で、デレゲーション規則の設定を許可することができるからである。この手順もまた、本発明の範囲外である。サービスプロバイダおよびアイデンティティプロバイダが設定されると、デレゲーションがアクティブになるので、所有者は、秘密鍵をデレゲートに（例えば物理的な引き渡しによって）与えることができる。
【００４５】
図７は、デレゲートが、デレゲーションを受けたサービスにアクセスしようとする場合を例示している。最初のステップで、（サービスプロバイダ固有のプロトコルを用いることにより）サービスプロバイダと交信し、サービスを要求する。通常のアイデンティティ管理の場合と同様に、ＳＰは、アイデンティティプロバイダと交信してユーザを認証する。この認証の一部として、ＩｄＰは、デレゲーションを認識し、それに関連する規則がさらに存在するかチェックする。該当する場合には、アイデンティティプロバイダは、デレゲートの認証結果とともに、デレゲーションに対する追加的な制限と、デレゲーションの証明書をＳＰへ送る（ＳＰもまた発行者としてその証明書を保存しているので、このステップは、単に証明書への参照で置き換えてもよい）。
【００４６】
そして、ＳＰはデレゲートと交信し、デレゲートがデレゲーションの証明書に基づいて（２回目の）認証を行うことを要求する。このステップは、デレゲートがデレゲーションを複製しているのではなく、真正なデレゲートであることを保証する。そして、デレゲートは、秘密鍵を用いてＳＰからのチャレンジに応答し、サービス消費を開始することができる。ＳＰはデレゲーションを所有者のアカウントに関連づけることができるので、所有者には、デレゲートによってアクセスされたサービスに対する課金もなされる。
【００４７】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと理解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【特許請求の範囲】
【請求項１】
リソース、特にサービスのデレゲーションを実行する方法において、ユーザ、すなわちリソース所有者は、サービスプロバイダによって提供されるリソースにアクセス可能であり、該リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲され、
前記サービスプロバイダにおいて前記デレゲートの認証を実行するステップと、
認可規則に基づいてアイデンティティプロバイダにおいて前記デレゲートの認可を実行するステップと
を備えたことを特徴とする、リソースのデレゲーションを実行する方法。
【請求項２】
デレゲートに対して規定される前記認可規則が前記アイデンティティプロバイダに登録され、それにより前記デレゲーション・クレデンシャルを使用することを特徴とする請求項１に記載の方法。
【請求項３】
デレゲートに対して規定される前記認可規則がリソースアクセス制限を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
リソースへの前記アクセスが、サービスへのサブスクリプションを保持する前記リソース所有者によって確立されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記デレゲーション・クレデンシャルが前記サービスプロバイダによって発行されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
前記デレゲーション・クレデンシャルが前記デレゲートに渡されることを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
前記サービスプロバイダにおける前記デレゲートの前記認証が前記デレゲーション・クレデンシャルに基づいて実行されることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
前記デレゲートが前記サービスプロバイダにおけるサービスを要求した場合、前記アイデンティティプロバイダにおいて、前記デレゲーション・クレデンシャルに基づいて前記デレゲートの認証が実行されることを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
認可が前記サービスプロバイダにおいて実行されることを特徴とする請求項１ないし８のいずれか１項に記載の方法。
【請求項１０】
ユーザアカウントが前記アイデンティティプロバイダに設けられ、各アカウントが前記ユーザの別のデジタルアイデンティティに結合されることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
デレゲートに対して規定される前記認可規則が、デジタルアイデンティティごとに固有の方法で規定されることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記サービスプロバイダにおける前記デレゲートの認証が、前記デレゲートのデジタルアイデンティティに基づくことを特徴とする請求項１０または１１に記載の方法。
【請求項１３】
前記認可規則が、リソース／サービスの種別、時間、リソース／サービスのユーザ料金等に基づくことを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
【請求項１４】
前記認可規則が、さらなるデレゲーションの許可または拒否に関係することを特徴とする請求項１ないし１３のいずれか１項に記載の方法。
【請求項１５】
前記デレゲーション・クレデンシャルが証明書および秘密鍵を含むことを特徴とする請求項１ないし１４のいずれか１項に記載の方法。
【請求項１６】
認可情報が、各デレゲートごとに集約され、前記アイデンティティプロバイダに集中化されることを特徴とする請求項１ないし１５のいずれか１項に記載の方法。
【請求項１７】
認可情報が、各サービスごとに集約され、前記アイデンティティプロバイダに集中化されることを特徴とする請求項１ないし１６のいずれか１項に記載の方法。
【請求項１８】
リソース、特にサービスのデレゲーションを実行するシステムにおいて、該システムは、リソースを提供するサービスプロバイダを備え、ユーザ、すなわちリソース所有者は該リソースにアクセス可能であり、該リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲され、
前記サービスプロバイダが、前記デレゲートの認証を実行するように構成され、
アイデンティティプロバイダが設けられ、認可規則に基づいて前記デレゲートの認可を実行するように構成されたことを特徴とする、リソースのデレゲーションを実行するシステム。
【請求項１９】
前記アイデンティティプロバイダが、デレゲートに対して規定される前記認可規則を登録し、それにより前記デレゲーション・クレデンシャルを使用することを可能とするように構成されたことを特徴とする請求項１８に記載のシステム。
【請求項２０】
デレゲートに対して規定される前記認可規則がリソースアクセス制限を含むことを特徴とする請求項１８または１９に記載のシステム。
【請求項２１】
ユーザアカウント管理を実行するアイデンティティ管理システムを含むことを特徴とする請求項１８ないし２０のいずれか１項に記載のシステム。
【請求項１】
リソース、特にサービスのデレゲーションを実行する方法において、ユーザ、すなわちリソース所有者は、サービスプロバイダによって提供されるリソースにアクセス可能であり、該リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲され、
前記サービスプロバイダにおいて前記デレゲートの認証を実行するステップと、
認可規則に基づいてアイデンティティプロバイダにおいて前記デレゲートの認可を実行するステップと
を備えたことを特徴とする、リソースのデレゲーションを実行する方法。
【請求項２】
デレゲートに対して規定される前記認可規則が前記アイデンティティプロバイダに登録され、それにより前記デレゲーション・クレデンシャルを使用することを特徴とする請求項１に記載の方法。
【請求項３】
デレゲートに対して規定される前記認可規則がリソースアクセス制限を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
リソースへの前記アクセスが、サービスへのサブスクリプションを保持する前記リソース所有者によって確立されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記デレゲーション・クレデンシャルが前記サービスプロバイダによって発行されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
前記デレゲーション・クレデンシャルが前記デレゲートに渡されることを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
前記サービスプロバイダにおける前記デレゲートの前記認証が前記デレゲーション・クレデンシャルに基づいて実行されることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
前記デレゲートが前記サービスプロバイダにおけるサービスを要求した場合、前記アイデンティティプロバイダにおいて、前記デレゲーション・クレデンシャルに基づいて前記デレゲートの認証が実行されることを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
認可が前記サービスプロバイダにおいて実行されることを特徴とする請求項１ないし８のいずれか１項に記載の方法。
【請求項１０】
ユーザアカウントが前記アイデンティティプロバイダに設けられ、各アカウントが前記ユーザの別のデジタルアイデンティティに結合されることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
デレゲートに対して規定される前記認可規則が、デジタルアイデンティティごとに固有の方法で規定されることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記サービスプロバイダにおける前記デレゲートの認証が、前記デレゲートのデジタルアイデンティティに基づくことを特徴とする請求項１０または１１に記載の方法。
【請求項１３】
前記認可規則が、リソース／サービスの種別、時間、リソース／サービスのユーザ料金等に基づくことを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
【請求項１４】
前記認可規則が、さらなるデレゲーションの許可または拒否に関係することを特徴とする請求項１ないし１３のいずれか１項に記載の方法。
【請求項１５】
前記デレゲーション・クレデンシャルが証明書および秘密鍵を含むことを特徴とする請求項１ないし１４のいずれか１項に記載の方法。
【請求項１６】
認可情報が、各デレゲートごとに集約され、前記アイデンティティプロバイダに集中化されることを特徴とする請求項１ないし１５のいずれか１項に記載の方法。
【請求項１７】
認可情報が、各サービスごとに集約され、前記アイデンティティプロバイダに集中化されることを特徴とする請求項１ないし１６のいずれか１項に記載の方法。
【請求項１８】
リソース、特にサービスのデレゲーションを実行するシステムにおいて、該システムは、リソースを提供するサービスプロバイダを備え、ユーザ、すなわちリソース所有者は該リソースにアクセス可能であり、該リソースは、デレゲーション・クレデンシャルを使用することにより、少なくとも一の他のユーザ、すなわちデレゲートに権限委譲され、
前記サービスプロバイダが、前記デレゲートの認証を実行するように構成され、
アイデンティティプロバイダが設けられ、認可規則に基づいて前記デレゲートの認可を実行するように構成されたことを特徴とする、リソースのデレゲーションを実行するシステム。
【請求項１９】
前記アイデンティティプロバイダが、デレゲートに対して規定される前記認可規則を登録し、それにより前記デレゲーション・クレデンシャルを使用することを可能とするように構成されたことを特徴とする請求項１８に記載のシステム。
【請求項２０】
デレゲートに対して規定される前記認可規則がリソースアクセス制限を含むことを特徴とする請求項１８または１９に記載のシステム。
【請求項２１】
ユーザアカウント管理を実行するアイデンティティ管理システムを含むことを特徴とする請求項１８ないし２０のいずれか１項に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２０１０−５３７３２９（Ｐ２０１０−５３７３２９Ａ）
【公表日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願番号】特願２０１０−５２２２４７（Ｐ２０１０−５２２２４７）
【出願日】平成２０年８月２７日（２００８．８．２７）
【国際出願番号】ＰＣＴ／ＥＰ２００８／００７０２９
【国際公開番号】ＷＯ２００９／０２７０８２
【国際公開日】平成２１年３月５日（２００９．３．５）
【出願人】（５０８３４２１８３）エヌイーシー ヨーロッパ リミテッド (101)
【氏名又は名称原語表記】ＮＥＣ ＥＵＲＯＰＥ ＬＴＤ．
【Ｆターム（参考）】
【公表日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願日】平成２０年８月２７日（２００８．８．２７）
【国際出願番号】ＰＣＴ／ＥＰ２００８／００７０２９
【国際公開番号】ＷＯ２００９／０２７０８２
【国際公開日】平成２１年３月５日（２００９．３．５）
【出願人】（５０８３４２１８３）エヌイーシー ヨーロッパ リミテッド (101)
【氏名又は名称原語表記】ＮＥＣ ＥＵＲＯＰＥ ＬＴＤ．
【Ｆターム（参考）】
[ Back to top ]