JP2008544387A - アイデンティティに基づくシナリオにおいてプリンシパルリファレンス（ｒｅｆｅｒｅｎｃｉｎｇ）を向上させる方法 - Google Patents

アイデンティティに基づくシナリオにおいてプリンシパルリファレンス（ｒｅｆｅｒｅｎｃｉｎｇ）を向上させる方法 Download PDF

Info

Publication number
JP2008544387A
JP2008544387A JP2008517626A JP2008517626A JP2008544387A JP 2008544387 A JP2008544387 A JP 2008544387A JP 2008517626 A JP2008517626 A JP 2008517626A JP 2008517626 A JP2008517626 A JP 2008517626A JP 2008544387 A JP2008544387 A JP 2008544387A
Authority
JP
Japan
Prior art keywords
principal
invited
inviting
identifier
wsp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2008517626A
Other languages
English (en)
Inventor
ミゲル−アンヘル モンハス−ジョレンテ，
ヴァレンスエラ， カロリーナ カナレス
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2008544387A publication Critical patent/JP2008544387A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)
  • Purification Treatments By Anaerobic Or Anaerobic And Aerobic Bacteria Or Animals (AREA)

Abstract

本明細書では、招待プロセスの間で作成されて送達される、被招待プリンシパルＢに関連付けられている１対のユーザ識別子を導入することによって、共有リソースに対するアクセス制御を招待側プリンシパルＡが行うことを可能にするプリンシパルリファレンス方法が記載される。各識別子は、両パーティ間で共有される。第１の識別子は、両方のプリンシパル、即ち、被招待プリンシパルと招待側プリンシパルのディスカバリサービス（ＤＳ−Ａ及びＤＳ−Ｂ）間で共有される。第２の識別子は、被招待プリンシパルＢも同様に識別するが、招待側プリンシパルのウェブサービスプロバイダ（ＷＳＰ−Ａ）とＤＳ−Ａとの間で共有される。従って、ＤＳ−Ａは、両方の識別子プレーンを分離する、識別子切替ポイントである。これらの２つの識別子の目的は、ディスカバリ及びアクセスのプロセスの間に、任意の１つの識別子が２より多いパーティ間で共有され得るようにすることによって、彼／彼女のプライバシを損なうことなく、被招待プリンシパルＢが参照される／識別されることを可能にすることである。２より多いパーティ間で１つの識別子が共有される場合、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔのプライバシ保護用件が満たされない可能性があるので、このことは重要である。
【選択図】 なし

Description

優先権の主張
本出願は、２００５年６月２３日に出願され、名称「アイデンティティに基づくシナリオにおいてプリンシパルリファレンス提案を向上させる方法」の米国仮出願第６０／６９３，３９６の優先権を主張するものであり、これを参照するにより本明細書に組み込まれる。
本発明の背景
本発明の分野
本発明は、招待側（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）ハンドラの作成と確立。これらのあいまいなハンドラは、招待プロセスの間に作成されて分配され、その後、招待側パーティＡに、自身のリソース／属性へのアクセスを試行している被招待プリンシパルＢに関して、アクセス制御を行わせるために、ディスカバリ及びアクセスのプロセスに使用される。
２．共有リソースとそのようなリソースの所有者（招待側プリンシパルＡ）だけでなく、リソースにアクセスしようとしている被招待プリンシパルＢへのリファレンスも含めるようにセキュリティトークンのフォーマットを変更することによって、現行のセキュリティモデルも向上する。
最後に、本ソリューションは、多くの望ましい機能と利点とを有しており、その一部を以下に示す。
・本ソリューションは、ＬＡＰのプライバシ原理を保証しながら、同時に、招待側プリンシパルＡによって使用されることになるアクセス制御メカニズムを可能にする。
・本ソリューションは、アイデンティティに基づくシナリオに際立った向上をもたらすが、それは、リソースの実際の消費者（サービスプロバイダ）ではなく、代わりに、サービスプロバイダがその代理としてリソースへのアクセスを試行している被招待プリンシパルにおける許可とプライバシ制御とに着目しているるからである。
・本ソリューションは、ＰＩＫＳＰの役割を果たすためのより適切な候補として、ＤＳの価値を強調するので、スタンドアロンのＰＩＫＳＰを有する必要性をなくせる。
本発明の一実施形態を添付の図面で示し、上述の詳細説明で記載しているが、本発明は開示されている実施形態に限定されるのではなく、上述の、かつ、請求項によって定義される、本発明の精神から逸脱しない、多くの再構成、修正、置換が可能であるということであることが理解されるべきである。
被招待プリンシパルＢの代理として、（アクセス制御を有しない）ＷＳＰ−Ａから招待側プリンシパルＡのリソースにアクセスするＷＳＣ−Ｂを示す図である。 どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、従来技術のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを示す信号シーケンス図である。 どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、従来技術のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを示す信号シーケンス図である。 どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、従来技術のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを示す信号シーケンス図である。 どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、新規のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを、ステップ毎に示す信号シーケンス図である。 どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、新規のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを、ステップ毎に示す信号シーケンス図である。 どのようにして被招待プリンシパルが招待側プリンシパルによって招待され得るか、また、次いで、どのようにして被招待プリンシパルが、その後、新規のプリンシパルリファレンススキームに従って、招待側プリンシパルの属性／リソースにアクセスできるかを、ステップ毎に示す信号シーケンス図である。 どのようにして識別子及びセキュリティトークンが、図３Ａ−３Ｃに示される新規のプリンシパルリファレンススキームを可能にするために、各種のエンティティ間で転送され得るかを示す信号シーケンス図である。

Claims (12)

  1. 招待側プリンシパルのリソース／属性へのアクセスを被招待プリンシパルに可能にする方法であって、
    前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へアクセスすることに招待されている場合の招待プロセス中に、
    第１のデバイス（ＰＩＫＳＰ−Ａ）において、前記被招待プリンシパルに関連付けられている第１の識別子を作成し、前記第１の識別子を、第２のデバイス（ＤＳ−Ａ）と第３のデバイス（ＤＳ−Ｂ）へ送達するステップと、
    前記第１のデバイス（ＰＩＫＳＰ−Ａ）において、前記被招待プリンシパルに関連付けられている第２の識別子を作成し、前記第２の識別子を、前記第２のデバイス（ＤＳ−Ａ）と第４のデバイス（ＷＳＰ−Ｗ、ＳＰ−Ａ）へ送達するステップと
    を備えることを特徴とする方法。
  2. 前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性のディスカバリを試行する場合のディスカバリプロセス中に、
    第５のデバイス（ＷＳＣ−Ｂ）において、前記被招待プリンシパルに関連付けられている前記第１の識別子を含む情報を、前記第３のデバイス（ＤＳ−Ｂ）から受信するステップと、
    前記第５のデバイス（ＷＳＣ−Ｂ）から、前記第１の識別子を要求メッセージで前記第２のデバイス（ＤＳ−Ａ）へ送信するステップと、
    前記第２のデバイス（ＤＳ−Ａ）において、前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へのアクセスが認可されているかを判定するためのアクセス制御を実行するステップと
    を更に備えることを特徴とする請求項１に記載の方法。
  3. 前記第２のデバイス（ＤＳ−Ａ）によって認可された後に前記被招待プリンシパルが前記招待側プリンシパルのリソース／属性へのアクセスを試行する場合の前記ディスカバリ及びアクセスプロセス中に、
    前記第５のデバイス（ＷＳＣ−Ｂ）において、前記被招待プロセスに関連付けられている前記第２の識別子を含む情報を、前記第２のデバイス（ＤＳ−Ａ）から受信するステップと、
    前記第５のデバイス（ＷＳＣ−Ｂ）から、前記第２の識別子を要求メッセージで前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信するステップと、
    前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）において、前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へのアクセスが認可されているかを判定するためのアクセス制御を実行するステップと
    を更に備えることを特徴とする請求項２に記載の方法。
  4. 前記第１の識別子を要求メッセージで前記第２のデバイス（ＤＳ−Ａ）へ送信するステップは、更に、前記第２のデバイス（ＤＳ−Ａ）へ送信される前記要求メッセージに、第１のセキュリティトークンを追加することを含み、
    前記第２の識別子を要求メッセージで前記要求メッセージで前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信するステップは、更に、前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信される前記要求メッセージに第２のセキュリティトークンを追加することを含んでいる
    ことを特徴とする請求項３に記載の方法。
  5. 前記第１のデバイス（ＰＩＫＳＰ−Ａ）と前記第２のデバイス（ＤＳ−Ａ）は、単一のデバイスに統合されている
    ことを特徴とする請求項１に記載の方法。
  6. 招待側プリンシパルのリソース／属性へのアクセスを被招待プリンシパルに可能にするシステムであって、
    前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性へアクセスすることに招待されている場合の招待プロセス中に、
    前記被招待プリンシパルに関連付けられている第１の識別子を作成し、前記第１の識別子を、第２のデバイス（ＤＳ−Ａ）と第３のデバイス（ＤＳ−Ｂ）へ送達し、
    前記被招待プリンシパルに関連付けられている第２の識別子を作成し、前記第２の識別子を、前記第２のデバイス（ＤＳ−Ａ）と第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送達する
    ための、メモリ内に記憶されている命令を処理するプロセッサを有する、第１のデバイス（ＰＩＫＳＰ−Ａ）と、
    前記被招待プリンシパルが、前記招待側プリンシパルのリソース／属性のディスカバリを試行する場合のディスカバリ及びアクセスプロセス中に、
    前記第１の識別子を前記第３のデバイス（ＤＳ−Ｂ）から取得し、
    前記第１の識別子を含むクエリを前記第２のデバイス（ＤＳ−Ａ）へ送信し、
    前記第２の識別子を含む応答を前記第２のデバイス（ＤＳ−Ａ）から受信し、
    前記２の識別子を含むクエリを前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）へ送信し、
    前記招待側プリンシパルの前記リソース／属性を前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）から取得し、
    前記招待側プリンシパルの前記リソース／属性を前記被招待プリンシパルへ転送する
    ための、メモリ内に記憶されている命令を処理するプロセッサを有する、第５のデバイス（ＷＳＣ−Ｂ）と
    を備えることを特徴とするシステム。
  7. 前記第２のデバイス（ＤＳ−Ａ）は、前記被招待プリンシパルが、前記招待側プリンシパルの前記リソース／属性へのアクセスが認可されているかどうかを判定するためのアクセス制御を実行するためのプロセッサを有する
    ことを特徴とする請求項６に記載のシステム。
  8. 前記第４のデバイス（ＷＳＰ−Ａ、ＳＰ−Ａ）は、前記被招待プリンシパルが、前記招待側プリンシパルの前記リソース／属性へのアクセスが認可されているかどうかを判定するためのアクセス制御を実行するためのプロセッサを有する
    ことを特徴とする請求項６に記載のシステム。
  9. 前記第５のデバイス（ＷＳＣ−Ｂ）は、前記第１の識別子とともに第１のセキュリティトークンを、前記第３のデバイス（ＤＳ−Ｂ）から取得するためのプロセッサを有する
    ことを特徴とする請求項６に記載のシステム。
  10. 前記第５のデバイス（ＷＳＣ−Ｂ）は、前記第２の識別子とともに第２のセキュリティトークンを、前記第２のデバイス（ＤＳ−Ａ）から取得するためのプロセッサを有する
    ことを特徴とする請求項６に記載のシステム。
  11. 前記第２のデバイスは、前記招待側プリンシパルによって招待された前記被招待プリンシパルについての情報を記憶し、かつ、前記被招待プリンシパルが、前記招待側プリンシパルの前記リソース／属性へアクセスすることを招待されていることについての情報を記憶するためのプロセッサを有する
    ことを特徴とする請求項６に記載のシステム。
  12. 前記第１のデバイス（ＰＩＫＳＰ−Ａ）と前記第２のデバイス（ＤＳ−Ａ）は、単一のデバイスに統合されている
    ことを特徴とする請求項６に記載のシステム。
JP2008517626A 2005-06-23 2006-06-22 アイデンティティに基づくシナリオにおいてプリンシパルリファレンス（ｒｅｆｅｒｅｎｃｉｎｇ）を向上させる方法 Pending JP2008544387A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US69339605P 2005-06-23 2005-06-23
PCT/IB2006/001712 WO2006136936A1 (en) 2005-06-23 2006-06-22 Method to enhance principal referencing in identity-based scenarios

Publications (1)

Publication Number Publication Date
JP2008544387A true JP2008544387A (ja) 2008-12-04

Family

ID=37052583

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008517626A Pending JP2008544387A (ja) 2005-06-23 2006-06-22 アイデンティティに基づくシナリオにおいてプリンシパルリファレンス（ｒｅｆｅｒｅｎｃｉｎｇ）を向上させる方法

Country Status (7)

Country Link
US (1) US8095660B2 (ja)
EP (1) EP1894181B1 (ja)
JP (1) JP2008544387A (ja)
CN (1) CN101213570B (ja)
AT (1) ATE445888T1 (ja)
DE (1) DE602006009806D1 (ja)
WO (1) WO2006136936A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2937816B1 (fr) * 2008-10-27 2011-08-26 Bouygues Telecom Sa Procede et fonctionnement d'identification convergente d'utilisateur de reseau de communication
US9626651B2 (en) * 2011-02-04 2017-04-18 International Business Machines Corporation Automated social network introductions for e-meetings
US9247290B2 (en) * 2011-02-16 2016-01-26 Sony Corporation Seamless transition between display applications using direct device selection
US9332433B1 (en) 2013-09-30 2016-05-03 Emc Corporation Distributing access and identification tokens in a mobile environment
US9729667B2 (en) * 2014-12-09 2017-08-08 Facebook, Inc. Generating user notifications using beacons on online social networks

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI980427A (fi) * 1998-02-25 1999-08-26 Ericsson Telefon Ab L M Menetelmä, järjestely ja laite todentamiseen
US7325143B2 (en) * 2001-10-15 2008-01-29 Linux Foundation Digital identity creation and coalescence for service authorization
US7610390B2 (en) * 2001-12-04 2009-10-27 Sun Microsystems, Inc. Distributed network identity
JP4186512B2 (ja) * 2002-05-20 2008-11-26 ソニー株式会社 サービス提供システム、機器端末およびその処理方法、認証装置および方法、サービス提供装置および方法、並びにプログラム
US7266582B2 (en) * 2002-08-09 2007-09-04 Sun Microsystems, Inc. Method and system for automating generation of web services from existing service components
US20040260946A1 (en) * 2003-06-20 2004-12-23 Cahill Conor P. User not present
WO2005032100A1 (en) * 2003-09-30 2005-04-07 Telefonaktiebolaget Lm Ericsson (Publ) Means and method for generating a unique user’s identity for use between different domains
US7290278B2 (en) * 2003-10-02 2007-10-30 Aol Llc, A Delaware Limited Liability Company Identity based service system
SE0303057D0 (sv) * 2003-11-18 2003-11-18 Ericsson Telefon Ab L M Apparatus for providing a service in an identity federation framework
US7565356B1 (en) * 2004-04-30 2009-07-21 Sun Microsystems, Inc. Liberty discovery service enhancements
WO2005109822A1 (en) * 2004-05-11 2005-11-17 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for providing access to an identity service
CN101694682B (zh) * 2004-07-08 2016-03-23 连接Usall有限公司 优化对等移动通信
US7631346B2 (en) * 2005-04-01 2009-12-08 International Business Machines Corporation Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment

Also Published As

Publication number Publication date
CN101213570B (zh) 2011-06-15
US8095660B2 (en) 2012-01-10
WO2006136936A1 (en) 2006-12-28
EP1894181B1 (en) 2009-10-14
EP1894181A1 (en) 2008-03-05
US20090138941A1 (en) 2009-05-28
CN101213570A (zh) 2008-07-02
ATE445888T1 (de) 2009-10-15
DE602006009806D1 (de) 2009-11-26

Similar Documents

Publication Publication Date Title
US10810515B2 (en) Digital rights management (DRM)-enabled policy management for an identity provider in a federated environment
US10333941B2 (en) Secure identity federation for non-federated systems
US8196177B2 (en) Digital rights management (DRM)-enabled policy management for a service provider in a federated environment
AU2015240467B2 (en) Method for authentication and assuring compliance of devices accessing external services
JP4579546B2 (ja) 単一サインオンサービスにおけるユーザ識別子の取り扱い方法及び装置
Sánchez et al. Enhancing privacy and dynamic federation in IdM for consumer cloud computing
Chadwick et al. A conceptual model for attribute aggregation
JP2010506511A (ja) クライアントベースの匿名
JP2008544387A (ja) アイデンティティに基づくシナリオにおいてプリンシパルリファレンス（ｒｅｆｅｒｅｎｃｉｎｇ）を向上させる方法
JP4932154B2 (ja) アイデンティティ管理ネットワークにおいてユーザーの認証をメンバーサイトに与える方法及びシステム、アイデンティティ管理ネットワークに属するホームサイトでユーザーの認証を行う方法、コンピュータ読み取り可能な媒体、ならびに、階層的分散アイデンティティ管理のためのシステム
JP5283036B2 (ja) サービス提供システム、代理処理履歴収集方法および代理処理履歴収集プログラム
JP7119797B2 (ja) 情報処理装置及び情報処理プログラム
Sharif et al. Cross-Domain Sharing of User Claims: A Design Proposal for OpenID Connect Attribute Authorities
Standard Web Services Federation Language (WS-Federation) Version 1.2
Sundar Study of Facebook’s application architecture
Chiusano Web Services Security and More: The Global XML Web Services (GXA) Initiative
Lakshmiraghavan OAuth 2.0 Using Live Connect API

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090525

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120312

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120803