JP7215342B2 - 通信プログラム、通信方法、および、通信装置 - Google Patents

Description

本発明は、通信プログラム、通信方法、および、通信装置に関する。

オンラインショッピング、クレジットカードの発行申し込み、銀行の口座開設などの様々なサービスを利用する際に、サービスの利用者がサービスの提供者に電子証明書を提示することがある。電子証明書は認証局によって発行され得る。この場合、認証局は、ユーザに対して身元確認などを実施し、その結果に基づいて証明書を発行する。ユーザは得られた電子証明書をサービスの提供者に提示する。サービスの提供者は、証明書のフォーマットを予め記憶しているので、電子証明書で証明されている情報を取得できる。

また、近年、仮想通貨を実現する基盤として登場した分散台帳技術が注目されている。分散台帳を用いると、システムの中央管理者が存在しなくても情報の改ざんを防ぐことができるため、仮想通貨以外の領域への応用も検討されている。

関連する技術として、信頼当事者のサービスにアクセスするためのトークンをアイデンティティプロバイダから取得する方法が知られている（例えば、特許文献１など）。第１のセキュリティドメインに属する装置が、第２のセキュリティドメインに対応したクレデンシャルＢと第１のセキュリティドメインのシステムでのクレデンシャルＡを対応付けて記憶するシステムも提案されている（例えば、特許文献２）。このシステムでは、第１のセキュリティドメインに属する装置は、クレデンシャルＡを用いてクレデンシャルＢをリポジトリサーバから取得し、第２のセキュリティドメイン中の通信先の装置にクレデンシャルＢを送信する。

特表２０１１－５２５０２８号 特開２００８－７１２２６号

中央管理者が存在しないシステムでは、証明書の発行なども特定の認証局以外の装置によって行われる可能性がある。例えば、システム中の任意の装置が電子証明書を発行可能なシステムも設計され得る。しかし、電子証明書の発行が特定の装置以外でも行われる場合、電子証明書により証明される情報の種類を表す名称が発行元の装置によって異なってしまう可能性がある。さらに、電子証明書を要求している提供者と電子証明書の発行元の間で、同じ情報について異なる名称を使用する可能性もある。この場合、ユーザが提供者の装置から要求された情報を含む電子証明書を提供者の装置に送付しても、要求された情報に対応付けられた名称は提供者が使用している名称と異なることから提供者の装置が証明書中の情報を認識せず、検証に失敗してしまう。電子証明書を用いた情報の検証に失敗すると、提供者はユーザに要求した情報についてユーザから自己申告を受け付けた上で、別途、ユーザからの申告が正しいかを検証することになってしまうため、コストや時間がかかってしまい、検証処理の効率が悪くなってしまう。

本発明は、１つの側面として、検証処理の効率の低下を防止することを目的とする。

ある１つの態様にかかる通信プログラムは、通信装置で実行される。通信装置は、電子証明書に含まれるユーザ情報の属性と前記属性の定義の対応関係を記録した分散台帳を共有している複数の装置のいずれかに接続する第１の装置から、第１の属性に対応付けられた情報を含む電子証明書を取得する。通信装置は、前記複数の装置のいずれかに接続する第２の装置から第２の属性に対応付けられた情報の要求を受信すると、前記第１の属性に対応付けられた第１の定義、および、前記第２の属性に対応付けられた第２の定義を、前記複数の装置のいずれかから取得する。通信装置は、前記第１の定義と前記第２の定義が一致する場合、前記第１の属性と前記第２の属性が同じ定義を有することを通知するメッセージとともに、前記第１の属性に対応付けられた情報を含む電子証明書を、前記第２の装置に送信する。

検証処理の効率の低下を防止できる。

実施形態にかかる通信方法の例を説明する図である。 通信装置の構成の例を説明する図である。 通信装置のハードウェア構成の例を説明する図である。 分散台帳を用いて共有される情報の例を説明する図である。 クレデンシャルのフォーマットの例を説明する図である。 ネットワークの例を説明する図である。 クレデンシャルの送信のために行われる処理の例を説明する図である。 属性対応テーブルの例を説明する図である。 属性対応メッセージの例を説明する図である。 情報を要求された通信装置が行う処理の例を説明するフローチャートである。 属性対応メッセージを受信した通信装置で行われる処理の例を説明するフローチャートである。 通信装置が行う検証処理の例を説明するフローチャートである。 第２の実施形態で行われる通信の例を説明する図である。 各コンソーシアムで共有される属性定義の例を説明する図である。 属性対応テーブルの例を説明する図である。 属性対応メッセージの例を説明する図である。 第２の実施形態で行われる処理の例を説明する図である。 第２の実施形態で行われる処理の例を説明する図である。 クレデンシャルの送信処理の例を説明する図である。 第２の実施形態で行われる処理の例を説明するフローチャートである。 第２の実施形態で行われる処理の例を説明するフローチャートである。

図１は、実施形態にかかる通信方法の例を説明する図である。図１では、発行者２が電子証明書（クレデンシャル）を発行する。保持者３は、保持者３に関する情報を証明する電子証明書を発行者２に要求するものとする。保持者３は、名前、住所など、様々な属性の情報を有する。なお、保持者３は、ユーザ個人であってもよく、また、組織などであってもよい。さらに、検証者４は、適宜、保持者３に対して保持者３に関する情報の証明を求めるものとする。また、発行者２は通信装置２０ａを用いる。同様に、保持者３は通信装置２０ｂを使用し、検証者４は通信装置２０ｃを使用するものとする。

ネットワーク中には、１つ以上のコンソーシアム（クラスタ）が含まれる。各コンソーシアムは、分散台帳１５を共有し得る任意の形式のクラスタであり、例えば、ブロックチェーン技術におけるコンソーシアムであってもよい。

コンソーシアム１に参加している複数のノード１０（１０ａ～１０ｃ）は、分散台帳１５を共有する。図１の例では３台のノード１０が図示されているが、コンソーシアム１に含まれるノード１０の数は実装に応じて任意に変更され得る。分散台帳１５は、属性定義１６を含み、オプションとして、検証用公開鍵情報１７も含み得る。属性定義１６は、電子証明書で証明されるユーザ情報の種類を表す名称（属性）と属性の定義の対応関係である。例えば、属性定義１６は、「名前」という属性は、ユーザの苗字を漢字で表した文字列であることを含み得る。また、１つの定義に複数の属性が対応付けられていてもよい。例えば、属性定義１６において、「氏名」という属性がユーザの苗字を漢字で表した文字列であることも、併せて記録されていてもよい。なお、以下の説明では、属性の各々に対して、その属性を識別するための識別情報が割り当てられているものとする。図１の例では、「名前」という属性にＡ１、「氏名」という属性にＡ１０という識別情報が割り当てられているとする。検証用公開鍵情報１７は、各通信装置２０が暗号化に使用可能な秘密鍵の対になった公開鍵などの情報を含む。

ノード１０の各々は、分散台帳１５中の属性定義１６を参照することにより、個々の属性に対応付けられた情報の定義を特定できる。通信装置２０ａは、ノード１０ａに接続しているので、適宜、ノード１０ａから属性に対応付けられている定義の内容や、他の通信装置２０で暗号化された情報を復号するための公開鍵を取得できる。同様に、通信装置２０ｂはノード１０ｂから属性と定義の対応付けや公開鍵などの情報を取得し、通信装置２０ｃはノード１０ｃから属性と定義の対応付けや公開鍵などの情報を取得する。

例えば、保持者３が自分の名前についての証明を発行者２に要求したとする。発行者２は、通信装置２０ａを用いて保持者３についての証明書を発行する。このとき、通信装置２０ａは、「名前」（Ａ１）という属性を含む電子証明書を生成して、通信装置２０ｂに送信する（ステップＳ１）。

一方、保持者３の通信装置２０ｂは、検証者４の通信装置２０ｃから「氏名」という属性（Ａ１０）の情報の要求を受信したとする。通信装置２０ｂは、ノード１０ｂから、「氏名」（Ａ１０）という属性に対する定義と、「名前」（Ａ１）という属性に対する定義を取得して、両者を比較する。ここでは、「氏名」と「名前」のいずれも、ユーザの苗字を漢字で表した文字列に対応付けられている。そこで、通信装置２０ｂは、「氏名」（Ａ１０）という属性に対する定義と「名前」（Ａ１）という属性に対する定義が等しいことを通信装置２０ｃに通知する。さらに、通信装置２０ｂは、通信装置２０ａから取得した電子証明書を通信装置２０ｃに送信する（ステップＳ２）。

通信装置２０ｃは、適宜、ノード１０ｃから属性定義１６に記録されている情報を取得することにより、属性＝Ａ１０（氏名）と属性＝Ａ１（名前）では定義が等しいと判定したとする。すると、通信装置２０ｃは、通信装置２０ｂから受信した電子証明書中の属性＝Ａ１（名前）の情報を属性＝Ａ１０（氏名）の情報として読み替えることにより、電子証明書を用いた検証処理に成功する。このため、通信装置２０ｃは、通信装置２０ｂに対するサービスの提供等を行うことができる。

ネットワーク中の複数の通信装置２０の間で使用する属性が異なっていたとしても、その属性に対応付けられている情報の定義が等しい場合は、いずれの属性も同じ情報を表す。実施形態にかかる通信装置２０は、属性定義１６を含む分散台帳１５を共有するノード１０から属性定義１６を取得することにより、要求した情報の属性と同じ定義を有する電子証明書中の属性に対応付けられた情報を用いて検証処理を行うことができる。このため、証明書の発行元の通信装置２０と証明書の検証を行う通信装置２０で異なる属性定義を用いていても、電子証明書を用いた検証を行うことができる。

なお、図１は一例であり、実装に応じた改変が行われ得る。例えば、ネットワーク中のノード１０や通信装置２０の数は任意に変更され得る。また、通信装置２０は、通信装置２０間の通信の際に、適宜、秘密鍵を用いた暗号化処理を行ってもよい。受信した情報が暗号化されている場合、通信装置２０は、送信元の通信装置２０に対応付けられた公開鍵を用いた復号化処理の後で検証処理などを行うことができる。さらに、発行者２、保持者３、検証者４の各々は、通信装置２０を操作してもよく、また、通信装置２０を操作するための端末を介して通信装置２０を制御してもよい。

さらに、通信装置２０のいずれも、電子証明書の発行、取得、および、検証が可能である。すなわち、通信装置２０ａ～２０ｃの各々の通信装置２０が行っている処理は任意の通信装置２０で行われ得る。

＜装置構成＞
図２は、通信装置２０の構成の例を説明する図である。通信装置２０は、通信部３０、制御部４０、および、記憶部５０を備える。通信部３０は、受信部３１と送信部３２を有する。受信部３１は、ノード１０、端末、他の通信装置２０などからパケットを受信する。送信部３２は、ノード１０、端末、他の通信装置２０などにパケットを送信する。

制御部４０は、取得部４１、判定部４２、生成部４３、および、アプリケーション処理部４４を備える。取得部４１は、クレデンシャル（電子証明書）に含まれている属性、および、他の通信装置２０から要求された情報に対応付けられた属性の定義を、ノード１０から取得する。判定部４２は、ノード１０から取得した情報を用いて、複数の属性間で定義が一致するかを判定する。生成部４３は、複数の属性間で定義が一致すると判定部４２が判定した場合、定義が一致すると判定した属性同士を対応付けるためのメッセージ（属性対応メッセージ）を生成する。アプリケーション処理部４４は、アプリケーションを用いてクレデンシャルの発行やクレデンシャルの検証などを行う。

記憶部５０は、属性対応テーブル５１および秘密鍵５２を有する。属性対応テーブル５１は、判定部４２で得られた判定結果を記録する。秘密鍵５２は、通信装置２０が他の通信装置２０にクレデンシャルなどを送信するときの暗号化に使用される。

図３は、通信装置２０のハードウェア構成の例を説明する図である。通信装置２０は、プロセッサ１０１、メモリ１０２、バス１０５、ネットワークインタフェース１０９を備える。さらに、通信装置２０は、入力装置１０３、出力装置１０４、記憶装置１０６、可搬記憶媒体駆動装置１０７の１つ以上を有していても良い。

プロセッサ１０１は、任意の処理回路であり、例えば、Central Processing Unit（ＣＰＵ）とすることができる。プロセッサ１０１は、制御部４０として動作する。プロセッサ１０１は、例えば、メモリ１０２や記憶装置１０６に記憶されたプログラムを実行することができる。メモリ１０２は、プロセッサ１０１の動作により得られたデータや、プロセッサ１０１の処理に用いられるデータを、適宜、記憶する。記憶装置１０６は、プログラムやデータなどを格納し、格納している情報を、適宜、プロセッサ１０１などに提供する。メモリ１０２や記憶装置１０６は、通信装置２０において、記憶部５０として動作する。

バス１０５は、プロセッサ１０１、メモリ１０２、入力装置１０３、出力装置１０４、記憶装置１０６、可搬記憶媒体駆動装置１０７、ネットワークインタフェース１０９を、相互にデータの送受信が可能になるように接続する。入力装置１０３は、キーボード、マウス、マイク、カメラなど、情報の入力に使用される任意の装置であり、出力装置１０４は、ディスプレイなど、データの出力に使用される任意の装置である。可搬記憶媒体駆動装置１０７は、メモリ１０２や記憶装置１０６のデータを可搬記憶媒体１０８に出力することができ、また、可搬記憶媒体１０８からプログラムやデータ等を読み出すことができる。ここで、可搬記憶媒体１０８は、Compact Disc Recordable（ＣＤ－Ｒ）やDigital Versatile Disk Recordable（ＤＶＤ－Ｒ）を含む、持ち運びが可能な任意の記憶媒体とすることができる。ネットワークインタフェース１０９は、適宜、通信装置２０が他の装置と通信するための処理を行う。ネットワークインタフェース１０９は、通信部３０として動作する。

＜第１の実施形態＞
以下、第１の実施形態を、分散台帳１５を用いて共有される情報の例、クレデンシャルの取得、取得済みのクレデンシャルの利用、属性対応メッセージを受信した通信装置２０での処理、クレデンシャルを受信した通信装置２０の処理に分けて説明する。以下の説明では、処理を行っている通信装置２０を明確にするために、処理を行っている通信装置２０の符号の末尾のアルファベットを通信装置２０の部分の符号の末尾に示すことがある。例えば、受信部３１ａは通信装置２０ａの受信部３１であり、取得部４１ｂは通信装置２０ｂの取得部４１である。

（１）分散台帳１５を用いて共有される情報の例
図４は、分散台帳１５を用いて共有される情報の例を説明する図である。分散台帳１５には、属性定義１６と検証用公開鍵情報１７が含まれている。属性定義１６は、属性定義ＩＤ、属性、属性定義を含む。属性定義１６は、分散台帳１５を共有するいずれかのノード１０に接続する通信装置２０が使用する属性の全てについて、その定義と属性を識別する情報を記録している。ここで、属性定義ＩＤは、属性を識別する識別情報である。属性定義は、各々の属性で表される情報の定義である。例えば、属性定義ＩＤ＝Ａ１の属性は、「名前」であり、苗字を漢字で表記する。同様に、属性定義ＩＤ＝Ａ２の属性は「発行者」であり、クレデンシャルの発行者として動作している通信装置２０に割り当てられた識別情報（ＡｇｅｎｔＩＤ）を数字で表記する。他の属性についても同様に属性定義ＩＤと属性定義が対応付けられている。

図４の例では、苗字は属性定義ＩＤ＝Ａ１、Ａ１０、Ａ１１のいずれかで表され得る。属性定義ＩＤ＝Ａ１の属性は「名前」であり、属性定義ＩＤ＝Ａ１０の属性は「氏名」であるが、いずれも属性定義は、苗字の漢字表記に対応付けられている。従って、属性定義ＩＤ＝Ａ１に対応する情報と属性定義ＩＤ＝Ａ１０に対応する情報は、属性の名称は異なるが、同じユーザ等については互換性のある情報として使用され得る。一方、属性定義ＩＤ＝Ａ１と属性定義ＩＤ＝Ａ１１のいずれも属性は「名前」であるが、属性定義ＩＤ＝Ａ１１に対応付けられた属性定義は、苗字のローマ字表記である。従って、属性定義ＩＤ＝Ａ１に対応する情報と属性定義ＩＤ＝Ａ１１に対応する情報は、属性の名称は一致するが、互いに互換性はない。各通信装置２０の判定部４２は、適宜、図４を参照しながら説明したように複数の属性についての属性定義を比較することにより、２つの属性の間に互換性があるかを判定できる。

検証用公開鍵情報１７には、通信装置、ＡｇｅｎｔＩＤ、公開鍵、アドレスが対応付けられている。ＡｇｅｎｔＩＤは、エントリ中の通信装置２０に割り当てられた識別情報である。公開鍵は、エントリ中の通信装置２０が暗号化に使用する秘密鍵の対となっている公開鍵である。アドレスは、エントリ中の通信装置２０に割り当てられたアドレスである。例えば、通信装置２０ａにはＡｇｅｎｔＩＤ＝３とアドレス＝ＩＰａが割り当てられており、通信装置２０ａが使用する秘密鍵の対となる公開鍵はＫｅｙＢである。通信装置２０ｂにはＡｇｅｎｔＩＤ＝１とアドレス＝ＩＰｂが割り当てられており、通信装置２０ｂが使用する秘密鍵の対となる公開鍵はＫｅｙＤである。同様に、通信装置２０ｃにはＡｇｅｎｔＩＤ＝２とアドレス＝ＩＰｃが割り当てられており、通信装置２０ｃが使用する秘密鍵の対となる公開鍵はＫｅｙＦである。

分散台帳１５には、属性定義１６と検証用公開鍵情報１７以外の情報も含まれ得る。分散台帳１５は、コンソーシアム１に参加しているノード１０間で共有されるので、通信装置２０の各々は、その通信装置２０が接続しているノード１０を介して、分散台帳１５中の情報を取得できる。

（２）クレデンシャルの取得
以下、コンソーシアム１中のノード１０間で図４に示す情報が分散台帳１５を用いて共有されている場合について、クレデンシャルの取得処理の例を説明する。以下の説明では、通信装置２０ａが使用する秘密鍵はＫｅｙＡであり、ＫｅｙＡのペアとなる公開鍵はＫｅｙＢであるとする。同様に、通信装置２０ｂが使用する秘密鍵はＫｅｙＣであり、ＫｅｙＣのペアとなる公開鍵はＫｅｙＤであるとする。さらに、通信装置２０ｃが使用する秘密鍵はＫｅｙＥであり、ＫｅｙＥのペアとなる公開鍵はＫｅｙＦであるとする。

図５のスキーマ定義１８は、クレデンシャルのフォーマットの例である。スキーマ定義１８には、スキーマＩＤとクレデンシャルに含められる各情報の種類を表す属性の識別情報が記録される。スキーマＩＤはスキーマ定義１８を識別する識別情報である。図５の例では、スキーマＩＤはＳＣ＿１である。ＳＣ＿１で識別されるスキーマ定義１８には、属性の識別情報として、Ａ２とＡ１も含まれている。

図５のＣＬは、スキーマ定義１８を用いて生成されたクレデンシャルの例である。ＣＬに示すクレデンシャルには、スキーマＩＤ＝ＳＣ＿１、Ａ２＝３、Ａ１＝鈴木という情報が含まれている。従って、ＣＬに示すクレデンシャルには、ＡｇｅｎｔＩＤ＝３が割り当てられた通信装置２０ａによってスキーマＩＤ＝ＳＣ＿１のスキーマ定義１８を用いて生成されたクレデンシャルであることと、ユーザの苗字が「鈴木」であることが記録されている。クレデンシャルの他に、クレデンシャルを識別するための識別情報（クレデンシャルＩＤ）も、クレデンシャルＣＬに含まれる。図５のＣＬは、クレデンシャルＩＤ＝ＣＩＤ＿１のクレデンシャルである。

スキーマ定義１８は、分散台帳１５を用いてノード１０間で共有されていてもよい。なお、各通信装置２０は、自装置がクレデンシャルを発行する際に使用するスキーマ定義１８を予め記憶できる。

図６は、ネットワークの例を説明する図である。図６の例では、コンソーシアム１にノード１０ａ、ノード１０ｂ、および、ノード１０ｃが参加している。ノード１０ａに通信装置２０ａが接続しており、通信装置２０ａに端末５ａが接続している。以下の説明では、端末５ａは、クレデンシャルの発行者２が操作する端末であるとする。ノード１０ｂに通信装置２０ｂが接続しており、通信装置２０ｂに端末５ｂが接続している。以下の説明では、端末５ｂは、クレデンシャルの保持者３が操作する端末であるとする。ノード１０ｃに通信装置２０ｃが接続しており、通信装置２０ｃに端末５ｃが接続している。以下の説明では、端末５ｃは、クレデンシャルの検証者４が操作する端末であるとする。なお、図６はネットワークの一例であり、ノード１０、通信装置２０、端末５の数や接続関係は、通信装置２０の各々がいずれかのノード１０に接続できる任意の形態に変更され得る。例えば、通信装置２０ａ～２０ｃの３台がすべてノード１０ｂに接続されていてもよい。

図６のネットワークにおいて、保持者３が発行者２からクレデンシャルを取得する際に行われる処理の例を説明する。まず、保持者３がクレデンシャルを取得する旨を発行者２に通知する。この通知は、通信装置２０や端末５を介して行われてもよく、また、端末５ｂと端末５ａの間の直接的な通信によって行われてもよい。さらに、発行者２がクレデンシャルの発行を行う対象を認識できる任意の方法が使用され得るので、例えば、保持者３から発行者２へのメールや郵送による申し込みが行われてもよい。

発行者２は、保持者３がクレデンシャルの発行を要求していることを認識すると、端末５ａから通信装置２０ａにクレデンシャルで証明する情報を含むデータ（証明用データ）を送信する（ステップＳ１１）。なお、端末５ａは、証明用データとともにクレデンシャルの送信先の情報として通信装置２０ｂのアドレス等を通信装置２０ａに送信する。

通信装置２０ａの受信部３１ａは、証明用データを受信すると、アプリケーション処理部４４ａに出力する。アプリケーション処理部４４ａは、クレデンシャルのフォーマットに応じてクレデンシャルを生成する。なお、通信装置２０ａは、図５に示すスキーマ定義１８を予め記憶部５０ａに記憶しているとする。この例では、アプリケーション処理部４４ａは、図５のＣＬに示すクレデンシャルを生成したとする。アプリケーション処理部４４ａは、生成したクレデンシャルを、秘密鍵５２ａ（ＫｅｙＡ）で暗号化する。送信部３２ａは、暗号化後のクレデンシャルを通信装置２０ｂに送信する（ステップＳ１２）。

通信装置２０ｂの受信部３１ｂは、受信したクレデンシャルをアプリケーション処理部４４ｂに出力する。クレデンシャルが暗号化されているので、取得部４１ｂは、通信装置２０ａに対応付けられた公開鍵をノード１０ｂに要求する（ステップＳ１３）。ノード１０ｂは、取得部４１ｂの要求に応じて、通信装置２０ａに対応付けられた公開鍵（ＫｅｙＢ）を送信する（ステップＳ１４）。このため、アプリケーション処理部４４ｂは、得られた公開鍵を用いて、クレデンシャルを復号化できる。

（３）取得済みのクレデンシャルの使用
以下、保持者３が発行者２から取得したクレデンシャルを検証者４に提示する場合を例として、取得済みのクレデンシャルを使用する場合に行われる処理の例を説明する。以下の例では、保持者３が検証者４に提示するクレデンシャルは図５に示すクレデンシャルＣＬであるとする。

図７は、クレデンシャルの送信のために行われる処理の例を説明する図である。クレデンシャルを提示しようとする保持者３は、端末５ｂを用いて、端末５ｂと通信する通信装置２０が通信装置２０ｂであることを通知する情報を、検証者４が使用する端末５ｃに通知する（ステップＳ２１）。端末５ｃは、端末５ｂから受信した情報に基づいて、端末５ｂを使用しているユーザが通信装置２０ｂを通じてクレデンシャルを提示しようとしていると認識する。そこで、端末５ｃは、取得しようとするユーザの情報がユーザの氏名であることと、情報の要求先が通信装置２０ｂであることを通信装置２０ｃに通知する（ステップＳ２２）。

通信装置２０ｃの受信部３１ｃは、端末５ｃからの要求を受信すると、アプリケーション処理部４４ｃに出力する。アプリケーション処理部４４ｃは要求する情報の属性定義ＩＤと要求先のアドレスを特定する。なお、アプリケーション処理部４４ｃは、通信装置２０ｃに接続している端末５ｃが取得する情報の属性に対応付けられている属性定義ＩＤを予め記憶しているものとする。この例では、アプリケーション処理部４４ｃは、端末５ｃが要求する「氏名」という属性を識別する属性定義ＩＤはＡ１０であるとする。情報の要求先である通信装置２０ｂのアドレスを記憶部５０に記憶していない場合、アプリケーション処理部４４ｃは、ノード１０ｃに通信装置２０ｂのアドレスを要求する。ノード１０ｃは、分散台帳１５中の検証用公開鍵情報１７を参照することにより、通信装置２０ｂに割り当てられたアドレスを返信する。要求する情報に対応する属性定義ＩＤと要求先のアドレスが特定できると、アプリケーション処理部４４ｃは、情報の要求先の通信装置２０に属性定義ＩＤを提示して情報を要求するための処理を行う。図７の例では、アプリケーション処理部４４ｃは、通信装置２０ｂに対する属性定義ＩＤ＝Ａ１０の情報の要求を、送信部３２ｃ経由で送信する（ステップＳ２３）。

通信装置２０ｂのアプリケーション処理部４４ｂは、受信部３１ｂを介して、属性定義ＩＤ＝Ａ１０の情報の要求を取得する。ここで、属性定義ＩＤ＝Ａ１０は、端末５ｂで使用される属性ではなく、また、これまでに通信装置２０ｂが受信したクレデンシャルにも使用されていないとする。アプリケーション処理部４４ｂは、要求されている属性定義ＩＤが属性対応テーブル５１ｂで他の属性定義ＩＤと対応付けられているかを判定する。ここでは、属性定義ＩＤ＝Ａ１０は属性対応テーブル５１ｂに記録されていないとする。すると、アプリケーション処理部４４ｂは、属性定義ＩＤ＝Ａ１０に対応付けられた定義が不明であることを取得部４１ｂと判定部４２ｂに通知する。

取得部４１ｂは、取得済みのクレデンシャルに含まれている属性の属性定義ＩＤに対応付けられている属性定義と、定義が不明であることが通知された属性定義ＩＤに対応付けられている属性定義をノード１０ｂに要求する（ステップＳ２４）。この例では、属性定義ＩＤ＝Ａ１０に対応付けられた定義が不明である。さらに、通信装置２０ｂは、クレデンシャルＣＬ（図５）に含まれている属性定義ＩＤ＝Ａ２およびＡ１の情報を取得している。そこで、取得部４１は、ノード１０に対して属性定義ＩＤ＝Ａ１、Ａ２、Ａ１０の各々について、属性定義を要求する。

ノード１０ｂは、分散台帳１５中の属性定義１６（図４）を参照することにより、要求された属性定義を特定すると、特定した結果を取得部４１ｂに通知する（ステップＳ１５）。この例では、以下の３つの定義情報が取得部４１ｂに通知される。

定義情報１
属性定義ＩＤ＝Ａ１
属性 ＝名前
属性定義 ＝苗字、漢字
定義情報２
属性定義ＩＤ＝Ａ２
属性 ＝発行者
属性定義 ＝ＡｇｅｎｔＩＤ、数字
定義情報３
属性定義ＩＤ＝Ａ１０
属性 ＝氏名
属性定義 ＝苗字、漢字

取得部４１ｂは、ノード１０ｂから取得した情報を判定部４２ｂに出力する。

判定部４２ｂは、入力された情報中の属性定義を比較する。アプリケーション処理部４４ｂから定義が不明であると通知された属性の属性定義ＩＤがＡ１０であるため、判定部４２は、属性定義ＩＤ＝Ａ１０に対応付けられている属性定義をキーとして、同じ属性定義に対応付けられた属性定義ＩＤがあるかを判定する。ここでは、属性定義ＩＤ＝Ａ１０に対応付けられている属性定義が苗字の漢字表記であるので、判定部４２ｂは、属性定義ＩＤ＝Ａ１０と属性定義ＩＤ＝Ａ１の間で属性定義が一致すると判定する。判定部４２ｂは、判定結果を属性対応テーブル５１ｂに記録する。

図８は、属性定義ＩＤ＝Ａ１０と属性定義ＩＤ＝Ａ１の間で属性定義が一致すると判定された場合に生成される属性対応テーブル５１の例である。属性対応テーブル５１は、属性定義が等しい２つの属性の組み合わせ同士を対応付ける。ここで、属性定義が等しい２つの属性は、情報の提示を要求してきた通信装置２０に対して属性の読み替えを要求することができる属性同士の組み合わせである。従って、属性対応テーブル５１は、クレデンシャルの宛先となる通信装置２０に対して読み替えを要求可能な属性の組み合わせを記録していると言える。属性定義が等しい２つの属性の組み合わせの一方に関する情報が属性１の欄に記録され、属性定義が等しい２つの属性の組み合わせの他方に関する情報が属性２の欄に記録される。いずれの属性についても、属性定義ＩＤと属性が記録される。図８では、属性定義ＩＤ＝Ａ１の情報が属性１の欄に記録されている。属性定義ＩＤ＝Ａ１の属性は「名前」である。一方、属性２の欄に記録される属性定義ＩＤ＝Ａ１０の属性は「氏名」である。

図９は、属性対応メッセージの例を説明する図である。判定部４２ｂでの判定と属性対応テーブル５１ｂの更新が行われると、生成部４３ｂは、判定部４２ｂでの判定結果を同じコンソーシアム１に属するノード１０に接続している他の通信装置２０に通知するための属性対応メッセージを生成する。図９のＦ１は、属性対応メッセージに含まれる情報の例である。属性対応メッセージには、メッセージ作成者ＩＤと対応する属性の組み合わせが含まれる。メッセージ作成者ＩＤは、属性対応メッセージを生成した通信装置２０に割り当てられたＡｇｅｎｔＩＤである。対応する属性は、判定部４２において、属性定義が等しいと判定された属性定義ＩＤの組み合わせである。なお、Ｆ１は属性対応メッセージに含まれる情報の一例であり、実装に応じて属性対応メッセージ中の情報は変更され得る。また、属性対応メッセージの送受信の際、Ｆ１に示した情報を含むペイロードに、適宜、ヘッダが付加され得る。

図９のＦ２は、図４～図８を参照しながら説明する例において、通信装置２０ｂの生成部４３ｂが生成する属性対応メッセージの例である。通信装置２０ｂにはＡｇｅｎｔＩＤ＝１が割り当てられているので、メッセージ作成者ＩＤは１である。また、属性定義ＩＤ＝Ａ１０と属性定義ＩＤ＝Ａ１の間で属性定義が一致すると判定されているので、対応する属性には、Ａ１＝Ａ１０が記録される。

送信部３２ｂは、生成部４３ｂが生成した属性対応メッセージを、接続先のノード１０が同じコンソーシアム１に属する全ての通信装置２０に送信する（図７のステップＳ２６）。なお、同じコンソーシアム１に属するノード１０に接続する全ての通信装置２０に属性対応メッセージを送信するために使用するアドレスが記憶部５０ｂに記憶されていない場合、取得部４１ｂは、属性対応メッセージを送信するために使用するアドレスをノード１０ｂから取得する。ノード１０ｂは、適宜、検証用公開鍵情報１７（図４）を参照することにより、属性対応メッセージを送信するために使用するアドレスを取得部４１ｂに通知できる。なお、接続先のノード１０が同じコンソーシアム１に属する全ての通信装置２０が宛先となるマルチキャストアドレスが設定されていても良い。この場合、各ノード１０は属性対応メッセージを送信するために使用するアドレスとして、マルチキャストアドレスを通信装置２０に通知できる。

アプリケーション処理部４４ｂは、通信装置２０ｃから要求された属性（属性定義ＩＤ＝Ａ１０）の情報を含むクレデンシャルとして、属性定義ＩＤ＝Ａ１の属性を含むクレデンシャルＣＬ（図５）を使用できると判定する。そこで、属性対応メッセージの送信後、アプリケーション処理部４４ｂは、送信部３２ｂを介してクレデンシャルＣＬを送信する（図７のステップＳ２７）。さらに、アプリケーション処理部４４ｂは、クレデンシャルＣＬを通信装置２０ａから取得したことも併せて通信装置２０ｃに通知する。なお、アプリケーション処理部４４ｂは、通信装置２０ａから受信した状態のクレデンシャルＣＬを送信するので、クレデンシャルＣＬは通信装置２０ａの秘密鍵５２（ＫｅｙＡ）で暗号化されている。

図１０は、情報を要求された通信装置２０が行う処理の例を説明するフローチャートである。なお、図１０は処理の一例であり、処理の手順は実装に応じて変更され得る。例えば、ステップＳ３７とＳ３８の処理の順序は互いに変更され得る。

受信部３１は、情報の要求を受信するまで待機する（ステップＳ３１でＮｏ）。受信部３１が情報の要求を受信すると、アプリケーション処理部４４は、要求で通知された属性定義ＩＤを含むクレデンシャルがあるかを判定する（ステップＳ３１でＹｅｓ、ステップＳ３２）。要求で通知された属性定義ＩＤを含むクレデンシャルを既に取得済みである場合、アプリケーション処理部４４は、通知された属性定義ＩＤを含むクレデンシャルを要求元に送信するための処理を行う（ステップＳ３２でＹｅｓ、ステップＳ３３）。

一方、要求で通知された属性定義ＩＤを含むクレデンシャルを有していない場合、アプリケーション処理部４４は、通知された属性定義ＩＤが属性対応テーブル５１にあるかを判定する（ステップＳ３２でＮｏ、ステップＳ３４）。通知された属性定義ＩＤが属性対応テーブル５１にない場合、通信装置２０は通知された属性定義ＩＤが割り当てられた属性と同じ情報を表す属性を知らない状態である（ステップＳ３４でＮｏ）。そこで、取得部４１は、通知された属性定義ＩＤ、および、通信装置２０が取得済みのクレデンシャルに含まれる属性定義ＩＤについて、ノード１０から属性定義を取得する（ステップＳ３５）。判定部４２は、ノード１０から得られた情報を用いて、要求で通知された属性定義ＩＤと定義が等しい属性定義ＩＤがあるかを判定する（ステップＳ３６）。以下の記載では、要求で通知された属性定義ＩＤと同じ属性定義を有する属性定義ＩＤのことを「代替属性定義ＩＤ」と記載することがある。

要求で通知された属性定義ＩＤと定義が等しい属性定義ＩＤがある場合、判定部４２は属性対応テーブル５１を更新する（ステップＳ３６でＹｅｓ、ステップＳ３７）。このため、要求で通知された属性定義ＩＤと代替属性定義ＩＤが、更新後の属性対応テーブル５１に対応付けて記録される。なお、代替属性定義ＩＤで識別される属性は、クレデンシャルの検証の際に、要求で通知された属性定義ＩＤで識別される属性の代替として使用され得る。生成部４３は、要求で通知された属性定義ＩＤと代替属性定義ＩＤを対応付けた属性対応メッセージを送信する（ステップＳ３８）。その後、アプリケーション処理部４４は、要求で通知された属性定義ＩＤの代替属性定義ＩＤを含むクレデンシャルを、要求元に送信する（ステップＳ３９）。

一方、要求で通知された属性定義ＩＤと定義が等しい属性定義ＩＤが無い場合、判定部４２は、送信可能なクレデンシャルがないことを端末５に通知するための処理を行う（ステップＳ３６でＮｏ、ステップＳ４１）。このため、送信可能なクレデンシャルがないという通知を受けた端末５のユーザは、適宜、新たなクレデンシャルを取得できる。

要求で通知された属性定義ＩＤを含むクレデンシャルを有さないが、通知された属性定義ＩＤが属性対応テーブル５１にある場合、通信装置２０は通知された属性定義ＩＤが割り当てられた属性と同じ情報を表す属性を特定できる（ステップＳ３４でＹｅｓ）。アプリケーション処理部４４は、要求で通知された属性定義ＩＤの代替属性定義ＩＤを含むクレデンシャルを有するかを判定する（ステップＳ４０）。要求で通知された属性定義ＩＤの代替属性定義ＩＤを含むクレデンシャルを有さない場合、アプリケーション処理部４４は、ステップＳ４１の処理を行う（ステップＳ４０でＮｏ）。要求で通知された属性定義ＩＤの代替属性定義ＩＤを含むクレデンシャルを有する場合、アプリケーション処理部４４はステップＳ３９の処理を行う（ステップＳ４０でＹｅｓ）。

（４）属性対応メッセージを受信した通信装置２０での処理
図１１は、属性対応メッセージを受信した通信装置２０で行われる処理の例を説明するフローチャートである。以下、図１１を参照しながら、図７のステップＳ２６により属性対応メッセージを受信した通信装置２０ａで行われる処理の例を説明する。

受信部３１ａは、属性対応メッセージを受信する（ステップＳ５１）。記憶部５０は、属性対応メッセージを保存する（ステップＳ５２）。図７を参照しながら説明した例では、記憶部５０ａに、属性定義ＩＤ＝Ａ１０と属性定義ＩＤ＝Ａ１の間で属性定義が一致することを示す属性対応メッセージが保存される。

取得部４１ａは、属性対応メッセージに含まれている属性定義ＩＤの各々について、属性定義をノード１０から取得する（ステップＳ５３）。このため、図７で示す例では、取得部４１ａは以下の２つの定義情報を取得する。

定義情報１
属性定義ＩＤ＝Ａ１
属性 ＝名前
属性定義 ＝苗字、漢字
定義情報２
属性定義ＩＤ＝Ａ１０
属性 ＝氏名
属性定義 ＝苗字、漢字

判定部４２ａは、属性対応メッセージで通知された対応関係が正しいかを判定する（ステップＳ５４）。図７で示す例では、属性対応メッセージに含まれている属性定義ＩＤのいずれも、属性定義は苗字の漢字表記である。従って、属性対応メッセージで通知された対応関係は正しい（ステップＳ５４でＹｅｓ）。このため、判定部４２ａは、属性対応メッセージで通知された情報を用いて属性対応テーブル５１ａを更新する（ステップＳ５５）。従って、ステップＳ５５の処理により、属性対応テーブル５１ａに以下の情報が記録される。

属性１
属性定義ＩＤ＝Ａ１
属性 ＝名前
属性２
属性定義ＩＤ＝Ａ１０
属性 ＝氏名

一方、属性対応メッセージで通知された対応関係が正しくないと判定した場合、判定部４２は属性対応テーブル５１を更新せずに処理を数量する（ステップＳ５４でＮｏ）。

なお、以上の処理は、属性対応メッセージを受信した全ての通信装置２０で行われる。従って、図７の例では、通信装置２０ｃにおいても、属性対応メッセージの受信により通信装置２０ａと同様の処理が行われる。

（５）クレデンシャルを受信した通信装置２０の処理
図１２は、通信装置２０が行う検証処理の例を説明するフローチャートである。以下、図１２を参照しながら、図７のステップＳ２７によりクレデンシャルを受信した通信装置２０ｃで行われる処理の例を説明する。なお、図１２の処理が行われる時点では、属性定義ＩＤ＝Ａ１０と属性定義ＩＤ＝Ａ１の間で属性定義が一致することが属性対応テーブル５１ｃに記録されているとする。

受信部３１ｃは、クレデンシャルを受信するまで待機する（ステップＳ６１でＮｏ）。受信部３１ｃがクレデンシャルを受信すると、アプリケーション処理部４４ｃは、受信したクレデンシャルの復号処理を行う（ステップＳ６２）。復号処理に際して、取得部４１ｃは、クレデンシャルＣＬを生成した通信装置２０ａに対応付けられている公開鍵ＫｅｙＢをノード１０ｃから取得し、アプリケーション処理部４４ｃに出力できる。アプリケーション処理部４４ｃは、情報の要求先に通知した属性定義ＩＤが、復号後のクレデンシャルＣＬに含まれているかを判定する（ステップＳ６３）。情報の要求先に通知した属性定義ＩＤが復号後のクレデンシャルＣＬに含まれている場合、アプリケーション処理部４４ｃは、情報の要求先に通知した属性定義ＩＤに対応付けられた情報を取得する（ステップＳ６３でＹｅｓ、ステップＳ６４）。

情報の要求先に通知した属性定義ＩＤが、復号後のクレデンシャルＣＬに含まれていない場合、アプリケーション処理部４４ｃは、通知した属性定義ＩＤの代替属性定義ＩＤがクレデンシャルに含まれるかを判定する（ステップＳ６３でＮｏ、ステップＳ６５）。ここで、代替属性定義ＩＤは、通知した属性定義ＩＤに属性対応テーブル５１ｃ中で対応付けられた属性定義ＩＤである。通知した属性定義ＩＤの代替属性定義ＩＤがクレデンシャルに含まれる場合、アプリケーション処理部４４ｃは、代替属性定義ＩＤに対応付けられた情報を取得する（ステップＳ６５でＹｅｓ、ステップＳ６７）。

図７を参照しながら説明した例では、通信装置２０ｃから属性定義ＩＤ＝Ａ１０の情報を通信装置２０ｂに要求しているが、通信装置２０ｂから受信したクレデンシャルには属性定義ＩＤ＝Ａ１０が含まれず、属性定義ＩＤ＝Ａ１が含まれている。また、属性定義ＩＤ＝Ａ１０と属性定義ＩＤ＝Ａ１の間で属性定義が一致することが属性対応テーブル５１ｃに記録されているので、Ａ１はＡ１０の代替属性定義ＩＤである。そこで、アプリケーション処理部４４ｃは、クレデンシャルＣＬ（図５）のＡ１に対応付けられた情報「鈴木」をユーザの「氏名」として取得する。

一方、情報の要求先に通知した属性定義ＩＤと通知した属性定義ＩＤの代替属性定義ＩＤのいずれもクレデンシャルに含まれない場合、アプリケーション処理部４４は要求した情報が通知されていないと判定する（ステップＳ６５でＮｏ）。この場合、アプリケーション処理部４４ｃは、クレデンシャルの送信元に、検証失敗を通知する（ステップＳ６６）。

以上説明したように、第１の実施形態では、属性対応テーブル５１を用いた属性の読み替えが行われる。このため、クレデンシャルを発行した通信装置２０と検証を行う通信装置２０の間で、処理に使用する属性が異なっていても、属性対応テーブル５１を用いて属性を読み替えて、受信したクレデンシャル中の情報を検証処理に使用できるようになる。従って、検証処理の失敗を防止しやすくできるとともに、保持者３が取得済みのクレデンシャルを利用しやすくでき、検証処理が効率化される。

第１の実施形態によると、属性定義が同じであることを特定した通信装置２０は、他の通信装置２０に対して属性対応メッセージを用いて属性定義が同じ属性の組み合わせを通知する。さらに、属性対応メッセージを受信した各通信装置２０においても、分散台帳１５中の情報を用いて属性対応メッセージが正しいことを確認すると、属性対応メッセージで通知された属性同士を対応付ける。このため、同じコンソーシアム１に属するノード１０に接続した通信装置２０間では、属性対応メッセージで通知された属性の組み合わせについて、属性対応テーブル５１を用いることによる属性の読み替えが可能になる。

＜第２の実施形態＞
第２の実施形態では、クレデンシャルを発行した通信装置２０とクレデンシャルを検証する通信装置２０が、互いに異なるコンソーシアムに属するノード１０に接続されている場合について説明する。

図１３は、第２の実施形態で行われる通信の例を説明する図である。図１３に示すネットワークには、コンソーシアム１ａとコンソーシアム１ｂが含まれる。コンソーシアム１ａにＩＤ＝Ｃ１が割り当てられ、コンソーシアム１ｂにＩＤ＝Ｃ２が割り当てられている。ノード１０ｄ、ノード１０ｅ、および、ノード１０ｇはコンソーシアム１ａに参加している。ノード１０ｆ、ノード１０ｈ、および、ノード１０ｉはコンソーシアム１ｂに参加している。なお、図１３は各コンソーシアム１に参加しているノード１０の一部を示しており、いずれのコンソーシアム１にも図示されている以外のノード１０が参加している。

通信装置２０ｄはノード１０ｄと端末５ｄに接続されている。通信装置２０ｇはノード１０ｉと端末５ｇに接続されている。通信装置２０ｅは、ノード１０ｅ、ノード１０ｆ、および、端末５ｅに接続されている。通信装置２０ｆは、ノード１０ｇ、ノード１０ｈ、および、端末５ｆに接続されている。ここで、通信装置２０ｅと通信装置２０ｆは、いずれも、コンソーシアム１ａに参加しているノード１０とコンソーシアム１ｂに参加しているノード１０の両方に接続されている。従って、通信装置２０ｅと通信装置２０ｆは、コンソーシアム１ａで共有されている属性定義１６ａとコンソーシアム１ｂで共有されている属性定義１６ｂの両方を取得できる。一方、通信装置２０ｄは属性定義１６ｂの情報を参照することはなく、通信装置２０ｇは属性定義１６ａの情報を参照することはない。

図１４は、各コンソーシアム１で共有される属性定義１６の例を説明する図である。第２の実施形態でも、各コンソーシアム１に参加するノード１０は、分散台帳１５を用いて属性定義１６と検証用公開鍵情報１７を共有する。以下の説明では、コンソーシアム１ａに参加しているノード１０間で属性定義１６ａが共有され、コンソーシアム１ｂに参加しているノード１０間で属性定義１６ｂが共有されているとする。このため、コンソーシアム１ａでは、属性定義ＩＤ＝Ａ１の属性は「名前」であり、属性定義は苗字の漢字表記である。一方、コンソーシアム１ｂでは、苗字の漢字表記が属性定義として定義されている属性は「氏名」であり、属性定義ＩＤはＡ２である。属性＝発行者の属性定義は、属性定義１６ａと属性定義１６ｂのいずれでもＡｇｅｎｔＩＤの数字表記であるが、属性定義ＩＤはコンソーシアム１間で異なっている。

以下、図１３のネットワーク中で、発行者２が端末５ｄを使用し、保持者３が端末５ｅを使用し、検証者４が端末５ｇを使用しているとする。さらに、保持者３は、発行者２からクレデンシャルＣＬ１を取得しているが、コンソーシアム１ｂで共有されている属性定義１６ｂに基づいて生成されたクレデンシャルを有していないものとする。コンソーシアム１内でのクレデンシャルの取得処理は、第１の実施形態で説明したとおりである。クレデンシャルＣＬ１は属性定義１６ａに従って生成されるので、保持者３の名字の漢字表記が属性定義ＩＤ＝Ａ１（属性＝名前）に対応付けて記録される。なお、第２の実施形態では、各通信装置２０は、自装置が使用した属性定義１６を共有しているコンソーシアム１のＩＤをクレデンシャルに含めるものとする。図１３の例では、通信装置２０ｄは属性定義１６ａを使用しているので、クレデンシャルＣＬ１には、コンソーシアムのＩＤ＝Ｃ１という情報が含まれる。

ここで、端末５ｅを使用する保持者３が、端末５ｇを使用する検証者４から属性定義ＩＤ＝Ａ２（属性＝氏名）の情報を要求される場合を例とする。なお、端末５ｅと端末５ｇの間の通信や端末５ｇの接続先となっている通信装置２０ｇからの情報要素の要求は、第１の実施形態と同様に行われる。すなわち、端末５ｅは、通信装置２０ｅを使用していることを端末５ｇに通知し、端末５ｇは通信装置２０ｇに対して、「氏名」に関する情報を通信装置２０ｅから取得することを要求する。

属性定義１６ｂ（図１４）では「氏名」という属性は属性定義ＩＤ＝Ａ２に対応付けられているため、通信装置２０ｇのアプリケーション処理部４４ｇは、属性定義ＩＤ＝Ａ２の情報を要求することを決定する。このとき、アプリケーション処理部４４ｇは、コンソーシアム１ｂのＩＤも併せて通信装置２０ｅに通知する。従って、アプリケーション処理部４４ｇは、以下の情報を含む要求を通信装置２０ｅに送信するための処理を行う。

送信元：通信装置２０ｇ
宛先 ：通信装置２０ｅ
要求する属性の属性定義ＩＤ ：Ａ２
属性を定義したコンソーシアムのＩＤ：Ｃ２

通信装置２０ｅのアプリケーション処理部４４ｅは、受信部３１ｅを介して、コンソーシアム１ｂ（ＩＤ＝Ｃ２）での属性定義ＩＤ＝Ａ２の情報の要求を取得する。端末５ｅを使用する保持者３は、コンソーシアム１ｂで共有されている属性定義１６ｂに基づいて生成されたクレデンシャルを有していない。このため、通信装置２０ｅは、コンソーシアムのＩＤ＝Ｃ２を含むクレデンシャルを有していない。アプリケーション処理部４４ｅは、要求されている属性定義ＩＤが属性対応テーブル５１ｅで他の属性定義ＩＤと対応付けられているかを判定する。ここでは、コンソーシアムＩＤ＝Ｃ２と属性定義ＩＤ＝Ａ２の組み合わせに対応する属性の情報は属性対応テーブル５１ｅに記録されていないとする。すると、アプリケーション処理部４４ｅは、コンソーシアムＩＤ＝Ｃ２と属性定義ＩＤ＝Ａ２の組み合わせに対応付けられた定義が不明であることを、取得部４１ｅと判定部４２ｅに通知する。

取得部４１ｅは、取得済みのクレデンシャルＣＬ１に含まれている属性定義ＩＤに対応付けられている属性定義を、コンソーシアム１ａに属するノード１０ｅに問い合わせる（ステップＳ７１）。さらに、取得部４１ｅは、定義が不明であることが通知された属性定義ＩＤ＝Ａ２に対応付けられている属性定義を、その属性定義ＩＤに対応付けられたコンソーシアム１ｂに含まれるノード１０ｆに要求する（ステップＳ７２）。

ノード１０ｅは、分散台帳１５ａ中の属性定義１６ａ（図１４）を参照することにより、要求された属性定義を特定すると、特定した結果を取得部４１ｅに通知する（ステップＳ７３）。このとき、ノード１０ｅは、ノード１０ｅが属するコンソーシアム１のＩＤも併せて通知する。このため、この例では、以下の定義情報がノード１０ｅから取得部４１ｅに通知される。

定義情報１
コンソーシアムＩＤ＝Ｃ１
属性定義ＩＤ＝Ａ１
属性 ＝名前
属性定義 ＝苗字、漢字

同様に、ノード１０ｆは、分散台帳１５ｂ中の属性定義１６ｂ（図１４）を参照することにより要求された属性定義を特定し、特定した結果を取得部４１ｅに通知する（ステップＳ７４）。この例では、以下の定義情報がノード１０ｆから取得部４１ｅに通知される。

定義情報１
コンソーシアムＩＤ＝Ｃ２
属性定義ＩＤ＝Ａ２
属性 ＝氏名
属性定義 ＝苗字、漢字

取得部４１ｅは、ノード１０ｅ、ノード１０ｆの各々から取得した情報を判定部４２ｅに出力する。

判定部４２ｅは、定義が不明であると通知されたコンソーシアムＩＤ＝Ｃ２の属性定義ＩＤ＝Ａ２に対応付けられた属性定義を、コンソーシアムＩＤ＝Ｃ１の属性定義ＩＤ＝Ａ１に対応付けられた属性定義と比較する。この例ではいずれの属性定義の苗字の漢字表記である。そこで、判定部４２ｅは、コンソーシアムＩＤ＝Ｃ２の属性定義ＩＤ＝Ａ２の属性定義は、コンソーシアムＩＤ＝Ｃ１の属性定義ＩＤ＝Ａ１の属性定義と一致すると判定する。判定部４２ｅは、判定結果を属性対応テーブル５１ｅに記録する。

図１５は、第２の実施形態で使用される属性対応テーブルの例を説明する図である。第２の実施形態でも属性対応テーブル５１は属性定義が等しい２つの属性の組み合わせ同士を対応付けるが、各々の属性に対して、その属性が使用されるコンソーシアム１のＩＤも併せて記録する。すなわち、属性対応テーブル５１では、いずれの属性についても、コンソーシアムのＩＤ、属性定義ＩＤ、および、属性が記録される。図１５では、コンソーシアムＩＤ＝Ｃ１のコンソーシアム１ａで使用される属性定義ＩＤ＝Ａ１の情報が属性１の欄に記録されている。属性定義ＩＤ＝Ａ１の属性は「名前」である。一方、属性２の欄には、コンソーシアムＩＤ＝Ｃ２のコンソーシアム１ｂで使用される記録される属性定義ＩＤ＝Ａ２の情報が記録される。コンソーシアムＩＤ＝Ｃ２での属性定義ＩＤ＝Ａ２の属性は「氏名」である。

一方、生成部４３ｅは、判定部４２ｅの判定結果を他の通信装置２０に通知するための属性対応メッセージＭ１を生成する。さらに、生成部４３ｅは、コンソーシアム１ａに属するノード１０に接続している他の通信装置２０と、コンソーシアム１ｂに属するノード１０に接続している他の通信装置２０に、属性対応メッセージＭ１を送信するための処理を行う（図１３のステップＳ７５）。なお、属性対応メッセージＭ１の送信の際に使用するアドレス情報の取得は、第１の実施形態と同様に行われる。ここで、属性対応メッセージの送信は、１つのコンソーシアム１で共有される属性定義１６にアクセス可能な通信装置２０と、複数のコンソーシアム１の各々で共有される複数の属性定義１６にアクセス可能な通信装置２０の両方に送信される。従って、ステップＳ７５の処理により、図１３中の通信装置２０ｄ、通信装置２０ｆ、通信装置２０ｇのいずれも、属性対応メッセージＭ１を受信する。

図１６は、第２の実施形態で使用される属性対応メッセージの例を説明する図である。図１６は、図１３で送信される属性対応メッセージＭ１に含まれる情報の例を示す。属性対応メッセージには、メッセージ種別が属性対応メッセージであることを示す情報、発信者ＩＤ、属性１に関する情報、および、属性２に関する情報が含まれる。属性１と属性２は、属性定義が一致すると判定された２つの属性のいずれかである。属性１と属性２の各々には、その属性を定義したコンソーシアム１のＩＤ、その属性に対応付けられた属性定義ＩＤ、属性の名称が含まれる。図１６は、属性１がコンソーシアムＩＤ＝Ｃ１の属性定義ＩＤ＝Ａ１であり、属性２がコンソーシアムＩＤ＝Ｃ２の属性定義ＩＤ＝Ａ２である場合の属性対応メッセージの例を示している。

図１７は、第２の実施形態で行われる処理の例を説明する図である。図１７は、図を見やすくするため、図１３のネットワーク中の装置の一部を省略している。属性対応メッセージＭ１を受信した各通信装置２０の取得部４１は、自装置が属性対応メッセージＭ１にＩＤが含まれている２つのコンソーシアム（１ａ、１ｂ）の各々で使用されている属性定義１６を取得可能であるかを判定する。

通信装置２０は、属性対応メッセージＭ１中のＩＤで識別される２つのコンソーシアム（１ａ、１ｂ）の各々で使用されている属性定義１６の両方の情報を参照しない装置である場合、受信した属性対応メッセージＭ１の内容が正しいかの判定を行わない。属性対応メッセージＭ１中のＩＤで識別される２つのコンソーシアムの各々で使用されている属性定義１６の両方を参照しない通信装置２０は、属性対応メッセージで通知された対応関係について、その情報の受信回数をカウントする。例えば、通信装置２０ｄおよび通信装置２０ｇの判定部４２は、属性対応メッセージＭ１の内容が正しいかの判定を行わないが、属性対応メッセージの内容ごとに、受信数を計数する。従って、判定部４２ｇは、属性対応メッセージＭ１を受信すると以下の情報を記憶する。

対応関係１
属性１を定義したコンソーシアムのＩＤ＝Ｃ１
属性１の属性定義ＩＤ＝Ａ１
属性２を定義したコンソーシアムのＩＤ＝Ｃ２
属性２の属性定義ＩＤ＝Ａ２
対応関係１の情報の受信数：１

通信装置２０ｄでも通信装置２０ｇと同様の処理が行われる。

一方、属性対応メッセージＭ１中のＩＤで識別される２つのコンソーシアム（１ａ、１ｂ）の各々で使用されている属性定義１６を取得可能である場合、通信装置２０は、属性対応メッセージＭ１の内容が正しいかを判定する処理を行う。例えば、通信装置２０ｆは、属性対応メッセージＭ１中のＩＤで識別される２つのコンソーシアム（１ａ、１ｂ）の各々で使用されている属性定義１６を取得可能である。そこで、通信装置２０ｆの取得部４１ｆは、コンソーシアム１ａに参加しているノード１０ｇに対して、属性定義ＩＤ＝Ａ１の属性定義と属性を要求する。さらに、取得部４１ｆは、コンソーシアム１ｂに参加しているノード１０ｈに対して、属性定義ＩＤ＝Ａ２の属性定義と属性を要求する。

ノード１０ｇは、分散台帳１５ａ中の属性定義１６ａ（図１４）を参照することにより、要求された属性定義を特定し、特定した結果を取得部４１ｆに通知する。このため、以下の定義情報がノード１０ｇから取得部４１ｆに通知される。

定義情報１
コンソーシアムＩＤ＝Ｃ１
属性定義ＩＤ＝Ａ１
属性 ＝名前
属性定義 ＝苗字、漢字

同様に、ノード１０ｈは、分散台帳１５ｂ中の属性定義１６ｂ（図１４）を参照することにより要求された属性定義を特定し、特定した結果を取得部４１ｆに通知する。この例では、以下の定義情報がノード１０ｈから取得部４１ｆに通知される。

定義情報１
コンソーシアムＩＤ＝Ｃ２
属性定義ＩＤ＝Ａ２
属性 ＝氏名
属性定義 ＝苗字、漢字

取得部４１ｆは、ノード１０ｇ、ノード１０ｈの各々から取得した情報を判定部４２ｆに出力する。このため、判定部４２ｆは、コンソーシアムＩＤ＝Ｃ２の属性定義ＩＤ＝Ａ２の属性定義は、コンソーシアムＩＤ＝Ｃ１の属性定義ＩＤ＝Ａ１の属性定義と一致すると判定する。判定部４２ｆは、判定結果が属性対応テーブル５１ｆに記録されていない場合、属性対応テーブル５１ｆに記録するので、属性対応テーブル５１ｆには図１５に示す情報が追加される。生成部４３ｆは、属性対応メッセージＭ１に含まれている２つの属性についての属性対応メッセージＭ２を生成する。さらに、生成部４３ｆは、コンソーシアム１ａに属するノード１０に接続している他の通信装置２０と、コンソーシアム１ｂに属するノード１０に接続している他の通信装置２０に、属性対応メッセージＭ２を送信するための処理を行う（ステップＳ７６）。なお、ネットワークの輻輳を避けるため、生成部４３ｆは、属性対応メッセージＭ２と同じ内容のメッセージを所定の期間内に送信したことがある場合には、属性対応メッセージＭ２の送信を行わない。

なお、判定部４２において属性定義が一致しないと判定された場合、生成部４３は属性非対応メッセージを生成する。属性非対応メッセージは、図１６と同様であるが、メッセージ種別は属性非対応メッセージに設定されている。属性非対応メッセージも、コンソーシアム１ａに属するノード１０に接続している他の通信装置２０と、コンソーシアム１ｂに属するノード１０に接続している他の通信装置２０に、送信される。

ステップＳ７６に示すように属性対応メッセージＭ２が送信されると、通信装置２０ｅ、通信装置２０ｇ、通信装置２０ｄなどの通信装置２０が属性対応メッセージＭ２を受信する。属性対応メッセージＭ２も各通信装置２０において、属性対応メッセージＭ１と同様に処理される。このため、属性定義１６ａと属性定義１６ｂの両方の情報を取得可能な通信装置２０では、属性対応メッセージＭ２の情報が正しいかが判定される。また、属性対応メッセージＭ２の情報が正しいかを判定した通信装置２０のうちで属性対応メッセージＭ２と同じ内容の属性対応メッセージを所定期間内に送信していない通信装置２０は、属性対応メッセージを送信する。一方、通信装置２０ｄや通信装置２０ｇでも、属性対応メッセージＭ２は、属性対応メッセージＭ１と同様に処理される。このため、通信装置２０ｇ中の判定部４２ｇは、属性対応メッセージＭ２を受信すると、以下のように記憶している受信数を更新する。

対応関係１
属性１を定義したコンソーシアムのＩＤ＝Ｃ１
属性１の属性定義ＩＤ＝Ａ１
属性２を定義したコンソーシアムのＩＤ＝Ｃ２
属性２の属性定義ＩＤ＝Ａ２
対応関係１の情報の受信数：２

図１８は、第２の実施形態で行われる処理の例を説明する図である。各通信装置２０は、属性対応メッセージで通知された属性の対応関係の情報の受信数を閾値Ｔｈ１と比較する。図１７を参照しながら説明した処理が各通信装置２０によって行われることにより、対応関係の情報の受信数が閾値Ｔｈ１以上になると、閾値Ｔｈ１以上の数の通信装置２０が属性対応メッセージの内容が正しいと判定していることになる。そこで、属性対応メッセージで通知された情報が正しいかを自装置で判定しない装置の判定部４２は、対応関係についての受信数が閾値Ｔｈ１以上になると、その対応関係が正しいものと判定して、属性対応テーブル５１を更新する。

図１８の例では、閾値Ｔｈ１＝３であるとする。通信装置２０ｇは、コンソーシアムＩＤ＝Ｃ２の属性定義ＩＤ＝Ａ２の属性定義は、コンソーシアムＩＤ＝Ｃ１の属性定義ＩＤ＝Ａ１の属性定義と一致するという内容の属性対応メッセージＭ１～Ｍ３を受信したとする。すると、属性対応テーブル５１ｇに、属性対応メッセージＭ１～Ｍ３で通知された情報を記録する。なお、図１８では、紙面の関係で属性対応テーブル５１ｇの情報の一部を示しているが、属性対応テーブル５１ｇも図１５と同様のフォーマットを有する。

図１９は、クレデンシャルの送信処理の例を説明する図である。図１９でも、図１３に示すネットワークに含まれる一部の装置を図示している。図１３～図１８を参照しながら説明した処理を行う前に、予め、通信装置２０ｅは、通信装置２０ｄからクレデンシャルＣＬ１を受信している（ステップＳ７０）。また、クレデンシャルＣＬ１には、属性定義ＩＤ＝Ａ１の情報が「鈴木」であることが記録されているとする。

図１３～図１８を参照しながら説明した処理により、コンソーシアムＩＤ＝Ｃ２の属性定義ＩＤ＝Ａ２の属性定義がコンソーシアムＩＤ＝Ｃ１の属性定義ＩＤ＝Ａ１の属性定義と一致することが、通信装置２０ｇの属性対応テーブル５１ｇに記録されたとする。

その後、通信装置２０ｅのアプリケーション処理部４４ｅは、送信部３２ｅを介して、クレデンシャルＣＬ１を通信装置２０ｇに送信する（ステップＳ７７）。ステップＳ７７の時点では、属性対応テーブル５１ｇが更新されているので、アプリケーション処理部４４ｇは、コンソーシアムＩＤ＝Ｃ１での属性定義ＩＤ＝Ａ１は、コンソーシアムＩＤ＝Ｃ２での属性定義ＩＤ＝Ａ２と定義が同じことを認識できる。そこで、クレデンシャルＣＬ１中の属性定義ＩＤ＝Ａ１（名前）をコンソーシアムＩＤ＝Ｃ２での属性定義ＩＤ＝Ａ２（氏名）と読み替えて処理する。このため、コンソーシアム１ａとコンソーシアム１ｂの間で属性や属性定義ＩＤが異なっているが、通信装置２０ｇはクレデンシャルＣＬ１を用いた情報の取得に成功する。

以上説明したように、第２の実施形態では、クレデンシャルの発行元と検証を行う装置が異なる属性定義１６を使用していても、属性対応テーブル５１を用いた属性の読み替えが行われる。従って、検証処理の失敗を防止しやすくできるとともに、保持者３が取得済みのクレデンシャルを利用しやすくでき、検証処理が効率化される。

図２０は、第２の実施形態で行われる処理の例を説明するフローチャートである。図２０は、比較対象となっている２つの属性の各々に対する定義を含む２つの属性定義１６を取得可能な通信装置２０で行われる処理の例である。

受信部３１は、属性対応メッセージまたは属性非対応メッセージを受信するまで待機する（ステップＳ８１でＮｏ）。属性対応メッセージまたは属性非対応メッセージを受信すると、判定部４２は、受信したメッセージに記載されている２つの属性の定義が同じであるかを判定する（ステップＳ８１でＹｅｓ、ステップＳ８２）。メッセージ中の２つの属性ＩＤに対応する定義が同じである場合、判定部４２は、受信したメッセージ中の２つの属性ＩＤに対応する定義が同じことが属性対応テーブル５１に登録済みであるかを判定する（ステップＳ８２でＹｅｓ、ステップＳ８３）。受信したメッセージに記載されている２つの属性の定義が同じであることが属性対応テーブル５１に登録されていない場合、判定部４２は属性対応テーブル５１を更新する（ステップＳ８３でＮｏ、ステップＳ８４）。その後、生成部４３は、同一の属性定義ＩＤの組み合わせに関する属性対応メッセージを送信しているかを判定する（ステップＳ８５）。同一の属性定義ＩＤの組み合わせに関する属性対応メッセージを送信していない場合、定義が同じであると判定した属性定義ＩＤの組み合わせを含む属性対応メッセージを送信する（ステップＳ８５でＮｏ、ステップＳ８６）。

一方、同一の属性定義ＩＤの組み合わせに関する属性対応メッセージを送信している場合、ステップＳ８１に戻る（ステップＳ８５でＮｏ）。ステップＳ８３において、定義が同じであると判定した属性定義ＩＤの組み合わせが属性対応テーブル５１に登録済みであると判定した場合（ステップＳ８３でＹｅｓ）、生成部４３は、ステップＳ８５以降の処理を行う。

ステップＳ８２において、判定部４２は受信したメッセージに記載されている２つの属性ＩＤに対応する定義が異なると判定したとする（ステップＳ８２でＮｏ）。この場合、生成部４３は、同一の属性定義ＩＤの組み合わせに関する属性非対応メッセージを送信しているかを判定する（ステップＳ８７）。同一の属性定義ＩＤの組み合わせに関する属性非対応メッセージを送信している場合、ステップＳ８１に戻る（ステップＳ８７でＹｅｓ）。同一の属性定義ＩＤの組み合わせに関する属性非対応メッセージを送信していない場合、生成部４３は、定義が異なると判定した属性定義ＩＤの組み合わせを含む属性非対応メッセージを送信する（ステップＳ８７でＮｏ、ステップＳ８８）。

図２１は、比較対象となっている２つの属性の各々に対する定義を含む２つの属性定義１６のうちの一方を取得できるが他方を取得しない通信装置２０で行われる処理の例である。図２１の例では、各通信装置２０は、閾値Ｔｈ１に加えて属性非対応メッセージの受信数と比較するための閾値Ｔｈ２も記憶している。閾値Ｔｈ２は閾値Ｔｈ１と異なる値であっても良く、また、閾値Ｔｈ１と同じ値であっても良い。属性非対応メッセージを受信した数が閾値Ｔｈ２以上になることが削除条件として通信装置２０で記憶されているとする。

取得部４１は、属性対応メッセージを受信したかを判定する（ステップＳ９１）。属性対応メッセージを受信した場合、判定部４２は、属性対応メッセージを保存する（ステップＳ９１でＹｅｓ、ステップＳ９２）。判定部４２は、受信した属性対応メッセージと同一の属性定義ＩＤの組み合わせが属性対応テーブル５１に存在せず、かつ、登録条件を満たしているかを判定する（ステップＳ９３）。ここで、登録条件は、受信した属性対応メッセージと同一の属性定義ＩＤの組み合わせを含む属性対応メッセージの受信数が閾値Ｔｈ１以上であることである。属性定義ＩＤの組み合わせが属性対応テーブル５１に存在せず、かつ、登録条件を満たす場合、判定部４２は、受信した属性対応メッセージと同一の属性定義ＩＤの組み合わせを属性対応テーブル５１に登録する（ステップＳ９３でＹｅｓ、ステップＳ９４）。その後、ステップＳ９１以降の処理が繰り返される。また、属性定義ＩＤの組み合わせが属性対応テーブル５１に存在するか、または、登録条件を満たさない場合、ステップＳ９１以降の処理が繰り返される（ステップＳ９３でＮｏ）。

一方、属性対応メッセージを受信していないと判定した場合、取得部４１は、属性非対応メッセージを受信したかを判定する（ステップＳ９１でＮｏ、ステップＳ９５）。属性非対応メッセージも受信していない場合、ステップＳ９１以降の処理が繰り返される（ステップＳ９５でＮｏ）。属性非対応メッセージを受信した場合、判定部４２は、属性非対応メッセージを保存する（ステップＳ９５でＹｅｓ、ステップＳ９６）。

判定部４２は、受信した属性非対応メッセージと同一の属性定義ＩＤの組み合わせが属性対応テーブル５１に登録済みであり、かつ、削除条件を満たしているかを判定する（ステップＳ９７）。属性定義ＩＤの組み合わせが属性対応テーブル５１に登録されており、かつ、削除条件を満たす場合、判定部４２は、受信した属性非対応メッセージと同一の属性定義ＩＤの組み合わせを属性対応テーブル５１から削除する（ステップＳ９７でＹｅｓ、ステップＳ９８）。その後、ステップＳ９１以降の処理が繰り返される。属性定義ＩＤの組み合わせが属性対応テーブル５１に登録されていないか、または、削除条件を満たさない場合、ステップＳ９１以降の処理が繰り返される（ステップＳ９７でＮｏ）。

以上説明したように、第２の実施形態では、クレデンシャルの発行元と検証を行う装置が異なる属性定義１６を使用していても、属性対応テーブル５１を用いた属性の読み替えが行われる。このため、クレデンシャルを発行した通信装置２０と検証を行う通信装置２０の間で、属性の定義が異なっていても、属性対応テーブル５１を用いて属性を読み替えて、受信したクレデンシャル中の情報を検証処理に使用できるようになる。従って、検証処理の失敗を防止しやすくできるとともに、保持者３が取得済みのクレデンシャルを利用しやすくでき、検証処理が効率化される。

＜その他＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。

判定部４２が２つの属性間で定義が等しいかを判定する契機は、他の通信装置２０からの情報の要求の受信や、属性対応メッセージもしくは属性非対応メッセージ受信に限定されない。例えば、判定部４２は、アプリケーション処理部４４が複数のクレデンシャルを取得したことを契機として、クレデンシャル中の情報と属性の比較処理を行ってもよい。

例えば、第１の実施形態において、通信装置２０ａのアプリケーション処理部４４ａが市役所で使用されている通信装置２０ｍから以下の情報を含む住所証明のクレデンシャルを取得したとする。

クレデンシャルＩＤ＝ＣＩＤ＿２
スキーマＩＤ：ＳＣ＿２
Ａ１：鈴木
Ａ５：神奈川県川崎市

その後、通信装置２０ａのアプリケーション処理部４４ａが運転免許センターで使用されている通信装置２０ｎから以下の情報を含むクレデンシャルを取得したとする。

クレデンシャルＩＤ＝ＣＩＤ＿３
スキーマＩＤ：ＳＣ＿３
Ａ４：鈴木
Ａ６：神奈川県川崎市

判定部４２ａは、ＣＩＤ＿２のクレデンシャルとＣＩＤ＿３のクレデンシャルを比較する。すると、いずれのクレデンシャルにも「鈴木」という情報と、「神奈川県川崎市」という情報がある。「鈴木」という情報は、ＣＩＤ＿２のクレデンシャルでは属性定義ＩＤ＝Ａ１に対応付けられており、ＣＩＤ＿３のクレデンシャルでは属性定義ＩＤ＝Ａ４に対応付けられている。そこで、判定部４２ａは、属性定義ＩＤ＝Ａ１と属性定義ＩＤ＝Ａ４が等しいと判定し、属性対応テーブル５１ａの更新や属性対応メッセージの送信を行う。同様に、「神奈川県川崎市」という情報は、ＣＩＤ＿２のクレデンシャルでは属性定義ＩＤ＝Ａ５に対応付けられており、ＣＩＤ＿３のクレデンシャルでは属性定義ＩＤ＝Ａ６に対応付けられている。すると、判定部４２ａは、属性定義ＩＤ＝Ａ５と属性定義ＩＤ＝Ａ６が等しいと判定し、属性対応テーブル５１ａの更新や属性対応メッセージの送信を行う。

複数のクレデンシャルを比較することによる属性対応テーブル５１の更新や属性対応メッセージの送信は、第２の実施形態のように、複数のコンソーシアム１が含まれるシステムでも行われ得る。この場合、生成部４３は、属性対応メッセージに各属性が使用されているコンソーシアム１の識別情報を含めるので、図１６に示すような属性対応メッセージを生成する。

以上で説明したテーブル、メッセージ、クレデンシャル等のフォーマットは一例にすぎず、実装に応じて変更され得る。例えば、テーブル、メッセージ、クレデンシャルは、以上に述べた情報要素以外の情報要素を含んでも良く、図示された情報要素の一部を含まなくても良い。

以上の説明では、理解しやすくするために、通信装置２０が行う処理を分けて説明したが、いずれの通信装置２０もクレデンシャルの発行、送信、検証を行い得る。さらに、第２の実施形態では、いずれの通信装置２０も、クレデンシャルの発行、送信、検証、属性対応メッセージや属性非対応メッセージの作成、属性対応テーブル５１の更新を行い得る。

さらに、以上の説明で用いたネットワークは一例であり、ネットワーク中のコンソーシアム１（クラスタ）の数は任意である。また、比較対象となっている属性定義１６の組み合わせによっては、複数のコンソーシアム１中の属性定義１６を取得可能な通信装置２０であっても、図２１で示す処理を行うことがある。例えば、通信装置２０ｘはノード１０ｘとノード１０ｙに接続し、ノード１０ｘはコンソーシアム１ｘに参加し、ノード１０ｙはコンソーシアム１ｙに参加しているとする。この場合に、コンソーシアム１ｚで使用される属性定義１６ｚ中の定義とコンソーシアム１ｘで使用される属性定義１６ｘ中の定義の組み合わせについて、属性対応メッセージが送信されたとする。すると、通信装置２０ｘは、属性定義１６ｚを共有するノード１０に接続していないので、属性定義１６ｚを取得可能な通信装置２０ではない。そこで、この属性対応メッセージの処理の際には、図２１に示す処理を行う。

１ コンソーシアム
２ 発行者
３ 保持者
４ 検証者
５ 端末
１０ ノード
１５ 分散台帳
１６ 属性定義
１７ 検証用公開鍵情報
１８ スキーマ定義
２０ 通信装置
３０ 通信部
３１ 受信部
３２ 送信部
４０ 制御部
４１ 取得部
４２ 判定部
４３ 生成部
４４ アプリケーション処理部
５０ 記憶部
５１ 属性対応テーブル
５２ 秘密鍵
１０１ プロセッサ
１０２ メモリ
１０３ 入力装置
１０４ 出力装置
１０５ バス
１０６ 記憶装置
１０７ 可搬記憶媒体駆動装置
１０８ 可搬記憶媒体
１０９ ネットワークインタフェース

Claims (8)

1. 電子証明書に含まれるユーザ情報の属性と前記属性の定義の対応関係を記録した分散台帳を共有している複数の装置のいずれかに接続する第１の装置から、第１の属性に対応付けられた情報を含む電子証明書を取得し、
   前記複数の装置のいずれかに接続する第２の装置から第２の属性に対応付けられた情報の要求を受信すると、前記第１の属性に対応付けられた第１の定義、および、前記第２の属性に対応付けられた第２の定義を、前記複数の装置のいずれかから取得し、
   前記第１の定義と前記第２の定義が一致する場合、前記第１の属性と前記第２の属性が同じ定義を有することを通知するメッセージとともに、前記第１の属性に対応付けられた情報を含む電子証明書を、前記第２の装置に送信する
   処理を通信装置に行わせることを特徴とする通信プログラム。
2. 前記通信装置に、
   前記第１の属性と前記第２の属性が対応することを対応テーブルに記録し、
   第３の属性と第４の属性が同じ定義を有することを通知する他のメッセージを受信すると、前記第３の属性に対応付けられた第３の定義と前記第４の属性に対応付けられた第４の定義を取得し、
   前記第３の定義と前記第４の定義が一致すると判定すると、前記第３の属性と第４の属性が対応することを前記対応テーブルに記録し、
   前記第４の属性の情報が要求されると、前記第３の属性の情報を含む他の電子証明書を前記第４の属性の情報の要求元に送信することを、前記対応テーブルを用いて決定する
   処理をさらに行わせることを特徴とする請求項１に記載の通信プログラム。
3. 前記通信装置が、前記複数の装置で形成される第１のクラスタに参加している第１の接続先と、他の分散台帳を共有する他の複数の装置で形成される第２のクラスタに参加している第２の接続先の両方に接続する場合、
   前記第２のクラスタ中の装置のいずれかに接続する第３の装置から第５の属性に対応付けられた情報の要求を受信すると、前記第２の接続先から前記第５の属性に対応付けられた第５の定義を取得し、
   前記第１の定義と前記第５の定義が一致する場合、前記第３の装置に、前記第１のクラスタで使用される前記第１の属性と前記第２のクラスタで使用される前記第５の属性が同じ定義を有することを通知するとともに、前記第１の属性に対応付けられた情報を含む電子証明書を送信する
   処理を前記通信装置に行わせることを特徴とする請求項１または２に記載の通信プログラム。
4. 前記分散台帳は、前記第１のクラスタ中の装置のいずれかに接続する装置の各々のアドレス情報をさらに記録し、
   前記他の分散台帳は、前記第２のクラスタ中の装置のいずれかに接続する装置の各々のアドレス情報をさらに記録し、
   前記通信装置は、前記第１の定義と前記第５の定義が一致する場合、前記第１のクラスタまたは前記第２のクラスタの装置のいずれかに接続する装置に、前記第１のクラスタで使用される前記第１の属性と前記第２のクラスタで使用される前記第５の属性が同じ定義を有することを通知する通知メッセージを送信する
   ことを特徴とする請求項３に記載の通信プログラム。
5. 前記第１のクラスタで使用される前記第１の属性と前記第２のクラスタで使用される第６の属性が同じ定義を有することを通知する他の通知メッセージを受信すると、
   前記第２の接続先から前記第６の属性に対応付けられた第６の定義を取得し、
   前記第１の定義と前記第６の定義が一致すると判定した場合、前記他の通知メッセージを、前記第１のクラスタまたは前記第２のクラスタの装置のいずれかに接続する装置に送信する
   処理を前記通信装置に行わせることを特徴とする請求項３または４に記載の通信プログラム。
6. 前記通信装置が、前記第１のクラスタ中の装置のいずれかに接続しているが、前記第２のクラスタ中の装置に接続していない場合、前記他の通知メッセージを受信した回数が閾値を超えると、前記第１のクラスタで使用される前記第１の属性と前記第２のクラスタで使用される第６の属性が同じ定義を有することを記憶する
   処理を前記通信装置に行わせることを特徴とする請求項５に記載の通信プログラム。
7. 電子証明書に含まれるユーザ情報の属性と前記属性の定義の対応関係を記録した分散台帳を共有している複数の装置のいずれかに接続する第１の装置から、第１の属性に対応付けられた情報を含む電子証明書を取得し、
   前記複数の装置のいずれかに接続する第２の装置から第２の属性に対応付けられた情報の要求を受信すると、前記第１の属性に対応付けられた第１の定義、および、前記第２の属性に対応付けられた第２の定義を、前記複数の装置のいずれかから取得し、
   前記第１の定義と前記第２の定義が一致する場合、前記第１の属性と前記第２の属性が同じ定義を有することを通知するメッセージとともに、前記第１の属性に対応付けられた情報を含む電子証明書を、前記第２の装置に送信する
   処理を通信装置が行うことを特徴とする通信方法。
8. 電子証明書に含まれるユーザ情報の属性と前記属性の定義の対応関係を記録した分散台帳を共有している複数の装置のいずれかに接続する第１の装置から、第１の属性に対応付けられた情報を含む電子証明書を取得する処理部と、
   前記複数の装置のいずれかに接続する第２の装置から第２の属性に対応付けられた情報の要求を受信する受信部と、
   前記第１の属性に対応付けられた第１の定義、および、前記第２の属性に対応付けられた第２の定義を、前記複数の装置のいずれかから取得する取得部と、
   前記第１の定義と前記第２の定義が一致する場合、前記第１の属性と前記第２の属性が同じ定義を有することを通知するメッセージとともに、前記第１の属性に対応付けられた情報を含む電子証明書を、前記第２の装置に送信する送信部
   を備えることを特徴とする通信装置。

Images