JP5783630B2 - 複合リソース文書上のデジタル署名 - Google Patents

Description

本開示は一般にデータ処理システム内のリソースのセキュリティに関し、より具体的にはデータ処理システム内の協同ビジネス・プロセスにおける複合リソース文書上のデジタル署名に関する。

「文書」は、ウェブ・ベースの商取引又は協同ビジネス・プロセスのインスタンスを表す便利なメタファである。文書はエンド・ユーザが、情報システムとのエンド・ユーザの対話及びそれら対話の全体の状況についての完全なデジタル表現を保存し、電子メールで送り、そしてそれにデジタル署名することを可能にする。文書はまた、ウェブ・アプリケーションの開発者にとっても便利なメタファであり、なぜなら文書は開発者に対して、ビジネス・プロセスを通して送り、リッチな対話型アプリケーションに関する全体のユーザ体験定義をカプセル化し、ビジネス・プロセス取引に関連する全てのユーザ入力、添付書類及びデジタル署名を包含することができる単一のデジタル・アセットを与えるからである。従って、文書メタファを介して、オフライン又は非接続のフォーム記入体験をエンド・ユーザに容易に提供することができる。

図３を参照すると、ビジネス・プロセス３００内を流通する対話型の文書が、ビジネス・プロセス中の種々の協力者、例えば協力者３１２及び協力者３１４にたいして供給され、その協力者が、コンテンツ・リポジトリ３０２及び契約テンプレート３０６を用いて文書に彼らの入力を与えて提案契約３０８を作成できるようにするメンタルモデルが示される。提案契約は、認可者３１６が審査し認可することができ、その際認可者３１６はインターネット３１８のようなネットワークで通信してチェック・クレジット・サービス３２０及び電子資金振替サービス３２２を使用して履行契約３１０を生成する。履行契約３１０はリポジトリ３０４内に保存することができる。

図４を参照すると、対話型文書の論理層が示される。基本的に、「対話型文書」はウェブ・アプリケーション、及び特定のユーザ又はユーザの組によるウェブ・アプリケーションの体験を表す。履行契約３１０のような文書は、典型的にはデータ層、ビジネス規則層、論理ユーザ・インタフェース層、及びプレゼンテーション層を含む幾つかの論理層４００に編成される傾向がある。対話型文書４００は、協同ビジネス・プロセス内の対話型文書のコンポーネントを表すための論理的に階層化された手法である。ヒューマン・インタフェース４０２は、論理ユーザ・インタフェース層及びプレゼンテーション層の一例であり、一方ビジネス論理及び動的確認４０４はビジネス規則層を表す。

データ層は、データ・アクセス及び確認４０６によって表され、基礎となるデータを表すものであり、このデータは拡張マークアップ言語（ＸＭＬ）形式で書かれることが多く、ＸＭＬパス言語（ＸＰａｔｈ）によってアドレス可能であり、情報システムが最終的に推進するように設計された最終取引のＸＭＬスキーマ４１８に適合するように意図したものである。このアプリケーションの目標はデータ層の「記入体験」である。データ層は、データの簡単な項目、例えば、ユーザによって入力された、名称、日付、数、及び量のようなデータ・インスタンス４０８など、並びに添付ファイル及びデジタル署名を含むことができる。ビジネス・プロセスのキーポイントにおいて、データを残りの文書から分離してデータベースに保存することができ、及び／又はワークフロー・ステップを促進するか又は取引を完了するのに用いることができる。

ビジネス規則、論理ユーザ・インタフェース及びプレゼンテーション層は、データ層に結合して対話サービスを提供する。例えば、ＸＭＬフォーム定義言語、XFormsモデル４１６を用いるビジネス規則は、ユーザが特定の年齢のときにだけデータの特定の部分が関連するようにすることができ、XForms論理ユーザ・インタフェース４１４は、データ及びビジネス規則メタデータをプレゼンテーション層に接続する結合機構を提供することができ、プレゼンテーション層は、グラフィカル・ユーザ体験を、マルチページＸＦＤＬ４１２を用いて複数のページに分割することができる。拡張書式記述言語（ＸＦＤＬ）は、最初にワールドワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）ＮＯＴＥ−ＸＦＤＬ−１９９８０９０２の中で仕様を定められた拡張マークアップ言語（ＸＭＬ）の一種である。２０１０年８月現在で、ＸＦＤＬの最新の仕様は、下記のサイトから入手できる。
http://publib.boulder.ibm.com/infocenter/forms/v3r5m1/topic/com.ibm.form.designer.xfdl.doc/XFDL%20Specification%207.7.pdf

そのような文書の上のデジタル署名は、ユーザによって提供されたデータを保護し、また同時に他の層を保護し、それにより、データと内部にデータが収集されたアプリケーション・コンテキストとの間の保護された結合を作成する。デジタル署名は、通常ＸＭＬ及びＸＭＬ署名４２０を用いるセキュリティ、監査能力及び相互運用４１０を通じてサポートされる。例えば、ユーザがデータ値「５００」を入力するとき、デジタル署名はデータ値「５００」だけでなく、そのデータ値が「５００個の鉄骨を購入する」又は「５００株売却する」を意味するかどうかのデータ値の意味もまた保護する。このアプリケーションの要件は、８．１節におけるＷ３ＣＸＭＬ署名標準（http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/）に適合し、これは、適合するアプリケーションは収集された下層のデータだけでなくユーザが「見た」ものに署名及び確認すべきであることを実質的に言明するものである。

協同ビジネス・プロセスには、デジタル署名に関する複雑な要素が存在する。簡単なデジタル署名アプリケーションでは、完全な不透明ファイル、口語的には「ビットのバケツ」として文書に署名する傾向がある。この署名は、全体のファイルを保護し、署名を付けられた後に何らかの修正がファイルに加えられるときにデジタル署名は無効となる。しかし、協同ビジネス・プロセスにおいては、最初のデジタル署名が付けられた後にワークフローのステップが実施されることが多い。これらのワークフロー・ステップは、全体の取引に関連する付加的情報を作成する。文書は全体の完全なビジネス・プロセス取引を表すものであるので、これらのワークフロー・ステップは文書を修正するはずであり、これらはデジタル署名を無効にせずに行われる必要がある。

Ｗ３Ｃ ＸＭＬ署名標準はデジタル署名変換の形の解決策を提供する。変換を用いずに、単一のＸＭＬ署名を任意の数のＵＲＩアドレス可能リソースに署名することができる。任意の数のこれらリソースはバイナリとすることができ、それゆえにＸＭＬ署名はＸＭＬコンテンツ及び非ＸＭＬコンテンツに署名することができる。各々のリソースの暗号ハッシュがＸＭＬ署名内に配置され、次に一組のリソース・ハッシュが署名者のプライベート鍵マテリアルでハッシュされ暗号化される。しかしながら、Ｗ３ＣＸＭＬ署名標準はまた、各々のリソースをハッシュする前に変換することを可能にする。特にＸＭＬリソースはXPathフィルター２（http://www.w3.org/TR/xmldsig-filter2/から入手できる）を用いて変換することができ、このフィルターはＸＭＬリソースの部分を、ハッシュを計算する前に取り去ることを可能にする。

フィルタリング変換はまた、署名されるべきものを簡単にリストアップすることができるが、これはリストアップされないどんなものでも署名を無効にせずにリソースに加えることができるのでセキュリティ値が低い。協同ビジネス・プロセスにおいて、既知の最良の実施はサブトラクション・フィルターを用いることであり、その理由は、取り去るものの表現がまた、署名を付けられた後で残りのビジネス・プロセスのどれが修正可能であるかの特徴付けともなるからである。サブトラクション・フィルターによって特徴付けられないあらゆる他の付加、変更又は削除は、デジタル署名を無効化する望ましい効果を有することになる。

単一のＸＭＬ文書は、アプリケーションの作者が益々多くのページを有するアプリケーションを作成し、同時にサーバ毎のより高いフォーム処理能力を要求するので、時間がたつにつれて維持できなくなる可能性がある。既知の解決策は、サブトラクション・フィルタリングが可能であるが性能が不十分な単一ＸＭＬファイルとして文書を表現すること、並びに、より優れた性能を提供し、各リソース内でのサブトラクション・フィルタリングは可能であるが、複合リソースからのリソース全体のサブトラクション・フィルタリングが可能ではない複合リソースとして文書を表現することを含む、対話型文書にデジタル方式で署名することに関する欠点を有する。

一実施形態により、複合リソース文書のためのデジタル署名を作成するコンピュータ実施の方法は、少なくとも１つのリソースを含む複合リソース文書を受け取り、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得し、最新のマニフェスト・リソース内のリソースのリストから取り去るべきゼロ、１つ又は複数のリソースを指示して、署名されるべき識別されたリソースの生成署名参照リストを作成し、生成署名参照リスト内の識別されたリソース用いてハッシュ・トークンを生成して署名ハッシュ・トークンを形成し、秘密鍵を用いて署名ハッシュ・トークンを暗号化する。

一実施形態により、複合リソース文書のデジタル署名を確認するためのコンピュータ実施の方法は、デジタル署名を有する１つ又は複数のリソースを含む複合リソース文書を受け取り、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得し、デジタル署名内の生成署名参照リスト内の識別されたリソース用いてハッシュ・トークンを生成して生成ハッシュ・トークンを形成し、取得した復号鍵を用いてデジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成し、生成ハッシュ・トークンと署名ハッシュ・トークンとの少なくとも比較に応答して署名正当性結果を生成する。

別の実施形態により、複合リソース文書のためのデジタル署名を作成するためのコンピュータ・プログラムは、内部にストアしたコンピュータ実行可能プログラム・コードを含むコンピュータ書き込み可能型媒体を含む。このコンピュータ実行可能プログラム・コードは、少なくとも１つのリソースを含む複合リソース文書を受け取るためのコンピュータ実行可能プログラム・コードと、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得するためのコンピュータ実行可能プログラム・コードと、最新のマニフェスト・リソース内のリソースのリストから取り去るべきゼロ、１つ又は複数のリソースを指示して、署名されるべき識別されたリソースの生成署名参照リストを作成するためのコンピュータ実行可能プログラム・コードと、生成署名参照リスト内の識別されたリソース用いてハッシュ・トークンを生成して署名ハッシュ・トークンを形成するためのコンピュータ実行可能プログラム・コードと、秘密鍵を用いて署名ハッシュ・トークンを暗号化するためのコンピュータ実行可能プログラム・コードとを含む。

別の実施形態において、複合リソース文書のデジタル署名を確認するためのコンピュータ・プログラムは、内部にストアしたコンピュータ実行可能プログラム・コードを含むコンピュータ書き込み可能型媒体を含む。このコンピュータ実行可能プログラム・コードは、デジタル署名を有する１つ又は複数のリソースを含む複合リソース文書を受け取るためのコンピュータ実行可能プログラム・コードと、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得するためのコンピュータ実行可能プログラム・コードと、デジタル署名内の生成署名参照リスト内の識別されたリソース用いてハッシュ・トークンを生成して生成ハッシュ・トークンを形成するためのコンピュータ実行可能プログラム・コードと、取得した復号鍵を用いてデジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成するためのコンピュータ実行可能プログラム・コードと、生成ハッシュ・トークンと署名ハッシュ・トークンとの少なくとも比較に応答して署名正当性結果を生成するためのコンピュータ実行可能プログラム・コードとを含む。

別の実施形態により、複合リソース文書のためのデジタル署名を作成するための装置は、通信ファブリックと、通信ファブリックに接続され、コンピュータ実行可能プログラム・コードを含むメモリと、通信ファブリックに接続された通信ユニットと、通信ファブリックに接続された入力／出力ユニットと、通信ファブリックに接続されたディスプレイと、通信ファブリックに接続されたプロセッサ・ユニットとを備える。プロセッサ・ユニットは、コンピュータ実行可能プログラム・コードを実行して、装置に対して、少なくとも１つのリソースを含む複合リソース文書を受け取り、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得し、最新のマニフェスト・リソース内のリソースのリストから取り去るべきゼロ、１つ又は複数のリソースを指示して、署名されるべき識別されたリソースの生成署名参照リストを作成し、生成署名参照リスト内の識別されたリソース用いてハッシュ・トークンを生成して署名ハッシュ・トークンを形成し、秘密鍵を用いて署名ハッシュ・トークンを暗号化するように命令する。

別の実施形態により、複合リソース文書のデジタル署名を確認するための装置は、通信ファブリックと、通信ファブリックに接続され、コンピュータ実行可能プログラム・コードを含むメモリと、通信ファブリックに接続された通信ユニットと、通信ファブリックに接続された入力／出力ユニットと、通信ファブリックに接続されたディスプレイと、通信ファブリックに接続されたプロセッサ・ユニットとを備える。プロセッサ・ユニットは、コンピュータ実行可能プログラム・コードを実行して、装置に対して、デジタル署名を有する１つ又は複数のリソースを含む複合リソース文書を受け取り、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得し、デジタル署名内の生成署名参照リスト内の識別されたリソース用いてハッシュ・トークンを生成して生成ハッシュ・トークンを形成し、取得した復号鍵を用いてデジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成し、生成ハッシュ・トークンと署名ハッシュ・トークンとの少なくとも比較に応答して署名正当性結果を生成するように命令する。

本開示のより完全な理解のために、これから添付の図面に関連して記述した以下の簡単な説明及び詳細な説明について言及するが、その際、類似の参照番号は類似の部分を表す。

本開示の種々の実施形態に関する動作可能なデータ処理システムの例示的なネットワークのブロック図である。 本開示の種々の実施形態に関する動作可能な例示的なデータ処理システムのブロック図である。 対話型文書フローのメンタルモデルのブロック図である。 図３の対話型文書の階層化のブロック図である。 本開示の一実施形態による複合文書システムのブロック図である。 本開示の一実施形態による、モノリシック対話型文書から複合文書の書式への論理的移行のブロック図である。 本開示の実施形態による、複合文書、複合文書をウェブ上で利用可能にするＲＥＳＴサービス、ウェブ・アプリケーション層、及びエンド・ユーザ対話層の間の関係のブロック図である。 本開示の実施形態による、複合リソース文書のコンポーネントに関連するＸＭＬ署名の論理記憶位置のブロック図である。 本開示の実施形態による、マニフェストのコード断片の一例である。 本開示の種々の実施形態による、複合リソース文書テンプレート内のＸＭＬデータのコード断片の一例である。 本開示の種々の実施形態による、記入された図１０の複合リソース文書内のＸＭＬデータのコード断片の一例である。 本開示の種々の実施形態による、複合リソース文書署名を含むコード断片の一例である。 本開示の種々の実施形態による、複合リソース文書署名を含むコード断片の一例である。 本開示の種々の実施形態による、複合リソース文書署名を含むコード断片の一例である。 本開示の種々の実施形態による、参照リスト生成を示す複合リソース文書署名定義の別のコード断片の例である。 本開示の種々の実施形態による、参照リスト生成を示す複合リソース文書署名定義の別のコード断片の例である。 本開示の種々の実施形態による、複数の署名者を有し、変換されたリソースを指定する手段を示す複合リソース文書定義のコード断片の一例である。 本開示の種々の実施形態による、参照生成を制御するためのパターンを指定するためのコード断片の一例である。 本開示の種々の実施形態による、生成署名参照リストから特定のリソースをフィルタリングするためのコード断片の一例である。 本開示の種々の実施形態による、生成署名参照リストから特定のリソースをフィルタリングするためのコード断片の一例である。 本開示による複合リソースのためのデジタル署名を生成する方法のフローチャートである。 本開示の種々の実施形態による、図１７の複合リソースのためのデジタル署名を確認する方法のフローチャートである。 本開示による、図１８の署名正当性結果を生成する方法のフローチャートである。

１つ又は複数の実施形態の例証となる実施を以下に与えるが、本開示のシステム及び／又は方法は、多くの技術を用いて実施することができる。本開示は、本明細書で示し、説明する例示的な設計及び実施を含む、以下で説明する例証的な実施、図面、及び技術に決して限定されるべきではなく、添付の特許請求の範囲並びにそれらの均等物の全範囲内で修正することができる。

当業者によって理解されるように、本開示の態様は、システム、方法、又はコンピュータ・プログラムとして具体化することができる。従って、本開示の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、又は本明細書で一般的に全て「回路」、「モジュール」、又は「システム」と呼ぶことができるソフトウェア態様とハードウェア態様を組み合わせた実施形態の形をとるものとすることができる。さらに、本開示の態様は、その上に具体化されたコンピュータ可読プログラム・コードを有する、１つ又は複数のコンピュータ可読媒体内に具体化されたコンピュータ・プログラムの形態を取ることができる。

１つ又は複数のコンピュータ可読媒体の任意の組合せを用いることができる。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体とすることができる。コンピュータ可読記憶媒体は、例えば、これらに限定されるものではないが、電子、磁気、光学、電磁、赤外線、又は半導体のシステム、装置、又はデバイス、或いは上記の任意の適切な組合せとすることができる。コンピュータ可読記憶媒体のよりより具体的な例（非網羅的なリスト）には、以下のもの、すなわち、１つ又は複数の配線を有する電気的接続、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤＲＯＭ）、光記憶装置、又は磁気記憶装置、或いはそれらの任意の適切な組合せを含む。本明細書の文脈において、コンピュータ可読記憶媒体は、命令実行システム、装置、若しくはデバイスによって、又はそれらと接続して使用するための、プログラムを含み、又は格納することができる任意の有形の媒体とすることができる。

コンピュータ可読信号媒体は、例えば、ベースバンド内に又は搬送波の一部分として、それにより具体化されたコンピュータ可読プログラム・コードを有する伝搬データ信号を含むことができる。こうした伝搬信号は、これらに限定されるものではないが、電磁気的、光学的、又はそれらの任意の適切な組合せを含む様々な形態をとることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、又はデバイスによって、又はそれらと接続して使用するための、プログラムを通信し、伝搬し、又は搬送することができる任意のコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に具体化されたプログラム・コードは、これらに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦなど、又はそれらの任意の適切な組合せを含む任意の適切な媒体を用いて伝達することができる。

本開示の態様に関する動作を実行するためのコンピュータ・プログラム・コードは、例えば、Ｊａｖａ（商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、及び、「Ｃ」プログラミング言語又は同様なプログラミング言語のような、従来の手続き型プログラミング言語を含む、１つ又は複数のプログラミング言語の任意の組合せで書くことができる。Ｊａｖａ及び全てのＪａｖａベースの商標及びロゴは、米国、他の国、又はその両方におけるＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．，社の登録商標である。プログラム・コードは、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で、独立したソフトウェア・パッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。一番最後のシナリオの場合、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部のコンピュータへの接続がなされる場合もある（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）。

本開示の態様は、本発明の実施形態による方法、装置、（システム）及びコンピュータ・プログラムのフローチャート説明図及び／又はブロック図を参照して、ここに説明される。フローチャート説明図及び／又はブロック図の各ブロック、並びに、フローチャート説明図及び／又はブロック図中のブロックの組合せは、コンピュータ・プログラム命令によって実施できることを理解されるであろう。

これらのコンピュータ・プログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに供給してマシンを形成し、その結果、コンピュータ又は他のプログラム可能データ処理装置のプロセッサにより実行される命令が、フローチャート及び／又はブロック図のブロック又はブロック群において指定される機能／動作を実装するための手段を生成するようすることができる。

コンピュータ可読媒体に格納された命令が、フローチャート及び／又はブロック図のブロック又はブロック群において指定される機能／動作を実装する命令手段を含む製品を生成するように、コンピュータ又は他のプログラム可能なデータ処理装置に特定の方法で機能するように命令することが可能なこれらのコンピュータ・プログラム命令を、コンピュータ可読メモリに格納することもできる。

コンピュータ又は他のプログラム可能な装置上で実行する命令が、フローチャート及び／又はブロック図のブロック又はブロック群において指定される機能／動作を実装するためのステップを提供するように、コンピュータ・プログラム命令をコンピュータ又は他のプログラム可能データ処理装置にロードし、一連の操作ステップをコンピュータ又は他のプログラム可能装置上で実行させて、コンピュータに実装されるプロセスを生成することもできる。

ここで図を参照し、特に図１及び図２を参照すると、例証的な実施形態を実施することができるデータ処理環境の例示的な略図が与えられる。図１及び図２は単に例示的なものに過ぎず、種々の実施形態を実施することができる環境に対して何らかの制限を主張又は暗示することを意図したものではないことを認識されたい。図示した実施形態には多くの修正を加えることができる。

図１は、例証的な実施形態を実施することができるデータ処理システムのネットワークの図形的表現を示す。ネットワーク・データ処理システム１００は、例証的な実施形態を実施することができるコンピュータのネットワークである。ネットワーク・データ処理システム１００は、ネットワーク１０２を含み、これは、ネットワーク・データ処理システム１００の内部に共に接続された種々のデバイス及びコンピュータの間の通信リンクを提供する。

図示した例において、サーバ１０４及びサーバ１０６は記憶装置１０８と共にネットワーク１０２に接続する。さらに、クライアント１１０、１１２、及び１１４がネットワーク１０４に接続する。クライアント１１０、１１２、及び１１４は、例えば、パーソナル・コンピュータ又はネットワーク・コンピュータとすることができる。図示した例において、サーバ１０４は、例えば、起動ファイル、オペレーティング・システム・イメージ、及びアプリケーションなどのデータをクライアント１１０、１１２、及び１１４に供給することができる。クライアント１１０、１１２、及び１１４は本例においてはサーバ１０４に対するクライアントである。ネットワーク・データ処理システム１００は、図には示さない付加的なサーバ、クライアント、及び他のデバイスを含むことができる。

図示した例において、ネットワーク・データ処理システム１００は、ネットワーク１０２を有するインターネットであり、これは、相互に通信するための通信制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のプロトコル一式を用いるネットワーク及びゲートウェイの世界的規模の集合を表す。インターネットの中心には、データ及びメッセージを伝送する数千の商用、行政、教育又は他のコンピュータ・システムからなる、主要ノード又はホスト・コンピュータの間の高速データ通信ラインの基乾回線が存在する。もちろん、ネットワーク・データ処理システム１００はまた、例えばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、又は広域ネットワーク（ＷＡＮ）などの多くの異なるタイプのネットワークとして実施することもできる。図１は例示のためであり、種々の例証的な実施形態に対する構造上の限定を意図したものではない。

次に図２を見ると、本開示の種々の実施形態に対して動作可能な例示的なデータ処理システムのブロック図が示される。この例証的な例において、データ処理システム２００は通信ファブリック２０２を含み、これが、プロセッサ・ユニット２０４、メモリ２０６、永続記憶装置２０８、通信ユニット２１０、入力／出力（Ｉ／Ｏ）ユニット２１２、及びディスプレイ２１４の間の通信をもたらす。

プロセッサ・ユニット２０４は、メモリ２０６にロードすることができるソフトウェアの命令を実行するように働く。プロセッサ・ユニット２０４は、特定の実施に応じて、１つ又は複数のプロセッサの組とすることができ、又はマルチ・プロセッサ・コアとすることができる。さらにプロセッサ・ユニット２０４は、主プロセッサが副プロセッサと共に単一チップ内に存在する１つ又は複数の異種プロセッサ・システムを用いて実施することができる。別の例証的な例として、プロセッサ・ユニット２０４は、同じタイプの複数のプロセッサを含んだ対称型マルチ・プロセッサ・システムとすることができる。

メモリ２０６及び永続記憶装置２０８は記憶装置２１６の例である。記憶装置は、例えば、制限無しに、データ、関数型のプログラム・コード、及び／又は他の適切な情報などの情報を、一時的に又は永続的にストアすることができる、任意のハードウェア要素である。これらの例においてメモリ２０６は、例えば、ランダム・アクセス・メモリ又は任意の他の適切な揮発又は不揮発記憶装置とすることができる。永続記憶装置２０８は、具体的な実施に応じて種々の形態を取ることができる。例えば、永続記憶装置２０８は１つ又は複数のコンポーネント又はデバイスを含むことができる。例えば、永続記憶装置２０８はハード・ドライブ、フラッシュ・メモリ、書換え可能光ディスク、書換え可能磁気テープ、又はそれらのある組合せとすることができる。永続記憶装置２０８によって用いる媒体はまた取り外し可能とすることができる。例えば、取り外し可能ハード・ドライブを永続記憶装置２０８用に用いることができる。

これらの例において通信ユニット２１０は、他のデータ処理システム又はデバイスとの通信をもたらす。これらの例において通信ユニット２１０は、ネットワーク・インタフェース・カードとする。通信ユニット２１０は、物理的通信リンク及び無線通信リンクのいずれか又は両方の使用による通信をもたらす。

入力／出力ユニット２１２は、データ処理システム２００に接続することができる他のデバイスとのデータの入力及び出力を可能にする。例えば、入力／出力ユニット２１２は、キーボード、マウス、及び／又は何らかの他の適切な入力デバイスによるユーザ入力に関する接続をもたらすことができる。さらに、入力／出力ユニット２１２は、出力をプリンタに送ることができる。ディスプレイ２１４は、ユーザに情報を表示する機構を与える。

オペレーティング・システム、アプリケーション及び／又はプログラムに関する命令は、通信ファブリック２０２を通じてプロセッサ・ユニット２０４と通信する記憶装置２１６内に配置することができる。これらの例証的な例において、命令は永続記憶装置２０８上の関数形式とする。これらの命令は、プロセッサ・ユニット２０４による実行のためにメモリ２０６にロードすることができる。異なる実施形態の方法は、メモリ２０６のようなメモリ内に配置することができるコンピュータ実施の命令を用いてプロセッサ・ユニット２０４により実行することができる。

これらの命令は、プログラム・コード、コンピュータ使用可能プログラム・コード、コンピュータ実行可能命令、又はコンピュータ可読プログラム・コードと呼ばれ、これはプロセッサ・ユニット２０４内のプロセッサによって読まれて実行されることができる。異なる実施形態におけるプログラム・コードは、例えばメモリ２０６又は永続記憶装置２０８のような異なる物理的又は有形のコンピュータ可読媒体上に具体化することができる。

プログラム・コード２１８は、選択的に取り外し可能なコンピュータ可読媒体２２０上に関数形式で配置され、プロセッサ・ユニット２０４による実行のためにデータ処理システム２００にロード又は転送することができる。プログラム・コード２１８及びコンピュータ可読媒体２２０は、これらの例においてはコンピュータ・プログラム２２２を形成する。一例において、コンピュータ可読媒体２２０は、例えば、永続記憶装置の一部分であるドライブ又は他のデバイス内に挿入又は配置され、例えば永続記憶装置２０８の一部分であるハード・ドライブのような記憶装置上への転送のための光又は磁気ディスクなどの有形形態にすることができる。有形形態において、コンピュータ可読媒体２２０はまた、データ処理システム２００に接続されたハード・ドライブ、サム・ドライブ（thumb drive）、又はフラッシュ・メモリなどの永続記憶装置の記憶媒体の形態を取ることができる。コンピュータ可読媒体２２０の有形形態はまた、コンピュータ書き込み可能記憶媒体とも呼ばれる。ある場合には、コンピュータ可読媒体２２０は取り外し可能でなくても良い。

代替的に、プログラム・コード２１８は、コンピュータ可読媒体２２０から、通信ユニット２１０への通信リンクを通じて及び／又は入力／出力ユニット２１２への接続により、データ処理システム２００へ転送することができる。通信リンク及び／又は接続は、例証的な実施例においては物理的又は無線とすることができる。コンピュータ可読媒体はまた、プログラム・コードを含んだ通信リンク又は無線伝送のような無形媒体の形態を取ることができる。

幾つかの例証的な実施形態において、プログラム・コード２１８は、データ処理システム２００内での使用のために、別のデバイス又はデータ処理システムからネットワークを介して永続記憶装置２０８にダウンロードすることができる。例えば、サーバ・データ処理システム内のコンピュータ可読記憶媒体内にストアされたプログラム・コードを、ネットワークを介してサーバからデータ処理システム２００にダウンロードすることができる。プログラム・コード２１８を供給するデータ処理システムは、サーバ・コンピュータ、クライアント・コンピュータ、又はプログラム・コード２１８をストアし及び伝送することができる何れかの他のデバイスとすることができる。

一例として図２のデータ処理システム２００を用いる例証的な実施形態によれば、プロセッサ・ユニット２０４は、複合リソース文書のためのデジタル署名を作成するためのコンピュータ実施の方法を実行し、通信ユニット２１０、記憶装置２１６又は入力／出力ユニット２１２を含むソースからの少なくとも１つのリソースを含んだ複合リソース文書を受け取る。プロセッサ・ユニット２０４は、複合リソース文書内の全てのリソースをリストアップした最新のマニフェスト・リソースを取得し、最新のマニフェスト・リソース内のリソースのリストから取りさるべきゼロ、１つ又は複数のリソースを指示して、署名されるべき識別されたリソースの生成署名参照リストを作成する。プロセッサ・ユニット２０４は、生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成して署名ハッシュ・トークンを形成し、秘密鍵を用いて署名ハッシュ・トークンを暗号化する。

プロセッサ・ユニット２０４は、さらにコンピュータ実施の方法を実行して複合リソース文書のデジタル署名を確認する。プロセッサ・ユニット２０４は、デジタル署名を有する１つ又は複数のリソースを含む複合リソース文書を、通信ユニット２１０、記憶装置２１６又は入力／出力ユニット２１２を含むソースから受け取る。プロセッサ・ユニット２０４は、複合リソース文書内の全てのリソースをリストアップした最新のマニフェスト・リソースを取得する。プロセッサ・ユニット２０４は、デジタル署名内の生成署名参照リスト内の識別されたリソースを用いて生成ハッシュ・トークンを形成し、取得した復号鍵を用いてデジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成する。プロセッサ・ユニット２０４は、生成ハッシュ・トークンと署名ハッシュ・トークンとの少なくとも比較に応答して、署名正当性結果を生成する。

代替的な実施形態において、コンピュータ実施の方法を含む図２のプログラム・コード２１８はコンピュータ・プログラム２２２としてコンピュータ可読媒体２２０内にストアすることができる。別の例証的な実施形態において、複合リソース文書にデジタル署名する方法は、通信ファブリックと、通信ファブリックに接続され、コンピュータ実行可能プログラム・コードを含むメモリと、通信ファブリックに接続された通信ユニットと、通信ファブリックに接続された入力／出力ユニットと、通信ファブリックに接続されたディスプレイと、通信ファブリックに接続されたプロセッサ・ユニットとを備えた装置内で実施することができる。装置のプロセッサ・ユニットはコンピュータ実行可能プログラム・コードを実行して装置に対して方法を実行するように命令する。

図５を参照すると、本開示の一実施形態による複合文書システムのブロック図が示される。複合文書システム５００は、図２のデータ処理システム２００のようなシステムに典型的な下層のオペレーティング・システム・サービスのサポートを含む一組のコンポーネントの一例である。

複合文書システム５００は、拡張署名ジェネレータ５０２、拡張署名メタデータ５０４、マニフェスト・リソース５０６、ＵＲＩリゾルバ５０８、オブジェクト要素５１０及び複合文書構造体５１２を含む多数の相互に関係するコンポーネントを含む。

拡張署名ジェネレータ５０２は、ＸＭＬ命令文を処理する機能を提供して、用いられる適用可能なＸＭＬ標準に適合するデジタル署名を生成する。署名ジェネレータは拡張されてＵＲＩリゾルバ５０８を含み、これがデジタル署名の作成中に必要なリソースを検索する。ＵＲＩリゾルバ５０８は、共通リソース識別子を用いて複合文書内に含まれる特定のリソースを取得する。ＵＲＩは本質的に参照リソースを検索する。署名ジェネレータと共にリゾルバを含めることにより、必要なリソース・エントリが通常の市販のＸＭＬ署名プロセッサにより検出できるようになり、リソースは、ローカルに複合リソース文書内で、又は遠隔にウェブ・サーバ上で検索される。デジタル信号ライブラリ関数の呼び出し元は、ＵＲＩリゾルバをデジタル信号ライブラリに供給する。ＵＲＩリゾルバは、典型的には、ジャバ（Java）のようなプログラミング言語（によって供給される）の一部分である。

拡張署名メタデータ５０４は、署名特性要素として含めることができる付加的な項目を含む。この付加的な項目は、エンド・ユーザのロケール記述子、ロケール・データ及び署名時間、並びにＵＴＣデータ及び署名時間を含む。

マニフェスト・リソース５０６は、複合リソース文書内に含まれる全てのリソースのリストを含む。典型的には、複合リソース文書のプロセッサは、複合リソース文書にリソースが加えられるか又はそれから削除されるときはいつでも、マニフェスト・リソース５０６を更新する。しかし、本開示の目的のためには、デジタル署名を生成する時点及びデジタル署名を確認する時点において、マニフェスト・リソース５０６が複合リソース文書内のリソースを反映することだけが必要である。オブジェクト要素５１０は、複合文書の署名要素内の作者によって設計された特別のコンテンツを含む１つ又は複数の要素を含んだ一組の要素である。例示的な実施形態において、オブジェクト要素５１０は、署名された情報構造体内に生成される参照要素のリストから取り去るべきリソースを指示するリソース記述子のリストを宣言する特別に識別されるＸＭＬ属性を含む。

複合文書構造体５１２は、対話型ウェブ文書書式を表す複合リソース文書を含む要素の相対的位置に関する論理構造を定義する。典型的な要素はヘッダ、例えば、ＭＩＭＥ型識別子、ウィザード・ページのリソース、イメージ、フォーム・ページ、データ・インスタンス、添付書類書式モデル、対話制御及びマニフェストなどを含む。図６は複合文書構造体の一例を示す。

図６を参照すると、本開示の一実施形態による、モノリシックな対話型文書から複合文書の書式への論理的移行のブロック図が示される。構造体６００は時間と共に展開する論理的移行を表す。移行は処理中に起こる変換を示すのではなく、むしろこの表示は異なるモデルの類似点と相違点を示す。図中、Ｗはウィザード・ページを表し、Ｆはフォーム・ページを表し、Ｄはデータ・インスタンスを表し、Ｍはフォームのモデルを表し、そしてＩＣは対話コントローラを表す。

構造体６０２は、モノリシック・モデルを用いて文書を単一のＸＭＬファイル書式として表す。構造体６０４は、構造体６０２のリソース分解図に、構造体６０２内の対話型ユーザ・インタフェース定義を含んだウィザード・ページ及びフォーム・ページのリソースの間の管理移行を補助するための随意の対話コントローラを加えたものを表す。

構造体６０６は、対話型文書に必要な全てのリソースを含む圧縮アーカイブとしてオープン文書書式（ＯＤＦ）パッケージング書式を用いた、複合リソース文書書式の圧縮アーカイブ書式を表す。構造体６０６の文書書式は、構造体６０４及びそれ故に構造体６０２の種々のコンポーネントを別個のリソースとして内部に含む。構造体６０６はまた、ＭＩＭＥ型６０８情報要素及びマニフェスト６１０リソースを含む。

圧縮アーカイブ書式には、リソース及びディレクトリの付加、削除及び変更を許可し、そしてもちろんリソースのコンテンツ及びディレクトリ・リストを取得する機能を許可するアプリケーション・プログラミング・インタフェースを介してアクセスすることができる。通常、それらのリソース及びディレクトリの付加、削除及び変更はマニフェスト６１０リソースのコンテンツ内に反映される。

図７を参照すると、本開示の実施形態による、複合文書、ウェブ上で利用可能な複合文書を作成するＲＥＳＴサービス、ウェブ・アプリケーション層、及びエンド・ユーザ対話層の間の関係のブロック図が示される。例証的な一実施形態において、ウェブ・ベースでのエンド・ユーザの複合文書との対話の許可には、文書に対して表現状態転送（ＲＥＳＴ）アーキテクチャ・サービスのフロント・エンドが用いられる。このサービスは、文書テンプレートをコピーして協同ビジネス・プロセスのインスタンスの中心的なアーチファクトにすることを可能にする。ビジネス・プロセスを通して全体の文書が伝送されるのではなく、インスタンス化された文書のＲＥＳＴインタフェースへのアクセス制御のトークンがビジネス・プロセス内を送られる。

関係７００は、ビジネス・プロセス７０２の継続期間に適用され、アプリケーション・クライアント層７０４と、アプリケーション・サーバ層７０６、文書対話層７０８、及び複合ウェブ・リソース層との関連を与える。文書対話層７０８は、論理的に解凍された複合リソース文書７１２と対話するための複合リソース文書プロセッサ、ＲＥＳＴインタフェース７１４を提供する。ＲＥＳＴインタフェース７１４の２つの端点は、複合リソース文書内に指定されたＸＭＬデジタル署名を生成し、複合リソース文書内の指定されたＸＭＬデジタル署名を確認する機能を提供する。複合リソース文書プロセッサ、ＲＥＳＴインタフェース７１４は、論理的に解凍された複合リソース文書７１２と対話してそれらを修正するためのアクセスを、サーバ７１６の論理層及びクライアント７１８の論理層の両方に与える。

図８を参照すると、本開示による、複合リソース文書のコンポーネントに関連するＸＭＬ署名の論理位置のブロック図が示される。例示的な実施には、アパッチ（Apache）ＸＭＬ署名ライブラリ（アパッチは、アパッチ・ソフトウェア・ファウンデーションの登録商標である）が用いられるが、実施にはジャバ（Java）に組み込まれたＸＭＬ署名機能を用いることもできる。例示的な実施形態における複合リソース文書８０２に関する論理関係８００は、ＵＲＩリゾルバをＸＭＬ署名ジェネレータに供給して、署名ジェネレータが複合リソース文書のリソースを検出できるようにする。複合リソース文書８０２は、ロゴ８０４、並びに、データ・インスタンス８１０及びデータ・インスタンス８１２を伴うフォーム・ページ８０６及びフォーム・ページ８０８を備える。データ・インスタンス８１２はさらにＸＭＬ署名８１４含む。

ＸＭＬ署名８１４を生成する前に、署名のマークアップがXFormインスタンスのＸＭＬデータ内に以下の形で現れる。

SignedInfo要素内において、ＸＭＬ署名は参照要素を用いて署名又は確認するための１つ又は複数のリソースをリストアップすることができる。リソースはＵＲＩによって指示され、これは例示的な実施においては本開示のＵＲＩリゾルバによって分解される。論理関係８００は、複合リソース文書が何処にストアされているかに関わらず、データ層内でのＸＭＬ署名８１４の論理位置、並びに、複合リソース文書８０２内の相対的参照リソースに対するＸＭＬ署名８１４の機能を示す。一実施においてはＲＥＳＴサービス内のリソース取得端点を用いることができるが、ＵＳＩリゾルバを用いる例示的な実施では、ＸＭＬ署名機能がＲＥＳＴインタフェース７１４の後方に、複合リソース文書プロセッサ７１４（ＲＥＳＴインタフェースの実施）の一部分として存在するので、複合リソース文書に直接アクセスする。

ＸＭＬ署名ジェネレータ自体は、次に、参照要素内の変換要素を用いて各々のリソースをさらにフィルタリングする機能を提供する。最終的にリソースのハッシュ（ダイジェスト）が計算される。署名生成中、ハッシュはDigestValue要素内にストアされる。確認中、計算されたハッシュがDigestValueと比較されてリソースが修正されているか（これは署名を無効化することになる）どうかが判断される。署名を生成しているときに、ひとたび各々のリソースのDigestValueが計算され参照要素内にストアされると、SignedInfo要素（上を参照されたい）を含む全体のハッシュが計算され、署名者の秘密鍵を用いて暗号化され、ベース６４でコード化され、SignatureValue要素内にストアされる。署名確認中、DigestValueの値が、確認時におけるリソースの計算されたハッシュとの等値性についてチェックされ、参照要素によって示される各々のリソースに対して等値が実現された場合に、SignedInfoのハッシュが取得され、署名生成時にSignatureValue要素内にストアされ、ベース６４でデコードされ、復号されたハッシュ値との等値性に関して比較される。いずれかのDigestValue又はSignatureValueの確認中に計算されたハッシュとの非等値性により、無効結果が生成される。そうでない場合には、コア確認は成功結果を報告し、アプリケーションには、鍵の有効期限、鍵の取消し、発行者の正当性、及び信頼できる鍵リスト内のメンバーシップなどの２次チェックを自由に行える。

慣行のＵＲＩリゾルバに加えて、本開示の方法は、エンド・ユーザの秘密鍵材料を必要とするSignatureValueの最終的暗号化からDigestValue計算を分離することによって、ＸＭＬ署名ジェネレータの標準的な挙動に過負荷をかける。ＸＭＬ署名ジェネレータは、本開示の方法においてはサーバ上にＲＥＳＴサービス実施７１４の一部分として配置される。本開示の方法は、ダミー秘密鍵を与えてＸＭＬ署名ジェネレータがSignatureValueを生成できるようにする。生成されたSignedInfoはクライアント・マシーンに返される。SignedInfoはハッシュ化され、そのハッシュはユーザの秘密鍵を用いて暗号化される。本開示の方法は、ＲＥＳＴインタフェース７１４内に別個のＲＥＳＴ端点を設けて、最終的な正しいSignatureValueをデジタル署名内に設定できるようにする。署名確認は、署名者の公開鍵を必要とするだけであるので、同様の過負荷を必要としない。

標準的なＸＭＬ署名システムは複数のリソースに署名を与え、複合文書上の基本的なデジタル署名を作成するのに用いられる。しかし、複合文書上のデジタル署名は安全にするためのサブトラクション・フィルター機構を必要とする。

デフォルト設定を用いると、本開示の方法の例示的な実施は、複合文書のためのデジタル署名生成ステップに、指定されたデジタル署名のSignedInfoに関する参照要素のリストを作成する前処理ステップで過負荷をかける。一実施例において、参照リストは以下のように作成することができる。

Ｒに関する参照の事前存在に対する条件付きテスト（上記の５番目のテキスト行）は、デジタル署名マークアップが、複合リソース文書内の特定のリソースについての変換を表明することを可能にする。デジタル署名マークアップによって特に参照されなかったいずれのリソースもデジタル署名マークアップに加えられ、それゆえに全体として署名される。従ってデフォルト設定においては、SignedInfoは、既存の参照及びそれぞれの可能な変換によって指示されるものを除いて全体の複合リソース文書に署名するように拡大される（これは個々のリソースのセキュリティのためのサブトラクション変換であると考えられる）。

例示的な一実施形態において、content.xmlはページ・ナビゲーション及び他の対話を管理することに関連する制御構造体のみを含み、それゆえに例示的なプロトタイプは、content.xmlのリソースに自動的には署名しないが、しかしデジタル署名マークアップの作者はcontent.xmlのリソース又はその任意の部分に、URI=”content.xml”を伴う参照を付け加えることによって署名することができる。デジタル署名マークアップを含むリソースはまた、この例示的な実施形態により参照要素が生成されるリソースから削除される。このリソースは、デジタル署名を生成する一環として変更する必要があり、それ故に、このリソースは特に「包まれた」署名として取り扱う必要がある。

複合リソース文書内の１つのリソースはマニフェスト６１０である。従って、署名後に何れかのリソースが複合リソース文書に加えられ又はそれから削除される場合には、マニフェスト６１０は変更され、その結果マニフェスト６１０を保護する参照のDigestValueは適合しなくなり、これにより無効の署名正当性結果が生成されることになる。実際の生成された署名は、署名時に存在したリソースに、（署名済み）参照要素内で表明された何れかの変換によって許可された以外の変更が何もなされていないことを保証する。参照要素が署名されるので、リソースに対して許可される変更は、署名生成時に存在する参照変換においてデジタル署名マークアップの作者によって表明されたものだけである。

ＸＭＬ署名標準は、作者がオブジェクト要素を用いて署名要素内に特別なコンテンツを含めることを可能にする。例示的な設計には、例示的な実施のデフォルト動作を無効にする機能が用いられる。実施例において、特別に認識されたＸＭＬ属性を持つオブジェクト要素は、SignedInfo内に生成される参照要素のリストから取り去るべきリソースを指示するリソース記述子のリストを宣言する。リソース記述子は以下に示すように、ワイルドカード検索パターンを許可する。

所与のリソース記述子と一致するリソースのサブトラクションを可能にすることにより、本開示の機構は、デジタル署名マークアップの作者が、エンド・ユーザが署名を付けられた後の複合リソース文書に特定のリソースを加えるか又はそれから削除できるようにすることを可能にする。

例示的な設計において、オブジエクトは、SignedInfoの参照要素のリストに自動的に加えられ、デジタル署名により保護される。特別のオブジェクトを含めることにより、本方法はマニフェスト６１０リソースに関する参照にサブトラクション変換を自動的に加えるようになり、デジタル署名が生成されるときにマニフェスト６１０リソースに対して生成されるハッシュ値を無効にせずに、リソース記述子と一致するリソースを付加又は削除することが可能になる。

さらに、例示的な設計は、署名生成前にデジタル署名マークアップに付加的な情報を自動的に書き込み署名する。別のオブジェクト要素が、選択されたSignatureProperties要素内に基本署名メタデータを書き込むために加えられる。書き込まれた特定のメタデータ項目は、典型的には、エンド・ユーザ（署名者）ロケール記述子、署名のローカル日時、及び署名時のＵＴＣデータを含む。このメタデータ・オブジェクトに対する参照は自動的にSignedInfoに加えられてメタデータをデジタル署名によって保護する。例証的な実施形態はまた、KeyInfo要素を、X509SubjectName及びX509Certificate要素を含むX509Dataによって完全にし、KeyInfo要素に対する参照はまたSignedInfoに加えられる。署名メタデータ及びKeyInfoコンテンツは、ＸＭＬ最新電子署名（ＸＡｄＥＳ）によって指定される基本的セキュリティ要件に適合するための補助となる。さらに、例証的な実施形態の設計はＸＭＬ署名に基づくので、例えば、署名に対する認証済みタイムスタンプの付加などの（ＸＡｄＥＳ）要件は本来的にサポートされる。

図９を参照すると、本開示によるマニフェストのコード断片の例が示される。署名確認に関して、例示的実施形態の設計の重要な態様は、ＯＤＦパッケージング上の複合リソース文書書式に基礎を置くものであり、これは複合リソース文書内のリソースのうちの１つが、全てのリソースをリストアップするマニフェストであることを意味する。マニフェスト９００は、複合リソース文書内の全てのリソースのリストを与える。マニフェスト９００内のリソース、例えば、loan1.xhtml、loan2.xhtml及びloan3.xhtmlは、データ・リソースloanInstance.xml内に配置されている情報を収集するための段階的なユーザ・インタフェースを提供する。gen_default.css及びformat.jsのような他のファイルは、複合リソース文書のユーザ・インタフェース外観及びランタイム動作に寄与する。

図１０を参照すると、本開示の種々の実施形態による、複合リソース文書テンプレート内のＸＭＬデータのコード断片の例が示される。この実施例において、ローンを探すユーザのために、文書テンプレートが初めにインスタンス化されて特定のビジネス・プロセスを起動するとき、loanInstance.xmlの初期コンテンツは図１０のコード断片に示すようになる。

コード断片１０００において、<ds:Signature>要素、要素１００２の初期設定は、なにも<Reference>要素を含まない。参照要素が存在しない理由は、本開示の設計がＸＭＬ署名参照リストにサブトラクション・セマンティックを与えているからであり、このことはマニフェスト内にリストアップされている参照は署名生成時に自動的に含まれることになり、確認時に自動的にチェックされることになることを意味する。

図１１を参照すると、本発明の種々の実施形態による、記入された図１０の複合リソース文書内のＸＭＬデータのコード断片の例が示される。ひとたびユーザがloan*.xhtmlを用いてデータ記入体験を完了すると、データはコード断片１１００のように見えることになる。ここでデータ値が以前に空であったテンプレート・フィールド１１０２に入る。

図１２を参照すると、本発明の種々の実施形態による、複合リソース文書署名定義を含むコード断片の例が示される。コード断片１２００は、一組の参照、マニフェスト及びデジタル署名を含む、図９、図１０及び図１１からの情報を用いて完成した文書を表す。

ユーザが、図１０の要素１００２内に準備されている署名動作を呼び出すとき、本開示のプロセスは、loanInstance.xml、例えば要素１２０２に関する同じ文書参照を加えるが、ここで、ＵＲＩ＝“”は生成中の署名がそれ自体から削除されることを可能にし、参照１２０４、参照１２０６及び参照１２０８などのマニフェスト中にリストアップされている全ての他のリソースに関する参照要素を加える。manifest.xmlファイル、マニフェスト１２１０も同様に加えられる。

要素１２１２のデジタル署名値が同様に示される。要素１２１２は、本開示のプロセスが参照要素を生成した後で署名値要素のコンテンツを生成するコア・デジタル署名生成動作の前の複合リソース文書定義のsigned info部分のコンテンツを示す。

署名確認動作は、manifest.xmlに対する参照を確認することによって、望ましくないファイルの付加又は削除が行われていないことを保証する。マニフェストと実際のアーカイブ・コンテンツとの間に不一致があるときは、ＯＤＦパッケージ文書プロセッサは文書をロードしないことが想定されている。代替の実施では、署名確認時における参照及びマニフェスト・パリティに関して簡単にチェックすることができる。

別の実施例において、２人又はそれ以上の交付金申請者がそれぞれの個人情報を記入し、履歴書のコピーを添付し、文書にデジタル署名し、完成のためにワークフロー・システムに文書を次の申込者に送らせることが予想される交付金申請が示される。第１のユーザにより作成されるデジタル署名は、他の申請者に対応するデータ・ファイル・サブツリー及び他の申請者により作成された添付ファイルを取り去る必要がある。２つの前述の例外を除いて、ユーザ・インタフェース、ユーザ体験、又は署名するユーザのデータ若しくは添付書類を記述する複合リソース文書内の全ての他のファイル、それゆえに全てが署名されなければならない。

ファイルを添付する任意の機能は、より多くのＸＨＴＭＬページ、ＣＳＳファイル、ＪＳファイルなどを複合リソース文書内に配置することを可能にする。さらに、content.xmlファイルは“which xhtml page should beshown first”のような制御構造部を含む故にcontent.xmlファイルが削除されるので、いずれかの新しく加えられたファイルは、第１の署名者が署名したものに関して誤った要求をし得る新しい別のユーザ体験を加える可能性がある。誤った要求を行う可能性は、ＸＭＬ署名の参照リストのレベルに至るまでサブトラクション・フィルタリングする方針をとることによって防止される。

図１３を参照すると、本開示の種々の実施形態による、参照リストの生成を示す複合リソース文書署名定義のコード断片の例が示される。本開示の種々の実施形態により提供されるサブトラクション・フィルタリングのゼロの場合は、従来技術と比較して重要な動作変化である。デフォルトにより、ＸＭＬ署名はアプリケーション設計者が参照要素を用いて署名されるべきリソースをリストアップすることを要求する。複合リソース文書において、アプリケーション設計者はテンプレートを作成し、典型的にはデジタル署名機能を含めるように決定する。しかし、実行時において、エンド・ユーザは作成されたテンプレートのインスタンスを修正してビジネス・プロセスを推進する必要がある。予想されるエンド・ユーザの動作は新しいファイルを複合リソース文書に添付する。従って、署名生成の実行時に署名する必要のあるリソースの全てをアプリケーション設計時に参照要素としてリストアップすることは不可能である。その代りに、複合リソース文書プロセッサの拡張署名ジェネレータが、デジタル署名が生成される時に参照要素のリストを作成する必要がある。

従って、複合リソース文書内のマニフェストを含む各々のリソースに関する参照要素ジェネレータを生成するステップで署名動作を拡張することが重要である。これは、署名から複合リソース文書内のゼロ個のリソースを取り去る場合である。図１０、図１１及び図１２のコード断片は、ゼロ個のファイルが取り去られるこの場合の例を示した。しかし、テキストだけは、署名生成プロセスの直前及び完全署名生成プロセスの直後のマークアップを示した。以前の例は、参照リストを生成するデジタル署名拡張後、及びコア・デジタル署名生成の前の時点での即時のマークアップを示さなかった。図１３は付加的なマークアップの実例をコード断片１３００として与える。要素１３０２は署名要素を定義し、要素１３０４は、本開示の方法の種々の実施形態により自動的に生成される参照要素の１つを定義する。

要素１３０４を含む一組の参照要素がSignedInfo内に生成され、そのおのおのは空のDigestValue要素を有する。同様にSignatureValueも空である。前に説明した署名拡張の後、コア署名生成の前に、例えば、署名時間及び場所などの基本署名プロパティ並びに署名に対する別の参照を含むようにds:Objectを加えるステップを含むさらに別のステップを行うことができる。別の例においては、ds:KeyInfoを加えてデジタル署名証明書及び署名者のサブジェクト名をストアすることになる。同様にKeyInfoに署名するのに、さらに別の参照を自動的に加えることができる。最終的にコア・デジタル署名ジェネレータが呼び出されて、DigestValueコンテンツ及びSignatureValueコンテンツが生成される。拡張署名生成の最終結果の一例を図１２のコード断片１２００のマークアップ例の内部に示す

図１４を参照すると、本開示に種々の実施形態による、複数の署名者を有し、変換されるリソースを指定する手段を示す複合リソース文書定義のコード断片の例が示される。図１３に関して上で説明したように、ＸＭＬ署名参照リストを、デフォルトではゼロ個の要素を取り去るサブトラクション・フィルターとして扱う際の値がある。例えば、参照リストは、事前にアプリケーションの設計者（複合リソース文書のテンプレートの作成者）によってではなく、署名動作の拡張として自動的に生成される。従って、本開示の機能は、文書が複合リソース文書であるとき、特にエンド・ユーザが、元の文書テンプレート内で利用できるよりも多くのリソースを文書に加えることができるとき、文書全体に署名する方法の実施を可能にする。

さらに、本開示の方法は、参照要素が既に与えられているものには何にでも自動的に生成された参照を加え、アプリケーション設計者、即ち複合リソース文書のテンプレートの作成者が、本開示の方法により生成されるものに加えて署名情報を選ぶことができるようにする。例えば、アプリケーション論理は、署名内のds:Object内に情報を生成することができ、署名は、ds:Objectに署名するに関連して設定することができる。

最も重要なことには、本開示のプロセスは、自動的に生成された参照要素をSignedInfo内の参照要素リストに併合し、各々のリソースがSignedInfo内に予め存在する参照を未だ有さない場合にだけ、そのリソースに関する参照を効果的に加える。本開示の方法の実施が参照を加えるとき、参照はリソース全体への署名をもたらすので、本開示の方法は、アプリケーション設計者による特定のリソースに適用された任意の変換、又は複合リソース文書プロセッサの代替の態様に対応する。

一実施例において、前に説明した「ローン」申請が署名者−連署者シナリオを満たすように設計される。loanInstance.xmlファイル内のデータがコード断片１４００内に表される。第１の署名１４０２並びに第２の署名１４０４が与えられる。第２の署名者の署名１４０４は以前の実施例の署名と同一の形態であるが、第１の署名１４０２は既に、それ自体（包まれた署名）だけでなく第２の署名者の署名もまた取り去るURI=””に対する参照を含み、第２の署名は第１の署名が付けられた後で生成される必要がある。従って、本開示の方法が第１の署名１４０２に関する参照要素を生成するとき、URI=””参照は、既に存在するために生成されない。

図１５を参照すると、本開示の種々の実施形態による、参照生成を制御するためのパターンを指定するコード断片の一例が示される。前の例のコード断片における構成要素は、サブトラクション・フィルターの第１のステップを記述し、そのステップにおいては、明示的にリストアップされたものだけに署名するのではなく、利用可能な全てのものに署名するデフォルトのコンテキストが用いられる。複合リソース文書レベルで十分に機能付与されたサブトラクション・フィルタリングにより、アプリケーション設計者は、本開示の方法を用いるときにどの付加的参照が生成されてはならないかを、パターンによって指定することができる。

以前の実施例において、ワイルドカード正規表現シンタックスが用いられたが、XPath表現を用いることもできる。この実施例においては、署名が付けられて、複合リソース文書内へのファイルのその後の付加が、attchmentsディレクトリのような特定のディレクトリにおいてのみ可能になる。コード断片１５００のマークアップは、要素１５０２が、リソース・サブトラクションの明示的なパターンを指定する一例を与え、そのパターンは本実施例においてはユーザがリソース添付ファイルの付加又は削除を許可された「添付」サブディレクトリ内の全てのリソースに適合する。

図１６を参照すると、本開示の種々の実施形態による、生成署名参照リストから特定のリソースをフィルタリングし、それにより、図１５のオブジェクトを用いて特定のリソースに関する参照生成を抑制するコード断片の一例が示される。本開示の方法は、図１５のコード断片１５０２内で定義されたオブジェクトに応答して、参照を特別のds:Objectに加え、その結果署名がフィルターに署名し、manifest.xml参照を修正して記述子に適合するファイル・エントリ要素を取り去り、与えられた記述子に適合するリソースに関する参照の生成を抑制する。

コード断片１６００を用いる別の実施例は、要素１６０２のリソース記述子によって、styleサブディレクトリからファイルをフィルタリングする。

生成されたURI=””参照要素は、要素１６０４、即ち署名のサブトラクション変換及びリソース記述子オブジェクトに関するユニオンを収容する。style/で始まるＵＲＩ属性を有する参照要素は、リスト内に現れない。manifest.xmlに対する参照要素１６０６は、記述子に適合するファイル・エントリ要素を削除するサブトラクション・フィルターを収容する。

図１７を参照すると、本開示による、複合リソースのためのデジタル署名を生成する方法のフローチャートが示される。方法１７００は、図５の複合文書システム５００を用いる方法の一例である。

方法１７００は開始（ステップ１７０２）して、少なくとも１つのリソースを含む複合リソース文書を受け取る（ステップ１７０４）。方法１７００は、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得する（ステップ１７０６）。方法１７００は、最新のマニフェスト・リソース内のリソースのリストから取り去るべきゼロ、１つ又は複数のリソースを指示して、署名されるべき識別されたリソースの生成署名参照リストを作成する（ステップ１７０８）。次に署名されるリソースを参照し、除去されるリソースを含まないことを確認する。例示的な一実施形態において、生成署名参照リストを生成することは、オブジェクトを示す参照を含めることをさらに含み、ここでオブジェクトは、参照リストを作成するためのリソース・リストから取り去られるリソースのリストを示すリソース記述のリストを宣言する。

方法１７００は生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成し、署名ハッシュ・トークンを形成する（ステップ１７１０）。例示的な実施形態において、ハッシュ・トークンの生成は、参照リスト内の１つ又は複数のリソースを選択して、選択された変換済みリソースを形成し、参照リストからの残りのリソースは未変換リソースを形成するようにすることと、選択された変換済みリソースと組み合せた未変換リソースを用いて、デジタル署名変換を選択された変換済みリソースに適用してハッシュ・トークンを生成することとを含む。特に、現行のＷ３ＣＸＭＬ署名標準に適合する例示的な実施形態は、そのＵＲＩ属性が参照リスト内のリソースを指示する既存の参照要素に関する署名SignedInfo要素を分析し、そしてこの例示的な実施形態は、既存の参照要素の何れとも対応しない参照リスト・リソースに関する参照要素のみを生成する。従って、各々の既存の参照要素は、変換要素を含む可能性があり、そうでなければステップ１７０８においてリソースに対して生成されることになる参照要素を無効にし、そしてこの方法から結果として得られる参照要素のリストがステップ１７１０において署名ハッシュ・トークンを生成するのに用いられる。

例示的な実施形態において、署名ハッシュ・トークンを生成することは、ＵＲＩリゾルバを用いて参照リスト内の１つ又は複数のリソースのコンテンツを取得することと、参照リスト内の少なくとも１つのリソースのダイジェスト値を用いて署名ハッシュ・トークンを生成することとのうちの少なくとも１つをさらに含むことができる。特に、現行のＷ３ＣＸＭＬ署名標準に適合する例示的な実施形態においては、署名値ハッシュ・トークンは、参照リスト内の全てのリソースの実際のコンテンツではなく、ダイジェスト値に基づいて計算される。

方法１７００は、秘密鍵を用いて署名ハッシュ・トークンを暗号化してデジタル署名を作成し（ステップ１７１２）、その後終了する（ステップ１７１４）。

図１８を参照すると、本開示による、図１７の複合リソースに関するデジタル署名を確認する方法のフローチャートが示される。方法１８００は、図５の複合文書システムを用いる方法の一実施例である。

方法１８００は開始（ステップ１８０２）して、デジタル署名を有する１つ又は複数のリソースを含む複合リソース文書を受け取る（ステップ１８０４）。方法１８００は、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得する（ステップ１８０６）。

方法１８００は、デジタル署名内の生成署名参照リスト内の識別されたリソースを用いて、生成ハッシュ・トークンを形成する（ステップ１８０８）。方法１８００は、取得した復号鍵を用いてデジタル署名内に含まれる暗号化ハッシュ・トークンを復号し、署名ハッシュ・トークンを形成する（ステップ１８１０）。生成ハッシュ・トークンと署名ハッシュ・トークンとの少なくとも比較に応答して、方法１８００は署名正当性結果を生成し（ステップ１８１２）、その後終了する（ステップ１８１４）。

図１９を参照すると、本開示による、図１８の署名正当性結果を生成する方法のフローチャートが示される。方法１９００は、生成リソース・ハッシュ・トークンと、ステップ１８１０において復号されたデジタル署名ハッシュ・トークンとを比較し、そして図１８のステップ１８１２において署名正当性結果を生成する方法の一実施例である。

方法１９００は開始（ステップ１９０２）して、生成ハッシュ・トークンが署名ハッシュ・トークンに等しいかどうかを判断する（１９０４）。生成ハッシュ・トークンが署名ハッシュ・トークンに等しいと判断されたとき、「イエス」結果が得られる。生成ハッシュ・トークンが復号された署名ハッシュ・トークンに等しくないと判断されたときは、「ノー」結果が得られる。「ノー」結果が得られるとき、方法１９００は無効の署名正当性結果を生成し（ステップ１９０６）、その後終了する（ステップ１９０８）。判断は、最新のマニフェスト・リソースからのリソースのリストが、デジタル署名内の生成署名参照リスト内の識別されたリソースのリストに等しくないかどうか判断することをさらに含む。例示的な実施形態において、最新のマニフェスト・リソースからのリソースのリストは、生成署名参照リストを形成するときに取り去られるリソースのリストを指示するリソース記述のリストを宣言するオブジェクトによって示されるリソースが差し引かれた最新のマニフェスト・リソースからのリソースのリストを含む。

ステップ１９０４において「イエス」の結果が得られるとき、方法１９００は復号鍵が有効かどうか判断する（ステップ１９１０）。復号鍵が有効であるとの判断がなされるとき、「イエス」の結果が得られる。復号鍵が無効であるとの判断がなされるときは「ノー」の結果が得られる。復号鍵が有効であるかどうかの判断は、鍵有効期限テスト、鍵取消しテスト、鍵発行者信用証明テスト、及び信用鍵リスト・テストを含む、ゼロ、１つ又は複数のテストを用いた復号鍵の正当性をテストすることを含む。復号鍵正当性テストの失敗に応答して、無効の署名正当性結果が生成される。

ステップ１９１０において「イエス」が得られるとき、方法１９００は、生成ハッシュ・トークンが署名ハッシュ・トークンに等しいこと及び復号鍵正当性テストに失敗がないことの全体的判断に応答して有効の署名正当性結果を生成し（ステップ１９１２）、その後終了する（ステップ１９０８）。この判断は、最新のマニフェスト・リソースからのリソースのリストが、デジタル署名内の生成署名参照リスト内の識別されたリソースのリストに等しいかどうか判断することをさらに含む。例示的な実施形態において、最新のマニフェスト・リソースからのリソースのリストは、生成署名参照リストを形成するときに取り去られるリソースのリストを指示するリソース記述のリストを宣言するオブジェクトによって示されるリソースが差し引かれた最新のマニフェスト・リソースからのリソースのリストを含む。ステップ１９１０において「ノー」の結果が得られるとき、方法１９００は無効の署名正当性結果を生成し（ステップ１９０６）、その後前と同様に終了する（ステップ１９０８）。

従って、一実施形態において、複合リソース文書のためのデジタル署名を作成するコンピュータ実施の方法であって、複数のリソースにデジタル署名するための以前の解決策には無かったリソース・サブトラクション・フィルター機能を設けることによって複合リソース文書のためのデジタル署名に高度のセキュリティをもたらす方法を提示する。本開示のコンピュータ実施の方法は、少なくとも１つのリソースを含む複合リソース文書を受け取り、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得し、最新のマニフェスト・リソース内のリソースのリストから取り去るべきゼロ、１つ又は複数のリソースを指示して、署名されるべき識別されたリソースの生成署名参照リストを生成し、生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成して署名ハッシュ・トークンを形成し、秘密鍵を用いて署名ハッシュ・トークンを暗号化する。

ハッシュ・トークンを生成することは、ゼロ、１つ又は複数のリソースに関して以前に指定された参照要素を用いて参照リストを形成することをさらに含むことができ、それにより、以前に指定された参照要素によって指示されるリソースの処理にデジタル署名変換を加える機能が可能になる。

コンピュータ実施の方法の例証的な実施形態は、複合リソース文書のためのデジタル署名を確認する機能をさらに与える。コンピュータ実施の方法はさらに、デジタル署名を有する１つ又は複数のリソースを含む複合リソース文書を受け取り、複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得し、デジタル署名内の生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成して生成ハッシュ・トークンを形成し、取得した復号鍵を用いてデジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成し、生成ハッシュ・トークンと署名ハッシュ・トークンとの少なくとも比較に応答して署名正当性結果を生成する。

従って、例証的な実施形態は、圧縮アーカイブを用いた、一つの文書内の個々のリソースがデータ記録、添付ファイル、ページ及び付加的な要素を表す、複合リソース文書を開示する。複合リソース文書は単一文書アーキテクチャの利点を保持すると同時に、ページ毎のユーザ体験を与えるのに必要な要素を取得するための全体的アーカイブのＸＭＬ構文解析を実行する必要性をなくす。ワールドワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）ＸＭＬ署名によって提供される、リソースに対する複数参照のサポートにより、Ｗ３ＣＸＭＬ署名を複合リソース文書と共に用いてデジタル署名機能を実施することが可能になる。しかし、サブトラクション・フィルタリング機能は単一のＸＭＬリソースの処理に限定されない。同時に署名されるべき複数リソースのより高レベルの定義に対して、現在Ｗ３ＣＸＭＬ署名標準は、特に署名SignedInfo要素内の参照要素のリストから得られるリソースのリストをリストアップする機能のみを提供する。

既知の従来技術の解決策は通常、対話型文書のデジタル署名に関して、サブトラクション・フィルタリングが可能であるが性能が不十分な単一ＸＭＬファイルとして文書を表すこと、及びより性能が良いがリソース・レベルのサブトラクション・フィルタリングが可能でない複合文書として文書を表すこと、を含む欠陥を有する。

本開示の方法は、複合リソース文書の概念をサブトラクション・フィルタリングと組み合せて、協同ビジネス・プロセス内の複合リソース文書について同じレベルのデジタル署名セキュリティを達成すると同時に、また複合リソース文書によって提供される性能に著しい進歩をもたらす。

図中のフローチャート及びブロック図は、本発明の種々の実施形態によるシステム、方法、及びコンピュータ・プログラムの可能な実施のアーキテクチャ、機能性、及び動作を示す。この点において、フローチャート又はブロック図内の各々のブロックは、モジュール、セグメント、又はコードの部分を表すことができ、これは指定された論理機能を実施する１つ又は複数の命令を含む。また、幾つかの代替的実施において、ブロック内に示された機能は図に示したのとは異なる順序で行われ得ることにも留意されたい。例えば、連続して示した２つのブロックは、実際には、実質的に同時に実行することができ、又はブロックは、関与する機能に応じて、場合により逆の順序で実行することができる。また、ブロック図及び／又はフローチャートの各ブロック、並びに、ブロック図及び／又はフローチャート内のブロックの組合せは、指定された機能及び動作を実行する専用ハードウェアをベースとするシステム、又は専用ハードウェア及びコンピュータ命令の組合せによって実施することができることにも留意されたい。

添付の特許請求の範囲内の全てのミーンズ又はステップ・プラス・ファンクション要素の対応する構造体、材料、動作、及び等価物は、具体的に特許請求された他の特許請求要素と組み合せて機能を実施するための任意の構造体、材料、又は動作を含むことが意図されている。本発明の説明は、例証及び説明の目的で提示したものであり、網羅的であること又は本発明を開示した形態に限定することを意図したものではない。当業者には、本発明の範囲及び趣旨から逸脱することのない多くの修正及び変形が明白となるであろう。実施形態は、本発明の原理及び実際的用途を最も良く説明し、当業者が企図する特定の用途に適した種々の修正を有する種々の実施形態に関して本発明を理解することができるように選び説明した。

本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はハードウェア要素とソフトウェア要素の両方を含む実施形態の形をとることができる。好ましい実施形態において、本発明は、それらに限定されないが、ファームウェア、常駐ソフトウェア、マイクロコード、及び当業者が認識することができる他のソフトウェア媒体、を含むソフトウェアにおいて実施される。

本発明は完全に機能するデータ処理システムの状況で説明したが、当業者であれば、本発明の方法は命令のコンピュータ可読媒体の形態及び種々の形態で配布することができること、及び、本発明は配布を実施するのに実際に用いられる特定のタイプの信号支持媒体に関係せずに等しく適用できることに留意することが重要である。コンピュータ可読媒体の例としては、書き込み可能型の媒体、例えばフロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤＲＯＭ、ＤＶＤ−ＲＯＭ、並びに、伝送型媒体、例えば、デジタル及びアナログ通信リンク、例えば無線周波数及び光波伝送などの伝送形式を用いる有線又は無線通信リンクが挙げられる。コンピュータ可読媒体は、特定のデータ処理システム内で実際に用いるためにデコードされるコード化フォーマットの形態を取ることができる。

プログラム・コードをストアし及び／又は実行するのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接又は間接に結合された少なくとも１つのプロセッサを含むことになる。メモリ要素には、プログラム・コードの実際の実行中に用いられるローカル・メモリ、大容量記憶装置、及び、実行中にコードを大容量記憶装置から読み出す必要のある回数を減らすための、少なくとも幾つかのプログラム・コードの一時的記憶を提供するキャッシュ・メモリを含めることができる。

入力／出力又はＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイスなどを含むが、それらに限定されない）を、直接又は介在するＩ／Ｏコントローラを介してシステムに結合することができる。

またネットワーク・アダプタをシステムに結合して、介在するプライベート又はパブリック・ネットワークにより、データ処理システムが他のデータ処理システム又は遠隔プリンタ又は記憶装置に結合できるようにすることができる。モデム、ケーブル・モデム、及びイーサネット・カードは現在利用できるタイプのネットワーク・アダプタのうちの一部に過ぎない。

本発明の説明は、例示及び説明の目的で提示されたものであり、網羅的であること又は開示された形式の発明に限定することを意図するものではない。当業者であれば、多くの修正及び変形が明らかであろう。実施形態は、本発明の原理及び実際の適用を最も良く説明するように、及び、当業者以外であっても、考えられる特定の用途に適合するような様々な実施形態について本発明を理解できるように、選択され、説明されたものである。

１００：ネットワーク・データ処理システム
１０２：ネットワーク
１０４、１０６：サーバ
１０８：記憶装置
１１０、１１２、１１４：クライアント
２００：データ処理システム
２０２：通信ファブリック
２０４：プロセッサ・ユニット
２０６：メモリ
２０８：永続記憶装置
２１０：通信ユニット
２１２：入力／出力（Ｉ／Ｏ）ユニット
２１４：ディスプレイ
２１６：記憶デバイス
２１８：プログラム・コード
２２０：コンピュータ可読媒体
２２２：コンピュータ・プログラム
３００：ビジネス・プロセ
３０２、３０４：コンテンツ・リポジトリ
３０６：契約テンプレート
３０８：提案契約
３１０：履行契約
３１２、３１４：協力者
３１６：認可者
３１８：インターネット
３２０：チェック・クレジット・サービス
３２２：電子資金振替サービス
４００：論理層／対話型文書
４０２：ヒューマン・インタフェース
４０４：ビジネス論理及び動的確認
４０６：データ・アクセス及び確認
４０８：データ・インスタンス
４１０：セキュリティ、監査能力及び相互運用
４１２：マルチページＸＦＤＬ
４１４：XForms論理ユーザ・インタフェース
４１６：XFormsモデル
４１８：ＸＭＬスキーマ
４２０：ＸＭＬ及びＸＭＬ署名
５００：複合文書システム
５０２：拡張署名ジェネレータ
５０４：拡張署名メタデータ
５０６：マニフェスト・リソース
５０８：ＵＲＩリゾルバ
５１０：オブジェクト要素
５１２：複合文書構造体
６００、６０２、６０４、６０６：構造体
６０８：ＭＩＭＥ型
６１０：マニフェスト
７００：関係
７０２：ビジネス・プロセス
７０４：アプリケーション・クライアント層
７０６：アプリケーション・サーバ層
７０８：文書対話層
７１０：複合ウェブ・リソース層
７１２：論理的に解凍された複合リソース文書
７１４：ＲＥＳＴインタフェース
７１６：サーバ
７１８：クライアント
８００：論理関係
８０２：複合リソース文書
８０４：ロゴ
８０６、８０８：フォーム・ページ
８１０，８１２：データ・インスタンス
８１４：ＸＭＬ署名
９００、１２１０：マニフェスト
１０００、１１００、１２００、１３００、１４００、１５００、１６００：コード断片
１００２、１２０２、１２１２、１３０２，１３０４、１５０２、１６０２、１６０４、１６０６：要素
１１０２：テンプレート・フィールド
１２０４、１２０６、１２０８：参照
１４０２：第１の署名
１４０４：第２の署名

Claims (14)

1. 複合リソース文書のためのデジタル署名を確認するコンピュータ実施の方法であって、
   デジタル署名を有する前記複合リソース文書を受け取るステップであって、前記複合リソース文書は１つ又は複数のリソースを含む、前記受け取るステップと、
   前記複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得するステップと、
   前記デジタル署名内の生成署名参照リスト内の識別された前記リソースを用いてハッシュ・トークンを生成して生成ハッシュ・トークンを形成するステップと、
   取得した復号鍵を用いて、前記デジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成するステップと、
   前記生成ハッシュ・トークンと前記署名ハッシュ・トークンとの少なくとも比較に応答して、署名正当性結果を生成するステップであって、
   前記生成ハッシュ・トークンが前記署名ハッシュ・トークンと等しくないとの判断に応答して無効の署名正当性結果を生成するステップであって、前記判断は、前記最新のマニフェスト・リソースからのリソースのリストが前記デジタル署名内の前記生成署名参照リスト内の識別されたリソースのリストに等しくないかどうかの判断をさらに含む、前記生成するステップと、
   鍵有効期限テスト、鍵取消しテスト、鍵発行者信用証明テスト及び信用鍵リスト・テストを含むゼロ、１つ又は複数のテストを用いて取得された復号鍵の正当性をテストするステップと
   を含む、前記署名正当性結果を生成するステップと
   を含む、前記方法。
2. 前記署名正当性結果を生成するステップは、
   復号鍵正当性テストの失敗に応答して、無効の署名正当性結果を生成するステップと、
   前記生成ハッシュ・トークンが前記署名ハッシュ・トークンに等しく、且つ復号鍵正当性テストに失敗がないとの判断に応答して、有効の署名正当性結果を生成するステップであって、前記判断は、前記最新のマニフェスト・リソースからのリソースのリストが前記デジタル署名内の生成署名参照リスト内の識別されたリソースのリストに等しいかどうかの判断をさらに含む、前記有効の署名正当性結果を生成するステップと
   を含む、請求項１に記載の方法。
3. 前記生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成するステップは、
   ＵＲＩリゾルバを用いて前記生成署名参照リスト内の識別された１つ又は複数のリソースのコンテンツを取得するステップ
   をさらに含む、請求項１又は２に記載の方法。
4. 前記生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成するステップは、
   前記生成署名参照リスト内の識別された少なくとも１つのリソースに対して少なくとも１回のデジタル署名変換を実施するステップ
   をさらに含む、請求項１又は２に記載の方法。
5. 前記生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成するステップは、
   前記生成署名参照リスト内の識別された少なくとも１つのリソースのダイジェスト値を用いて前記ハッシュ・トークンを生成するステップ
   をさらに含む、請求項１又は２に記載の方法。
6. 前記複合リソース文書は、複数のリスースを含む、請求項１〜５のいずれか一項に記載の方法。
7. 複合リソース文書のためのデジタル署名を確認するコンピュータ実施の方法であって、
   デジタル署名を有する前記複合リソース文書を受け取るステップであって、前記複合リソース文書は１つ又は複数のリソースを含む、前記受け取るステップと、
   前記複合リソース文書内の全てのリソースをリストアップする最新のマニフェスト・リソースを取得するステップと、
   前記デジタル署名内の生成署名参照リスト内の識別された前記リソースを用いてハッシュ・トークンを生成して生成ハッシュ・トークンを形成するステップと、
   取得した復号鍵を用いて、前記デジタル署名内に含まれる暗号化ハッシュ・トークンを復号して署名ハッシュ・トークンを形成するステップと、
   前記生成ハッシュ・トークンと前記署名ハッシュ・トークンとの少なくとも比較に応答して、署名正当性結果を生成するステップであって、
   前記生成ハッシュ・トークンが前記署名ハッシュ・トークンと等しくないとの判断に応答して無効の署名正当性結果を生成するステップであって、前記判断は、前記最新のマニフェスト・リソースからのリソースのリストが前記デジタル署名内の前記生成署名参照リスト内の識別されたリソースのリストに等しくないかどうかの判断をさらに含む、前記生成するステップと、
   復号鍵正当性テストの失敗に応答して、無効の署名正当性結果を生成するステップと、
   前記生成ハッシュ・トークンが前記署名ハッシュ・トークンに等しく、且つ復号鍵正当性テストに失敗がないとの判断に応答して、有効の署名正当性結果を生成するステップであって、前記判断は、前記最新のマニフェスト・リソースからのリソースのリストが前記デジタル署名内の生成署名参照リスト内の識別されたリソースのリストに等しいかどうかの判断をさらに含む、前記有効の署名正当性結果を生成するステップと
   を含む、前記署名正当性結果を生成するステップと
   を含む、前記方法。
8. 前記署名正当性結果を生成するステップは、
   鍵有効期限テスト、鍵取消しテスト、鍵発行者信用証明テスト及び信用鍵リスト・テストを含むゼロ、１つ又は複数のテストを用いて取得された復号鍵の正当性をテストするステップ
   を含む、請求項７に記載の方法。
9. 前記生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成するステップは、
   ＵＲＩリゾルバを用いて前記生成署名参照リスト内の識別された１つ又は複数のリソースのコンテンツを取得するステップ
   をさらに含む、請求項７又は８に記載の方法。
10. 前記生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成するステップは、
    前記生成署名参照リスト内の識別された少なくとも１つのリソースに対して少なくとも１回のデジタル署名変換を実施するステップ
    をさらに含む、請求項７又は８に記載の方法。
11. 前記生成署名参照リスト内の識別されたリソースを用いてハッシュ・トークンを生成するステップは、
    前記生成署名参照リスト内の識別された少なくとも１つのリソースのダイジェスト値を用いて前記ハッシュ・トークンを生成するステップ
    をさらに含む、請求項７又は８に記載の方法。
12. 前記複合リソース文書は、複数のリスースを含む、請求項７〜１１のいずれか一項に記載の方法。
13. 複合リソース文書のためのデジタル署名を確認するための装置であって、
    通信ファブリックと、
    前記通信ファブリックに接続され、コンピュータ実行可能プログラム・コードを含むメモリと、
    前記通信ファブリックに接続された通信ユニットと、
    前記通信ファブリックに接続された入力／出力ユニットと、
    前記通信ファブリックに接続されたディスプレイと、
    前記通信ファブリックに接続されたプロセッサ・ユニットと
    を備えており、
    前記プロセッサ・ユニットは、前記コンピュータ実行可能プログラム・コードを実行して前記装置に対して、
    請求項１〜１２のいずれか一項に記載の方法の各ステップに記載の方法を実行するように命令する、前記装置。
14. 複合リソース文書のためのデジタル署名を確認するためのコンピュータ・プログラムであって、コンピュータに、請求項１〜１２のいずれか一項に記載の方法の各ステップを実行させる、前記コンピュータ・プログラム。

Images