(57)【要約】  本明細書では、招待プロセスの間で作成されて送達される、被招待プリンシパルＢに関連付けられている１対のユーザ識別子を導入することによって、共有リソースに対するアクセス制御を招待側プリンシパルＡが行うことを可能にするプリンシパルリファレンス方法が記載される。各識別子は、両パーティ間で共有される。第１の識別子は、両方のプリンシパル、即ち、被招待プリンシパルと招待側プリンシパルのディスカバリサービス（ＤＳ−Ａ及びＤＳ−Ｂ）間で共有される。第２の識別子は、被招待プリンシパルＢも同様に識別するが、招待側プリンシパルのウェブサービスプロバイダ（ＷＳＰ−Ａ）とＤＳ−Ａとの間で共有される。従って、ＤＳ−Ａは、両方の識別子プレーンを分離する、識別子切替ポイントである。これらの２つの識別子の目的は、ディスカバリ及びアクセスのプロセスの間に、任意の１つの識別子が２より多いパーティ間で共有され得るようにすることによって、彼／彼女のプライバシを損なうことなく、被招待プリンシパルＢが参照される／識別されることを可能にすることである。２より多いパーティ間で１つの識別子が共有される場合、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  Ｐｒｏｊｅｃｔのプライバシ保護用件が満たされない可能性があるので、このことは重要である。【選択図】  なし
2008544387.tif 000002
【特許請求の範囲】
【請求項１】
招待側プリンシパルのリソース／属性へのアクセスを被招待プリンシパルに可能にする方法であって、
前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へアクセスすることに招待されている場合の招待プロセス中に、
第１のデバイス（ＰＩＫＳＰ−Ａ）において、前記被招待プリンシパルに関連付けられている第１の識別子を作成し、前記第１の識別子を、第２のデバイス（ＤＳ−Ａ）と第３のデバイス（ＤＳ−Ｂ）へ送達するステップと、
前記第１のデバイス（ＰＩＫＳＰ−Ａ）において、前記被招待プリンシパルに関連付けられている第２の識別子を作成し、前記第２の識別子を、前記第２のデバイス（ＤＳ−Ａ）と第４のデバイス（ＷＳＰ−Ｗ、ＳＰ−Ａ）へ送達するステップと
を備えることを特徴とする方法。
【請求項２】
前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性のディスカバリを試行する場合のディスカバリプロセス中に、
第５のデバイス（ＷＳＣ−Ｂ）において、前記被招待プリンシパルに関連付けられている前記第１の識別子を含む情報を、前記第３のデバイス（ＤＳ−Ｂ）から受信するステップと、
前記第５のデバイス（ＷＳＣ−Ｂ）から、前記第１の識別子を要求メッセージで前記第２のデバイス（ＤＳ−Ａ）へ送信するステップと、
前記第２のデバイス（ＤＳ−Ａ）において、前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へのアクセスが認可されているかを判定するためのアクセス制御を実行するステップと
を更に備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のデバイス（ＤＳ−Ａ）によって認可された後に前記被招待プリンシパルが前記招待側プリンシパルのリソース／属性へのアクセスを試行する場合の前記ディスカバリ及びアクセスプロセス中に、
前記第５のデバイス（ＷＳＣ−Ｂ）において、前記被招待プロセスに関連付けられている前記第２の識別子を含む情報を、前記第２のデバイス（ＤＳ−Ａ）から受信するステップと、
前記第５のデバイス（ＷＳＣ−Ｂ）から、前記第２の識別子を要求メッセージで前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信するステップと、
前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）において、前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へのアクセスが認可されているかを判定するためのアクセス制御を実行するステップと
を更に備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記第１の識別子を要求メッセージで前記第２のデバイス（ＤＳ−Ａ）へ送信するステップは、更に、前記第２のデバイス（ＤＳ−Ａ）へ送信される前記要求メッセージに、第１のセキュリティトークンを追加することを含み、
前記第２の識別子を要求メッセージで前記要求メッセージで前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信するステップは、更に、前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信される前記要求メッセージに第２のセキュリティトークンを追加することを含んでいる
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記第１のデバイス（ＰＩＫＳＰ−Ａ）と前記第２のデバイス（ＤＳ−Ａ）は、単一のデバイスに統合されている
ことを特徴とする請求項１に記載の方法。
【請求項６】
招待側プリンシパルのリソース／属性へのアクセスを被招待プリンシパルに可能にするシステムであって、
前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へアクセスすることに招待されている場合の招待プロセス中に、
前記被招待プリンシパルに関連付けられている第１の識別子を作成し、前記第１の識別子を、第２のデバイス（ＤＳ−Ａ）と第３のデバイス（ＤＳ−Ｂ）へ送達し、
前記被招待プリンシパルに関連付けられている第２の識別子を作成し、前記第２の識別子を、前記第２のデバイス（ＤＳ−Ａ）と第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送達する
ための、メモリ内に記憶されている命令を処理するプロセッサを有する、第１のデバイス（ＰＩＫＳＰ−Ａ）と、
前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性のディスカバリを試行する場合のディスカバリ及びアクセスプロセス中に、
前記第１の識別子を前記第３のデバイス（ＤＳ−Ｂ）から取得し、
前記第１の識別子を含むクエリを前記第２のデバイス（ＤＳ−Ａ）へ送信し、
前記第２の識別子を含む応答を前記第２のデバイス（ＤＳ−Ａ）から受信し、
前記２の識別子を含むクエリを前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信し、
前記招待側プリンシパルの前記リソース／属性を前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）から取得し、
前記招待側プリンシパルの前記リソース／属性を前記被招待プリンシパルへ転送する
ための、メモリ内に記憶されている命令を処理するプロセッサを有する、第５のデバイス（ＷＳＣ−Ｂ）と
を備えることを特徴とするシステム。
【請求項７】
前記第２のデバイス（ＤＳ−Ａ）は、前記被招待プリンシパルが、前記招待側プリンシパルの前記リソース／属性へのアクセスが認可されているかどうかを判定するためのアクセス制御を実行するためのプロセッサを有する
ことを特徴とする請求項６に記載のシステム。
【請求項８】
前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）は、前記被招待プリンシパルが、前記招待側プリンシパルの前記リソース／属性へのアクセスが認可されているかどうかを判定するためのアクセス制御を実行するためのプロセッサを有する
ことを特徴とする請求項６に記載のシステム。
【請求項９】
前記第５のデバイス（ＷＳＣ−Ｂ）は、前記第１の識別子とともに第１のセキュリティトークンを、前記第３のデバイス（ＤＳ−Ｂ）から取得するためのプロセッサを有する
ことを特徴とする請求項６に記載のシステム。
【請求項１０】
前記第５のデバイス（ＷＳＣ−Ｂ）は、前記第２の識別子とともに第２のセキュリティトークンを、前記第２のデバイス（ＤＳ−Ａ）から取得するためのプロセッサを有する
ことを特徴とする請求項６に記載のシステム。
【請求項１１】
前記第２のデバイスは、前記招待側プリンシパルによって招待された前記被招待プリンシパルについての情報を記憶し、かつ、前記被招待プリンシパルが、前記招待側プリンシパルの前記リソース／属性へアクセスすることを招待されていることについての情報を記憶するためのプロセッサを有する
ことを特徴とする請求項６に記載のシステム。
【請求項１２】
前記第１のデバイス（ＰＩＫＳＰ−Ａ）と前記第２のデバイス（ＤＳ−Ａ）は、単一のデバイスに統合されている
ことを特徴とする請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
優先権の主張
本出願は、２００５年６月２３日に出願され、名称「アイデンティティに基づくシナリオにおいてプリンシパルリファレンス提案を向上させる方法」の米国仮出願第６０／６９３，３９６の優先権を主張するものであり、これを参照するにより本明細書に組み込まれる。
【０００２】
本発明の背景
本発明の分野
本発明は、招待側（inviting）プリンシパルが、被招待（invited）プリンシパルの有する自身のリソース／リソースの提供物（offerings）へのアクセスを制御することを可能にすることによって、「プリンシパルリファレンス」のスキームを向上させる方法に関するものである。
【０００３】
従来技術の説明
従来技術と本発明の両方の説明に役立てるために、以下の略語／定義を提供する。
【０００４】
ＡＰ              Ａｔｔｒｉｂｕｔｅ  Ｐｒｏｖｉｄｅｒ（属性プロバイダ）。本願の説明にあたり、この用語はＷｅｂ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ（ウェブサービスプロバイダ）という用語と同義である。
【０００５】
ＡＲ              Ａｔｔｒｉｂｕｔｅ  Ｒｅｑｕｅｓｔｏｒ（属性リクエスタ）。本本願の説明にあたり、この用語はＷｅｂ  Ｓｅｒｖｉｃｅ  Ｃｏｎｓｕｍｅｒ（ウェブサービスコンシューマ）という用語と同義である。
【０００６】
属性              本願の説明にあたり、この用語はリソースと同義である。
【０００７】
信頼の輪          ＬＡＰ仕様と業務契約に基づく取引（ビジネス）関係を有するサービスプロバイダとアイデンティティプロバイダとの連結（federation：連合）であって、これを用いて、ユーザはセキュアかつ明確なシームレスな環境で取引（ビジネス）を処理することができる。
【０００８】
Ｃｏ      Ｔ      Ｃｉｒｃｌｅ  ｏｆ  Ｔｒｕｓｔ（信頼の輪）。
【０００９】
ＤＳ              Ｄｉｓｃｏｖｅｒｙ  Ｓｅｒｖｉｃｅ（ディスカバリ（発見）サービス）。リクエスタが、特定のプリンシパルについてのリソース提供物を発見することを可能にするアイデンティティサービス。
【００１０】
ＤＳＲＯ          ＤＳ  Ｒｅｓｏｕｒｃｅ  Ｏｆｆｅｒｉｎｇ（ＤＳリソース提供物）。ＤＳリソース提供物は、サービスプロバイダ（属性リクエスタ）が所与のプリンシパルのリソース提供物をＤＳから取得するこことを可能にする、データのセットである。
【００１１】
ＤＳＴ            Ｄａｔａ  Ｓｅｒｖｉｃｅｓ  Ｔｅｍｐｌａｔｅｓ（データサービステンプレート）。リソースを探し出してアクセスする場合にパーティ（ＷＳＰ、ＷＳＣ、及びＤＳ）が対話する方法を定義するために、ＬＡＰによって定義された、ＸＭＬベースのプロトコル。
【００１２】
連結              ２つのエンティティ間の関係を確立する動作。ここでは、連結とは、所与のプリンシパルに関してサービスプロバイダとアイデンティティプロバイダとの間の関係を確立する動作である。
【００１３】
ＨＴＴＰ          Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ハイパーテキスト転送プロトコル）。
【００１４】
ＩＤ−ＦＦ        Ｉｄｅｎｔｉｔｙ  Ｆｅｄｅｒａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ（アイデンティティ連結フレームワーク）。
【００１５】
ＩＤ−ＳＩＳ      Ｉｄｅｎｔｉｔｙ  Ｓｅｒｖｉｃｅｓ  Ｉｎｔｅｒｆａｃｅｓ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ（アイデンティティサービスインタフェース仕様）
ＩＤ−ＷＳＦ      Ｉｄｅｎｔｉｔｙ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｆｒａｍｅｗｏｒｋ（アイデンティティウェブサービスフレームワーク）。
【００１６】
アイデンティティプロバイダ（Identity Provider）      信頼の輪の中でプリンシパルの認証を他のサービスプロバイダに提供するアイデンティティサービス。
【００１７】
アイデンティティベースウェブサービス（Identity-Based Web Service）      プリンシパルについての情報を検索するため、プリンシパルについての情報を更新するため、または、プリンシパルの利益になる何らかの動作を実行するために、何らかのリソース上で動作するウェブサービスの抽象的概念。簡単にするために、この用語は略してアイデンティティサービスと呼ばれることがある。
【００１８】
ＩｄＰ            Ｉｄｅｎｔｉｔｙ  Ｐｒｏｖｉｄｅｒ（アイデンティティプロバイダ）。
【００１９】
招待側プリンシパル      自身と他のプリンシパルまたはグループとの間の何らかのオンライン対話を可能にするための招待メカニズムを開始するプリンシパル。
【００２０】
被招待プリンシパル      何らかのオンライン対話に参加するために、他のプリンシパルによって招待されるプリンシパル。
【００２１】
招待              プリンシパル間のオンライン対話を可能にするために、必要な承諾が得られ、かつ要求される連結が確立されることを可能にする、電子的メカニズム。要約すると、招待側プリンシパルによって招待されているプリンシパルの代理として動作するＷＳＣによって、所与のプリンシパルのリソースに対してその後アクセスすることを可能にするプロセスである。
【００２２】
ＬＡＰ            Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  Ｐｒｏｊｅｃｔ（リバティアライアンスプロジェクト）。
【００２３】
名前識別子        サービスプロバイダとプリンシパルのアイデンティティプロバイダとの間で共有される、プリンシパルの識別子。連結プロセスが発生すると、そのような識別子を両パーティが共有する。
【００２４】
ＰＩＫＳ          Ｐｅｏｐｌｅ  Ｉ  Ｋｎｏｗ  Ｓｅｒｖｉｃｅ（自身が知っている人々のサービス）。
【００２５】
ＰＩＫＳＰ        Ｐｅｏｐｌｅ  Ｉ  Ｋｎｏｗ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ（自身が知っている人々のサービスのプロバイダ）。オンライン対話に参加するために、これまでに招待されている他のプリンシパルのリストをプリンシパルのために保持し、認可されているリクエスタがこの情報を利用できるようにする、リバティＩＤ−ＷＳＦサービス。
【００２６】
プリンシパル      そのアイデンティティが認証され得るエンティティ（広義では、ユーザ）。
【００２７】
プリンシパルリファレンス      異なるアプリケーション同士が、招待側ユーザの社会的ネットワーク内で、招待されるユーザと情報（オンラインリソース）を共有し得るが、他方、そのような情報と、その情報が公表される条件が招待側ユーザの（リバリティＩＤ−ＷＳＦの使用を介して）制御下にある、メカニズムである。
【００２８】
ＲｅｓＯｆｆ      Ｒｅｓｏｕｒｃｅ  Ｏｆｆｅｒｉｎｇ（リソース提供物）。
【００２９】
リソース          あるプリンシパルもしくはプリンシパルのグループに関連するデータ、または、あるプリンシパルもしくはプリンシパルのグループの代理として動作するサービス。異なるリソースの例として、アリスの位置、アリスのためのヤフーのインスタントメッセージングサービス、または、ボブのためのヤフーのインスタントメッセージングサービスが挙げられる。
【００３０】
リソース提供物    サービスプロバイダ（属性リクエスタ）が、ＡＰを探し出してＡＰと対話できるようにする、データのセット。これは、リソースとサービスとのアソシエーション（連携）を示しており、リソースＩＤと、サービスタイプと、プロバイダＩＤと、プロトコルのエンドポイントと、そして、サービスの記述とを含んでいる。
【００３１】
ＳＡＭＬ          Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（セキュリティアサーションマークアップ言語）。
【００３２】
セキュリティトークン      セキュリティトークンとは、ユーザ／エンティティに対応する品質に関するステートメントの集まりを示し、セキュリティの目的で使用され得る。
【００３３】
サービスプロバイダ        システムエンティティが引き受ける役割。プリンシパルの立場から見ると、サービスプロバイダは、典型的には、ウェブサイトを提供するサービス及び商品の少なくとも一方である。
【００３４】
ＳｈａｒｅｄＩｄ          ２人のパーティ間で共有される、プリンシパルの識別子。
【００３５】
ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ  −  ＤＳ−Ｂ）（共有ＩＤ）      プリンシパルＢの識別子であって、自身のディスカバリサービスと、別のプリンシパル（典型的には、彼もしくは彼女を招待しているプリンシパル）のディスカバリサービスとの間で、共有される識別子。
【００３６】
ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ  −  ＷＳＰ−Ａ）（共有ＩＤ）      プリンシパルＢの識別子であって、自身のディスカバリサービスと、彼／彼女が別のプリンシパルによって招待されている場合のＷＳＰとの間で、共有される識別子。この識別子は、通常は、新たな識別子を作成する代わりにそれを再利用できるように、ＷＳＰ−ＡとプリンシパルＢのアイデンティティプロバイダとの間で共有される名前識別子と同一である。
【００３７】
シングルサインオン        エンドユーザがある認証を実行し、その結果、異なるリソースやサービスにアクセスできるようになる能力のこと。
【００３８】
ＳＯＡＰ          Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（シンプルオブジェクトアクセスプロトコル）。
【００３９】
ＳＳＯ            Ｓｉｎｇｌｅ  Ｓｉｇｎ−Ｏｎ（シングルサインオン）。
【００４０】
ＵＲＬ            Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ユニフォームリソースロケータ）。
【００４１】
ＷＳＣ            Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｃｏｎｓｕｍｅｒ（ウェブサービスコンシューマ）。システムエンティティがウェブサービスに対する要求を行う場合にシステムエンティティが引き受ける役割。本願の説明において、この用語は、属性リクエスタという用語と同義である。
【００４２】
ＷＳＰ      Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｐｒｏｖｉｄｅｒ（ウェブサービスプロバイダ）。システムエンティティがウェブサービスを提供する場合にシステムエンティティが引き受ける役割。本願の説明において、この用語は、属性プロバイダという用語と同義である。
【００４３】
リバティアライアンスプロジェクト（Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  Ｐｒｏｊｅｃｔ：ＬＡＰ）は、アイデンティティとアイデンティティベースのウェブサービスとに関連付けられている、各種の技術的、ビジネス的、そして政策（ポリシー）的課題に取り組むために創設されている、世界中の組織を代表するコンソーシアムである。この目的を達成するために、ＬＡＰは、アイデンティティとアイデンティティベースのウェブサービスとに関連するオープン技術仕様のセットを開発している。本願に関係があるこの仕様は、非公式にはプリンシパルリファレンス（参照）仕様として知られている（そして、公式には、Ｐｅｏｐｌｅ  Ｉ  Ｋｎｏｗサービス（ＰＩＫＳ）仕様として知られている）。
【００４４】
プリンシパルリファレンス仕様によって、第１のユーザ（招待側プリンシパル）は友人のグループ（被招待プリンシパル）を特定することができ、次いで、これらの友人を招待して自身の１つ以上のリソース／属性にアクセスさせることができる。例えば、プリンシパルリファレンス仕様によって、下記のシナリオが可能になるであろう。１人の友人（被招待プリンシパル）は、もしもあなた（招待側プリンシパル）が偶然近くにいるなら、あなたと一緒にランチを食べたいと思っている。それを調べるには、友人は、あなたの携帯電話会社（モバイルオペレータ）が提供するあなたの位置情報にアクセスする必要がある。それ以外にも、友人は、（あなたのランチ／ディナーのプロファイルにアクセスして）あなたのお気に入りのレストランに関してあなたのプリファレンスを見つけることに関心を持つかもしれない。そして、友人は、あなたに連絡を取る前に、そもそもあなたがランチに出てこられるかどうか（あなたのオンラインカレンダにアクセスして）確認したいかもしれない。この場合、あなたの友人がアクセスしたい共有リソースには、あなたの位置情報と、あなたのランチ／ディナーのプロファイルと、あなたのカレンダ情報とが含まれる。友人が使用している装置のタイプは、ウェブサービスコンシューマ（ＷＳＣ）として機能できるウェブサービス対応の装置であるか、または、ブラウザを含んでいるＨＴＴＰ対応の装置である限り、携帯電話でも、パーソナルコンピュータでも、あるいは他のいかなるタイプの装置であってもよいだろう。
【００４５】
プリンシパルリファレンスは、最初に、ＬＡＰによって「プリンシパルリファレンス（マーケティング要件文書）」バージョン１．０.  ２００４−０９−１７という名称の文書の中で議論された。この文書の内容は、参照することにより本願に組み込まれる。この文書では、２つの異なる属性共有事例について検討している。
【００４６】
１．共有リソースに、ウェブブラウザを介してアクセス可能である（属性はサービスプロバイダによってホストされる）。
【００４７】
２．共有リソースに、ウェブサービスベースのインタフェースを介してアクセス可能である（属性は、ウェブサービスプロバイダ−ＷＳＰによってホストされる）。この議論に反映されている例は、主にこの用途の事例に焦点を当てているが、これは、本発明の適用可能性がこのシナリオに限定されることを示唆しているのではない。逆に、本発明は、共有リソースにブラウザを介してアクセス可能な前者の用途に適用されてもよいであろう。
【００４８】
このプリンシパルリファレンス仕様に従えば、別のプリンシパルに属するリソースにアクセスすることを希望しているプリンシパルは、被招待プリンシパルと命名される（「被招待（invited）」という用語がここで使用されているのは、彼／彼女は、別のプリンシパルのリソースにアクセスすることを許可される前に、そのプリンシパルによって招待される必要があるからである）。そして、被招待プリンシパルの代理としてＷＳＣによってリソースがアクセスされるプリンシパルは、招待側プリンシパルと命名される（このユーザが、その代理としてリソースへのアクセスが実行されるプリンシパル、即ち、被招待プリンシパル、を招待している）。招待されているプリンシパルは、本明細書中、プリンシパルＢと呼ばれることが多い（また、ＤＳ−Ｂ、ＷＳＣ−Ｂ、及びそれに類似した用語も、本明細書中で同様に使用される）。そして、招待側プリンシパルは、プリンシパルＡと呼ばれることが多い（また、ＤＳ−Ａ、ＷＳＰ−Ａ、及びそれに類似した用語も、本明細書中で同様に使用される）。図１（先行技術）は、被招待プリンシパルＢの代理として、ＷＳＰ−Ａ（これはアクセス制御を有しない）から招待側プリンシパルＡのリソースにアクセスするＷＳＣ−Ｂを示す図である。
【００４９】
残念ながら、このプリンシパルリファレンス仕様は複数の問題を抱えており、そのすべてについて、図２Ａ乃至図２Ｃ（先行技術）に示す信号シーケンス図に関して以下に詳細に説明する。この信号シーケンス図は、どのようにしてプリンシパルが招待され、次いで、その招待されたプリンシパルが、招待側プリンシパルの属性／リソースにどのようにしてアクセスするかを示している。ステップは以下の通りである。
【００５０】
１．招待側プリンシパルＡは、ＷＳＰ−Ａへのアクセスを試行する。
【００５１】
２．ＷＳＰ−Ａは、招待側プリンシパルＡに関する認証要求を、招待側プリンシパルＡを介してＩＤＰ−Ａへ送信する。
【００５２】
３．ＩＤＰ−Ａは、招待側プリンシパルＡについての（名前ＩＤとＤＳＲＯ−Ａを備える）認証応答を、招待側プリンシパルＡを介してＷＳＰ−Ａへ送信する。
【００５３】
４．ＷＳＰ−Ａは、招待側プリンシパルＡについてのＰＩＫＳＰのリソース提供物を取得するために、（ＤＳＲＯ−Ａを含む）ＧＥＴ  ＰＩＫＳＰ−Ａ  Ｒｅｓ  ＯｆｆメッセージをＤＳ−Ａへ送信する。
【００５４】
５．ＤＳ−Ａは、招待側プリンシパルＡについてのＰＩＫＳＰのリソース提供物を含む、ＰＩＫＳＰ−Ａ  Ｒｅｓ  ＯｆｆメッセージをＷＳＰ−Ａへ送信する。注意：ステップ４及び５は、ＰＩＫＳＰ−Ａのディスカバリに関連付けられている。
【００５５】
６．ＷＳＰ−Ａは、招待側プリンシパルＡの友人達（招待側プリンシパルＡによって以前に招待されているプリンシパル）のリストを取得するために、クエリメッセージをＰＩＫＳＰ−Ａへ送信する。
【００５６】
７．ＰＩＫＳＰ−Ａは、そのようなリストを含むクエリ応答メッセージを、ＷＳＰ−Ａへ送信する。
【００５７】
８．ＷＳＰ−Ａは、招待側プリンシパルの友人グループの現在のメンバを表示する。注意：被招待プリンシパルＢは、友人グループの現在のメンバではない（ボックス１．０を参照）。
【００５８】
９．招待側プリンシパルは、新たな被招待プリンシパルＢに許可を付与することを、ＷＳＰ−Ａに通知する。
【００５９】
１０．ＷＳＰ−Ａは、（被招待プリンシパルＢを招待することに関連付けられている、ユーザにやさしい文字列によって識別されている）修正メッセージをＰＩＫＳＰ−Ａへ送信する。
【００６０】
１１．ＰＩＫＳＰ−Ａは、招待ＵＲＬであるＩｎｖＵＲＬ１と一時的なユーザ識別子であるｔｅｍｐＩＤ−Ｂとを含む（被招待プリンシパルＢを招待することに関連付けられている）修正応答メッセージを、ＷＳＰ−Ａへ送信する。注意：（１）ＩｎｖＵＲＬ１は、ＰＩＫＳＰ−Ａが、被招待プリンシパルＢに関連する更なる要求を相関する手段を含んでいて、（２）ＩｎｖＵＲＬ１は、ＰＩＫＳＰ−Ａウェブドメインに属し、そして（３）ＷＳＰ−Ａは、ｔｅｍｐＩＤ−Ｂを使用して被招待プリンシパルＢに権限を付与し、ＩｎｖＵＲＬ１を記憶する（ボックス１．１を参照）。
【００６１】
１２．ＷＳＰ−Ａは、（招待ＵＲＬであるＩｎｖＵＲＬ２を含む）招待メッセージを、被招待プリンシパルＢへ送達する。時間が経過する（ボックス１．１を参照）。注意：（１）ＩｎｖＵＲＬ２はＷＳＰ−Ａウェブドメインに属する。
【００６２】
１３．被招待プリンシパルＢは、ＩｎｖＵＲＬ２をＷＳＰ−Ａへ送信する。
【００６３】
１４．ＷＳＰ−Ａは、（リターンＵＲＬ  バックＵＲＬ（backURL）を含む）ＲＥＤＩＲＥＣＴ（リダイレクト）ＩｎｖＵＲＬ１メッセージを、被招待プリンシパルＢを介してＰＩＫＳＰ−Ａへ送信する。注意：（１）バックＵＲＬは、ＷＳＰ−Ａウェブドメインに属しており、ＰＩＫＳＰ−Ａに、被招待プリンシパルＢをＷＳＰ−Ａへ返信することを許容する。
【００６４】
１５．ＰＩＫＳＰ−Ａは、（一時的なユーザ識別子ｔｅｍｐＩＤ−Ｂを含む）被招待プリンシパルＢに関する認証要求を、被招待プリンシパルＢを介してＩＤＰ−Ｂへ送信する。注意：（１）ｔｅｍｐＩＤ−Ｂは、ステップ１１で引用されている一時的なユーザ識別子であり、ＰＩＫＳＰ−Ａが、被招待プリンシパルＢを正しい招待（インビテーション）プロセスと相関することができるように、ＩｎｖＵＲＬ２に関連付けられる。
【００６５】
１６．ＩＤＰ−Ｂは、（ｔｅｍｐＩＤ−Ｂ、名前ＩＤ及びＤＳＲＯ−Ｂを含む）被招待プリンシパルＢのための認証応答を、被招待プリンシパルＢを介してＰＩＫＳＰ−Ａへ送信する。注意：ステップ１５及び１６は、ＰＩＫＳＰ−Ａにおける被招待プリンシパルＢのアイデンティティの連結に関連する（ボックス１．３を参照）。
【００６６】
１７．ＰＩＫＳＰ−Ａは、（ＤＳＲＯ−Ａを含む）ディスカバリ更新メッセージをＤＳ−Ｂへ送信する。注意：ＰＩＫＳＰ−Ａは、ＤＳ−ＢにおいてＤＳＲＯ−Ａを登録する（従って、ＤＳ−Ｂは、どのユーザがＤＳ−Ｂのユーザを招待したのかを把握する）（ボックス１．４を参照）。
【００６７】
１８．ＤＳ−Ｂは、ＯＫメッセージをＰＩＫＳＰ−Ａへ送信する。
【００６８】
１９．ＰＩＫＳＰ−Ａは、ＲＥＤＩＲＥＣＴバックＵＲＬメッセージを、被招待プリンシパルＢを介してＷＳＰ−Ａへ送信する。注意：これは、ＷＳＰ−ＡにおいてＢのアイデンティティの連結を開始する。
【００６９】
２０．ＷＳＰ−Ａは、被招待プリンシパルＢに関する認証要求を、被招待プリンシパルＢを介してＩＤＰ−Ｂへ送信する。注意：ＩＤＰ−Ｂは、ｔｅｍｐＩＤ−Ｂが、ステップ１１で引用されている一時的ユーザ識別子であり、かつＷＳＰ−Ａと関連付けられていることを把握している（ボックス１．５を参照）。
【００７０】
２１．ＩＤＰ−Ｂは、（名前ＩＤ、ｔｅｍｐＩＤ−Ｂ及びＤＳＲＯ−Ｂを含む）被招待プリンシパルＢのための認証応答を、被招待プリンシパルＢを介してＷＳＰ−Ａへ送信する。注意：（１）ステップ２０及び２１は、ＷＳＰ−Ａにおける被招待プリンシパルＢのアイデンティティの連結に関連があり（ボックス１．６を参照）、そして、（２）ＷＳＰ−Ａは、名前ＩＤと共に権限をユーザへ転送し、ｔｅｍｐＩＤ−Ｂを消去する（ボックス１．７を参照）。
【００７１】
２２．被招待プリンシパルＢは、ＷＳＣ−Ｂへのアクセスを試行する。注意：このステップは、招待側プリンシパルＡの属性をディスカバリ（発見）して共有するプロセスを開始する。
【００７２】
２３．ＷＳＣ−Ｂは、被招待プリンシパルＢに関する認証要求を、被招待プリンシパルＢを介して、ＩＤＰ−Ｂへ送信する。
【００７３】
２４．ＩＤＰ−Ｂは、（名前ＩＤとＤＳＲＯ−Ｂとを含む）被招待プリンシパルのための認証応答を、被招待プリンシパルＢを介してＷＳＣ−Ｂへ送信する。注意：これは、ＷＳＣ−ＢへのＳＳＯを完了する（ボックス１．８を参照）。
【００７４】
２５．ＷＳＣ−Ｂは、招待側プリンシパルをＷＳＣ−Ｂへ迎える。
【００７５】
２６．被招待プリンシパルＢは、（招待側プリンシパルＡを含む）自身のリソース／属性にアクセスするために彼らを招待している人々のリストを取得するための要求を、ＷＳＣ−Ｂへ送信する。
【００７６】
２７．ＷＳＣ−Ｂは、（プリンシパルＢを招待している人々のリストと、リスト内の各人のＤＳＲＯとの両方を要求する）ＧＥＴメッセージを、ＤＳ−Ｂへ送信する。
【００７７】
２８．ＤＳ−Ｂは、（招待側プリンシパルＡを含む）招待側プリンシパルの友好名とＤＳＲＯとのリストを、ＷＳＣ−Ｂへ送信する。
【００７８】
２９．ＷＳＣ−Ｂは、（招待側プリンシパルＡを含む）招待側プリンシパルのリストから、どの友人（招待側プリンシパルＡ）が選択されるべきなのかを、被招待プリンシパルＢに問い合わせるメッセージを送信する。
【００７９】
３０．被招待プリンシパルＢは、友人は招待側プリンシパルＡであることをＷＳＣ−Ｂに示す。注意：ＷＳＣ−Ｂは、ＤＳＲＯ−Ａを有する（ボックス１．９を参照）。
【００８０】
３１．ＷＳＣ−Ｂは、招待側プリンシパルＡのどの属性を取得したいか、または、どの属性にアクセスしたいかを、被招待プリンシパルＢに問い合わせるメッセージを送信する。
【００８１】
３２．被招待プリンシパルＢは、「Ｘ」タイプの属性を取得したいことを示すメッセージを、ＷＳＣ−Ｂへ送信する。
【００８２】
３３．ＷＳＣ−Ｂは、招待側プリンシパルＡの「Ｘ」タイプの属性を要求するメッセージ＜ｄｉｓｃｏ＞を、ＤＳ−Ａへ送信する。注意：ＤＳ−Ａは、招待側プリンシパルＡによって招待されている（被招待プリンシパルＢを含む）ユーザを把握しているだけである。従って、招待側プリンシパルＡが、どの特定の属性（群）を、この特定の被招待プリンシパルＢと共有したいと思っているのか、ＤＳ−Ａは把握していない（ボックス１．１０の中の問題１を参照）。
【００８３】
３４．ＤＳ−Ａは、（招待側プリンシパルＡの「Ｘ」タイプの属性のリソース提供物（ＷＳＰ−Ａによって共有されるもの）を含む）メッセージを、ＷＳＣ−Ｂへ送信する。注意：ＤＳ−Ａは、被招待プリンシパルＢへのリファレンスを受信していない。従って、ＤＳ−Ａは、被招待プリンシパルＢに関しては、いかなるタイプのアクセス制御であっても属性（群）のリソース提供物に適用することができない（ボックス１．１１の問題２を参照）。
【００８４】
３５．ＷＳＣ−Ｂは、ステップ３４で受信されている属性のリソース提供物を使用して、「Ｘ」タイプの属性取得メッセージを、ＷＳＰ−Ａへ送信する。
【００８５】
３６．ＷＳＰ−Ａは、「Ｘ」タイプの属性をＷＳＣ−Ｂへ送信する。注意：ＷＳＰ−Ａは、被招待プリンシパルＢへのリファレンスを受信していない。従って、ＷＳＰ−Ａは、被招待プリンシパルＢに関しては、いかなるタイプのアクセス制御であっても属性に適用することができな（ボックス１．１２の問題３を参照）。
【００８６】
３７．ＷＳＣ−Ｂは、被招待プリンシパルＢに「Ｘ」タイプの属性を利用できるようにする。
【００８７】
プリンシパルリファレンス仕様の基盤は、ＰＩＫＳＰ（Ｐｅｏｐｌｅ  Ｉ  Ｋｎｏｗ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）と呼ばれるアイデンティティサービスである。上述のように、ＰＩＫＳＰは、各招待側プリンシパルＡの友人のリストを保持し、かつ招待側プリンシパルＡの代理として招待プロセスを管理する責任を持っている。詳細には、ＰＩＫＳＰの主な機能は以下の通りである。
【００８８】
・ＰＩＫＳＰは、（ＷＳＰ−Ａが、招待側プリンシパルＡが招待プロセスをトリガ（起動）するＷＳＰである場合）被招待プリンシパルＢが自身のアイデンティティをＷＳＰ−Ａと連結することを保証するように機能する。ＰＩＫＳＰは、被招待プリンシパルＢが認証を実行して認可決定を行えるように、被招待プリンシパルＢが（セキュアな識別子の可能性がある）識別子を有することを要求とする。
【００８９】
・ＰＩＫＳＰは、各招待側プリンシパルＡによって招待されるプリンシパルだけでなく、各招待側プリンシパルＡが被招待プリンシパルＢの各々を招待したことがある場合のサービスプロバイダも含むリストを維持するように機能する。（ウェブサービスインタフェースを備える、即ち、ＷＳＰ、ウェブブラウザを用いる、即ち、ＳＰ、またはその両方を備える）サービスプロバイダは、固有のプロバイダ識別子であるプロバイダＩＤを用いて識別される。アイデンティティサービスであることから、ＰＩＫＳＰは、それ自身の個々のユーザについて、招待側プリンシパルのリストを保持すると想定され、即ち、物理的に言えば、同一のＣｏＴの中に複数のＰＩＫＳＰが存在してもよく、その各々は、招待側プリンシパルのグループを扱う。また、ＰＩＫＳＰは、各被招待プリンシパルＢと、それらが招待されている場合のサービスプロバイダ（ＳＰまたはＷＳＰ）との連結識別子を保持することもできる。しかしながら、招待プロセスの前に、被招待プリンシパルＢがＷＳＰ−Ａにおいて識別子を連結していない場合、仕様は、被招待プリンシパルＢが自身のアイデンティティをＷＳＰ−Ａと連結する手段を提供する（図２Ｂに示される招待プロセスの中のステップ２０−２１を参照）。以下に、ＰＩＫＳＰの中に記憶することができるデータの概要を記述する。
【００９０】
プリンシパルＡ１
−Ａ１によって割当てられている被招待プリンシパルＢ１の友好名
−サービスプロバイダ１（ＳＰ１）におけるＢ１の名前識別子
−サービスプロバイダ２（ＳＰ２）におけるＢ１の名前識別子
−サービスプロバイダｎ（ＳＰｎ）におけるＢ１の名前識別子
−Ａ１によって割当てられている被招待プリンシパルＢ２の友好名
−サービスプロバイダｎ（ＳＰｎ）におけるＢ２の名前識別子
−Ａ１によって割当てられている被招待プリンシパルＢｍの友好名
−サービスプロバイダ２（ＳＰ２）におけるＢｍの名前識別子
−サービスプロバイダｎ（ＳＰｎ）におけるＢｍの名前識別子
プリンシパルＡｎ
−Ａｎによって割当てられている被招待プリンシパルＢ１の友好名
−サービスプロバイダ１（ＳＰ１）におけるＢ１の名前識別子
−Ａｎによって割当てられている被招待プリンシパルＢ３の友好名
−サービスプロバイダｎ（ＳＰｎ）におけるＢ３の名前識別子
・ＰＩＫＳＰは、そのいかなるユーザによって招待される各プリンシパルのＤＳにおいても、彼／彼女を招待したことのあるすべてのプリンシパルのＤＳリソース提供物（即ち、所与の被招待プリンシパルのＤＳは、彼／彼女を招待したことのあるすべてのプリンシパルのリファレンスを、彼らのＤＳＲＯによって所有するする）を、登録するように機能する。従って、ディスカバリサービスに関しては、招待プロセスの結果は、被招待プリンシパルのＤＳ（ＤＳ−Ｂ）を、それらを招待したことのあるすべてのプリンシパルに関して更新することになる。招待側プリンシパルのＤＳ（ＤＳ−Ａ）に関しては、何の動作も起こらない。
【００９１】
・ＰＩＫＳＰは、招待側プリンシパルの属性のディスカバリ及び共有においては、何の役割も果たさない。
【００９２】
要約すると、このプリンシパルリファレンススキームは、２つの主な手順、即ち、（１）招待プロセス（ここでは、招待側プリンシパルＡは、所与のＷＳＰ−Ａにおいて、ＰＩＫＳＰ−Ａのサポートを得て、別のプリンシパルＢを招待する）、及び、（２）リソースのディスカバリとリソースへのアクセスのプロセス、を含んでいる。招待プロセスの結果は以下の通りである。
【００９３】
・被招待プリンシパルＢのアイデンティティは、（連結がまだである場合）ＰＩＫＳＰ−Ａと連結される。
【００９４】
・被招待プリンシパルＢのアイデンティティは、（連結がまだである場合）ＷＳＰ−Ａと連結される。
【００９５】
・また、ＰＩＫＳＰは、各ユーザについて、友好名と、そして、それらのアイデンティティも連結されている限り、被招待プリンシパルＢのアイデンティティ管理インフラストラクチャへのポインタと、によって識別される彼／彼女の友人のリストを保持する。このポインタは、それを固有に識別する、ＩＤＰ−ＢのプロバイダＩＤの形式であり得り、また、その他のいかなるタイプのポインタ、例えば、ＤＳ−Ｂ  ＲＯ、を含んでもよいだろう。
【００９６】
共有リソースのディスカバリとそれへのアクセスのプロセスに関して、基本ステップは、ＷＳＣ−Ｂが被招待プリンシパルＢのＤＳ−Ｂにアクセスすることと、（自身のＤＳＲＯを含む）彼／彼女を招待したことのあるプリンシパルのリストを取得することを含んでいる。その後、このデータを用いることで、ＷＳＣ−Ｂは、招待側プリンシパルＡのディスカバリサービスＡへクエリを送信することと、彼／彼女のリソース／属性をディスカバリ／取得することができる（図２Ｃを参照）。
【００９７】
残念ながら、従来のプリンシパルリファレンススキームは、適切に動作させるための複数の様々な機能が不足している。主な問題は、リソースを公表する招待側プリンシパルが、そのようなリソースもしくはそれらのリソース提供物へのアクセスを適切に制御できないことである。この問題は、ＤＳ−Ａ及びＷＳＰ−Ａが、ＷＳＣ−Ｂが代理としてそれらにアクセスしているユーザ（被招待プリンシパルＢ）を知らないことが原因で生じ、そのため、これらのエンティティは、いかなるアクセス制御ポリシーも実行することができない。もう１つの問題は、共有リソースに関する精度の不足である。特に、被招待プリンシパルＢの代理のＷＳＣ−Ｂはリソースにアクセスすることを望む場合、プリンシパルＢを招待したことのある招待側プリンシパル（及びそれらのＤＳＲＯ）のリストを取得するためにＤＳ−Ｂにアクセスしても良い。次に、ＷＳＧ−Ｂは、招待側プリンシパルＡの関連するリソース提供物を取得するために適切なＤＳ−Ａにアクセスしても良い。しかしながら、ＤＳ−Ａは、招待プロセスに関与していることがなく、それは、ＷＳＰ−Ａがホストするすべてのタイプの属性から、招待側プリンシパルＡがどの属性を特定の被招待プリンシパルＢと共有したいと望んでいるのかを判定することができないことを意味する。事実、ＤＳ−Ａは、招待側プリンシパルＡ以外のプリンシパルの代理としてそれにＷＳＣ−Ｂがアクセスしていることを知りもしない。ここで、これらの問題の一部に取り組むために、ＬＡＰは、それ以来、このプリンシパルリファレンス仕様を更新しているが、新たな仕様は非常に複雑で、シグナリングの負荷も重いことに注意されたい。従って、これらの欠点及びその他の欠点に効果的に取り組むことのできるプリンシパルリファレンススキームの必要性が依然として存在する。本発明は、この必要性及び他の必要性に取り組むものである。
【００９８】
本発明の概要説明
招待プロセスの間に作成されて送達される、被招待プリンシパルＢに関連付けられている１対のユーザ識別子を導入することによって、自身の共有リソースに対するアクセス制御を招待側プリンシパルＡが行うことを可能にするプリンシパルリファレンス方法が、本明細書で説明される。各識別子は、両パーティ（当事者）間で共有される。第１の識別子は、両方のプリンシパル、即ち、被招待プリンシパルと招待側プリンシパルのディスカバリサービス（ＤＳ−Ａ及びＤＳ−Ｂ）間で共有される。第２の識別子は、被招待プリンシパルＢも同様に識別するが、招待側プリンシパルのウェブサービスプロバイダ（ＷＳＰ−Ａ）とＤＳ−Ａとの間で共有される。従って、ＤＳ−Ａは、両方の識別子プレーンを分離する、識別子切替ポイントである。これらの２つの識別子の目的は、ディスカバリ及びアクセスのプロセスの間に、任意の１つの識別子が２より多いパーティ間で共有されるようにすることによって、彼／彼女のプライバシを損なうことなく、被招待プリンシパルＢが参照される／識別されることを可能にすることである。２より多い数のパーティ間で１つの識別子が共有された場合、ＬＡＰのプライバシ保護要件が満たされない可能性があるため、このことは重要である。
【００９９】
図面の詳細説明
図３Ａ乃至３Ｃを参照して、どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、そして、次いで、どのようにしてその被招待プリンシパルが、その後、新たなプリンシパルリファレンススキームに従って招待側プリンシパルの属性／リソースにアクセスするかを、ステップ毎で示す信号シーケンス図が示される。ステップは以下の通りである。
【０１００】
１．招待側プリンシパルＡは、ＷＳＰ−Ａへのアクセスを試行する。
【０１０１】
２．ＷＳＰ−Ａは、招待側プリンシパルＡに関する認証要求を、招待側プリンシパルＡを介してＩＤＰ−Ａへ送信する。
【０１０２】
３．ＩＤＰ−Ａは、招待側プリンシパルＡについての（名前ＩＤとＤＳＲＯ−Ａを備える）認証応答を、招待側プリンシパルＡを介してＷＳＰ−Ａへ送信する。
【０１０３】
４．ＷＳＰ−Ａは、招待側プリンシパルＡについてのＰＩＫＳＰのリソース提供物を取得するために、（ＤＳＲＯ−Ａを含む）ＧＥＴ  ＰＩＫＳＰ−Ａ  Ｒｅｓ  ＯｆｆメッセージをＤＳ−Ａへ送信する。
【０１０４】
５．ＤＳ−Ａは、招待側プリンシパルＡについてのＰＩＫＳＰのリソース提供物を含む、ＰＩＫＳＰ−Ａ  Ｒｅｓ  ＯｆｆメッセージをＷＳＰ−Ａへ送信する。注意：ステップ４及び５は、ＰＩＫＳＰ−Ａのディスカバリに関連付けられている。
【０１０５】
６．ＷＳＰ−Ａは、招待側プリンシパルＡの友人達（招待側プリンシパルＡによって以前に招待されているプリンシパル）のリストを取得するために、クエリメッセージをＰＩＫＳＰ−Ａへ送信する。
【０１０６】
７．ＰＩＫＳＰ−Ａは、そのようなリストを含むクエリ応答メッセージを、ＷＳＰ−Ａへ送信する。
【０１０７】
８．ＷＳＰ−Ａは、招待側プリンシパルの友人グループの現在のメンバを表示する。注意：被招待プリンシパルＢは、友人グループの現在のメンバではない（ボックス１．０を参照）。
【０１０８】
９．招待側プリンシパルＡは、新たな被招待プリンシパルＢに許可を付与することを、ＷＳＰ−Ａに通知する。
【０１０９】
１０．ＷＳＰ−Ａは、ユーザにやさしい文字列によって識別される（被招待プリンシパルＢを招待することに関連付けられている）修正メッセージを、ＰＩＫＳＰ−Ａへ送信する。注意：このステップまでは、スキームは以前のものと同じである。
【０１１０】
１１’．ＰＩＫＳＰ−Ａは、招待ＵＲＬであるＩｎｖＵＲＬ１、一時的ユーザ識別子であるｔｅｍｐＩＤ−Ｂ、及び、共有ユーザ識別子であるＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＷＳＰ−Ａ）を含む（被招待プリンシパルＢを招待することに関連付けられている）修正応答メッセージを、ＷＳＰ−Ａへ送信する。注意：（１）ＰＩＫＳＰ−Ａは、被招待プリンシパルＢに割当てられてＷＳＰ−ＡとＤＳ−Ａとの間で共有されることになる共有ユーザ識別子を、作成し、記憶し、送達し（この識別子は、従来のプリンシパルリファレンススキームとの違いを際立たせるため太字で示す）、（２）ＩｎｖＵＲＬ１は、ＰＩＫＳＰ−Ａが被招待プリンシパルＢに関する更なる要求を相関させる手段を含み、（３）ＩｎｖＵＲＬ１は、ＰＩＫＳＰ−Ａウェブドメインに属し、そして、（４）ＷＳＰ−Ａは、ｔｅｍｐＩＤ−Ｂを使用して被招待プリンシパルＢに権限を付与して、ＩｎｖＵＲＬ１を記憶する（ボックス１．１を参照）。
【０１１１】
１２．ＷＳＰ−Ａは、（招待ＵＲＬであるＩｎｖＵＲＬ２を含む）招待メッセージを、被招待プリンシパルＢへ送達する。時間が経過する（ボックス１．２を参照）。注意：（１）ＩｎｖＵＲＬ２は、ＷＳＰ−Ａウェブドメインに属する。
【０１１２】
１３．被招待プリンシパルＢは、ＩｎｖＵＲＬ２をＷＳＰ−Ａへ送信する。
【０１１３】
１４．ＷＳＰ−Ａは、（リターンＵＲＬ  バックＵＲＬを含む）ＲＥＤＩＲＥＣＴ  ＩｎｖＵＲＬ１メッセージを、被招待プリンシパルＢを介してＰＩＫＳＰ−Ａへ送信する。注意：（１）バックＵＲＬは、ＷＳＰ−Ａウェブドメインに属しており、ＰＩＫＳＰ−Ａに被招待プリンシパルＢをＷＳＰ−Ａへ返信することを許容する。
【０１１４】
１５．ＰＩＫＳＰ−Ａは、（一時的なユーザ識別子ｔｅｍｐＩＤ−Ｂを含む）被招待プリンシパルＢに関する認証要求を、被招待プリンシパルＢを介してＩＤＰ−Ｂへ送信する。注意：（１）ｔｅｍｐＩＤ−Ｂは、ステップ１１で引用されている一時的なユーザ識別子であり、ＰＩＫＳＰ−Ａは、被招待プリンシパルＢを正しい招待プロセスと相関させることができるように、ＩｎｖＵＲＬ２に関連付けられる。
【０１１５】
１６．ＩＤＰ−Ｂは、（ｔｅｍｐＩＤ−Ｂ、名前ＩＤ及びＤＳＲＯ−Ｂを含む）被招待プリンシパルＢのための認証応答を、被招待プリンシパルＢを介してＰＩＫＳＰ−Ａへ送信する。注意：ステップ１５及び１６は、ＰＩＫＳＰ−Ａにおける被招待プリンシパルＢのアイデンティティの連結に関連している（ボックス１．３を参照）。
【０１１６】
１７’．ＰＩＫＳＰ−Ａは、（ＤＳＲＯ−Ａ及び共有識別子であるＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）を含む）ディスカバリ更新メッセージをＤＳ−Ｂへ送信する。注意：（１）ＰＩＫＳＰ−Ａは、被招待プリンシパルＢに割当てられてＤＳ−ＡとＤＳ−Ｂとの間で共有されることになる識別子を、作成し、記憶し、送達し（この識別子は、従来のプリンシパルリファレンススキームとの違いを際立たせるため太字で示す）、そして（２）ＰＩＫＳＰ−Ａは、ＤＳ−ＢにおいてＤＳＲＯ−Ａを登録する（従って、ＤＳ−Ｂは、どのユーザがＤＳ−Ｂのユーザを招待しているかを把握している）（ボックス１．４を参照）。
【０１１７】
１８．ＤＳ−Ｂは、ＯＫメッセージをＰＩＫＳＰ−Ａへ送信する。
【０１１８】
１９．ＰＩＫＳＰ−Ａは、ＲＥＤＩＲＥＣＴバックＵＲＬメッセージを、被招待プリンシパルＢを介してＷＳＰ−Ａへ送信する。注意：これは、ＷＳＰ−ＡにおいてＢのアイデンティティの連結を開始する。
【０１１９】
２０．ＷＳＰ−Ａは、被招待プリンシパルＢに関する認証要求を、被招待プリンシパルＢを介してＩＤＰ−Ｂへ送信する。注意：ＩＤＰ−Ｂは、ｔｅｍｐＩＤ−Ｂが、ステップ１１で引用されている一時的ユーザ識別子であり、ＷＳＰ−Ａと関連付けられていることを把握している（ボックス１．５を参照）。
【０１２０】
２１．ＩＤＰ−Ｂは、（名前ＩＤ、ｔｅｍｐＩＤ−Ｂ、そしてＤＳＲＯ−Ｂを含む）被招待プリンシパルＢのための認証応答を、被招待プリンシパルＢを介してＷＳＰ−Ａへ送信する。注意：（１）ステップ２０及び２１は、ＷＳＰ−Ａにおける被招待プリンシパルＢのアイデンティティの連結に関連があり（ボックス１．６を参照）、そして（２）ＷＳＰ−Ａは、名前ＩＤと共に権限をユーザへ転送し、ｔｅｍｐＩＤ−Ｂを消去する（ボックス１．７を参照）。
【０１２１】
２１ａ’．ＰＩＫＳＰ−Ａは、（共有識別子であるＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＷＳＰ−Ａ）及びＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）を含む）ディスカバリ更新メッセージをＤＳ−Ａへ送信する。注意：（１）このメッセージは新たなものであり、従来のプリンシパルリファレンススキームとの違いを際立たせるため太字で示しており、（２）被招待プリンシパルＢの両方の共有識別子は、両方の識別子の間の橋渡しの役割を果たすＤＳ−Ａへ送達され、そして、（３）このメッセージは、ＰＩＫＳＰ−Ａによって非同期的に送信されても良く、また、ステップ１８の直後に送信されても良い。
【０１２２】
２１ｂ’．ＤＳ−Ａは、ＯＫメッセージをＰＩＫＳＰ−Ａへ送信する（このメッセージは、従来のプリンシパルリファレンススキームとの違いを際立たせるため太字で示す）。
【０１２３】
２２．被招待プリンシパルＢは、ＷＳＣ−Ｂへのアクセスを試行する。注意：このステップは、招待側プリンシパルＡの属性をディスカバリ（発見）して共有するプロセスを開始する。
【０１２４】
２３．ＷＳＣ−Ｂは、被招待プリンシパルＢに関する認証要求を、被招待プリンシパルＢを介してＩＤＰ−Ｂへ送信する。
【０１２５】
２４．ＩＤＰ−Ｂは、（名前ＩＤとＤＳＲＯ−Ｂとを含む）被招待プリンシパルのための認証応答を、被招待プリンシパルＢを介してＷＳＣ−Ｂへ送信する。注意：これは、ＷＳＣ−ＢへのＳＳＯを完了する（ボックス１．８を参照）。
【０１２６】
２５．ＷＳＣ−Ｂは、招待側プリンシパルＢをＷＳＣ−Ｂへ迎える。
【０１２７】
２６．被招待プリンシパルＢは、（招待側プリンシパルＡを含む）自身のリソース／属性にアクセスするためにそれらを招待している人々のリストを取得するための要求を、ＷＳＣ−Ｂへ送信する。
【０１２８】
２７．ＷＳＣ−Ｂは、（プリンシパルＢを招待したことのある人々のリストと、そのリストに含まれる各人のＤＳＲＯとの両方を要求する）ＧＥＴメッセージを、ＤＳ−Ｂへ送信する。
【０１２９】
２８’．ＤＳ−Ｂは、（ａ）（招待側プリンシパルＡを含む）招待側プリンシパルの友好名のリストと、（ｂ）（招待側プリンシパルＡを含む）招待側プリンシパルのＤＳＲＯと、（ｃ）ＳｈａｒｅＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）と、そして（ｄ）ＤＳ−Ａにおけるアクセス制御のためのセキュリティトークン（群）とを含むメッセージを、ＷＳＣ−Ｂへ送信する（このメッセージの一部は、従来のプリンシパルリファレンススキームとの違いを際立たせるため太字で示す）。注意：セキュリティトークン（群）については、以下で詳細に説明する。
【０１３０】
２９．ＷＳＣ−Ｂは、（招待側プリンシパルＡを含む）招待側プリンシパルのリストから、どの友人（招待側プリンシパルＡ）が選択されるべきなのかを、被招待プリンシパルＢに問い合わせるメッセージを送信する。
【０１３１】
３０．被招待プリンシパルＢは、友人は招待側プリンシパルＡであることをＷＳＣ−Ｂに示す。注意：ＷＳＣ−Ｂは、ＤＳＲＯ−Ａを有する（ボックス１．９を参照）。
【０１３２】
３１．ＷＳＣ−Ｂは、招待側プリンシパルＡのどの属性を取得したいのか、または、どの属性にアクセスしたいのかを、被招待プリンシパルＢに問い合わせるメッセージを送信する。
【０１３３】
３２．被招待プリンシパルＢは、「Ｘ」タイプの属性を取得したいことを示すメッセージを、ＷＳＣ−Ｂへ送信する。
【０１３４】
３３’．ＷＳＣ−Ｂは、招待側プリンシパルＡの「Ｘ」タイプの属性を要求するメッセージ＜ｄｉｓｃｏ＞を、ＤＳ−Ａへ送信する。注意：このクエリは、（１）ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ｂ、ＤＳ−Ａ）と（２）被招待プリンシパルＢがＤＳ−Ａへのアクセスを有していると断言するセキュリティトークン（群）とを、含んでいる（ボックス１．１０’を参照）。
【０１３５】
３４．ＤＳ−Ａは、（招待側プリンシパルＡの「Ｘ」タイプの属性のリソース提供物（ＷＳＰ−Ａによって共有されるもの）を含む）メッセージを、ＷＳＣ−Ｂへ送信する。注意：ＤＳ−Ａは、被招待プリンシパルＢへの参照を受信んしている（ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ｂ，ＤＳ−Ａ））。従って、ＤＳ−Ａは、被招待プリンシパルＢに関しては、いかなるタイプのアクセス制御であっても属性のリソース提供物に適用することができる。
【０１３６】
３５’．ＷＳＣ−Ｂは、ステップ３４で受信している属性のリソース提供物を使用して、「Ｘ」タイプの属性取得メッセージを、ＷＳＰ−Ａへ送信する。注意：このクエリは、（１）ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ｂ，ＷＳＰ−Ａ）と（２）被招待プリンシパルＢがＷＳＰ−Ａへのアクセスを有していると断言するセキュリティトークンとを含んでいる（ボックス１．１１’を参照）。
【０１３７】
３６．ＷＳＰ−Ａは、「Ｘ」タイプの属性をＷＳＣ−Ｂへ送信する。注意：ＷＳＰ−Ａは、被招待プリンシパルＢへのリファレンスを（ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ｂ、ＷＳＰ−Ａ））を受信している。従って、ＷＳＰ−Ａは、被招待プリンシパルＢに関しては、アクセス制御を属性に適用することができる。
【０１３８】
３７．ＷＳＣ−Ｂは、被招待プリンシパルＢに「Ｘ」タイプの属性を利用できるようにする。
【０１３９】
注意１：図３Ａ乃至３Ｃに示されている、２つの新たな共有識別子のうちいずれかによって代理として要求が行われる被招待プリンシパルＢについての情報を含むことが、（リソースにアクセスすること、あるいは、それらの位置を特定することを目的とする）あらゆる要求において可能であるということを保証するために、関与するエンティティすべて（ＷＳＣ−Ｂ、ＤＳ−Ｂ、ＤＳ−Ａ．．．）の間のインタフェースの修正と、関連するプロトコル（ＳＯＡＰ  Ｂｉｎｄｉｎｇ（バインド）、ディスカバリサービス、ＤＳＴ）の修正とが、必要となる。また、アクセス制御を目的として使用されてもよい適切なセキュリティトークンを含むことが可能であるべきである（図４を参照）。
【０１４０】
注意２：関与するエンティティ（ＷＳＣ−Ｂ、ＤＳ−Ｂ、ＤＳ−Ａ．．．）の各々は、上述の信号シーケンス図に示す各種の信号を、受信し、解析し、送信することが可能な、メモリ内に記憶されている命令を処理するプロセッサを有する。
【０１４１】
上述のように、本発明の重要な特徴は、被招待プリンシパルＢに割当てられ、ＰＩＫＳＰ−Ａによって招待プロセスの間に作成されて送達される、１対の共有ユーザ識別子の導入である（図３Ａ−図３Ｃのステップ１１’、１７’、２１ａ’、２１ｂ及び、２８’を参照）。基本的な概念は、ユーザ（被招待プリンシパルＢ）の代理としてディスカバリのプロセスとリソースへのアクセスのプロセスとが実行されている場合のそのユーザを、関与するパーティ（ＤＳ−Ａ、ＷＳＰ−Ａ）が把握することができるようにすることである。このスキームにおいては、複数のパーティによって共有され得る可能性がある単一の識別子は使用されていないが、それは、そのような単一の識別子は、（プリンシパル識別子は２より多いエンティティによって共有されてはならない）ＬＡＰのプライバシ保護原理に違反する可能性があるからである。代わりに、１対の共有識別子が作成され、その各々が２つのパーティだけに共有される。
【０１４２】
第１のユーザ識別子は、両方のプリンシプル、即ち、被招待プリンシプルと招待側プリンシプルのＤＳ−ＡとＤＳ−Ｂとの間で共有される。この識別子は、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）として示され、また、招待プロセスの間に＜ＤｉｓｃｏｖｅｒｙＵｐｄａｔｅ＞動作によって、両方のディスカバリサービスに送達される（図３Ｂのステップ１７’、２１ａ’及び２１ｂ’を参照）。図３Ｂに示されるように、招待側プリンシパルＡのＤＳ−Ａを更新するために、新たな＜ＤｉｓｃｏｖｅｒｙＵｐｄａｔｅ＞動作が導入される（ステップ２１ａ’及び２１ｂ’を参照）。
【０１４３】
第２のユーザ識別子は、招待側プリンシパルＡのリソースを共有するＷＳＰ−Ａと、彼／彼女のＤＳ−Ａとの間で共有される。この識別子は、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＷＳＰ−Ａ）として示され、招待プロセスの間にＤＳ−ＡとＷＳＰ−Ａとの両方に送達される（図３Ａ−３Ｂのステップ１１’、２１ａ’及び２１ｂ’を参照）。また、図３Ａに示されるように、識別子をＷＳＰ−Ａに送達するために、新たな被招待プリンシパルを招待側プリンシパルのリストに追加する責任を有する＜修正応答（Ｍｏｄｉｆｙ  Ｒｅｓｐｏｎｓｅ）＞動作も使用される（ステップ１１’を参照）。図３Ｂにおいて、招待側プリンシパルＡのＤＳ−Ａを更新するために、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＷＳＰ−Ａ）を含む新たな動作＜ディスカバリ更新（ＤｉｓｃｏｖｅｒｙＵｐｄａｔｅ）＞が使用される（ステップ２１ａ’及び２１ｂ’を参照）。このようにして、ＤＳ−Ａは、両方の識別子プレーンを分離する、被招待プリンシパルのアイデンティティ切替ポイントとなる。
【０１４４】
招待プロセスを完了した後、ＷＳＣ−Ｂは、被招待プリンシパルＢの代理として招待側プリンシパルＡの共有リソースを探し出して消費することができる。これがどのようにして、これら２つの識別子と任意のセキュリティトークン（後述）とを各種のエンティティの間で転送することによって行われ得るかについての簡単な図を、図４に示す（従来のプリンシパルリファレンススキームに対する相違点を太字でマークする）。ステップは、以下の通りである。
【０１４５】
１．ＷＳＣ−Ｂは、（プリンシパルＢを招待したことのある人々のリストと、このリストに含まれる各人についてのＤＳＲＯとを要求する）ＧＥＴメッセージを、ＤＳ−Ｂへ送信する（図３Ｃのステップ２７を参照）。
【０１４６】
２．ＤＳ−Ｂは、ＤＳ−Ａ  ＲＯ、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）、及びセキュリティトークン１を、ＷＳＣ−Ｂへ送信する（図３Ｃのステップ２８’を参照）。
【０１４７】
３．ＷＳＣ−Ｂは、（ＤＳ−Ａ  ＲＯ、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ｂ、ＤＳ−Ａ）、及びセキュリティトークン１を含む）＜ｄｉｓｃｏ＞メッセージを、ＤＳ−Ａへ送信する（図３Ｃのステップ３３’を参照）。
【０１４８】
４．ＤＳ−Ａは、（ＷＳＰ−Ａ  ＲＯ、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）、及びセキュリティトークン２を含む）メッセージを、ＷＳＣ−Ｂへ送信する（図３Ｃのステップ３４を参照）。
【０１４９】
５．ＷＳＣ−Ｂは、（ＷＳＰ−Ａ  ＲＯ、ＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ｂ、ＷＳＰ−Ａ）、及びセキュリティトークン２を含む）クエリメッセージを、ＷＳＰ−Ａへ送信する（図３Ｃのステップ３５’を参照）。
【０１５０】
この転送プロセスについての詳細な説明は、以下の通りである。代理としてＷＳＣ−Ｂが動作しているプリンシパルを招待したことのあるプリンシパルのリストを取得するためにＷＳＣ−ＢがＤＳ−Ｂにアクセスする場合、ＷＳＣ−Ｂは、それらのＤＳリソース提供物だけでなく、ＤＳ−ＡとＤＳ−Ｂとの間で共有されるユーザ識別子と、場合によっては、被招待プリンシパルＡを識別するセキュリティトークンとを、取得する（図４のステップ１及び２を参照）。ＷＳＣ−Ｂは、その識別子と（存在する場合）セキュリティトークンとを使用して、その後ＤＳ−Ａにアクセスする（図４のステップ３を参照）。そのような識別子と、被招待プリンシパルＢに関連付けられているものとを、ＤＳ−Ａが記憶すると、ＤＳ−Ａは、Ａの属性のうち、どのタイプのものが被招待プリンシパルＢと共有されることになるかを把握することができ、そして、適切なアクセス制御を適用することができる（このようにして、図２Ｃのステップ３３及び３４における問題１及び２が解決する）。許可される場合、ＤＳ−Ａは、もう一方の共有ユーザ識別子（及び、場合によっては、新たなセキュリティトークン２）を含むリソース提供物を、ＷＳＣ−Ｂへ送信する（図４のステップ４を参照）。次いで、ＷＳＣ−Ｂは、リソース提供物の中のこの情報を、ＷＳＰ−Ａへ送信する（図４のステップ５を参照）。この情報によって、ＷＳＰ−Ａは、関連する制御のチェックを適用することができる（このようにして、図２Ｃのステップ３６における問題３が解決する）。
【０１５１】
上述のように、ＤＳ−ＡとＤＳ−Ｂとによって発行されているリソース提供物は、通常、セキュリティトークンを含んでいて、このセキュリティトークンは、提供される場合には、これらのリソース提供物に関連付けられているリソースへのアクセスを試行する場合にＷＳＣ−Ｂが行う要求の中に含まれることになる（図４のステップ２及び４を参照）。このセキュリティトークンは、発行者（ＤＳ−Ａ、ＤＳ−Ｂ）によってデジタル的に署名されても良く、それによって、関与するパーティに、アクセス制御ポリシーを適用することを許容することができる。ここで、ＬＡＰによって記述されるシナリオの中で使用されるセキュリティトークンは、このフォーマットに従う。
【０１５２】
＜セキュリティトークン／
対象ステートメント（トークンが適用されるユーザ、そのようなユーザの確認方法等）：ユーザＡ
属性ステートメント（ユーザがアクセスを有するリソース）：ＷＳＰ−Ａ
それ以外の任意のフィールド
／セキュリティトークン＞
本ソリューションに関連付けられるメカニズムの結果として、プリンシパルリファレンスシナリオの中で取り扱われるであろうセキュリティトークンは、以下の情報を搬送する。
【０１５３】
＜セキュリティトークン／
対象ステートメント（トークンが適用されるユーザ、そのようなユーザの確認方法等）：ユーザＢ
属性ステートメント（ユーザがアクセスを有するリソース）：ＷＳＰ−Ａ
それ以外の任意のフィールド
／セキュリティトークン＞
ここで、重要な相違点は、トークンが発行される相手である対象（被招待プリンシパルＢ）は、リソースの所有者（招待側プリンシパルＡ）とは異なっている必要がある、ということである。特に、被招待プリンシパルＢは、セキュリティトークン１においてはＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＤＳ−Ｂ）を用いて識別され、セキュリティトークン２においてはＳｈａｒｅｄＩｄ（Ｂ）（ＤＳ−Ａ、ＷＳＰ−Ａ）を用いて識別される（図４を参照）。トークンのフォーマットは変更されていない（但し、トークンのフォーマットの別のフィールドは変更されている）ことから、この情報は、現行のＬＡＰ仕様（典型的には、ＳＡＭＬアサーション）で使用されているメッセージによって搬送されてもよいだろう。
【０１５４】
理解され得るはずだが、ＤＳ−ＡとＤＳ−Ｂとの内部構造は、本ソリューションによって提案される新たなデータモデル構造を扱うために修正されるべきである。従来のプリンシパルリファレンス仕様は、ＤＳ−Ｂ（被招待プリンシパルのディスカバリサービス）が、ＤＳの各ユーザを招待したことのある招待側プリンシパルについての情報を維持することを、提案する。そして、本ソリューションは、ＤＳ−Ａ（招待側プリンシパルのディスカバリサービス）が、そのユーザによって招待されたプリンシパルについての情報を、また、これらの被招待プリンシパルが、リソース／属性にアクセスすることを招待されたことがある場合に、維持することを提案する。この機能をサポートするために、ＤＳの内部構造は、以下のスキームに従って更新されてもよいだろう。
【０１５５】
被招待プリンシパルのディスカバリサービス（ＤＳ−Ｂ）に関して：
プリンシパルＢ１
B1のRO、(DS-B1 RO、WSP1-B1 RO、WSP2-B1 RO...)
DS-A1 RO、「A1」(友好名)、SharedId(B1) (DS-A1、DS-B1)
DS-A2 RO、「A2」(友好名)、SharedId(B1) (DS-A2、DS-B1)
プリンシパルＢ２
B2のRO、(DS-B2 RO、WSP1-B2 RO、WSP2-B2 RO...)
DS-A1 RO、「A1」(友好名)、SharedId(B2) (DS-A3、DS-B2)
DS-A3 RO、「A3」(友好名)、SharedId(B2) (DS-A3、DS-B2)
ここでＡiは、Ｂjを招待したことのあるプリンシパルである。  そして、招待側プリンシパルのディスカバリサービス（ＤＳ−Ａ）に関して：
プリンシパルＡ１
A1のRO、(DS-A1 RO、WSP1-A1 RO、WSP2-A1 RO...)
SharedId(B1)(DS-A1、DS-B1)
SharedId(B1)(DS-A1、WSP1-A1)、WSP1のタイフ゜のリソース
SharedId(B1)(DS-A1、WSP2-A1)、WSP2のタイフ゜のリソース
SharedId(B1)(DS-A1、WSP3-A1)、WSP3のタイフ゜のリソース
SharedId(B2)(DS-A1、DS-B2)
SharedId(B2)(DS-A1、WSP2-A1)、WSP2のタイフ゜のリソース
SharedId(B2)(DS-A1、WSP3-A1)、WSP3のタイフ゜のリソース
SharedId(B3)(DS-A1、DS-B3)
SharedId(B3)(DS-A1、WSP1-A1)、WSP1のタイフ゜のリソース
SharedId(B3)(DS-A1、WSP23-A1)、WSP2のタイフ゜のリソース
プリンシパルＡ２
SharedId(B2)(DS-A2、DS-B2)
SharedId(B2)(DS-A2、WSP2-A2)、WSP2のタイフ゜のリソース
SharedId(B2)(DS-A2、WSP5-A1)、WSP5のタイフ゜のリソース
SharedId(B3)(DS-A2、DS-B3)
SharedId(B3)(DS-A2、WSP1-A2)、WSP1のタイフ゜のリソース
SharedId(B4)(DS-A2、WSP2-A2)、WSP2のタイフ゜のリソース
ここで、Ｂiは、Ａjによって招待されるプリンシパルである。
【０１５６】
注意：また、ＤＳ−Ａ及びＤＳ−Ｂの論理も、上述のセキュリティトークン情報モデルに従って構成されるセキュリティトークンを生成できるように、修正されるべきである。
【０１５７】
理解されうるはずだが、ＤＳ−Ａについて提案される機能（招待側プリンシパルのディスカバリサービス）は、まさに（少なくとも、それがホストするユーザ情報の点で）ＰＩＫＳＰ−Ａの機能に非常によく似ている。従って、ＤＳ−Ａの役割を果たしているエンティティが、信頼の輪の中でＰＩＫＳＰ−Ａの機能を引き継ぐことが可能である。このようにして、ＰＩＫＳＰ−ＡとＤＳ−Ａとの間の対話は、特に、図３Ｂのステップ２１ａ’と２１ａ’とは、それらが多分同一のエンティティであるだろうから、必要ないであろう（同じことが、ＤＳ−ＢとＰＩＫＳＰ−Ｂとについても可能である）。選択的には、ＰＩＫＳＰ−Ａの役割を果たしているエンティティが、ＤＳ−Ａの機能を引き継いでもよいであろう（同じことが、ＰＩＫＳＰ−ＢとＤＳ−Ｂとについても可能である）。これらの組み合わせの可能性は、２つの機能エンティティ間の論理的な分離が存在するであろうから、純粋に実装上の問題を伴うであろう。
【０１５８】
他の検討材料として、識別子の対を送達する代わりに、同一の識別子が使用され、暗号化スキームによって保護されるということも可能である。しかしながら、このシナリオは、（すべてのパーティが、暗号化されている識別子を復号できるための）複雑な鍵送達メカニズムを必要とするか、または、（ＩｄＰによって提供されるもののような）識別子復号サービスの使用を必要とする可能性があるため、実施が困難であろう。また、このシナリオは、関与するパーティが三者ともそれぞれ（ＤＳ−Ａ、ＤＳ−Ｂ、ＷＳＰ−Ａ）、平文で識別子にアクセスすることができる必要があることから、実施が困難であろう。
【０１５９】
上述のことから、本ソリューションは、プリンシパルリファレンスシナリオにおいて、以下によってアクセス制御を可能にすることが理解されるべきである。
【０１６０】
１．被招待プリンシパルＢを識別し、ディスカバリ及びアクセスのプロセスに関与するすべてのパーティ間で共有される、あいまいな（opaque）ハンドラの作成と確立。これらのあいまいなハンドラは、招待プロセスの間に作成されて分配され、その後、招待側パーティＡに、自身のリソース／属性へのアクセスを試行している被招待プリンシパルＢに関して、アクセス制御を行わせるために、ディスカバリ及びアクセスのプロセスに使用される。
【０１６１】
２．共有リソースとそのようなリソースの所有者（招待側プリンシパルＡ）だけでなく、リソースにアクセスしようとしている被招待プリンシパルＢへのリファレンスも含めるようにセキュリティトークンのフォーマットを変更することによって、現行のセキュリティモデルも向上する。
【０１６２】
最後に、本ソリューションは、多くの望ましい機能と利点とを有しており、その一部を以下に示す。
【０１６３】
・本ソリューションは、ＬＡＰのプライバシ原理を保証しながら、同時に、招待側プリンシパルＡによって使用されることになるアクセス制御メカニズムを可能にする。
【０１６４】
・本ソリューションは、アイデンティティに基づくシナリオに際立った向上をもたらすが、それは、リソースの実際の消費者（サービスプロバイダ）ではなく、代わりに、サービスプロバイダがその代理としてリソースへのアクセスを試行している被招待プリンシパルにおける許可とプライバシ制御とに着目しているるからである。
【０１６５】
・本ソリューションは、ＰＩＫＳＰの役割を果たすためのより適切な候補として、ＤＳの価値を強調するので、スタンドアロンのＰＩＫＳＰを有する必要性をなくせる。
【０１６６】
本発明の一実施形態を添付の図面で示し、上述の詳細説明で記載しているが、本発明は開示されている実施形態に限定されるのではなく、上述の、かつ、請求項によって定義される、本発明の精神から逸脱しない、多くの再構成、修正、置換が可能であるということであることが理解されるべきである。
【図面の簡単な説明】
【０１６７】
【図１】被招待プリンシパルＢの代理として、（アクセス制御を有しない）ＷＳＰ−Ａから招待側プリンシパルＡのリソースにアクセスするＷＳＣ−Ｂを示す図である。
【図２Ａ】どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、従来技術のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを示す信号シーケンス図である。
【図２Ｂ】どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、従来技術のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを示す信号シーケンス図である。
【図２Ｃ】どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、従来技術のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを示す信号シーケンス図である。
【図３Ａ】どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、新規のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを、ステップ毎に示す信号シーケンス図である。
【図３Ｂ】どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、新規のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを、ステップ毎に示す信号シーケンス図である。
【図３Ｃ】どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、新規のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを、ステップ毎に示す信号シーケンス図である。
【図４】どのようにして識別子及びセキュリティトークンが、図３Ａ−３Ｃに示される新規のプリンシパルリファレンススキームを可能にするために、各種のエンティティ間で転送され得るかを示す信号シーケンス図である。
【図１】
2008544387.tif 000003
【図２Ａ】
2008544387.tif 000004
【図２Ｂ】
2008544387.tif 000005
【図２Ｃ】
2008544387.tif 000006
【図３Ａ】
2008544387.tif 000007
【図３Ｂ】
2008544387.tif 000008
【図３Ｃ】
2008544387.tif 000009
【図４】
2008544387.tif 000010
【国際調査報告】
2008544387.tif 000011
2008544387.tif 000012