ウェブサービス間のセキュリティ構成の動的ネゴシエーション
【課題】２つ以上のウェブサービス間でセキュリティ構成をネゴシエーションしそして実施するための新規なコンピュータベースの装置及び方法を提供する。
【解決手段】本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して発生し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。
【解決手段】本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して発生し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２つ以上のウェブサービス間でセキュリティ構成をネゴシエーションしそして実施するためのコンピュータベースの装置及び方法に係る。より詳細には、本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して生成し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。
【０００２】
版権の通告：本特許文書の開示の一部分は、版権保護を受ける資料を含む。版権所有者は、特許商標庁の特許ファイル又は記録に現われるように誰かが特許文書又は特許開示を複写再現することに異議を唱えるものではなく、たとえそうでも全ての版権は確保されるものとする。
【０００３】
コンピュータプログラムリスト添付資料の参照：本明細書には、コンピュータプログラムリスト添付資料を添付する。このコンピュータプログラムリスト添付資料は、次のプログラム抜粋を含む。
SecuritySenderReceiverInfo.XSD （ネゴシエーション入力のスキーマ）
SecurityContractKeyInfo.XSD （セキュリティに使用するキーのスキーマ）
SecurityContract.XSD （ネゴシエーションから出力されるセキュリティ契約のためのスキーマ）
CommunitySecurityTemplatesInfo.XML （ネゴシエーション入力のスキーマ）
SecuritySenderInfo.XML （送信者情報の例）
SecurityReceiverInfo.XML （送信者情報の例）
ComputerSecurityContract.XML （計算型セキュリティ契約の例）
【背景技術】
【０００４】
ビジネス対ビジネス（Ｂ２Ｂ）及びアプリケーション対アプリケーション（Ａ２Ａ）電子商取引は、以前の慣習を電子データ交換（ＥＤＩ）に置き換えつつある。企業がＢ２Ｂ及びＡ２Ａシステムでそれらの効率を改善するように努力するにつれて、多数の互換性のないプラットホームや計算規格が出現した。互換性のある規格の中には、埋めるべきギャップが残っている。例えば、業界は、単純なウェブサービスは何かを定義した。単純なウェブサービスに関連した規格は、ＵＤＤＩ、ＷＳＤＬ、ＸＳＤＬ及びＳＯＡＰを含む。しかしながら、これらの規格は、実際のＢ２Ｂ及びＡ２Ａ電子商取引のためのセキュリティ、信頼性、管理性及びコレオグラフィー(choreography)要件を完全に満足するものではない。特にセキュリティは、多数のオプション及び構成上の問題を提起する。コラボレーティブウェブサービス及びそれらのセキュリティの必要性は、非ウェブビジネスと同様に進化することが予想される。ウェブサービスが進化するにつれてセキュリティオプション及び構成を動的に解決し且つ更新する包括的な又は一体化型の装置や方法は存在しない。
【０００５】
Ｂ２Ｂ及びＡ２Ａ電子商取引に適用可能な規格を拡張するための業界のイニシアティブは多数ある。コレオグラフィー努力は、ＯＡＳＩＳからのｅｂＸＭＬ／ＢＰＳＳ、ＩＢＭからのＷＳＦＬ、及びマイクロソフトからのＸＬＡＮＧを含む。会話努力は、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びマイクロソフトのＷＳルーティングを含む。主要なセキュリティ努力は、ＩＢＭ及びマイクロソフトからのＷＳセキュリティであり、又、ＯＡＳＩＳにも、ＳＡＭＬと称される相補的なセキュリティ努力が存在する。信頼性については、マイクロソフトからの提案、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びＩＢＭからのＨＴＴＰＲがある。Ｗ３Ｃは、これら全ての領域における規格化に向けられている。重要な業界の活動家は、ＷＳＩと称されるライバルのコンソーシアムを形成した。しかしながら、それらは、動的セキュリティネゴシエーション問題に向けられたものではない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従って、取引のパートナーに対するセキュリティオプション及び構成上の問題を動的に解決する方法及び装置を開発する機会が生じる。
【課題を解決するための手段】
【０００７】
本発明は、２つ以上のウェブサービス間でセキュリティ構成をネゴシエーションしそして実施するためのコンピュータベースの装置及び方法に係る。より詳細には、本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して発生し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。
【図面の簡単な説明】
【０００８】
【図１】セキュリティ構成のコンピュータ支援型の動的ネゴシエーションが有用となる１つの環境であるコミュニティ及びコミュニティのネットワークを示す図である。
【図２】セキュリティ構成のネゴシエーション及び実施を示す図である。
【図３】アルゴリズム形式の中の環境設定を調停するところを示す図である。
【図４】セキュリティ構成の計算に対して送信者がローカルであるときに受信者の情報を得るための別の実施形態を示す図である。
【図５】本発明の態様を実施するのに使用できるプログラムロジック及びリソースの１つのネットワークを示す図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照して詳細に説明する。本発明を例示するために好ましい実施形態を説明するが、これは、特許請求の範囲により規定された本発明の範囲を限定するものではない。当業者であれば、以下の説明に基づいて種々の同等の変更がなされ得ることが理解されよう。
【００１０】
図１は、セキュリティ構成のコンピュータ支援型の動的ネゴシエーションが有用となる１つの環境であるコミュニティ及びコミュニティのネットワークを示す。これらコミュニティの中で、あるコミュニティは、そのコミュニティの一部分であるユーザ、会社、サービス及びコネクタのような情報を含むローカルレジストリーを維持する。コミュニティは、市場、企業、又は事業部でよい。コミュニティは、１つ以上のコミュニティネットワークに属することができる。通常、コミュニティ及びネットワークは、ある共通のビジネス利益を有する。１つ以上のコミュニティネットワーク内のメンバーコミュニティ間で相互操作がなされる。ネットワークは、金市場ネットワーク１と、貴金属市場ネットワーク２と、プライベートネットワーク３と、グローバル取引ウェブネットワーク４とを備えている。この図では、金市場ネットワーク１及び貴金属市場ネットワーク２は、グローバル取引ウェブネットワーク４内に収容される。貴金属市場ネットワーク２は、金及び銀市場１４、１３を含む。金市場の顧客は、銀市場１３において銀を取引することができ、そして銀市場の顧客は、金市場１４において取引を行うことができる。１つのコミュニティであるＰＱＲ企業１７は、金市場ネットワーク１、プライベートネットワーク３及びグローバル取引ウェブネットワーク４に所属し、別のコミュニティであるＡＢＣ大規模供給者１８は、プライベートネットワーク３に所属する。この図では、ＸＹＺ金１４は、金を取引するための市場又はコミュニティである。企業は、このコミュニティに所属する。それら自体でコミュニティを形成しているＰＱＲ企業１７のような企業は、金市場ネットワーク１に所属する。これらのコミュニティは、金市場ネットワーク１及びグローバル取引ウェブネットワーク４の一部分である。小規模供給者１５は、金市場コミュニティの一部分である。他の企業１６は、金市場コミュニティネットワーク１の一部分であるコミュニティである。ＸＹＺ金１４と他の金市場エンティティ１５−１７との間の接続は、金市場が、例えば、勘定及びビジネスインテリジェンス情報を収集するために、金の取引を取り扱う企業（コミュニティ又はその他）間の全てのトラフィックを、ＸＹＺ金１４を通るルートにするよう要求することを示している。ＰＱＲ企業１７は、金市場の一部分であると共に、供給者１８とのローカルプライベートネットワークの一部分でもあるコミュニティである。小規模供給者１５は、それ自体でコミュニティを形成することを希望せず、むしろ、ユーザ、組織、サービス及び変換等のメタデータを金市場のレジストリーに登録する個々の小規模供給者でよい。一方、ＡＢＣ大規模供給者１８は、例えば、そのメタデータ、内部バックオフィスシステム及び変換を、それらが著しいコストで開発されたことから、一般的な公衆アクセスから隠れた状態に保持したいために、それ自身のプライベートネットワークを形成している。ＰＲＱ１７は、ＡＢＣ１８の顧客であるので、プライベートネットワーク３に参加する。フィナンシャルサービスプロバイダーＤＥＦフィナンシャル１２は、グローバル取引ウェブネットワーク４の誰かに、それ自身のコミュニティを形成したりグローバルトレーディングウェブルート１１に登録したりするフィナンシャルサービスを提供することを希望する。コミュニティのネットワークは、コミュニティのグローバルレジストリーを利用できるようにする。このグローバルレジストリーは、コミュニティをルックアップし、そしてそのコミュニティ又は外部コネクタへの１つ以上のルートを決定するのを許し、上記外部コネクタは、それを経てコミュニティへ向う電子商取引ドキュメントをルーティングできるものである。１つのコミュニティから別のコミュニティへルーティングされるドキュメントは、２つのコミュニティについては外部コネクタ間で直接ルーティングされてもよく、或いは１つ以上の中間コミュニティを経て間接的にルーティングされてもよい。又、コミュニティを伴うトランザクションに対するビジネス及びセキュリティルールも定義して、コミュニティレジスタに維持すことができる。一般に、図１は、電子商取引プラットホーム間の相互操作性の刺激を生じさせるエンティティ及びコミュニティの混合忠誠さを示す。
【００１１】
コネクタとは、他のアプリケーションと通信するアプリケーションに対する一般的な用語である。コネクタは、ハブ、ゲートウェイ、外部ポート、中央コネクタ等として機能する他のコネクタを通してピア対ピア（Ｐ２Ｐ）ベース又は指令ベースで通信することができる。Ｐ２Ｐで通信するコネクタは、同じトランスポート／エンベローププロトコルを使用する他のコネクタと通信することができる。Ｐ２Ｐで通信するコネクタは、任意であるが、同じトランスポート／エンベローププロトコルを使用しないコネクタと通信を試みるときに、変換サービスを実行する他のハブコネクタの協力を得てもよい。指令ベースで通信するコネクタは、ルーティングルールに基づいてハブコネクタを経て通信する。コネクタ間のルーティングルールは、１つ以上のトランスポート／エンベローププロトコルに対して１つ以上のハブ及びスポークトポロジーをサポートするように、指令グラフにマップすることができる。ハブ及びスポークトポロジーは、１つ以上の結合子 (tier)においてスポークに沿ってハブへの通信を指令する。これは、勘定、ビジネスインテリジェンス収集、追跡、監査、会計、その他の集中サービスを容易にする。図２に示唆されるように、異なるトランスポート／エンベローププロトコル及びテクノロジーをサポートするために、多数のハブ及びスポーク組織が同じコネクタをオーバーレイしてもよい。例えば、ＨＴＴＰ又はＨＴＴＰＳを使用するのではなく、ソニック(Sonic)をトランスポートテクノロジーとして使用するために、より強いハブ及びスポーク組織が必要とされてもよい。任意であるが、通信ルートは、ソース及び行先が同じコミュニティの一部分であるかどうかに依存してもよい。準コミュニティ（全コミュニティを含んでもよい）内で、集中機能が不要とされ、そして他の準コミュニティ内の行先と通信するときに親コネクタと通信するよう指令されたコネクタ間でＰ２Ｐ通信が許されてもよい。
【００１２】
コネクタは、単純なコネクタ（時々単にコネクタと称される）、ハブ（時々ゲートウェイ又はルーターと称される）又は中央コネクタと示されてもよい。或いは又、それらは、機能的に記述されてもよい。単純なコネクタは、同じ準コミュニティ内のコネクタ間でＰ２Ｐ通信することが許されるとき以外は、ハブコネクタを経て通信するよう指令される。いわゆるハブは、それらに明確に向けられ又はリンクされるコネクタにより使用される。ハブは、２つ以上の機能を果たすことができ、従って、ソースから行先へのルートにおいて２回以上現われることがある。ハブは、電子商取引のドキュメント又はメッセージを転送する。又、ハブは、共通のエンベローププロトコルをサポートするトランスポートプロトコル間で変換を行ってもよい。例えば、ハブは、エンベローププロトコルを変換し、そして受信時ではなく送信時に異なるトランスポートプロトコルを実施してもよい。中央コネクタは、ハブの特殊なケースであり、それらに明確に向けられもリンクもされないコネクタにより使用することができる。中央コネクタは、例えば、ルーティングルールに基づいてソースからコネクタを横断しても、行先により使用されるトランスポート／エンベローププロトコルをサポートするハブに至らないときに、変換機能を実行するのに有用である。
【００１３】
本発明の態様に基づくセキュリティ構成の概要がスキーマ及びプロセスフローにより与えられる。この点について、セキュリティ構成のネゴシエーションは、送信側及び受信側サービスのセキュリティプロファイルを使用して、相互に合意し得るセキュリティ構成を決定するためのコンピュータベースのプロセスにより実行される。好ましくは、このセキュリティ構成は、ユーザを介在せずに、ネゴシエーションされるか、又は潜在的に規則的に更新される。この構成は、ユーザの要求があったときに、又はユーザを介在せずに、メッセージが交換されるとき、又は他の何らかの周期又は時々、例えば、毎月、毎週、毎日、或いは特定の送信者と受信者との間のメッセージの交換に影響する事象が発生したとき（例えば、ソフトウェアコンポーネントの故障、又はセキュリティ環境設定の変化）、既にネゴシエーションされた構成が故障したとき、又は他の何らかの周期的又は時々のベースで、ネゴシエーションされ、更新され、又は有効性についてチェックされる。ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤ」は、セキュリティ構成のネゴシエーションに対する幾つかの入力を記述する。又、ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」は、いわゆるセキュリティ相互操作契約ドキュメント（ＳＣＩＤ）において、ネゴシエーションされるセキュリティ構成の一実施形態を記述する。図１のプロセスフローは、セキュリティ構成のネゴシエーション及び実施を記述するのに使用できる。
【００１４】
ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤ」は、セキュリティ構成のネゴシエーションに対して複数の入力ファイルを確認するのに使用できる。この実施形態では、マシン読み取り可能な入力ファイルは、ＸＭＬドキュメントである。他の実施形態では、他のデータ構造、例えば、ＸＭＬコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。スキーマ「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤ」は、ドキュメント発生ビューを含むスキーマの多数の別々のビューを与えるＸＭＬ Ｓｐｙ ＴＭのような一体化開発環境（ＩＤＥ）へファイルをロードすることにより最も良く理解される。送信者及び受信者セキュリティ相互操作性契約ドキュメント情報ブロックは、このスキーマにより定義される。Ｓｐｙのスキーマ設計ビューで見ると、ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤは、送信者及び受信者セキュリティ情報を定義するのに使用される多数のコンポーネントを含む。ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＰｏｌｉｃｙＰｒｅｆｅｒｅｎｃｅコンポーネントは、ヘッダに署名し、信用証明(credential)を暗号化するためのコミュニティの環境設定、及び信用証明の環境設定を示す。これは、全コミュニティに対するデフォールト値を特定するのに使用できるし、又はコラボレーションパートナー（ＣＰ）に対するデフォールト値を特定するように適応することもできる。ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙコンポーネントは、署名及び暗号化の環境設定と、認証オプションとを特定するのを許す。サービスとサービスとの間で交換されるメッセージは、多数の部分を有することができる。署名及び暗号化ポリシーは、メッセージ全体又は個々の部分に適用することができる。この解決策は、書名及び暗号化ポリシーを部分内のエレメントに適用するように容易に拡張することができる。ＰｕｂｌｉｃＫｅｙｓコンポーネントは、このＣＰに対するキー記録を識別する。ＣｏｎｎｅｃｔｏｒＣａｐａｂｉｌｉｔｙコンポーネントは、セキュリティ構成の一部分を実施するリソースにコネクタ名のようなルーティング情報を与える。これは、暗号化能力、署名能力、暗号化パブリックキー当事者、及び署名パブリックキー当事者のようなコネクタ能力パラメータを含む。パブリックキー当事者は、署名が含まれるか暗号化が含まれるかに基づいて、送信者のＣＰ、受信者のＣＰ、又はコネクタの所有者である。パブリックキー当事者が定義されない場合には、メッセージ送信者のキーを署名に使用することができ、そしてメッセージ受信者のキーを暗号化に使用することができる。ＳｅｃｕｒｉｔｙＣｏｎｔａｉｎｅｒコンポーネントは、セキュリティに有用な付加的なオブジェクトを搬送するのに使用することができる。ＳｅｎｄｉｎｇＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｙＰｒｏｆｉｌｅコンポーネントは、送信側ＣＰに得られる信用証明情報を含む。ＣＰＳｅｎｄＳｅｒｖｉｃｅｓＳｅｃｕｒｉｔｙＰｏｌｉｃｙ及びＣＰＲｅｃｖＳｅｒｖｉｃｅｓＳｅｃｕｒｉｔｙＰｏｌｉｃｙコンポーネントは、各々、送信側及び受信側サービスに対するセキュリティポリシーのセットを含む。サービスの環境設定及びオーバーライドをここで定義することができる。
【００１５】
又、ソースコード添付資料におけるスキーマ「ＳｅｃｉｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」は、マシン読み取り可能なセキュリティ相互操作性契約ドキュメントを作成するためのモデルとして使用することができる。この実施形態では、マシン読み取り可能なドキュメントは、ＸＭＬドキュメントである。他の実施形態では、他のデータ構造、例えば、ＸＭＬコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。このスキーマは、セキュリティポリシーに対するポリシー及びチャンネルを定義する。セキュリティチャンネルは、署名、暗号化及び認証アルゴリズムのようなセキュリティアルゴリズムを実行するリソース及びリソースへのルートを定義する。又、これは、否認防止及び許可リソースを含んでもよい。
【００１６】
図２のプロセスフローは、セキュリティ構成のネゴシエーション及び実施を説明するのに使用される。一実施形態では、送信及び受信側サービスの環境設定がレジストリー２０１に維持される。このレジストリーは、各々のサービスがセキュリティ構成を計算できるように送信側及び受信側サービスに対してアクセスすることもできるし、或いは送信側及び受信側サービスの一方又は両方にアクセスできるセキュリティ構成計算サービスに利用することもできる。送信及び受信側サービスは、それら自身のレジスタを維持してもよい。或いは、送信及び受信側サービスに対して、それらのセキュリティ環境設定をセキュリティ構成のネゴシエーションの一部分として交換するためのプロトコルが開発されてもよい。レジストリー２０１は、更に、コラボレーションパートナーが所属するサービス又はコミュニティ或いはその両方を所有するコラボレーションパートナーのデフォールトの環境設定に関する情報を維持してもよい。デフォールトの環境設定は、一般的に、サービス特有の環境設定によりオーバーライドされてもよいし、或いはあるデフォールトの環境設定に、サービス特有の環境設定に勝る優位性が与えられてもよい。コラボレーションパートナーのデフォールトの環境設定は、コミュニティのデフォールトの環境設定とは異なるように処理されてもよい。セキュリティ構成の環境設定の入力記述は、レジストリー２０１又は別のソースから取り出されて、セキュリティ構成計算サービス２０２によって作用されてもよい。一実施形態では、この計算サービスは、セキュリティ契約ビルダーである。１組のセキュリティ構成が出力される（２０３）。これらの構成は、送信側及び受信側サービスで確認されてもよいし、送信側又は受信側サービスにより拒否を受けてもよいし、又は送信側及び受信側サービスにより信用されてもよい。送信側サービス２０５、又は送信側サービスに応答する別のサービスは、セキュリティ構成２０３を使用して、ドキュメント２０４を受信側サービス２０９へ送信すべく処理する。ある状況においては、セキュリティ構成は、信用されたアサーションサービス２０６からアサーションを得ることを要求する。
例えば、送信側及び受信側サービスは、ＳＡＭＬサービスを利用して認証アサーションを発生することに合意してもよい。セキュリティ構成２０３は、ＳＡＭＬアサーションの発生を要求し、そして送信側サービス２０５は、ＳＡＭＬサーバー２０６からＳＡＭＬアサーションを得る。別の実施形態では、信用されたサービス２０６により電子公証が与えられてもよい。銀行やセキュリティ当局は、公証と同様のファンクションにおいて認証アサーションを発生するための信用がある。ある環境においては、セキュリティ構成は、パブリックキーソース２０８からの非対称的署名又は暗号化に使用されるパブリックキーを得ることを要求する。例えば、送信側及び受信側サービスは、ＸＫＭＳサービスを利用してパブリックキーを交換することに合意してもよい。セキュリティ構成２０３は、ＸＫＭＳサービスアドレスをパブリックキーのソースとして特定する。送信側サービス２０５及び受信側サービス２０９は、両方とも、合意したキーソース２０８にアクセスする。セキュリティ構成２０３によれば、送信側サービス２０５は、ネットワーク２０７を経て受信当事者２０９へドキュメント２０４を通信する。ネットワーク２０７を通るルート及び搬送は、セキュリティ構成の一部分でもよいし、又はセキュアトランスポートインフラストラクチャーにより取り扱われるのが好ましい。セキュリティ構成２０３は、計算サービス２０２により受信当事者２０９へ与えられてもよいし、さもなければ、ドキュメント２０４を搬送するメッセージとは独立して受信当事者にアクセスできるようにされてもよい。或いは又、セキュリティ構成２０３は、予め構成されたプロトコルによりドキュメント２０４と共に含まれてもよい。例えば、これは、メッセージヘッダの一部分でもよいし、又はメッセージの個別部分でもよい。予め構成されたプロトコルは、メッセージヘッダを要求してもよいし、或いは当事者の各キーを使用して署名及び／又は暗号化されるべきメッセージ部分を要求してもよい。このプロセス及び前記スキーマを銘記して、ソースコード添付資料からの例を説明する。
【００１７】
ファイル「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＩｎｆｏ．ＸＭＬ」、「ＳｅｃｕｒｉｔｙＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＭＬ」及び「ＣｏｍｐｕｔｅＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＭＬ」は、送信者及び受信者の環境設定と、それにより生じる計算されたセキュリティ構成との例を与える。送信者及び受信者の環境設定は、上述したＸＭＬスキーマに適合するＸＭＬコードに示されている。計算されたセキュリティ構成は、ソースコード添付資料における「ＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」スキーマに適合する相互操作性セキュリティ契約ドキュメントに示されている。
【００１８】
この例では、送信者の環境設定情報は、コミュニティの環境設定及びサービスの環境設定を含む。コミュニティの環境設定は、セキュリティアルゴリズム、ヘッダに署名し、信用証明を暗号化し、そして入手可能な信用証明の中で選択するための環境設定に向けられる。又、コミュニティの環境設定は、セキュリティアルゴリズムの順序をランク付けしてもよいし、或いはセキュリティアルゴリズムの中で環境設定を指示してもよい。コミュニティに対する環境設定に代わって又はそれに加えて、コラボレーションパートナーに対する同様の１組の環境設定が与えられてもよい。この例では、コミュニティは、「ＸＭＬＳｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍＴｅｍｐｌｅｔｅ」と称するエレメントにおいて６組の署名アルゴリズムオプションと、「ＸＭＬＥｎｃｒｙｐｔｉｏｎＡｌｇｏｒｉｔｈｍＴｅｍｐｌｅｔｅ」と称されるエレメントにおいて３組の暗号化アルゴリズムオプションとを有する。これらの組のオプションは、テンプレートである。２つ以上のテンプレートのオプションを特定のアルゴリズムに対して設けることができる。テンプレートの使用で、オプションの構成が簡単化されると共に、送信側及び受信側サービスにより一貫したオプションの組が選択される見込みが高くなる。この例のコミュニティは、ヘッダに署名することも信用証明を暗号化することも好まず、そして基本的な信用証明を受け容れる。一般に、コミュニティ又はコラボレーションパートナーは、サービスが選択できるセキュリティ構成オプションを好んでもよいし、或いはコミュニティ又はコラボレーションパートナーは、幾つかのオプションだけを好んでもよい。送信者の環境設定ファイルにおけるコミュニティの環境設定は、コミュニティの環境設定のためのレジストリーエントリーのように、どこかに示されたコミュニティの環境設定に対応しなければならない。ファイル「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌｅｔｅｓＰｒｅｆｅｒｅｎｃｅｓ．ＸＭＬ」は、コミュニティのセキュリティ環境設定の幾つか又は全部を記録するのに使用されるファイルの一例である。
【００１９】
サービス（この例では送信側サービス）は、メッセージの部分の取り扱い、メッセージ全体の署名及び暗号化、並びに認証のためのその環境設定を「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」に記録する。メッセージは、多数の部分を有することができる。メッセージの部分に対応して、サービスは、メッセージの部分を識別し、そしてメッセージの部分に署名する又は署名しない、或いはメッセージの部分を暗号化する又は暗号化しないという環境設定を表現することができる。この実施形態では、一般的アルゴリズム又はＸＭＬ特有のアルゴリズムといったアルゴリズムのカテゴリーの環境設定を選択することができる。他の実施形態では、サービスは、アルゴリズムのカテゴリーを指定しなくてもよいし、又は特定のアルゴリズムを指定してもよい。
【００２０】
セキュリティに対する他の構成もこの例によりカバーされる。Ｘ５０９フォーマットでの受信者（バイヤー）のパブリックキーは、署名及び認証に使用される。いわゆるコネクタである２つのリソースは、署名及び暗号化に使用するために送信側サービスに対して識別される。送信者に得られる信用証明は、基本的及びＸ５０９信用証明として識別される。送信側サービスのセキュリティ構成の環境設定は、「ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＴｅｍｐｌｅｔｅＰｒｅｆｅｒｅｎｃｅ」のもとで１から３までの順序でランク付けされる。この例では、ＸＭＬ特有の暗号化に対して全部で３つの暗号化の環境設定がある。この例についてのこれら及び他の詳細は、ソースコード添付資料ファイル「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＩｎｆｏ．ＸＭＬ」に見られる。
【００２１】
受信当事者の環境設定は、ソースコード添付資料ファイル「ＳｅｃｕｒｉｔｙＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＭＬ」に見られる。一般に、受信当事者の基準プロファイルのエレメントは、スキーマからの同じエレメント形式を使用しても、送信当事者のエレメントに非常に類似したものとなる。認証及び許可には著しい相違が見られる。というのは、認証及び許可に適用できるロジックは、あなたがあなたの信用証明を提示するかどうか、又は提示されたものを受け容れるべきかどうか決定することに依存するからである。例えば、送信当事者の「ＳｅｎｄｉｎｇＣＰＳｅｃｕｒｉｔｙＰｒｏｆｉｌｅ」は、入手可能な信用証明をリストする。このエレメントは、受信当事者の環境設定の部分ではない。この問題は、「ＡｃｃｅｐｔｅｄＣｒｅｄｅｎｔｉａｌ」を識別する受信当事者の「ＣＰＲｅｃｖＳｅｒｖｉｃｅｓＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」により対処される。
【００２２】
この例では、セキュリティ構成ロジックが調停するところの２つの形式の環境設定が示される。一方の形式の環境設定は、アルゴリズムテンプレートの中にある。エレメント「ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＴｅｍｐｌｅｔｅＰｒｅｆｅｒｅｎｃｅ」は、送信側及び受信側サービスの環境設定に２回現われて、アルゴリズムの中でコミュニティ及びサービス特有の環境設定を示す。図３は、アルゴリズム形式の中の環境設定の調停を示す。スタック３０１及び３０２は、送信側及び受信側の環境設定を表わしている。Ａは、セキュリティが最も高く、Ｇは、最も低いと仮定する。２つの環境設定スタック３０１、３０２において、環境設定ＢとＤは一致する。Ｂ又はＤを選択するための判断ルールは、環境設定の一方又は両方のスタックを考慮する。例えば、署名のための受信側サービスの環境設定（Ｄ）、又は暗号化のための送信側サービスの環境設定（Ｂ）は、一致するものの中から選択されてもよい。両方の環境設定を考慮して、最もセキュリティが高い（Ｂ）又は最もセキュリティが低い（Ｄ）が選択されてもよい。別の実施形態では、各サービスは、それらの環境設定に重み又はスコアを付けてもよいし、合成重み又はスコアを使用して、両方の環境設定を考慮に入れてもよい。第２の形式の環境設定は、メッセージの一部分に署名すべきか又はそれを暗号化すべきかである。何に署名するか又は何を暗号化するかは、「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」の「ＳＡＭｓｇＰａｒｔ」エレメントにより対処される。この例におけるメッセージ部分は、「オーダー」及び「イメージ」である。この例では、送信者及び受信者の環境設定は、「オーダー」の署名及び暗号化と、「イメージ」の暗号化のみについて一致する。受信者が署名された「イメージ」と、「オーダー」とを希望する場合には、環境設定は一致しない。次いで、この不一致を解決するために判断ルールが必要となる。利用できる判断ルールは、受信者の勝ち、送信者の勝ち、最も高い要件の勝ち、最も低い要件の勝ちを含むことができる。一方の形式の環境設定の調停は、セキュリティ手段を適用すべきかどうか決定する。他方の形式は、セキュリティ手段が適用されるときにオプションテンプレートの中で選択を行う。
【００２３】
この例に対する１組の計算された計算されたセキュリティ構成は、「ＣｏｍｐｕｔｅｒＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＭＬ」に現われ、これは、次のように部分的に再現される。
【００２４】
この１組のセキュリティ構成は、セキュリティポリシー及びセキュリティチャンネルに対する２つの主要セクションを有する。この例では、全メッセージに適用できる１つのセキュリティポリシーと、該セキュリティポリシーの部分を実施するための多数のセキュリティチャンネルがある。セキュリティポリシーセクションは、署名ポリシー、暗号化ポリシー及び暗号キー情報を設定する。又、これは、発信点又は受領の認証、許可及び否認防止に関するポリシーを設定してもよい。この実施形態では、同じ署名及び暗号化ポリシーがドキュメントの全ての部分に適用される。他の実施形態では、異なる部分に多数のアルゴリズムを適用することができる。署名、暗号化及び認証のために選択されるアルゴリズムは、オプションセットを含むテンプレートにより抽象化され、アルゴリズムの選択を簡単にする。選択されるアルゴリズムは、ロジック及びリソースに関連付けられ、従って、メッセージの異なる部分に署名し／照合し及びそれを暗号化し／暗号解読するのに、異なるサービス又はプロセスを使用することができる。セキュリティポリシーセクションの暗号キーエレメントにおいてパブリックキー又は証明書を送信することができる。セキュリティチャンネルセクションは、セキュリティポリシーの適用に含まれるサービス又はコネクタを記述する。特定のポリシーについては、チャンネルセクションは、セキュリティポリシーを適用する際に支援を要求するソースコネクタ（例えば、暗号化を要求する送信側サービス）と、セキュリティポリシーを適用するか、又はセキュリティポリシーを適用するロジック及びリソースに対して仲介者として働くターゲットコネクタとを識別する。署名、暗号化、認証、許可、又は否認防止のような特定のセキュリティポリシーに対して、そのセキュリティポリシーを実行するのに必要な特定の情報がセキュリティチャンネルセクションにおいて与えられる。
【００２５】
セキュリティ構成を決定するのに使用されるデータは、メッセージ及びアクティビティ関連データ、ＣＰサービス関連データ、セキュリティアルゴリズム関連データ、ルーティング関連データ、暗号キー関連データ、及びコンフィギュレーションデータとして分類することができる。これらの分類の使用に関する幾つかの付加的な詳細を以下に説明する。メッセージ及びアクティビティ関連データは、デジタル署名、暗号化、否認防止及び許可に関連したものである。否認防止については、受信者は、受信者への送信者メッセージについての信用ある当事者の確認であるところの送信者に対する否認防止の手段を要求してもよい。同様に、送信者は、受信者による送信者メッセージの受領についての信用ある当事者の確認であるところの受信者に対する否認防止の手段を要求してもよい。以上の説明に加えて、微細な粒度が望まれる場合には、データの特定項目にエレメントベースで署名及び暗号化を適用できることを述べておかねばならない。更に、送信側及び受信側サービスの対にオーバーライドを指定することもできる。例えば、既存の又は立証された関係を、完全に新規な関係とは異なるように処理することができる。セキュリティポリシーへのオーバーライドは、特定のケースにおけるセキュリティ要件を慎重に減少する（又は保証されたように増加する）ように実施できる。
【００２６】
ＣＰ関連データは、認証及び許可データを含む。許可は、ネットワークリソースへのアクセスを許可又は拒絶するプロセスである。ほとんどのコンピュータセキュリティシステムへのアクセスに対する許可は、２段階プロセスである。その第１段階は、本人（ユーザ、プロセス、アプリケーション又はサービス）がそれを請求することを保証するための認証である。第２段階は、本人がその認識に基づいて種々のリソースへアクセスするのを許す許可である。許可は、アクセス制御とも称される。アクセス制御は、ウェブサイトリソースへのアクセスを許可するのに使用される。これは、ユーザ、ユーザのグループ、及びユーザに指定される役割に関する情報を管理する。ＳＡＭＬは、ＳＯＡＰメッセージにおいてセキュリティ事象（認証及び許可）及び属性（例えばクレジット等級）に関する情報を共有するためのＸＭＬベースの手段を与える。このＳＡＭＬデータは、次いで、第三者へ送信することができ、これは、「分散された信用」を可能にし、これにより、ユーザは、一度署名すると、それらの認証又は許可の詳細を再使用することができる。ＳＡＭＬ又は同様の信用された当事者のテクノロジーでは、係争当局は、要求者により証拠が与えられると、リソースウェブサービスへのアクセス形式に対して、当該サービス又は送信者による要求を許可すべきかどうか判断する。許可判断は、特定のリソースへの当該アクセスを許可又は拒絶する。ＳＡＭＬは、ウェブサービスセキュリティに対する有用なオプションであるが、最初にある程度の信用及び技術的リソースを要求する。ＳＡＭＬが利用できないか又は好ましくないときには、ＩＤ／パスワードや、ＩＤに関連した特典のテーブルのような他の解決策を使用することができる。本発明は、使用する許可テクノロジーにより限定されるものではなく、現在利用できる又は今後発明されるテクノロジーの中の選択へと更に抽象的に拡張される。ＳＡＭＬ許可又はＩＤ／パスワードテクノロジーでは、許可データを暗号化してメッセージへ組み込むことができる。
【００２７】
セキュリティアルゴリズムに関連したデータは、署名、暗号化及び否認防止のためのアルゴリズム及びコンフィギュレーションオプションを含む。スキーマが示すように、署名アルゴリズムオプション（ＸＭＬ又は非ＸＭＬ）は、ＸＭＬＤｓｉｇの使用、キャノニカライゼーション(Canonicalization)アルゴリズムの選択、署名メソッド、及びダイジェストアルゴリズムを含んでもよい。暗号化／暗号解読オプション（ＸＭＬ又は非ＸＭＬ）は
、キーサイズ、キー及びメソッドを含んでもよい。デフォールトは、サービスの環境設定をオーバーライドするか又はオーバーライドされているとしてサービスにより継承されてもよい。更に、上述したように、ＣＰ対に対して特定のオーバーライドを指定することができる。又、上述したオプションテンプレートは、セキュリティ構成のネゴシエーションを簡単化する。ＸＭＬ及び非ＸＭＬアルゴリズム、例えば、署名アルゴリズムには、異なるオプションが適用される。ＸＭＬ署名アルゴリズム、例えば、ＸＭＬＤｉｓｇは、メソッド、キャノニカライゼーション、変換及びダイジェストのためのオプションをオファーすることができ、一方、非ＸＭＬアルゴリズム、例えば、ＰＣＫＳ＃７は、署名及びダイジェストメソッドのみに対するオプションを有する。各サービスの環境設定リスト間に少なくとも１つの一致があるよう確保するためには、コミュニティの標準セキュリティテンプレートの使用が好ましい。コミュニティは、コミュニティ内でメッセージを交換できるよう確保するために、コミュニティ内で動作する全てのＣＰ又は全てのサービスが特定のコミュニティ標準セキュリティオプションをサポートすることを要求する。
【００２８】
ルーティングに関連したデータは、認証／照合、署名／照合及び暗号化／暗号解読を実施するロジック及びリソースにいかにアクセスするかを含む。ユニバーサルリソースネーム（ＵＲＮ）又はユニバーサルリソースロケータ（ＵＲＬ）のようないかなる形式のアクセス情報が使用されてもよい。上述した以前の特許出願に説明されたように、メッセージは、変換又は他の付加価値サービスのためのコネクタを経て多数のホップをとることができる。従って、いかなるアクションにも多数のルートステップが関連付けられる。セキュリティは、通常、変換又は他の付加価値サービスの後に再適用されることが必要となる。
【００２９】
暗号化キーに関連したデータは、一般的に、上述した。
【００３０】
コンフィギュレーションデータは、デフォールトの（例えばコミュニティ又はコラボレーションパートナー）環境設定と、信用証明の環境設定とを含む。
【００３１】
図４は、送信者が、セキュリティ構成の計算に対してローカルであるときに、受信者の情報を得るための別の実施形態を示す。図中、ローカルレジストリー４３１及びリモートレジストリー４３２が示されている。この例では、送信者がローカルであり、そして受信者がリモートである。送信者のデータは、ローカルレジストリー４３１に現存しそして完全である。送信者の情報は、収集され（４２１）、そしてセキュリティ構成４１１を計算するロジック及びリソースに利用できるようにされる。受信者のデータは、例えば、受信者が送信者と同じコミュニティにいてコミュニティ規模のレジストリーが存在するか、或いは受信者の情報が最近得られてローカルキャッシュされた場合に、現存しそして完全である。受信者の情報がどこで見つかるか（４３１又は４３２）に基づいて、プロセス４２２又は４２３が呼び出されて、受信者の情報を収集し、そしてセキュリティ構成を計算するロジックに利用できるようにされる。１組のセキュリティ構成４０１が得られる。
【００３２】
図５は、本発明の態様を実施するのに使用できるプログラムロジック及びリソースの１つのネットワークを示す。このネットワークのロジックコンポーネントは、送信側収集５５１と、受信側収集５５２と、データオブジェクトマネージャー５４１と、ルーティングマネージャー５４２と、信用証明ネゴシエーター５３１と、テンプレートネゴシエーター５３２と、コネクタマネージャー５３３と、認証マネージャー５２１と、ポリシーマネージャー５２２と、パブリックキーマネージャー５２３と、アルゴリズムマネージャー５２４と、ポリシービルダー５１１と、チャンネルビルダー５１２と、セキュリティ構成ドキュメントビルダー５０１とを備えている。
【００３３】
コラボレーションパートナーのコミュニティにおいて動作してセキュリティ構成を発生するプログラムロジックの一実施形態を以下に説明する。送信者ＣＰを認証するための属性アサーションを含む受信者セキュリティ情報を収集する。送信者セキュリティ情報を収集する。ルーティングブロックを見て、セキュリティ手段を実施するための全てのコネクタ情報を見出す。各コネクタに対して能力パラメータを得る。ルーティングチェーンを通って進み、認証、署名及び暗号化のためにどのコネクタ対を使用するか見出す。受信者のサービスアクティビティメッセージオブジェクトを得る。これは、受信者から「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトを得ることを含んでもよい。これは、多数の部分を有し、そして全メッセージに対して署名及び暗号化ポリシーを有することができる。又、これも、送信者から「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトを得ることを含んでもよく、そして「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトにオーバーライドオプションを適宜に一致させる。（オーバーライド判断テーブルは、以下に説明する。）「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトから、このメッセージに必要な全てのアルゴリズムを見出し、そして「ＲｅｑｕｉｒｅｄＡｌｇｏｒｉｔｈｍＬｉｓｔ」を構築する。「ＳｅｎｄＩｎｆｏ」及び「ＲｅｃｅｉｖｅＩｎｆｏ」の両方に対してコミュニティ環境設定オブジェクトを得る。これは、送信者の「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」オブジェクトを得ることを含んでもよく、これは、セキュリティアルゴリズムテンプレート及びコミュニティセキュリティポリシー環境設定を含む。又、これは、同じコミュニティでない場合に、受信者の「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」オブジェクトを得ることを含んでもよい。それらが同じコミュニティにいる場合には、オブジェクトポインタをセットすれば充分である。送信者及び受信者の両サービスに対するＣＰサービスオブジェクトを得、そして対応するコミュニティに対するＣＰオブジェクトを得る。これは、送信者及び受信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｙＰｒｅｆｅｒｅｎｃｅ」を構築することを含んでもよい。送信者及び受信者の環境設定と、「ＲｅｑｕｉｒｅｄＡｌｇｏｒｉｔｈｍＬｉｓｔ」の判断ルールとに基づいて、環境設定リストから選択を行うと共に、「ＲｅｑｕｉｒｅｄＴｅｍｐｌａｔｅＯｂｊｅｃｔＬｉｓｔ」を構築する。サービスの各環境設定リストがアルゴリズムにおいて一致しない場合には、コミュニティのデフォールトが一致を発生してもよい。受信者サービスに対して「ＳｅｒｖｉｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ」オブジェクトを得る。これは、受け容れられた信用証明及び認証モードを含む１つ以上の指定の認証メソッドを有する。「ＳｅｒｖｉｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ」オブジェクトからの信用証明と、送信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｅＰｒｅｆｅｒｅｎｃｅ」から得られる信用証明とを一致させる。２つ以上の一致がある場合には、受信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｅＰｒｅｆｅｒｅｎｃｅ」から、又は受信者に対応する「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」から、「ＣｒｅｄｅｎｔｉａｌＰｒｅｆｅｒｅｎｃｅ」に一致するものを得る。受信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｅＰｒｅｆｅｒｅｎｃｅ」、又は受信者の「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」オブジェクトのいずれかから、「ＳｉｇｎＭｅｓｓａｇｅＨｅａｄｅｒ」及び「ＥｎｃｒｙｐｔＣｒｅｄｅｎｔｉａｌ」の値を得る。いずれの場所でも値が指定されない場合には、それを偽又は真のようなデフォールトにセットする。受信者により選択された利用可能な送信者の信用証明、受信者に対する「ＳｅｒｖｉｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ」オブジェクトに指定された認証モード、「ＳｉｇｎＭｅｓｓａｇｅＨｅａｄｅｒ」ブール属性、及び「ＥｎｃｒｙｐｔＣｒｅｄｅｎｔｉａｌ」を使用して、認証アルゴリズムを構築する。コネクタの「ＰｕｂｌｉｃＫｅｙＣａｐａｂｉｌｉｔｙ」に基づいて、適切なキーを得る。これは、暗号化が要求される場合には、送信者の暗号キーを得ることを含み、そして署名が要求される場合には、受信者の署名キーＩＤを得ることを含む。Ｘ５０９認証が要求される場合には、受信者の認証キーＩＤを得る。セキュリティ構成のポリシーセクションを構築する。チャンネルセクションに対するコネクタを見つけ、そしてセキュリティ構成のチャンネルセクションを構築する。
【００３４】
判断テーブルを使用して、メッセージの一部分に署名すべきか又は暗号化すべきかに関連した環境設定の形式の調停を実施してもよい。この場合も、署名すべきでない環境設定を受け容れたり受信者の環境設定又は単なる反対を受け容れたりするように判断を偏らせることもできる。考えられる判断ルールを実施するのに使用できる判断テーブルを以下に示す。
【００３５】
【００３６】
本発明は、送信者と受信者との間の経路に沿って中間コネクタにおいて署名及び暗号化をサポートするように容易に拡張される。これは、メッセージの発信者でも最終的な受信者でもないルーティング経路に沿ったコネクタにおいてドキュメントに署名し及びドキュメントを暗号化することができる上で有用である。これは、ゲートウェイ、ルーター及び中央コネクタにとって有用である。ゲートウェイについては、署名され／暗号化されたメッセージデータが１つのエンベローププロトコルから別のものへ変換される場合に、署名及び暗号化をゲートウェイにより実行することが必要になり得る。ルーター及び中央コネクタについては、外部コミュニティに対し企業への単一の入口／出口ポイントを使用するのが望ましい。ルーター又は中央コネクタは、中央のセキュリティハブとして働くと共に、企業全体に代わってセキュリティオペレーションを遂行又は編成することができる。これは、ＰＫＩマネージメント及びその他の管理負担を簡単化できる。この機能は、コミュニティの企業部分においてコネクタのセキュリティ能力を設定することにより構成できる。コネクタは、署名能力又は暗号化能力をもつようにエンベロープ／トランスポートプロトコルベースで構成できると共に、他のコネクタにおけるコラボレーションパートナーの署名及び暗号化能力にリンクすることができる。ゲートウェイ及びルーターの場合には、ＣＰ自身のキー又はゲートウェイ／ルーターコネクタを使用するようにコネクタを構成することができる。
【００３７】
以上の説明から、当業者であれば、本発明の態様及び要素から広範囲なシステム及び方法を構成できることが明らかであろう。一実施形態は、送信側サービスと受信側サービスとの間で１つ以上のメッセージを交換するためのセキュリティオプションを動的に決定する方法である。この方法は、送信者及び受信者のセキュリティの環境設定を使用し、これは、第１及び第２のサービスに対してマシンセキュリティプロファイルの形態をとり得る。セキュリティプロファイルは、各サービスに受け容れられるセキュリティオプション／エレメント及びオプションサブセットを識別することができる。オプションは、メッセージの１つ以上の部分に署名し又は暗号化するための要件、１つ以上の署名アルゴリズムに対応する署名オプションサブセット、１つ以上の暗号化アルゴリズムに対応する暗号化オプションサブセット、署名及び暗号キーの識別、並びに認証アルゴリズムの識別を含んでもよい。動的な方法は、セキュリティプロファイルにアクセスし、そして各サービスに受け容れられる特定オプションセットを選択することを含む。任意であるが、このオプションセットは、各サービスとサービスとの間にメッセージを通信するのに使用できる。本発明の多数のオプション及び態様をこの実施形態に付加することができる。セキュリティプロファイルは、第１及び第２サービスのセキュリティロジックにアクセスできる１つ以上のレジストリーに維持することができる。デフォールトオプションサブセット及び／又は環境設定は、コミュニティ又はコラボレーションパートナーセキュリティプロファイルにおいて指定することができると共に、サービスセキュリティプロファイルへコピーされてもよい。署名又は暗号化の要件は、メッセージの部分又はメッセージ全体に適用することもできる。署名及び暗号化アルゴリズムは、メッセージ全体に適用して複雑さを減少することもできる。署名及び暗号キーは、対称的でも、非対称的でもよい。認証は、信用されたエージェント、例えば、ＳＡＭＬサーバーにより、各サービスとサービスとの間にメッセージを通信する前に、実行されてもよい。信用されたエージェントによる認証は、認証アサーションにより証拠とされてもよい。或いは又、認証は、受信側サービスにより検査するための信用証明を提示することを含んでもよい。これらの信用証明は、メッセージの一部分でもよいし、又はメッセージに加えて送信されてもよい。認証に加えて、許可は、セキュリティ構成により対処されてもよい。セキュリティプロファイルは、送信側サービスの特典を確立するために少なくとも１つの許可アルゴリズムの識別を含んでもよい。この許可は、メッセージを通信する前に信用されたエージェントにより実施されてもよいし、或いはメッセージを受信するサービスに信用証明を提示することにより実施されてもよい。本発明の更に別の態様は、署名及び／又は暗号化のためのオプションサブセットの中で各サービスの環境設定を考慮に入れる。一方又は両方のサービスの環境設定が考慮されてもよい。受信者が勝ち、送信者が勝ち、最もセキュアなものが勝ち、最もセキュアでないものが勝ち、又は両サービスの環境設定の重み付けファクタを含む上述したいずれの判断ルールが適用されてもよい。セキュリティ構成の決定は、署名、暗号化、認証、許可又は否認防止の任意の組合せを実施するように各当事者により使用されるべきリソースを決定することを含んでもよい。リソース、アルゴリズム及びオプションは、セキュリティチャンネルへパッケージされてもよい。セキュリティチャンネルは、単一のセキュリティ態様を実施してもよい。
【００３８】
以上、好ましい実施形態及び実施例を参照して本発明を説明したが、これらは、本発明を例示するものであって、限定するものではないことを理解されたい。前記実施形態では、コンピュータ支援処理が示唆される。従って、本発明は、コンピュータ支援の処理方法、この方法を実施するためのロジックを含むシステム、この方法を実施するためのロジックが銘記された媒体、この方法を実施するためのロジックが銘記されたデータストリーム、或いはコンピュータアクセス可能な処理サービスにおいて実施することができる。当業者であれば、本発明の精神及び範囲内で種々の変更や組合せがなされ得ることが理解されよう。
【００３９】
【技術分野】
【０００１】
本発明は、２つ以上のウェブサービス間でセキュリティ構成をネゴシエーションしそして実施するためのコンピュータベースの装置及び方法に係る。より詳細には、本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して生成し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。
【０００２】
版権の通告：本特許文書の開示の一部分は、版権保護を受ける資料を含む。版権所有者は、特許商標庁の特許ファイル又は記録に現われるように誰かが特許文書又は特許開示を複写再現することに異議を唱えるものではなく、たとえそうでも全ての版権は確保されるものとする。
【０００３】
コンピュータプログラムリスト添付資料の参照：本明細書には、コンピュータプログラムリスト添付資料を添付する。このコンピュータプログラムリスト添付資料は、次のプログラム抜粋を含む。
SecuritySenderReceiverInfo.XSD （ネゴシエーション入力のスキーマ）
SecurityContractKeyInfo.XSD （セキュリティに使用するキーのスキーマ）
SecurityContract.XSD （ネゴシエーションから出力されるセキュリティ契約のためのスキーマ）
CommunitySecurityTemplatesInfo.XML （ネゴシエーション入力のスキーマ）
SecuritySenderInfo.XML （送信者情報の例）
SecurityReceiverInfo.XML （送信者情報の例）
ComputerSecurityContract.XML （計算型セキュリティ契約の例）
【背景技術】
【０００４】
ビジネス対ビジネス（Ｂ２Ｂ）及びアプリケーション対アプリケーション（Ａ２Ａ）電子商取引は、以前の慣習を電子データ交換（ＥＤＩ）に置き換えつつある。企業がＢ２Ｂ及びＡ２Ａシステムでそれらの効率を改善するように努力するにつれて、多数の互換性のないプラットホームや計算規格が出現した。互換性のある規格の中には、埋めるべきギャップが残っている。例えば、業界は、単純なウェブサービスは何かを定義した。単純なウェブサービスに関連した規格は、ＵＤＤＩ、ＷＳＤＬ、ＸＳＤＬ及びＳＯＡＰを含む。しかしながら、これらの規格は、実際のＢ２Ｂ及びＡ２Ａ電子商取引のためのセキュリティ、信頼性、管理性及びコレオグラフィー(choreography)要件を完全に満足するものではない。特にセキュリティは、多数のオプション及び構成上の問題を提起する。コラボレーティブウェブサービス及びそれらのセキュリティの必要性は、非ウェブビジネスと同様に進化することが予想される。ウェブサービスが進化するにつれてセキュリティオプション及び構成を動的に解決し且つ更新する包括的な又は一体化型の装置や方法は存在しない。
【０００５】
Ｂ２Ｂ及びＡ２Ａ電子商取引に適用可能な規格を拡張するための業界のイニシアティブは多数ある。コレオグラフィー努力は、ＯＡＳＩＳからのｅｂＸＭＬ／ＢＰＳＳ、ＩＢＭからのＷＳＦＬ、及びマイクロソフトからのＸＬＡＮＧを含む。会話努力は、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びマイクロソフトのＷＳルーティングを含む。主要なセキュリティ努力は、ＩＢＭ及びマイクロソフトからのＷＳセキュリティであり、又、ＯＡＳＩＳにも、ＳＡＭＬと称される相補的なセキュリティ努力が存在する。信頼性については、マイクロソフトからの提案、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びＩＢＭからのＨＴＴＰＲがある。Ｗ３Ｃは、これら全ての領域における規格化に向けられている。重要な業界の活動家は、ＷＳＩと称されるライバルのコンソーシアムを形成した。しかしながら、それらは、動的セキュリティネゴシエーション問題に向けられたものではない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従って、取引のパートナーに対するセキュリティオプション及び構成上の問題を動的に解決する方法及び装置を開発する機会が生じる。
【課題を解決するための手段】
【０００７】
本発明は、２つ以上のウェブサービス間でセキュリティ構成をネゴシエーションしそして実施するためのコンピュータベースの装置及び方法に係る。より詳細には、本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して発生し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。
【図面の簡単な説明】
【０００８】
【図１】セキュリティ構成のコンピュータ支援型の動的ネゴシエーションが有用となる１つの環境であるコミュニティ及びコミュニティのネットワークを示す図である。
【図２】セキュリティ構成のネゴシエーション及び実施を示す図である。
【図３】アルゴリズム形式の中の環境設定を調停するところを示す図である。
【図４】セキュリティ構成の計算に対して送信者がローカルであるときに受信者の情報を得るための別の実施形態を示す図である。
【図５】本発明の態様を実施するのに使用できるプログラムロジック及びリソースの１つのネットワークを示す図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照して詳細に説明する。本発明を例示するために好ましい実施形態を説明するが、これは、特許請求の範囲により規定された本発明の範囲を限定するものではない。当業者であれば、以下の説明に基づいて種々の同等の変更がなされ得ることが理解されよう。
【００１０】
図１は、セキュリティ構成のコンピュータ支援型の動的ネゴシエーションが有用となる１つの環境であるコミュニティ及びコミュニティのネットワークを示す。これらコミュニティの中で、あるコミュニティは、そのコミュニティの一部分であるユーザ、会社、サービス及びコネクタのような情報を含むローカルレジストリーを維持する。コミュニティは、市場、企業、又は事業部でよい。コミュニティは、１つ以上のコミュニティネットワークに属することができる。通常、コミュニティ及びネットワークは、ある共通のビジネス利益を有する。１つ以上のコミュニティネットワーク内のメンバーコミュニティ間で相互操作がなされる。ネットワークは、金市場ネットワーク１と、貴金属市場ネットワーク２と、プライベートネットワーク３と、グローバル取引ウェブネットワーク４とを備えている。この図では、金市場ネットワーク１及び貴金属市場ネットワーク２は、グローバル取引ウェブネットワーク４内に収容される。貴金属市場ネットワーク２は、金及び銀市場１４、１３を含む。金市場の顧客は、銀市場１３において銀を取引することができ、そして銀市場の顧客は、金市場１４において取引を行うことができる。１つのコミュニティであるＰＱＲ企業１７は、金市場ネットワーク１、プライベートネットワーク３及びグローバル取引ウェブネットワーク４に所属し、別のコミュニティであるＡＢＣ大規模供給者１８は、プライベートネットワーク３に所属する。この図では、ＸＹＺ金１４は、金を取引するための市場又はコミュニティである。企業は、このコミュニティに所属する。それら自体でコミュニティを形成しているＰＱＲ企業１７のような企業は、金市場ネットワーク１に所属する。これらのコミュニティは、金市場ネットワーク１及びグローバル取引ウェブネットワーク４の一部分である。小規模供給者１５は、金市場コミュニティの一部分である。他の企業１６は、金市場コミュニティネットワーク１の一部分であるコミュニティである。ＸＹＺ金１４と他の金市場エンティティ１５−１７との間の接続は、金市場が、例えば、勘定及びビジネスインテリジェンス情報を収集するために、金の取引を取り扱う企業（コミュニティ又はその他）間の全てのトラフィックを、ＸＹＺ金１４を通るルートにするよう要求することを示している。ＰＱＲ企業１７は、金市場の一部分であると共に、供給者１８とのローカルプライベートネットワークの一部分でもあるコミュニティである。小規模供給者１５は、それ自体でコミュニティを形成することを希望せず、むしろ、ユーザ、組織、サービス及び変換等のメタデータを金市場のレジストリーに登録する個々の小規模供給者でよい。一方、ＡＢＣ大規模供給者１８は、例えば、そのメタデータ、内部バックオフィスシステム及び変換を、それらが著しいコストで開発されたことから、一般的な公衆アクセスから隠れた状態に保持したいために、それ自身のプライベートネットワークを形成している。ＰＲＱ１７は、ＡＢＣ１８の顧客であるので、プライベートネットワーク３に参加する。フィナンシャルサービスプロバイダーＤＥＦフィナンシャル１２は、グローバル取引ウェブネットワーク４の誰かに、それ自身のコミュニティを形成したりグローバルトレーディングウェブルート１１に登録したりするフィナンシャルサービスを提供することを希望する。コミュニティのネットワークは、コミュニティのグローバルレジストリーを利用できるようにする。このグローバルレジストリーは、コミュニティをルックアップし、そしてそのコミュニティ又は外部コネクタへの１つ以上のルートを決定するのを許し、上記外部コネクタは、それを経てコミュニティへ向う電子商取引ドキュメントをルーティングできるものである。１つのコミュニティから別のコミュニティへルーティングされるドキュメントは、２つのコミュニティについては外部コネクタ間で直接ルーティングされてもよく、或いは１つ以上の中間コミュニティを経て間接的にルーティングされてもよい。又、コミュニティを伴うトランザクションに対するビジネス及びセキュリティルールも定義して、コミュニティレジスタに維持すことができる。一般に、図１は、電子商取引プラットホーム間の相互操作性の刺激を生じさせるエンティティ及びコミュニティの混合忠誠さを示す。
【００１１】
コネクタとは、他のアプリケーションと通信するアプリケーションに対する一般的な用語である。コネクタは、ハブ、ゲートウェイ、外部ポート、中央コネクタ等として機能する他のコネクタを通してピア対ピア（Ｐ２Ｐ）ベース又は指令ベースで通信することができる。Ｐ２Ｐで通信するコネクタは、同じトランスポート／エンベローププロトコルを使用する他のコネクタと通信することができる。Ｐ２Ｐで通信するコネクタは、任意であるが、同じトランスポート／エンベローププロトコルを使用しないコネクタと通信を試みるときに、変換サービスを実行する他のハブコネクタの協力を得てもよい。指令ベースで通信するコネクタは、ルーティングルールに基づいてハブコネクタを経て通信する。コネクタ間のルーティングルールは、１つ以上のトランスポート／エンベローププロトコルに対して１つ以上のハブ及びスポークトポロジーをサポートするように、指令グラフにマップすることができる。ハブ及びスポークトポロジーは、１つ以上の結合子 (tier)においてスポークに沿ってハブへの通信を指令する。これは、勘定、ビジネスインテリジェンス収集、追跡、監査、会計、その他の集中サービスを容易にする。図２に示唆されるように、異なるトランスポート／エンベローププロトコル及びテクノロジーをサポートするために、多数のハブ及びスポーク組織が同じコネクタをオーバーレイしてもよい。例えば、ＨＴＴＰ又はＨＴＴＰＳを使用するのではなく、ソニック(Sonic)をトランスポートテクノロジーとして使用するために、より強いハブ及びスポーク組織が必要とされてもよい。任意であるが、通信ルートは、ソース及び行先が同じコミュニティの一部分であるかどうかに依存してもよい。準コミュニティ（全コミュニティを含んでもよい）内で、集中機能が不要とされ、そして他の準コミュニティ内の行先と通信するときに親コネクタと通信するよう指令されたコネクタ間でＰ２Ｐ通信が許されてもよい。
【００１２】
コネクタは、単純なコネクタ（時々単にコネクタと称される）、ハブ（時々ゲートウェイ又はルーターと称される）又は中央コネクタと示されてもよい。或いは又、それらは、機能的に記述されてもよい。単純なコネクタは、同じ準コミュニティ内のコネクタ間でＰ２Ｐ通信することが許されるとき以外は、ハブコネクタを経て通信するよう指令される。いわゆるハブは、それらに明確に向けられ又はリンクされるコネクタにより使用される。ハブは、２つ以上の機能を果たすことができ、従って、ソースから行先へのルートにおいて２回以上現われることがある。ハブは、電子商取引のドキュメント又はメッセージを転送する。又、ハブは、共通のエンベローププロトコルをサポートするトランスポートプロトコル間で変換を行ってもよい。例えば、ハブは、エンベローププロトコルを変換し、そして受信時ではなく送信時に異なるトランスポートプロトコルを実施してもよい。中央コネクタは、ハブの特殊なケースであり、それらに明確に向けられもリンクもされないコネクタにより使用することができる。中央コネクタは、例えば、ルーティングルールに基づいてソースからコネクタを横断しても、行先により使用されるトランスポート／エンベローププロトコルをサポートするハブに至らないときに、変換機能を実行するのに有用である。
【００１３】
本発明の態様に基づくセキュリティ構成の概要がスキーマ及びプロセスフローにより与えられる。この点について、セキュリティ構成のネゴシエーションは、送信側及び受信側サービスのセキュリティプロファイルを使用して、相互に合意し得るセキュリティ構成を決定するためのコンピュータベースのプロセスにより実行される。好ましくは、このセキュリティ構成は、ユーザを介在せずに、ネゴシエーションされるか、又は潜在的に規則的に更新される。この構成は、ユーザの要求があったときに、又はユーザを介在せずに、メッセージが交換されるとき、又は他の何らかの周期又は時々、例えば、毎月、毎週、毎日、或いは特定の送信者と受信者との間のメッセージの交換に影響する事象が発生したとき（例えば、ソフトウェアコンポーネントの故障、又はセキュリティ環境設定の変化）、既にネゴシエーションされた構成が故障したとき、又は他の何らかの周期的又は時々のベースで、ネゴシエーションされ、更新され、又は有効性についてチェックされる。ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤ」は、セキュリティ構成のネゴシエーションに対する幾つかの入力を記述する。又、ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」は、いわゆるセキュリティ相互操作契約ドキュメント（ＳＣＩＤ）において、ネゴシエーションされるセキュリティ構成の一実施形態を記述する。図１のプロセスフローは、セキュリティ構成のネゴシエーション及び実施を記述するのに使用できる。
【００１４】
ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤ」は、セキュリティ構成のネゴシエーションに対して複数の入力ファイルを確認するのに使用できる。この実施形態では、マシン読み取り可能な入力ファイルは、ＸＭＬドキュメントである。他の実施形態では、他のデータ構造、例えば、ＸＭＬコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。スキーマ「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤ」は、ドキュメント発生ビューを含むスキーマの多数の別々のビューを与えるＸＭＬ Ｓｐｙ ＴＭのような一体化開発環境（ＩＤＥ）へファイルをロードすることにより最も良く理解される。送信者及び受信者セキュリティ相互操作性契約ドキュメント情報ブロックは、このスキーマにより定義される。Ｓｐｙのスキーマ設計ビューで見ると、ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＳＤは、送信者及び受信者セキュリティ情報を定義するのに使用される多数のコンポーネントを含む。ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＰｏｌｉｃｙＰｒｅｆｅｒｅｎｃｅコンポーネントは、ヘッダに署名し、信用証明(credential)を暗号化するためのコミュニティの環境設定、及び信用証明の環境設定を示す。これは、全コミュニティに対するデフォールト値を特定するのに使用できるし、又はコラボレーションパートナー（ＣＰ）に対するデフォールト値を特定するように適応することもできる。ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙコンポーネントは、署名及び暗号化の環境設定と、認証オプションとを特定するのを許す。サービスとサービスとの間で交換されるメッセージは、多数の部分を有することができる。署名及び暗号化ポリシーは、メッセージ全体又は個々の部分に適用することができる。この解決策は、書名及び暗号化ポリシーを部分内のエレメントに適用するように容易に拡張することができる。ＰｕｂｌｉｃＫｅｙｓコンポーネントは、このＣＰに対するキー記録を識別する。ＣｏｎｎｅｃｔｏｒＣａｐａｂｉｌｉｔｙコンポーネントは、セキュリティ構成の一部分を実施するリソースにコネクタ名のようなルーティング情報を与える。これは、暗号化能力、署名能力、暗号化パブリックキー当事者、及び署名パブリックキー当事者のようなコネクタ能力パラメータを含む。パブリックキー当事者は、署名が含まれるか暗号化が含まれるかに基づいて、送信者のＣＰ、受信者のＣＰ、又はコネクタの所有者である。パブリックキー当事者が定義されない場合には、メッセージ送信者のキーを署名に使用することができ、そしてメッセージ受信者のキーを暗号化に使用することができる。ＳｅｃｕｒｉｔｙＣｏｎｔａｉｎｅｒコンポーネントは、セキュリティに有用な付加的なオブジェクトを搬送するのに使用することができる。ＳｅｎｄｉｎｇＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｙＰｒｏｆｉｌｅコンポーネントは、送信側ＣＰに得られる信用証明情報を含む。ＣＰＳｅｎｄＳｅｒｖｉｃｅｓＳｅｃｕｒｉｔｙＰｏｌｉｃｙ及びＣＰＲｅｃｖＳｅｒｖｉｃｅｓＳｅｃｕｒｉｔｙＰｏｌｉｃｙコンポーネントは、各々、送信側及び受信側サービスに対するセキュリティポリシーのセットを含む。サービスの環境設定及びオーバーライドをここで定義することができる。
【００１５】
又、ソースコード添付資料におけるスキーマ「ＳｅｃｉｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」は、マシン読み取り可能なセキュリティ相互操作性契約ドキュメントを作成するためのモデルとして使用することができる。この実施形態では、マシン読み取り可能なドキュメントは、ＸＭＬドキュメントである。他の実施形態では、他のデータ構造、例えば、ＸＭＬコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。このスキーマは、セキュリティポリシーに対するポリシー及びチャンネルを定義する。セキュリティチャンネルは、署名、暗号化及び認証アルゴリズムのようなセキュリティアルゴリズムを実行するリソース及びリソースへのルートを定義する。又、これは、否認防止及び許可リソースを含んでもよい。
【００１６】
図２のプロセスフローは、セキュリティ構成のネゴシエーション及び実施を説明するのに使用される。一実施形態では、送信及び受信側サービスの環境設定がレジストリー２０１に維持される。このレジストリーは、各々のサービスがセキュリティ構成を計算できるように送信側及び受信側サービスに対してアクセスすることもできるし、或いは送信側及び受信側サービスの一方又は両方にアクセスできるセキュリティ構成計算サービスに利用することもできる。送信及び受信側サービスは、それら自身のレジスタを維持してもよい。或いは、送信及び受信側サービスに対して、それらのセキュリティ環境設定をセキュリティ構成のネゴシエーションの一部分として交換するためのプロトコルが開発されてもよい。レジストリー２０１は、更に、コラボレーションパートナーが所属するサービス又はコミュニティ或いはその両方を所有するコラボレーションパートナーのデフォールトの環境設定に関する情報を維持してもよい。デフォールトの環境設定は、一般的に、サービス特有の環境設定によりオーバーライドされてもよいし、或いはあるデフォールトの環境設定に、サービス特有の環境設定に勝る優位性が与えられてもよい。コラボレーションパートナーのデフォールトの環境設定は、コミュニティのデフォールトの環境設定とは異なるように処理されてもよい。セキュリティ構成の環境設定の入力記述は、レジストリー２０１又は別のソースから取り出されて、セキュリティ構成計算サービス２０２によって作用されてもよい。一実施形態では、この計算サービスは、セキュリティ契約ビルダーである。１組のセキュリティ構成が出力される（２０３）。これらの構成は、送信側及び受信側サービスで確認されてもよいし、送信側又は受信側サービスにより拒否を受けてもよいし、又は送信側及び受信側サービスにより信用されてもよい。送信側サービス２０５、又は送信側サービスに応答する別のサービスは、セキュリティ構成２０３を使用して、ドキュメント２０４を受信側サービス２０９へ送信すべく処理する。ある状況においては、セキュリティ構成は、信用されたアサーションサービス２０６からアサーションを得ることを要求する。
例えば、送信側及び受信側サービスは、ＳＡＭＬサービスを利用して認証アサーションを発生することに合意してもよい。セキュリティ構成２０３は、ＳＡＭＬアサーションの発生を要求し、そして送信側サービス２０５は、ＳＡＭＬサーバー２０６からＳＡＭＬアサーションを得る。別の実施形態では、信用されたサービス２０６により電子公証が与えられてもよい。銀行やセキュリティ当局は、公証と同様のファンクションにおいて認証アサーションを発生するための信用がある。ある環境においては、セキュリティ構成は、パブリックキーソース２０８からの非対称的署名又は暗号化に使用されるパブリックキーを得ることを要求する。例えば、送信側及び受信側サービスは、ＸＫＭＳサービスを利用してパブリックキーを交換することに合意してもよい。セキュリティ構成２０３は、ＸＫＭＳサービスアドレスをパブリックキーのソースとして特定する。送信側サービス２０５及び受信側サービス２０９は、両方とも、合意したキーソース２０８にアクセスする。セキュリティ構成２０３によれば、送信側サービス２０５は、ネットワーク２０７を経て受信当事者２０９へドキュメント２０４を通信する。ネットワーク２０７を通るルート及び搬送は、セキュリティ構成の一部分でもよいし、又はセキュアトランスポートインフラストラクチャーにより取り扱われるのが好ましい。セキュリティ構成２０３は、計算サービス２０２により受信当事者２０９へ与えられてもよいし、さもなければ、ドキュメント２０４を搬送するメッセージとは独立して受信当事者にアクセスできるようにされてもよい。或いは又、セキュリティ構成２０３は、予め構成されたプロトコルによりドキュメント２０４と共に含まれてもよい。例えば、これは、メッセージヘッダの一部分でもよいし、又はメッセージの個別部分でもよい。予め構成されたプロトコルは、メッセージヘッダを要求してもよいし、或いは当事者の各キーを使用して署名及び／又は暗号化されるべきメッセージ部分を要求してもよい。このプロセス及び前記スキーマを銘記して、ソースコード添付資料からの例を説明する。
【００１７】
ファイル「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＩｎｆｏ．ＸＭＬ」、「ＳｅｃｕｒｉｔｙＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＭＬ」及び「ＣｏｍｐｕｔｅＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＭＬ」は、送信者及び受信者の環境設定と、それにより生じる計算されたセキュリティ構成との例を与える。送信者及び受信者の環境設定は、上述したＸＭＬスキーマに適合するＸＭＬコードに示されている。計算されたセキュリティ構成は、ソースコード添付資料における「ＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」スキーマに適合する相互操作性セキュリティ契約ドキュメントに示されている。
【００１８】
この例では、送信者の環境設定情報は、コミュニティの環境設定及びサービスの環境設定を含む。コミュニティの環境設定は、セキュリティアルゴリズム、ヘッダに署名し、信用証明を暗号化し、そして入手可能な信用証明の中で選択するための環境設定に向けられる。又、コミュニティの環境設定は、セキュリティアルゴリズムの順序をランク付けしてもよいし、或いはセキュリティアルゴリズムの中で環境設定を指示してもよい。コミュニティに対する環境設定に代わって又はそれに加えて、コラボレーションパートナーに対する同様の１組の環境設定が与えられてもよい。この例では、コミュニティは、「ＸＭＬＳｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍＴｅｍｐｌｅｔｅ」と称するエレメントにおいて６組の署名アルゴリズムオプションと、「ＸＭＬＥｎｃｒｙｐｔｉｏｎＡｌｇｏｒｉｔｈｍＴｅｍｐｌｅｔｅ」と称されるエレメントにおいて３組の暗号化アルゴリズムオプションとを有する。これらの組のオプションは、テンプレートである。２つ以上のテンプレートのオプションを特定のアルゴリズムに対して設けることができる。テンプレートの使用で、オプションの構成が簡単化されると共に、送信側及び受信側サービスにより一貫したオプションの組が選択される見込みが高くなる。この例のコミュニティは、ヘッダに署名することも信用証明を暗号化することも好まず、そして基本的な信用証明を受け容れる。一般に、コミュニティ又はコラボレーションパートナーは、サービスが選択できるセキュリティ構成オプションを好んでもよいし、或いはコミュニティ又はコラボレーションパートナーは、幾つかのオプションだけを好んでもよい。送信者の環境設定ファイルにおけるコミュニティの環境設定は、コミュニティの環境設定のためのレジストリーエントリーのように、どこかに示されたコミュニティの環境設定に対応しなければならない。ファイル「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌｅｔｅｓＰｒｅｆｅｒｅｎｃｅｓ．ＸＭＬ」は、コミュニティのセキュリティ環境設定の幾つか又は全部を記録するのに使用されるファイルの一例である。
【００１９】
サービス（この例では送信側サービス）は、メッセージの部分の取り扱い、メッセージ全体の署名及び暗号化、並びに認証のためのその環境設定を「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」に記録する。メッセージは、多数の部分を有することができる。メッセージの部分に対応して、サービスは、メッセージの部分を識別し、そしてメッセージの部分に署名する又は署名しない、或いはメッセージの部分を暗号化する又は暗号化しないという環境設定を表現することができる。この実施形態では、一般的アルゴリズム又はＸＭＬ特有のアルゴリズムといったアルゴリズムのカテゴリーの環境設定を選択することができる。他の実施形態では、サービスは、アルゴリズムのカテゴリーを指定しなくてもよいし、又は特定のアルゴリズムを指定してもよい。
【００２０】
セキュリティに対する他の構成もこの例によりカバーされる。Ｘ５０９フォーマットでの受信者（バイヤー）のパブリックキーは、署名及び認証に使用される。いわゆるコネクタである２つのリソースは、署名及び暗号化に使用するために送信側サービスに対して識別される。送信者に得られる信用証明は、基本的及びＸ５０９信用証明として識別される。送信側サービスのセキュリティ構成の環境設定は、「ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＴｅｍｐｌｅｔｅＰｒｅｆｅｒｅｎｃｅ」のもとで１から３までの順序でランク付けされる。この例では、ＸＭＬ特有の暗号化に対して全部で３つの暗号化の環境設定がある。この例についてのこれら及び他の詳細は、ソースコード添付資料ファイル「ＳｅｃｕｒｉｔｙＳｅｎｄｅｒＩｎｆｏ．ＸＭＬ」に見られる。
【００２１】
受信当事者の環境設定は、ソースコード添付資料ファイル「ＳｅｃｕｒｉｔｙＲｅｃｅｉｖｅｒＩｎｆｏ．ＸＭＬ」に見られる。一般に、受信当事者の基準プロファイルのエレメントは、スキーマからの同じエレメント形式を使用しても、送信当事者のエレメントに非常に類似したものとなる。認証及び許可には著しい相違が見られる。というのは、認証及び許可に適用できるロジックは、あなたがあなたの信用証明を提示するかどうか、又は提示されたものを受け容れるべきかどうか決定することに依存するからである。例えば、送信当事者の「ＳｅｎｄｉｎｇＣＰＳｅｃｕｒｉｔｙＰｒｏｆｉｌｅ」は、入手可能な信用証明をリストする。このエレメントは、受信当事者の環境設定の部分ではない。この問題は、「ＡｃｃｅｐｔｅｄＣｒｅｄｅｎｔｉａｌ」を識別する受信当事者の「ＣＰＲｅｃｖＳｅｒｖｉｃｅｓＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」により対処される。
【００２２】
この例では、セキュリティ構成ロジックが調停するところの２つの形式の環境設定が示される。一方の形式の環境設定は、アルゴリズムテンプレートの中にある。エレメント「ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＴｅｍｐｌｅｔｅＰｒｅｆｅｒｅｎｃｅ」は、送信側及び受信側サービスの環境設定に２回現われて、アルゴリズムの中でコミュニティ及びサービス特有の環境設定を示す。図３は、アルゴリズム形式の中の環境設定の調停を示す。スタック３０１及び３０２は、送信側及び受信側の環境設定を表わしている。Ａは、セキュリティが最も高く、Ｇは、最も低いと仮定する。２つの環境設定スタック３０１、３０２において、環境設定ＢとＤは一致する。Ｂ又はＤを選択するための判断ルールは、環境設定の一方又は両方のスタックを考慮する。例えば、署名のための受信側サービスの環境設定（Ｄ）、又は暗号化のための送信側サービスの環境設定（Ｂ）は、一致するものの中から選択されてもよい。両方の環境設定を考慮して、最もセキュリティが高い（Ｂ）又は最もセキュリティが低い（Ｄ）が選択されてもよい。別の実施形態では、各サービスは、それらの環境設定に重み又はスコアを付けてもよいし、合成重み又はスコアを使用して、両方の環境設定を考慮に入れてもよい。第２の形式の環境設定は、メッセージの一部分に署名すべきか又はそれを暗号化すべきかである。何に署名するか又は何を暗号化するかは、「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」の「ＳＡＭｓｇＰａｒｔ」エレメントにより対処される。この例におけるメッセージ部分は、「オーダー」及び「イメージ」である。この例では、送信者及び受信者の環境設定は、「オーダー」の署名及び暗号化と、「イメージ」の暗号化のみについて一致する。受信者が署名された「イメージ」と、「オーダー」とを希望する場合には、環境設定は一致しない。次いで、この不一致を解決するために判断ルールが必要となる。利用できる判断ルールは、受信者の勝ち、送信者の勝ち、最も高い要件の勝ち、最も低い要件の勝ちを含むことができる。一方の形式の環境設定の調停は、セキュリティ手段を適用すべきかどうか決定する。他方の形式は、セキュリティ手段が適用されるときにオプションテンプレートの中で選択を行う。
【００２３】
この例に対する１組の計算された計算されたセキュリティ構成は、「ＣｏｍｐｕｔｅｒＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＭＬ」に現われ、これは、次のように部分的に再現される。
【００２４】
この１組のセキュリティ構成は、セキュリティポリシー及びセキュリティチャンネルに対する２つの主要セクションを有する。この例では、全メッセージに適用できる１つのセキュリティポリシーと、該セキュリティポリシーの部分を実施するための多数のセキュリティチャンネルがある。セキュリティポリシーセクションは、署名ポリシー、暗号化ポリシー及び暗号キー情報を設定する。又、これは、発信点又は受領の認証、許可及び否認防止に関するポリシーを設定してもよい。この実施形態では、同じ署名及び暗号化ポリシーがドキュメントの全ての部分に適用される。他の実施形態では、異なる部分に多数のアルゴリズムを適用することができる。署名、暗号化及び認証のために選択されるアルゴリズムは、オプションセットを含むテンプレートにより抽象化され、アルゴリズムの選択を簡単にする。選択されるアルゴリズムは、ロジック及びリソースに関連付けられ、従って、メッセージの異なる部分に署名し／照合し及びそれを暗号化し／暗号解読するのに、異なるサービス又はプロセスを使用することができる。セキュリティポリシーセクションの暗号キーエレメントにおいてパブリックキー又は証明書を送信することができる。セキュリティチャンネルセクションは、セキュリティポリシーの適用に含まれるサービス又はコネクタを記述する。特定のポリシーについては、チャンネルセクションは、セキュリティポリシーを適用する際に支援を要求するソースコネクタ（例えば、暗号化を要求する送信側サービス）と、セキュリティポリシーを適用するか、又はセキュリティポリシーを適用するロジック及びリソースに対して仲介者として働くターゲットコネクタとを識別する。署名、暗号化、認証、許可、又は否認防止のような特定のセキュリティポリシーに対して、そのセキュリティポリシーを実行するのに必要な特定の情報がセキュリティチャンネルセクションにおいて与えられる。
【００２５】
セキュリティ構成を決定するのに使用されるデータは、メッセージ及びアクティビティ関連データ、ＣＰサービス関連データ、セキュリティアルゴリズム関連データ、ルーティング関連データ、暗号キー関連データ、及びコンフィギュレーションデータとして分類することができる。これらの分類の使用に関する幾つかの付加的な詳細を以下に説明する。メッセージ及びアクティビティ関連データは、デジタル署名、暗号化、否認防止及び許可に関連したものである。否認防止については、受信者は、受信者への送信者メッセージについての信用ある当事者の確認であるところの送信者に対する否認防止の手段を要求してもよい。同様に、送信者は、受信者による送信者メッセージの受領についての信用ある当事者の確認であるところの受信者に対する否認防止の手段を要求してもよい。以上の説明に加えて、微細な粒度が望まれる場合には、データの特定項目にエレメントベースで署名及び暗号化を適用できることを述べておかねばならない。更に、送信側及び受信側サービスの対にオーバーライドを指定することもできる。例えば、既存の又は立証された関係を、完全に新規な関係とは異なるように処理することができる。セキュリティポリシーへのオーバーライドは、特定のケースにおけるセキュリティ要件を慎重に減少する（又は保証されたように増加する）ように実施できる。
【００２６】
ＣＰ関連データは、認証及び許可データを含む。許可は、ネットワークリソースへのアクセスを許可又は拒絶するプロセスである。ほとんどのコンピュータセキュリティシステムへのアクセスに対する許可は、２段階プロセスである。その第１段階は、本人（ユーザ、プロセス、アプリケーション又はサービス）がそれを請求することを保証するための認証である。第２段階は、本人がその認識に基づいて種々のリソースへアクセスするのを許す許可である。許可は、アクセス制御とも称される。アクセス制御は、ウェブサイトリソースへのアクセスを許可するのに使用される。これは、ユーザ、ユーザのグループ、及びユーザに指定される役割に関する情報を管理する。ＳＡＭＬは、ＳＯＡＰメッセージにおいてセキュリティ事象（認証及び許可）及び属性（例えばクレジット等級）に関する情報を共有するためのＸＭＬベースの手段を与える。このＳＡＭＬデータは、次いで、第三者へ送信することができ、これは、「分散された信用」を可能にし、これにより、ユーザは、一度署名すると、それらの認証又は許可の詳細を再使用することができる。ＳＡＭＬ又は同様の信用された当事者のテクノロジーでは、係争当局は、要求者により証拠が与えられると、リソースウェブサービスへのアクセス形式に対して、当該サービス又は送信者による要求を許可すべきかどうか判断する。許可判断は、特定のリソースへの当該アクセスを許可又は拒絶する。ＳＡＭＬは、ウェブサービスセキュリティに対する有用なオプションであるが、最初にある程度の信用及び技術的リソースを要求する。ＳＡＭＬが利用できないか又は好ましくないときには、ＩＤ／パスワードや、ＩＤに関連した特典のテーブルのような他の解決策を使用することができる。本発明は、使用する許可テクノロジーにより限定されるものではなく、現在利用できる又は今後発明されるテクノロジーの中の選択へと更に抽象的に拡張される。ＳＡＭＬ許可又はＩＤ／パスワードテクノロジーでは、許可データを暗号化してメッセージへ組み込むことができる。
【００２７】
セキュリティアルゴリズムに関連したデータは、署名、暗号化及び否認防止のためのアルゴリズム及びコンフィギュレーションオプションを含む。スキーマが示すように、署名アルゴリズムオプション（ＸＭＬ又は非ＸＭＬ）は、ＸＭＬＤｓｉｇの使用、キャノニカライゼーション(Canonicalization)アルゴリズムの選択、署名メソッド、及びダイジェストアルゴリズムを含んでもよい。暗号化／暗号解読オプション（ＸＭＬ又は非ＸＭＬ）は
、キーサイズ、キー及びメソッドを含んでもよい。デフォールトは、サービスの環境設定をオーバーライドするか又はオーバーライドされているとしてサービスにより継承されてもよい。更に、上述したように、ＣＰ対に対して特定のオーバーライドを指定することができる。又、上述したオプションテンプレートは、セキュリティ構成のネゴシエーションを簡単化する。ＸＭＬ及び非ＸＭＬアルゴリズム、例えば、署名アルゴリズムには、異なるオプションが適用される。ＸＭＬ署名アルゴリズム、例えば、ＸＭＬＤｉｓｇは、メソッド、キャノニカライゼーション、変換及びダイジェストのためのオプションをオファーすることができ、一方、非ＸＭＬアルゴリズム、例えば、ＰＣＫＳ＃７は、署名及びダイジェストメソッドのみに対するオプションを有する。各サービスの環境設定リスト間に少なくとも１つの一致があるよう確保するためには、コミュニティの標準セキュリティテンプレートの使用が好ましい。コミュニティは、コミュニティ内でメッセージを交換できるよう確保するために、コミュニティ内で動作する全てのＣＰ又は全てのサービスが特定のコミュニティ標準セキュリティオプションをサポートすることを要求する。
【００２８】
ルーティングに関連したデータは、認証／照合、署名／照合及び暗号化／暗号解読を実施するロジック及びリソースにいかにアクセスするかを含む。ユニバーサルリソースネーム（ＵＲＮ）又はユニバーサルリソースロケータ（ＵＲＬ）のようないかなる形式のアクセス情報が使用されてもよい。上述した以前の特許出願に説明されたように、メッセージは、変換又は他の付加価値サービスのためのコネクタを経て多数のホップをとることができる。従って、いかなるアクションにも多数のルートステップが関連付けられる。セキュリティは、通常、変換又は他の付加価値サービスの後に再適用されることが必要となる。
【００２９】
暗号化キーに関連したデータは、一般的に、上述した。
【００３０】
コンフィギュレーションデータは、デフォールトの（例えばコミュニティ又はコラボレーションパートナー）環境設定と、信用証明の環境設定とを含む。
【００３１】
図４は、送信者が、セキュリティ構成の計算に対してローカルであるときに、受信者の情報を得るための別の実施形態を示す。図中、ローカルレジストリー４３１及びリモートレジストリー４３２が示されている。この例では、送信者がローカルであり、そして受信者がリモートである。送信者のデータは、ローカルレジストリー４３１に現存しそして完全である。送信者の情報は、収集され（４２１）、そしてセキュリティ構成４１１を計算するロジック及びリソースに利用できるようにされる。受信者のデータは、例えば、受信者が送信者と同じコミュニティにいてコミュニティ規模のレジストリーが存在するか、或いは受信者の情報が最近得られてローカルキャッシュされた場合に、現存しそして完全である。受信者の情報がどこで見つかるか（４３１又は４３２）に基づいて、プロセス４２２又は４２３が呼び出されて、受信者の情報を収集し、そしてセキュリティ構成を計算するロジックに利用できるようにされる。１組のセキュリティ構成４０１が得られる。
【００３２】
図５は、本発明の態様を実施するのに使用できるプログラムロジック及びリソースの１つのネットワークを示す。このネットワークのロジックコンポーネントは、送信側収集５５１と、受信側収集５５２と、データオブジェクトマネージャー５４１と、ルーティングマネージャー５４２と、信用証明ネゴシエーター５３１と、テンプレートネゴシエーター５３２と、コネクタマネージャー５３３と、認証マネージャー５２１と、ポリシーマネージャー５２２と、パブリックキーマネージャー５２３と、アルゴリズムマネージャー５２４と、ポリシービルダー５１１と、チャンネルビルダー５１２と、セキュリティ構成ドキュメントビルダー５０１とを備えている。
【００３３】
コラボレーションパートナーのコミュニティにおいて動作してセキュリティ構成を発生するプログラムロジックの一実施形態を以下に説明する。送信者ＣＰを認証するための属性アサーションを含む受信者セキュリティ情報を収集する。送信者セキュリティ情報を収集する。ルーティングブロックを見て、セキュリティ手段を実施するための全てのコネクタ情報を見出す。各コネクタに対して能力パラメータを得る。ルーティングチェーンを通って進み、認証、署名及び暗号化のためにどのコネクタ対を使用するか見出す。受信者のサービスアクティビティメッセージオブジェクトを得る。これは、受信者から「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトを得ることを含んでもよい。これは、多数の部分を有し、そして全メッセージに対して署名及び暗号化ポリシーを有することができる。又、これも、送信者から「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトを得ることを含んでもよく、そして「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトにオーバーライドオプションを適宜に一致させる。（オーバーライド判断テーブルは、以下に説明する。）「ＳＡＭｓｇＳｅｃｕｒｉｔｙＰｏｌｉｃｙ」オブジェクトから、このメッセージに必要な全てのアルゴリズムを見出し、そして「ＲｅｑｕｉｒｅｄＡｌｇｏｒｉｔｈｍＬｉｓｔ」を構築する。「ＳｅｎｄＩｎｆｏ」及び「ＲｅｃｅｉｖｅＩｎｆｏ」の両方に対してコミュニティ環境設定オブジェクトを得る。これは、送信者の「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」オブジェクトを得ることを含んでもよく、これは、セキュリティアルゴリズムテンプレート及びコミュニティセキュリティポリシー環境設定を含む。又、これは、同じコミュニティでない場合に、受信者の「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」オブジェクトを得ることを含んでもよい。それらが同じコミュニティにいる場合には、オブジェクトポインタをセットすれば充分である。送信者及び受信者の両サービスに対するＣＰサービスオブジェクトを得、そして対応するコミュニティに対するＣＰオブジェクトを得る。これは、送信者及び受信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｙＰｒｅｆｅｒｅｎｃｅ」を構築することを含んでもよい。送信者及び受信者の環境設定と、「ＲｅｑｕｉｒｅｄＡｌｇｏｒｉｔｈｍＬｉｓｔ」の判断ルールとに基づいて、環境設定リストから選択を行うと共に、「ＲｅｑｕｉｒｅｄＴｅｍｐｌａｔｅＯｂｊｅｃｔＬｉｓｔ」を構築する。サービスの各環境設定リストがアルゴリズムにおいて一致しない場合には、コミュニティのデフォールトが一致を発生してもよい。受信者サービスに対して「ＳｅｒｖｉｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ」オブジェクトを得る。これは、受け容れられた信用証明及び認証モードを含む１つ以上の指定の認証メソッドを有する。「ＳｅｒｖｉｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ」オブジェクトからの信用証明と、送信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｅＰｒｅｆｅｒｅｎｃｅ」から得られる信用証明とを一致させる。２つ以上の一致がある場合には、受信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｅＰｒｅｆｅｒｅｎｃｅ」から、又は受信者に対応する「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」から、「ＣｒｅｄｅｎｔｉａｌＰｒｅｆｅｒｅｎｃｅ」に一致するものを得る。受信者の「ＣＰＳｅｃｕｒｉｔｙＰｏｌｉｃｅＰｒｅｆｅｒｅｎｃｅ」、又は受信者の「ＣｏｍｍｕｎｉｔｙＳｅｃｕｒｉｔｙＴｅｍｐｌａｔｅｓＰｒｅｆｅｒｅｎｃｅ」オブジェクトのいずれかから、「ＳｉｇｎＭｅｓｓａｇｅＨｅａｄｅｒ」及び「ＥｎｃｒｙｐｔＣｒｅｄｅｎｔｉａｌ」の値を得る。いずれの場所でも値が指定されない場合には、それを偽又は真のようなデフォールトにセットする。受信者により選択された利用可能な送信者の信用証明、受信者に対する「ＳｅｒｖｉｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ」オブジェクトに指定された認証モード、「ＳｉｇｎＭｅｓｓａｇｅＨｅａｄｅｒ」ブール属性、及び「ＥｎｃｒｙｐｔＣｒｅｄｅｎｔｉａｌ」を使用して、認証アルゴリズムを構築する。コネクタの「ＰｕｂｌｉｃＫｅｙＣａｐａｂｉｌｉｔｙ」に基づいて、適切なキーを得る。これは、暗号化が要求される場合には、送信者の暗号キーを得ることを含み、そして署名が要求される場合には、受信者の署名キーＩＤを得ることを含む。Ｘ５０９認証が要求される場合には、受信者の認証キーＩＤを得る。セキュリティ構成のポリシーセクションを構築する。チャンネルセクションに対するコネクタを見つけ、そしてセキュリティ構成のチャンネルセクションを構築する。
【００３４】
判断テーブルを使用して、メッセージの一部分に署名すべきか又は暗号化すべきかに関連した環境設定の形式の調停を実施してもよい。この場合も、署名すべきでない環境設定を受け容れたり受信者の環境設定又は単なる反対を受け容れたりするように判断を偏らせることもできる。考えられる判断ルールを実施するのに使用できる判断テーブルを以下に示す。
【００３５】
【００３６】
本発明は、送信者と受信者との間の経路に沿って中間コネクタにおいて署名及び暗号化をサポートするように容易に拡張される。これは、メッセージの発信者でも最終的な受信者でもないルーティング経路に沿ったコネクタにおいてドキュメントに署名し及びドキュメントを暗号化することができる上で有用である。これは、ゲートウェイ、ルーター及び中央コネクタにとって有用である。ゲートウェイについては、署名され／暗号化されたメッセージデータが１つのエンベローププロトコルから別のものへ変換される場合に、署名及び暗号化をゲートウェイにより実行することが必要になり得る。ルーター及び中央コネクタについては、外部コミュニティに対し企業への単一の入口／出口ポイントを使用するのが望ましい。ルーター又は中央コネクタは、中央のセキュリティハブとして働くと共に、企業全体に代わってセキュリティオペレーションを遂行又は編成することができる。これは、ＰＫＩマネージメント及びその他の管理負担を簡単化できる。この機能は、コミュニティの企業部分においてコネクタのセキュリティ能力を設定することにより構成できる。コネクタは、署名能力又は暗号化能力をもつようにエンベロープ／トランスポートプロトコルベースで構成できると共に、他のコネクタにおけるコラボレーションパートナーの署名及び暗号化能力にリンクすることができる。ゲートウェイ及びルーターの場合には、ＣＰ自身のキー又はゲートウェイ／ルーターコネクタを使用するようにコネクタを構成することができる。
【００３７】
以上の説明から、当業者であれば、本発明の態様及び要素から広範囲なシステム及び方法を構成できることが明らかであろう。一実施形態は、送信側サービスと受信側サービスとの間で１つ以上のメッセージを交換するためのセキュリティオプションを動的に決定する方法である。この方法は、送信者及び受信者のセキュリティの環境設定を使用し、これは、第１及び第２のサービスに対してマシンセキュリティプロファイルの形態をとり得る。セキュリティプロファイルは、各サービスに受け容れられるセキュリティオプション／エレメント及びオプションサブセットを識別することができる。オプションは、メッセージの１つ以上の部分に署名し又は暗号化するための要件、１つ以上の署名アルゴリズムに対応する署名オプションサブセット、１つ以上の暗号化アルゴリズムに対応する暗号化オプションサブセット、署名及び暗号キーの識別、並びに認証アルゴリズムの識別を含んでもよい。動的な方法は、セキュリティプロファイルにアクセスし、そして各サービスに受け容れられる特定オプションセットを選択することを含む。任意であるが、このオプションセットは、各サービスとサービスとの間にメッセージを通信するのに使用できる。本発明の多数のオプション及び態様をこの実施形態に付加することができる。セキュリティプロファイルは、第１及び第２サービスのセキュリティロジックにアクセスできる１つ以上のレジストリーに維持することができる。デフォールトオプションサブセット及び／又は環境設定は、コミュニティ又はコラボレーションパートナーセキュリティプロファイルにおいて指定することができると共に、サービスセキュリティプロファイルへコピーされてもよい。署名又は暗号化の要件は、メッセージの部分又はメッセージ全体に適用することもできる。署名及び暗号化アルゴリズムは、メッセージ全体に適用して複雑さを減少することもできる。署名及び暗号キーは、対称的でも、非対称的でもよい。認証は、信用されたエージェント、例えば、ＳＡＭＬサーバーにより、各サービスとサービスとの間にメッセージを通信する前に、実行されてもよい。信用されたエージェントによる認証は、認証アサーションにより証拠とされてもよい。或いは又、認証は、受信側サービスにより検査するための信用証明を提示することを含んでもよい。これらの信用証明は、メッセージの一部分でもよいし、又はメッセージに加えて送信されてもよい。認証に加えて、許可は、セキュリティ構成により対処されてもよい。セキュリティプロファイルは、送信側サービスの特典を確立するために少なくとも１つの許可アルゴリズムの識別を含んでもよい。この許可は、メッセージを通信する前に信用されたエージェントにより実施されてもよいし、或いはメッセージを受信するサービスに信用証明を提示することにより実施されてもよい。本発明の更に別の態様は、署名及び／又は暗号化のためのオプションサブセットの中で各サービスの環境設定を考慮に入れる。一方又は両方のサービスの環境設定が考慮されてもよい。受信者が勝ち、送信者が勝ち、最もセキュアなものが勝ち、最もセキュアでないものが勝ち、又は両サービスの環境設定の重み付けファクタを含む上述したいずれの判断ルールが適用されてもよい。セキュリティ構成の決定は、署名、暗号化、認証、許可又は否認防止の任意の組合せを実施するように各当事者により使用されるべきリソースを決定することを含んでもよい。リソース、アルゴリズム及びオプションは、セキュリティチャンネルへパッケージされてもよい。セキュリティチャンネルは、単一のセキュリティ態様を実施してもよい。
【００３８】
以上、好ましい実施形態及び実施例を参照して本発明を説明したが、これらは、本発明を例示するものであって、限定するものではないことを理解されたい。前記実施形態では、コンピュータ支援処理が示唆される。従って、本発明は、コンピュータ支援の処理方法、この方法を実施するためのロジックを含むシステム、この方法を実施するためのロジックが銘記された媒体、この方法を実施するためのロジックが銘記されたデータストリーム、或いはコンピュータアクセス可能な処理サービスにおいて実施することができる。当業者であれば、本発明の精神及び範囲内で種々の変更や組合せがなされ得ることが理解されよう。
【００３９】
【特許請求の範囲】
【請求項１】
１つ以上の部分を有する少なくとも１つのメッセージをサービスとサービスとの間で交換するためのセキュリティオプションを動的に決定する方法において、
第１及び第２のサービスに対するマシン読み取り可能なセキュリティプロファイルを与えるステップであって、前記セキュリティプロファイルは、各々のサービスに受け容れられる複数のセキュリティエレメントを識別し、そして該セキュリティエレメントは、
前記メッセージの１つ以上の部分に署名するための要件と、
前記メッセージの１つ以上の部分を暗号化するための要件と、
前記メッセージの１つ以上の部分に適用されるべき署名アルゴリズムを含む、署名アルゴリズムのための１つ以上の署名オプションサブセットと、
前記メッセージの１つ以上の部分に適用されるべき暗号化アルゴリズムを含む、暗号化アルゴリズムのための１つ以上の暗号化オプションサブセットと、
前記署名アルゴリズムと共に使用するための１つ以上の署名キーと、
前記暗号化アルゴリズムと共に使用するための１つ以上の暗号キーと、
前記メッセージの１つ以上の部分に適用されるべき少なくとも１つの認証アルゴリズムと、を含むようなステップと、
前記セキュリティプロファイルにアクセスし、そして各々のサービスに受け容れられるメッセージに対する前記セキュリティエレメントの特定セットを選択するステップと、
前記特定オプションセットに従って各サービスとサービスとの間でメッセージを通信するステップと、
を備えた方法。
【請求項２】
前記セキュリティプロファイルは、前記第１及び第２サービスのセキュリティロジックにアクセスできるレジストリーに維持される請求項１に記載の方法。
【請求項３】
マシン読み取り可能なデフォールトセキュリティプロファイルにおけるデフォールトにより１つ以上のセキュリティエレメントが特定される請求項１に記載の方法。
【請求項４】
前記署名要件は、前記メッセージの個々の部分に適用される請求項１に記載の方法。
【請求項５】
前記署名要件は、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項６】
前記暗号化要件は、前記メッセージの個々の部分に適用される請求項１に記載の方法。
【請求項７】
前記暗号化要件は、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項８】
前記署名アルゴリズムは、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項９】
前記暗号化アルゴリズムは、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項１０】
前記署名及び暗号キーは非対称的である請求項１に記載の方法。
【請求項１１】
前記暗号キーは対称的である請求項１に記載の方法。
【請求項１２】
前記認証アルゴリズムは、メッセージを通信する前に信用されたエージェントにより実行されそして認証アサーションにより証拠とされる請求項１に記載の方法。
【請求項１３】
前記認証アルゴリズムは、メッセージを受信するサービスにより検査するためにメッセージに添付する信用証明を提示することを含む請求項１に記載の方法。
【請求項１４】
前記セキュリティエレメントは、更に、送信側サービスの特典を確立するために少なくとも１つの許可アルゴリズムの識別を含む請求項１に記載の方法。
【請求項１５】
前記許可アルゴリズムは、メッセージを通信する前に信用されたエージェントにより実行されそして許可アサーションにより証拠とされる請求項１４に記載の方法。
【請求項１６】
前記認証アルゴリズムは、メッセージを受信するサービスにより検査するためにメッセージに添付する信用証明を提示することを含む請求項１４に記載の方法。
【請求項１７】
前記セキュリティプロファイルは、更に、前記署名及び暗号化セキュリティエレメント間の環境設定の記述を含み、そして前記特定オプションサブセットを選択することは、少なくとも１つのサービスの環境設定を考慮する請求項１に記載の方法。
【請求項１８】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを受信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項１９】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを送信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項２０】
前記特定オプションサブセットを選択することは、両サービスの環境設定を考慮する請求項１７に記載の方法。
【請求項２１】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるセキュリティエレメントの中の最高のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２２】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるセキュリティエレメントの中の最低のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２３】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、少なくとも１つのサービスの環境設定を考慮する請求項１７に記載の方法。
【請求項２４】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを受信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項２５】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを送信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項２６】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、両サービスの環境設定を考慮する請求項１７に記載の方法。
【請求項２７】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるセキュリティエレメントの中の最高のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２８】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるセキュリティエレメントの中の最低のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２９】
前記セキュリティプロファイルは、更に、署名及び暗号化を実施するために各サービスにより使用される１つ以上のリソースを含む請求項１に記載の方法。
【請求項３０】
前記セキュリティプロファイルは、更に、署名及び暗号化を実施するために各サービスにより使用される１つ以上のリソースを含む請求項１７に記載の方法。
【請求項３１】
前記セキュリティプロファイルは、更に、メッセージを送信するサービスを認証するのに使用される１つ以上のリソースを含む請求項１に記載の方法。
【請求項１】
１つ以上の部分を有する少なくとも１つのメッセージをサービスとサービスとの間で交換するためのセキュリティオプションを動的に決定する方法において、
第１及び第２のサービスに対するマシン読み取り可能なセキュリティプロファイルを与えるステップであって、前記セキュリティプロファイルは、各々のサービスに受け容れられる複数のセキュリティエレメントを識別し、そして該セキュリティエレメントは、
前記メッセージの１つ以上の部分に署名するための要件と、
前記メッセージの１つ以上の部分を暗号化するための要件と、
前記メッセージの１つ以上の部分に適用されるべき署名アルゴリズムを含む、署名アルゴリズムのための１つ以上の署名オプションサブセットと、
前記メッセージの１つ以上の部分に適用されるべき暗号化アルゴリズムを含む、暗号化アルゴリズムのための１つ以上の暗号化オプションサブセットと、
前記署名アルゴリズムと共に使用するための１つ以上の署名キーと、
前記暗号化アルゴリズムと共に使用するための１つ以上の暗号キーと、
前記メッセージの１つ以上の部分に適用されるべき少なくとも１つの認証アルゴリズムと、を含むようなステップと、
前記セキュリティプロファイルにアクセスし、そして各々のサービスに受け容れられるメッセージに対する前記セキュリティエレメントの特定セットを選択するステップと、
前記特定オプションセットに従って各サービスとサービスとの間でメッセージを通信するステップと、
を備えた方法。
【請求項２】
前記セキュリティプロファイルは、前記第１及び第２サービスのセキュリティロジックにアクセスできるレジストリーに維持される請求項１に記載の方法。
【請求項３】
マシン読み取り可能なデフォールトセキュリティプロファイルにおけるデフォールトにより１つ以上のセキュリティエレメントが特定される請求項１に記載の方法。
【請求項４】
前記署名要件は、前記メッセージの個々の部分に適用される請求項１に記載の方法。
【請求項５】
前記署名要件は、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項６】
前記暗号化要件は、前記メッセージの個々の部分に適用される請求項１に記載の方法。
【請求項７】
前記暗号化要件は、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項８】
前記署名アルゴリズムは、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項９】
前記暗号化アルゴリズムは、前記メッセージ全体に適用される請求項１に記載の方法。
【請求項１０】
前記署名及び暗号キーは非対称的である請求項１に記載の方法。
【請求項１１】
前記暗号キーは対称的である請求項１に記載の方法。
【請求項１２】
前記認証アルゴリズムは、メッセージを通信する前に信用されたエージェントにより実行されそして認証アサーションにより証拠とされる請求項１に記載の方法。
【請求項１３】
前記認証アルゴリズムは、メッセージを受信するサービスにより検査するためにメッセージに添付する信用証明を提示することを含む請求項１に記載の方法。
【請求項１４】
前記セキュリティエレメントは、更に、送信側サービスの特典を確立するために少なくとも１つの許可アルゴリズムの識別を含む請求項１に記載の方法。
【請求項１５】
前記許可アルゴリズムは、メッセージを通信する前に信用されたエージェントにより実行されそして許可アサーションにより証拠とされる請求項１４に記載の方法。
【請求項１６】
前記認証アルゴリズムは、メッセージを受信するサービスにより検査するためにメッセージに添付する信用証明を提示することを含む請求項１４に記載の方法。
【請求項１７】
前記セキュリティプロファイルは、更に、前記署名及び暗号化セキュリティエレメント間の環境設定の記述を含み、そして前記特定オプションサブセットを選択することは、少なくとも１つのサービスの環境設定を考慮する請求項１に記載の方法。
【請求項１８】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを受信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項１９】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを送信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項２０】
前記特定オプションサブセットを選択することは、両サービスの環境設定を考慮する請求項１７に記載の方法。
【請求項２１】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるセキュリティエレメントの中の最高のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２２】
前記特定オプションサブセットを選択することは、各サービスに受け容れられるセキュリティエレメントの中の最低のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２３】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、少なくとも１つのサービスの環境設定を考慮する請求項１７に記載の方法。
【請求項２４】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを受信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項２５】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを送信するサービスにより最も好まれるオプションサブセットに対応する請求項１７に記載の方法。
【請求項２６】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、両サービスの環境設定を考慮する請求項１７に記載の方法。
【請求項２７】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるセキュリティエレメントの中の最高のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２８】
前記メッセージの１つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるセキュリティエレメントの中の最低のセキュリティレベルを考慮する請求項１７に記載の方法。
【請求項２９】
前記セキュリティプロファイルは、更に、署名及び暗号化を実施するために各サービスにより使用される１つ以上のリソースを含む請求項１に記載の方法。
【請求項３０】
前記セキュリティプロファイルは、更に、署名及び暗号化を実施するために各サービスにより使用される１つ以上のリソースを含む請求項１７に記載の方法。
【請求項３１】
前記セキュリティプロファイルは、更に、メッセージを送信するサービスを認証するのに使用される１つ以上のリソースを含む請求項１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１１−２３８２８９（Ｐ２０１１−２３８２８９Ａ）
【公開日】平成２３年１１月２４日（２０１１．１１．２４）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−１７７７６１（Ｐ２０１１−１７７７６１）
【出願日】平成２３年７月２８日（２０１１．７．２８）
【分割の表示】特願２００４−５３７６７３（Ｐ２００４−５３７６７３）の分割
【原出願日】平成１５年８月１９日（２００３．８．１９）
【出願人】（５０８０４１０８０）オープン インヴェンション ネットワーク リミテッド ライアビリティ カンパニー (4)
【Ｆターム（参考）】
【公開日】平成２３年１１月２４日（２０１１．１１．２４）
【国際特許分類】
【出願番号】特願２０１１−１７７７６１（Ｐ２０１１−１７７７６１）
【出願日】平成２３年７月２８日（２０１１．７．２８）
【分割の表示】特願２００４−５３７６７３（Ｐ２００４−５３７６７３）の分割
【原出願日】平成１５年８月１９日（２００３．８．１９）
【出願人】（５０８０４１０８０）オープン インヴェンション ネットワーク リミテッド ライアビリティ カンパニー (4)
【Ｆターム（参考）】
[ Back to top ]