1つ以上の部分を有する少なくとも1つのメッセージをサービスとサービスとの間で交換するためのセキュリティオプションを動的に決定する方法において、第1及び第2のサービスに対するマシン読み取り可能なセキュリティプロファイルを与えるステップであって、前記セキュリティプロファイルは、各々のサービスに受け容れられる複数のセキュリティエレメントを識別し、そして該セキュリティエレメントは、前記メッセージの1つ以上の部分に署名するための要件と、前記メッセージの1つ以上の部分を暗号化するための要件と、前記メッセージの1つ以上の部分に適用されるべき署名アルゴリズムを含む、署名アルゴリズムのための1つ以上の署名オプションサブセットと、前記メッセージの1つ以上の部分に適用されるべき暗号化アルゴリズムを含む、暗号化アルゴリズムのための1つ以上の暗号化オプションサブセットと、前記署名アルゴリズムと共に使用するための1つ以上の署名キーと、前記暗号化アルゴリズムと共に使用するための1つ以上の暗号キーと、前記メッセージの1つ以上の部分に適用されるべき少なくとも1つの認証アルゴリズムと、を含むようなステップと、前記セキュリティプロファイルにアクセスし、そして各々のサービスに受け容れられるメッセージに対する前記セキュリティエレメントの特定セットを選択するステップと、前記特定オプションセットに従って各サービスとサービスとの間でメッセージを通信するステップと、を備えた方法。前記セキュリティプロファイルは、前記第1及び第2サービスのセキュリティロジックにアクセスできるレジストリーに維持される請求項1に記載の方法。マシン読み取り可能なデフォールトセキュリティプロファイルにおけるデフォールトにより1つ以上のセキュリティエレメントが特定される請求項1に記載の方法。前記署名要件は、前記メッセージの個々の部分に適用される請求項1に記載の方法。前記署名要件は、前記メッセージ全体に適用される請求項1に記載の方法。前記暗号化要件は、前記メッセージの個々の部分に適用される請求項1に記載の方法。前記暗号化要件は、前記メッセージ全体に適用される請求項1に記載の方法。前記署名アルゴリズムは、前記メッセージ全体に適用される請求項1に記載の方法。前記暗号化アルゴリズムは、前記メッセージ全体に適用される請求項1に記載の方法。前記署名及び暗号キーは非対称的である請求項1に記載の方法。前記暗号キーは対称的である請求項1に記載の方法。前記認証アルゴリズムは、メッセージを通信する前に信用されたエージェントにより実行されそして認証アサーションにより証拠とされる請求項1に記載の方法。前記認証アルゴリズムは、メッセージを受信するサービスにより検査するためにメッセージに添付する信用証明を提示することを含む請求項1に記載の方法。前記セキュリティエレメントは、更に、送信側サービスの特典を確立するために少なくとも1つの許可アルゴリズムの識別を含む請求項1に記載の方法。前記許可アルゴリズムは、メッセージを通信する前に信用されたエージェントにより実行されそして許可アサーションにより証拠とされる請求項14に記載の方法。前記認証アルゴリズムは、メッセージを受信するサービスにより検査するためにメッセージに添付する信用証明を提示することを含む請求項14に記載の方法。前記セキュリティプロファイルは、更に、前記署名及び暗号化セキュリティエレメント間の環境設定の記述を含み、そして前記特定オプションサブセットを選択することは、少なくとも1つのサービスの環境設定を考慮する請求項1に記載の方法。前記特定オプションサブセットを選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを受信するサービスにより最も好まれるオプションサブセットに対応する請求項17に記載の方法。前記特定オプションサブセットを選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを送信するサービスにより最も好まれるオプションサブセットに対応する請求項17に記載の方法。前記特定オプションサブセットを選択することは、両サービスの環境設定を考慮する請求項17に記載の方法。前記特定オプションサブセットを選択することは、各サービスに受け容れられるセキュリティエレメントの中の最高のセキュリティレベルを考慮する請求項17に記載の方法。前記特定オプションサブセットを選択することは、各サービスに受け容れられるセキュリティエレメントの中の最低のセキュリティレベルを考慮する請求項17に記載の方法。前記メッセージの1つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、少なくとも1つのサービスの環境設定を考慮する請求項17に記載の方法。前記メッセージの1つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを受信するサービスにより最も好まれるオプションサブセットに対応する請求項17に記載の方法。前記メッセージの1つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるオプションサブセットであって、メッセージを送信するサービスにより最も好まれるオプションサブセットに対応する請求項17に記載の方法。前記メッセージの1つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、両サービスの環境設定を考慮する請求項17に記載の方法。前記メッセージの1つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるセキュリティエレメントの中の最高のセキュリティレベルを考慮する請求項17に記載の方法。前記メッセージの1つ以上の部分に署名する要件又はそれを暗号化する要件を選択することは、各サービスに受け容れられるセキュリティエレメントの中の最低のセキュリティレベルを考慮する請求項17に記載の方法。前記セキュリティプロファイルは、更に、署名及び暗号化を実施するために各サービスにより使用される1つ以上のリソースを含む請求項1に記載の方法。前記セキュリティプロファイルは、更に、署名及び暗号化を実施するために各サービスにより使用される1つ以上のリソースを含む請求項17に記載の方法。前記セキュリティプロファイルは、更に、メッセージを送信するサービスを認証するのに使用される1つ以上のリソースを含む請求項1に記載の方法。従って、取引のパートナーに対するセキュリティオプション及び構成上の問題を動的に解決する方法及び装置を開発する機会が生じる。本発明は、2つ以上のウェブサービス間でセキュリティ構成をネゴシエーションしそして実施するためのコンピュータベースの装置及び方法に係る。より詳細には、本発明は、入力及び出力インターフェイスを特定し、入力に一致するセキュリティ契約を計算して発生し、そしてネゴシエーションされたセキュリティ構成に基づいてセキュリティを実施する装置及び方法に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。以下、添付図面を参照して詳細に説明する。本発明を例示するために好ましい実施形態を説明するが、これは、特許請求の範囲により規定された本発明の範囲を限定するものではない。当業者であれば、以下の説明に基づいて種々の同等の変更がなされ得ることが理解されよう。図1は、セキュリティ構成のコンピュータ支援型の動的ネゴシエーションが有用となる1つの環境であるコミュニティ及びコミュニティのネットワークを示す。これらコミュニティの中で、あるコミュニティは、そのコミュニティの一部分であるユーザ、会社、サービス及びコネクタのような情報を含むローカルレジストリーを維持する。コミュニティは、市場、企業、又は事業部でよい。コミュニティは、1つ以上のコミュニティネットワークに属することができる。通常、コミュニティ及びネットワークは、ある共通のビジネス利益を有する。1つ以上のコミュニティネットワーク内のメンバーコミュニティ間で相互操作がなされる。ネットワークは、金市場ネットワーク1と、貴金属市場ネットワーク2と、プライベートネットワーク3と、グローバル取引ウェブネットワーク4とを備えている。この図では、金市場ネットワーク1及び貴金属市場ネットワーク2は、グローバル取引ウェブネットワーク4内に収容される。貴金属市場ネットワーク2は、金及び銀市場14、13を含む。金市場の顧客は、銀市場13において銀を取引することができ、そして銀市場の顧客は、金市場14において取引を行うことができる。1つのコミュニティであるPQR企業17は、金市場ネットワーク1、プライベートネットワーク3及びグローバル取引ウェブネットワーク4に所属し、別のコミュニティであるABC大規模供給者18は、プライベートネットワーク3に所属する。この図では、XYZ金14は、金を取引するための市場又はコミュニティである。企業は、このコミュニティに所属する。それら自体でコミュニティを形成しているPQR企業17のような企業は、金市場ネットワーク1に所属する。これらのコミュニティは、金市場ネットワーク1及びグローバル取引ウェブネットワーク4の一部分である。小規模供給者15は、金市場コミュニティの一部分である。他の企業16は、金市場コミュニティネットワーク1の一部分であるコミュニティである。XYZ金14と他の金市場エンティティ15-17との間の接続は、金市場が、例えば、勘定及びビジネスインテリジェンス情報を収集するために、金の取引を取り扱う企業コミュニティ又はその他間の全てのトラフィックを、XYZ金14を通るルートにするよう要求することを示している。PQR企業17は、金市場の一部分であると共に、供給者18とのローカルプライベートネットワークの一部分でもあるコミュニティである。小規模供給者15は、それ自体でコミュニティを形成することを希望せず、むしろ、ユーザ、組織、サービス及び変換等のメタデータを金市場のレジストリーに登録する個々の小規模供給者でよい。一方、ABC大規模供給者18は、例えば、そのメタデータ、内部バックオフィスシステム及び変換を、それらが著しいコストで開発されたことから、一般的な公衆アクセスから隠れた状態に保持したいために、それ自身のプライベートネットワークを形成している。PRQ17は、ABC18の顧客であるので、プライベートネットワーク3に参加する。フィナンシャルサービスプロバイダーDEFフィナンシャル12は、グローバル取引ウェブネットワーク4の誰かに、それ自身のコミュニティを形成したりグローバルトレーディングウェブルート11に登録したりするフィナンシャルサービスを提供することを希望する。コミュニティのネットワークは、コミュニティのグローバルレジストリーを利用できるようにする。このグローバルレジストリーは、コミュニティをルックアップし、そしてそのコミュニティ又は外部コネクタへの1つ以上のルートを決定するのを許し、上記外部コネクタは、それを経てコミュニティへ向う電子商取引ドキュメントをルーティングできるものである。1つのコミュニティから別のコミュニティへルーティングされるドキュメントは、2つのコミュニティについては外部コネクタ間で直接ルーティングされてもよく、或いは1つ以上の中間コミュニティを経て間接的にルーティングされてもよい。又、コミュニティを伴うトランザクションに対するビジネス及びセキュリティルールも定義して、コミュニティレジスタに維持すことができる。一般に、図1は、電子商取引プラットホーム間の相互操作性の刺激を生じさせるエンティティ及びコミュニティの混合忠誠さを示す。コネクタとは、他のアプリケーションと通信するアプリケーションに対する一般的な用語である。コネクタは、ハブ、ゲートウェイ、外部ポート、中央コネクタ等として機能する他のコネクタを通してピア対ピアP2Pベース又は指令ベースで通信することができる。P2Pで通信するコネクタは、同じトランスポート/エンベローププロトコルを使用する他のコネクタと通信することができる。P2Pで通信するコネクタは、任意であるが、同じトランスポート/エンベローププロトコルを使用しないコネクタと通信を試みるときに、変換サービスを実行する他のハブコネクタの協力を得てもよい。指令ベースで通信するコネクタは、ルーティングルールに基づいてハブコネクタを経て通信する。コネクタ間のルーティングルールは、1つ以上のトランスポート/エンベローププロトコルに対して1つ以上のハブ及びスポークトポロジーをサポートするように、指令グラフにマップすることができる。ハブ及びスポークトポロジーは、1つ以上の結合子においてスポークに沿ってハブへの通信を指令する。これは、勘定、ビジネスインテリジェンス収集、追跡、監査、会計、その他の集中サービスを容易にする。図2に示唆されるように、異なるトランスポート/エンベローププロトコル及びテクノロジーをサポートするために、多数のハブ及びスポーク組織が同じコネクタをオーバーレイしてもよい。例えば、HTTP又はHTTPSを使用するのではなく、ソニックをトランスポートテクノロジーとして使用するために、より強いハブ及びスポーク組織が必要とされてもよい。任意であるが、通信ルートは、ソース及び行先が同じコミュニティの一部分であるかどうかに依存してもよい。準コミュニティ全コミュニティを含んでもよい内で、集中機能が不要とされ、そして他の準コミュニティ内の行先と通信するときに親コネクタと通信するよう指令されたコネクタ間でP2P通信が許されてもよい。コネクタは、単純なコネクタ時々単にコネクタと称される、ハブ時々ゲートウェイ又はルーターと称される又は中央コネクタと示されてもよい。或いは又、それらは、機能的に記述されてもよい。単純なコネクタは、同じ準コミュニティ内のコネクタ間でP2P通信することが許されるとき以外は、ハブコネクタを経て通信するよう指令される。いわゆるハブは、それらに明確に向けられ又はリンクされるコネクタにより使用される。ハブは、2つ以上の機能を果たすことができ、従って、ソースから行先へのルートにおいて2回以上現われることがある。ハブは、電子商取引のドキュメント又はメッセージを転送する。又、ハブは、共通のエンベローププロトコルをサポートするトランスポートプロトコル間で変換を行ってもよい。例えば、ハブは、エンベローププロトコルを変換し、そして受信時ではなく送信時に異なるトランスポートプロトコルを実施してもよい。中央コネクタは、ハブの特殊なケースであり、それらに明確に向けられもリンクもされないコネクタにより使用することができる。中央コネクタは、例えば、ルーティングルールに基づいてソースからコネクタを横断しても、行先により使用されるトランスポート/エンベローププロトコルをサポートするハブに至らないときに、変換機能を実行するのに有用である。本発明の態様に基づくセキュリティ構成の概要がスキーマ及びプロセスフローにより与えられる。この点について、セキュリティ構成のネゴシエーションは、送信側及び受信側サービスのセキュリティプロファイルを使用して、相互に合意し得るセキュリティ構成を決定するためのコンピュータベースのプロセスにより実行される。好ましくは、このセキュリティ構成は、ユーザを介在せずに、ネゴシエーションされるか、又は潜在的に規則的に更新される。この構成は、ユーザの要求があったときに、又はユーザを介在せずに、メッセージが交換されるとき、又は他の何らかの周期又は時々、例えば、毎月、毎週、毎日、或いは特定の送信者と受信者との間のメッセージの交換に影響する事象が発生したとき例えば、ソフトウェアコンポーネントの故障、又はセキュリティ環境設定の変化、既にネゴシエーションされた構成が故障したとき、又は他の何らかの周期的又は時々のベースで、ネゴシエーションされ、更新され、又は有効性についてチェックされる。ソースコード添付資料におけるスキーマSecuritySenderReceiverInfo.XSDは、セキュリティ構成のネゴシエーションに対する幾つかの入力を記述する。又、ソースコード添付資料におけるスキーマSecurityContract.XSDは、いわゆるセキュリティ相互操作契約ドキュメントSCIDにおいて、ネゴシエーションされるセキュリティ構成の一実施形態を記述する。図1のプロセスフローは、セキュリティ構成のネゴシエーション及び実施を記述するのに使用できる。ソースコード添付資料におけるスキーマSecuritySenderReceiverInfo.XSDは、セキュリティ構成のネゴシエーションに対して複数の入力ファイルを確認するのに使用できる。この実施形態では、マシン読み取り可能な入力ファイルは、XMLドキュメントである。他の実施形態では、他のデータ構造、例えば、XMLコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。スキーマSecuritySenderReceiverInfo.XSDは、ドキュメント発生ビューを含むスキーマの多数の別々のビューを与えるXMLSpyTMのような一体化開発環境IDEへファイルをロードすることにより最も良く理解される。送信者及び受信者セキュリティ相互操作性契約ドキュメント情報ブロックは、このスキーマにより定義される。Spyのスキーマ設計ビューで見ると、SecuritySenderReceiverInfo.XSDは、送信者及び受信者セキュリティ情報を定義するのに使用される多数のコンポーネントを含む。CommunitySecurityPolicyPreferenceコンポーネントは、ヘッダに署名し、信用証明を暗号化するためのコミュニティの環境設定、及び信用証明の環境設定を示す。これは、全コミュニティに対するデフォールト値を特定するのに使用できるし、又はコラボレーションパートナーCPに対するデフォールト値を特定するように適応することもできる。SAMsgSecurityPolicyコンポーネントは、署名及び暗号化の環境設定と、認証オプションとを特定するのを許す。サービスとサービスとの間で交換されるメッセージは、多数の部分を有することができる。署名及び暗号化ポリシーは、メッセージ全体又は個々の部分に適用することができる。この解決策は、書名及び暗号化ポリシーを部分内のエレメントに適用するように容易に拡張することができる。PublicKeysコンポーネントは、このCPに対するキー記録を識別する。ConnectorCapabilityコンポーネントは、セキュリティ構成の一部分を実施するリソースにコネクタ名のようなルーティング情報を与える。これは、暗号化能力、署名能力、暗号化パブリックキー当事者、及び署名パブリックキー当事者のようなコネクタ能力パラメータを含む。パブリックキー当事者は、署名が含まれるか暗号化が含まれるかに基づいて、送信者のCP、受信者のCP、又はコネクタの所有者である。パブリックキー当事者が定義されない場合には、メッセージ送信者のキーを署名に使用することができ、そしてメッセージ受信者のキーを暗号化に使用することができる。SecurityContainerコンポーネントは、セキュリティに有用な付加的なオブジェクトを搬送するのに使用することができる。SendingCPSecurityPolicyProfileコンポーネントは、送信側CPに得られる信用証明情報を含む。CPSendServicesSecurityPolicy及びCPRecvServicesSecurityPolicyコンポーネントは、各々、送信側及び受信側サービスに対するセキュリティポリシーのセットを含む。サービスの環境設定及びオーバーライドをここで定義することができる。又、ソースコード添付資料におけるスキーマSecirityContract.XSDは、マシン読み取り可能なセキュリティ相互操作性契約ドキュメントを作成するためのモデルとして使用することができる。この実施形態では、マシン読み取り可能なドキュメントは、XMLドキュメントである。他の実施形態では、他のデータ構造、例えば、XMLコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。このスキーマは、セキュリティポリシーに対するポリシー及びチャンネルを定義する。セキュリティチャンネルは、署名、暗号化及び認証アルゴリズムのようなセキュリティアルゴリズムを実行するリソース及びリソースへのルートを定義する。又、これは、否認防止及び許可リソースを含んでもよい。図2のプロセスフローは、セキュリティ構成のネゴシエーション及び実施を説明するのに使用される。一実施形態では、送信及び受信側サービスの環境設定がレジストリー201に維持される。このレジストリーは、各々のサービスがセキュリティ構成を計算できるように送信側及び受信側サービスに対してアクセスすることもできるし、或いは送信側及び受信側サービスの一方又は両方にアクセスできるセキュリティ構成計算サービスに利用することもできる。送信及び受信側サービスは、それら自身のレジスタを維持してもよい。或いは、送信及び受信側サービスに対して、それらのセキュリティ環境設定をセキュリティ構成のネゴシエーションの一部分として交換するためのプロトコルが開発されてもよい。レジストリー201は、更に、コラボレーションパートナーが所属するサービス又はコミュニティ或いはその両方を所有するコラボレーションパートナーのデフォールトの環境設定に関する情報を維持してもよい。デフォールトの環境設定は、一般的に、サービス特有の環境設定によりオーバーライドされてもよいし、或いはあるデフォールトの環境設定に、サービス特有の環境設定に勝る優位性が与えられてもよい。コラボレーションパートナーのデフォールトの環境設定は、コミュニティのデフォールトの環境設定とは異なるように処理されてもよい。セキュリティ構成の環境設定の入力記述は、レジストリー201又は別のソースから取り出されて、セキュリティ構成計算サービス202によって作用されてもよい。一実施形態では、この計算サービスは、セキュリティ契約ビルダーである。1組のセキュリティ構成が出力される203。これらの構成は、送信側及び受信側サービスで確認されてもよいし、送信側又は受信側サービスにより拒否を受けてもよいし、又は送信側及び受信側サービスにより信用されてもよい。送信側サービス205、又は送信側サービスに応答する別のサービスは、セキュリティ構成203を使用して、ドキュメント204を受信側サービス209へ送信すべく処理する。ある状況においては、セキュリティ構成は、信用されたアサーションサービス206からアサーションを得ることを要求する。例えば、送信側及び受信側サービスは、SAMLサービスを利用して認証アサーションを発生することに合意してもよい。セキュリティ構成203は、SAMLアサーションの発生を要求し、そして送信側サービス205は、SAMLサーバー206からSAMLアサーションを得る。別の実施形態では、信用されたサービス206により電子公証が与えられてもよい。銀行やセキュリティ当局は、公証と同様のファンクションにおいて認証アサーションを発生するための信用がある。ある環境においては、セキュリティ構成は、パブリックキーソース208からの非対称的署名又は暗号化に使用されるパブリックキーを得ることを要求する。例えば、送信側及び受信側サービスは、XKMSサービスを利用してパブリックキーを交換することに合意してもよい。セキュリティ構成203は、XKMSサービスアドレスをパブリックキーのソースとして特定する。送信側サービス205及び受信側サービス209は、両方とも、合意したキーソース208にアクセスする。セキュリティ構成203によれば、送信側サービス205は、ネットワーク207を経て受信当事者209へドキュメント204を通信する。ネットワーク207を通るルート及び搬送は、セキュリティ構成の一部分でもよいし、又はセキュアトランスポートインフラストラクチャーにより取り扱われるのが好ましい。セキュリティ構成203は、計算サービス202により受信当事者209へ与えられてもよいし、さもなければ、ドキュメント204を搬送するメッセージとは独立して受信当事者にアクセスできるようにされてもよい。或いは又、セキュリティ構成203は、予め構成されたプロトコルによりドキュメント204と共に含まれてもよい。例えば、これは、メッセージヘッダの一部分でもよいし、又はメッセージの個別部分でもよい。予め構成されたプロトコルは、メッセージヘッダを要求してもよいし、或いは当事者の各キーを使用して署名及び/又は暗号化されるべきメッセージ部分を要求してもよい。このプロセス及び前記スキーマを銘記して、ソースコード添付資料からの例を説明する。ファイルSecuritySenderInfo.XML、SecurityReceiverInfo.XML及びComputeSecurityContract.XMLは、送信者及び受信者の環境設定と、それにより生じる計算されたセキュリティ構成との例を与える。送信者及び受信者の環境設定は、上述したXMLスキーマに適合するXMLコードに示されている。計算されたセキュリティ構成は、ソースコード添付資料におけるSecurityContract.XSDスキーマに適合する相互操作性セキュリティ契約ドキュメントに示されている。この例では、送信者の環境設定情報は、コミュニティの環境設定及びサービスの環境設定を含む。コミュニティの環境設定は、セキュリティアルゴリズム、ヘッダに署名し、信用証明を暗号化し、そして入手可能な信用証明の中で選択するための環境設定に向けられる。又、コミュニティの環境設定は、セキュリティアルゴリズムの順序をランク付けしてもよいし、或いはセキュリティアルゴリズムの中で環境設定を指示してもよい。コミュニティに対する環境設定に代わって又はそれに加えて、コラボレーションパートナーに対する同様の1組の環境設定が与えられてもよい。この例では、コミュニティは、XMLSignatureAlgorithmTempleteと称するエレメントにおいて6組の署名アルゴリズムオプションと、XMLEncryptionAlgorithmTempleteと称されるエレメントにおいて3組の暗号化アルゴリズムオプションとを有する。これらの組のオプションは、テンプレートである。2つ以上のテンプレートのオプションを特定のアルゴリズムに対して設けることができる。テンプレートの使用で、オプションの構成が簡単化されると共に、送信側及び受信側サービスにより一貫したオプションの組が選択される見込みが高くなる。この例のコミュニティは、ヘッダに署名することも信用証明を暗号化することも好まず、そして基本的な信用証明を受け容れる。一般に、コミュニティ又はコラボレーションパートナーは、サービスが選択できるセキュリティ構成オプションを好んでもよいし、或いはコミュニティ又はコラボレーションパートナーは、幾つかのオプションだけを好んでもよい。送信者の環境設定ファイルにおけるコミュニティの環境設定は、コミュニティの環境設定のためのレジストリーエントリーのように、どこかに示されたコミュニティの環境設定に対応しなければならない。ファイルCommunitySecurityTempletesPreferences.XMLは、コミュニティのセキュリティ環境設定の幾つか又は全部を記録するのに使用されるファイルの一例である。サービスこの例では送信側サービスは、メッセージの部分の取り扱い、メッセージ全体の署名及び暗号化、並びに認証のためのその環境設定をSAMsgSecurityPolicyに記録する。メッセージは、多数の部分を有することができる。メッセージの部分に対応して、サービスは、メッセージの部分を識別し、そしてメッセージの部分に署名する又は署名しない、或いはメッセージの部分を暗号化する又は暗号化しないという環境設定を表現することができる。この実施形態では、一般的アルゴリズム又はXML特有のアルゴリズムといったアルゴリズムのカテゴリーの環境設定を選択することができる。他の実施形態では、サービスは、アルゴリズムのカテゴリーを指定しなくてもよいし、又は特定のアルゴリズムを指定してもよい。セキュリティに対する他の構成もこの例によりカバーされる。X509フォーマットでの受信者バイヤーのパブリックキーは、署名及び認証に使用される。いわゆるコネクタである2つのリソースは、署名及び暗号化に使用するために送信側サービスに対して識別される。送信者に得られる信用証明は、基本的及びX509信用証明として識別される。送信側サービスのセキュリティ構成の環境設定は、SecurityPolicyTempletePreferenceのもとで1から3までの順序でランク付けされる。この例では、XML特有の暗号化に対して全部で3つの暗号化の環境設定がある。この例についてのこれら及び他の詳細は、ソースコード添付資料ファイルSecuritySenderInfo.XMLに見られる。受信当事者の環境設定は、ソースコード添付資料ファイルSecurityReceiverInfo.XMLに見られる。一般に、受信当事者の基準プロファイルのエレメントは、スキーマからの同じエレメント形式を使用しても、送信当事者のエレメントに非常に類似したものとなる。認証及び許可には著しい相違が見られる。というのは、認証及び許可に適用できるロジックは、あなたがあなたの信用証明を提示するかどうか、又は提示されたものを受け容れるべきかどうか決定することに依存するからである。例えば、送信当事者のSendingCPSecurityProfileは、入手可能な信用証明をリストする。このエレメントは、受信当事者の環境設定の部分ではない。この問題は、AcceptedCredentialを識別する受信当事者のCPRecvServicesSecurityPolicyにより対処される。この例では、セキュリティ構成ロジックが調停するところの2つの形式の環境設定が示される。一方の形式の環境設定は、アルゴリズムテンプレートの中にある。エレメントSecurityPolicyTempletePreferenceは、送信側及び受信側サービスの環境設定に2回現われて、アルゴリズムの中でコミュニティ及びサービス特有の環境設定を示す。図3は、アルゴリズム形式の中の環境設定の調停を示す。スタック301及び302は、送信側及び受信側の環境設定を表わしている。Aは、セキュリティが最も高く、Gは、最も低いと仮定する。2つの環境設定スタック301、302において、環境設定BとDは一致する。B又はDを選択するための判断ルールは、環境設定の一方又は両方のスタックを考慮する。例えば、署名のための受信側サービスの環境設定D、又は暗号化のための送信側サービスの環境設定Bは、一致するものの中から選択されてもよい。両方の環境設定を考慮して、最もセキュリティが高いB又は最もセキュリティが低いDが選択されてもよい。別の実施形態では、各サービスは、それらの環境設定に重み又はスコアを付けてもよいし、合成重み又はスコアを使用して、両方の環境設定を考慮に入れてもよい。第2の形式の環境設定は、メッセージの一部分に署名すべきか又はそれを暗号化すべきかである。何に署名するか又は何を暗号化するかは、SAMsgSecurityPolicyのSAMsgPartエレメントにより対処される。この例におけるメッセージ部分は、オーダー及びイメージである。この例では、送信者及び受信者の環境設定は、オーダーの署名及び暗号化と、イメージの暗号化のみについて一致する。受信者が署名されたイメージと、オーダーとを希望する場合には、環境設定は一致しない。次いで、この不一致を解決するために判断ルールが必要となる。利用できる判断ルールは、受信者の勝ち、送信者の勝ち、最も高い要件の勝ち、最も低い要件の勝ちを含むことができる。一方の形式の環境設定の調停は、セキュリティ手段を適用すべきかどうか決定する。他方の形式は、セキュリティ手段が適用されるときにオプションテンプレートの中で選択を行う。この例に対する1組の計算された計算されたセキュリティ構成は、ComputerSecurityContract.XMLに現われ、これは、次のように部分的に再現される。この1組のセキュリティ構成は、セキュリティポリシー及びセキュリティチャンネルに対する2つの主要セクションを有する。この例では、全メッセージに適用できる1つのセキュリティポリシーと、該セキュリティポリシーの部分を実施するための多数のセキュリティチャンネルがある。セキュリティポリシーセクションは、署名ポリシー、暗号化ポリシー及び暗号キー情報を設定する。又、これは、発信点又は受領の認証、許可及び否認防止に関するポリシーを設定してもよい。この実施形態では、同じ署名及び暗号化ポリシーがドキュメントの全ての部分に適用される。他の実施形態では、異なる部分に多数のアルゴリズムを適用することができる。署名、暗号化及び認証のために選択されるアルゴリズムは、オプションセットを含むテンプレートにより抽象化され、アルゴリズムの選択を簡単にする。選択されるアルゴリズムは、ロジック及びリソースに関連付けられ、従って、メッセージの異なる部分に署名し/照合し及びそれを暗号化し/暗号解読するのに、異なるサービス又はプロセスを使用することができる。セキュリティポリシーセクションの暗号キーエレメントにおいてパブリックキー又は証明書を送信することができる。セキュリティチャンネルセクションは、セキュリティポリシーの適用に含まれるサービス又はコネクタを記述する。特定のポリシーについては、チャンネルセクションは、セキュリティポリシーを適用する際に支援を要求するソースコネクタ例えば、暗号化を要求する送信側サービスと、セキュリティポリシーを適用するか、又はセキュリティポリシーを適用するロジック及びリソースに対して仲介者として働くターゲットコネクタとを識別する。署名、暗号化、認証、許可、又は否認防止のような特定のセキュリティポリシーに対して、そのセキュリティポリシーを実行するのに必要な特定の情報がセキュリティチャンネルセクションにおいて与えられる。セキュリティ構成を決定するのに使用されるデータは、メッセージ及びアクティビティ関連データ、CPサービス関連データ、セキュリティアルゴリズム関連データ、ルーティング関連データ、暗号キー関連データ、及びコンフィギュレーションデータとして分類することができる。これらの分類の使用に関する幾つかの付加的な詳細を以下に説明する。メッセージ及びアクティビティ関連データは、デジタル署名、暗号化、否認防止及び許可に関連したものである。否認防止については、受信者は、受信者への送信者メッセージについての信用ある当事者の確認であるところの送信者に対する否認防止の手段を要求してもよい。同様に、送信者は、受信者による送信者メッセージの受領についての信用ある当事者の確認であるところの受信者に対する否認防止の手段を要求してもよい。以上の説明に加えて、微細な粒度が望まれる場合には、データの特定項目にエレメントベースで署名及び暗号化を適用できることを述べておかねばならない。更に、送信側及び受信側サービスの対にオーバーライドを指定することもできる。例えば、既存の又は立証された関係を、完全に新規な関係とは異なるように処理することができる。セキュリティポリシーへのオーバーライドは、特定のケースにおけるセキュリティ要件を慎重に減少する又は保証されたように増加するように実施できる。CP関連データは、認証及び許可データを含む。許可は、ネットワークリソースへのアクセスを許可又は拒絶するプロセスである。ほとんどのコンピュータセキュリティシステムへのアクセスに対する許可は、2段階プロセスである。その第1段階は、本人ユーザ、プロセス、アプリケーション又はサービスがそれを請求することを保証するための認証である。第2段階は、本人がその認識に基づいて種々のリソースへアクセスするのを許す許可である。許可は、アクセス制御とも称される。アクセス制御は、ウェブサイトリソースへのアクセスを許可するのに使用される。これは、ユーザ、ユーザのグループ、及びユーザに指定される役割に関する情報を管理する。SAMLは、SOAPメッセージにおいてセキュリティ事象認証及び許可及び属性例えばクレジット等級に関する情報を共有するためのXMLベースの手段を与える。このSAMLデータは、次いで、第三者へ送信することができ、これは、分散された信用を可能にし、これにより、ユーザは、一度署名すると、それらの認証又は許可の詳細を再使用することができる。SAML又は同様の信用された当事者のテクノロジーでは、係争当局は、要求者により証拠が与えられると、リソースウェブサービスへのアクセス形式に対して、当該サービス又は送信者による要求を許可すべきかどうか判断する。許可判断は、特定のリソースへの当該アクセスを許可又は拒絶する。SAMLは、ウェブサービスセキュリティに対する有用なオプションであるが、最初にある程度の信用及び技術的リソースを要求する。SAMLが利用できないか又は好ましくないときには、ID/パスワードや、IDに関連した特典のテーブルのような他の解決策を使用することができる。本発明は、使用する許可テクノロジーにより限定されるものではなく、現在利用できる又は今後発明されるテクノロジーの中の選択へと更に抽象的に拡張される。SAML許可又はID/パスワードテクノロジーでは、許可データを暗号化してメッセージへ組み込むことができる。セキュリティアルゴリズムに関連したデータは、署名、暗号化及び否認防止のためのアルゴリズム及びコンフィギュレーションオプションを含む。スキーマが示すように、署名アルゴリズムオプションXML又は非XMLは、XMLDsigの使用、キャノニカライゼーションアルゴリズムの選択、署名メソッド、及びダイジェストアルゴリズムを含んでもよい。暗号化/暗号解読オプションXML又は非XMLは、キーサイズ、キー及びメソッドを含んでもよい。デフォールトは、サービスの環境設定をオーバーライドするか又はオーバーライドされているとしてサービスにより継承されてもよい。更に、上述したように、CP対に対して特定のオーバーライドを指定することができる。又、上述したオプションテンプレートは、セキュリティ構成のネゴシエーションを簡単化する。XML及び非XMLアルゴリズム、例えば、署名アルゴリズムには、異なるオプションが適用される。XML署名アルゴリズム、例えば、XMLDisgは、メソッド、キャノニカライゼーション、変換及びダイジェストのためのオプションをオファーすることができ、一方、非XMLアルゴリズム、例えば、PCKS7は、署名及びダイジェストメソッドのみに対するオプションを有する。各サービスの環境設定リスト間に少なくとも1つの一致があるよう確保するためには、コミュニティの標準セキュリティテンプレートの使用が好ましい。コミュニティは、コミュニティ内でメッセージを交換できるよう確保するために、コミュニティ内で動作する全てのCP又は全てのサービスが特定のコミュニティ標準セキュリティオプションをサポートすることを要求する。ルーティングに関連したデータは、認証/照合、署名/照合及び暗号化/暗号解読を実施するロジック及びリソースにいかにアクセスするかを含む。ユニバーサルリソースネームURN又はユニバーサルリソースロケータURLのようないかなる形式のアクセス情報が使用されてもよい。上述した以前の特許出願に説明されたように、メッセージは、変換又は他の付加価値サービスのためのコネクタを経て多数のホップをとることができる。従って、いかなるアクションにも多数のルートステップが関連付けられる。セキュリティは、通常、変換又は他の付加価値サービスの後に再適用されることが必要となる。暗号化キーに関連したデータは、一般的に、上述した。コンフィギュレーションデータは、デフォールトの例えばコミュニティ又はコラボレーションパートナー環境設定と、信用証明の環境設定とを含む。図4は、送信者が、セキュリティ構成の計算に対してローカルであるときに、受信者の情報を得るための別の実施形態を示す。図中、ローカルレジストリー431及びリモートレジストリー432が示されている。この例では、送信者がローカルであり、そして受信者がリモートである。送信者のデータは、ローカルレジストリー431に現存しそして完全である。送信者の情報は、収集され421、そしてセキュリティ構成411を計算するロジック及びリソースに利用できるようにされる。受信者のデータは、例えば、受信者が送信者と同じコミュニティにいてコミュニティ規模のレジストリーが存在するか、或いは受信者の情報が最近得られてローカルキャッシュされた場合に、現存しそして完全である。受信者の情報がどこで見つかるか431又は432に基づいて、プロセス422又は423が呼び出されて、受信者の情報を収集し、そしてセキュリティ構成を計算するロジックに利用できるようにされる。1組のセキュリティ構成401が得られる。図5は、本発明の態様を実施するのに使用できるプログラムロジック及びリソースの1つのネットワークを示す。このネットワークのロジックコンポーネントは、送信側収集551と、受信側収集552と、データオブジェクトマネージャー541と、ルーティングマネージャー542と、信用証明ネゴシエーター531と、テンプレートネゴシエーター532と、コネクタマネージャー533と、認証マネージャー521と、ポリシーマネージャー522と、パブリックキーマネージャー523と、アルゴリズムマネージャー524と、ポリシービルダー511と、チャンネルビルダー512と、セキュリティ構成ドキュメントビルダー501とを備えている。コラボレーションパートナーのコミュニティにおいて動作してセキュリティ構成を発生するプログラムロジックの一実施形態を以下に説明する。送信者CPを認証するための属性アサーションを含む受信者セキュリティ情報を収集する。送信者セキュリティ情報を収集する。ルーティングブロックを見て、セキュリティ手段を実施するための全てのコネクタ情報を見出す。各コネクタに対して能力パラメータを得る。ルーティングチェーンを通って進み、認証、署名及び暗号化のためにどのコネクタ対を使用するか見出す。受信者のサービスアクティビティメッセージオブジェクトを得る。これは、受信者からSAMsgSecurityPolicyオブジェクトを得ることを含んでもよい。これは、多数の部分を有し、そして全メッセージに対して署名及び暗号化ポリシーを有することができる。又、これも、送信者からSAMsgSecurityPolicyオブジェクトを得ることを含んでもよく、そしてSAMsgSecurityPolicyオブジェクトにオーバーライドオプションを適宜に一致させる。オーバーライド判断テーブルは、以下に説明する。SAMsgSecurityPolicyオブジェクトから、このメッセージに必要な全てのアルゴリズムを見出し、そしてRequiredAlgorithmListを構築する。SendInfo及びReceiveInfoの両方に対してコミュニティ環境設定オブジェクトを得る。これは、送信者のCommunitySecurityTemplatesPreferenceオブジェクトを得ることを含んでもよく、これは、セキュリティアルゴリズムテンプレート及びコミュニティセキュリティポリシー環境設定を含む。又、これは、同じコミュニティでない場合に、受信者のCommunitySecurityTemplatesPreferenceオブジェクトを得ることを含んでもよい。それらが同じコミュニティにいる場合には、オブジェクトポインタをセットすれば充分である。送信者及び受信者の両サービスに対するCPサービスオブジェクトを得、そして対応するコミュニティに対するCPオブジェクトを得る。これは、送信者及び受信者のCPSecurityPolicyPreferenceを構築することを含んでもよい。送信者及び受信者の環境設定と、RequiredAlgorithmListの判断ルールとに基づいて、環境設定リストから選択を行うと共に、RequiredTemplateObjectListを構築する。サービスの各環境設定リストがアルゴリズムにおいて一致しない場合には、コミュニティのデフォールトが一致を発生してもよい。受信者サービスに対してServiceAuthenticationオブジェクトを得る。これは、受け容れられた信用証明及び認証モードを含む1つ以上の指定の認証メソッドを有する。ServiceAuthenticationオブジェクトからの信用証明と、送信者のCPSecurityPolicePreferenceから得られる信用証明とを一致させる。2つ以上の一致がある場合には、受信者のCPSecurityPolicePreferenceから、又は受信者に対応するCommunitySecurityTemplatesPreferenceから、CredentialPreferenceに一致するものを得る。受信者のCPSecurityPolicePreference、又は受信者のCommunitySecurityTemplatesPreferenceオブジェクトのいずれかから、SignMessageHeader及びEncryptCredentialの値を得る。いずれの場所でも値が指定されない場合には、それを偽又は真のようなデフォールトにセットする。受信者により選択された利用可能な送信者の信用証明、受信者に対するServiceAuthenticationオブジェクトに指定された認証モード、SignMessageHeaderブール属性、及びEncryptCredentialを使用して、認証アルゴリズムを構築する。コネクタのPublicKeyCapabilityに基づいて、適切なキーを得る。これは、暗号化が要求される場合には、送信者の暗号キーを得ることを含み、そして署名が要求される場合には、受信者の署名キーIDを得ることを含む。X509認証が要求される場合には、受信者の認証キーIDを得る。セキュリティ構成のポリシーセクションを構築する。チャンネルセクションに対するコネクタを見つけ、そしてセキュリティ構成のチャンネルセクションを構築する。判断テーブルを使用して、メッセージの一部分に署名すべきか又は暗号化すべきかに関連した環境設定の形式の調停を実施してもよい。この場合も、署名すべきでない環境設定を受け容れたり受信者の環境設定又は単なる反対を受け容れたりするように判断を偏らせることもできる。考えられる判断ルールを実施するのに使用できる判断テーブルを以下に示す。本発明は、送信者と受信者との間の経路に沿って中間コネクタにおいて署名及び暗号化をサポートするように容易に拡張される。これは、メッセージの発信者でも最終的な受信者でもないルーティング経路に沿ったコネクタにおいてドキュメントに署名し及びドキュメントを暗号化することができる上で有用である。これは、ゲートウェイ、ルーター及び中央コネクタにとって有用である。ゲートウェイについては、署名され/暗号化されたメッセージデータが1つのエンベローププロトコルから別のものへ変換される場合に、署名及び暗号化をゲートウェイにより実行することが必要になり得る。ルーター及び中央コネクタについては、外部コミュニティに対し企業への単一の入口/出口ポイントを使用するのが望ましい。ルーター又は中央コネクタは、中央のセキュリティハブとして働くと共に、企業全体に代わってセキュリティオペレーションを遂行又は編成することができる。これは、PKIマネージメント及びその他の管理負担を簡単化できる。この機能は、コミュニティの企業部分においてコネクタのセキュリティ能力を設定することにより構成できる。コネクタは、署名能力又は暗号化能力をもつようにエンベロープ/トランスポートプロトコルベースで構成できると共に、他のコネクタにおけるコラボレーションパートナーの署名及び暗号化能力にリンクすることができる。ゲートウェイ及びルーターの場合には、CP自身のキー又はゲートウェイ/ルーターコネクタを使用するようにコネクタを構成することができる。以上の説明から、当業者であれば、本発明の態様及び要素から広範囲なシステム及び方法を構成できることが明らかであろう。一実施形態は、送信側サービスと受信側サービスとの間で1つ以上のメッセージを交換するためのセキュリティオプションを動的に決定する方法である。この方法は、送信者及び受信者のセキュリティの環境設定を使用し、これは、第1及び第2のサービスに対してマシンセキュリティプロファイルの形態をとり得る。セキュリティプロファイルは、各サービスに受け容れられるセキュリティオプション/エレメント及びオプションサブセットを識別することができる。オプションは、メッセージの1つ以上の部分に署名し又は暗号化するための要件、1つ以上の署名アルゴリズムに対応する署名オプションサブセット、1つ以上の暗号化アルゴリズムに対応する暗号化オプションサブセット、署名及び暗号キーの識別、並びに認証アルゴリズムの識別を含んでもよい。動的な方法は、セキュリティプロファイルにアクセスし、そして各サービスに受け容れられる特定オプションセットを選択することを含む。任意であるが、このオプションセットは、各サービスとサービスとの間にメッセージを通信するのに使用できる。本発明の多数のオプション及び態様をこの実施形態に付加することができる。セキュリティプロファイルは、第1及び第2サービスのセキュリティロジックにアクセスできる1つ以上のレジストリーに維持することができる。デフォールトオプションサブセット及び/又は環境設定は、コミュニティ又はコラボレーションパートナーセキュリティプロファイルにおいて指定することができると共に、サービスセキュリティプロファイルへコピーされてもよい。署名又は暗号化の要件は、メッセージの部分又はメッセージ全体に適用することもできる。署名及び暗号化アルゴリズムは、メッセージ全体に適用して複雑さを減少することもできる。署名及び暗号キーは、対称的でも、非対称的でもよい。認証は、信用されたエージェント、例えば、SAMLサーバーにより、各サービスとサービスとの間にメッセージを通信する前に、実行されてもよい。信用されたエージェントによる認証は、認証アサーションにより証拠とされてもよい。或いは又、認証は、受信側サービスにより検査するための信用証明を提示することを含んでもよい。これらの信用証明は、メッセージの一部分でもよいし、又はメッセージに加えて送信されてもよい。認証に加えて、許可は、セキュリティ構成により対処されてもよい。セキュリティプロファイルは、送信側サービスの特典を確立するために少なくとも1つの許可アルゴリズムの識別を含んでもよい。この許可は、メッセージを通信する前に信用されたエージェントにより実施されてもよいし、或いはメッセージを受信するサービスに信用証明を提示することにより実施されてもよい。本発明の更に別の態様は、署名及び/又は暗号化のためのオプションサブセットの中で各サービスの環境設定を考慮に入れる。一方又は両方のサービスの環境設定が考慮されてもよい。受信者が勝ち、送信者が勝ち、最もセキュアなものが勝ち、最もセキュアでないものが勝ち、又は両サービスの環境設定の重み付けファクタを含む上述したいずれの判断ルールが適用されてもよい。セキュリティ構成の決定は、署名、暗号化、認証、許可又は否認防止の任意の組合せを実施するように各当事者により使用されるべきリソースを決定することを含んでもよい。リソース、アルゴリズム及びオプションは、セキュリティチャンネルへパッケージされてもよい。セキュリティチャンネルは、単一のセキュリティ態様を実施してもよい。以上、好ましい実施形態及び実施例を参照して本発明を説明したが、これらは、本発明を例示するものであって、限定するものではないことを理解されたい。前記実施形態では、コンピュータ支援処理が示唆される。従って、本発明は、コンピュータ支援の処理方法、この方法を実施するためのロジックを含むシステム、この方法を実施するためのロジックが銘記された媒体、この方法を実施するためのロジックが銘記されたデータストリーム、或いはコンピュータアクセス可能な処理サービスにおいて実施することができる。当業者であれば、本発明の精神及び範囲内で種々の変更や組合せがなされ得ることが理解されよう。