JP4775980B2 - ウェブ・サービスにおける秘密データ通信 - Google Patents

Description

本発明の分野はデータ処理であり、或いは、特にウェブ・サービスにおける秘密データ通信のための方法、システム、及び製品である。

“ウェブ・サービス”という用語は、ウェブ・ベースのアプリケーションを統合する標準化された方法を指す。ウェブ・サービスは、通例、バインディングと呼ばれる標準化されたフォーマットでのデータ通信を通してリクエストに応じてビジネス・サービスを提供する。バインディングは、データ符号化方法とデータ通信プロトコルとの仕様である。ウェブ・サービスに用いられる最も普通のバインディングは、ＳＯＡＰプロトコルに従うＸＭＬでのデータ符号化とＨＴＴＰでのデータ通信とである。ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（シンプル・オブジェクト・アクセス・プロトコル））は、ＸＭＬ及び拡張を用いて構造化されたタイプト・データの通過をサポートするリクエスト／レスポンス・メッセージ送信プロトコルである。

ブラウザ・クライアントからのリクエストに応答してＨＴＭＬ文書を提供するＨＴＴＰサーバのような在来のクライアント／サーバ・モデルとは異なって、ウェブ・サービスは表示とは関係が無い。その代わりに、ウェブ・サービスは、ネットワークを介してプログラムに従ったインターフェース（ａ ｐｒｏｇｒａｍｍａｔｉｃ ｉｎｔｅｒｆａｃｅ）を通してビジネス・ロジック、データ、及びプロセスを共有する。ウェブ・サービス・アプリケーションはユーザとではなくて相互にインターフェースする。ウェブ・サービス間の全てのデータ通信は標準化されたバインディングに従って行われるので、ウェブ・サービスは１つのオペレーティング・システム或いはプログラミング言語に縛られない。ウィンドウズ（登録商標）プラットフォームで動作するジャバ・クライアントは、パールで書かれてユニックスの下で動作するウェブ・サービス・オペレーションを呼び出すことができる。Ｃ＋＋で書かれたウィンドウズ（登録商標）・アプリケーションは、ジャバ・サーブレットとして実現されたウェブ・サービスにおいてオペレーションを呼び出すことができる。

ウェブ・サービス・プロトコルは、通例、クライアント又は仲介リクエスタが特定のサービスを要求するリクエスト・メッセージをウェブ・サービスに送り、ウェブ・サービスがレスポンス・メッセージの形のレスポンスを提供するようになっているリクエスト／レスポンス・プロトコルである。或るメッセージ交換パターンでは、交換のイニシエータにとっては、自分が受け取ったメッセージが実際に自分が開始したリクエストに対するレスポンスであることを確かめることが望ましい。その様な確認は、関連するレスポンスを促したリクエストの内容に関してリクエスタとウェブ・サービスとの間で合意を確立するのに役立つ。この確認は、ある形の攻撃からの危険を減少させるのに役立つ。しかし、現在の技術は、リクエスタが受け取ったメッセージが実際にリクエスタが開始したリクエストに対するレスポンスであることをリクエスタが確かめる方法を提供していない。

該して、値を有する第１署名を帯びているエレメントを含むリクエストをクライアントからウェブ・サービスで受け取り、その第１署名の値を署名し、これにより第２署名を作成し、そのウェブ・サービスから第２署名を含むレスポンスをクライアントに送ることによってウェブ・サービスにおける秘密データ通信が提供されるようになっている方法、システム、及び製品が開示される。リクエスタは、レスポンスが第２署名を含むことを確かめることができる。リクエストは暗号化され得、レスポンスは暗号化され得る。第１署名は暗号化され得、ウェブ・サービスは、第１署名の値を暗号化して、第１署名のその暗号化された値をレスポンスに含めることができる。ウェブ・サービスは、ＳＯＡＰで符号化されたリクエストを受け取り、ＳＯＡＰで符号化されたレスポンスを送ることができる。

値を有する署名確認エレメントを作成し、その署名確認エレメントの値を第１署名の値にセットし、署名確認エレメントを署名し、これにより第２署名を作成し、署名確認エレメントと第２署名とをレスポンスに含めることによって、第１署名の値の署名を行うことができる。値を各々有する第１署名を帯びた複数のエレメントを含むリクエストをウェブ・サービスが受け取ったとき、或る実施態様ではウェブ・サービスは第１署名の値の全てを署名し、これにより複数の第２署名を作ることができ、ウェブ・サービスはそれらの複数の第２署名を含むレスポンスをリクエスタに送ることができる。

本発明の上記の及び他の目的、特徴及び利点は、同様の参照番号が本発明の同様の部分を表している添付図面に示されている本発明の代表的実施態様についての以下のより詳しい記述から明らかとなろう。

本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための代表的なシステムを示すネットワーク図を示す。 図２Ａは、本発明の実施態様に従って秘密データ通信が実行され得るウェブ・サービスのための代表的アーキテクチャの線図を示す。図２Ｂは、本発明の実施態様に従って秘密データ通信が実行され得るウェブ・サービスのための代表的アーキテクチャの線図を示す。 本発明の実施態様に従うウェブ・サービスにおける秘密データ通信に役立つ代表的コンピュータを含む自動化された計算機のブロック図を示す。 本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための代表的方法を示すフローチャートを示す。 本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための更なる代表的方法を示すフローチャートを示す。 本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための更なる代表的方法を示すフローチャートを示す。 本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための更なる代表的方法を示すフローチャートを示す。

本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための代表的な方法、システム及び製品が、添付図面を先ず図１から参照して、記載される。図１は、本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための代表的システムを示すネットワーク図を示す。“ネットワーク”という用語は、本明細書においては、２つ以上のコンピュータ間でのデータ通信のための任意のネットワーク化された結合を意味するために使用される。ネットワーク・データ通信は、通例、ルータと呼ばれる専用コンピュータで実行される。ネットワークは、通例、１つのコンピュータから他のコンピュータへ経路指定されるメッセージにコンピュータ・データを納めることによりデータ通信を実行する。ネットワークの良く知られている例は“インターネット”、すなわち、ＩＥＴＦのＲＦＣ７９１に記載されている“インターネット・プロトコル”に従って相互に通信するコンピュータの相互に接続されたシステムである。本発明の種々の実施態様で役に立つネットワークの他の例は、イントラネット、エクストラネット、ローカル・エリア・ネットワーク（“ＬＡＮ”）、ワイド・エリア・ネットワーク（“ＷＡＮ”）、及びその他の、当業者が考え付くネットワーク設備を含む。リクエスタから、ウェブ・サービスをサポートするウェブ・サーバへの任意のネットワーク化された結合の使用が完全に本発明の範囲内にある。

図１のシステムはデータ通信ネットワーク（１００）を含む。ネットワーク（１００）は、リクエスタ（１０８，１１２，１０２，１１０，１２６）とウェブ・サービス（１０６，１２８）との間のデータ通信を提供する。ウェブ・サービス・サーバ（１０６）はコンピュータであって、データ通信のためにワイヤライン接続（１３２）を通してネットワーク（１００）に結合されており、これにウェブ・サービス（３０３）がインストールされて動作する。ウェブ・サービス（３０３）の機能を実行するためのコンピュータ・プログラム命令は、ウェブ・サービス・サーバ（１０６）のコンピュータ・メモリに格納されている。クライアント・デバイス（‘リクエスタ’）は、サービスを求めるリクエストをサーバ（１０６）に送信する。ウェブ・サービス（３０３）は、ネットワーク（１００）を介してリクエストを受け取り、リクエストを処理し、ネットワーク（１００）を介してレスポンスを送信する。図１のシステムは、ウェブ・サービスを求めるリクエストをウェブ・サービス（３０３）に送信してレスポンスを受信することのできる数個のリクエスタを含む。図１のシステムにおけるリクエスタは、
ワイヤライン接続（１２２）を通してネットワーク（１００）に結合されているコンピュータであるワークステーション（１０２）と、
ワイヤライン接続（１２０）を通してネットワーク（１００）に結合されているパーソナル・コンピュータ（１０８）と、
無線接続（１１４）を通してネットワーク（１００）に結合されているパーソナル・デジタル・アシスタント（１１２）と、
無線接続（１１８）を通してネットワーク（１００）に結合されているラップトップ・コンピュータ（１２６）と、
無線接続（１１６）を通してネットワーク（１００）に結合されている移動電話機（１１０）と、
を含む。

‘リクエスタ’という用語は、任意のデータ通信クライアント・デバイスを、すなわち、データ通信のためにウェブ・サービスに結合し、リクエストをウェブ・サービスに送信し、ウェブ・サービスからレスポンスを受信することのできる任意のデバイスを指す。リクエスタの例は、パーソナル・コンピュータ、インターネット対応（ｉｎｔｅｒｎｅｔ−ｅｎａｂｌｅｄ）特別目的デバイス、インターネット可能な（ｉｎｔｅｒｎｅｔ−ｃａｐａｂｌｅ）パーソナル・データ・アドミニストレータ、及び他の、当業者が思いつくものである。リクエスタの種々の具体例は、ウェブ・サービスと有線又は無線で、或いはその両方で、結合することができる。ネットワークを通してウェブ・サービスにアクセスすることのできる任意のクライアント・デバイス又は機器のリクエスタとしての使用が充分に本発明の範囲内にある。

図１は、ワイヤライン接続（１３０）を通してネットワーク（１００）に結合されたウェブ・サービス仲介（１２８）も含んでいる。ウェブ・サービス仲介（１２８）は、ウェブ・サービス（３０１）をインストールして、それに対して作用することができる。ウェブ・サービス（３０１）は、仲介ウェブ・サービスを提供する。ウェブ・サービス仲介は、ウェブ・サービス・リクエスタとウェブ・サービスとの間にあるウェブ・サービス・コンポーネント（この例では、サーバ）である。仲介は、一般に、クライアントからのリクエストを傍受し、仲介サービスを提供し、その後にそのクライアント・リクエストをウェブ・サービス・プロバイダ（時には‘ターゲット・サービス’と称される）に転送することによって動作する。同様に、ウェブ・サービス・プロバイダ（ターゲット・サービス）からのレスポンスは傍受され、操作され、その後に元のリクエスタに戻される。

仲介により提供されるサービスは、例えば、ターゲット・サービスについてのリクエストのソースの認証、コンテンツ及び形式についてのメッセージ確認、監査目的のためのメッセージ・ロギングを含む。仲介は、サービス、ウェブ・サービス・ヒットの数、個々のクライアントにより使用されたサービスの量及びタイミングなどを報告するマネージメントを提供することができる。仲介は、例えば新聞記事などのような頻繁に変化するけれども頻繁に要求されるデータを格納することによって、改善された性能をサポートするキャッシュとして使用され得る。仲介は、ロード・バランシング、すなわち数個のクライアントからのサービスを求めるリクエストを格納してそれらをピーク時でない実働時間中にターゲット・サービスに転送する、という意味での性能改善のために使用され得る。仲介は、例えば、後に支払勘定、受取勘定、及び一般元帳サービスのための別々のターゲット・サービスに転送される会計転記を求めるリクエストを受け取る会計仲介としてサービスを集めることができる。

図１のシステムは、一般的に、値を有する第１署名を帯びたエレメントを含むリクエストをリクエスタから例えばウェブ・サービス（３０３）などのウェブ・サービスにおいて受け取ることによって本発明の実施態様に従ってウェブ・サービスにおいて秘密データ通信を提供するように働く。ウェブ・サービスは、第１署名の値を署名し、これにより第２署名を作成し、そしてその第２署名を含むレスポンスをウェブ・サービス（３０３）からリクエスタに送る。以下でより詳しく説明されるように、第２署名（第１署名の１つの署名）を帯びたレスポンスを送ることは、リクエスタに対してウェブ・サービスのアイデンティティを認証し、そのレスポンスがリクエスタから受け取られたまさにそのリクエストに対するレスポンスであるとメッセージ完全性を証明する。

図１に示されている代表的システムを構成するクライアント・デバイス、サーバ、ネットワーク、及び他のデバイスの構成は、限定ではなくて説明を目的とするものである。本発明の種々の実施態様に従うウェブ・サービスにおける秘密データ通信に役立つデータ処理システムは、当業者が思い浮かべるであろうように、付加的な、図１に示されていないサーバ、ルータ、他のデバイス、及びピア・ツー・ピア・アーキテクチャを含むことができる。この様なデータ処理システムにおけるネットワークは、当業者が思い浮かべるであろうように、例えばＴＣＰ／ＩＰ、ＨＴＴＰ、ＷＡＰ、ＨＤＴＰ、及びその他を含む多くのデータ通信プロトコルをサポートすることができる。本発明の種々の実施態様は、図１に示されているものに加えて多様なハードウェア・プラットフォーム及びネットワーク構成で実現され得る。

更なる説明のために、図２Ａは、ウェブ・サービスにおける秘密データ通信が本発明の実施態様に従って実行され得るウェブ・サービス用の代表的コンピュータ・アーキテクチャの線図を示している。図２Ａのアーキテクチャにおいて、ウェブ・サービス仲介（３０１）はデータ通信のためにデータ通信プロトコルを通してリクエスタ（１０２）及びターゲット・ウェブ・サービス（３０３）に結合されている。ウェブ・サービス仲介（３０１）とターゲット・ウェブ・サービス（３０３）とは、両方とも、ウェブ・サービスをサポートするサーバにインストールされている。リクエスタ（１０２）の位置にあるウェブ・サービス・コンポーネントは一般的に本明細書においては‘リクエスタ’と称される。同様に、仲介（３０１）の位置にあるコンポーネントは、特にリクエスタの視点から見られたときには、‘ウェブ・サービス’と称され得る。

クライアント／サーバの区別と、‘リクエスタ’という名称とは、ウェブ・サービスとの関係においては慎重に用いられなければならない。特定のコンポーネントがリクエスタであるのか、クライアントであるのか、サーバであるのか、それともサービスであるのかは、通信プロトコルでのリクエスト／レスポンス・メッセージの交換におけるそのコンポーネントの役割による。更なる説明のために、図２Ａは、ウェブ・サービスにおける秘密データ通信が本発明の実施態様に従って実行され得るウェブ・サービス用の代表的コンピュータ・アーキテクチャの線図を示している。図２Ｂのアーキテクチャでは、例えば、ターゲット・サービス（３０３）は、リクエスタ（１０２）からのリクエストに対するレスポンスを準備するとき、ウェブ・サービス仲介（２０２）を通してターゲット・ウェブ・サービス（２０４）からウェブ・サービスを要求することができる。その様にするとき、ターゲット・ウェブ・サービス（３０３）はクライアントとして、且つリクエスタとして動作している。仲介（２０２）は、リクエストをターゲット・サービス（２０４）に転送するときクライアントとして且つリクエスタとして動作しているのであり、仲介（２０２）は、ターゲット・サービス（３０３）からリクエストを受け取ってターゲット・サービス（３０３）へのレスポンスを準備して送るときウェブ・サービスとして動作しているのである。同様に、仲介（３０１）は、リクエストをターゲット・サービス（３０３）に転送するときにはクライアントとして且つリクエスタとして動作しているのであり、仲介（３０１）は、リクエスタ（１０２）からリクエストを受け取ってリクエスタ（１０２）へのレスポンスを準備して送るときにはウェブ・サービスとして動作しているのである。従って、特定のウェブ・サービス・コンポーネントが特定の時点でクライアントと考えられるか、それともサーバと考えられるか、また、リクエスタと考えられるか、それともサービスと考えられるかは、その時点でそのコンポーネントにより実行されている機能による。ウェブ・サービス・コンポーネントは或る時点でクライアント又はリクエスタであり得、また次の時点ではサーバ又はウェブ・サービスであり得る。従って、用語からの混乱の危険を減少させるために、本明細書ではウェブ・サービス・コンポーネントは、普通、‘クライアント’又は‘サーバ’ではなくて‘リクエスタ’、‘仲介’、及び‘ウェブ・サービス’という用語を用いることによって記述される。

本発明に従うウェブ・サービスにおける秘密データ通信は、一般にコンピュータで、すなわち自動化された計算機で実行される。例えば、図１のシステムでは、全てのノード、サーバ、及び通信装置はある程度は少なくともコンピュータとして実現される。従って、更なる説明のために、図３は、本発明の実施態様に従うウェブ・サービスにおける秘密データ通信に役立つ代表的コンピュータ（１５２）を含む自動化計算機のブロック図を示している。図３のコンピュータ（１５２）は、少なくとも１つのコンピュータ・プロセッサ（１５６）又は‘ＣＰＵ’と、システム・バス（１６０）を通してプロセッサ（１５６）及びコンピュータの他のコンポーネントに接続されているランダム・アクセス・メモリ（１６８）（“ＲＡＭ”）とを含む。

ＲＡＭ（１６８）にはウェブ・サービス（３０３）、すなわち、本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のために改良されたコンピュータ・プログラム命令のセットが格納されている。ＲＡＭ（１６８）には、サービスを求めるリクエスト（３０４）も格納されている。このリクエストは、値（３０８）を有する第１署名（３０６）を帯びたエレメント（３１０）を含む。ＲＡＭ（１６８）には、リクエストに対するレスポンス（３２６）も格納されている。このレスポンスは第２署名（３２０）（第１署名の１つの署名）を帯びている。レスポンスは第１署名の値（３０８）も帯びている。ウェブ・サービス（３０３）のコンピュータ・プログラム命令は、値を有する第１署名（３０６）を帯びたエレメントを含むリクエスト（３０４）をリクエスタ（１８２）からウェブ・サービス（３０３）で受け取り、その第１署名の値を署名し、これにより第２署名（３２０）を作成し、第２署名（３２０）を含むレスポンスをウェブ・サービス（３０３）からリクエスタ（１８２）に送るための命令を含む。第２署名（第１署名の１つの署名）を帯びたレスポンスを送ることは、リクエスタに対してウェブ・サービスのアイデンティティを認証し、メッセージ完全性を証明する、すなわち、そのレスポンスがリクエスタから受け取られたまさにそのリクエストに対するレスポンスであると証明するという有益な効果を有する。

ＲＡＭ（１６８）にはオペレーティング・システム（１５４）も格納されている。本発明の実施態様に従うコンピュータにおいて役に立つオペレーティング・システムはユニックス、リナックス、マイクロソフトＮＴ、ＡＩＸ、ＩＢＭのｉ５／ＯＳ、及びその他の、当業者が思い浮かべるであろうものを含む（ユニックスは米国及び他の国におけるザ・オープン・グループ（Ｔｈｅ
Ｏｐｅｎ Ｇｒｏｕｐ）の登録商標であり、リナックスは米国、他の国、或いはその両方におけるリーナス・トーバルズの登録商標であり、マイクロソフト、ウィンドウズ（登録商標）、ウィンドウズ（登録商標）ＮＴ、及びウィンドウズ（登録商標）・ロゴは米国、他の国、或いは両方におけるマイクロソフト社の商標であり、ＡＩＸ、ＩＢＭ及びｉ５／ＯＳはインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である）。図３の例におけるオペレーティング・システム（１５４）、ウェブ・サービス（３０３）、リクエスト（３０４）、及びレスポンス（３１０）はＲＡＭ（１６８）の中に示されているが、これらのソフトウェアの多くのコンポーネントは通例不揮発性メモリ（１６６）にも格納される。

図３のコンピュータ（１５２）は、システム・バス（１６０）を通してプロセッサ（１５６）とコンピュータ（１５２）の他のコンポーネントとに結合された不揮発性コンピュータ・メモリ（１６６）を含む。不揮発性コンピュータ・メモリ（１６６）は、ハード・ディスク・ドライブ（１７０）、光ディスク・ドライブ（１７２）、電気的に消去可能でプログラマブルな読み出し専用メモリ・スペース（いわゆる‘ＥＥＰＲＯＭ’又は‘フラッシュ’メモリ）（１７４）、ＲＡＭドライブ（図示されていない）、或いは当業者が思い浮かべる他の任意の種類のコンピュータ・メモリとして実現され得る。

図３のコンピュータ例は１つ以上の入出力インターフェース・アダプタ（１７８）を含む。コンピュータにおける入出力インターフェース・アダプタは、コンピュータ表示スクリーンのような表示装置（１８０）への出力と、キーボード及びマウスのようなユーザ入力装置（１８１）からのユーザ入力とを制御するために例えばソフトウェア・ドライバ及びコンピュータ・ハードウェアなどを通してユーザ指向の入出力を実行する。

図３の代表的コンピュータ（１５２）は、クライアント、リクエスタ（１８２）、ウェブ・サービス仲介、他のウェブ・サービス、及び他のコンピュータとのデータ通信接続（１８４）を実現するための通信アダプタ（１６７）を含む。この様なデータ通信は、ＲＳ−２３２接続を通してシリアルに、ＵＳＢのような外部バスを通して、ＩＰネットワークのようなデータ通信ネットワークを通して、また当業者が思い浮かべるであろう他の方法で、実行され得る。通信アダプタはハードウェア・レベルのデータ通信を実行し、それを通してコンピュータは直接に又はネットワークを通してデータ情報を他のコンピュータに送る。本発明の実施態様に従って宛先の可用性を判定するのに役立つ通信アダプタの例は、有線ダイアルアップ通信用モデム、有線ネットワーク通信用イーサネット（登録商標）（ＩＥＥＥ８０２．３）アダプタ、及び無線ネットワーク通信用８０２．１１ｂアダプタを含む。

更なる説明のために、図４は、リクエスタ（１０２）からリクエスト（３０４）をウェブ・サービス（３０３）で受け取ること（３０２）を含む本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための代表的方法を示すフローチャートを示している。図４の例では、リクエスト（３０４）は、第１署名３０６を帯びたエレメント（３１０）を含む。第１署名（３０６）は値（３０８）を有する。リクエスト（３０４）は例えばＳＯＡＰなどのウェブ・サービス・リクエスト／レスポンス・プロトコルに従うメッセージであり得る。エレメント（３１０）はメッセージ構造のインスタンスである。ＳＯＡＰメッセージはＸＭＬで表現されるので、ＳＯＡＰの例では、エレメント（３１０）はＸＭＬエレメントとして、すなわち、ＸＭＬタグで実現されたメッセージ構造として、実現され得る。

第１署名（３０６）は、例えば、エレメント（３１０）をハッシュしてパブリック・キー・インフラストラクチャからのリクエスタの秘密キーでハッシュを暗号化することによってエレメント（３１０）のためのデジタル署名として実現され得る。エレメントからデジタル署名を作成するこのプロセスは‘署名（ｓｉｇｎｉｎｇ）’と称される。第１署名（３０６）は、暗号化されたハッシュをリクエストに含めることによってリクエスト（３０４）に組み込まれ得る。ＳＯＡＰメッセージの例では、署名は、ＳＯＡＰ署名エレメントを作成し（その値は、暗号化されたハッシュのそれである）、そのＳＯＡＰ署名エレメントをリクエスト（３０４）に含めることによって、リクエスト（３０４）に組み込まれ得る。

図４の方法は、第１署名（３０６）の値（３０８）を署名し（３０９）、これにより第２署名（３２０）を作成することを含む。ウェブ・サービスは、リクエスト（３０４）に対するレスポンス（３２６）を生成（３２４）する。リクエスト（３０４）の場合と同じく、レスポンスはウェブ・サービス・リクエスト／レスポンス・プロトコルに従うメッセージである。レスポンス（３２６）は第２署名（３２０）を含む。第１署名（３０６）と同様に、第２署名（３２０）は、第１署名の値（３０８）をハッシュしてパブリック・キー・インフラストラクチャからのウェブ・サービスの秘密キーでハッシュを暗号化することによって実現され得る。第２署名（３２０）は、暗号化されたハッシュをレスポンス（３２６）に含めることによってレスポンス（３２６）に組み込まれ得る。ＳＯＡＰメッセージの例では、署名は、ＳＯＡＰ署名エレメントを作成し（その値は、暗号化されたハッシュのそれである）、そのＳＯＡＰ署名エレメントをレスポンス（３２６）に含めることによって、レスポンス（３２６）に組み込まれ得る。レスポンス（３２６）は第１署名（３０６）の値（３０８）も含み得る。図４の方法は、第２署名を含むレスポンス（３２６）をウェブ・サービス（３０３）からリクエスタ（１０２）に送ること（３３８）も含む。

図４の方法では、リクエスタ（１０２）は、レスポンス（３２６）が第２署名（３２０）を含むことと、第２署名が第１署名（３０６）の値（３０８）の１つの署名であることとを確認（３４２）する。ＳＯＡＰリクエストの場合、例えば、署名はＳＯＡＰ署名エレメントとして実現され得る。リクエスタ（１０２）は、ＳＯＡＰ署名エレメントについてメッセージを調べることによってリクエストが署名を含むことを確認することができる。

リクエスタ（１０２）は、例えば、第２署名を解読して第１署名のハッシュと称されるものを生じさせることによって、第２署名が第１署名の１つの署名であることを確認することができる。リクエスタは、そのようにして作られたハッシュを、第１署名の記憶されているコピーからそのときに計算された第１署名のハッシュと比較することができる。代わりに、リクエスタ（１０２）は、リクエスタが第１署名を作成したときに第１署名のハッシュを格納し、第１署名のハッシュの格納されているコピーを用いてレスポンス・メッセージからのハッシュと称されるものと比較することができる。第２署名が第１署名（３０６）の値（３０８）の１つの署名であるという事実は、その２つのハッシュが等しければ、確認される（３４２）。その２つのハッシュが等しいということは、第２署名の解読が正しいことも立証する。ウェブ・サービスのパブリック・キーでの第２署名のリクエスタによる解読は、第２署名がウェブ・サービスの秘密キーを用いることによりウェブ・サービスによって暗号化され得たに過ぎないから、ウェブ・サービスのアイデンティティを認証する。確認プロセスは、第２署名（３２０）に埋め込まれている第１署名（３０６）の値（３０８）の完全性を、すなわち、第１署名がウェブ・サービスから改変無しで受け取られたことを、リクエスタ（１０２）に対して保証する。

図４の例では、リクエスト（３０４）は２つのエレメント（３１０，３１２）を含み、各エレメントは第１署名（３０６，３１４）を帯びている。リクエスト（３０４）内に２つのエレメントが示されていることは、本発明を限定するものではない。２という数はリクエスト（３０４）が第１署名（３０６，３１４）を帯びた複数のエレメント（３１０，３１２）を含み得、各第１署名が値（３０８，３１６）を有することを説明するために使われている。図４の方法は、第１署名の全ての値（３０８，３１６）を署名し（３０９）、これにより複数の第２署名（３２０，３２２）を作成することを更に含む。図４の方法は、レスポンス（３２６）をウェブ・サービス（３０３）からリクエスタ（１０２）に送ること（３３８）を更に含んでおり、そのレスポンス（３２６）は複数の第２署名（３２０，３２２）を含む。第１署名（３０６，３１４）の値（３０８，３１６）もレスポンス（３２６）に含まれ得る。

更なる説明のために、図５は、本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための更なる代表的方法を示すフローチャートを示しており、ここでは受け取られたリクエスト（３０４）は暗号化されていて良い。データを暗号化するプロセスは、データを難解な形に変換するためにデータにアルゴリズムを適用することを含む。代表的な暗号化アルゴリズムは、キーとして知られるている秘密の使用を含むことができる。或るアルゴリズムは、リクエスタとウェブ・サービスとにより共有される１つの秘密キーを使用する。他の或るアルゴリズムは２つのキー、すなわち被密キー及びパブリック・キー、を使用する。広く使用されている暗号化アルゴリズムは３ＤＥＳ（データ暗号化規格）、ＣＡＳＴ−１２８、Ｔｗｏｆｉｓｈ、及びアドバンスト・エンクリプション・スタンダード（Ａｄｖａｎｃｅｄ Ｅｃｎｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ））を含む。

図５の代表的方法は、図４の方法に似ている。すなわち、図５の方法は、値（３０８）を有する第１署名（３０６）を帯びた暗号化されたリクエスト（３０４）を受け取り（３０２）、第１署名（３０６）の値（３０８）を署名し、ウェブ・サービス（３０３）からレスポンス（３２６）を送る（３３８）ことを含み、これらは全て図４の方法と同様の仕方で作用する。しかし、図５の方法は、受け取られたリクエスト（３０４）が暗号化されているか否か判定する（３２１）ことも含む。例えばＳＯＡＰリクエストの場合、メッセージ・セキュリティ・ヘッダはリクエスト又はリクエストのエレメントが暗号化されているか否かを記述する情報を含むことができ、受け取られたリクエストが暗号化されているか否かを判定することは、その様なリクエスト・メッセージ・セキュリティ・ヘッダを調べることによって実行され得る。図５の例では、もしリクエストが暗号化されていれば（３２７）、この方法はウェブ・サービス（３０３）においてレスポンス（３３１）を暗号化すること（３２５）を含む。もしリクエストが暗号化されていなければ（３２９）、ウェブ・サービスはレスポンスを暗号化すること無くレスポンス（３２６）を送る（３３８）。

更なる説明のために、図６は、第１署名が暗号化され得る本発明の実施態様に従うウェブ・サービスにおける秘密データ通信の代表的方法を示すフローチャートを示す。図６の方法は図４の方法に似ている。すなわち、図６の方法は、値（３０８）を有する暗号化された第１署名（３０６）を帯びたリクエスト（３０４）を受け取り（３０２）、第１署名（３０６）の値（３０８）を署名し、レスポンス（３２６）をウェブ・サービス（３０３）から送ること（３３８）を含み、これらは全て図４の方法と同様の仕方で作用する。しかし、図６の方法は、第１署名が暗号化されているか否か判定すること（３５４）も含む。例えば、ＳＯＡＰリクエストの場合、セキュリティ・ヘッダはリクエスト又はリクエストのエレメントが暗号化されているか否かを記述する情報を含むことができ、受け取られたリクエストの第１署名（３０６）が暗号化されているか否かを判定すること（３５４）は、その様なリクエスト・メッセージ・セキュリティ・ヘッダを調べることによって実行され得る。

第１署名（３０６）が暗号化されているとき、レスポンス内の第１署名の値（３０８）を暗号化することは、第１書名を作るために使用されたキーを保護するために役立つことができる。もし第１署名が暗号化されてリクエスト（３０４）で送られて、第１署名（３０６）の値（３０８）がレスポンス（３２６）において暗号化されていなければ、アタッカーが暗号化されている署名の値と暗号化されていない署名の値とを比較して、リクエスト（３０４）中の署名を作るためにリクエスタ（１０２）により使用されたキーに関する情報を入手する或る程度の危険がある。従って、図６の例では、もし第１署名が暗号化されていれば（３５２）、この方法は、ウェブ・サービス（３０３）において第１署名の値（３０８）を暗号化すること（３５０）と、その暗号化された値（３５８）をレスポンス（３２６）に含めることとを含む。もし第１署名の値が暗号化されていなければ（３５６）、ウェブ・サービスは、第１署名の値を暗号化せずにレスポンス（３２６）を送る（３３８）。

更なる説明のために、図７は、ウェブ・サービスのためにＳＯＡＰ／ＨＴＴＰバインディングを使用する本発明の実施態様に従うウェブ・サービスにおける秘密データ通信のための更なる代表的方法を示す。図７の方法は、図４の方法に似ている。すなわち、図７の方法は、値（３０８）を有する第１署名（３０６）を帯びたＳＯＡＰで符号化されているリクエスト（６０４）を受け取り（３０２）、第１署名（３０６）の値（３０８）を署名し（３０９）、ウェブ・サービス（３０３）からレスポンスを送ることを含んでおり、これらは全て図４の方法と同様の仕方で作用する。図７の方法は、ＳＯＡＰで符号化されたリクエスト（６０４）を受け取り（６０２）、署名確認エレメント（４１０）を作成すること（４０８）を更に含み、署名確認エレメントは値（４０６）を有する。署名確認エレメントは、値フィールドを含むＳＯＡＰデータ構造である。ウェブ・サービス（３０３）は、署名確認エレメント（４１０）の値（４０６）を第１署名（３０６）の値（３０８）にセットする（４１６）。図７の方法は、ウェブ・サービス（３０３）が署名確認エレメント（４１０）を署名し（４１２）、これにより第２署名（３２０）を作成することを更に含む。この出願において、第１エレメントを“署名すること”は、その値が第１エレメントである署名確認エレメントを署名することも含む。図７の方法はＳＯＡＰリクエスト（６０４）に対するレスポンス（３２６）を生成することを更に含み、それは署名確認エレメント（４１０）と第２署名（３２０）とを含む。

図７の例では、ＳＯＡＰリクエスト（６０４）は値（３０８）を有する１つの署名を含み、レスポンス（３２６）は１つの署名確認エレメント（４１０）を含んでいた。単一の署名確認エレメントが示されていることは、本発明を限定するものではない。ＳＯＡＰリクエスト（６０４）は、複数の署名を伴う、複数の署名付きエレメントを含むことができる。本発明の種々の実施態様に従うウェブ・サービスにおける秘密データ通信のための或る方法では、ＳＯＡＰレスポンス（３２６）は、元のリクエスト中の各署名について署名確認エレメント（４１０）を含むことができる。各署名確認エレメント（４１０）は、対応する署名の値（４０６）を含む。本発明の種々の実施態様に従うウェブ・サービスにおける秘密データ通信のための或る方法では、ＳＯＡＰレスポンス（３２６）は単一の署名確認エレメント（４１０）を含むことができ、その値（４０６）は元のリクエスト中の署名のうちの１つの署名の値である。

下記は擬似コードＳＯＡＰリクエストの例である：
＜Ｓ１１：Ｅｎｖｅｌｏｐｅ ｘｍｌｎｓ：Ｓ１１＝”．．．”ｘｍｌｎｓ：ｗｓｓｅ＝”．．．”ｘｍｌｎｓ：ｗｓｕ＝”．．．”ｘｍｌｎｓ：ｘｅｎｃ＝”．．．”ｘｍｌｎｓ：ｄｓ＝”．．．”＞
＜Ｓ１１：Ｈｅａｄｅｒ＞
．．．
＜ｗｓｓｅ：Ｓｅｃｕｒｉｔｙ＞
．．．
＜ｄｓ：Ｓｉｇｎａｔｕｒｅ＞
．．．
＜ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞
＜ｄｓ：Ｒｅｆｅｒｅｎｃｅ ＵＲＩ＝”＃ＣｒｅｄｉｔＣａｒｄＩｎｆｏ”＞
＜／ｄｓ：Ｒｅｆｅｒｅｎｃｅ＞
＜／ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞
＜ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
ｋｐＲｙｅｊＹ４ｕｘｗＴ９Ｉ７４ＦＹｖ８ｎＱ＝＝
＜／ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
＜ｄｓ：ＫｅｙＩｎｆｏ＞
．．．
＜ｄｓ：ＫｅｙＩｎｆｏ＞
＜／ｄｓ：Ｓｉｇｎａｔｕｒｅ＞
＜／ｗｓｓｅ：Ｓｅｃｕｒｉｔｙ＞
．．．
＜／Ｓ１１：Ｈｅａｄｅｒ＞
＜Ｓ１１：Ｂｏｄｙ＞
＜ＣｒｅｄｉｔＣａｒｄＩｎｆｏ ｗｓｕ：Ｉｄ＝”ＣｒｅｄｉｔＣａｒｄＩｎｆｏ”＞
＜／ＣｒｅｄｉｔＣａｒｄＩｎｆｏ＞
．．．
＜／Ｓ１１：Ｂｏｄｙ＞
＜／Ｓ１１：Ｅｎｖｅｌｏｐｅ＞

この例は‘擬似コード’として記述されているが、その理由は、それがリクエストの実際の作業モデルではなくてＸＭＬコードの一般的な形で提示された説明であることにある。この例は、ＳＯＡＰ＜ｈｅａｄｅｒ>エレメントとＳＯＡＰ＜ｂｏｄｙ>エレメントとをＳＯＡＰ＜ｅｎｖｅｌｏｐｅ>の中に包み込んでいる。ヘッダは、＜ｓｅｃｕｒｉｔｙ>エレメントの中にセキュリティ・データを含む。ボディはリクエスト・データを含む。この代表的ＳＯＡＰリクエストは、＜ｄｓ：Ｓｉｇｎａｔｕｒｅ＞と称される署名を帯びた＜ｗｓｓｅ：Ｓｅｃｕｒｉｔｙ>と称されるエレメントを含む。この署名は＜ｄｓ：Ｓｉｇｎａｔｕｒｅ Ｖａｌｕｅ＞と称される値を有する。この様に、この例において示されているＳＯＡＰリクエストは、上で記述され図７の参照符（６０４）のところに示されている種類のリクエストを具体化している。

署名の値は“ｋｐＲｙｅｊＹ４ｕｘｗＴ９Ｉ７４ＦＹｖ８ｎＱ”である。この値は、署名されたエレメントをハッシュし、その後に暗号化することにより得られる。署名エレメントの＜ｒｅｆｅｒｅｎｃｅ>エレメントは、署名により署名されたエレメントの名前が“ＣｒｅｄｉｔＣａｒｄＩｎｆｏ”であることを示す。＜ｃｒｅｄｉｔＣａｒｄＩｎｆｏ＞エレメントはリクエストのボディに含まれている。ＣｒｅｄｉｔＣａｒｄＩｎｆｏの“Ｉｄ”属性はＣｒｅｄｉｔＣａｒｄＩｎｆｏであって、このエレメントが“ＣｒｅｄｉｔＣａｒｄＩｎｆｏ”により参照され得ることを示す。従って、署名はＣｒｅｄｉｔＣａｒｄＩｎｆｏエレメントを署名する。

下記は、上記リクエスト・メッセージにより表されるウェブ・サービス・リクエストに対するレスポンスを実現し得る擬似コードＳＯＡＰレスポンス・メッセージの例である：
<Ｓ１１：Ｅｎｖｅｌｏｐｅ ｘｍｌｎｓ：Ｓ１１＝”．．．”ｘｍｌｎｓ：ｗｓｓｅ＝”．．．”ｘｍｌｎｓ：ｗｓｕ＝”．．．”ｘｍｌｎｓ：ｘｅｎｃ＝”．．．”ｘｍｌｎｓ：ｄｓ＝”．．．”ｘｍｌｎｓ：ｗｓｓｅ１１＝”．．．”＞
＜Ｓ１１：Ｈｅａｄｅｒ＞
．．．
＜ｗｓｓｅ：Ｓｅｃｕｒｉｔｙ＞
＜ｗｓｓｅ１１：ＳｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ ｗｓｕ：Ｉｄ＝”ＳｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ”
Ｖａｌｕｅ＝”ｋｐＲｙｅｊＹ４ｕｘｗＴ９１７４ＦＹｖ８ｎＱ＝＝”／＞
．．．
＜ｄｓ：Ｓｉｇｎａｔｕｒｅ＞
．．．
＜ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞
．．．
＜ｄｓ：Ｒｅｆｅｒｅｎｃｅ ＵＲＩ＝”＃ＳｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ”＞
＜ｄｓ：ＤｉｇｅｓｔＭｅｔｈｏｄ
Ａｌｇｏｒｉｔｈｍ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／ｘｍｌｄｓｉｇ＃ｓｈａｌ”／＞
＜ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞
ＬｙＬｓＦ０Ｐｉ４ｗＰＵ．．．
＜ｄｓ：Ｄｉｇｅｓｔ Ｖａｌｕｅ＞
＜／ｄｓ：Ｒｅｆｅｒｅｎｃｅ＞
＜／ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞
＜ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
ＭＣ０ＣＦＦｒＶＬｔＲｌｋ
＜／ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
＜ｄｓ：ＫｅｙＩｎｆｏ＞．．．＜／ｄｓ：ＫｅｙＩｎｆｏ＞
＜／ｄｓ：Ｓｉｇｎａｔｕｒｅ＞
．．．
＜／ｗｓｓｅ：Ｓｅｃｕｒｉｔｙ＞
．．．
＜／Ｓ１１：Ｈｅａｄｅｒ＞
＜Ｓ１１：Ｂｏｄｙ＞
．．．
＜／Ｓ１１：Ｂｏｄｙ＞
＜／Ｓ１１：Ｅｎｖｅｌｏｐｅ＞

この例では、ＳＯＡＰレスポンスは、リクエスト中の署名の値に等しい値を有する署名確認エレメントを含む。ＳＯＡＰレスポンスは署名も含み、それは署名確認エレメントを署名する。この様に、この例において記載されたＳＯＡＰレスポンスは、上で記述され図７の参照符（３２６）のところに示されている種類のレスポンスを具体化している。

上記の代表的ＳＯＡＰリクエストと同様に、この代表的なＳＯＡＰレスポンスはＳＯＡＰエンベロープの中にヘッダとボディとを有する。ヘッダは＜ｗｓｓｅ：Ｓｅｃｕｒｉｔｙ>という名前のエレメントの中に記載されたセキュリティ情報を含む。セキュリティ・エレメントの中には＜ｓｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ＞エレメントがあり、これは、“Ｖａｌｕｅ”という名前の属性において、対応するリクエストからの第１署名の値を伝えている。この例における“Ｖａｌｕｅ”属性は、リクエスト中の署名の値に等しい“ｋｐＲｙｅｊＹ４ｕｘｗＴ９１７４ＦＹｖ８ｎＱ”にセットされている。＜ｓｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ>エレメントは“Ｉｄ”という名前の識別属性も持っており、その値は“ＳｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ”である。

セキュリティ・エレメント＜ｗｓｓｅ：Ｓｒｃｕｒｉｔｙ＞は、＜ｄｓ：Ｓｉｇｎａｔｕｒｅ＞という名前の署名エレメントも含む。リクエストからの第１署名の１つの署名である第２署名の値は、＜ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞という名前の＜ｄｓ：Ｓｉｇｎａｔｕｒｅ＞のエレメントにおいて示されている。この例では第２署名の値は“ＭＣ０ＣＦＦｒＶＬｔＲｌｋ”にセットされている。署名エレメントの＜ｄｓ：Ｒｅｆｅｒｅｎｃｅ＞エレメントは、”＃ＳｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ”にセットされているその”ＵＲＩ”属性により、第２署名を作成するために署名されたデータを特定する。この例では、＜ｄｓ：Ｒｅｆｅｒｅｎｃｅ＞は、第１署名を、署名されたデータとして、すなわち、＜ｗｓｓｅ１１：ＳｉｇｎａｔｕｒｅＣｏｎｆｉｒｍａｔｉｏｎ＞エレメント中の値“ｋｐＲｙｅｊＹ４ｕｘｗＴ９１７４ＦＹｖ８ｎＱ”として特定する。従って、ＳＯＡＰレスポンスのこの例は、第１署名と、第２署名と、第２署名を作成するために署名されたデータとして第１署名を特定するＵＲＩとを含む。

本発明の種々の実施態様に従うウェブ・サービスにおける秘密データ通信では、リクエスタは、レスポンス中の署名確認エレメントを見出してその署名確認エレメントの値を対応するＳＯＡＰリクエスト中の署名の値と比較することによって、ＳＯＡＰレスポンスが特定のＳＯＡＰリクエストに対応することを確認することができる。ＳＯＡＰリクエストが複数の署名を含むときには、リクエスタは、レスポンスに含まれている署名確認エレメントの全てを見出して、それらの署名確認エレメントの値フィールドの値を元のＳＯＡＰリクエスト中の署名の値と比較することができる。

上記のＳＯＡＰリクエスト例及びＳＯＡＰレスポンス例の正確なフォーマットは本発明を限定するものではない。上記の例は、本発明に従うウェブ・サービスにおける秘密データ通信についてのＳＯＡＰリクエスト及びＳＯＡＰレスポンスのための可能なフォーマットの説明に過ぎない。本発明の種々の実施態様に従うウェブ・サービスにおける秘密データ通信のためにＳＯＡＰメッセージ構造又はＳＯＡＰデータ通信プロトコルを用いるときには、署名は当業者が思い浮かべるであろう任意のデータ構造で実現され得、全てのそのような構造は充分に本発明の範囲内にある。

本発明の代表的実施態様は、主として、ウェブ・サービスにおける秘密データ通信のための完全に機能的なコンピュータ・システムと関連して記載されている。しかし、当業者である読者は、任意の適切なデータ処理システムで使用される信号担持媒体に配置されたコンピュータ・プログラム製品においても本発明が具体化され得ることを認めるであろう。その様な信号担持媒体は、磁気媒体、光媒体、又は他の適切な媒体を含む、機械可読情報のための伝送媒体又は記録可能媒体であり得る。記録可能媒体の例は、ハードディスク内の磁気ディスク又はディスケット、光学ドライブ用のコンパクト・ディスク、磁気テープ、及びその他の、当業者が思い浮かべるであろうものを含む。伝送媒体の例は、音声通信用の電話ネットワークと、例えばイーサネット（登録商標）などのデジタル・データ通信ネットワークと、インターネット・プロトコル及びワールド・ワイド・ウェブで通信するネットワークとを含む。適切なプログラミング手段を有する任意のコンピュータ・システムが、プログラム製品において具体化された本発明の方法のステップを実行し得るであろうことを当業者は直ぐに認めるであろう。この明細書に記載されている代表的実施態様のうちの幾つかはコンピュータ・ハードウェアにインストールされてその上で実行するソフトウェアに向けられているけれども、ファームウェアとして或いはハードウェアとして具体化される代わりの実施態様が充分に本発明の範囲内にあることを当業者は直ぐに認めるであろう。

以上の記述から、本発明の種々の実施態様において、その範囲から逸脱すること無く、改変及び変更が行われ得ることが理解されるであろう。この明細書の記述は、説明を目的としているに過ぎず、限定的意味に解されるべきではない。本発明の範囲は、以下の請求項の言葉によってのみ限定される。

１００ ネットワーク

Claims (9)

1. ウェブ・サービスにおける秘密データ通信のための方法であって、前記方法は、
   値を有する第１署名を帯びているエレメントを含むリクエストをリクエスタからウェブ・サービスで受け取るステップと、
   前記第１署名の値を署名し、これにより第２署名を作成して当該第２署名をレスポンスに含めるステップと、
   前記第１署名が暗号化されているか否かを判定するステップと、
   前記第１署名が暗号化されていると判定された場合に、前記第１署名の前記値を、前記値が暗号化された状態で前記レスポンスに含めるステップと、
   前記ウェブ・サービスから前記第２署名を含む前記レスポンスを前記リクエスタに送るステップと、
   前記レスポンスが前記第２署名を含むことを前記リクエスタにより確認するステップと、を含み、
   前記リクエストを受け取るステップは、前記第１署名のみが暗号化されているリクエストを受け取るステップを含むことを特徴とする方法。
2. 前記リクエストを受け取るステップは、ＳＯＡＰで符号化されたリクエストを受け取るステップを更に含み、
   前記レスポンスを送るステップは、ＳＯＡＰで符号化されたレスポンスを送るステップを更に含むことを特徴とする請求項１に記載の方法。
3. 前記第１署名の前記値を署名するステップは、
   値を有する署名確認エレメントを作成するステップと、
   前記署名確認エレメントの前記値を前記第１署名の前記値にセットするステップと、
   前記署名確認エレメントを署名し、これにより第２署名を作成するステップとを更に含んでおり、
   前記レスポンスは前記署名確認エレメントと前記第２署名とを含むことを特徴とする請求項２に記載の方法。
4. 前記リクエストは、値を有する第１署名を帯びた複数のエレメントを更に含み、
   前記第１署名の前記値を署名するステップは、前記第１署名の全ての前記値を署名し、これにより複数の第２署名を作成するステップを更に含み、
   前記レスポンスを送るステップは、前記複数の第２署名を含むレスポンスを送るステップを更に含むことを特徴とする請求項１から３のうちのいずれかに記載の方法。
5. ウェブ・サービスにおける秘密データ通信のためのシステムであって、前記システムはコンピュータ・プロセッサとコンピュータ・メモリとを含み、前記コンピュータ・メモリは前記コンピュータ・プロセッサに作用可能に結合され、前記コンピュータ・メモリの中には、
   値を有する第１署名を帯びているエレメントを含むリクエストをリクエスタからウェブ・サービスで受け取るステップと、
   前記第１署名の値を署名し、これにより第２署名を作成して当該第２署名をレスポンスに含めるステップと、
   前記第１署名が暗号化されているか否かを判定するステップと、
   前記第１署名が暗号化されていると判定された場合に、前記第１署名の前記値を、前記値が暗号化された状態で前記レスポンスに含めるステップと、
   前記ウェブ・サービスから前記第２署名を含む前記レスポンスを前記リクエスタに送るステップと、
   前記レスポンスが前記第２署名を含むことを前記リクエスタにより確認するステップと、
   を実行することができるコンピュータ・プログラム命令が配置され、
   前記リクエストを受け取るステップは、前記第１署名のみが暗号化されているリクエストを受け取るステップを含むことを特徴とするシステム。
6. 前記リクエストを受け取るステップは、ＳＯＡＰで符号化されたリクエストを受け取るステップを更に含み、
   前記レスポンスを送るステップは、ＳＯＡＰで符号化されたレスポンスを送るステップを更に含むことを特徴とする請求項５に記載のシステム。
7. 前記第１署名の前記値を署名するステップは、
   値を有する署名確認エレメントを作成するステップと、
   前記署名確認エレメントの前記値を前記第１署名の前記値にセットするステップと、
   前記署名確認エレメントを署名し、これにより第２署名を作成するステップとを更に含んでおり、
   前記レスポンスは前記署名確認エレメントと前記第２署名とを含むことを特徴とする請求項６に記載のシステム。
8. 前記リクエストは、値を有する第１署名を帯びた複数のエレメントを更に含み、
   前記第１署名の前記値を署名するステップは、前記第１署名の全ての前記値を署名し、これにより複数の第２署名を作成するステップを更に含み、
   前記レスポンスを送るステップは、前記複数の第２署名を含むレスポンスを送るステップを更に含むことを特徴とする請求項５から７のうちのいずれかに記載のシステム。
9. コンピュータ・プログラムであって、請求項１から４までのうちのいずれかの請求項の全てのステップをコンピュータに実行させる、コンピュータ・プログラム。

Images