JP2002536735A - 電子取引システムのための信頼マネージャ - Google Patents

Abstract

(57)【要約】 電子取引システムが、このシステムに対する記名者の属性の記名者保証を表す電子信号を発行する機関と、この発行機関によって発行された記名者保証に関する情報を表す電子信号を入手し、信頼パーティに対する署名済み保証申し出を表す電子信号を発行し、署名済み保証申し出が少なくとも記名者属性保証に基づく信頼サーバを含み、信頼サーバが保証に対する要求を行うことが信頼パーティに認可されている場合にのみ、署名済み保証申し出を提供する。

Description

【発明の詳細な説明】

【０００１】 （１．発明の分野） 本発明は、電子取引の分野に関し、より詳細には、電子取引システムでの信頼
をサポートするサービスに関する。

【０００２】 （２．背景） 電子的にビジネス取引を実現するためのシステムは、ますます普及しており、
これは、部分的には、インターネットなどのグローバルコンピュータネットワー
クの到来のためであり、また部分的には、そうした商取引のセキュリティを強化
する公開キー暗号の発達および成熟のためである。

【０００３】 従来の方法によりセキュアな電子商取引を利用するためには、各ユーザは、関
連する一対のキー、すなわち秘密キー（そのユーザによって秘密に保たれる）と
公開キー（これは、対応する秘密キーの秘密性を危うくすることなく、だれによ
っても知られ得る）。特定の公開キーを使用して、アルゴリズムは、対応する秘
密キーが所与のメッセージに署名しまたはこれを認証するのに使用されたか否か
を判定することができる。

【０００４】 公開キーは、単に値（一般的に、数）であり、それがそのメッセージを認証す
る人を含めて、だれとも固有の関連を有さない。デジタル署名の広範な、商業上
の使用は、識別される人々に公開キーを関連付ける、信頼できる情報を必要とす
る。それらの識別される人々のメッセージが、次に、そのキーを使用して認証さ
れ得る。

【０００５】 デジタル署名証明書（ときとして、公開キー証明書、または単に証明書とも呼
ばれる）が、こうした必要性を満たす。これらの証明書は、一般的に、証明機関
（ＣＡ）として知られる信頼されたサードパーティによって発行され、このサー
ドパーティが、（１）発行を行う証明機関がその証明書の主を識別したことを認
証し（しばしば、証明実施ステートメントで画定される指定により）、（２）ま
た指定の公開キー（証明書内の）が証明書の主によって保持される秘密キーに対
応することを証明する。

【０００６】 証明書の真正性が後に検証され得ることを確実にするため、証明機関は、証明
書を発行するとき、それにデジタル方式で署名する。発行を行う証明機関のデジ
タル署名は、それ自体、公開キー（証明機関の公開キー）に対する参照によって
検証することができ、この公開キーは、その証明機関と、第１証明機関に対する
第２証明機関によって発行された別の証明書内で関連付けられている。その別の
証明機関のデジタル署名は、さらにべつの証明書内でリストされた公開キーによ
って証明可能であり、これが、以下同様に、証明書の連鎖を辿って、その公開キ
ーが広範かつ信頼できるように配布されているいわゆるルート証明機関または主
証明機関に達するまで続く。取引で頼りにされる証明書の真正性を最大限に保証
するため、それを信頼するパーティは、従来の方法を使用して、連鎖内の各証明
書を検証しなければならない。

【０００７】 ほとんどの法律制度は、発行を行う機関と、記名者、すなわち証明書内で、そ
の証明書内にリストされる公開キーに対応する秘密キーの保持者として識別され
た人との間の契約に準拠する陳述、認定、または締結として、証明書を扱う。記
名者以外の人々も、その証明書を信頼することが可能である。それらの信頼パー
ティ（ｒｅｌｙｉｎｇ ｐａｒｔｙ）に対する証明機関の責務が、陳述または不
正な陳述に適用される規則、信頼パーティを証明機関と記名者の間での契約のサ
ードパーティ受益者として扱う規則、デジタル署名に適用される定款、または前
述ことのすべての混合、ならびに、場合によっては、追加の法的原則から生じ得
る。

【０００８】 しばしば、証明書を信頼することのパーティの権利は、限られている。例えば
、虚偽表示に適用される法律では、信頼は、一般的に、合理的であることが必要
とされる。さらに、ある種の証明書に対する信頼は、それ自体で、信頼のおけな
いものであると定められている。明白な線が、ある種類の明らかに信頼のおけな
い証明書を他のすべての証明書から隔てており、信頼パーティは、その証明書の
欠陥に関して、発行を行う証明機関または記名者に対する償還請求なしに、自身
で危険を覚悟してそれを信頼する。それ自体で信頼のおけない証明書は、従来、
無効なものと呼ばれ、下記のどの証明書も含み得る。

【０００９】 （１）失効したもの（すなわち、信頼の時点が、その満期としてその証明書内
に定められた日付よりも後であるもの） （２）取り消されたもの（すなわち、その証明書を発行した証明機関によって
永久に無効であると宣言されたもの） （３）信頼の時点で延期されているもの（すなわち、その証明書を発行した証
明機関によって一時的に無効であると宣言されたもの）

【００１０】 さらに、その記名者によって受理されていない、または証明機関によって発行
されていない証明書は、発効したとは考えられるべきものではなく、恐らく、漠
然と、無効であると考えられる。

【００１１】 証明書を延期および／または取り消すことは、証明機関または記名者による誤
りの結果を最小限に抑える重要な手段である。適用される法律規則に応じて、証
明機関は、証明書を取り消すことによって、その証明書内の不正確さに起因する
さらなる損失を回避することができる。記名者は、証明書を取り消して、漏洩し
た、すなわち、紛失した、または盗まれた秘密キーを使用して作成された偽造デ
ジタル署名に対する信頼を防止することができる。取り消しによって無効になる
証明書は、１つの規格、例えば、ＩＴＵ Ｘ．５０９によれば、一般的に、証明
書取り消しリスト（ＣＲＬ）内にリストされる。延期、つまり一時的に無効にす
ることは、ＩＴＵ Ｘ．５０９では考慮されておらず、ＣＲＬ内に含めることも
、含めないことも可能である。その経時のために無効になる証明書は、ＣＲＬ内
にリストする必要がない。というのは、各証明書が、それ自体の失効の日付を含
むからである。

【００１２】 実際、従来のＣＲＬベースのシステムは、次のように機能する。記名者が、検
証可能なデジタル署名を作成できるには、まず、記名者は、証明機関がその記名
者をその記名者の公開キーで識別する証明書を発行するように手配しなければな
らない。記名者は、発行された証明書を受け取り、それを承諾して、次に、デジ
タル署名を作成して、１部の証明書をそのそれぞれに添付する。取引に関与する
別のパーティは、そうしたデジタル署名を受け取ったとき、一般的にそのオンラ
インデータベースを介して証明機関に問い合わせて、その証明書が、現在、有効
であるか否かを判定しなければならない。有効であり、そのデジタル署名が、そ
の証明書内の公開キーによって検証され得る場合、そのパーティは、通常、その
デジタル署名を信頼する強い立場にある。

【００１３】 既存の従来システムは、いくつかの欠点を有し、これには、下記のものが含ま
れる。

【００１４】 リスク管理のためのサポートがほとんどない：従来システムは、証明機関が、
証明書のリスクを管理できるようにする機構または機会をほとんど提供しない。
証明機関は、任意の人がその証明機関によって発行された証明書をいつ信頼する
か、あるいはそれが発行した任意の証明書を任意の人がどの程度、信頼している
かについて知らない。証明機関は、未処理の証明書を監視する手立て、問題が起
きたか否かを確認する手立て、権限証明書のリスクに影響を与える要因または証
明機関が引き受けることが賢明であるリスク負担の範囲を評価する手立てが全く
ない。さらに従来システムは、記名者および信頼パーティが、秘密キーをセキュ
アに保つことのリスクを含め、リスクを管理するのを助ける機構をほとんど提供
しない。

【００１５】 信頼パーティが十分なサービスを受けない：かなりの程度、取引で詐欺または
偽造のリスクを負うのは、記名者ではなく、信頼パーティである。文書が、偽造
された、または詐欺によって改ざんされた場合、信頼パーティは、その結果を被
ることになり、これは、ほとんどの州の法律によれば、そのメッセージが無効と
して扱われることである。信頼パーティは、取引の情報セキュリティに最も強い
関心を有するが、証明機関のサービス契約は、完全に記名者とのものである。詐
欺または偽造の場合、記名者は、犯罪実行者でさえあり得る。従来システムの役
割は、したがって、証明機関を、比較的、無関心なパーティと、または、問題の
ある場合、犯罪実行者とさえ取引するように手配するが、主に損失を被るパーテ
ィとのコンタクトを有さないことである。この状況は、信頼パーティとの関係で
、証明機関を深刻な賠償責任（ｌｉａｂｉｌｉｔｙ）のリスクにさらし、その証
明機関が、信頼パーティにサービスを提供するビジネス機会をあきらめることを
もたらす。記名者と排他的に取引するのではなく、デジタル署名インフラストラ
クチャは、信頼パーティと取引するための手立ても必要である。

【００１６】 記名者に前倒しでかかる費用：証明機関の契約は、記名者とだけのものであり
、信頼パーティとのものではないので、前述のとおり、信頼パーティが署名され
たメッセージのセキュリティに主な利害を有するにもかかわらず、証明機関は、
すべての費用および利益を記名者から回収するより他ない。

【００１７】 堅固さの欠如：従来システムは、リスク管理および信頼パーティの必要性に対
処していないので、証明機関は、その役割を狭く解釈する傾向がある。証明機関
は、例えば、取引に関与するパーティの期待を満たすことである、証明書の現実
のビジネスニーズに応えることに目的を持って努力することなく、見掛けの運転
免許証を機械的に見ることを約束する、または証明書に対する公証された出願を
額面どおりに受諾する可能性がある。証明書に対するこの機械的手法は、ＣＡが
、電子商取引にさらなる価値を付与する可能性を制限する。より堅固なシステム
が、例えば、認可、資格認定、陪審員の法的地位、およびクレジットを証明する
ために使用可能である必要がある。

【００１８】 （現行で好ましい例としての実施形態の詳細な説明） 序論 本発明の構成要素の概要が、図１の図を参照して提供される。本発明は、信頼
マネージャ（ＲＭ）システムを提供し、これは、証明機関（ＣＡ）が、自らの発
行した証明書に関連する取引上のリスクを監視できるようにする。好ましい実施
形態では、本発明のＲＭサービスは、金融信用機関（ＦＴＡ）と呼ばれる参加金
融機関（ＰＦＩ）のなかの組織によって、その組織内で実施され得る。

【００１９】 本明細書で使用する、信頼マネージャ（ＲＭ）は、保証、証明書ステータス、
保証管理サービスに対する一般的用語である。本発明によるＲＭは、公開キーイ
ンフラストラクチャ（ＰＫＩ）階層内で機能する。証明機関（ＣＡ）は、一般的
に、証明書に署名し、それを発行するアプリケーションを指す。ＰＫＩは、それ
自体に対するＣＡ、およびＦＴＡ内のレベル１のＰＦＩ（銀行）のそれぞれに対
するＣＡを含む。本発明によるＰＫＩ内では、銀行（発行銀行、ＩＢ）が、取引
ベースの賠償責任証明書（ＴＢＬ証明書）をエンティティ、例えば、エンドユー
ザ（署名パーティ、ＳＰ）に発行する。これらの証明書に関連する方針および規
則が、ＴＢＬ証明書を備えた署名済みメッセージを受け取る任意のパーティ（信
頼パーティ、ＲＰ）が、その署名済みメッセージに実現される取引に関連する保
証を得るために、何をしなければならないかを定義する。保証は、信頼パーティ
（ＲＰ）が、その取引に関して所望する賠償責任保護である。保証は、一般的に
、ＴＢＬ証明書内に含まれる情報（通常、識別情報またはステータス情報）が間
違っている、または不正確である場合に、信頼パーティ（ＲＰ）が被ることにな
る直接の損害に限られる。ただし、本発明の範囲内で、任意のタイプの保証を与
えることができ、考慮することができる。

【００２０】 本発明のオペレーションに関与する様々なエンティティが、図１を参照して簡
単に説明されている。

【００２１】 参加金融機関（ＰＦＩ）の発行する銀行（発行銀行（Ｉｓｓｕｉｎｇ Ｂａｎ
ｋ））が、企業およびその従業員／被指名者などの様々なエンティティに証明サ
ービスおよび保証サービスを提供する。保証サービスは、登録機関（ＲＡ）サー
ビス、証明書発行、および証明書管理を含む。証明サービスは、証明書検証およ
び証明書情報引受け／保証を含む。

【００２２】 図１、２の４コーナモデル例に関して、発行銀行（ＩＢ）は、記名者の証明書
、すなわち、信頼パーティがそれに対して保証を要求する証明書を発行し、信頼
パーティ銀行ＲＭサーバからの保証要求に応答する銀行である。銀行は、一般的
に、発行パーティの役割と信頼パーティの役割の両方を実施することに留意され
たい。

【００２３】 ＰＩＦ発行者証明機関（ＣＡ）が、通常、機関の記名者である様々なエンティ
ティに証明書を発行する。記名者は、一般的に、発行銀行がそ人のために記名者
の証明書、つまり取引を伴う賠償責任（ＴＢＬ）証明書を作成したエンドユーザ
である。記名者は、契約に署名して、記名者のＴＢＬ証明書を送ることによって
、信頼パーティとのオンライン取引に参与する。記名者は、時には署名パーティ
とも呼ばれる。

【００２４】 ＣＡは、使用法によって決定される複数タイプの証明書を発行することができ
、これには、取引ベース賠償責任（ＴＢＬ）証明書およびユーティリティ（セキ
ュアソケット層、ＳＳＬ）証明書が含まれる。取引ベース（または取引を伴う）
賠償責任証明書（ＴＢＬ）は、例えば、ＰＫＩの下で、識別保証（ｉｄｅｎｔｉ
ｔｙ ｗａｒｒａｎｔｙ）のために使用される証明書である。つまり、ＴＢＬ証
明書（保証証明書および属性証明書としても知られる）は発行銀行によってその
記名者に与えられる証明書である。これは、銀行によって、そのアーキテクチャ
によって指定された証明書プロファイルを実施するそのエンドユーザに与えられ
る証明書である。ＲＭクライアントは、その秘密キーおよびその保証証明書を使
用して、識別保証要求メッセージおよび証明書ステータス要求メッセージに署名
して、それらを認証する。

【００２５】 属性証明書は、取引ですることができ、保証要求の一部であり得るＲＭクライ
アントについての追加情報を含んだ証明書である。属性証明書の一例は、「Ｍｅ
ｔｈｏｄ Ｆｏｒ Ｓｅｃｕｒｅｌｙ Ｕｓｉｎｇ Ｄｉｇｉｔａｌ Ｓｉｇｎ
ａｔｕｒｅｓ Ｉｎ Ａ Ｃｏｍｍｅｒｃｉａｌ Ｃｒｙｐｔｏｇｒａｐｈｉｃ
Ｓｙｓｔｅｍ」と題された１９９７年８月１９日に発行され、参照によって本
明細書に組み込まれる米国特許第５６５９６１６号に記載される証明書である。

【００２６】 ユーティリティ証明書は、証明書ステータスメッセージまたは識別保証サービ
スメッセージ以外の何らかの使用のために発行される証明書であり、例えば、Ｓ
ＳＬクライアント証明書およびＳＳＬサーバ証明書である。

【００２７】 ＰＦＩリポジトリ（図１のＲｅｐｏ．）が、更新済み証明書ステータス情報を
記憶して、これを信頼パーティにガーディアン／ＲＭを介して提供する。リポジ
トリは、一般的に、ＣＡがそれに対して証明書を発行するサービスまたはアプリ
ケーションを指す。通常、各ＣＡごとに１つのリポジトリが存在する。ただし、
ＣＡごとに複数のリポジトリが存在することが可能であり、またＣＡがリポジト
リを共用することが可能である。リポジトリサービスは、ＣＡが証明書を発行し
たことを確認して、その証明書が取り消されたか否かを述べる。任意の銀行に対
するＲＭサーバは、その銀行およびルートＣＡに対するリポジトリと直接に話す
。他の銀行のリポジトリとの通信は、他の銀行のＲＭを介してチャネルされる。
ＲＰクライアントもまた、その銀行のリポジトリ（および他の銀行のリポジトリ
）のサービスに、その銀行のＲＭを介してアクセスする。リポジトリは、証明書
ステータスの要求、証明書の要求、およびときとして、ＣｅｒｔＲｅｐｏｓｉｔ
ｏｒｙと呼ばれる証明書取消しリスト（ＣＲＬ）自体の要求に応答する。

【００２８】 署名パーティ（署名パーティ、ＳＰ）は、エンティティ、例えば、発行銀行か
らＴＢＬ証明書を受け取る企業の従業員などである。また、各署名パーティには
、保証制限が割り当てられ、これは、ＰＦＩによって企業に与えられる保証制限
の一部分であり得る。一般的に、署名パーティ（ＳＰ）は、４コーナモデル（図
１を参照）に関して、信頼パーティによって購入され得る、識別保証を管理する
ための識別保証アカウントをその銀行が保持する保証証明書保持者である。

【００２９】 ガーディアン（ＲＭ）サーバ（ガーディアン（ＲＭ））は、保証認可について
の情報およびすべてのＰＩＦ記名者に対する制限を記憶して、それに対するアク
セスを提供する。

【００３０】 ＲＦＩ信頼パーティ銀行（ＲＰＢ）は、保証サービスを信頼パーティに提供す
る。好ましい実施形態では、ＲＰＢは、信用階層に対するＲＰの唯一のアクセス
ポイントを提供する。信頼パーティ銀行（ＲＰＢ）は、４コーナモデル（図１、
２を参照）に関して、一般的に、信頼パーティクライアントからの識別保証サー
ビス要求および証明書ステータス要求に応答する銀行である。つまり、ＲＰＢは
、信頼パーティ証明書、すなわち信頼パーティが、その銀行に保証要求および証
明書ステータス要求を送り、これが、信頼パーティクライアントからの保証要求
に応答するとき、自らを識別するのに使用する証明書を発行する銀行である。前
述のとおり、銀行は、一般的に、発行パーティの役割と信頼パーティの役割の両
方を実施する。

【００３１】 信頼パーティ（ＲＰ）は、エンティティ、例えば、ＲＰＢから証明書の発行を
受け、したがって、署名パーティからの個別の署名済み取引に対する保証を求め
る権利を有する企業の従業員である。（署名済み取引は、一般的に、ビジネス協
定をペイロードとして、また内容タイプ、内容メッセージ要約、署名証明書、証
明書時刻、署名者契約（ｓｉｇｎｅｒ ｃｏｎｔｒａｃｔ）を認証された属性と
して含むＣＭＳ署名済みデータメッセージ（下記の）を指す。）

【００３２】 一般的に、信頼パーティ（ＲＰ）は、４コーナモデル（図１を参照）に関して
、その信頼パーティ銀行に対して保証ステータス要求および識別保証要求を発行
する保証証明書保持者である。要求は、署名パーティの証明書および署名パーテ
ィの署名済み文書に関して行われる。言い換えれば、信頼パーティは、自分の信
頼パーティ銀行に対して保証要求および証明書ステータス要求を発行するＲＭク
ライアントである。信頼パーティは、記名者の証明書に関して、保証要求および
証明書ステータス要求を発行する。

【００３３】 ガーディアン（ＲＭ）管理者は、識別保証アカウントを管理して、ガーディア
ン（ＲＭ）サービスのステータスを監視する。各ガーディアン（ＲＭ）は、すべ
ての取引に対する記録：識別保証、証明書ステータス、およびアカウント管理を
含むローカルデータベースを有する。ガーディアン（ＲＭ）管理者は、このデー
タベース内で収集されたデータに対するレポート（報告）を実行することができ
る。様々なデータベースは、下記の「データベース設計」と題するセクションで
より詳細に説明する。

【００３４】 図１の様々な構成要素は、いわゆる「４コーナ」モデルを表し、それを定義し
、その「コーナ」は、発行銀行、信頼パーティ銀行、および信頼パーティ、およ
び署名パーティによって定義されることに留意されたい。

【００３５】 本発明によるＲＭは、デジタル証明書の使用に関連するリスク負担を管理する
ための包括的な解決法を提供する。これは、金融機関が、その企業顧客に、証明
書ベースの情報に対して財政的に裏付けのある保証を提供することができる。こ
れは、識別保証サービスおよび証明書ステータスサービス（下記の）を含む様々
なサービスを、インターネット取引に参与することを所望する信頼パーティのた
めに提供する。また、本発明は、ＲＭ管理者のための識別保証管理サービスも提
供する。

【００３６】 識別保証サービス：署名パーティの秘密キーによって署名された契約に関する
署名パーティの識別を信頼パーティの証明された損失の金額に対して保証するサ
ービス。信頼パーティが、その銀行（信頼パーティ銀行、またはＲＰＢ）にある
ガーディアン（ＲＭ）に対して、保証要求を行う。次に、ガーディアン（ＲＭ）
が、信頼パーティの証明書を確認して、保証がそれに対して求められているＴＢ
Ｌ証明書内で識別されるガーディアン（ＲＭ）に対して保証要求を発行する。こ
の要求を受け取ったガーディアン（ＲＭ）は、ＴＢＬ証明書を確認して、保証が
許可されるべきか否かについて判定を行う。この保証応答（ａｓｓｕｒａｎｃｅ
ｒｅｓｐｏｎｃｅ）が、発行銀行によってデジタル方式で署名されて、ＲＰＢ
に送られる。次に、ＲＰＢが、その保証応答に署名して、それをその顧客である
信頼パーティに送る。ＴＢＬ証明書に関連する方針および契約条件（システム規
則）の下では、信頼パーティは、そのシステム規則に従ってそのＲＰＢによって
署名された保証の許可を受け取っているのでなければ、ＴＢＬ証明書に対して、
いかなる法的信頼も（また、したがって、賠償責任も）置くことができない。こ
の要件は、発行銀行が、取引ごとに、証明書に関連するリスクを管理できるよう
にする。

【００３７】 証明書ステータスサービス：このサービスは、ＯＣＳＰ要求に応答して、識別
保証証明書のステータスを提供する。

【００３８】 識別保証管理サービス：このサービスは、ガーディアン（ＲＭ）管理者が、識
別保証アカウントを管理し、ガーディアン（ＲＭ）オペレーションを管理し、ま
たガーディアン（ＲＭ）サービスのステータスを監視することを可能にする。

【００３９】 好ましい実施形態では、すべてのメッセージは、暗号メッセージ構文（ＣＭＳ
）（文書に署名する（またそれを封印する）ためのＩＥＴＦ規格）を使用して符
号化され、またすべてが、ＳＳＬ上でＨＴＴＰを介してトランスポートされる。
レポートは、ＳＳＬ上でのみトランスポートされる。ＳＳＬは、サーバのクライ
アントに対する認証およびクライアントのサーバに対する認証を含む、様々なレ
ベルのプライバシーおよび認証を提供するように構成され得るトランスポートレ
ベルのセキュリティ機能である。ＳＳＬは、現在、「トランスポートレベルセキ
ュリティ」またはＴＬＳとして、ＩＥＴＦ規格としての仕上げが行われている。

【００４０】 ＣＭＳは、１９９９年７月１２日に刊行されたＩＥＴＦ ＲＦＣ２６３０（「
ｆｔｐ：／／ｆｔｐ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２６３０．ｔｘｔ」）
で定義され、これは、参照により、本明細書に組み込まれる。

【００４１】 システムは、適切なシステム規則の下で、例えば、１つの機関が信頼パーティ
および署名パーティのためのすべてのサービスを提供する３コーナモデルとして
動作するように構成することができる。同様に、参加機関が、提供される保証の
タイプを増やし、または制限するために、保証の申し出内の任意のパラメータを
変更できるようにするように、システム規則を定め、システムを構成することが
できる。システムは、発行銀行が、取引ごとに、または一群の取引ごとに証明書
に関連するリスクを管理できるように構成することができる。

【００４２】 （概要） ＲＭ機構は、次の４つのクライアントサービスを提供する。申し出メッセージ
および受諾メッセージを伴う識別保証、申し出メッセージおよび受諾メッセージ
を伴わない識別保証、証明書ステータス、および識別保証管理である。ＲＭクラ
イアントおよびサーバは、ＰＫＩのコンテキスト内で機能する。

【００４３】 クライアントサービス クライアントサービスは、「４コーナ」モデル（図１、２）のコンテキスト内
で実施される。

【００４４】 このモデルでは、発行銀行ＣＡが、署名パーティの秘密キーのための保証証明
書およびユーティリティ証明書を作成する。信頼パーティ銀行ＣＡが、信頼パー
ティの秘密キーのための保証証明書およびユーティリティ証明書を作成する。署
名パーティのキーおよび証明書、ならびに信頼パーティのキーおよび証明書は、
スマートカード上などのセキュア（ｓｅｃｕｒｅ）な方式で送達され、維持され
るのが好ましい。

【００４５】 署名パーティは、その保証証明書の秘密キーを使用して、ビジネス協定に署名
して、これを信頼パーティに送る。署名パーティの保証証明書によってカバーさ
れるビジネス協定は、契約そのもの、および信頼パーティの、識別保証の購入を
規定するいくつかの識別保証パラメータを含む。ビジネス協定および署名に加え
て、署名パーティは、その保証証明書連鎖（保証証明書、発行銀行ＣＡ証明書、
ルートＣＡ証明書）を送る。

【００４６】 署名パーティの保証証明書および秘密キーは、ビジネス協定を保護するためだ
けに使用されることに留意されたい。ＳＳＬおよび他のアプリケーションの場合
、署名パーティおよび信頼パーティは、そのユーティリティ証明書および秘密キ
ーを使用し、これらは、証明書が一般的認証手続きに失敗することを引き起こす
ような証明書の拡張を全く含まないように設計されている。

【００４７】 ビジネス協定を受け取る信頼パーティは、自らの保証証明書の秘密キーを使用
して、その信頼パーティ銀行（ＲＰＢ）ＲＭに送る識別保証要求メッセージおよ
び受諾メッセージに署名する。

【００４８】 要求メッセージは、契約に対するチェックサムを含む。というのは、契約の詳
細は、ＲＰＢ ＲＭの関与するところではないからである。要求は、チェックサ
ム、署名パーティのパラメータおよび属性、ならびに署名パーティの署名を含み
、ＲＰＢサーバおよびＩＢ ＲＭサーバが、署名パーティの署名と、契約と、パ
ラメータとの間での結付けを検証できるようになっている。また、要求は、メッ
セージ全体に対するＲＰ署名、およびＳＰとＲＰの証明書連鎖も含み、ＲＰＢ
ＲＭおよびＩＢ ＲＭが、そのＲＰ証明書とＳＰ証明書の署名とステータスを検
証できるようになっている。

【００４９】 信頼パーティは、ＲＰＢ ＲＭによって証明書について要求されたときに、そ
のユーティリティ証明書および秘密キーをそのＳＳＬクライアント識別のために
使用する。

【００５０】 申し出メッセージおよび受諾メッセージを伴う識別保証サービス 識別保証を得るための処理は、図３を参照すると、下記のとおりである。 １．信頼パーティが、署名済み取引を受け取る。 ２．信頼パーティが（好ましくは、何らかのメカニズム、例えば、信頼パーテ
ィ銀行によって提供されるソフトウェアを使用して）、署名済み取引に対する保
証の申し出に対する要求を送る。 ３．信頼パーティ銀行が、信頼マネージャシステムを操作して、その信頼パー
ティの要求を認可するか否かを決定する。署名パーティの証明書内に含まれる情
報に基づいて、信頼パーティ銀行が、信頼マネージャシステムを操作して、その
要求を署名パーティの証明書に対して責任を負っている署名パーティの発行銀行
に転送する。 ４．署名パーティの銀行、すなわち、発行銀行も、信頼マネージャシステムを
操作して、要求された金額の識別保証を支払うか否かを決定して、識別保証の申
し出またはエラーを信頼パーティ銀行に送る。この申し出は、満了の日付を含む
。 ５．信頼パーティ銀行が、申し出を更新して、それを信頼パーティに伝送する
。この銀行は、それが信頼パーティに提供する、ある付加価値サービスに対する
追加料金を見積ることができる。 ６．信頼パーティが、申し出を受諾するか否かを選択して、受諾メッセージを
信頼パーティ銀行に送る。 ７．信頼パーティ銀行が、２度目に、信頼パーティの要求を認可するか否かを
決定して、取引を行い、受諾メッセージを署名パーティの発行銀行に転送する。 ８．申し出がまだ有効である場合、発行銀行が、２度目に、識別保証の要求さ
れた金額を支払うか否かを決定し、署名パーティの識別保証アカウントから識別
保証金額を支払い（またはその金額を支払うことを拒否し）、その保証を信頼パ
ーティ銀行に戻す。 ９．信頼パーティ銀行が、保証を更新し、それを信頼パーティに転送する。

【００５１】 申し出メッセージおよび受諾メッセージを伴わない識別保証サービス 別法では、図４に示すとおり、信頼パーティは、申し出メッセージおよび受諾
メッセージを回避することを選択して、即時に要求を行うことができる。このバ
ージョンのプロトコルでは、信頼パーティは、識別保証料金を、事前にその料金
が正確にいくらになるかを知ることなく、受諾することに留意されたい。識別保
証に対して課金されることに署名パーティが合意するとき、単一往復（ｓｉｎｇ
ｌｅ ｒｏｕｎｄ−ｔｒｉｐ）バージョンのプロトコルが、最も理にかなってい
る。

【００５２】 １．信頼パーティが、署名済み取引を受け取る。 ２．信頼パーティが、信頼パーティ銀行からの契約に対する識別保証に対する
要求を送る。 ３．信頼パーティ銀行が、信頼マネージャシステムを操作して、その信頼パー
ティの要求を認可するか否かを決定する。証明書内に含まれる情報に基づいて、
信頼パーティ銀行が、信頼マネージャシステムを操作して、署名パーティの証明
書に対する責任を負っている署名パーティの発行銀行と通信を行う。 ４．署名パーティの銀行も、信頼マネージャシステムを操作して、識別保証の
要求された金額を支払うか否かを決定し、その金額を即時に支払い（またはその
金額を支払うことを拒否し）、保証またはエラーを信頼パーティ銀行に伝送する
。 ５．信頼パーティ銀行も、保証を更新して、それを信頼パーティに転送する。
この銀行は、それが信頼パーティに提供するある付加価値サービスに対する追加
料金を見積ることができる。

【００５３】 証明書ステータスサービス 信頼パーティは、その信頼パーティ銀行に問い合わせて、保証証明書に対する
証明書連鎖内で保証書のステータスを検証することもできる。図５は、本発明の
実施形態による証明書ステータスサービスのための処理を示す。

【００５４】 １．信頼パーティが、証明書ステータス要求をその信頼パーティ銀行にあるＲ
Ｍサーバに送る。 ２．メッセージ内の証明書が、その信頼パーティ銀行によって発行されている
場合には、信頼パーティ銀行ＲＭサーバが、証明書そのもののステータスを検査
して、応答を信頼パーティに送る。 ３．メッセージ内の証明書が、異なる銀行（図５の「目標証明書銀行」）によ
って発行されている場合には、信頼パーティ銀行は、証明書ステータス要求を作
成して、それを、信頼パーティの代理として、目標証明書銀行ＲＭサーバに送る
。目標証明書銀行ＲＭサーバは、証明書のステータスを検査して、応答を信頼パ
ーティ銀行に送り返し、この銀行が、その応答に署名し直して、それを信頼パー
ティに目標証明書銀行の代理として送る。

【００５５】 識別保証管理サービス 図６は、本発明による識別保証管理サービスの概要を提供している。各ＲＭサ
ーバは、その識別保証アカウントについての情報を含むローカルデータベースを
有する。このデータベースは、また、すべての取引に関する記録、つまり、識別
保証、証明書ステータス、アカウント管理（例えば、アカウントを作成する、ア
カウントを変更するなど）も含む。ＲＭ管理者は、識別保証アカウントを管理し
て、識別保証管理サービスを介してＲＭサービスのステータスを監視する。

【００５６】 すべてのコマンドは、信頼パーティクライアントと同じフレームワークで機能
するように実施される。一例は、管理コマンド形式および管理応答形式について
分かっている管理バージョンのプラグインを使用する、署名プラグインを有する
ＣＯＴＳブラウザからのものであろう。ＲＭサーバは、固定ＵＲＬを介してその
管理インターフェースをエクスポートする。ＲＭ管理者には、スマートカード上
で保証証明書が発行される。

【００５７】 ＲＭサーバが最初にインストールされたとき、インストーラが、認可データベ
ースを初期設定して、１人のＲＭ管理者にアクセスを許可する。ＲＭ管理者は、
自分のスマートカードをＰＣに挿入して、ＲＭサーバから管理フォームのうちの
１つ（例えば、新しい信頼パーティを作成する）をダウンロードし、場合によっ
ては、このプロセスで、ＲＭ管理プラグインをダウンロードして、インストール
する。ＲＭ管理者は、そのフォームに記入して、「提出」ボタンを押す。プラグ
インが、管理者の証明書連鎖を収集して、管理コマンドを生成し、それに署名し
て、そのコマンドをＲＭサーバに送る。次に、このサーバが、その応答を構文解
析し、検査して、表示する。

【００５８】 管理コマンドは、２つのカテゴリに入る。アカウントを管理するコマンド、お
よびＲＭサービスを監視するコマンドである。アカウント管理コマンドは、識別
保証制限などのセンシティブなデータに影響を与える。ＲＭサーバが、アカウン
ト管理コマンドに対する認可検査を適用して、複数の管理者の承認を要求し、各
管理者は、目標アカウントに対する実際の更新を実行する前に、自分の保証証明
書でその要求に署名する。

【００５９】 サービス監視コマンドは、ＲＭサービスのステータスをリストするレポートを
生成する。これは、例えば、午前８：００時以来のすべての識別保証取引のリス
トを戻す、識別保証制限に等しい識別保証収支を有するすべてのアカウントのリ
ストを戻すなどである。アカウント管理コマンドとは異なり、サービス監視コマ
ンドは、複数のＲＭ管理者の承認を必要としない。ただし、これらのコマンドは
、同じ認可データベースに照らして検証される。

【００６０】 レポートの種類は、銀行ごとに異なる可能性が高いので、ＲＭサーバは、拡張
可能な設計を実施して、銀行が容易にカストマイズされたレポートをインストー
ルできるようにする。サービス監視コマンド（別名、レポート生成）が、ＨＴＴ
ＰＳ ＵＲＬに対するＨＴＴＰ ＰＯＳＴ／ＲＥＳＰＯＮＳＥメッセージとして
実施され、クライアントのＳＳＬ識別（ユーティリティ証明書）に照らして認可
される。

【００６１】 さらに、各ＲＭサーバは、ローカルホストシステムのリソースを使用して、ロ
ーカル管理インターフェースを実装する。サーバは、最初、Ｗｉｎｄｏｗｓ（登
録商標）／ＮＴ上に実装されるので、ＲＭサーバは、Ｗｉｎｄｏｗｓ（登録商標
）／ＮＴサービスを実行して、動作を開始、停止、および一時停止するために、
Ｗｉｎｄｏｗｓ（登録商標）／ＮＴサービスコントロールパネルを使用する。た
だし、Ｗｉｎｄｏｗｓ（登録商標）／ＮＴログサービスを使用する代わりに、Ｒ
Ｍサーバは、それ自体の、暗号方式で保護されたログファイルを実装する。この
ログファイルは、サーバアプリケーション自体のステータスに関連する情報、特
に、システムリソースの利用およびネットワーク接続性を含むものを記録する。

【００６２】 ＲＭサーバは、識別保証レベルの定期的ステータス、または識別保証リソース
の消耗（およびその他の経験によって決定されるもの）などの重要なサービスイ
ベントのログをとる。これは、迅速な応答のため、例えば、ログを走査して、重
要なイベントを検出したときに、銀行固有の警報またはアラームを活動化（ａｃ
ｔｉｖａｔｅ）する銀行固有プロセスを介して、サーバ活動化されたパスを提供
する。

【００６３】 ロギング ＲＭサーバは、プロトコルメッセージおよびデータベーストランザクションの
ログをとる。プロトコルメッセージ内の署名は、通信を行うパートナおよびロー
カルサーバ動作の否認不可能な証拠を提供する。ＲＭサーバは、ＲＭクライアン
トおよび他のＲＭサーバから受け取る識別保証メッセージのログをとる。ＲＭサ
ーバは、それ自体が生成する識別保証メッセージのログもとる。ＲＭサーバは、
また、それがＯＳＣＰ応答側、すなわち、ローカルリポジトリ、リポジトリ、お
よび他のＲＭサーバから受信する証明書ステータス（ＯＣＳＰ）メッセージのロ
グもとる。プロトコルメッセージは、ローカルファイルシステムにログをとられ
る。このロギングシステムは、ロギング秘密キーを使用して、個別エントリに署
名をし、また削除されたエントリに対する保護のため、一連のエントリに署名を
する。管理者は、ログエントリを遠隔方式で閲覧することができるが、エントリ
自体は、主に、クレーム処理のために価値のあるものである。

【００６４】 データベーストランザクション（例えば、識別保証アカウント、更新識別保証
アカウント保証収支、更新識別保証アカウント保証制限）が、データベーステー
ブルにログをとられる。これらのログは、支払請求記録を生成するため、またす
べてのアクティブな識別保証の総価値などのリソースの配分を監視して、管理す
るために使用される。データベースログは、データベース全体として、同一のメ
カニズムによって、つまり、データベーステーブルに対するアクセスを記憶済み
手続きに制限すること、およびデータベース管理者アカウントをＲＭサーバによ
って使用されるアカウントに制限することなどのデータベースの特定の構成によ
って保護される。

【００６５】 カスタマイズ ＲＭサーバは、銀行固有の認可手続きおよび通貨換算手続きとの統合に備える
。ＲＭサーバを、それが銀行固有のリスク管理手続きを呼び出すようにカスタマ
イズするため、ＲＭインストーラが、銀行によって供給されたライブラリをＲＭ
構成に追加する。ローカル認可手続きを実行した後、ＲＭサーバは、そのライブ
ラリを介して、銀行によって供給された手続きを呼び出す。ＲＭサーバは、認可
のために、下記の銀行によって供給された手続きを呼び出す。

【００６６】 １．要求 ２．転送された要求 ３．受諾 ４．転送された受諾

【００６７】 ＲＭサーバは、また、通貨換算のための銀行によって供給された手続きも提供
する。ＲＭサーバは、要求または受諾を認可するとき、通貨間の換算を行い得る
。というのは、識別保証アカウント金額フィールドおよび要求金額フィールドは
、特定の通貨でなければならないからである。ＲＭサーバは、また、申し出を作
成または転送するときにも、通貨間の換算を行い得る。というのは、要求内の通
貨が、識別保証料金を計算するのに銀行が使用する通貨と一致しないことがあり
得るからである。

【００６８】 他の構成パラメータと同様に、銀行固有の手続きを実装する共用ライブラリは
、この共用ライブラリファイル自体の上で計算され、暗号トークン上に記憶され
るハッシュ値を介して、特定の暗号トークンに結合されている。

【００６９】 ＲＭ識別 各ＲＭサーバは、複数の識別を維持することができ、ここで、識別は、公開キ
ー／秘密キーペアおよび発行された証明書を意味する。キーペアおよび証明書は
、すべて、暗号デバイス（すなわち、１つの、または場合によっては、複数のハ
ードウェアトークン）上に記憶される。ＲＭサーバが最初にインストールされた
とき、インストールアプリケーションが、この暗号デバイス上に新しい公開キー
／秘密キーペアを生成し、またキーペアのそれぞれに対する証明書要求を作成す
る。このインストーラは、その要求をＣＡ（これが、すべてのＲＭ証明書に署名
する）に伝えて、各要求ごとに、新しい証明書をＣＡに作成させる。インストー
ルの最終部分は、証明書およびＲＭ構成をハードウェアトークン上でキーペアに
結合する。ＲＭ秘密キーは、ハードウェアトークン上に完全に含まれる。ハード
ウェアトークンは、さらに、パスフレーズによって保護され、ＲＭは、開始する
たびに毎回、ローカル管理者に、パスフレーズをタイプ入力しなければ、開始で
きないことをプロンプト指示する。（別法では、インストーラは、パスフレーズ
についてプロンプト指示を受けることと、パスフレーズを（隠蔽された）ローカ
ルストレージ内に、ローカルストレージの保護が重大なセキュリティリスクにな
るという警告付きでセーブすることとの間で選択することができる。）

【００７０】 ＲＭサーバは、下記のものに対して署名を生成する。 ・転送された要求 ・申し出 ・転送された申し出 ・転送された受諾 ・保証 ・転送された保証 ・ＯＣＳＰ要求 ・ＯＣＳＰ応答 ・管理コマンド応答 ・ログファイルエントリ ＲＭサーバは、また、公開キー／秘密キーペアを使用して、通信をトランスポ
ートするのを保護する。 ・ＳＳＬ サーバは、署名のために５つの識別を使用し、またＳＳＬのために１つの識別
を使用する。 ・ＲＰＢ識別保証メッセージのためのＲＰＢ識別：転送された要求、転送され
た申し出、転送された受諾、転送された保証、エラー ・ＩＢ識別保証メッセージのためのＩＢ識別：申し出、保証、エラー ・ＯＣＳＰメッセージのための保証ステータス識別：要求、応答 ・管理応答メッセージのための管理識別 ・ログファイルエントリのためのロギング識別 ・ＳＳＬ識別

【００７１】

【表１】

【００７２】 ＳＳＬ以外の識別のための証明書は、好ましくは、各活動ごとの拡張されたキ
ー使用拡張ＯＩＤを備えた保証証明書である。

【００７３】 ＳＳＬ証明書は、好ましくは、ユーティリティ証明書である。

【００７４】 識別のうちのどれを更新するにも、ＲＭ管理者は、好ましくは、サーバのオペ
レーションを一時停止して、新しいキーペアおよび証明書要求を作成するインス
トールコマンドを再実行して、その新しい証明書をＲＭ構成内にインストールす
る。

【００７５】 保証要求プロトコル イントロダクション 本節は、本発明の実施形態による識別保証プロトコル（ＩＷＰ）を説明する。
具体的には、記名者と信頼パーティ（ＲＰ）との間、ＲＰと信頼マネージャ（Ｒ
Ｍ）との間、およびＲＭ間のメッセージが定義される。プロトコルは、ＣＭＳ
ｓｉｇｎｅｄＤａｔａ構成を使用する、取引をカプセル化するためのＣＭＳ（以
前はＰＫＣＳ ＃７）の使用に基づく。個々のメッセージは、ＡＳＮ．１ＤＥＲ
（これはＣＭＳ自体に対しても使用される）を使用して指定され、符号化される
。ｓｉｇｎｅｄＤａｔａインスタンスは、（例えばｂｅｓｅ６４符号化を使用し
て）転送するためにさらに符号化することができ、一層の保護（例えば、ＳＳＬ
またＳ／ＭＩＭＥ）を適用することができる。この署名者の識別は、その証明書
連鎖中に含まれる。図７〜９は、本発明による、保証管理サービスを識別するた
めの様々なメッセージの流れ図を示す。図７は、本発明の実施形態による識別保
証プロトコルメッセージフローを示す。

【００７６】 図７のメッセージは、以下の通りである。 １．署名した取引（技術的には、これは識別保証プロトコルの部分ではない） ２．要求 ３．転送された要求 ４．申し出（これとメッセージ５〜７は、要求に応じた任意選択である） ５．転送された申し出 ６．受諾 ７．転送された受諾 ８．保証 ９．転送された保証

【００７７】 発行銀行または信頼パーティ銀行のいずれかは、例えば署名パーティまたは信
頼パーティの証明書が取り消されたものであったことが判明した場合に、エラー
を返す可能性がある。

【００７８】 図８は、ＲＰ銀行エラーを伴う識別保証プロトコルメッセージフローを示す。
図８のメッセージは、以下の通りである。 １．署名した取引（技術的には、これは識別保証プロトコルの部分ではない） ２．要求または受諾 ３．エラー

【００７９】 図９は、発行銀行のエラーを伴う識別保証プロトコルメッセージフローを示す
。図９のメッセージは、以下の通りである。 １．署名した取引（技術的には、これは識別保証プロトコルの部分ではない） ２．要求または受諾 ３．転送された要求または受諾 ４．エラー ５．再署名したエラー

【００８０】 署名した取引構造 本発明による署名した取引では、ＣＭＳメッセージ構造（ＳｉｇｎｅｄＤａｔ
ａ）を使用することを仮定する。

【００８１】 署名者は、以下に示すＳｉｇｎｅｒＣｏｎｔｒａｃｔ構造中の実際の識別保証
プロトコルに、パーティが使用可能な形で、取引上の情報を提供する。

【００８２】 SignerContract ::= SEQUENCE { version Version, contractID ContractID, transactionType [0] TransactionType OPTIONAL, paymentType [1] PaymentType OPTIONAL, amountLimit [2] MonetaryValue OPTIONAL, timeLimit [3] GeneralizedTime OPTIONAL, relyingPartyID [4] CertificateIdentifier OPTIONAL, contractAmount [5] MonetaryValue OPTIONAL, contractExpires [6] GeneralizedTime OPTIONAL, extensions [7] Extensions OPTIONAL } Version ::= INTEGER { v1(0), v2(1), v3(2) } -- from X.509 ContractID ::= OCTET STRING -- SHA-1 hash of transaction PaymentType ::= OBJECT IDENTIFIER -- define values in arc for signing party pays, relying party pays, ...
TransactionType ::= OBJECT IDENTIFIER -- define values in arc for fx, purch, collat, security, ... MonetaryValue ::= SEQUENCE { -- from SET and ANSI X9.45 currency INTEGER (1..999), -- per ISO 4217 amount INTEGER, exponent INTEGER } -- value = amount* 10^exponent CertificateIdentifier ::= OCTET STRING -- SHA-1 hash of DER encoding of relying party certificate

【００８３】 契約は、ＳｉｇｎｅｄＤａｔａメッセージの内容として含まれる。Ｓｉｇｎｅ
ｒＣｏｎｔｒａｃｔ構造は、識別保証の要求を受ける取引のハッシュを含む。取
引自体は、未署名属性として含まれる。したがって、署名は、実際の取引とＳｉ
ｇｎｅｒＣｏｎｔｒａｃｔの両方をカバーする。

【００８４】 契約ＩＤは、未署名属性中の取引の保全性を検証するためのハッシュである。
取引タイプは、あるレベルの細分性では、取引のタイプを示す。これは、取引に
関連したリスクを判定する際にＲＭが使用することができるコンテキストの最少
金額である。支払いタイプフィールドは、署名パーティが保証に対する支払いを
申し出るために使用することができる。

【００８５】 金額制限、時間制限、および信頼パーティＩＤフィールドは、信頼パーティの
識別保証要求を制限する。要求中の金額は、金額制限中の金額を超過することが
できない。要求の時間は、時間制限中の時間よりも後にはできない。要求を発信
する信頼パーティに対する証明書は、信頼パーティの識別子と同じでなければな
らない。

【００８６】 契約金額および取引満了フィールドは、取引を記述する。契約金額は、実際の
取引値である。契約満了フィールドは、取引の最大所要時間を示す。契約は、拡
張（例えば追加の取引コンテクスト）を含むこともできるが、現在のところ拡張
は定義されていない。

【００８７】 署名者は、メッセージ中の署名済み属性として、署名証明書属性のインスタン
スも提供する。この属性は、ＳｉｇｎｅｒＩｎｆｏ署名を検証するために証明書
を識別する。署名者は、ＣＭＳメッセージ構造中のその証明書からルート証明書
への連鎖中で証明書を提供する。

【００８８】 識別保証を要求される取引は、未署名属性として含まれる。この指定は、取引
内容に、どんな特定の構造も指示しない。

【００８９】 spTransaction ATTRIBUTE ::= { WITH SYNTAX SPTransaction ID <... an OID ...> } SPTransaction ::= OCTET STRING

【００９０】 署名者は、メッセージ中で認証または未認証の属性としての署名パーティの認
証情報である、１つまたは複数のインスタンス中のハードウェアまたはアプリケ
ーション特有の認証または認可データを、任意選択で提供することができる。

【００９１】 spAuthInfo ATTRIBUTE :: = { WITH SYNTAX SPAuthData ID <... OID ...> } SPAuthData ::= SEQUENCE { version Version, type OBJECT IDENTIFIER, content ANY DEFINED BY type

【００９２】 例えば、スマートカード指定中で記述されたＣＳＳＤ署名は、未認証属性とし
て搬送されることになる。

【００９３】 id-CSSDAuthInfo ::= <... OID ...> CSSDAuthInfo ::= OCTET STRING

【００９４】 署名済み取引（署名者契約を含む）は、Ｓ／ＭＩＭＥを使用して容易に搬送す
ることができる。取引は、ＣＭＳメッセージの内容として含めることができ、こ
のＣＭＳメッセージは、ＭＩＭＥタイプ「ａｐｐｌｉｃａｔｉｏｎ／ｐｋｃｓ７
−ｍｉｍｅ」で送られる。信頼パーティは、「取引」未署名属性なしにメッセー
ジを再符号化することができる。署名済み取引のフォーマット（一部の詳細を省
略している）を図１０に示す。

【００９５】 識別保証プロトコル 本セクションでは、残りの識別保証プロトコルメッセージのフォーマットを定
義する。識別保証プロトコルは、通常２回の往復が必要である。４コーナモデル
（図１〜２）に対しては、信頼パーティが、その信頼パーティ銀行に要求を送信
し、信頼パーティ銀行は、その要求を発行銀行に転送する（この２つの銀行は、
同じであっても良い）。それに応答して、発行銀行は、申し出を作成し、それを
信頼パーティ銀行に送信する。信頼パーティ銀行は、その申し出を信頼パーティ
に転送する。これで第１の往復が完了する。

【００９６】 信頼パーティは、第２往復を受諾メッセージを作成することによって開始し、
その受諾メッセージを信頼パーティ銀行に送る。信頼パーティ銀行は、その受諾
メッセージを発行銀行に転送する。それに応答して、発行銀行は、保証を作成し
、それを信頼パーティ銀行に送信する。信頼パーティ銀行は、その保証を信頼パ
ーティに転送して戻す。

【００９７】 申し出および受諾メッセージの内部交換は、信頼パーティが申し出を受諾する
か、それとも拒絶するかを自身で決定したいことを示す場合にだけ必要である。
信頼パーティが申し出を自動的に受諾することを選ぶ場合、内部往復の必要はな
い。信頼パーティは、その信頼パーティ銀行に要求を送信し、信頼パーティ銀行
は、発行銀行にその要求を転送する。それに応答して、発行銀行は、保証を作成
し、それを信頼パーティ銀行に送信する。信頼パーティ銀行は、信頼パーティに
保証を転送して戻す。

【００９８】 識別保証プロトコルメッセージが、ＣＭＳメッセージ構造（ＳｉｇｎｅｄＤａ
ｔａ）を使用すると仮定する。識別保証プロトコルは、それぞれがそれ自体の署
名済みおよび／または未署名属性の組を有する多数の署名（すなわち、多数のＳ
ｉｇｎｅｒＩｎｆｏフィールド）を、同じメッセージ内容に付加するＣＭＳ Ｓ
ｉｇｎｅｄＤａｔａ機能を利用する。メッセージ発信元は、メッセージ内容およ
び追加の認証または未認証属性を組み上げ、署名する。中間パーティ（例えば、
信頼パーティ銀行）は、発信元のメッセージ内容およびＳｉｇｎｅｒＩｎｆｏを
転送し、それ自体の証明書およびＳｉｇｎｅｒＩｎｆｏを認証および／または未
認証属性および署名と共に加える。

【００９９】 中間パーティがダウンストリームの受信側に公開したくない重要アップストリ
ーム情報を保護し、しかもダウンストリームのクライアントが検証するアップス
トリームの署名を保持するために、アップストリームの近隣は、メッセージの署
名部分中の重要情報の要約と、メッセージの未認証部分中の重要情報自体を送信
する。中間パーティは、アップストリーム近隣が取引に参加している証拠として
メッセージの署名済み部分および署名をダウンストリームの近隣に転送する。そ
して中間パーティは、重要情報を調整し、中間パーティが署名するメッセージの
部分中に重要情報を含める。

【０１００】 例えば、この方法は、発行銀行の申し出および保証を保護するために使用され
、その結果、信頼パーティ銀行は、発行銀行の署名を保持し、信頼パーティから
、発行銀行と信頼パーティ銀行の料金の関係を保護しながら、それ自体の料金を
発行銀行の料金に加えることができる。この方法は、銀行から、署名パーティと
信頼パーティの間のビジネス取引も保護する。

【０１０１】 要求 図１１を参照すると、識別保証取引を開始するために、信頼パーティは、署名
パーティメッセージからの内容およびＳｉｇｎｅｒＩｎｆｏ−−未署名属性の取
引を除いて−−を信頼パーティのＳｉｇｎｅｒＩｎｆｏと共に含むＣＭＳ Ｓｉ
ｇｎｅｄＤａｔａ メッセージを作成する。（未署名属性を省略するか、あるい
は含むかによって、基本プロトコルに違いは生じない。実施形態により、信頼パ
ーティ銀行が署名パーティ取引を転送する必要がある場合、単に要求中にこの未
署名属性を含めることができる。）メッセージに対する内容タイプは、「署名者
契約」である。これは、メッセージ内容署名済み属性として、ＣＭＳ指定ごとに
含まれる。信頼パーティは、ｒｐＲｅｑｕｅｓｔＩｎｆｏ署名済み属性中で識別
保証金額および期間を指定する。その構文は、図１１を参照して以下のように指
定される。

【０１０２】 rpRequestInfo ATTRIBUTE ::= { WITH SYNTAX IdentityWarrantyRequest ID <... OID ...> } IdentityWarrantyRequest ::= SEQUENCE { version Version, warrantyAmount MonetaryValue, warrantyExpires GeneralizedTime, requestType IdentityWarrantyRequestType, extensions Extensions OPTIONAL -- none currently define
d} IdentityWarrantyRequestType ::= OBJECT IDENTIFIER -- define values in arc for bid, purchase, accept purchase

【０１０３】 保証金額は、信頼パーティがこの取引に関する証明書識別の妥当性に対する主
張をそれに対して発行できる識別保証の最大値を指定する。

【０１０４】 保証満了は、識別保証契約に対する期間を指定する。要求タイプは、信頼パー
ティが受諾メッセージを送信することによって申し出を明示的に受諾することを
望むか（ｒｅｑｕｅｓｔＴｙｐｅはビッド（ｂｉｄ））、信頼パーティが申し出
を最初に検討することなく暗黙的に受諾することを望むか（ｒｅｑｕｅｓｔＴｙ
ｐｅは購入）、それとも信頼パーティが保証を購入するための署名パーティの申
し出を受諾することを望むか（ｒｅｑｕｅｓｔＴｙｐｅは受諾購入）を指定する
。Ｅｘｔｅｎｓｉｏｎは、必要なときに指定することができる。

【０１０５】 転送された要求 図１２を参照すると、信頼パーティ銀行は、信頼パーティＣＭＳメッセージか
らのＣＭＳメッセージ内容およびＳｉｇｎｅｒＩｎｆｏを含むＣＭＳ Ｓｉｇｎ
ｅｄＤａｔａメッセージを、それ自体のＳｉｇｎｅｒＩｎｆｏと共に作成する。
メッセージについてのＳｉｇｎｅｒＩｎｆｏ内容タイプは、「署名者契約」であ
る。これは、ＣＭＳ指定ごとに、メッセージ内容署名属性として含まれる。信頼
パーティ銀行は、ｒｐＢａｎｋＩｎｆｏ属性中で追加の情報を指定する。ｒｐＢ
ａｎｋＩｎｆｏ属性の構文は、以下のように指定される（図１２も参照）。

【０１０６】 rpBankInfo ATTRIBUTE ::= { WITH SYNTAX RPBankInfo ID <... OID ...> } RPBankInfo ::= SEQUENCE { version Version, extensions Extensions OPTIONAL}

【０１０７】 代替実施形態は、信頼パーティの証明書に対するＯＣＳＰ応答などの認証また
は認可情報を含むことができる。

【０１０８】 申し出 図１２を参照すると、発行銀行は、ＣＭＳメッセージ内容として申し出要約（
以下に説明するＡｔｔｒｉｂｕｔｅＤｉｇｅｓｔ）を含むＣＭＳ Ｓｉｇｎｅｄ
Ｄａｔａメッセージを作成する。メッセージに対する内容タイプは、「識別保証
申し出」である。これは、ＣＭＳ指定ごとにメッセージ内容署名属性として含ま
れる。発行銀行は、ｉｂＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＯｆｆｅｒ属性中で
申し出詳細を指定する。ｉｂＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＯｆｆｅｒ属性
の構文は、以下（および図１２）のように指定される。

【０１０９】 AttributeDigest ::= SEQUENCE { version Version, attributeId OBJECT IDENTIFIER, randomPad OCTET STRING (SIZE 80), -- 160 bits of entropy for hash to follow digestValue OCTET STRING (SIZE 20) -- SHA-1 hash of DER encoding of attribute and random pad }

【０１１０】 属性ＩＤは、この構造がそれに対する要約である未署名属性を識別する。要約
値は、ＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＯｆｆｅｒ属性およびｒａｎｄｏｍＰ
ａｄのＤＥＲ符号化の連結にわたって計算される。要約値は、申し出の内容を保
護し、申し出は、未署名属性として送信される。申し出を未署名属性として送る
ことにより、信頼パーティ銀行が、信頼パーティに送る申し出をカストマイズす
ること、例えば、それ自体の課金を発行銀行の課金に加えることが可能となる。

【０１１１】 ibldentityWarrantyOffer ATTRIBUTE ::= { WITH SYNTAX IdentityWarrantyOffer ID <... OID ...> IdentityWarrantyOffer ::= SEQUENCE { version Version, transactionID TransactionID, warrantyAmount MonetaryValue, warrantyExpires GeneralizedTime, warrantyFee MonetaryValue, offerExpires GeneralizedTime, extensions Extensions OPTIONAL } TransactionID ::= SEQUENCE { contractDigest OCTET STRING (SIZE 20), -- SHA-1 hash of SignerContract seqNum INTEGER } -- distinguishes multiple protocol runs for the same transaction

【０１１２】 取引ＩＤは、同じ署名者契約および署名時間に対するプロトコルの多数の実行
を識別するシーケンス数と共に、 １．署名パーティＳｉｇｎｅｒＣｏｎｔｒａｃｔ ２．署名パーティＳｉｇｎｅｒＩｎｆｏからの署名時間属性 のＤＥＲ符号化（すなわち全てのＡＳＮ．１タイプおよび長さ情報を含む）の
連結のＳＨＡ−１ハッシュからなる。取引ＩＤシーケンス数は、発行銀行によっ
て割り当てられ、取引についての最初の申し出に対して１から始まる。

【０１１３】 発行銀行は、同じＳｉｇｎｅｒＣｏｎｔｒａｃｔに対する保証のための同じ信
頼パーティによる多数の要求を調整するためにＴｒａｎｓａｃｔｉｏｎＩＤを使
用する。各要求に対して、発行銀行は、新しいＴｒａｎｓａｃｔｉｏｎＩＤ．ｓ
ｅｑＮｕｍを有する新しい申し出を生成する。発行銀行が受諾メッセージを受信
したとき、発行銀行は、受諾メッセージ中のＴｒａｎｓａｃｔｉｏｎＩＤを使用
して申し出を探し出し、同じＴｒａｎｓａｃｔｉｏｎＩＤ．ｃｏｎｔｒａｃｔＤ
ｉｇｅｓｔを有する全ての他の申し出を削除する。

【０１１４】 発行銀行は、既存の保証がまだ満了していない間に信頼パーティが同じＳｉｇ
ｎｅｒＣｏｎｔｒａｃｔに対する第２の保証を得ることのないようにするために
ＴｒａｎｓａｃｔｉｏｎＩＤ．ｃｏｎｔｒａｃｔＤｉｇｅｓｔも使用する。信頼
パーティが保証が満了した後に同じＳｉｇｎｅｒＣｏｎｔｒａｃｔに対する保証
を逐次得ることのないように望む署名パーティは、ＳｉｇｎｅｒＣｏｎｔｒａｃ
ｔ．ｔｉｍｅＬｉｍｉｔを使用すべきである。あるいは、発行銀行は、署名パー
ティのＳｉｇｎｅｒＩｎｆｏ中の署名時間日付以降のある時間（例えば３０日）
で、どんなＳｉｇｎｅｒＣｏｎｔｒａｃｔについての保証も認可することを拒絶
する方針を実施することもできる。

【０１１５】 この申し出は、申し出をした保証に対する金額および持続時間（ｗａｒｒａｎ
ｔｙＡｍｏｕｎｔおよびｗａｒｒａｎｔｙＥｘｐｉｒｅｓ）、保証手数料（ｗａ
ｒｒａｎｔｙＦｅｅ）、および申し出が有効な時間（ｏｆｆｅｒＥｘｐｉｒｅｓ
）も識別する。

【０１１６】 転送された申し出 図１４を参照すると、信頼パーティ銀行は、それ自体のＳｉｇｎｅｒＩｎｆｏ
と共に、発行銀行ＣＭＳメッセージからのＣＭＳメッセージ内容およびＳｉｇｎ
ｅｒＩｎｆｏを含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成する。転送
された申し出は、クレーム処理の証拠に対する発行銀行の申し出内容および署名
者情報が必要であればそれを含む。信頼パーティは、応答を処理するときは、そ
れらを使用しない。（発行銀行署名が保持されるか否かは、その保証に対して誰
が法的に責任を負うかにある程度依存する。発行銀行署名を含むことが不要とな
った場合、信頼パーティ銀行は、単に転送された申し出から発行銀行署名者情報
を省略する。）メッセージに対する内容タイプ属性は、「識別保証申し出」であ
る。これは、ＣＭＳ指定ごとにメッセージ内容署名属性として含まれる。信頼パ
ーティ銀行は、ｒｐｂＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＯｆｆｅｒ属性中の識
別保証申し出詳細を指定する。ｒｐｂＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＯｆｆ
ｅｒ属性の構文は、以下で指定される（図１４も参照）。

【０１１７】 信頼パーティは、ｒｐｂＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ属性中のそれ自
体の証明書のステータスを検証する（リポジトリによって署名された）ＯＣＳＰ
応答を供給する。ｒｐｂＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ属性の構文は、以
下で指定される。信頼パーティは、ＯＣＳＰ署名証明書のローカルコピーを使用
してｒｐｂＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ属性中のＯＣＳＰ応答を検証す
る。次いで信頼パーティは、信頼パーティ銀行証明書中の公開キーを使用して信
頼パーティ銀行ＳｉｇｎｅｒＩｎｆｏを検証する。

【０１１８】 rpbIdentityWarrantyOffer ATTRIBUTE ::= { WITH SYNTAX IdentityWarrantyOffer ID <... OID ...> rpbCertificateStatus ATTRIBUTE ::= { WITH SYNTAX SignedOCSPResponseSet ID <... OID ...> SignedOCSPResponseSet ::= SEQUENCE OF SignedOCSPResponse SignedOCSPResponse ::= OCTET STRING -- per OCSP spec.

【０１１９】 受諾 図１５を参照すると、信頼パーティは、ＣＭＳメッセージ内容として受諾（以
下で説明するＡｃｃｅｐｔａｎｃｅ。図１５も参照）を含むＣＭＳ Ｓｉｇｎｅ
ｄＤａｔａメッセージを作成する。メッセージに対するＳｉｇｎｅｒＩｎｆｏ内
容タイプは、「識別保証受諾」である。これは、ＣＭＳ指定ごとにメッセージ内
容署名属性として含まれる。

【０１２０】 Acceptance ::= SEQUENCE { version Version, transactionID TransactionID, acceptanceStatus AcceptanceStatus, extensions Extensions } AcceptanceStatus ::= OBJECT IDENTIFIER -- define values in arc for accept, reject

【０１２１】 転送された受諾 図１６を参照すると、信頼パーティ銀行は、自身のＳｉｇｎｅｒＩｎｆｏと共
に、信頼パーティＣＭＳメッセージからのＣＭＳメッセージ内容およびＳｉｇｎ
ｅｒＩｎｆｏを含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成する。メッ
セージに対するＳｉｇｎｅｒＩｎｆｏ内容タイプは、「識別保証受諾」である。
これは、ＣＭＳ指定ごとにメッセージ内容署名属性として含まれる。信頼パーテ
ィ銀行は、ｒｐｂＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ属性中の追加の情報を指
定する。ｒｐｂＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ属性の構文は、上記および
図１６のように指定される。

【０１２２】 識別保証 図１７を参照すると、発行銀行は、ＣＭＳメッセージ内容として識別保証要約
（前述のＡｔｔｒｉｂｕｔｅＤｉｇｅｓｔ）を含むＣＭＳ ＳｉｇｎｅｄＤａｔ
ａメッセージを作成する。メッセージに対する内容タイプは、「識別保証」であ
る。これは、ＣＭＳ指定ごとにメッセージ内容署名属性として含まれる。発行銀
行は、ｉｂＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙ属性中の保証詳細を指定する。ｉ
ｂＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙ属性の構文は、以下のように指定される（
図１７も参照）。

【０１２３】 ibldentityWarranty ATTRIBUTE ::= { WITH SYNTAX IdentityWarranty ID <... OID ...> IdentityWarranty ::= SEQUENCE { version Version, transactionID TransactionID, signerContract SignerContract, warrantyRequest IdentityWarrantyRequest, warrantyAmount MonetaryValue, warrantyExpires GeneralizedTime, warrantyFee MonetaryValue, extensions Extensions OPTIONAL }

【０１２４】 署名者契約および保証要求は、保証への署名パーティおよび信頼パーティ入力
を記録する。保証金額および保証満了は、得られる保証を記述する。保証手数料
は、保証に対する課金を記述する。

【０１２５】 転送された識別保証 図１８を参照すると、信頼パーティ銀行は、それ自体のＳｉｇｎｅｒＩｎｆｏ
と共に発行銀行ＣＭＳメッセージからのＣＭＳメッセージ内容およびＳｉｇｎｅ
ｒＩｎｆｏを含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成する。メッセ
ージに対するＳｉｇｎｅｒＩｎｆｏ内容タイプは、「識別保証」である。これは
、ＣＭＳ指定ごとにメッセージ内容署名属性として含まれる。信頼パーティ銀行
は、ｒｐｂＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ属性中で、それ自体の証明書の
ステータスを証明する署名ＯＣＳＰ応答を指定する。ｒｐｂＣｅｒｔｉｆｉｃａ
ｔｅＳｔａｔｕｓ属性の構文は、上記のように指定される。図１８も参照された
い。

【０１２６】 識別保証エラー 図１９を参照すると、発行銀行または信頼パーティ銀行が要求を処理するエラ
ーに遭遇する場合、あるいは発行銀行または信頼パーティ銀行が要求を拒絶する
ことを選ぶ場合、発行銀行または信頼パーティ銀行は、このエラーメッセージを
返す。銀行は、ＣＭＳメッセージ内容としてエラー（以下に説明するＩｄｅｎｔ
ｉｔｙＷａｒｒａｎｔｙＥｒｒｏｒ）を含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッ
セージを作成する。メッセージに対する内容タイプは、「識別保証エラー」であ
る。これは、ＣＭＳ指定ごとにメッセージ内容署名属性として含まれる。

【０１２７】 発行銀行または信頼パーティ銀行のいずれかは、識別保証エラーメッセージを
生成することができる。メッセージは、発行銀行によって生成された識別保証エ
ラーが証明書ステータス属性を含まないという点だけが変化する。信頼パーティ
銀行が発行銀行によって生成されたエラーを受信したとき、信頼パーティ銀行は
、発行銀行ＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＥｒｒｏｒ内容に再署名し、証明
書ステータス属性を作成し、信頼パーティ銀行署名のみを有するメッセージを送
信する。エラーメッセージ上の発行銀行署名が有効であると判定される場合、プ
ロトコルは、発行銀行および信頼パーティ銀行ＳｉｇｎｅｒＩｎｆｏｓを有する
ＩｄｅｎｔｉｔｙＷａｒｒａｎｔｙＥｒｒｏｒ内容から構成される転送されたエ
ラーを含むように拡張されることになる。

【０１２８】 Identity WarrantyError ::= SEQUENCE { version Version, error Identity WarrantyStatus, transactionID TransactionID OPTIONAl, certStatus OCSPResponse OPTIONAL } IdentityWarrantyStatus ::= SEQUENCE { statusCode IdentityWarrantyStatusCode, errorText IA5String OPTIONAL } IdentityWarrantyStatuscode ::= ENUMERATED { success(0), subscriberCertChainOCSPError(1), rpCertChainOCSPError(2), rpServiceCertChainOCSPError(3), subscriberServiceCertChainOCSPError(4), Identity WarrantyValueExceedsLimit(5), ... } OCSPResponse ::= OCTET STRING -- per OCSP spec.

【０１２９】 エラーがＯＣＳＰ応答によって引き起こされた場合、発行銀行は、エラーの証
明書ステータスフィールド中にＯＣＳＰ応答を含む。

【０１３０】 プロトコルメッセージがＣＭＳを使用して（上記のように）記述することがで
きる間、プロトコルメッセージは、ＸＭＬを使用して記述することもできる。本
セクションでは、ＸＭＬを使用して識別保証プロトコルメッセージのフォーマッ
トを定義する。

【０１３１】 識別保証プロトコル（ＸＭＬ） 前述のように、識別保証プロトコルは、２往復を通常必要とする。４コーナモ
デルに対しては、信頼パーティはその信頼パーティ銀行に要求を送信し、信頼パ
ーティ銀行は発行銀行に要求を転送する（２つの銀行は同じであっても良い）。
それに応答して、発行銀行は申し出を作成し、それを信頼パーティ銀行に送信す
る。信頼パーティ銀行は申し出を信頼パーティに転送する。これで第１往復が完
了する。

【０１３２】 信頼パーティは、受諾メッセージを作成することによって第２往復を開始し、
信頼パーティは、信頼パーティ銀行に受諾メッセージを送信する。信頼パーティ
銀行は、発行銀行に受諾メッセージを転送する。それに応答して、発行銀行は保
証を作成し、それを信頼パーティ銀行に送信する。信頼パーティ銀行は保証を信
頼パーティに転送する。

【０１３３】 申し出および受諾メッセージの内部交換は、信頼パーティが、申し出を受諾す
るか、それとも拒絶するかを自身で決定したいことを示す場合にだけ必要である
。信頼パーティが申し出を自動的に受諾することを選ぶ場合、内部往復の必要は
ない。信頼パーティは、その信頼パーティ銀行に要求を送信し、信頼パーティ銀
行は、発行銀行にその要求を転送する。それに応答して、発行銀行は、保証を作
成し、それを信頼パーティ銀行に送信し、信頼パーティ銀行は、信頼パーティに
保証を転送する。

【０１３４】 保証プロトコルは、９個のＸＭＬメッセージを定義する。

【０１３５】 <!-Warranty Protocol DTD --> <!-- PUBLIC "-//CertCo//DTD WP 1.0//EN" --> <!-- SYSTEM "wp.dtd" --> <!ELEMENT wpmsg (warranty-request | interbank-request | interbank-offer | customer-offer | acceptance | interbank-acceptance | interbank-warranty | warranty | error) > <!ATTLIST wpmsg version CDATA #FIXED "1.0" >

【０１３６】 プロトコル中の全てのメッセージは、署名パーティの取引から切り離した署名
と、ＸＭＬ中で表される保証プロトコルメッセージとからなる。２つの構成要素
は、ＭＩＭＥマルチパート／メッセージ構造で搬送される。ＭＩＭＥ複数パーツ
／メッセージ構造は、ＳｉｇｎｅｄＤａｔａの実際の内容を形成する。メッセー
ジに対する内容タイプは、「データ」である。これは、ＣＭＳ指定ごとに内容タ
イプ署名属性として含まれる。したがってＭＩＭＥメッセージの構造は、以下の
とおりである。

【０１３７】 Content-Type: multipart/mixed; boundary=9afb45g -- 9afb45g Content-Type: applicaion/pkcs7-signature <base64 encoding of detached signature from signing party> -- 9afb45g Content-Type: text/plain <XML warranty request message> -- 9afb45g

【０１３８】 発行銀行からＲＰ銀行への保証メッセージをＲＰに伝えることが望ましい場合
、メッセージは、第３ＭＩＭＥボディ部分としてカプセル化することができる。

【０１３９】 保証要求（ＸＭＬ） 識別保証取引を開始するために、信頼パーティは、以下で定義する保証要求メ
ッセージと共に、署名パーティメッセージから切り離した署名を含むＣＭＳ Ｓ
ｉｇｎｅｄＤａｔａメッセージを作成する。

【０１４０】 保証要求メッセージは以下のように定義される。

【０１４１】 <!ELEMENT warranty-request (amount, expires) > <!ATTLIST warranty-request reptype (BID | BUY | ACCEPT) "BID") > <!ELEMENT amount (#PCDATA) > <!-- currency codes per ISO 4217 --> <!ATTLIST amount &currcodes; "USD" > <!ENTITY currcodes "( AED | AFA | ALL | AMD | ANG | AOK | AON | ARA | ARS | ATS | AUD | AWG | AZM | BAD | BBD | BDT | BEF | BGL | BHD | BIF | BMD | BND | BOB | BRE | BRL | BRR | BSD | BTN | BWP | BYB | BZD | CAD | CDF | CHF | CLP | CNY | COP | CRC | CUP | CVE | CYP | CZK | DEM | DJF | DKK | DOP | DZD | ECS | EEK | EGP | ERB | ESP | ETB | EUR | FIM | FJD | FKP | FRF | GBP | GEL | GHC | GIP | GMD | GNF | GNS | GQE | GRD | GTQ | GWP | GYD | HKD | HNL | HRK | HTG | HUF | IDR | IEP | ILS | INR | IQD | IRR | ISK | ITL | JMD | JOD | JPY | KES | KGS | KHR | KMF | KPW | KWD | KYD | KZT | LAK | LBP | LKR | LRD | LSL | LTL | LUF | LVL | LYD | MAD | MDL | MGF | MKD | MLF | MMK | MNT | MOP | MRO | MTL | MUR | MVR | MWK | MXP | MYR | MZM | NAD | NGN | NIC | NLG | NOK | NPR | NZD | OMR | PAB | PEI | PEN | PGK | PHP | PKR | PLZ | PTE | PYG | QAR | ROL | RUR | RWF | SAR | SBD | SCR | SDP | SEK | SGD | SHP | SIT | SKK | SLL | SOS | SRG | STD | SVC | SYP | SZL | THB | TJR | TMM | TND | TOP | TRL | TTD | TWD | TZS | UAH | UGS | UGX | USD | UYN | UYP | UYU | UZS | VEB | VND | VUV | WST | XAF | XCD | XDR | XEU | XOF | XPE | YER | YUN | ZAR | ZMK | ZRN | ZWD )" > <!ELEMENT expires (#PCDATA) > <!-- expiration time in ISO 8601 format --> <!-- an example --> <wpmsg> <warranty-request> <amount ccy="GBP">10000</amount> <expires>19990731T16:00:00</expires> </warranty-request> </wpmsg>

【０１４２】 保証金額は、信頼パーティがこの取引に関する証明書の識別の妥当性に対する
主張をそれに対して発行できる識別保証の最大値を指定する。

【０１４３】 「満了」は、識別保証契約に対する所望の持続時間を指定する。

【０１４４】 要求タイプは、信頼パーティが受諾メッセージを送信することによって申し出
を明示的に受け入れることを望むか（ｒｅｑＴｙｐｅは「ビッド」）、信頼パー
ティが申し出を最初に検討することなく暗黙的に受諾することを望むか（ｒｅｑ
Ｔｙｐｅは「購入」）、それとも信頼パーティが保証を購入するための署名パー
ティの申し出を受諾することを望むか（ｒｅｑＴｙｐｅは「受諾」）を指定する
。

【０１４５】 署名者の証明書連鎖は、別々のＸＭＬ要素としてではなく、切り離した署名で
搬送される。切り離した署名は、ＳｉｇｎｅｒＩｎｆｏ構造、バージョン番号、
要約アルゴリズムＩＤ、および（任意選択で）証明書からなる。

【０１４６】 信頼パーティは、切り離した署名ではなく、署名済み取引全体を含むことがで
きる。これは、ＭＩＭＥヘッダ以外のＣＭＳカプセル化メッセージ全体となるこ
とになる。内容タイプは、ａｐｐｌｉｃａｔｉｏｎ／ｐｋｃｓ７−ｍｉｍｅとな
ることになる。

【０１４７】 銀行間要求（ＸＭＬ） 信頼パーティ銀行は、銀行間要求を作成し、それを署名者から切り離した署名
と共に発行銀行に送信する。メッセージ内容および構造は、保証要求と同じであ
る。切り離した署名が署名者の証明書連鎖を含むことに留意されたい。

【０１４８】 <!ELEMENT interbank-request (amount, expires) > <!ATTLIST interbank-request reqtype (BID | BUY | ACCEP) "BID") >

【０１４９】 銀行間申し出（ＸＭＬ） 発行銀行は、メッセージ内容として原取引の切り離した署名および保証申し出
を含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成する。２つの構成要素は
、前述の通りＭＩＭＥマルチパート／混合メッセージとして構造化される。この
時点で切り離した署名から署名者の証明書連鎖を廃棄することができることに留
意されたい。

【０１５０】 申し出は以下のように定義される。

【０１５１】 <!ELEMENT interbank-offer (transid, amount, expires, fee, offer-expires) > <!ELEMENT transid (#PCDATA) > <!-- hash of the SignerInfo portion of the original detached signature structure --> <!ATTLIST transid algorithm (SHA1) #IMPLIED seq (#PCDATA) #REQUIRED > <!ELEMENT fee (#PCDATA) > <!ATTLIST fee ccy &currcodes; "USD"> <!ELEMENT offer-expires (#PCDATA) > <!-- offer expiration time in ISO 8601 format --> <!-- an example --> <wpmsg> <interbank-offer> <transid seq="1">IzBqNVNK45FZV1acHk8qDSouC9A=</transid> <amount ccy="GBP">10000</amount> <expires>19990731t16:00:00</expires> <fee ccy="GBP">10</fee> <offer-expires>19990611t14:20:00</offer-expires> </interbank-offer> </wpmsg>

【０１５２】 取引ＩＤは、同じ署名者契約および署名時間に対するプロトコルの多数の実行
を識別するシーケンス番号と共に、署名パーティＳｉｇｎｅｒＩｎｆｏのＤＥＲ
のＳＨＡ−１ハッシュからなる。取引ＩＤシーケンス番号は、発行銀行によって
割り当てられ、取引に関する最初の申し出に対して１から始まる。

【０１５３】 発行銀行は、取引ＩＤを使用して、保証についての同じ信頼パーティによる同
じ取引に対する多数の要求を調整する。各要求に対して、発行銀行は、新しいシ
ーケンス番号を有する新しい申し出を生成する。発行銀行が受諾メッセージを受
信したとき、発行銀行は、受諾メッセージ中の取引ＩＤを使用して、申し出を探
し出し、取引に対する全ての他の申し出を削除する。

【０１５４】 発行銀行は、既存の保証がまだ満了しない間に信頼パーティが同じ取引に対す
る第２の保証を得ることのないように取引ＩＤも使用する。

【０１５５】 申し出は、申し出のあった保証に対する金額および持続時間、保証手数料、お
よび申し出が有効な時間も識別する。

【０１５６】 顧客申し出（ＸＭＬ） 信頼パーティ銀行は、原取引の切り離した署名および申し出を含むＣＭＳ Ｓ
ｉｇｎｅｄＤａｔａメッセージを作成する。転送された申し出の構文は、銀行間
申し出と同一である。

【０１５７】 <!ELEMENT customer-offer (transid, amount, expires, fee, offer-expires) >

【０１５８】 受諾（ＸＭＬ） 信頼パーティは、原取引から切り離した署名および受諾メッセージを含むＣＭ
Ｓ ＳｉｇｎｅｄＤａｔａメッセージを作成する。

【０１５９】 <!ELEMENT acceptance (transid) > <!ATTLIST acceptance status (ACCEPT|REJECT) #REQUIRED>

【０１６０】 転送された受諾（ＸＭＬ） 信頼パーティ銀行は、原取引から切り離した署名および受諾メッセージを含む
ＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成する。メッセージは、顧客受諾
メッセージと同じ構文を有する。

【０１６１】 <!ELEMENT interbank-acceptance (transid) >

【０１６２】 銀行間保証（ＸＭＬ） 発行銀行は、原取引から切り離した署名および識別保証を含むＣＭＳ Ｓｉｇ
ｎｅｄＤａｔａメッセージを作成する。この保証は、以下の構文を有する。

【０１６３】 <!ELEMENT interbank-warranty (transid, warranty-request, amount, expires, fee) >

【０１６４】 保証要求は、保証への署名パーティおよび信頼パーティ入力を記録する。メッ
セージの残りは、保証金額、満了時間、および手数料を含む。

【０１６５】 識別保証（ＸＭＬ） 信頼パーティ銀行は、原取引から切り離した署名と、信頼パーティに発行すべ
き保証とを含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成する。この保証
は、銀行間保証と同じ構造を有する。

【０１６６】 <!ELEMENT warranty (transid, warranty-request, amount, expires, fee) >

【０１６７】 識別保証エラー（ＸＭＬ） 発行銀行または信頼パーティ銀行が、エラー処理要求に遭遇した場合、または
要求を拒絶することを選んだ場合、発行銀行または信頼パーティ銀行は、このエ
ラーメッセージを返す。銀行は、ＣＭＳメッセージ内容としてエラー（以下で説
明）および原取引の切り離した署名を含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセ
ージを作成する。

【０１６８】 発行銀行または信頼パーティ銀行のどちらかは、識別保証エラーメッセージを
生成することができる。メッセージは、発行銀行によって生成された識別保証エ
ラーが証明書ステータスを含まないという点だけが変化する。信頼パーティ銀行
が発行銀行によって生成されたエラーを受信したとき、信頼パーティ銀行は、発
行銀行エラーメッセージ内容に再署名し、証明書ステータスフィールドを作成し
、信頼パーティ銀行署名のみを有するメッセージを送信する。エラーメッセージ
上の発行銀行署名が有効であると判定される場合、プロトコルは、発行銀行およ
び信頼パーティ銀行ＳｉｇｎｅｒＩｎｆｏｓを有するエラーメッセージ内容から
構成される転送されたエラーを含むように拡張されることになる。

【０１６９】 <!ELEMENT error (error-text?, transid?, cert-status?) > <!ATTLIST error status (success|subscriber-ocsp-error| rp-ocsp-error|rp-service-ocsp-error|subscriber-service=error| exceeds-limit) #REQUIRED > <!ELEMENT error-text (#PCDATA) > <!ELEMENT cert-status (#PCDATA) > <!-- base64-encoded OCSP response message -->

【０１７０】 エラーがＯＣＳＰ応答によって引き起こされた場合、発行銀行は、エラーの証
明書ステータスフィールド中にＯＣＳＰ応答を含む。

【０１７１】 保証プロトコルＤＴＤ 保証プロトコルＤＴＤを以下に示す。

【０１７２】 <!-Warranty Protoclo DTD --> <!-- PUBLIC "-//CertCo//DTD WP 1.0//EN" --> <!-- SYSTEM "wp.dtd" --> <!ELEMENT wpmsg (warranty-request | interbank-request | interbank-offer | customer-offer | acceptance | interbank-acceptance| interbank-warranty | warranty | error) > <!ATTLIST wpmsg version CDATA #FIXED "1.0" > <!ELEMENT warranty-request (amount, expires) > <!ATTLIST warranty-request reqtype (BID | BUY | ACCEPT) "BID") > <!ELEMENT amount (#PCDATA) > <!-- currency codes per ISO 4217 --> <!ATTLIST amount &currcodes; "USD" > <!ENTITY currcodes "( AED | AFA | ALL | AMD | ANG | AOK | AON | ARA | ARS | ATS | AUD | AWG | AZM | BAD | BBD | BDT | BEF | BGL | BHD | BIF | BMD | BND | BOB | BRE | BRL | BRR | BSD | BTN | BWP | BYB | BZD | CAD | CDF | CHF | CLP | CNY | COP | CRC | CUP | CVE | CYP | CZK | DEM | DJF | DKK | DOP | DZD | ECS | EEK | EGP | ERB | ESP | ETB | EUR | FIM | FJD | FKP | FRF | GBP | GEL | GHC | GIP | GMD | GNF | GNS | GQE | GRD | GTQ | GWP | GYD | HKD | HNL | HRK | HTG | HUF | IDR | IEP | ILS | INR | IQD | IRR | ISK | ITL | JMD | JOD | JPY | KES | KGS | KHR | KMF | KPW | KWD | KYD | KZT | LAK | LBP | LKR | LRD | LSL | LTL | LUF | LVL | LYD | MAD | MDL | MGF | MKD | MLF | MMK | MNT | MOP | MRO | MTL | MUR | MVR | MWK | MXP | MYR | MZM | NAD | NGN | NIC | NLG | NOK | NPR | NZD | OMR | PAB | PEI | PEN | PGK | PHP | PKR | PLZ | PTE | PYG | QAR | ROL | RUR | RWF | SAR | SBD | SCR | SDP | SEK | SGD | SHP | SIT | SKK | SLL | SOS | SRG | STD | SVC | SYP | SZL | THB | TJR | TMM | TND | TOP | TRL | TTD | TWD | TZS | UAH | UGS | UGX | USD | UYN | UYP | UYU | UZS | VEB | VND | VUV | WST | XAF | XCD | XDR | XEU | XOF | XPE | YER | YUN | ZAR | ZMK | ZRN | ZWD )" > <!ELEMENT expires (#PCDATA) > <!-- expiration time in ISO 8601 format --> <!ELEMENT interbank-request (amount, expires) > <!ATTLIST interbank-request reqtype (BID | BUY | ACCEPT) "BID") > <!ELEMENT interbank-offer (transid, amount, expires, fee, offer-expires) > <!ELEMENT transid (#PCDATA) > <!-- hash of the SignerInfo portion on the original detached signature structure --> <!ATTLISTtransid algorithm (SHA1) #IMPLIED seq (#PCDATA) #REQUIRED > <!ELEMENT fee (#PCDATA) > <!ATTLIST fee ccy &currcodes; "USD"> <!ELEMENT offer-expires (#PCDATA) > <!-- offer expiration time in ISO 8601 format --> <!ELEMENT customer-offer (transid, amount, expires, fee, offer-expires) > <!ELEMENT acceptance (transid) > <!ATTLIST acceptance status (ACCEPT|REJECT) #REQUIRED > <!ELEMENT interbank-acceptance (transid) > <!ELEMENT interbank-warranty (transid, warranty-request, amount, expires, fee) > <!ELEMENT wattanty (transid, warranty-request, amount, expires, fee) > <!ELEMENT error (error-text?, transid?, cert-status?) > <!ATTLIST error status ((success|subscriber-ocsp-error| rp-ocsp-error|rp-service-ocsp-error|subscriber-service=error| exceeds-limit) #REQUIRED > <!ELEMENT error-text (#PCDATA) > <!ELEMENT cert-status (#PCDATA) > <!-- base64-encoded OCSP response message -->

【０１７３】 機能説明 本セクションでは、識別保証、証明書ステータス、および識別保証管理サービ
スについてのより詳しい詳細を提供する。図２０〜２８は、本発明によるサービ
スに関連するメッセージフローの詳細を示す。

【０１７４】 識別保証サービス 識別保証サービスは、信頼パーティ（ＲＰ）の要求に応答して識別保証を提供
する。ＲＰは、信頼パーティ銀行（ＲＰＢ）と直接通信し、信頼パーティ銀行（
ＲＰＢ）は、認証やＲＰ証明書のステータスの検証など、ＲＰに関するオペレー
ションを実行する。ＲＰと通信するＲＰＢ識別保証サービスは、ＲＰＢＩＷＳと
して知られる。これらのオペレーションが成功したと仮定すると、次いでＲＰＢ
は、要求に署名し、これを署名パーティの発行銀行（ＩＢ）に転送する。ＲＰＢ
と通信するＩＢ識別保証サービスは、ＩＢＩＷＳとして知られる。ＩＢは、識別
保証金額の支払いの認証および認可、ＲＰＢおよびＳＰ証明書の検証などのＲＰ
Ｂおよび署名パーティ（ＳＰ）に関するオペレーションを実行する。ＩＢは、Ｒ
ＰＢへの応答を送信し、ＲＰＢは、ＩＢ情報をそれ自体の情報と組み合わせ、署
名し、組み合わせた結果をＲＰに転送する。

【０１７５】 ＲＰＢＩＷＳおよびＩＢＩＷＳのオペレーションは、要求メッセージ中のｒｅ
ｑｕｅｓｔＴｙｐｅフィールドの値によって制御される。ｒｅｑｕｅｓｔＴｙｐ
ｅフィールドがｉｄ−−ｒｅｑｕｅｓｔＯｆｆｅｒに設定される場合、ＩＢは申
し出を作成し、これを送信し、ＲＰＢは申し出を更新し、これに署名し、ＲＰに
転送する。申し出は、申し出がそれ以降は有効でなくなる満了日付を含む。ＲＰ
が申し出を受諾することを望む場合、満了日付の前のある時点で、ＲＰは、受諾
メッセージを作成し、送信し、ＲＰＢは受諾メッセージを署名してＩＢに転送す
る。ＩＢは、保証金額を署名パーティ識別保証アカウントから支払い、保証メッ
セージを返し、ＲＰＢはそれを更新し、署名し、ＲＰに転送する。

【０１７６】 ｉｄ−−ｒｅｑｕｅｓｔＷａｒｒａｎｔｙに設定されたｒｅｑｕｅｓｔＴｙｐ
ｅフィールドを有する要求メッセージは、メッセージの内部往復を除去する。Ｉ
Ｂは、即時に保証金額を支払い（または支払いを拒否し）、保証メッセージをＲ
ＰＢに返す。ＲＰＢは、保証を更新し、これに署名し、ＲＰに転送する。保証は
、メッセージ交換を完了する。ＲＰは、受諾メッセージを送信しない。

【０１７７】 全ての接続は、クライアント認証（すなわちクライアント証明書）を用いるＳ
ＳＬ ｖ３を使用することが好ましい。

【０１７８】 申し出および受諾を伴うＲＰＢ識別保証サービス：第１往復 図２０を参照すると、信頼パーティ銀行識別保証サービス（ＲＰＢＩＷＳ）は
、信頼パーティ銀行（ＲＰＢ）と発行銀行（ＩＢ）ＲＭサーバによって提供され
る識別保証サービスへの信頼パーティのポータルである。

【０１７９】 ＲＰＢＩＷＳは、識別保証金額のローカルデータベースと、ルートおよびＲＰ
Ｂリポジトリとに対して信頼パーティ（ＲＰ）を認証する。次いで、ＲＰＢＩＷ
Ｓは、ＲＰの識別保証アカウント中の支出収支および支出制限値に対する要求を
認可する。

【０１８０】 支出収支および支出制限フィールドは、ＲＰが依然としてそれに対する識別保
証手数料を支払わなければならない識別保証の合計値を制限する。要求を認可す
るために、ＲＰＢは、要求の支出収支および保証金額を支出制限と比較する。合
計が制限を超過する場合、ＲＰＢは、適切なステータス値を有するエラーメッセ
ージを送信する。

【０１８１】 銀行は、ＲＭと共に銀行特有の要求許可方法を登録することによって要求認可
を拡張することを選ぶこともできる。

【０１８２】 要求を認可した後、ＲＰＢＩＷＳは、そのＲＰＢ識別保証キーで要求に署名し
、要求のログをとり、ＩＢに要求を転送し、ＩＢ応答を待つ。ＩＢが要求を受諾
した場合、ＩＢは申し出を返し、そうでない場合は、エラーを返す。

【０１８３】 ＲＰＢＩＷＳが申し出をＩＢから受信したとき、ＲＰＢＩＷＳは、識別保証金
額のローカルデータベースおよびリポジトリに対してＩＢを認証する。次いで、
ＲＰＢＩＷＳは、例えばそれ自体の課金をｗａｒｒａｎｔｙＦｅｅに加えるなど
、ＩＢ申し出を更新する。

【０１８４】 最終的に、ＲＰＢＩＷＳは、そのＲＰＢ識別保証キーで申し出に署名し、申し
出のログをとり、申し出をＲＰに転送する。

【０１８５】 ＲＰＢＩＷＳがＩＢからエラーを受信した場合、ＲＰＢＩＷＳは、識別保証金
額のローカルデータベースおよびリポジトリに対してＩＢをやはり認証する。次
いで、ＲＰＢＩＷＳは、それ自体のエラーメッセージを生成し、ＩＢエラーステ
ータスをコピーまたは更新し、そのＲＰＢ識別保証キーでエラーに署名し、エラ
ーのログをとり、エラーをＲＰに送信する。

【０１８６】 信頼パーティ銀行要求／転送申し出の詳細に関連するメッセージフローを、図
２０を参照しながら以下に説明する。

【０１８７】 １．メッセージ内容を要求する（１）： ｉ．署名者契約 ｉｉ．要求（ｉｄ−−ｒｅｑｕｅｓｔＯｆｆｅｒに設定されたｒｅｑｕｅｓｔ
Ｔｙｐｅ） ２．要求のログをとる（２）。 ３．ＲＰを認証する：要求中のＲＰ識別保証証明書からのアカウントがアカウ
ントデータベース中に存在すること、およびアカウント中のＳＳＬクライアント
証明書識別子がセッションに対するＳＳＬ証明書とマッチすることを確認する（
３）。 ４．要求を認可する：要求保証金額の合計と、ＲＰ識別保証アカウント中の支
出収支フィールドとがＲＰ識別保証アカウント中の支出制限フィールドを超過し
ていないかを確認し、銀行ＲＰ認可方法が登録されている場合、それを起動する
（４）。 ５．ＲＰ証明書を検証する：ＲＰユーティリティ証明書のための拡張を確認す
る。ＲＰ識別保証証明書についての連鎖中の証明書のための拡張を確認する。Ｒ
Ｐ識別保証証明書連鎖のステータスおよびＲＰＢリポジトリＯＣＳＰ証明書のた
めのＲＰＢおよびルートリポジトリを確認し、ＯＣＳＰ応答のログをとる（５、
６） ６．要求に署名し、それを署名パーティ証明書のためにＩＢに転送する。応答
を待ち、応答のログをとる（７、８、９）。 ７．申し出またはエラーを認証する：申し出またはエラー中のＩＢ識別保証証
明書からのアカウントがアカウントデータベース中に存在すること、およびアカ
ウント中のＳＳＬクライアント証明書識別子がセッションについてのＳＳＬサー
バ証明書とマッチすることを確認する（１０）。 ８．ＩＢ証明書を検証する：ＩＢ識別保証証明書のための拡張を確認する。Ｉ
Ｂ識別保証証明書のステータスをルートリポジトリに照会し、ＯＣＳＰ応答のロ
グをとる（１１、１２）。 ９．ルートリポジトリにＲＰＢ識別保証証明書のステータスを照会する（１３
）。ＲＰＢ識別保証証明書に対する署名済み応答により、ＲＰが、ルートリポジ
トリ証明書のローカルコピーと共にＲＰＢ識別保証証明書のステータスを検証す
ることが可能となる。 １０．転送された申し出またはエラーを更新し、署名し、ログをとる（１４）
。 １１．転送された申し出またはエラーをＲＰに送信する（１５）。

【０１８８】 ＲＰＢＩＷＳは、申し出中の取引ＩＤと、ＩＢおよび申し出自体とを関連付け
るテーブルを維持し、その結果ＲＰＢＩＷＳは、どこに受諾メッセージを転送す
べきか、受諾を認可するためにどの保証金額を使用すべきかを認識する。

【０１８９】 申し出および受諾によるＩＢ識別保証サービス：第１往復 発行銀行識別保証サービス（ＩＢＩＷＳ）は、識別保証アカウントについての
識別保証の支払いに対する発行銀行の制御を提供する。ＩＢＩＷＳはｒｅｑｕｅ
ｓｔＴｙｐｅがｉｄ−−ｒｅｑｕｅｓｔＯｆｆｅｒにセットされた転送要求を受
信すると、ＲＰＢおよび署名パーティを識別保証アカウントのローカルデータベ
ースおよびルートおよびＩＢリポジトリに照らして認証することにより開始する
。次いでＩＢＩＷＳは転送された要求を認可する。認可決定への入力は次のもの
を含む。

【０１９０】 １．アクティブな保証のリスト ２．署名パーティによって課せられる制限（署名者契約中の） ３．署名パーティについての未処理識別保証金額に対する制限 ４．署名パーティのグループについての未処理識別保証金額に対する制限

【０１９１】 ＩＢＩＷＳはまず、この署名済み取引についての保証がまだ有効であるか否か
を調べるために、アクティブな保証のリストを走査する。保証は取引ＩＤのコピ
ーを含み、ｃｏｎｔｒａｃｔＤｉｇｅｓｔハッシュはこれについて署名済み取引
中の署名者契約のインスタンスを一意に識別する。この署名済み取引についての
保証がまだ有効であるか否かを判定するために、ＩＢＩＷＳはこの要求のｃｏｎ
ｔｒａｃｔＤｉｇｅｓｔハッシュを生成し、同じ値の取引ＩＤを有するものを求
めて現在の保証のリストを走査する。これは、ＩＢＩＷＳが、以前に発行された
保証の満了後に同一のＳｉｇｎｅｒＣｏｎｔｒａｃｔについての保証を繰り返し
発行することを妨げないことに留意されたい。ＲＰが同じＳｉｎｇｅｒＣｏｎｃ
ｔａｃｔについての保証を繰り返し獲得できないようにすることをＳＰが望む場
合は、ＳＰはＳｉｎｇｅｒＣｏｎｔｒａｃｔ自体の保証期間の制限を指定しなく
てはならない。

【０１９２】 ＩＢＩＷＳは次いで、転送された要求を署名者契約中の制限に照らして認可す
る。署名パーティは、保証金額や、保証期間、保証を要求するＲＰの識別の任意
の組み合わせを任意選択で制限することが可能である。

【０１９３】 ａ）要求中の保証金額が署名者契約中の保証金額を超える場合、 ｂ）あるいは要求中の保証期間が署名者契約中の保証期間を超える場合、 ｃ）あるいは要求中のＲＰ識別保証証明書が署名者契約中のＲＰ識別と一致し
ない場合には、ＩＢＩＷＳは転送された要求を適切なステータスコードを用いて
拒否する。

【０１９４】 ＩＢＩＷＳは次いで ａ）要求中の保証金額と、 ｂ）ＳＰ識別保証アカウント中の保証収支フィールド との合計が、同一アカウント中の保証制限フィールドを超えないことを確認す
る。最後に、ＳＰがグループのメンバーである場合ＩＢＩＷＳは、 ａ）要求中の保証金額と、 ｂ）そのグループアカウントについての保証収支フィールド との合計がそのグループの保証制限フィールドを超えないことを確認する。

【０１９５】 銀行はまた、ＲＭを用いた銀行固有の転送要求認可方法を登録することにより
、転送された要求の認可を拡張するように選択することもできる。要求の認可後
、ＩＢＩＷＳは銀行固有の方法を起動して保証料を計算し、完了した申し出をロ
ーカルデータベース中に記録するが、ＩＢＩＷＳはこれを使用して、転送された
受諾メッセージ（存在する場合に）のタイムリー性（ｔｉｍｅｌｉｎｅｓｓ）を
検証する。ＩＢＩＷＳはこの時に、その申し出のために一意の取引ＩＤの生成も
行う。ＲＰは、同一の署名者契約に対して複数の申し出を要求できる。ＩＢＩＷ
Ｓは、同一の取引ＩＤｃｏｎｔｒａｃｔＤｉｇｅｓｔを有する申し出の列挙とし
て計算される取引ＩＤ中の連続番号を含むことにより、同一の署名者契約に対す
る異なる申し出間の区別をつける。最後にＩＢＩＷＳは申し出に署名し、そのロ
グをとり、それをＲＰＢに送信する。

【０１９６】 上記に関連するメッセージフローは図２１を参照して説明する。 １．転送された要求のメッセージ内容（１）： ｉ．署名者契約 ｉｉ．要求（ｒｅｑｕｅｓｔＴｙｐｅはｉｄ−−ｒｅｑｕｅｓｔＯｆｆｅｒに
セットされる） ｉｉｉ．ＲＰＢ情報 ２．転送された要求のログをとる（２） ３．ＲＰＢおよびＳＰを認証する：ＲＰＢおよびＳＰ識別保証証明書からのア
カウントがデータベース中に存在することと、ＲＰＢ識別保証アカウント中のＳ
ＳＬクライアント証明書識別子がそのセッションのＳＳＬクライアント証明書と
一致することを確認する（３）。 ４．転送された要求を認可する：この転送された要求についてはアクティブな
保証が存在しないことを確認し、転送された要求中の識別保証金額が署名者契約
中の識別保証金額制限を超えないことを確認し、要求の時間が署名者契約中の識
別保証時間制限を超えないことを確認し、識別信頼パーティ証明書が署名者契約
中の信頼パーティＩＤと一致することを確認し、識別保証金額が、ＳＰ識別保証
アカウントまたはＳＰ識別保証アカウントのグループについての収支にその制限
を超えさせないことを確認し、登録されているものがあればその銀行の要求認可
方法を起動する（４）。 ５．ＲＰＢおよびＳＰ証明書を検証する：ＲＰＢユーティリティ証明書につい
ての拡張を確認し、ＲＰＢおよびＳＰ識別保証証明書の連鎖中の証明書について
の拡張を確認し、ＲＰＢおよびＳＰ識別保証証明書の連鎖中の証明書ステータス
と、ＩＢリポジトリＯＣＳＰ証明書とについてＩＢおよびルートリポジトリを確
認し、ＯＣＳＰ応答のログをとる（５、６）。 ６．申し出に署名し、そのログをとり、ＯＣＳＰ応答のログをとる（７）。 ７．申し出をＲＰＢに送信する（８）。

【０１９７】 ＩＢＩＷＳは満了日によって分類された未処理申し出のリストを維持し、それ
を周期的に走査して、満了日を過ぎた申し出、およびＲＰＢから転送された受諾
メッセージの処理にも使用される申し出を除去する。このリストは取引ＩＤを申
し出および署名パーティ識別保証アカウントと関連付ける。

【０１９８】 申し出および受諾によるＲＰＢ識別保証サービス；第２往復 ＲＰＢ申し出メッセージを受信しそれを検討すると、ＲＰクライアントは申し
出を受諾するかまたは拒否するかを選択し、その決定（受諾または拒否）を示す
フィールドを備える受諾メッセージをＲＰＢＩＷＳに送信する。あるいは、ＲＰ
がその申し出を受諾しないことを選択した場合は、ＲＰは受諾メッセージを送信
せずに単にその申し出を満了させることができる。信頼パーティ銀行識別保証サ
ービス（ＲＰＢＩＷＳ）は、識別保証アカウントのローカルデータベースとルー
トおよびＲＰＢリポジトリに照らしてＲＰを認証する。ＲＰＢＩＷＳは次いで、
信頼パーティの識別保証アカウント中の支出収支（Ｓｐｅｎｄｉｎｇ Ｂａｌａ
ｎｃｅ）および支出制限値（Ｓｐｅｎｄｉｎｇ Ｌｉｍｉｔ ｖａｌｕｅｓ）に
照らして受諾を認可する。

【０１９９】 ＲＰＢＩＷＳは、要求を認可したのと同じ方法、すなわち支出収支と要求の保
証金額との合計を支出制限と比較することにより受諾を認可する。ＲＰＢＩＷＳ
は、供給されるものがあれば銀行供給の要求認可方法も起動する。例えばＲＰが
異なる要求に対する申し出を受け取った場合など、ＲＰＢＩＷＳが対応する要求
を受け取り、認可した後に支出収支値が変化している可能性があるので、ＲＰＢ
ＩＷＳは要求からの金額を２度目に認可する。

【０２００】 支出収支と申し出の保証金額の合計が支出制限よりも少ない場合、ＲＰＢＩＷ
Ｓは申し出からの保証金額を支出収支に加算し、その取引のログをとる。したが
って２往復バージョンの識別保証プロトコルの場合、ＲＰＢはＲＰを２度認可す
る：１度目は要求、要求中の金額についてであり、この時点では支出収支は修正
されない。２度目は受諾、申し出中の金額についてであり、支出収支はこの時点
で修正される（この２度の認可は、転送された申し出および転送された受諾メッ
セージを認可するＩＢＩＷＳ手順と一致する。ＲＰＢＩＷＳおよびＩＢＩＷＳは
どちらも、ＲＰおよびＳＰ識別保証アカウント中の支出収支および保証収支フィ
ールドを更新する前に受諾メッセージを待つ。代替の設計は、要求メッセージの
認可がうまく行ったことに応答して収支フィールドを更新するものであり、これ
には２度目の認可を必要としないという望ましい特性がある。不都合なことには
、これはまた、同一の署名者契約に対する連続した要求が、人為的に膨張された
収支に照らして認証される（または認証されない）ことも意味する。ＩＢＩＷＳ
は１つの申し出しか受諾せず、この時点で、拒否されたすべての申し出について
の保証金額はＳＰおよびＲＰアカウント収支にフローバックすることになる）。

【０２０１】 受諾の認可後、ＲＰＢＩＷＳはそのＲＰＢ識別保証キーによりその受諾に署名
し、その受諾のログをとり、その受諾をＩＢに転送し、ＩＢ応答を待つ。ＩＢが
受諾を承認する場合、ＩＢは保証を戻す。承認しない場合にはエラーを戻す。

【０２０２】 ＲＰＢＩＷＳはＩＢから保証を受け取ると、識別保証アカウントのローカルデ
ータベースおよびリポジトリに照らしてそれを認証する。ＲＰＢＩＷＳは次いで
、例えばそれ自体の料金をｗａｒｒａｎｔｙＦｅｅに加算するなど、ＩＢ保証を
更新する。ＲＰＢは、保証中の保証金額が申し出中の金額と異なる場合には支出
収支の調整も行わなければならない。ＲＰがその保証について銀行に支払いをす
ると、ＲＭ管理者は支出収支を保証金額で減分する。最後にＲＰＢＩＷＳはその
ＲＰＢ識別保証キーで保証に署名し、その保証のログをとり、その保証をＲＰに
転送する。

【０２０３】 ＲＰＢＩＷＳはＩＢからエラーを受信した場合でも、それを識別保証アカウン
トのローカルデータベースおよびリポジトリに照らして認証する。次いでＲＰＢ
ＩＷＳはＩＢエラーステータスをコピーまたは更新してそれ自体のエラーメッセ
ージを生成し、そのＲＰＢ識別保証キーによりそのエラーに署名し、そのエラー
のログをとり、そのエラーをＲＰに送信する。ＲＰＢはまた、支出収支から申し
出保証金額を減分する。

【０２０４】 申し出および受諾によるｒｐｂ識別保証サービスに関連するメッセージフロー
：第２往復は図２２を参照して説明する。

【０２０５】 １．ＲＰ受諾メッセージ内容（１）： ｉ．受諾（取引ＩＤ、ステータス） ２．受諾のログをとる（２）。 ３．ＲＰを認証する：要求中のＲＰ識別保証証明書からのアカウントがアカウ
ントデータベース中に存在することと、そのアカウント中のＳＳＬクライアント
証明書識別子がそのセッションのＳＳＬクライアント証明書と一致することを確
認する。また、申し出についての記録（取引ＩＤによりローカルテーブル中に記
憶されている）が存在することを確認する（３）。 ４．受諾を認可する：識別保証金額とＲＰ識別保証アカウント支出収支フィー
ルドとの合計が、ＲＰ識別保証アカウント支出制限フィールドを超えないことを
確認し、登録されたものがある場合は銀行要求認可方法を起動する（４）。 ５．ＲＰ証明書を検証する：ＲＰユーティリティ証明書について拡張を確認し
；ＲＰ識別保証証明書の連鎖中の証明書についての拡張を確認し；ＲＰ識別保証
証明書連鎖のステータスおよびＲＰＢリポジトリＯＣＳＰ証明書について、ＲＰ
Ｂおよびルートリポジトリを確認し、ＯＣＳＰ応答のログをとる（５、６）。 ６．信頼パーティ識別保証アカウント要求収支を識別保証金額で更新する（７
）。 ７．署名パーティ証明書についてのＩＢに対する受諾に署名し、それを転送す
る；応答を待ち、応答のログをとる（８、９、１０）。 ８．保証またはエラーを認証する：保証中のＩＢ識別保証証明書からのアカウ
ントがアカウントデータベース中に存在することと、そのアカウント中のＳＳＬ
クライアント証明書識別子がそのセッションについてのＳＳＬサーバ証明書と一
致することを確認する（１１）。 ９．ＩＢ証明書を検証する：ＩＢ識別保証証明書についての拡張を確認し；Ｉ
Ｂ識別保証証明書のステータスについてのルートリポジトリを照会し、ＯＣＳＰ
応答のログをとる（１２、１３）。 １０．必要な場合は、信頼パーティ識別保証アカウント支出収支を識別保証金
額で調整（ｒｅｃｏｎｃｉｌｅ）する（１４）。 １１．ＲＰＢ識別保証証明書のステータスについてルートリポジトリを照会す
る（１５）。ＲＰＢ識別保証証明書に対する署名済みの応答と、ルートリポジト
リ証明書のローカルコピーとにより、ＲＰがＲＰＢ識別保証証明書のステータス
を検証することが可能になる。 １２．転送された保証を生成し、それに署名し、そのログをとる（１６）。 １３．転送された保証をＲＰに送信する（１７）。

【０２０６】 申し出および受諾によるＩＢ識別保証サービス：第２往復 ａｃｃｅｐｔａｎｃｅＳｔａｔｕｓフィールドがｉｄ−−ａｃｃｅｐｔＳｔａ
ｔｕｓにセットされた転送された受諾メッセージの受信は、ＩＢＩＷＳに、識別
保証値を支払うように信号を送る。ＩＢＩＷＳはまず、識別保証アカウントのロ
ーカルデータベースおよびルートリポジトリに照らしてＲＰＢを認証する。ＩＢ
ＩＷＳは次いで取引ＩＤを使用して、その申し出がまだ満了していないことを検
証するためにその未処理申し出の内部テーブル中で申し出の位置を突き止める。
申し出が満了していない場合、ＩＢＩＷＳは転送された受諾を認可する。

【０２０７】 転送された受諾を認可するために、ＩＢＩＷＳはＳＰ識別保証アカウントおよ
びＳＰグループアカウント（存在する場合）中の保証収支に照らして申し出中の
保証金額を確認する。ＩＢＩＷＳはまた、供給されるものがある場合には銀行に
より供給される、転送された受諾の認可方法も起動する。

【０２０８】 他のＲＰ（または同じＲＰでも）がＳＰに対する追加の識別保証を実行し、そ
れにより、ＩＢＩＷＳが要求からの金額を認可した時と転送された受諾を認可し
た時との間でＳＰ識別保証アカウント金額収支フィールド中の値が変更されてい
る場合、ＩＢＩＷＳは転送された要求からの金額を２度目に認可する。

【０２０９】 保証収支が保証制限よりも少ない場合、ＩＢＩＷＳはＳＰおよびＳＰグループ
アカウント中の識別保証収支に識別保証金額を加算する。これは、保証が満了す
るまでＳＰおよびＳＰグループにとって利用可能な保証金額を効果的に減らし、
この時にＩＢＩＷＳは保証金額をＳＰおよびＳＰグループアカウント収支フィー
ルドから減算することにより保証金額をプールに戻す。

【０２１０】 ＩＢＩＷＳはまた、保証の記録をアクティブな保証の内部リストに追加して、
保証の満了後にＩＢＩＷＳが保証金額を戻すことができ（クレームが申し立てら
れないと仮定すると）、またＩＢＩＷＳが同一の署名者契約に対する重複要求を
検出できるようにする。ＩＢＩＷＳはまた、同一の取引ＩＤのｃｏｎｔｒａｃｔ
Ｄｉｇｅｓｔハッシュを持つエントリについて未処理申し出のリストを走査し、
一致するものをそれぞれ除去することができる（これはそれほど重要ではない最
適化である。これを行わなくとも、ＩＢＩＷＳタイマは最終的に満了時にエント
リを除去する）。

【０２１１】 最後にＩＢＩＷＳは保証を生成し、それに署名し、そのログをとり、それをＲ
ＰＢに送信する。

【０２１２】 申し出および受諾によるｉｂ識別保証サービスに関するメッセージフロー：第
２往復は図２３を参照して説明する。

【０２１３】 １．転送された受諾メッセージの内容（１）： ｉ．受諾（取引ＩＤ、ステータス） ｉｉ．ＲＰＢ情報 ２．転送された受諾のログをとる（２）。 ３．ＲＰＢを認証する：ＲＰＢ証明書からのアカウントがデータベース中に存
在することと、ＲＰＢ識別保証アカウント中のＳＳＬクライアント証明書識別子
がそのセッションについてのＳＳＬクライアント証明書と一致することを確認す
る（３）。 ４．転送された受諾を認可する：その申し出が満了していないことを確認し、
識別保証アカウントが、ＳＰ識別保証アカウントまたはＳＰ識別保証アカウント
のグループについての収支にその制限を超えさせていないことを確認し、登録さ
れているものがあれば銀行申し出認可方法を起動し、識別保証アカウント金額を
更新する（４）。 ５．ＲＰＢおよびＳＰ証明書を検証する：ＲＰＢユーティリティ証明書につい
ての拡張を確認し；ＲＰＢ識別保証証明書の連鎖中の証明書についての拡張を確
認し；ＲＰＢおよびＳＰの連鎖中の証明書のステータスについてＩＢおよびルー
トリポジトリを確認し、ＯＣＳＰ応答のログをとる（５、６）。 ６．ＳＰ識別保証およびＳＰグループアカウント中の保証収支を更新する（７
）。 ７．保証に署名し、そのログをとる（８）。 ８．保証をＲＰＢに送信する（９）。

【０２１４】 申し出および受諾を伴わないＲＰＢ識別保証サービス ｒｅｑｕｓｅｔＴｙｐｅフィールドがｉｄ−−ｒｅｑｕｅｓｔＷａｒｒａｎｔ
ｙにセットされた要求メッセージは、メッセージの内部ラウンド（ｉｎｎｅｒ
ｒｏｕｎｄ）を除去する。ＩＢは保証金額をただちに支払い（あるいは支払うこ
とを拒否し）、保証（またはエラー）メッセージを戻す。ＲＰＢは保証（または
エラー）を更新し、それに署名し、それをＲＰに転送する。この保証はメッセー
ジ交換を完了する。ＲＰは受諾メッセージを送信しない。

【０２１５】 メッセージフローおよび処理ステップは、２部分からなるバージョンのプロト
コルの場合の相当するステップと同じである。

【０２１６】 信頼パーティ銀行識別保証サービス（ＲＰＢＩＷＳ）は、識別保証アカウント
のローカルデータベースと、ルートおよびＲＰＢリポジトリとに照らしてＲＰを
認証する。ＲＰＢＩＷＳは次いで、支出収支、および信頼パーティの識別保証ア
カウント中の支出制限値に照らして要求を認可する。

【０２１７】 支出収支と要求の保証金額の合計が支出制限より少ない場合、ＲＰＢＩＷＳは
、要求からの金額を支出収支に加算し、その取引のログをとる。

【０２１８】 要求の認可後、ＲＰＢＩＷＳはそのＲＰＢ識別保証キーで要求に署名し、その
要求のログをとり、その要求をＩＢに転送し、ＩＢ応答を待つ。ＩＢがその要求
を承認する場合、ＩＢは保証を戻す。承認しない場合はエラーを戻す。

【０２１９】 ＲＰＢＩＷＳはＩＢから保証を受け取ると、識別保証アカウントのローカルデ
ータベースおよびリポジトリに照らしてそのＩＢを認証する。ＲＰＢＩＷＳは次
いで、例えばそれ自体の料金をｗａｒｒａｎｔｙＦｅｅに加算するなど保証の更
新を行う。ＲＰＢはまた、保証中の保証金額が要求中の金額と異なる場合には支
出収支を調整しなければならない。ＲＰがその保証について銀行に支払いをする
と、ＲＭ管理者は保証金額で支出収支を減分する。

【０２２０】 最後にＲＰＢＩＷＳはそのＲＰＢ識別保証キーで保証に署名し、その保証のロ
グをとり、その保証をＲＰに転送する。

【０２２１】 ＲＰＢＩＷＳはＩＢからエラーを受け取った場合でも、識別保証アカウントの
ローカルデータベースおよびリポジトリに照らしてそのＩＢを認証する。ＲＰＢ
ＩＷＳは次いでＩＢエラーステータスをコピーまたは更新してそれ自体のエラー
メッセージを生成し、そのＲＰＢ識別保証キーでそのエラーに署名し、そのエラ
ーのログをとり、そのエラーをＲＰに送信する。

【０２２２】 申し出および受諾を伴わないＲＰＢ識別保証サービスに関連するメッセージフ
ローは、図２４を参照して説明する。

【０２２３】 １．要求メッセージ内容（１）： ｉ．署名者契約 ｉｉ．要求（ｒｅｑｕｅｓｔＴｙｐｅはｉｄ−−ｒｅｑｕｅｓｔＷａｒｒａｎ
ｔｙにセットされる） ２．要求のログをとる（２）。 ３．ＲＰを認証する：要求中のＲＰ識別保証証明書からのアカウントがアカウ
ントデータベース中に存在することと、そのアカウント中のＳＳＬクライアント
証明書識別子がそのセッションについてのＳＳＬクライアント証明書と一致する
ことを確認する（３）。 ４．要求を認可する：識別保証金額とＲＰ識別保証アカウント支出収支フィー
ルドの合計がＲＰ識別保証アカウント支出制限フィールドを超えないことを確認
し、登録されているものがあれば銀行要求認可方法を起動する（４）。 ５．ＲＰ証明書を検証する：ＲＰユーティリティ証明書についての拡張を確認
し、ＲＰ識別保証証明書の連鎖中の証明書についての拡張を確認し；ＲＰ識別保
証証明書連鎖のステータスおよびＲＰＢリポジトリについてＲＰＢおよびルート
リポジトリを確認し、ＯＣＳＰ応答のログをとる（５、６）。 ６．識別保証金額で信頼パーティ識別保証アカウント要求収支を更新する（７
）。 ７．要求に署名し、それを署名パーティ証明書のＩＢに転送し；応答を待ち、
応答のログをとる（８、９、１０）。 ８．保証またはエラーを認証する：保証中のＩＢ識別保証証明書からのアカウ
ントがアカウントデータベース中に存在することと、そのアカウント中のＳＳＬ
クライアント証明書識別子がそのセッションについてのＳＳＬサーバ証明書と一
致することを確認する（１１）。 ９．ＩＢ証明書を検証する：ＩＢ識別保証証明書についての拡張を調べ；ＩＢ
識別保証証明書のステータスについてルートリポジトリを照会し、ＯＣＳＰ応答
のログをとる（１２、１３）。 １０．必要であれば、信頼パーティ識別保証アカウント支出収支を識別保証金
額で調整する（１４）。 １１．ＲＰＢ識別保証証明書のステータスについてルートリポジトリを照会す
る（１５）。ＲＰＢ識別保証証明書に対する署名済みの応答と、ルートリポジト
リ証明書のローカルコピーとにより、ＲＰがＲＰＢ識別保証証明書のステータス
を検証することが可能になる。 １２．転送された保証に署名し、そのログをとる（１６）。 １３．転送された保証をＲＰに送信する（１７）。

【０２２４】 申し出および受諾を伴わないＩＢ識別保証サービス ｉｄ−−ｒｅｑｕｅｓｔＷａｒｒａｎｔｙにセットされたｒｅｑｕｅｓｔＴｙ
ｐｅフィールドを有する転送された要求メッセージはメッセージの内部ラウンド
を除去する。ＩＢは保証金額をただちに支払い（または支払いを拒否し）、保証
メッセージを戻す。

【０２２５】 メッセージフローおよび処理ステップは、２部分からなるバージョンのプロト
コルの場合の相当するステップと同じである。

【０２２６】 ＩＢＩＷＳは識別保証アカウントのローカルデータベースと、ルートおよびＩ
Ｂリポジトリとに照らしてＲＰＢと署名パーティを認証する。ＩＢＩＷＳは次い
で転送された要求を認可する。この認可プロセスは上記のものと同じである。

【０２２７】 転送された要求の認可後、ＩＢＩＷＳはＳＰおよびＳＰグループアカウント中
の識別保証収支に識別保証金額を加算する。これは、保証が満了するまでＳＰお
よびＳＰグループにとって利用可能な保証金額を効果的に減らし、ＩＢＩＷＳは
この時にその保証金額をＳＰおよびＳＰグループアカウント収支フィールドから
減算することにより、保証金額をプールに戻す。

【０２２８】 ＩＢＩＷＳはまた保証の記録をアクティブな保証の内部リストに加えて、保証
の満了後にＩＢＩＷＳが保証金額を戻すことができ（クレームが申し立てられな
いと仮定すると）、またＩＢＩＷＳが同一の署名者契約についての保証に対する
重複した転送要求を検出できるようにする。

【０２２９】 ＩＢＩＷＳは次いで、保証料を計算するために銀行固有の方法を起動する。

【０２３０】 最後にＩＢＩＷＳは保証を生成し、それに署名し、そのログをとり、それをＲ
ＰＢに転送する。

【０２３１】 申し出および受諾を伴わないＩＢ識別保証サービスに関する詳細なメッセージ
フローは図２５を参照して説明する。

【０２３２】 １．転送された要求メッセージの内容（１）： ｉ．署名者契約 ｉｉ．要求（ｒｅｑｕｅｓｔＴｙｐｅはｉｄ−−ｒｅｑｕｅｓｔＷａｒｒａｎ
ｔｙにセットされる） ｉｉｉ．ＲＰＢ情報 ２．転送された要求のログをとる（２）。 ３．クライアントを認証する：ＲＰＢおよび署名パーティ識別保証証明書から
のアカウントがデータベース中に存在することと、ＲＰＢ識別保証アカウント中
のＳＳＬクライアント証明書識別子がそのセッションについてのＳＳＬクライア
ント証明書と一致することを確認する（３）。 ４．転送された要求を認可する：転送された要求中の識別保証金額が署名者契
約中の制限を超えないことと、それが、署名パーティ識別保証アカウントまたは
署名パーティ識別保証アカウントのグループの収支にその制限を超えさせないこ
とを確認する（４）。 ５．クライアント証明書を検証する：信頼パーティ銀行ユーティリティ証明書
について拡張を確認し；信頼パーティ銀行および署名パーティ識別保証証明書の
連鎖中の証明書について拡張を確認し；信頼パーティ銀行および署名パーティ識
別保証証明書の連鎖中の証明書のステータスについて信頼パーティ銀行およびル
ートリポジトリを確認し、ＯＣＳＰ応答のログをとる（５、６）。 ６．ＳＰ識別保証およびＳＰグループアカウント中の保証収支を更新する（７
）。 ７．保証に署名し、そのログをとる（８）。 ８．保証をＲＰＢに送信する（９）。

【０２３３】 証明書ステータスサービス 証明書ステータスサービス（ＣＳＳ）は、証明書がＣＡによって発行されたこ
とと、その証明書が取り消されていないことを判定する。ＣＳＳはそのローカル
証明書ステータスサービスと直接通信して、そのＣＡによって発行された証明書
のステータスを判定する。異なるＣＡによって発行された証明書のステータスを
判定するには、ＣＳＳはＲＰであるかのように新しい要求を作成し、その要求を
他銀行のＣＳＳに送信する。

【０２３４】 ＣＳＳはＯＣＳＰプロトコルを介してクライアントおよび他のＲＭと通信する
。さらにＣＳＳはクライアントを認証し、ＯＣＳＰ取引の記録を保存して、その
記録を使用してサービス使用についての請求書を作成できるようにする。クライ
アントを認証するために、ＣＳＳは、クライアントがその識別保証証明書秘密キ
ーでそのＯＣＳＰ要求に署名することを求める。その要求がＳＳＬを使用した場
合、ＣＳＳはＲＰＢＩＷＳおよびＩＢＩＷＳと同じ認証アルゴリズムに従い、す
なわちＲＰ識別保証証明書についてアカウントが存在することと、そのアカウン
ト中のユーティリティ証明書識別子がＲＰのＳＳＬクライアント証明書と一致す
ることを検証する。ＣＳＳは、クライアントがＲＰであろうとあるいは他銀行の
ＲＭのＣＳＳであろうとクライアントを認証し、これは、各ＲＭがそのパートナ
ーＲＭのための識別保証アカウントを含まなければならないことを意味すること
に留意されたい。ＣＳＳから見ると、別の銀行のＲＭは非常にアクティブなＲＰ
であるように見える。

【０２３５】 また、ＣＳＳはＯＣＳＰ要求を処理する（ｓｅｒｖｅ）が要求を直接満たすの
ではなく、ローカルバンクまたはおそらくはリモートバンクＲＭの証明書ステー
タスサービスに対する代理として機能することにも留意されたい。ＣＳＳは、そ
れ自体のＯＣＳＰ要求およびトップレベルの証明書のローカルコピーを通じてこ
れらの証明書ステータスサービスおよびメッセージを認証する。代理ＯＣＳＰと
して、ＣＳＳはＯＣＳＰノンス（ｎｏｎｃｅ）アルゴリズムを実施しなければな
らず、またローカルリポジトリおよび近隣ＲＭのＣＳＳによって戻されたノンス
を検証しなければならない。

【０２３６】 ローカル証明書 ＣＳＳは、ＲＰの認証および検証によって開始する。ＣＳＳはＲＰ識別保証証
明書のためにアカウントが存在することを確認する。ＲＰがＳＳＬを使用した場
合、ＣＳＳはアカウント中のユーティリティ証明書識別子がＳＳＬクライアント
証明書と一致することを確認する。ＣＳＳは最後にそのローカルリポジトリを用
いてＲＰ証明書のステータスを確認し、またリポジトリを用いてそのリポジトリ
証明書のステータスを確認する。ＣＳＳがクライアントを正常に認証する場合、
ＣＳＳは次いでＲＰのＯＣＳＰ要求中の証明書ステータスについてそのローカル
リポジトリを確認する。完全性のために、ＣＳＳはリポジトリを用いて再度ロー
カルリポジトリ証明書のステータスについて確認する。ＣＳＳは証明書要求のロ
グをとり、ＯＣＳＰ応答をフォーマットし、それに署名し、それをＲＰに送信す
ることにより終了する。

【０２３７】 図２６を参照すると、 １．ＯＣＳＰ要求内容（１）： ｉ．証明書連鎖（この銀行のためのＣＡによって発行された証明書に対して） ｉｉ．ＲＰ署名および証明書連鎖 ２．ＲＰを認証する：要求中の信頼パーティ識別保証証明書からのアカウント
がアカウントデータベース中に存在することと、そのアカウント中のＳＳＬクラ
イアント証明書識別子がそのセッションについてのＳＳＬクライアント証明書と
一致することを確認する（２）。 ３．ＲＰ証明書を検証する：ＲＰユーティリティ証明書（存在する場合）につ
いての拡張を確認し；ＲＰ識別保証証明書の連鎖中の証明書についての拡張を確
認し；ＲＰ証明書のステータスについてＲＰＢリポジトリを確認し；ＲＰＢリポ
ジトリおよびＲＰＢ ＣＡ証明書のステータスについてリポジトリを確認する（
３、４）。 ４．要求される証明書を検証する：要求の証明書のステータスについてＲＰＢ
リポジトリを確認し；ＲＰＢリポジトリおよびＲＰＢ ＣＡ証明書のステータス
についてルートリポジトリを調べる（５、７）。 ５．取引を記録する（７） ６．ＯＣＳＰ応答に署名し、それをＲＰに戻す（８）。

【０２３８】 リモート証明書 ＣＳＳはＲＰの認証および検証によって開始する。ＣＳＳは、ＲＰ識別保証証
明書のためにアカウントが存在することを確認する。ＲＰがＳＳＬを使用した場
合、ＣＳＳは、アカウント中のユーティリティ証明書識別子がＳＳＬクライアン
ト証明書と一致することを検証する。最後に、ＣＳＳはそのローカルリポジトリ
を用いてＲＰ証明書のステータスを確認し、またリポジトリを用いてそのリポジ
トリ証明書のステータスを確認する。ＣＳＳが正常にクライアントを認証する場
合、ＣＳＳは次いでＲＰのＯＣＳＰ要求中の証明書に対するＯＣＳＰ要求をフォ
ーマットし、それをその証明書を発行した銀行の信頼マネージャのＣＳＳに転送
する。ローカルＣＳＳは、ルートリポジトリでリモートＣＳＳ証明書を検証する
ことにより応答を認証する。

【０２３９】 図２７を参照すると、 １．ＯＣＳＰ要求内容（１）： ｉ．証明書連鎖（リモート銀行のＣＡによって発行された証明書についての） ｉｉ．ＲＰ署名および証明書連鎖 ２．クライアントを認証する：要求中の信頼パーティ識別保証証明書からのア
カウントがアカウントデータベース中に存在することと、そのアカウント中のＳ
ＳＬクライアント証明書識別子がそのセッションについてのＳＳＬクライアント
証明書と一致することを確認する（２）。 ３．ＲＰ証明書を検証する：ＲＰユーティリティ証明書（存在する場合）につ
いて拡張を確認し；ＲＰ識別保証証明書の連鎖中の証明書について拡張を確認し
；ＲＰ証明書のステータスについてＲＰＢリポジトリを確認し；ＲＰＢリポジト
リおよびＲＰＢ証明書のステータスについてリポジトリを確認する（３、４）。 ４．ＲＰ要求中の証明書に対するＯＣＳＰ要求を作成する。それをリモートＣ
ＳＳ（発行銀行）に転送する。 ｉ．証明書連鎖（リモート銀行のためのＣＡによって発行された証明書につい
ての） ｉｉ．ＲＰＢ署名および証明書連鎖 ５．ＲＰＢを認証する：要求中の信頼パーティ銀行識別保証証明書からのアカ
ウントがアカウントデータベース中に存在することと、そのアカウント中のＳＳ
Ｌクライアント証明書識別子がそのセッションについてのＳＳＬクライアント証
明書と一致することを確認する（６）。 ６．ＲＰＢ証明書を検証する：ＲＰＢユーティリティ証明書についての拡張を
確認し；ＲＰＢ識別保証証明書の連鎖中の証明書についての拡張を確認し；ＲＰ
Ｂ識別保証証明書のステータスについてリポジトリを確認する（７）。 ７．要求される証明書を検証する：要求される証明書のステータスについてＩ
Ｂリポジトリを確認し；ＩＢリポジトリおよびＩＢ ＣＡ証明書のステータスに
ついてルートリポジトリを確認する（８、９）。 ８．取引を記録する（１０） ９．ＯＣＳＰ応答に署名し、それをＲＰＢに戻す（１１）。 １０．応答を検証する：ＩＢ証明書のステータスについてリポジトリを確認す
る（１２）。 １１．取引を記録する（１３） １２．ＯＣＳＰ応答に署名し、それをＲＰＢに戻す（１４）。

【０２４０】 識別保証管理サービス 識別保証管理サービス（ＩＷＭＳ）は、ＲＭサーバに対する管理アクションを
実施する。管理コマンドはいくつかのターゲットに対して機能する：識別保証ア
カウント、ＲＰＢＩＷＳ識別保証取引ログ、ＩＢＩＷＳ取引ログ、未処理識別保
証のＩＢ内部リスト、ＣＳＳログ、ＩＷＭＳログ。管理コマンドはターゲットご
とに異なる。多くのターゲットにとって、唯一の管理コマンドは選択基準（例え
ば日付の範囲）を与えられてエントリのレポートを戻すことである：ＲＰＢＩＷ
Ｓ識別保証取引ログ、ＩＢＩＷＳ取引ログ、ＣＳＳログ、ＩＷＭＳログ。他のタ
ーゲットは作成、修正、削除、および承認コマンドもサポートする：識別保証ア
カウント、ＩＢＩＷＳ認可、ＩＢＩＷＳ保留コマンド、未処理識別保証（例えば
クレームを受けるエントリをマークするなど）のＩＢ内部リスト。管理コマンド
の最後のグループはＲＭサーバ自体の動作を制御する：認可データベース記録の
編集、ルーティングテーブルの編集など。

【０２４１】 ＩＷＭＳはＵＲＬによって区別される２つのプロトコルをサポートする：１つ
はレポート用であり、１つは他のすべての管理コマンド用である。レポートコマ
ンドは単に、ＳＳＬｖ３を介してクライアント証明書とともに伝達されるＨＴＴ
Ｐ ＰＯＳＴメッセージである。レポート応答は、元のＨＴＴＰ ＰＯＳＴから
の要求と一致する、コンマで区切られたデータ行である。ＩＷＭＳは銀行のリポ
ジトリでＳＳＬクライアント（ユーティリティとしても知られる）証明書のステ
ータスを検証することにより、クライアントを認証する。ＩＷＭＳは「レポート
」管理コマンド、管理コマンドターゲット、およびＳＳＬクライアント（ユーテ
ィリティとしても知られる）からの主ＤＮ（Ｓｕｂｊｅｃｔ ＤＮ）を、認可デ
ータベース中でリストされるそのＤＮに対してリストされる特権と比較すること
により、クライアントを認証する。

【０２４２】 すべての他のコマンドはＣＭＳＳｉｇｎｅｄＤａｔａデータメッセージとして
コード化され、署名は管理者の識別保証証明書秘密キーによって生成され、メッ
セージはＳＳＬｖ３を介してクライアント証明書とともに（ＲＰＢＩＷＳ、ＩＢ
ＩＷＳ、およびＣＳＳと同様に）伝達される。ＲＰＢＩＷＳ、ＩＢＩＷＳおよび
ＣＳＳと同様にＩＷＭＳクライアントが認証され、ＩＷＭＳクライアント証明書
のステータスが検証される。次いで、管理コマンド、管理コマンドターゲット、
およびクライアント証明書からの主ＤＮを、認可データベース中でリストされる
ＤＮに対する特権（生成、修正、削除、承認、レポートなど）と比較することに
より、要求中の管理コマンドが認可される。

【０２４３】 識別保証アカウントを作成、修正、あるいは削除するＩＷＭＳコマンドは、作
成または編集コマンドを最初に提出する管理者のアクションと、そのコマンドを
承認する１人または複数の認可者のアクションとを必要とする複数部分からなる
変更プロセスを実施する。この変更は、定数の管理者がコマンドを承認するとき
にのみデータベースに適用される。コマンドを提出および承認することの許可は
ＲＭ認可データベースによって制御される。他のサービスと同様に、管理コマン
ドはログに記録され、管理者は認可データベースにおけるその権利に応じてレポ
ートを生成するコマンドを起動することができる。

【０２４４】 ＩＷＭＳレポートコマンド 図２８の図中、「認可ＤＢ」はＩＢＩＷＳ認可データベースであり、「アカウ
ントおよびログ」は識別保証アカウント、ＲＰＢＩＷＳ識別保証取引ログ、ＩＢ
ＩＷＳ取引ログ、ＣＳＳログ、および未処理識別保証のＩＢ内部リストを表し、
「保留取引」はＩＢＩＷＳ保留コマンドを表し、「管理ログ」はＩＷＭＳログを
表す。

【０２４５】 図２８を参照すると、 １．管理レポートコマンドメッセージ内容（１）： ｉ．例えば「識別保証アカウント」などの管理コマンドターゲット ｉｉ．レポート選択基準（例えば「１／１／９１から１／２／９１までのすべ
ての記録」など） ２．レポート要求のログをとる（２）。 ３．コマンドを認可する：ユーティリティ証明書からの主ＤＮについてのＩＷ
ＭＳ認可データベースのエントリが、管理コマンドターゲットに対する「レポー
ト」許可をリストした記録を含むことを確認する（３）。 ４．管理者証明書を検証する：ユーティリティ証明書についての拡張を確認し
；ユーティリティ証明書のステータスについて銀行リポジトリを確認し、ＯＳＣ
Ｐ応答のログをとる（４、５）。 ５．コマンドを実行する：データベースに記憶された手順（またはメッセージ
ログのためのディレクトリリスト手順）を起動して、要求中で指定されるターゲ
ットに対するレポート応答を生成する（６）。 ６．応答を戻す（７）。

【０２４６】 他のＩＷＭＳコマンド 「レポート」以外の管理コマンドはＣＭＳＳｉｇｎｅｄＤａｔａメッセージと
してコード化され、ＳＳＬｖ３を介してクライアント証明書とともに伝達される
。クライアント認証およびクライアント証明書の検証は、ＲＰＢＩＷＳ、ＩＢＩ
ＷＳおよびＣＳＳの場合と同じである。認可は、ＩＷＭＳ認可データベースおよ
び必要とされる定数の承認者を介して管理される。

【０２４７】 図２９の図中、「認可ＤＢ」はＩＢＩＷＳ認可データベースであり、「アカウ
ントおよびログ」は識別保証アカウント、ＲＰＢＩＷＳ識別保証取引ログ、ＩＢ
ＩＷＳ取引ログ、ＣＳＳログ、および未処理識別保証のＩＢ内部リストを表し、
「保留取引」はＩＢＩＷＳ保留コマンドを表し、「管理ログ」はＩＷＭＳログを
表している。

【０２４８】 図２９を参照すると、 １．管理コマンドメッセージ内容（１）： ｉ．ＡｄｍｉｎＲｅｑｕｅｓｔ（コマンド、ターゲット、パラメータ） ２．要求のログをとる（２）。 ３．管理者を認証する：要求中の管理者識別保証証明書からのアカウントがア
カウントデータベース中に存在することと、そのアカウント中のＳＳＬクライア
ント証明書識別子がそのセッションについてのＳＳＬクライアント証明書と一致
することを確認する（３）。 ４．管理者に対するコマンドを認可する：管理コマンドおよびターゲットを、
ＩＷＭＳ認可データベース中の管理者識別保証証明書主ＤＮについてリストされ
る許可と比較する（４）。 ５．管理者証明書を検証する：管理者ユーティリティ証明書について拡張を確
認し；管理者識別保証証明書の連鎖中の証明書についての拡張を確認し；ＲＰ証
明書のステータスについて銀行リポジトリを確認し；銀行リポジトリおよび銀行
ＣＡ証明書のステータスについてリポジトリを確認し、ＯＣＳＰ応答のログをと
る（５、６）。 ６．コマンドを実行する： ｉ．作成された、編集、削除コマンド抽出が、新エントリをＩＷＭＳ保留コマ
ンドデータベースに加える（７）。 ｉ．承認コマンドが、ＩＷＭＳ保留コマンドデータベースからのエントリをタ
ーゲットに適用する（８）。 ７．取引を記録し（９）、 ８．応答に署名し、そのログをとり、それを戻す（１０、１１）。

【０２４９】 ＩＷＭＳ認可データベース ＲＭは認可モデルを実施して、要求されるその操作を銀行員が実行することを
許可するか許可しないかを決定する。このモデルは、署名パーティの識別名に従
って署名パーティデータベースを区分する。アクセス制御ファイル中のエントリ
は、クライアントとして知られるどの被雇用者が、ターゲットとして知られるツ
リーの特定ブランチへのアクセス権を有するか、またクライアントがブランチ下
のエンティティに対してどのタイプの操作を実行することができるのかを指定す
る。例えば

【０２５０】

【表２】

【０２５１】 操作の実行をクライアントに認可するか否かを決定する際は、最長のＤＮマッ
チ（すなわち最低レベルのもの）が使用される。上記の例では、エージェント９
９がエージェント８６の証明書を取り消そうとした場合、第１のエントリではな
く第２のエントリが使用され、この操作は許可されないことになる。この短い要
約はモデルを正当に扱ってはいないが、我々はこれが補助者（ｓｕｂｓｉｄｉａ
ｒｙ）に対する適切な委任をサポートするのに十分な柔軟性があるものと信ずる
。

【０２５２】 アカウント修正は、それが複数のパーティによって承認されなければならない
という追加要件を有する可能性がある。最初の実施により、各ＲＭが修正操作に
対して実行時間定数を設定することが可能になる。適切な銀行員がＡＭＳに接続
すると、彼らは「変更の要求」を見るか、あるいは自身の要求を追加することが
できる。要求が必要定数によって承認されると、ＲＭは変更に作用する。イニシ
エータは変更要求をキャンセルすることが可能である。

【０２５３】 ＣＭＳプロファイル 本セクションでは、以下のようなＣＭＳの使用について紹介する。 １．署名者から信頼パーティへの初期メッセージ ２．信頼パーティから信頼パーティ銀行への識別保証要求 ３．信頼パーティ銀行から発行銀行へ転送される、識別保証要求 ４．発行銀行から信頼するパーティ銀行への識別保証申し出 ５．信頼パーティ銀行から署名パーティへ転送される、識別保証申し出 ６．信頼パーティから信頼パーティ銀行への識別保証受諾 ７．信頼パーティ銀行から発行銀行へ転送される、識別保証受諾 ８．発行銀行から信頼パーティ銀行への識別保証 ９．信頼パーティ銀行から信頼パーティへ転送される、識別保証

【０２５４】 証明書のプロファイル仕様では、表記法が定義されている。以下の図では次の
とおりである。 １）「サポート」列は、作成（ｏｒｉｇｉｎａｔｉｏｎ）および受取りに関す
る要件を示し、たとえば「ｏ／ｍ」は、要素の作成は任意選択であり受取りは必
須であることを意味する。 ２）「ｍ」は、サポートが必須であることを示す（ただし要素はあらゆるメッ
セージに存在する必要はない）。 ３）「ｏ」は、サポートが任意選択であることを示す。 ４）「ｘ」は、要素が禁止されていることを示す。 ５）「ｒ」は、要素が存在する必要があることを示す（作成時）。

【０２５５】 初期取引

【０２５６】

【表３】

【０２５７】

【表４】

【０２５８】 識別保証要求

【０２５９】

【表５】

【０２６０】

【表６】

【０２６１】 転送された識別保証要求

【０２６２】

【表７】

【０２６３】

【表８】

【０２６４】

【表９】

【０２６５】 識別保証申し出

【０２６６】

【表１０】

【０２６７】

【表１１】

【０２６８】

【表１２】

【０２６９】 転送された識別保証申し出

【０２７０】

【表１３】

【０２７１】 識別保証受諾

【０２７２】

【表１４】

【０２７３】

【表１５】

【０２７４】 転送された識別保証受諾

【０２７５】

【表１６】

【０２７６】 識別保証

【０２７７】

【表１７】

【０２７８】

【表１８】

【０２７９】 転送された識別保証

【０２８０】

【表１９】

【０２８１】 識別保証エラー

【０２８２】

【表２０】

【０２８３】

【表２１】

【０２８４】 データベース設計 本セクションでは、信頼マネージャ（ＲＭ）データベース、４つのＲＭサービ
スがアカウント情報のストアおよび操作に使用する構成要素、取引ログ、および
管理認可レコードについて説明する。具体的に言えばこのセクションでは、デー
タベーススキーマ、すなわちテーブル、そのフィールド、およびテーブル間の関
係の列挙、データベース情報の検索および操作に使用されるストアドプロシージ
ャ、データベースのストアドプロシージャへのアクセスを提供するクラスライブ
ラリについて説明する。

【０２８５】 本セクションでは、以下の用語が使用される。

【０２８６】 認可データベース：管理コマンドを認可するためにデータベースで保守される
（セキュア）識別子に関する権利の列挙。

【０２８７】 保証：オンラインクライアントによって証明された損失の金額に対して、記名
者の秘密キーによって署名された契約に関する記名者証明書の識別を保証するオ
ンラインサービス。

【０２８８】 外部キー（ｆｏｒｅｉｇｎ ｋｅｙ）：値が他のデータベーステーブルにある
１次キー（ｐｒｉｍａｒｙ ｋｅｙ）の値と一致する、データベーステーブル内
の列。

【０２８９】 １次キー：行を固有に識別する、データベーステーブル内の列または列の組合
せ。

【０２９０】 通常の操作中、ＲＭ機能は以下を含む様々な情報へのアクセスを必要とする。

【０２９１】 ・記名者および信頼パーティアカウント ・取引ログ ・未決定の管理取引 ・管理認可レコード

【０２９２】 この情報は、発行パーティ銀行および信頼パーティ銀行側のＳＱＬデータベー
ス内で維持される。ＲＭサービスは、データベースにアクセスするために、ＯＤ
ＢＣ上で階層化されたクラスライブラリを使用する。（本セクションで使用され
る場合、ＯＤＢＣとはオープンデータベース接続、すなわちいずれの特定データ
ベース管理システム（ＤＢＭＳ）からも独立した書込みアプリケーションを可能
にするアプリケーションプログラミングインターフェース（ＡＰＩ）を示す。）
ストアドプロシージャは、実際のデータ操作および取出しを実行するものであっ
て、クラスライブラリの１次関数は、Ｃ＋＋引数をストアドプロシージャのそれ
と結合させ、その後ストアドプロシージャを呼び出すものである。好ましい一実
施形態では、Ｗｉｎｄｏｗｓ（登録商標） ＮＴ（商標）でＳＱＬサーバ（商標
）を使用し、ＯＤＢＣを使用して他の環境、たとえばＵｎｉｘ（登録商標）での
Ｏｒａｃｌｅ（登録商標）への移植性を向上させる。

【０２９３】 ガーディアンデータベースへはＯＤＢＣを介してアクセスするため、ＯＤＢＣ
クラスライブラリおよび関連付けられたドライバの使用可能度に依拠する。これ
らの構成要素は、現在初期ターゲットプラットフォーム（ＮＴ／ＳＱＬサーバ）
に使用可能である。ＯＤＢＣドライバは、Ｓｕｎ Ｓｏｌａｒｉｓ、ＨＰ−ＵＸ
、およびＩＢＭ ＡＩＸ を含む、いくつかのＵｎｉｘ（登録商標）バリアント
上で実行中の、Ｏｒａｃｌｅ、Ｉｎｆｏｒｍｉｘ、およびＳｙｂａｓｅを含む他
のデータベースに使用可能である。

【０２９４】 ＲＭアーキテクチャは、１つ（または複数）の信頼パーティまたは記名者証明
書が与えられたデータベースアカウントを識別するためのメカニズムに依存する
。ＰＫＩアーキテクチャ仕様証明書プロファイルは、データベースアカウントへ
の証明書を関連付けるためのメカニズムとして、ｇｕａｒｄｉａｎＡｃｃｏｕｎ
ｔＮｕｍｂｅｒ属性でｓｕｂｊｅｃｔＤｉｒｅｃｔｏｒｙＡｔｔｒｉｂｕｔｅｓ
拡張の使用を規定する。

【０２９５】 任意の関係データベースを使用して、ＲＭデータベース内の情報は１組のテー
ブルにストアされる。このセクションでは、これらのテーブル、その内容、およ
び相互関係について説明する。

【０２９６】 データベースは、銀行が、発行銀行と信頼パーティ銀行の両方の役割を同時に
果たすことができるという事実を反映している。したがって、それぞれの役割に
ついて、固有のアカウントおよび取引ログテーブルが存在する。特定銀行が１つ
の役割だけを果たしている場合、他の役割に関連付けられたテーブルは存在する
が、空のままである。

【０２９７】 アカウント：アカウント情報は、記名者および信頼パーティアカウントテーブ
ルにストアされる。アカウントは、証明書のｇｕａｒｄｉａｎＡｃｃｏｕｎｔＮ
ｕｍｂｅｒ拡張属性で使用できる、アカウント番号によって固有に識別される。
作成時、アカウントには、アカウントの作成者を識別する親アカウント番号が割
り当てられる。アカウントは、保証取引に期限を適用するのに使用され、信頼パ
ーティの場合は証明書ステータス取引を制限するのに使用される。また、識別（
または保証）証明書とユーティリティ（すなわちＳＳＬ）証明書とを相互参照す
るのにも使用される。最終的にアカウントには、管理コマンドの認可時に使用さ
れる区別された名前が含まれる。

【０２９８】 ログ：監査、請求、契約満了時の保証回復、およびエラーに直面した場合の撤
回をサポートするために、すべてのＲＭアクティビティが１組の取引ログに記録
される。記名者および信頼パーティログテーブルは、この目的で働く。

【０２９９】 各クラスのＲＭアクティビティについて、以下を含む別々のテーブルが保守さ
れる。

【０３００】 ・保証取引 ・証明書ステータス要求 ・管理アクティビティ（アカウントの作成、修正など） ・保証取引ログへの変更 保全性を持たせるためにデータベースが更新され、ＳＱＬ取引ステートメント
を使用する極小アクションとして付属のログ操作が実行される。

【０３０１】 管理認可テーブル 認可モデルは、管理コマンドの実行を制御するものである。たとえば、新規ア
カウントを追加しようとする銀行員は、そうするための許可を受けなければなら
ない。管理認可テーブルには、クライアント（すなわち銀行員）が特定ターゲッ
ト（すなわち記名者組織）に対して実行することを認可されたアクション（すな
わちアカウント作成）を指定するレコードが含まれる。クライアントおよびター
ゲットは、区別された名前（ＤＮ）を使用して指定される。

【０３０２】 未決定の管理取引 ＲＭ管理サービス方針は、管理操作が実行前に承認されることを必要とする。
前の例によれば、銀行員はアカウント作成を要求し認可されることが可能であり
、銀行マネージャは、最終的にこの要求を承認すると予測される。このモデルで
は、未決定管理要求が、承認される（または拒否される）まで、データベース内
にセーブする必要がある。未決定の取引テーブルは、承認を待っている管理要求
をセーブする。

【０３０３】 各エントリには、アクションコード、ターゲットアカウント（信頼パーティま
たは署名パーティ）インジケータ、クライアントおよびターゲットＤＮ、アカウ
ント番号、およびＢＬＯＢ（バイナリ大規模オブジェクト（ｂｉｎａｒｙ ｌａ
ｒｇｅ ｏｂｊｅｃｔ））を含む、要求された管理取引を再構築するのに十分な
情報が含まれる。ＢＬＯＢコンテンツは、データベースによって解釈されるもの
ではなく、追加のコマンド特有データを格納するためのＲＭ管理サービスに関す
る単なる便利なメカニズムである。

【０３０４】 ストアドプロシージャ データベースアクティビティは、ＲＭサービスがＲＭＤＢライブラリを介して
アクセスする、１組のストアドプロシージャとして実施されることが好ましい。
ストアドプロシージャは、以下のそれぞれのアクションを実行するために使用可
能である。

【０３０５】 ・信頼パーティ ・保証取引の実行 ・保証取引のログ ・保証取引ログからレポートを作成 ・証明書ステータス取引の実行 ・証明書ステータス取引のログ ・証明書ステータス取引ログからのレポート作成 ・アカウントの作成／編集 ・アカウントのログ作成／編集 ・管理認可レコードの作成／編集 ・管理認可レコードのログ作成／編集 ・署名パーティ ・保証取引の実行 ・保証取引のログ ・保証取引ログの編集 ・保証取引ログのログ編集 ・アカウントの作成／編集 ・アカウントのログ作成／編集 ・管理認可レコードの作成／編集 ・管理認可レコードのログ作成／編集 通常の環境下では、ログ関数は基礎となる操作の一部として自動的に起動され
ることに留意されたい。たとえば、「保証取引の実行」は、保証取引を実行中に
「保証取引のログ」を直接呼出す。ただし、ＲＭサービスが検出した無効証明書
の受取りなどのエラー状態をサポートするために、ログ関数には高位階層から直
接アクセスすることもできる。

【０３０６】 ＲＭＤＢライブラリ ＲＭＤＢライブラリは、データベースのストアドプロシージャにアクセスする
ために、ＲＭサービスによって使用されるインターフェースを提供する。ライブ
ラリ内の関数とデータベースストアドプロシージャとの１対１マッピングがある
。典型的なライブラリ関数は、Ｃ＋＋引数のセットと、ストアドプロシージャの
それとを結合させ、ストアドプロシージャを呼び出して、ストアドプロシージャ
のステータスを呼出し側に戻す。ライブラリは、Ｕｎｉｘ（登録商標）／Ｏｒａ
ｃｌｅなどの他のプラットフォームへポートできるように、ＯＤＢＣ上で階層化
される。

【０３０７】 サービス機能 ＲＭサービスはすべて、最高の相互操作性、スケーラビリティ、および使用可
能性を提供するように実施される。ＲＭサービスは、相互操作性を最大にするた
めに標準プロトコルを使用することが好ましい。フロントエンド（すなわちクラ
イアント）では、ＲＭプロトコルが標準的なＷｅｂプロトコル、データタイプ、
および符号化アルゴリズムを使用することが好ましい。

【０３０８】 それぞれのＲＭサービス、すなわち証明書ステータス、識別保証、識別保証管
理は、アプリケーションペイロードがＣＭＳである、ＨＴＴＰ ＰＯＳＴ／ＲＥ
ＳＰＯＮＳＥメッセージペアとして実施されることが好ましい。

【０３０９】 標準プロトコルを使用すると、クライアントソフトウェアの複雑さが最小限に
抑えられる。ＲＭメッセージは、クライアントが証明書ステータスまたは要求を
生成するために、署名およびＣＭＳプラグインのサービスのみを必要とするよう
に設計される。応答の妥当性検査およびアーカイビングは、追加の機能を必要と
することに留意されたい。

【０３１０】 バックエンド（すなわちデータベース）では、ＲＭサービスは、標準ＳＱＬで
作成され汎用データベースＡＰＩを介してアクセスされたストアドプロシージャ
を呼び出すことが好ましい。ストアドプロシージャのリストには、必要なデータ
ベースのリストがすべて記載されている。この方法は、使用可能なサービスおよ
びスケーラビリティ要件に応じて、様々なデータベースが可能となるように設計
される。

【０３１１】 多数のアカウントおよび大容量のネットワークトラフィックにスケールアップ
するための機能は、ソフトウェアとハードウェアのサポートを複雑に組み合わせ
る必要がある。ＲＭサービスは、高いスケーラビリティをサポートするプラット
フォームに移行できるように実施される。

【０３１２】 実施アーキテクチャは、多重プロセッサシステムと円滑に適合し、これをフル
に利用する同期および非同期制御フロー（たとえばスレッド）のために、標準的
で移送が簡単なプログラミングアブストラクトを使用することが好ましい。

【０３１３】 ＲＭサービスは、ソフトウェアアーキテクチャとデータベースサービスとを混
合することによって、高い使用可能性を達成する。フルタイム操作を実施するた
めに、ＲＭ管理サービスは、プロトコルのランタイムロードおよびアンロード、
ならびに他のサービスを提供することが好ましい。同様に、ソフトウェアアーキ
テクチャは、動的メモリやネットワーク接続などの制約付き資源を精密に監視お
よび管理する。

【０３１４】 ローカルハードウェアの故障および他のネットワーク障害シナリオから回復す
るために、ＲＭサービスは、複製データベースと結合させると、ホットスタンバ
イモードで実行することができる。データベースは、スタンバイサーバがネット
ワーク外に常駐する場合に、遠隔サイトへのアカウントおよび取引情報の複製お
よび配布を管理する。１次サイトで電力またはネットワークの障害が発生すると
、企業は新しいサーバに要求を転送するために、バックアップサイトをネットワ
ークに接続し、そのネットワーク構成内でルーチン情報を更新する。

【０３１５】 信頼パーティアーキテクチャ ＲＰ環境は、スタンドアロンのコマンドラインツールから、ＳＡＰ、Ｐｅｏｐ
ｌｅＳｏｆｔなどの所与の銀行に特有のＷｅｂブラウザまたはクライアント環境
などのアプリケーション環境内で統合されたサービスまで、広範囲に渡るもので
あることが多い。

【０３１６】 ＲＰを特定のクライアント環境に制限しないために、ＲＭソフトウェアは、ソ
フトウェア開発キットとしてのＲＰサービス（ＲＰＳＤＫ）を提供する。ＲＰＳ
ＤＫには、すべてのクライアントサービスに関する参照クライアントと共に、識
別保証、証明書ステータス、およびＲＭ管理サービスを呼び出すための、ライブ
ラリ機能および文書が含まれる。

【０３１７】 ＲＰＳＤＫは、暗号トークンサービスインターフェースを介して暗号機能を呼
び出す。トークンの実施間で適合性を最大にするために、ＲＰＳＤＫはＰＫＣＳ
＃１１によって指定された暗号デバイスインターフェースを使用する。

【０３１８】 セキュリティに関する考慮事項 本発明に従ったＲＭシステムは、クライアント証明書でＳＳＬ ｖ３を実施し
、トランスポートレベルの統合性およびデータのプライバシーを達成するために
これを使用することが好ましい。さらにＲＭサーバは、ＳＳＬ ｖ３を使用して
、制限付きのホストベース認証使用も達成する。

【０３１９】 アプリケーションレベルのセキュリティは、認証および認可サービスを提供す
る。アプリケーションレベルのプライバシーに関するサポートは、暗号証明され
た秘密キーに関するサポートと一緒に実施されることが好ましく、この時点では
計画されていない。

【０３２０】 ＲＭクライアント（信頼パーティおよび管理者の両方）が要求に署名し、ＲＭ
サーバがＲＭの使用を証明されたキーで署名応答する。ＲＭクライアントには、
その要求内の証明連鎖が含まれ、ＲＭサーバには、クライアントで必要なインテ
リジェンスの量を少なくするための応答内での連鎖が含まれる。

【０３２１】 メッセージの保全性を検証するために、ＲＭのサーバおよびクライアントはパ
ートナの証明書内で公開キーを使用して、要求および応答ＰＤＵ上で署名を再作
成し、比較する。

【０３２２】 クライアントを認証するために、ＲＭサーバは第１に証明書からのアカウント
番号を使用し、適切なＲＭアカウントデータベースからのアカウントについてＳ
ＳＬクライアント証明書を検索する。アカウントおよびＳＳＬクライアント証明
書が有効であれば、次いでＲＭサーバはレベル１銀行およびリポジトリをチェッ
クして、クライアントの証明書連鎖内にあるすべての証明書が発行済みであり、
クライアントの証明書連鎖内の証明書が１つも取り消されていないことを検証す
る。

【０３２３】 応答を準備するために、サーバは、ローカルへのＯＣＳＰクエリおよびリポジ
トリを送信することで、独自の証明書連鎖の取り消されていないステータスを検
証する。サーバには、クライアントに戻すＰＤＵ内に、ＯＣＳＰ応答ならびにリ
ポジトリ署名が含まれる。

【０３２４】 ＲＭクライアントは、ルートおよび銀行リポジトリＯＣＳＰ署名証明書のロー
カルコピーを使用してサーバの応答を認証する。サーバの応答を認証および検証
するために、クライアントは証明書のそのローカルコピーを使用して、ＯＣＳＰ
応答上の署名を検証する。次いで、ＲＭサーバ証明書の取り消されていないステ
ータスを検証し、最終的にＲＭサーバ証明書内の公開キーを使用して、応答ＰＤ
Ｕ上の署名を検証する。

【０３２５】 応答への否認不可能を提供するために、サーバがクライアントに送信し、サー
バはＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージのコピーを、そのＳｉｇｎｅｒＩ
ｎｆｏ署名および証明書と共に保存する。

【０３２６】 認証は、取引タイプごとに異なる。ＲＰＢＩＷＳは、信頼パーティ識別保証ア
カウントでの支出収支および支出制限に対する要求を認証する。ＩＢＩＷＳは、
署名パーティ識別保証アカウントおよび署名パーティグループアカウント（存在
している場合）における識別保証の収支および制限に対する転送された要求を認
証する。管理コマンドは、ＩＷＭＳ認証データベース内のレコードおよび承認者
定数（ａｐｐｒｏｖｅｒ ｑｕｏｒｕｍ）によって認証される。

【０３２７】 本発明の好ましい実施形態に従って、以下のことが想定される。 １．ガーディアン（ＲＭ）取引内のすべてのエンティティが、証明インフラス
トラクチャの参加者について認証され、認証済み証明書が発行されている。 ２．ガーディアン（ＲＭ）は、発行銀行と信頼パーティ銀行との間のインター
フェース、およびリポジトリとのインターフェースを提供する。銀行およびルー
トリポジトリとの通信は、ステータスチェックのためにＯＣＳＰを使用する。 ３．秘密キーは、不正変更防止ハードウェア（たとえばスマートカード、ＰＣ
ＭＣＩＡなど）で配布される。 ４．ガーディアン（ＲＭ）がオフラインで導入および初期化される。 ５．署名パーティと信頼パーティとの間の通信は、専用バンキングネットワー
クの帯域外にある。 ６．署名パーティが、管理者（ＲＭ）処理に関する必要なすべての情報と共に
、デジタル署名された契約書を信頼パーティに送信する。 ７．発行銀行の保証期限の増加に関する要求は、オフラインで伝達される。 ８．署名パーティの初期化プロセスには、初期保証レベルがゼロに設定されて
いる場合に、保証レベルの修正に関する要求が含まれる。 ９．メッセージフローは、保証要求および証明書ステータスチェックをカバー
するものである。 １０．ガーディアン（ＲＭ）は、すべてのクライアントの保証アカウントを含
む、クライアントのすべての取引のデータベースを保守する。 １１．ガーディアン（ＲＭ）はキャッシュに関する賠償責任を一切負わないた
め、各保証要求にはアクティブな証明書チェックが必要である。 １２．各ＰＦＩは、システム規則に従ってサーバ上で時間を同期させる責務を
負う。 １３．システム規則は、交換レートに関連付けられた任意の問題を定義および
解決する。 １４．識別保証証明書が発行されると、ユーティリティ証明書が発行される。
識別保証証明書が取り消されると、ユーティリティ証明書が取り消される。

【０３２８】 機能要件 本発明の好ましい実施形態に従って、以下の機能要件が定められる。

【０３２９】 保証アカウント − ＴＢＬ証明書を受け取る各記名者は、その発行銀行のガ
ーディアン（ＲＭ）データベースに保証アカウントを有することが好ましい。こ
のデータベースは、アカウント識別子によって署名パーティを識別する。ガーデ
ィアン（ＲＭ）保証データベースには、各署名パーティの許容可能な総保証およ
び現在の未処理保証に関する情報が含まれる。（保証アカウントの初期化は、各
署名パーティに対して企業エンティティが保証制限を要求することにより、証明
書の発行と共に発生する。） 保証アカウントの管理 − 保証アカウントは、アカウントベースで管理され
ることが好ましい。クローズドユーザグループ間に完全な保護があることが好ま
しい。１人の顧客に特有な情報が他のユーザからの情報によって損なわれること
がない。

【０３３０】 保証およびステータス要求 − 保証またはステータスに関する要求はログに
記録されることが好ましい。ガーディアン（ＲＭ）は、関連するＳＰアカウント
に利用可能な保証が十分にない場合、保証要求を決して認めないことが好ましい
。

【０３３１】 理由コード − 保証に関するすべての応答は、応答の理由、特に保証の拒絶
を記載した理由コード、ならびに関連する可能性のある応答パス内にあるエンテ
ィティの他の状態情報が搬送可能であることが好ましい。

【０３３２】 保証要求に応答してＲＰＢによってＲＰに送られるメッセージは、すべての適
切なパーティによって十分に署名されることが好ましく、ＲＰは、応答上の署名
および応答の署名者の証明書を検証する必要がある。

【０３３３】 ログ − ガーディアン（ＲＭ）は、拒否された取引を含むすべての取引を記
録することが好ましい。

【０３３４】 ログ − すべてのガーディアン（ＲＭ）取引には、タイムスタンプが押され
ることが好ましい。

【０３３５】 レポート − ガーディアン（ＲＭ）は、保証修正およびアカウント要求を含
む、処理するすべての取引に関する情報を含んだオンデマンドレポートを生成す
ることが好ましい。

【０３３６】 レポート − ＲＰＢは、ＲＰ取引のステータスを動的に表示できることが好
ましい。

【０３３７】 保証取引 − 署名パーティは、取引上の保証金額を制限できることが好まし
い。

【０３３８】 保証取引 − 銀行は、ガーディアン（ＲＭ）を介して申し出のあった識別保
証要求に関して、価格を設定できることが好ましい。

【０３３９】 保証取引 − 保証取引は、カテゴリコードによって分類されることが好まし
い（たとえば外国為替はＦＸ、企業購入はＰＵＲＣＨ、Ｓ／ＭＩＭＥはＥＭＡＩ
Ｌなど）。この分類によってデータを収集することができるため、銀行はある種
の取引に関連付けられたリスクを追跡することができる。

【０３４０】 サービスに対する請求および支払 − 支払は、銀行への詳細な取引レポート
に基づいて、帯域外で実行されることが好ましい。

【０３４１】 保証に対する支払 − ガーディアン（ＲＭ）は、顧客に対する認可された支
出アカウントを保守することが好ましい。ガーディアン（ＲＭ）は、保証取引の
指定された支出アカウントが超過した場合に、保証要求を拒否することが好まし
い。

【０３４２】 請求紛争 − 紛争の解決は、システム規則に基づいて手作業で実行されるこ
とが好ましい。

【０３４３】 クレーム処理 − クレーム処理は、システム規則に基づいて手作業で実行さ
れることが好ましい。

【０３４４】 クレーム処理 − ガーディアン（ＲＭ）は、クレームが通知された後に、保
証に関する要求を処理するための適切な規則を実施することが好ましい。

【０３４５】 クレーム処理 − 取引の有効期間に従い、署名パーティ側で固有の取引ＩＤ
が生成されることが好ましい。

【０３４６】 ユーザインターフェース（ＵＩ） − ＵＩは、ガーディアン（ＲＭ）の構成
要素間で一貫しており、簡単に使用できることが好ましい。

【０３４７】 配布済み操作 − ガーディアン（ＲＭ）は、各レベル１ ＰＦＩで操作でき
ることが好ましい。

【０３４８】 システム要件 本発明の好ましい実施形態に従って、以下のシステム要件が定められる。

【０３４９】 ガーディアン（ＲＭ）処理は、公衆ネットワークの待ち時間がないものと想定
し、５つの同時取引の場合、１取引につき３０秒以上かからないことが好ましい
。

【０３５０】 ペイロードベースの設計 − 可能な範囲内で、プロトコルは、トランスポー
トプロトコルを新規に定義するかまたは既存のものを修正するのではなく、メッ
セージのコンテンツに焦点をあてるものとする。（この要件は、適切なセキュリ
ティ保守の必要性とバランスをとらなければならない。） 標準ベースの設計 − プロトコルは、操作要件およびセキュリティ要件と一
貫性がある場合、標準ベース（たとえばＨＴＴＰ／ＳＳＬ、ＳＭＴＰ／ＳＭＩＭ
Ｅ）であることが好ましい。

【０３５１】 ４コーナメッセージングモデルの実施 − 要求および応答は、ＲＰがそのＲ
ＰＢによって／を介して通信し、署名パーティがその発行銀行を介して通信する
、４コーナモデル内で動作することが好ましい。

【０３５２】 拡張性 − 本発明に従ったシステムは、新しい要求／応答タイプ、フィール
ド値、およびＰＫＩでの承認の対象となるパラメータの追加を容易にするように
設計されることが好ましい。

【０３５３】 統合 − 本発明に従ったシステムは、追加のＰＩＮまたはパスワードベース
の認証に対する不必要な要件を回避する、エンドユーザおよびサーバベースの統
合に適合するものであることが好ましい。

【０３５４】 展開（ｄｅｐｌｏｙｍｅｎｔ） − 本発明に従ったシステムは、特殊なソフ
トウェアおよびカスタムプロトコルの使用を最小限に抑えるものであることが好
ましい。システムはＰＫＩを活用するものとする。

【０３５５】 監査 − 本発明に従ったシステムは、紛争の解決を助けるために堅固な監査
メカニズムを有するものであることが好ましい。

【０３５６】 国際化サポート − 本発明に従ったシステムは、国際化問題に対処できるも
のであることが好ましい。

【０３５７】 証明書 − 本発明に従ったシステムは、証明書の期限および取消しに対処で
きるものであることが好ましい。

【０３５８】 操作要件 本発明の好ましい実施形態に従って、以下の操作要件が定められる。

【０３５９】 各ステップについての累積合計処理時間が、システム要件で述べた制限を超え
ないものであり、連鎖内の任意の単一ステップの時間が、その制限の３分の１を
超えないものであることが好ましい。

【０３６０】 証明書許容量 − 本発明に従ったシステムは、１００，０００までのアカウ
ントを処理できるものであることが好ましい。

【０３６１】 用途 − システム操作は、連続使用ベース（２４×７）で使用可能であるこ
とが好ましい。ガーディアン（ＲＭ）は、ハードウェア障害、保守、アップグレ
ード、および他のシステム対象イベントが、エンドユーザから見てシステム全体
の使用可能性に影響を与えていないように、エンジニアリングできることが好ま
しい。システムは、性能が多大に低下することなく、異なる位置で動作している
フルバックアップシステムへの始動操作を確実にできるものであることが好まし
い。各システムが２４×７サイクルの一部分に参加することで、ロールオーバの
位相セットによって、時間の経過と共に２４×７の完全な使用可能性が達成でき
る。

【０３６２】 展開 − 本発明に従ったシステムは、署名パーティ／信頼パーティの企業内
にあるアプリケーションサーバでの処理を可能にするものであることが好ましい
。

【０３６３】 システム統合 − ガーディアン（ＲＭ）は、他のシステムおよびネットワー
クサービスとの統合を簡単にする標準（すなわちＯＣＳＰ、ＳＳＬ ｖ３など）
を使用することが好ましい。

【０３６４】 バックアップ − 本発明に従ったシステムは、すべてのガーディアン（ＲＭ
）データのフルバックアップおよびデルタバックアップを作成できるものである
ことが好ましい。

【０３６５】 監査ログ − 本発明に従ったシステムは、企業からの署名パーティの保証ア
カウント変更に関するすべての要求の完全なログを保管できることが好ましい。

【０３６６】 アクセス制御 − １企業またはユーザグループからの要求は、いかなる方法
でも、他の企業の署名パーティに関する情報または方針を変更することはできな
い。

【０３６７】 セキュリティ要件 ハードウェアトークン − 暗号アスペクトおよび署名は、スマートカードお
よびＰＣＭＣＩＡデバイスなどのようにハードウェアベースであることが好まし
い。

【０３６８】 ハードウェアトークン − 暗号は、その時点で最も利用可能なアルゴリズム
、たとえばＲＳＡ、ＤＥＳ、Ｔｒｉｐｌｅ ＤＥＳ、およびＳＨＡ１を使用して
実施されるものであることが好ましい。

【０３６９】 トランスポートレベルセキュリティ − ガーディアン（ＲＭ）は、すべての
システム通信に対して、標準ベースのトランスポート層セキュリティを提供する
ものであることが好ましい。

【０３７０】 アプリケーションレベルセキュリティ − 高額取引の場合、ガーディアン（
ＲＭ）はエンドツーエンドのアプリケーション層の保全性を提供するものである
ことが好ましい。

【０３７１】 監査能力 − 署名済み保証要求およびガーディアン（ＲＭ）によって実行さ
れたアクションのレコードは、関連銀行に提供されるレコードの一部である。こ
れらのレコードは、交替に対して保護されており、安全に伝送されることが好ま
しい。

【０３７２】 秘密キー − ガーディアン（ＲＭ）秘密キーを置き換えるための標準プロシ
ージャがあることが好ましい。

【０３７３】 秘密キー − ガーディアン（ＲＭ）秘密キーの知られた損害から、合理的に
回復するための方法があることが好ましい。

【０３７４】 アクセス制御 − ガーディアン（ＲＭ）は、未認可の外部アクセスからアカ
ウント情報を保護することが好ましい。

【０３７５】 通信セキュリティ − ガーディアン（ＲＭ）と銀行との間でユーザアカウン
トを確立または変更する通信は、保全性および機密性の保護を有することが好ま
しい。この技法は、否認不可能をサポートしていることが好ましい。

【０３７６】 通信セキュリティ − 保証要求および応答の伝送に関連付けられたパラメー
タが保全性を有し、機密性保護が必要であることが好ましい。要求および応答は
、否認不可能をサポートしていることが好ましい。

【０３７７】 識別保証サービス（ＩＷＳ） ガーディアン（ＲＭ）識別保証サービスは、関連付けられた秘密キーによって
署名された契約に関する保証証明書の識別を保証する。この保証は、信頼パーテ
ィによって証明された損失の金額に対するものである。

【０３７８】 本発明の好ましい実施形態における保証アカウントに関して、以下の要件が定
められる。 １．識別保証証明書を受け取る記名者は、その発行銀行のガーディアン（ＲＭ
）データベースに、保証アカウントを有することになる。 このアカウントは、発行銀行によって作成されなければならない。 ２．アカウント識別子は、銀行内で固有である。 ３．ガーディアン（ＲＭ）アカウントには、各署名パーティの最大許容可能総
保証に関する情報が含まれる。 ４．ガーディアン（ＲＭ）アカウントには、各署名パーティの現在の未処理保
証に関する情報が含まれる。 ５．保証アカウントが作成されると、各署名パーティに対して保証限度を要求
する企業エンティティによって保証制限が設定される。 ６．ガーディアン（ＲＭ）は、各アカウントに対して認可された支出情報を保
守する。 ７．ガーディアン（ＲＭ）は、署名パーティのアカウント収支を超えると思わ
れる保証要求を拒否しなければならない。

【０３７９】 本発明の好ましい実施形態での保証取引（要求／申し出／受諾）に関して、以
下の要件が定められる。 １．署名パーティは、取引に関する保証金額を制限することができる。 ２．署名パーティは、保証が要求できる満了日を設定することができる。 ３．ＳＰは、保証を要求できる特定ＲＰを指定することができる。 ４．銀行は、保証要求に対する価格を設定することができる。 ５．識別保証要求でＲＰによって要求される金額は、申し出が行われた場合は
ＩＢが申し出た金額となる。 ６．保証要求にビジネス文書は含まれないが、識別用文書のハッシュは含まれ
る。 ７．保証要求によって料金情報を含む申し出が作成され、ＲＰはこれを受諾ま
たは拒否することができる。 ８．ＲＰは、申し出に応じる必要はない。応答が行われないと、申し出は期日
満了後に失効する。 ９．メカニズムは、申し出または受諾を必要とせずに即時に認められる要求保
証を除外することはない。これは、ＲＰが保証に対して支払うことのない８００
番タイプのサービスで有用である（たとえば、これは事前に支払い済みであるか
または署名パーティによって支払われる）。 １０．ＲＰはＲＰＢのみを、ＳＰはＩＢを処理する。

【０３８０】 本発明の好ましい実施形態での保証取引（署名およびセキュリティ）に関して
、以下の要件が定められる。 １．保証メッセージを信用するために、信頼パーティは保証メッセージ内の情
報、すなわち信頼パーティ銀行の署名、信頼パーティ銀行の証明書、ルートリポ
ジトリによって署名された信頼パーティ銀行のステータス、およびルートリポジ
トリの証明書を検証するだけでよい。 ２．すべての保証メッセージには、関連パーティの識別保証証明書を使用して
署名される。 ３．取引に関わるすべてのパーティは、適切なＰＫＩ識別を使用し、適切な識
別保証証明書を使用して、メッセージに署名しなければならない。 ４．識別保証サービス識別の秘密キーは、ハードウェアトークン上にストアさ
れる。

【０３８１】 本発明の好ましい実施形態での標準の使用に関して、以下の要件が定められる
。 １．ＣＭＳは、保証取引データの符号化に使用される。 ２．クライアント認証のあるＳＳＬ ｖ３は、保証取引のトランスポートに使
用される。

【０３８２】 ３．ＲＰ ＳＳＬクライアント証明書は、ユーティリティ証明書でなければな
らない。このユーティリティ証明書に関するエントリは、識別保証メッセージの
署名に使用される識別保証証明書に関連付けられたアカウントに発生しなければ
ならない。識別保証サービスは、ユーティリティ証明書が識別保証証明書と対に
なっているので、このユーティリティ証明書の取消しをチェックする必要はない
。

【０３８３】 本発明の好ましい実施形態での銀行システムとの統合に関して、以下の要件が
定められる。 １．ＲＰＢおよびＩＢの両方で、保証申し出の価格付けができるコールアウト
を提供する。 ２．ＲＰＢおよびＩＢの両方で、通貨変換のコールアウトを提供する。

【０３８４】 本発明の好ましい実施形態での認可に関して、以下の要件が定められる。 １．ＲＰ保証要求のＲＰＢ認可コールアウトをサポートする。 ２．ＲＰＢ転送保証要求のＩＢ認可コールアウトをサポートする。 ３．ＲＰ保証受諾のＲＰＢ認可コールアウトをサポートする。 ４．ＲＰＢ保証受諾のＩＢ認可コールアウトをサポートする。 ５．ＲＰ証明書ステータス要求のＲＰＢ認可コールアウトをサポートする。

【０３８５】 本発明の好ましい実施形態での管理（ｍａｎａｇｅｍｅｎｔ）、請求および管
理（ａｄｍｉｎｉｓｔｒａｔｉｏｎ）に関して、以下の要件が定められる。 １．すべての保証取引メッセージは、クレーム処理で後に使用するために保存
されることになる。 ２．すべてのクレーム処理は、プロトコルまたはガーディアン（ＲＭ）処理が
定義されておらず、帯域外である。 ３．保証取引は、カテゴリコード別に分類され（たとえば外国為替はＦＸ、企
業購入はＰＵＲＣＨ、Ｓ／ＭＩＭＥはＥＭＡＩＬなど）、これによってデータが
収集できるようになるため、銀行はある種の取引に関連付けられたリスクを追跡
することができる。 ４．適切なレコードが保管されるため、銀行は各ＲＰ保証要求に対して請求す
ることができる。

【０３８６】 証明書ステータスサービス（ＣＳＳ） 証明書ステータスサービス（ＣＳＳ）は、証明機関（ＣＡ）によって証明書が
発行されたか否か、および証明書が取り消されていないか否かを判定するもので
ある。

【０３８７】 オンライン証明書ステータスプロトコル（ＯＣＳＰ）は、証明書の有無および
ステータスに関するクエリに応答するプロトコルであって、中心となる設計の目
的は、クライアント側のＣＲＬ処理を不要にすることである。ＯＣＳＰは、リポ
ジトリによって実施されることが好ましい。本明細書で使用する場合、ＯＣＳＰ
応答者とはＯＣＳＰクエリに応答するサーバのことである。

【０３８８】 本発明の好ましい実施形態では、ＯＣＳＰの使用に関して次のように定められ
ている。 １．ガーディアン（ＲＭ）は、識別保証証明書ならびにユーティリティ証明書
のステータスを要求するための機能を信頼パーティに提供する。 ２．ガーディアン（ＲＭ）は、信頼パーティからのＯＣＳＰ要求に対してＯＣ
ＳＰ応答で応答する。 ３．ガーディアン（ＲＭ）は、他の登録済みガーディアン（ＲＭ）からのＯＣ
ＳＰ要求に対して、ＯＣＳＰ応答で応答する。 ４．ガーディアン（ＲＭ）は、ＩＥＴＦで定義されたように、ＯＣＳＰ ｖ１
．０を処理することができる。 ５．ガーディアン（ＲＭ）は、ＯＣＳＰ要求に署名し、証明書ステータス識別
証明に関連付けられた秘密キーで応答する。この識別は、識別保証および識別保
証管理サービスに関連付けられたような他のガーディアン（ＲＭ）識別とは異な
る。

【０３８９】 本発明の好ましい実施形態では、ステータスサービスに関して次のように定め
られている。 １．各ガーディアン（ＲＭ）は、証明書発行者ＤＮに基づいて、どの非ローカ
ルガーディアン（ＲＭ）が証明書の検証について契約しているかを判定するため
に、構成データを保守する。 ２．非ローカルガーディアン（ＲＭ）へのＯＣＳＰ要求は、ローカルガーディ
アン（ＲＭ）によって署名される新規要求である。転送された応答は、ガーディ
アン（ＲＭ）証明書ステータス識別を使用して再度署名される。 ３．信頼パーティとピアガーディアン（ＲＭ）の識別は、ＯＣＳＰ要求を処理
する際に確認される。

【０３９０】 本発明の好ましい実施形態では、標準に関して次のように定められている。

【０３９１】 識別とユーティリティの証明書はリンクされている。クライアント認証のある
ＳＳＬ ｖ３は、識別保証証明書と共に発行されたユーティリティ証明書でなけ
ればならない。

【０３９２】 本発明の好ましい実施形態では、署名およびセキュリティに関して次のように
定められている。

【０３９３】 １．すべてのＲＰ ＯＣＳＰ要求は、ＲＰ識別保証証明書を使用して署名され
、ＲＰ識別保証証明書の証明パス（ｐａｔｈ）を含まなければならない。 ２．ガーディアン（ＲＭ）は、ルートと接触することによって、リモートガー
ディアン（ＲＭ）およびそのＣｅｒｔＶａｌｉｄａｔｏｒを常時検証する。キャ
ッシュは実行されない。 ３．ガーディアン（ＲＭ）証明書ステータスの秘密キーおよび証明書は、ハー
ドウェアトークン上に格納される。 ４．ガーディアン（ＲＭ）処理で使用されるユーティリティおよび識別の保証
証明書は、アーキテクチャ証明書プロファイルに合致していなければならない。
ガーディアン（ＲＭ）は、これらのプロファイルに合致して証明書を処理できな
ければならない。

【０３９４】 本発明の好ましい実施形態では、管理、請求および管理に関して次のように定
められている。 １．すべてのＯＣＳＰ取引がログに記録される。 ２．適切なレコードが保管されるので、銀行は各ＲＰ保証要求について請求す
ることができる。

【０３９５】 識別保証管理サービス 識別保証管理サービスは、ガーディアン（ＲＭ）サーバの管理アクションを実
施する。

【０３９６】 本発明の好ましい実施形態では、識別保証管理サービス管理に関して次のよう
に定められている。 １．各ガーディアン（ＲＭ）は、識別保証アカウントに関する情報を含むロー
カルデータベースを有する。 ２．ガーディアン（ＲＭ）は、初期導入時に１管理者へのアクセスを提供する
。 ３．ガーディアン（ＲＭ）は、管理者がシステムを使用できるようにする前に
、管理者証明書連鎖を確認する。 ４．ガーディアン（ＲＭ）は、ピア構成データなどを編集するための機能を使
用して操作を制御することができる。

【０３９７】 本発明の好ましい実施形態では、識別保証管理サービスの保証アカウント管理
に関して次のように定められている。

【０３９８】 １．ガーディアン（ＲＭ）は、管理者が識別保証アカウントの作成、修正、ま
たは削除を実行できるようにする。 ２．ガーディアン（ＲＭ）は、以下のものを適切に管理しおよび見ることがで
きる。 ・識別保証アカウント ・識別保証取引ログ ・未処理ターゲットのＩＢ内部リスト ・ＲＰＢＩＷＳ識別保証取引ログ ・ＩＢＩＷＳ取引ログ ・ＣＳＳログ ・識別保証アカウント ３．ガーディアン（ＲＭ）は顧客情報を保護しなければならない。１人の顧客
に固有の情報が、他のユーザからの情報によって損なわれることはない。

【０３９９】 本発明の好ましい実施形態では、識別保証管理サービス監視に関して、次のよ
うに定められている。サービス監視コマンドは、ＨＴＴＰＳ ＵＲＬに対するＨ
ＴＴＰ ＰＯＳＴ／ＲＥＳＰＯＮＳＥメッセージで実施され、クライアントのＳ
ＳＬ識別（ユーティリティ）証明書に対して認可されることが好ましい。

【０４００】 本発明の好ましい実施形態では、識別保証管理サービスレポートに関して、次
のように定められている。

【０４０１】 １．ガーディアン（ＲＭ）は、以下の情報を含むオンデマンドレポートを生成
することができる。 ・ガーディアン（ＲＭ）サービスのステータス ・要求時からのすべての識別保証取引 ・識別保証制限に等しい識別保証収支のアカウント ２．ＲＰＢはＲＰ取引のステータスを動的に表示することができる。

【０４０２】 本発明の好ましい実施形態では、識別保証管理サービスログに関して次のよう
に定められている。 １．ガーディアン（ＲＭ）は、サーバアプリケーションのステータスに関する
情報をログに記録する。 ２．すべてのガーディアン（ＲＭ）取引に、タイムスタンプが押されなければ
ならない。 ３．ガーディアン（ＲＭ）は、以下を含むすべての識別保証およびＯＣＳＰメ
ッセージをログに記録する。

【０４０３】 ・ＲＰクライアントから受け取る識別保証メッセージ ・他のガーディアン（ＲＭ）サーバから受け取る識別保証メッセージ ・それ自体を生成する識別保証メッセージ ・ＯＣＳＰ応答者から受け取る証明書ステータス（ＯＣＳＰ）メッセージ ・ローカルＣｅｒｔＶａｌｉｄａｔｏｒから受け取る証明書ステータス（ＯＣ
ＳＰ）メッセージ ・ＣｅｒｔＶａｌｉｄａｔｏｒから受け取る証明書ステータス（ＯＣＳＰ）メ
ッセージ ・他のガーディアン（ＲＭ）サーバから受け取る証明書ステータス（ＯＣＳＰ
）メッセージ ・ガーディアン（ＲＭ）は、識別保証アカウントへのすべての変更をログに記
録する。

【０４０４】 本発明の好ましい実施形態では、識別保証管理サービスクレーム処理に関して
次のように定められている。 １．ガーディアン（ＲＭ）は、クレームが通知された後に、保証に関する要求
を処理するための適切な規則を実施しなければならない。 ２．ガーディアン（ＲＭ）サーバは、クレームが解決されたときに、保証アカ
ウントも更新できなければならない。 ３．ガーディアン（ＲＭ）は、古い取引識別子の再使用を検出する。

【０４０５】 ハードウェア要件（ＨＤＷ） 本発明に従ったシステムは、任意の適切なコンピュータシステムで動作可能で
あるが、このシステムの実施は、以下のような最小限のハードウェア／ソフトウ
ェアプラットフォーム上で動作することが好ましい。

【０４０６】 ハードウェア ・Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏ（商標） ４５０ ・１２８メガバイトＲＡＭ ・８〜１０ギガバイトのＳＣＳＩドライブ ・ネットワークカード（ＴＢＤ） ・ハードウェアトークンリーダ（ＴＢＤ） ・ハードウェアトークン（ＴＢＤ） ソフトウェア ・Ｗｉｎｄｏｗｓ（登録商標） ＮＴ ４．０ｗ／Ｓｅｒｖｉｃｅ Ｐａｃｋ
３ ・ハードウェアトークンドライバ ・Ｍｉｃｒｏｓｏｆｔ（登録商標） ＳＱＬサーバ ｖ７ ガーディアン（ＲＭ）は、それぞれの構成について別々のハードウェアおよび
ソフトウェアを必要とすることが好ましい。他のソフトウェアアプリケーション
は導入されないものとする。

【０４０７】 性能要件（ＰＥＲ） 要求とレポートの両方について合理的な応答時間を保証するために、好ましい
実施形態は以下の要件に合致するものとする。ガーディアン（ＲＭ）処理には、
公衆ネットワークの待ち時間の対象となる５つの同時取引がある場合、１取引に
つき３０秒以上かからないことが好ましい。

【０４０８】 セキュリティ 暗号および署名は、スマートカードおよびＰＣＭＣＩＡデバイスを利用するな
ど、ハードウェアベースであることが好ましい。暗号アルゴリズムは、たとえば
ＲＳＡ、ＤＥＳ、Ｔｒｉｐｌｅ ＤＥＳ、およびＳＨＡ１などの標準であること
が好ましい。

【０４０９】 ガーディアン（ＲＭ）は、標準ベースのトランスポート層セキュリティをすべ
てのシステム通信に提供するものであることが好ましい。ガーディアン（ＲＭ）
は、エンドツーエンドのアプリケーション階層の保全性を提供するものであるこ
とが好ましい。

【０４１０】 監査能力 − 署名済み保証要求およびガーディアン（ＲＭ）によって実行さ
れたアクションのレコードは、関連銀行に提供されるレコードの一部であること
が好ましい。これらのレコードは、交替に対して保護されており、安全に伝送さ
れることが好ましい。

【０４１１】 ガーディアン（ＲＭ）秘密キーを置き換えるための標準プロシージャがあるこ
とが好ましい。また、ガーディアン（ＲＭ）秘密キーの知られた損害から、合理
的に回復するための方法があることが好ましい。

【０４１２】 ガーディアン（ＲＭ）は、未認可の外部アクセスからアカウント情報を保護す
ることが好ましい。

【０４１３】 ガーディアン（ＲＭ）と銀行との間でユーザアカウントを確立または変更する
通信は、保全性および機密性の保護を有することが好ましい。この技法は、保全
性に関して否認不可能をサポートしていることが好ましい。

【０４１４】 保証要求および応答の伝送に関連付けられたパラメータが保全性を有し、機密
性保護が必要であることが好ましい。要求および応答は、否認不可能をサポート
していることが好ましい。

【０４１５】 ガーディアン（ＲＭ）は、未認可の外部アクセスからアカウント情報を保護す
ることが好ましい。

【０４１６】 標準（ＳＴＤ） ＣＭＳは、すべての識別保証メッセージの符号化に使用されることが好ましい
。

【０４１７】 本発明に従ったシステムは、少なくとも１９９８年９月のオンライン証明書ス
テータスプロトコル（ＯＣＳＰ）明細書−＜ｄｒａｆｔ−ｉｅｔｆ−ｐｋｉｘ−
ｏｃｓｐ−０７．ｔｘｔ＞の草案をサポートするものであることが好ましい。Ｏ
ＣＳＰは証明書の有無およびステータスに関するクエリに応答し、中心となる設
計の目的は、クライアント側のＣＲＬ処理を不要にすることである。ＯＣＳＰは
、リポジトリによって実施されることが好ましい。

【０４１８】 システムは、ＳＳＬバージョン３をサポートしていることが好ましい。

【０４１９】 システムは、管理（ａｄｍｉｎｉｓｔｒａｔｉｏｎ）および管理（ｍａｎａｇ
ｅｍｅｎｔ）のためにＳＳＬを介してＨＴＴＰを使用することが好ましい。

【０４２０】 カードおよび署名セキュリティデータ カードおよび署名セキュリティデータ（ＣＳＳＤ）は、取引のハッシュを介し
た署名であって、いくつかのデータ項目がカード上で保守される。これらの項目
には以下のものが含まれることが好ましい。

【０４２１】 ａ）カード番号 ｂ）保証署名バージョン番号 ｃ）カード認証暗号バージョン番号 ｄ）保証取引カウンタ ｅ）ユーティリティ取引カウンタ ｆ）ＣＳＳＤカウンタ ｇ）カードホルダ検証結果

【０４２２】 この情報は、発行銀行のリスク管理処理が、カードの不正使用を検出するため
に使用することができる。

【０４２３】 リカバリを備えた署名スキームが使用される場合、これらの項目は署名ブロッ
クで搬送され、署名検証時に回復することができる。回復できない場合、項目は
１つまたは複数の追加属性として搬送しなければならない。いずれの場合でも、
署名自体が属性として搬送されるものとする（署名の必要はない）。これら追加
属性の設計は、署名スキームが決定されたときに完了する。

【０４２４】 管理プロトコル このセクションでは、信頼マネージャの管理プロトコルを定義する。具体的に
言えば、ＲＭ管理者（ＲＭＡ）とＲＭとの間でメッセージが定義される。

【０４２５】 プロトコルはＣＭＳ（前述のＰＫＣＳ ＃７）の使用に基づいて、ＣＭＳｓｉ
ｇｎｅｄＤａｔａ構成を使用して取引をカプセル化するものである。個々のメッ
セージが、ＡＳＮ．１ ＤＥＲ（ＣＭＳそれ自体にも使用される）を使用して指
定および符号化される。ｓｉｇｎｅｄＤａｔａインスタンスは、さらに転送用に
符号化され（たとえばｂａｓｅ６４符号化を使用）、さらに保護（たとえばＳＳ
ＬまたはＳ／ＭＩＭＥ）が適用可能であるが、これらの機能については本明細書
では詳しく論じない。署名者の識別は、その証明書連鎖内に格納される。図３０
にメッセージフローが示してある。

【０４２６】 図３０を参照すると、メッセージは次のとおりである。 １．管理コマンド ２．ステータス

【０４２７】 管理プロトコル このセクションでは、管理プロトコルメッセージの形式を定義する。管理プロ
トコルは、ＲＭ管理者とＲＭ管理サービスとの間に単一の要求／応答ラウンドト
リップとからなる。

【０４２８】 管理プロトコルメッセージは、メッセージのコンテンツとしてＣＭＳ Ｓｉｇ
ｎｅｄＤａｔａを使用してカプセル化される。

【０４２９】 要求のコンテンツが管理コマンドである。応答のコンテンツが管理コマンドス
テータスである。

【０４３０】 メッセージ発信者は、メッセージのコンテンツおよび追加の認証属性または非
認証属性（たとえばＳｉｇｎｅｒＩｎｆｏ）を組み立ててこれに署名する。

【０４３１】 管理要求 保証取引を開始するには、ＲＭ管理者がａｄｍｉｎＲｅｑｕｅｓｔ構造を含む
ＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成するが、この構文を以下に示す
。メッセージのコンテンツタイプは「ｍａｎａｇｅｍｅｎｔ ｃｏｍｍａｎｄ」
であって、これがメッセージコンテント署名属性としてＣＭＳ仕様ごとに含まれ
る。

【０４３２】 AdminRequest ::= SEQUENCE {2 version Version, command AdminCommandType, target AdminTargetType, balance [1] MonetaryValue OPTIONAL, certificate [2] X509 OPTIONAL, ... extensions Extensions OPTIONAL - none currently
defined} AdminCommandType ::= ENUMERATED { create(0), modify(1), read(2), delete(
3), ...} AdminTargetType ::= ENUMERATED { idWarrantyAccount(0), idWarrantyRecord(
1), idWarrantyXAction(2), authorizationDb(3), ... } -- target database

【０４３３】 管理応答 保証取引に応答する場合、ＲＭ管理サービスは、ａｄｍｉｎＲｅｓｐｏｎｓｅ
ストラクチャを含むＣＭＳ ＳｉｇｎｅｄＤａｔａメッセージを作成するが、こ
の構文を以下に示す。メッセージのコンテンツタイプは「ｍａｎａｇｅｍｅｎｔ
ｒｅｓｐｏｎｓｅ」であって、これがメッセージコンテント署名属性としてＣ
ＭＳ仕様ごとに含まれる。

【０４３４】 AdminResponse ::= SEQUENCE { version Version, status AdminStatusType, ... extensions Extensions OPTIONAL - none currently defined} AdminStatusType ::= ENUMERATED { ok(0), noPermission(1), badCert(2)... }

【０４３５】 以上のように、電子取引システムの信頼マネージャが提供される。当分野の技
術者であれば、本発明が、限定的なものではなく例示的なものとして記載された
実施形態以外でも実施可能であって、本発明が前述の特許請求の範囲によっての
み限定されるものであることを理解されよう。

【図面の簡単な説明】

本発明の目的および利点は、参照符号が全体を通して同じ部分を指している添
付の図面と併せて、下記の詳細な説明を考慮することで、より明白となる。

【図１】 本発明の実施形態の構成要素の概要を示す図である。

【図２】 本発明の実施形態による４コーナモデルを示す図である。

【図３】 本発明の様々な実施形態による識別保証を得るための処理を示す図である。

【図４】 本発明の様々な実施形態による識別保証を得るための処理を示す図である。

【図５】 本発明の実施形態による証明書ステータスサービスのための処理を示す図であ
る。

【図６】 本発明の実施形態による識別保証管理サービスの概要を提示する図である。

【図７】 本発明の実施形態による識別保証管理サービスのための様々なメッセージフロ
ーを示す図である。

【図８】 本発明の実施形態による識別保証管理サービスのための様々なメッセージフロ
ーを示す図である。

【図９】 本発明の実施形態による識別保証管理サービスのための様々なメッセージフロ
ーを示す図である。

【図１０】 本発明の実施形態による署名済み取引の形式を示す図である。

【図１１】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１２】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１３】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１４】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１５】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１６】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１７】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１８】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図１９】 本発明によるサービスに関連する様々なメッセージを示す図である。

【図２０】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２１】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２２】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２３】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２４】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２５】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２６】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２７】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２８】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図２９】 本発明によるサービスに関連するメッセージフローの詳細を示す図である。

【図３０】 本発明のいくつかの実施形態による管理プロトコルメッセージフローを示す図
である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ＺＥＣ Ｇ０６Ｆ 17/60 ＺＥＣ Ｇ０９Ｃ 1/00 ６４０ Ｇ０９Ｃ 1/00 ６４０Ｂ ６４０Ｅ ６４０Ｚ Ｈ０４Ｌ 9/32 Ｈ０４Ｌ 9/00 ６７５Ｄ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＣＡ，Ｊ Ｐ，ＵＳ (72)発明者 チャールズ ティー．モンゴメリー アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 スチュアート スタッブルバイン アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 マルセル モルデチャイ ヨン アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 リチャード アンクネイ アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 リチャード ザルツ アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 トーマス ティチナー アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 ピーター リバーワース アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 アンドリュー コンスタンタラス アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 Ｆターム(参考） 5J104 AA07 AA09 KA01 KA05 LA03 LA06 MA03 NA02 PA07 PA10

Claims (28)

【特許請求の範囲】
1. 【請求項１】 電子取引システムであって、 前記システムに対する記名者の属性の記名者保証を表す電子信号を発行する機
   関と、 前記発行機関によって発行された前記記名者保証に関する情報を表す電子信号
   を取得し、信頼パーティに対する署名済み保証申し出を表す電子信号を発行し、
   前記署名済み保証申し出が、少なくとも、前記記名者属性保証に基づく信頼サー
   バとを備え、前記信頼サーバは、前記保証に対する要求を行うことが前記信頼パ
   ーティに認可されている場合にのみ、前記署名済み保証申し出を提供することを
   特徴とするシステム。
2. 【請求項２】 前記信頼サーバは、セキュアなハードウェア装置を使用して
   保証に署名することを特徴とする請求項１に記載のシステム。
3. 【請求項３】 前記セキュアなハードウェア装置は、証明機関によって認証
   されたキーを含むことを特徴とする請求項２に記載のシステム。
4. 【請求項４】 前記信頼サーバは、前記保証申し出に署名する決定を、 （ａ）発行パーティ証明書の属性と、 （ｂ）発行パーティ証明書に含まれていない前記発行パーティに関する属性と
   、 （ｃ）前記発行パーティによって送信される前記保証に対する要求の属性と を含む基準に基づいて行うことを特徴とする請求項１に記載のシステム。
5. 【請求項５】 前記信頼サーバは、前記保証申し出に署名する決定を、セキ
   ュアな管理プロセスの下で構成され得るスクリプトを介して定義される基準に基
   づいて行うことを特徴とする請求項１に記載のシステム。
6. 【請求項６】 前記信頼サーバは、特定の信頼パーティからの各要求を、同
   一の前記信頼パーティからの他のすべての要求とは独立に扱うことを特徴とする
   請求項１に記載のシステム。
7. 【請求項７】 特定の信頼パーティからの各要求は、署名済み保証申し出の
   発行に関する方針を前記信頼サーバに決定させる情報を含むことを特徴とする請
   求項１に記載のシステム。
8. 【請求項８】 前記信頼サーバは、すべての取引のセキュアなログを生成し
   て、前記システムが監査され得るようにすることを特徴とする請求項１に記載の
   システム。
9. 【請求項９】 信頼パーティに申し出られた前記保証は、前記申し出を前記
   信頼パーティが所定期限内に受諾しない場合、撤回され得ることを特徴とする請
   求項１に記載のシステム。
10. 【請求項１０】 前記発行機関は、各取引ごとに与えられ得る保証のレベル
    を制限することを特徴とする請求項１に記載のシステム。
11. 【請求項１１】 前記発行機間は、どの取引に対しても全体の制限を設定す
    ることによって、前記保証のレベルを制限することを特徴とする請求項１０に記
    載のシステム。
12. 【請求項１２】 電子取引システム内での信頼を管理する方法であって、 発行銀行（ＩＢ）が、取引を伴う賠償責任（ＴＢＬ）証明書を記名者に提供す
    るステップと、 前記記名者が、取引を結んでそれに署名し、前記署名済み取引は、前記ＴＢＬ
    証明書に含まれる情報を含み、前記署名済み取引を信頼パーティに転送するステ
    ップと、 前記信頼パーティが、前記取引に基づいて保証要求を信頼パーティ銀行に転送
    するステップと、 前記信頼パーティ銀行が、署名済み保証申し出を前記信頼パーティに発行し、
    前記署名済み保証申し出は少なくとも前記ＴＢＬ証明書内の情報に基づいている
    ステップであって、前記信頼パーティ銀行は、前記保証に対する要求を行うこと
    が前記信頼パーティに認可されている場合にのみ、前記署名済み保証申し出を提
    供するステップと を備えることを特徴とする方法。
13. 【請求項１３】 前記信頼パーティ銀行は、セキュアなハードウェア装置を
    使用して前記保証に署名することを特徴とする請求項１２に記載の方法。
14. 【請求項１４】 前記セキュアなハードウェア装置は、証明機関によって認
    証されたキーを含むことを特徴とする請求項１３に記載の方法。
15. 【請求項１５】 前記信頼パーティ銀行は、保証申し出に署名する決定を、 （ａ）ＴＢＬ証明書の属性と、 （ｂ）証明書に含まれていない前記発行銀行に関する属性と、 （ｃ）前記保証に対する要求の属性と を含む基準に基づいて行うことを特徴とする請求項１２に記載の方法。
16. 【請求項１６】 前記信頼パーティ銀行は、前記保証申し出に署名する決定
    を、セキュアな管理プロセスの下で構成され得るスクリプトを介して定義される
    基準に基づいて行うことを特徴とする請求項１２に記載の方法。
17. 【請求項１７】 前記信頼パーティ銀行は、特定の信頼パーティからの各要
    求を、同一の前記信頼パーティからの他のすべての要求とは独立に扱うことを特
    徴とする請求項１２に記載の方法。
18. 【請求項１８】 特定の信頼パーティからの要求は、署名済み保証申し出の
    発行に関する方針を前記信頼パーティ銀行に決定させる情報を含むことを特徴と
    する請求項１２に記載の方法。
19. 【請求項１９】 前記信頼パーティ銀行がすべての取引のセキュアなログを
    生成して、前記システムが監査され得るようにするステップをさらに備えること
    を特徴とする請求項１２に記載の方法。
20. 【請求項２０】 前記信頼パーティに申し出た保証を、前記申し出を前記信
    頼パーティが所定期限内に受諾しない場合、撤回するステップをさらに備えるこ
    とを特徴とする請求項１２に記載の方法。
21. 【請求項２１】 前記発行銀行が、各取引ごとに、与えられ得る保証のレベ
    ルを制限するステップをさらに備えることを特徴とする請求項１２に記載の方法
    。
22. 【請求項２２】 前記発行銀行が、どの取引に対しても全体の制限を設定す
    ることによって、前記保証のレベルを制限することを特徴とする請求項２１に記
    載の方法。
23. 【請求項２３】 前記信頼パーティが、オープンネットワークプロトコルを
    使用して、前記保証要求を転送することを特徴とする請求項１２に記載の方法。
24. 【請求項２４】 前記信頼パーティ銀行が、前記信頼パーティに前記要求を
    行うことが認可されていることを検証するステップであって、前記検証は、信頼
    パーティの識別証明書、および他のシステムから前記信頼パーティ銀行によって
    要求され得る情報と併せて前記信頼パーティ銀行によって決定された属性に基づ
    くステップをさらに備えることを特徴とする請求項１２に記載の方法。
25. 【請求項２５】 前記信頼パーティ銀行により、各信頼パーティごとに発行
    された保証を追跡するために保証アカウントを維持するステップをさらに備える
    ことを特徴とする請求項１２に記載の方法。
26. 【請求項２６】 前記信頼パーティ銀行により、グループの信頼パーティア
    カウントに対して発行された未解決の保証の記録を維持するステップをさらに備
    えることを特徴とする請求項１２に記載の方法。
27. 【請求項２７】 前記信頼パーティ銀行により、特定の保証しきい値が到達
    されたとき、警報メッセージを提供するステップをさらに備えることを特徴とす
    る請求項１２に記載の方法。
28. 【請求項２８】 前記信頼パーティ銀行により、他のシステムからの情報に
    対する要求を行って、前記保証申し出を発行するか否かを決定するステップをさ
    らに備えることを特徴とする請求項１２に記載の方法。