特開 2025-91746 認可システム及び認可方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025091746

(43)【公開日】2025-06-19

(54)【発明の名称】認可システム及び認可方法

(51)【国際特許分類】

   G06F 21/64 20130101AFI20250612BHJP

   H04L 9/32 20060101ALI20250612BHJP

【ＦＩ】

G06F21/64

H04L9/32 200B

H04L9/32 200F

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2023207181

(22)【出願日】2023-12-07

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】池田 麻奈美

(72)【発明者】

【氏名】安細 康介

(72)【発明者】

【氏名】若林 正樹

(72)【発明者】

【氏名】片山 堅斗

(72)【発明者】

【氏名】鈴木 茜

(72)【発明者】

【氏名】藤城 孝宏

(72)【発明者】

【氏名】西川 享宏

(72)【発明者】

【氏名】小川 政美

(72)【発明者】

【氏名】高橋 莉佳

(57)【要約】

【課題】
無効な検証可能証明書を用いたなりすましを防止すること。
【解決手段】
構造分析部は、認可依頼装置から検証可能依頼要求を受け取ると、第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する。
【選択図】 図６

【特許請求の範囲】

【請求項1】

委任者の属性情報を含む第１の検証可能証明書を発行するとともに、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する発行者装置と、
前記受任者が前記第２の検証可能証明書及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する認可依頼装置と、
前記認可依頼装置から受け取った前記検証可能依頼要求が真正なものであるか否かを認可する認可装置と、を備え、
前記認可装置は、
前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する構造分析部を有する
ことを特徴とする認可システム。

【請求項2】

前記構造分析部は、
前記不整合なく辿れない場合、それ以降検証対象から除外する
ことを特徴とする請求項１に記載の認可システム。

【請求項3】

前記認可装置は、
複数の検証可能証明書の関係性を構造化したデータである構造化データの一部の検証可能証明書が失効していると判断した場合、前記構造化データから前記一部の検証可能証明書を削除した残りの構造化データを検証の対象とする検証可能証明書検証部を備える
ことを特徴する請求項１に記載の認可システム。

【請求項4】

前記認可装置は、
複数の検証可能証明書の関係性を構造化したデータである構造化データの一部の検証可能証明書が失効していると判断した場合、前記構造化データから前記一部の検証可能証明書を削除した残りの構造化データを検証の対象とする認可ポリシ検証部を備える
ことを特徴とする請求項１に記載の認可システム。

【請求項5】

所定のサービスの提供を認可すべきか否かに関する判断基準を示す認可ポリシを格納する認可ポリシ格納部を備え、
前記認可ポリシ検証部は、
複数の検証可能証明書の関係性を構造化したデータである構造化データが前記認可ポリシに反しない場合には前記サービスの提供を認可する一方、前記構造化データが前記認可ポリシに反する場合には前記サービスの提供を認可しない
ことを特徴とする請求項４に記載の認可システム。

【請求項6】

発行者のトラスト情報と、前記認可ポリシに記載されている前記発行者のトラストに関する条件、前記発行者の前記構造化データに含まれる前記発行者の情報から、前記認可ポリシを満たしているか検証を行うトラスト検証部を備える
ことを特徴とする請求項４に記載の認可システム。

【請求項7】

電子署名の認証に用いられる公開鍵が格納される公開鍵キャッシュ部を備える
ことを特徴とする請求項１に記載の認可システム。

【請求項8】

検証対象の失効情報が格納される失効情報キャッシュ部を備える
ことを特徴とする請求項１に記載の認可システム。

【請求項9】

前記第１～第３の検証可能証明書は、Verifiable Credentialであり、前記検証可能依頼要求は、Verifiable Presentationである
ことを特徴とする請求項１に記載の認可システム。

【請求項10】

前記委任者及び前記受任者とやり取りを行うインターフェースと、
少なくとも前記構造分析部、前記検証可能依頼要求検証部、前記検証可能証明書検証部及び前記認可ポリシ検証部を有する検証可能依頼要求認可サーバと、が別体である
ことを特徴とする請求項３及び請求項４に記載の認可システム。

【請求項11】

発行者装置が、委任者の属性情報を含む第１の検証可能証明書を発行する第１の発行ステップと、
前記発行者装置が、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する第２の発行ステップと、
認可依頼装置が、前記受任者が前記第２の検証可能証明書に及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する第２の発行ステップと、
認可装置の構造分析部が、前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する検証可能依頼要求検証ステップと、
を有することを特徴とする認可方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、認可システム及び認可方法に関し、例えば、Verifiable Credentialsを活用する際におけるなりすましを防止する技術に関する認可システムに適用して好適なものである。

【背景技術】

【0002】

近年、プライバシ保護、可用性の観点から、検証可能証明書の一例としてVerifiable Credentialsを活用した認可システムが存在している。非特許文献１では、ＶＣ（Verifiable Credential）を用いた認可システムについて定義されており、当該認可システムの構成要素であるＩｓｓｕｅｒ、Ｈｏｌｄｅｒ、Ｖｅｒｉｆｉｅｒ及びＶＤＲ（Verifiable Data Registry）の基本機能が開示されている。ＶＣには、Ｖｅｒｉｆｉｅｒに対して認可を要求するＨｏｌｄｅｒの属性情報が記載されており、ＶｅｒｉｆｉｅｒがＨｏｌｄｅｒより複数ＶＣからなるＶＰ（Verifiable Presentation）を受け取ると、ＶＰに含まれる各ＶＣに記載されている属性情報を元に認可が行われる。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】https://www.w3.org/TR/ＶＣ-data-model-2.0/

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、悪意のあるＨｏｌｄｅｒが第三者に対して発行されたＶＣをＶＰに含めてＶｅｒｉｆｉｅｒに認可を要求すると、第三者に対して発行されたＶＣは検証において無効であるにも関わらず、Ｖｅｒｉｆｉｅｒは無効であるＶＣを検知することができないという問題があった。

【0005】

本発明は以上の点を考慮してなされたもので、無効な検証可能証明書を用いたなりすましを防止することができる認可システム及び認可方法を提案しようとするものである。

【課題を解決するための手段】

【0006】

かかる課題を解決するため本発明においては、委任者の属性情報を含む第１の検証可能証明書を発行するとともに、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する発行者装置と、前記受任者が前記第２の検証可能証明書及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する認可依頼装置と、前記認可依頼装置から受け取った前記検証可能依頼要求が真正なものであるか否かを認可する認可装置と、を備え、前記認可装置は、前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する構造分析部を有するようにした。

【0007】

また、本発明においては、発行者装置が、委任者の属性情報を含む第１の検証可能証明書を発行する第１の発行ステップと、前記発行者装置が、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する第２の発行ステップと、認可依頼装置が、前記受任者が前記第２の検証可能証明書に及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する第２の発行ステップと、認可装置の構造分析部が、前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する検証可能依頼要求検証ステップと、を有するようにした。

【発明の効果】

【0008】

本発明によれば、無効な検証可能証明書を用いたなりすましを防止することができる。

【図面の簡単な説明】

【0009】

【図1】第１の実施形態による認可システムの構成例を示すシステム構成図である。

【図2】図１に示すＩｓｓｕｅｒサーバのハードウェア構成の一例を示すブロック図である。

【図3】ＶＰの一例を示す図である。

【図4】図１に示すＩｓｓｕｅｒサーバのソフトウェア構成の一例を示すブロック図である。

【図5】図１に示すＨｏｌｄｅｒ端末のソフトウェア構成例を示すブロック図である。

【図6】図１に示すＶｅｒｉｆｉｅｒサーバのソフトウェア構成の一例を示すブロック図である。

【図7】発行対象者ベースＶＰ構造化データの一例を示す図である。

【図8】ＩｓｓｕｅｒベースＶＰ構造化データの具体例を示す図である。

【図9】ＶＤＲの構成例を示すブロック図である。

【図10】ＶＰ認可処理の概要を示す図である。

【図11】ＶＰ構造分析処理（初回）の手順の一例を示すフローチャートである。

【図12】ＶＰ検証処理の手順の一例を示すシーケンスチャートである。

【図13】発行対象者ベースＶＰ構造化データを用いてなりすましを検出する一例を示す図である。

【図14】なりすましを検出する具体例を示す図である。

【図15】ＶＣ検証処理の手順の一例を示すシーケンスチャートである。

【図16】ＶＣ検証処理の手順の一例を示すシーケンスチャートである。

【図17】失効によりＶＣが無効となる場合の一例を示している図である。

【図18】失効によりＶＣが無効となる場合の一例を示している図である。

【図19】ＶＰ構造分析処理（２回目以降）の手順の一例を示すフローチャートである。

【図20】認可ポリシ検証処理の手順の一例を示すシーケンスチャートである。

【図21】第２の実施形態による認可システムの構成例を示すブロック図である。

【発明を実施するための形態】

【0010】

以下、図面に基づいて、本発明の一実施形態を詳述する。
（１）第１の実施形態
図１は、第１の実施形態による認可システム１０００の構成例を示すシステム構成図である。認可システム１０００は、その構成要素として、例えばＩｓｓｕｅｒ、Ｈｏｌｄｅｒ、Ｖｅｒｉｆｉｅｒ及びＶｅｒｉｆｉｅｒサーバ３００、Ｖｅｒｉｆｉａｂｌｅ ｄａｔａ ｒｅｇｉｓｔｒｙ（以下「ＶＤＲ」と省略する）を有する。認可システム１０００は、例えばＶＣ（Verifiable Credential）を用いて認可を行う。

【0011】

本実施形態において各用語は以下のように用いられる。「Ｉｓｓｕｅｒ」は、要求元からの要求に応じてＶＣを発行する機能を有する。「Ｈｏｌｄｅｒ」は、発行されたＶＣを保有する機能を有する。「Ｖｅｒｉｆｉｅｒ」は、発行されたＶＣの検証認可を行い、その検証認可の結果に応じて、所定のサービスの提供を認可すべきか否かを決定する機能を有する。「委任者」は、受任者に対して、所定の要求を委任する機能を有する。「受任者」は、委任者から、所定の要求を受任する機能を有する。「発行対象者」は、ＶＣが発行される対象を示している。なお、本実施形態では、「Ｉｓｓｕｅｒ」、「Ｈｏｌｄｅｒ」、「Ｖｅｒｉｆｉｅｒ」、「委任者」、「受任者」及び「発行対象者」は、それぞれ、エンティティとも称し、例えば、端末、装置、システムのいずれかである。

【0012】

Ｉｓｓｕｅｒは、例えば、要求元である委任者からの要求に応じて当該委任者の属性情報を含めたＶＣを発行したり、要求元である受任者からの要求に応じて当該受任者の属性情報を含めたＶＣを発行する。Ｈｏｌｄｅｒは、発行されたＶＣを保持する。ＨｏｌｄｅｒはＶｅｆｉｆｉｅｒに検証可能依頼要求をする際、保有する複数のＶＣをＶＰ（Verifiable Presentation）としてＶｅｆｉｆｉｅｒに渡す。

【0013】

Ｖｅｆｉｆｉｅｒは、受け取ったＶＰ（Verifiable Presentation）を用いた検証可能依頼要求に応じて検証認可を行い、その検証認可結果に応じた認可を経て、所定のサービスを提供しうる。

【0014】

認可システム１０００は、例えば、Ｉｓｓｕｅｒサーバ１００、Ｈｏｌｄｅｒ端末２００、ＶＤＲ４００及びネットワーク５００を備えている。Ｉｓｓｕｅｒサーバ１００、Ｈｏｌｄｅｒ端末２００、Ｖｅｒｉｆｉｅｒサーバ３００及びＶＤＲ４００は、ネットワーク５００を経由して互いに接続されており、データ等をやり取りすることができる。

【0015】

Ｉｓｓｕｅｒサーバ１００は、Ｉｓｓｕｅｒとして機能し、要求元の属性情報を含めたＶＣ（Verifiable Credential）を作成し、Ｈｏｌｄｅｒに対して発行する少なくとも１台のコンピュータである。Ｉｓｓｕｅｒサーバ１００の詳細については後述する。

【0016】

Ｈｏｌｄｅｒ端末２００は、Ｈｏｌｄｅｒとして機能し、Ｉｓｓｕｅｒサーバ１００から受け取ったＶＣに、自らの属性情報を付加したＶＰを作成し、ＶｅｒｉｆｉｅｒとしてのＶｅｒｉｆｉｅｒサーバ３００に対して発行する端末装置である。Ｈｏｌｄｅｒ端末２００の詳細については後述する。

【0017】

Ｖｅｒｉｆｉｅｒサーバ３００は、ｖｅｒｉｆｉｅｒとして機能し、例えば、ＶＰを用いた検証可能依頼要求に応じて検証認可を行い、その検証認可結果に応じた認可を経て、所定のサービスを提供しうる少なくとも１台のコンピュータである。Ｖｅｒｉｆｉｅｒサーバ３００は、検証可能依頼要求に伴ってＨｏｌｄｅｒ端末２００から受け取ったＶＰの内容に基づいて検証認可を行い、その検証認可結果に応じて、特定のサービスの提供が認可された場合に、検証可能依頼要求の要求元に特定のサービスを提供する。Ｖｅｒｉｆｉｅｒサーバ３００の詳細については後述する。

【0018】

図２は、図１に示すＩｓｓｕｅｒサーバ１００のハードウェア構成の一例を示すブロック図である。なお、Ｈｏｌｄｅｒ端末２００、Ｖｅｒｉｆｉｅｒサーバ３００及びＶＤＲ４００は、一部の構成及び処理速度が異なる点を除き、Ｉｓｓｕｅｒサーバ１００とほぼ同様の構成であるため、説明を省略する。

【0019】

Ｉｓｓｕｅｒサーバ１００は、少なくとも１台のコンピュータであり、プロセッサ１、主記憶装置２、補助記憶装置３、入力装置４、出力装置５及び通信Ｉ／Ｆ６を備えている。プロセッサ１は、いわゆるＣＰＵ（Central Processing Unit）であり、例えばプログラムを実行する。主記憶装置２は、例えば、プロセッサ１が実行するプログラムやデータを格納可能な記憶領域を有するメモリである。補助記憶装置３は、いわゆるキャッシュであり、主記憶装置２に格納されるプログラムやデータが一時的に格納される記憶領域を有する。入力装置４は、外部から操作を受け付けるマウスやキーボードである。出力装置５は、いわゆるディスプレイである。通信Ｉ／Ｆ６は、ネットワーク５００を経由して、外部との間でデータ等の受け渡しを行う。

【0020】

図３は、ＶＰの一例を示す図である。本実施形態においてＶＰは、例えばｎ個のＶＣ（ＶＣ_１～ＶＣ_ｎ）、ＩＤ_{Ｈｏｌｄｅｒ}、電子署名_{Ｈｏｌｄｅｒ}を含んでいる。ＩＤ_{Ｈｏｌｄｅｒ}は、当該ＶＰを作成、保有する所有者（Ｈｏｌｄｅｒ）のＩＤ（IDentifier）を示している。電子署名_{Ｈｏｌｄｅｒ}は、当該ＶＰのＨｏｌｄｅｒの電子署名を示している。当該電子署名は、例えば公開鍵を用いた電子署名であり、この電子署名によりＶＰの改ざんを防止する。

【0021】

ＶＣ_１～ＶＣ_ｎは、それぞれ、ＩＤ_{発行対象者}、ＩＤ_{Ｉｓｓｕｅｒ}、２つの属性情報、有効期間、ＩＤ及び電子署名を有する。ＶＣに含まれる属性の数は２つに限定したものではなく、いくつ含まれていてもよい。

【0022】

ＩＤ_{発行対象者}は、当該ＶＣを発行した発行対象者を示しており、例えばＩＤ_{発行対象者ａ}は発行対象者が「発行対象者ａ」であることを示している。

【0023】

ＩＤ_{Ｉｓｓｕｅｒ}は、ＩｓｓｕｅｒのＩＤを示しており、例えばＩＤ_{ＩｓｓｕｅｒＡ}は、Ｉｓｓｕｅｒが「ＩｓｓｕｅｒＡ」であることを示している。

【0024】

２つの属性情報は、それぞれ、ＶＣの発行対象者であるエンティティの属性情報を示している。有効期間は、当該ＶＣの有効期間を示している。本実施形態において有効期間を経過したＶＣは、例えば無効なものとして取り扱われる。ＩＤは、当該ＶＣの識別子を示しており、例えばＩＤ_ＶＣ１は、当該ＶＣ_１の識別子を示している。電子署名は、当該ＶＣに付される電子署名を示しており、例えば電子署名_{ＩｓｓｕｅｒＡ}は、ＩｓｓｕｅｒＡの電子署名であることを示している。当該電子署名は、例えば公開鍵暗号方式を用いた電子署名であり、この電子署名によりＶＣの改ざんの有無を判断することができる。

【0025】

図４は、図１に示すＩｓｓｕｅｒサーバ３００のソフトウェア構成の一例を示すブロック図である。Ｉｓｓｕｅｒサーバ３００は、ＶＣ発行受付部１０１、ＶＣ発行部１０２、ＶＣ失効情報登録部１０３及び公開鍵登録部１０４を備える。

【0026】

ＶＣ発行受付部１０１は、要求元からの要求に応じてＶＣの発行を受け付ける。ここでいう、要求元は、委任者及び受任者の少なくとも一方である。当該要求には、要求元の属性情報が含まれている場合もあれば含まれていない場合もある。

【0027】

ＶＣ発行部１０２は、要求元の属性情報を含むＶＣを発行する。このとき、ＶＣ発行の要求の際に含まれている属性情報をＶＣに含めてもよいし、Ｉｓｓｕｅｒが管理している依頼元の属性情報をＶＣに含めてもよい。ＶＣ失効情報登録部１０３は、無効なＶＣについて失効情報をＶＤＲ４００に登録する。公開鍵登録部１０４は、電子署名を作成する際に用いる秘密鍵に対応する公開鍵をＶＤＲ４００に登録する。

【0028】

図５は、図１に示すＨｏｌｄｅｒ端末２００のソフトウェア構成例を示すブロック図である。Ｈｏｌｄｅｒ端末２００は、ＶＣ発行依頼部２０１、ＶＣ管理部２０２、ＶＰ作成部２０３、ＶＰ提示部２０４、ＶＣ管理ストア２０５及び、公開鍵に関する情報を登録可能な公開鍵情報登録部２０６を備えている。

【0029】

ＶＣ発行依頼部２０１は、要求元としてＶＣの発行依頼の要求をＩｓｓｕｅｒサーバ１００に対して発行する。ここでいう要求元とは、委任者及び受任者の少なくとも一方である。当該要求には、要求元の属性情報を含む場合もあれば含まれていない場合もある。

【0030】

ＶＣ管理部２０２は、Ｉｓｓｕｅｒサーバ１００によって発行されたＶＣを図示しない記憶領域に格納して管理する。

【0031】

ＶＰ作成部２０３は、少なくとも１つのＶＣを含めたＶＰを作成し、Ｖｅｒｉｆｉｅｒサーバ３００に対して発行する。ＶＰ提示部２０４は、作成したＶＰをＶｅｒｉｆｉｅｒサーバ３００に提示する。ＶＣ管理ストア２０５は、ＶＣを格納して管理する。公開鍵情報登録部２０６は電子署名を作成する際の秘密鍵に対応する公開鍵をＶＤＲ４００に登録する。

【0032】

図６は、図１に示すＶｅｒｉｆｉｅｒサーバ３００のソフトウェア構成の一例を示すブロック図である。Ｖｅｒｉｆｉｅｒサーバ３００は、インターフェース３１０、ＶＰ構造分析部３２０、ＶＰ検証部３３０、ＶＣ検証部３４０、認可ポリシ検証部３５０、ＶＰ構造データ格納部３６０、失効情報キャッシュ部３７０、公開鍵キャッシュ部３８０及び認可ポリシ格納部３９０を備えている。認可ポリシ格納部３９０には、所定のサービスの提供を認可すべきか否かに関する判断基準を示す認可ポリシを格納しており、例えば、Ｉｓｓｕｅｒのトラストに関する条件、及び、属性情報（例えば条件含む）に関する条件が記載された認可ポリシを格納している。

【0033】

インターフェース３１０は、ＶＰ受付部３１１及び認可判断結果返却部３１２を有する。ＶＰ受付部３１１は、ＶＰを受け付ける。認可判断結果返却部３１２は、Ｖｅｒｉｆｉｅｒサーバ３００による認可検証結果に基づく認可判断結果を要求元に返却する。

【0034】

ＶＰ構造分析部３２０は、Ｉｓｓｕｅｒベース構造分析部３２１、発行対象者ベース構造分析部３２２及び失効ＶＣ分析部３２３を備えている。

【0035】

Ｉｓｓｕｅｒベース構造分析部３２１は、ＶＰに対して、Ｉｓｓｕｅｒベースでの構造分析を行い、ＩｓｓｕｅｒベースＶＰ構造化データを生成する。発行対象者ベース構造分析部３２２は、ＶＰに対して、発行対象者ベースでの構造分析を行い、発行対象者ベースＶＰ構造化データを生成する。本実施形態において構造化データとは、Ｉｓｓｕｅｒ、Ｈｏｌｄｅｒ、委任者、受任者等の複数のＶＣの関係性を構造化したデータである。

【0036】

失効ＶＣ分析部３２３は、ＩｓｓｕｅｒベースＶＰ構造化データ、発行対象者ベースＶＰ構造化データ、失効情報キャッシュ部３７０の無効なＶＣに関する情報から有効なＶＣを判別し、Ｉｓｓｕｅｒベース有効ＶＰ構造化データ及び発行対象者ベース有効ＶＰ構造化データを作成する。このとき、失効ＶＣ分析部３２３は、なりすましの検出も行い、なりすましを検出した場合は、無効となるＶＣを各有効ＶＰ構造化データから削除する。各有効ＶＰ構造化データは、ＶＰ構造データ格納部３６０に格納される。

【0037】

ＶＰ検証部３３０は、検証可能依頼要求検証部の一例であり、Ｈｏｌｄｅｒ失効情報取得部３３１、Ｈｏｌｄｅｒ有効性検証部３３２、Ｈｏｌｄｅｒ公開鍵取得部３３３及びＨｏｌｄｅｒ署名検証部３３４を備えている。

【0038】

Ｈｏｌｄｅｒ失効情報取得部３３１は、ＶＰに記載されているＩＤ_{Ｈｏｌｄｅｒ}を用いて失効情報キャッシュ部３７０にＨｏｌｄｅｒの失効情報が格納されているか検索する。ここで、失効情報キャッシュ部３７０には、Ｈｏｌｄｅｒが失効している場合、Ｈｏｌｄｅｒの失効情報が格納されている場合がある。Ｈｏｌｄｅｒ失効情報取得部３３１は、失効情報キャッシュ部３７０にＨｏｌｄｅｒの失効情報が格納されている場合、当該Ｈｏｌｄｅｒの失効情報を取得する。一方、Ｈｏｌｄｅｒ失効情報取得部３３１は、Ｈｏｌｄｅｒの失効情報が格納されていない場合、ＩＤ_{Ｈｏｌｄｅｒ}を用いてＶＤＲ４００にＨｏｌｄｅｒの失効情報を要求し、ＶＤＲ４００に、該当する失効情報が格納されているときには、ＶＤＲ４００から当該Ｈｏｌｄｅｒの失効情報を取得する。Ｈｏｌｄｅｒ失効情報取得部３３１は、この失効情報を失効情報キャッシュ部３７０に格納する。

【0039】

Ｈｏｌｄｅｒ有効性検証部３３２は、Ｈｏｌｄｅｒの失効情報から当該Ｈｏｌｄｅｒの失効の有無を判断する。

【0040】

Ｈｏｌｄｅｒ公開鍵取得部３３３は、ＶＣに記載されているＩＤ_{Ｈｏｌｄｅｒ}を用いて公開鍵キャッシュ部３８０にＨｏｌｄｅｒの公開鍵が格納されているか検索する。ここで、公開鍵キャッシュ部３８０には、Ｈｏｌｄｅｒの公開鍵が格納されている場合がある。Ｈｏｌｄｅｒ有効性検証部３３２は、公開鍵キャッシュ部３８０にＨｏｌｄｅｒの公開鍵が格納されている場合には当該公開鍵を取得する。一方、Ｈｏｌｄｅｒ有効性検証部３３２は、Ｈｏｌｄｅｒの公開鍵が格納されていない場合にはＩＤ_{Ｈｏｌｄｅｒ}を用いてＶＤＲ４００にＨｏｌｄｅｒの公開鍵を要求し、ＶＤＲ４００に該当する公開鍵が格納されている場合にはＶＤＲ４００からＨｏｌｄｅｒの公開鍵を取得する。また、Ｈｏｌｄｅｒ有効性検証部３３２は、この公開鍵を公開鍵キャッシュ部３８０に格納する。

【0041】

Ｈｏｌｄｅｒ署名検証部３３４は、ＶＰのハッシュ値、Ｈｏｌｄｅｒによる電子署名及びＨｏｌｄｅｒの公開鍵を用いて、Ｈｏｌｄｅｒの電子署名について検証を行う。これにより、ＶＰの改ざんの有無を判断することができる。

【0042】

ＶＣ検証部３４０は、発行対象者失効情報取得部３４１、発行対象者有効性検証部３４２、Ｉｓｓｕｅｒ失効情報取得部３４３、Ｉｓｓｕｅｒ有効性検証部３４４、ＶＣ失効情報取得部３４５、ＶＣ有効性検証部３４６、Ｉｓｓｕｅｒ公開鍵取得部３４７及びＩｓｓｕｅｒ署名検証部３４８を備えている。

【0043】

発行対象者失効情報取得部３４１は、Ｉｓｓｕｅｒベース有効ＶＰ構造化データに含まれる各ＶＣに記載されているＩＤ_{発行対象者}を用いて失効情報キャッシュ部３７０に各発行対象者の失効情報が格納されているか検索する。このとき、発行対象者ベース有効ＶＰ構造化データに含まれる各ＶＣでもよい。発行対象者失効情報取得部３４１は、各発行対象者の失効情報が格納されている場合には失効情報を取得する。一方、発行対象者失効情報取得部３４１は、格納されていない場合にはＩＤ_{発行対象者}を用いてＶＤＲ４００に発行対象者の失効情報を要求し、ＶＤＲ４００に、該当する失効情報が格納されているときにはＶＤＲ４００から発行対象者の失効情報を取得する。また、発行対象者失効情報取得部３４１は、この失効情報を失効情報キャッシュ部３７０に格納する。また、この失効情報を失効ＶＣ分析部３２３に渡し、失効ＶＣ分析を行う。

【0044】

発行対象者有効性検証部３４２は、各Ｉｓｓｕｅｒの失効情報から各Ｉｓｓｕｅｒの失効有無を判断する。

【0045】

Ｉｓｓｕｅｒ失効情報取得部３４３は、Ｉｓｓｕｅｒベース有効ＶＰ構造化データに含まれる各ＶＣのＩｓｓｕｅｒに対し、ＩＤ_{Ｉｓｓｕｅｒ}を用いて失効情報キャッシュ部３７０に各Ｉｓｓｕｅｒの失効情報が格納されているか検索する。Ｉｓｓｕｅｒ失効情報取得部３４３は、格納されている場合には失効情報を取得する。一方、Ｉｓｓｕｅｒ失効情報取得部３４３は、格納されていない場合にはＩＤ_{Ｉｓｓｕｅｒ}を用いてＶＤＲ４００にＩｓｓｕｅｒの失効情報を要求し、ＶＤＲ４００に、該当する失効情報が格納されているときにはＶＤＲ４００からＩｓｓｕｅｒの失効情報を取得する。また、Ｉｓｓｕｅｒ失効情報取得部３４３は、この失効情報を失効情報キャッシュ部３７０に格納する。

【0046】

Ｉｓｓｕｅｒ有効性検証部３４４は、各Ｉｓｓｕｅｒの失効情報から各Ｉｓｓｕｅｒの失効有無を判断する。ＶＣ失効情報取得部３４５は、発行対象者ベース有効ＶＰ構造化データ（Ｉｓｓｕｅｒベース有効ＶＰ構造化データでもよい）に含まれるＶＣに対し、各ＶＣから、ＶＤＲ４００に各ＶＣの失効情報を要求し、ＶＤＲ４００から各ＶＣの失効情報を取得する。

【0047】

ＶＣ有効性検証部３４６は、発行対象者ベース有効ＶＰ構造化データ（Ｉｓｓｕｅｒベース有効ＶＰ構造化データでもよい）に含まれるＶＣに対し、各ＶＣの失効情報から失効有無を判断する。Ｉｓｓｕｅｒ公開鍵取得部３４７は、Ｉｓｓｕｅｒベース有効ＶＰ構造化データに含まれる各Ｉｓｓｕｅｒに対し、ＩＤ_{Ｉｓｓｕｅｒ}を用いて公開鍵キャッシュ部３８０にＩｓｓｕｅｒの公開鍵が格納されているか検索する。Ｉｓｓｕｅｒ公開鍵取得部３４７は、格納されている場合には公開鍵を取得する。一方、Ｉｓｓｕｅｒ公開鍵取得部３４７は、格納されていない場合にはＩＤ_{Ｉｓｓｕｅｒ}を用いてＶＤＲ４００にＩｓｓｕｅｒの公開鍵を要求し、ＶＤＲ４００に、該当する公開鍵が格納されているときには、ＶＤＲ４００からＩｓｓｕｅｒの公開鍵を取得する。また、Ｉｓｓｕｅｒ公開鍵取得部３４７は、この公開鍵を公開鍵キャッシュ部３８０に格納する。また、この失効情報を失効ＶＣ分析部３２３に渡し、失効ＶＣ分析を行う。

【0048】

Ｉｓｓｕｅｒ署名検証部３４８は、発行対象者ベース有効ＶＰ構造化データ（Ｉｓｓｕｅｒベースでもよい）に含まれる各ＶＣに対し、ＶＣのハッシュ値、Ｉｓｓｕｅｒによる電子署名、Ｉｓｓｕｅｒの公開鍵を用いてＩｓｓｕｅｒの電子署名の検証を行う。検証に失敗したＶＣがある際には該当ＶＣは失効しているとし、この失効情報を失効ＶＣ分析部３２３に渡し、失効ＶＣ分析を行う。

【0049】

認可ポリシ検証部３５０は、認可ポリシ取得部３５１、属性情報検証部３５２及びＩｓｓｕｅｒトラスト検証部３５３を備えている。

【0050】

認可ポリシ取得部３５１は、認可ポリシ格納部３９０から認可ポリシを取得する。属性情報検証部３５２は、認可ポリシに記載の属性情報の条件及び発行対象者ベース有効ＶＰ構造化データ（Ｉｓｓｕｅｒベース有効ＶＰ構造化データでもよい）に含まれるＶＣに対し、各ＶＣの属性情報から認可ポリシを満たしているか検証を行う。

【0051】

Ｉｓｓｕｅｒトラスト検証部３５３は、トラスト検証部の一例であり、ＶＤＲ４００から、後述するＩｓｓｕｅｒトラスト情報（発行者のトラスト情報）を取得し、このＩｓｓｕｅｒトラスト情報（発行者のトラスト情報）と、認可ポリシに記載されているＩｓｓｕｅｒ（発行者）のトラストに関する条件、Ｉｓｓｕｅｒベース有効ＶＰ構造化データに含まれるＩｓｓｕｅｒの情報から、認可ポリシを満たしているか検証を行う。属性情報検証部３５２およびＩｓｓｕｅｒトラスト検証部３５３は、認可ポリシを満たしている場合には、所定のサービスを提供することを認可する一方、認可ポリシを満たしていない場合には、所定のサービスを提供することを認可しない。

【0052】

図７は、発行対象者ベースＶＰ構造化データの一例を示す図である。図示の例では、発行対象者と関連するＶＣを構造化し、例えば木構造としている。
発行対象者ベースＶＰ構造化データは、例えば、発行対象者ａが、Ｈｏｌｄｅｒである発行対象者ｂに対してＩｓｓｕｅｒとしてふるまい、検証可能証明書の一例としてのＶＣ_３を発行している。発行対象者ａは、例えばＶＣ_１及びＶＣ_２を有し、発行対象者ｂは、例えば、検証可能証明書の一例としてのＶＣ_３、ＶＣ_４、ＶＣ_５を有する。

【0053】

本実施形態では、ＶＰ、ＶＣの特徴を生かし、以下の処理を行うことにより発行対象者間の関係を抽出する。関係の抽出には、例えば各ＶＣに含まれる各ＩＤを用いる。
手順１． 各ＶＣの情報からＩｓｓｕｅｒかつ発行対象者になっているエンティティ（図内の発行対象者ａ）を特定する。例として、ＶＣ_３は発行対象者ａが発行したものである場合について説明する。
手順２． 手順１で特定したエンティティがＩｓｓｕｅｒとなっているＶＣ（ＶＣ_３）に対して、発行対象者（発行対象者ｂ）を特定する。
手順３．手順１，２より発行対象者間の関係性について、手順１，２で特定したエンティティ間で関係があるとする。また、委任者の方が受任者よりも上位の関係があるとする。この例においては、発行対象者ａの方が発行対象者ｂよりも上位の関係にあると判断する。
手順４．Ｈｏｌｄｅｒと同一の発行対象者を特定する。

【0054】

図８は、ＩｓｓｕｅｒベースＶＰ構造化データの具体例を示す図である。図示の例では、Ｉｓｓｕｅｒと関連するＶＣを構造化し、例えば木構造としている。
ＩｓｓｕｅｒベースＶＰ構造化データは、ＩｓｓｕｅｒＡが、例えばＶＣ_１及びＶＣ_４を有し、ＩｓｓｕｅｒＢが、例えばＶＣ_２及びＶＣ_５を有し、ＩｓｓｕｅｒＣが、例えばＶＣ_３を有する。なお、図示の例の前提として、ＶＣ_３についてＩｓｓｕｅｒＣ＝発行対象者ａであるものとする。例えば、委任者は発行対象者ａであり、受任者は発行対象者ｂである。

【0055】

図９は、ＶＤＲ４００の構成例を示すブロック図である。ＶＤＲ４００は、ＩＤ失効情報４０１、ＶＣ失効情報４０２、公開鍵４０３及びＩｓｓｕｅｒトラスト情報４０４を備えている。

【0056】

ＩＤ失効情報４０１は、例えばＩｓｓｕｅｒがＩｓｓｕｅｒ１であれば（ＩＤ_{Ｉｓｓｕｅｒ１}，失効情報_{Ｉｓｓｕｅｒ１}）という形態で管理される。ＶＣ失効情報４０２は、例えばＶＣがＶＣ１であれば（ＩＤ_ＶＣ１，失効情報_ＶＣ１）という形態で管理される。公開鍵４０３は、例えばＩｓｓｕｅｒがＩｓｓｕｅｒ１であれば（ＩＤ_{Ｉｓｓｕｅｒ１}，ｐｋ_{Ｉｓｓｕｅｒ１}）という形態で管理される。なお、ｐｋは公開鍵を示している。Ｉｓｓｕｅｒトラスト情報４０４は、Ｉｓｓｕｅｒに関する信頼性の程度を示す情報である。

【0057】

図１０は、ＶＰ認可処理の概要を示す図である。ＶＰ検証部３３０は、ＶＰを受け取ると、当該ＶＰをＶＰ構造分析部３２０に引き渡す。ＶＰ構造分析部３２０は、当該ＶＰについて所定の構造分析を行って構造化データを作成する。ここでいう構造化データは、例えば、上述した発行対象者ベース有効ＶＰ構造化データ及びＩｓｓｕｅｒベース有効ＶＣ構造化データの少なくとも一方であり、本実施形態において両者を特段区別する必要がない場合、単に「構造化データ」と総称している。

【0058】

ＶＣ検証部３４０は、検証可能証明書検証部の一例であり、ＶＰ構造分析部３２０から受け取った構造化データの一部のＶＣが失効していると判断した場合、当該構造化データについての失効情報をＶＰ構造分析部３２０に引き渡す。ＶＰ構造分析部３２０は、これに応じて、当該構造化データについて失効を登録し、当該構造化データから当該一部のＶＣを削除する。これにより、その後、ＶＣ検証部３４０は、当該構造化データから当該一部のＶＣを削除した残りの構造化データを検証の対象とする。このように失効した構造化データを削除することにより、その後当該一部のＶＣを参照する必要がなくなるため、処理コストを削減することができる。

【0059】

認可ポリシ検証部３５０は、ＶＰ構造分析部３２０から受け取った構造化データの一部のＶＣが失効していると判断した場合、当該構造化データについての失効情報をＶＰ構造分析部３２０に引き渡す。ＶＰ構造分析部３２０は、これに応じて、当該構造化データについて当該一部のＶＣの失効を登録し、当該一部のＶＣを当該構造化データから削除する。これにより、その後、認可ポリシ検証部３５０は、当該一部のＶＣを検証する必要がなくなり、構造化データから当該一部の検証可能証明書を削除した残りの構造化データを検証の対象とすればよくなるため、処理コストを削減することができる。

【0060】

認可ポリシ検証部３５０は、ＶＰ構造分析部３２０から受け取った構造化データが失効していないと判断した場合、当該構造化データが認可ポリシに反するか否かを判断し、認可して良いかどうかに関する認可判断結果を出力する。認可ポリシ検証部３５０は、当該構造化データが認可ポリシに反しない場合には認可する一方、当該構造化データが認可ポリシに反する場合には認可しない。

【0061】

（ＶＰ構造分析処理（初回））
図１１は、ＶＰ構造分析処理（初回）の手順の一例を示すフローチャートである。図１１に示すＶＰ構造分析処理は、ＶＰ構造分析部３２０によって初回に実行されるＶＰ構造分析処理である。

【0062】

ステップＳ１０１では、発行対象者ベース構造分析部３２２が、ＶＰ受付部３１１からＶＰを取得し、発行対象者ベースＶＰ構造化データを作成する。

【0063】

ステップＳ１０２では、発行対象者ベース構造分析部３２２が、ＶＰ受付部３１１からＶＰを取得し、ＩｓｓｕｅｒベースＶＰ構造化データを作成する。

【0064】

ステップＳ１０３では、失効ＶＣ分析部３２３が、発行対象者ベースＶＰ構造化データの内、Ｈｏｌｄｅｒから辿れない少なくとも１つの構造化データ（以下「構造化データ群」とも称する）の検出を行う。本実施形態において、「辿れる」とは、ＶＣやＶＰに含まれる属性情報において、例えば委任者と受任者との関係性において不整合がなく、なりすましであるとは認められないことを意味している。

【0065】

ステップＳ１０４では、失効ＶＣ分析部３２３が、Ｈｏｌｄｅｒから辿れない構造化データ群があるか否かを判断する。

【0066】

失効ＶＣ分析部３２３は、Ｈｏｌｄｅｒから辿れない構造化データ群がない場合、ステップＳ１０５を実行する。ステップＳ１０５では、失効ＶＣ分析部３２３は、発行対象者ベースＶＰ構造化データを発行対象者ベース有効ＶＰ構造化データとする。ステップＳ１０６では、失効ＶＣ分析部３２３が、ＩｓｓｕｅｒベースＶＰ構造化データをＩｓｓｕｅｒベース有効ＶＰ構造化データとする。

【0067】

一方、失効ＶＣ分析部３２３は、Ｈｏｌｄｅｒから辿れない構造化データ群がある場合、ステップＳ１０７を実行する。ステップＳ１０７では、失効ＶＣ分析部３２３が、Ｈｏｌｄｅｒから辿れない構造化データ群に含まれる発行対象者及びその発行対象者にぶら下がるＶＣを全て削除としたものを発行対象者ベース有効ＶＰ構造化データとする。このように、Ｈｏｌｄｅｒから辿れないＶＣについてはなりすましによるＶＣであると検知することができる。なりすましに用いられているＶＣを検出して削除することにより、なりすましではない有効なＶＣのみ以降の検証に用いることができる。また、以降の検証において当該なりすましによる無効なＶＣを用いないようにすることで処理コストを低減することができる。

【0068】

次にステップＳ１０８では、失効ＶＣ分析部３２３が、当該削除されたＶＣを、ＩｓｓｕｅｒベースＶＰ構造化データから削除し、Ｉｓｓｕｅｒベース有効ＶＰ構造化データとする。

【0069】

さらにステップＳ１０９では、失効ＶＣ分析部３２３が、発行対象者ベース有効ＶＰ構造化データ、Ｉｓｓｕｅｒベース有効ＶＰ構造化データをＶＣ検証部３４０に渡す。

【0070】

図１２は、ＶＰ検証処理の手順の一例を示すシーケンスチャートである。当該ＶＰ検証処理は、ＶＰ検証部３３０によって実行される。ステップＳ２０１では、Ｈｏｌｄｅｒ失効情報取得部３３１が、ＩＤ_{Ｈｏｌｄｅｒ}に基づいて失効情報キャッシュ部３７０を検索する。ステップＳ２０２では、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する失効情報_{Ｈｏｌｄｅｒ}がある場合、Ｈｏｌｄｅｒ失効情報取得部３３１が、失効情報キャッシュ部３７０から失効情報_{Ｈｏｌｄｅｒ}を取得する。一方、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する失効情報_{Ｈｏｌｄｅｒ}がない場合、Ｈｏｌｄｅｒ失効情報取得部３３１は、ステップＳ２０３を実行する。

【0071】

ステップＳ２０３では、Ｈｏｌｄｅｒ失効情報取得部３３１が、ＩＤ_{Ｈｏｌｄｅｒ}に基づいてＶＤＲ４００を検索する。ステップＳ２０４では、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する失効情報_{Ｈｏｌｄｅｒ}がある場合、Ｈｏｌｄｅｒ失効情報取得部３３１が、ＶＤＲ４００から失効情報_{Ｈｏｌｄｅｒ}を取得する。

【0072】

当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する失効情報_{Ｈｏｌｄｅｒ}があった場合、ステップＳ２０５では、Ｈｏｌｄｅｒ失効情報取得部３３１が、失効情報_{Ｈｏｌｄｅｒ}を失効情報キャッシュ部３７０に格納する。一方、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する失効情報_{Ｈｏｌｄｅｒ}を取得できなかった場合、Ｈｏｌｄｅｒ失効情報取得部３３１は、失効情報キャッシュ部３７０にアクセスしない。

【0073】

次に、ステップＳ２０６では、Ｈｏｌｄｅｒ有効性検証部３３２が、Ｈｏｌｄｅｒの有効性を検証する。

【0074】

ステップＳ２０７では、Ｈｏｌｄｅｒ公開鍵取得部３３３が、ＩＤ_{Ｈｏｌｄｅｒ}に基づいて公開鍵キャッシュ部３８０を検索する。ステップＳ２０２では、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する公開鍵_{Ｈｏｌｄｅｒ}がある場合、Ｈｏｌｄｅｒ公開鍵取得部３３３が、公開鍵キャッシュ部３８０から公開鍵_{Ｈｏｌｄｅｒ}を取得する。

【0075】

一方、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する公開鍵_{Ｈｏｌｄｅｒ}がない場合、ステップＳ２０９では、Ｈｏｌｄｅｒ公開鍵取得部３３３が、ＩＤ_{Ｈｏｌｄｅｒ}に基づいてＶＤＲ４００を検索する。ステップＳ２１０では、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する公開鍵_{Ｈｏｌｄｅｒ}がある場合、Ｈｏｌｄｅｒ公開鍵取得部３３３が、ＶＤＲ４００から公開鍵_{Ｈｏｌｄｅｒ}を取得する。ステップＳ２１０では、Ｈｏｌｄｅｒ公開鍵取得部３３３が、公開鍵_{Ｈｏｌｄｅｒ}を公開鍵キャッシュ部３８０に格納する。

【0076】

次に、ステップＳ２１２では、Ｈｏｌｄｅｒ署名検証部３３４が、ＶＰに付与された署名を検証する。

【0077】

図１３は、発行対象者ベースＶＰ構造化データを用いてなりすましを検出する一例を示す図である。このなりすましの検出は、ＶＰ構造分析部３２０によって実行される。あるＶＰに関する図示の発行対象者ベースＶＰ構造化データにおいて、左側の部分は、上述した図７に示す発行対象者ベースＶＰ構造化データと同一であり、なりすましがないものと判断される。しかしながら、右側の部分は、発行対象者ｄにはＶＣ_６及びＶＣ_７がぶらさがっており、これらＶＣ_６及びＶＣ_７は、右側の発行対象者ベースＶＰ構造化データのＶＣに含まれていないため、辿ることができないと判断され、なりすましがあるものと検出される。

【0078】

図１４は、なりすましを検出する具体例を示す図である。まず、本実施形態による認可システム１０００について説明する。

【0079】

委任者は、Ｉｓｓｕｅｒサーバ１００に対して要求を発行してＩｓｓｕｅｒサーバ１００から、委任者として自らの属性情報を含めたＶＣ（以下「ＶＣ_１」とも称する）の発行を受け、当該ＶＣ_１のＨｏｌｄｅｒになる。当該ＶＣ_１の発行を受けた委任者は、このようにＶＣ_１のＨｏｌｄｅｒ（以下「Ｈｏｌｄｅｒ１」とも称する）に相当するとともに、Ｈｏｌｄｅｒ端末２００に対応している。当該委任者は、例えば、所定のサービスの提供の要求（サービス提供要求）をＶｅｒｉｆｉｅｒサーバ３００に対して行うことについて自らを委任者として受任者に対して委任する場合、次のように２種類のＶＣを委任者から受任者に渡す。

【0080】

すなわち、まず第１に、この委任者は、当該要求の委任者として自ら（委任者）の属性情報を含めたＶＣ（以下「ＶＣ_１」とも称する）を受任者に対して渡す。第２に、この委任者は、上述したようにＨｏｌｄｅｒであるが、当該受任者に対するＩｓｓｕｅｒとして、受任者に対して委任するために、委任者（Ｈｏｌｄｅｒ１）から受任者に対する委任情報として、当該委任者（Ｈｏｌｄｅｒ１）の属性情報を含めたＶＣ（以下「ＶＣ_２」とも称する）を発行する。このとき、ＶＣ_１とＶＣ_２をＶＰとしてまとめて渡してもよいし、それぞれ別々に渡してもよい。受任者は、発行されたＶＣ_２を受け取ったことにより、当該ＶＣ_２のＨｏｌｄｅｒ（以下「Ｈｏｌｄｅｒ２」とも称する）となり、Ｈｏｌｄｅｒ端末２００に対応している。すなわち、委任者は、当該ＶＣ_２のＨｏｌｄｅｒである一方、受任者に対する当該ＶＣ_２のＩｓｓｕｅｒにもなりうる場合がある。

【0081】

さらに、当該受任者（Ｈｏｌｄｅｒ２）は、Ｉｓｓｕｅｒサーバ１００に対して要求を発行してＩｓｓｕｅｒサーバ１００から、受任者として自らの属性情報を含めたＶＣ（以下「ＶＣ_３」とも称する）の発行を受け、当該ＶＣ_３のＨｏｌｄｅｒともなる。この受任者は、受け取り済みのＶＣ_１及びＶＣ_２にＶＣ_３を付加したＶＰ（所定のサービスの提供を受けることを希望する検証可能依頼要求）を作成し、Ｖｅｒｉｆｉｅｒに対して発行する。

【0082】

Ｖｅｆｉｆｉｅｒサーバ３００は、受け取ったＶＰを用いた検証可能依頼要求に応じて検証認可を行い、その検証認可結果に応じた認可を経て、所定のサービスを提供しうる。Ｖｅｆｉｆｉｅｒサーバ３００は、当該ＶＰの内容に基づいて、例えば、ＶＣ_２における委任者の属性情報からＨｏｌｄｅｒ１がＨｏｌｄｅｒ２との関係で委任者であり、かつ、ＶＣ_１における属性情報からＨｏｌｄｅｒ２がＨｏｌｄｅｒ１との関係で受任者であるか（「認可条件」とも称する）を判断し、当該認可条件を満たす場合には当該ＶＰが真正なものであると判断する一方、当該認可条件を満たない場合には当該ＶＰが真正なものでないと判断する。

【0083】

本実施形態による認可システム１０００は、委任者の属性情報を含むＶＣ_１を発行するとともに、委任者として受任者に対する委任情報として当該委任者の属性情報を含むＶＣ_２を発行する発行者装置の一例としてのＩｓｓｕｅｒサーバ１００と、受任者が上記ＶＣ_２及びＶＣ_１を受け取ると、受任者の属性情報を含むＶＣ_３をＶＣ_１及びＶＣ_２に付加して構成したＶＰを発行する認可依頼装置の一例としてのＨｏｌｄｅｒ端末２００と、Ｈｏｌｄｅｒ端末２００から受け取ったＶＰが真正なものであるか否かを認可する認可装置の一例としてのＶｅｒｉｆｉｅｒサーバ３００と、を備える。このＶｅｒｉｆｉｅｒサーバ３００は、以下のようなＶＰ構造分析部３２０を備えている。すなわち、このＶＰ構造分析部３２０は、Ｈｏｌｄｅｒ端末２００からＶＰを受け取ると、ＶＣ_２に含まれる委任者の属性情報が、ＶＣ_１に含まれる委任者の属性情報と不整合がなく辿れ、かつ、ＶＣ_３における受任者の属性情報が、ＶＣ_１における委任者、並びに、ＶＣ_２における委任者及び受任者の属性情報と不整合なく辿れる場合、ＶＣ_３を含むＶＰが真正なものと判断する。

【0084】

本実施形態による認可方法は、Ｉｓｓｕｅｒサーバ１００が、委任者の属性情報を含むＶＣ_１を発行する第１の発行ステップと、Ｉｓｓｕｅｒサーバ１００が、委任者として受任者に対する委任情報として委任者の属性情報を含むＶＣ_２を発行する第２の発行ステップと、Ｈｏｌｄｅｒ端末２００が、受任者がＶＣ_２及びＶＣ_１を受け取ると、受任者の属性情報を含むＶＣ_３をＶＣ_１及びＶＣ_２に付加して構成したＶＰを発行する第２の発行ステップと、Ｖｅｒｉｆｉｅｒサーバ３００のＶＰ構造分析部３２０が、Ｈｏｌｄｅｒ端末２００からＶＰを受け取ると、ＶＣ_２に含まれる委任者の属性情報が、ＶＣ_１に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、ＶＣ_３における受任者の属性情報が、ＶＣ_１における委任者、並びに、ＶＣ_２における委任者及び受任者の属性情報と不整合なく辿れる場合、ＶＣ_３を含むＶＰが真正なものと判断する検証可能依頼要求検証ステップと、を有する。

【0085】

本実施形態において、ＶＰ構造分析部３２０は、上述したように不整合なく辿れない場合、それ以降検証対象から除外する。

【0086】

図１５及び図１６は、ＶＣ検証処理の手順の一例を示すシーケンスチャートである。図１６に示すシーケンスチャートは、図１５に示すシーケンスチャートに連続している。当該ＶＣ検証処理は、Ｖｅｒｉｆｉｅｒサーバ３００のＶＣ検証部３４０によって実行される。

【0087】

図１５に示すステップＳ３０１では、発行対象者失効情報取得部３４１が、ＩＤ_{発行対象者}に基づいて失効情報キャッシュ部３７０を検索する。ステップＳ３０２では、当該ＩＤ_{発行対象者}に該当する失効情報_{発行対象者}がある場合、発行対象者失効情報取得部３４１が、失効情報キャッシュ部３７０から失効情報_{発行対象者}を取得する。

【0088】

一方、当該ＩＤ_{発行対象者}に該当する失効情報_{発行対象者}がない場合、ステップＳ３０３では、発行対象者失効情報取得部３４１が、ＩＤ_{発行対象者}に基づいてＶＤＲ４００を検索する。ステップＳ３０４では、当該ＩＤ_{発行対象者}に該当する失効情報_{発行対象者}がある場合、発行対象者失効情報取得部３４１が、ＶＤＲ４００から失効情報_{発行対象者}を取得する。

【0089】

当該ＩＤ_{発行対象者}に該当する失効情報_{発行対象者}があった場合、ステップＳ３０５では、発行対象者失効情報取得部３４１が、失効情報_{発行対象者}を失効情報キャッシュ部３７０に格納する。一方、当該ＩＤ_{Ｈｏｌｄｅｒ}に該当する失効情報_{Ｈｏｌｄｅｒ}を取得できなかった場合、発行対象者失効情報取得部３４１は、失効情報キャッシュ部３７０にアクセスしない。

【0090】

ステップＳ３０６では、発行対象者有効性検証部３４２が発行対象者の有効性を検証する。次に、ステップＳ３０７では、失効ＶＣ分析部３２３がＶＣの有効性の検証を行う。ステップＳ３０８では、Ｉｓｓｕｅｒ失効情報取得部３４３が、ＩＤ_{Ｉｓｓｕｅｒ}に基づいて失効情報キャッシュ部３７０を検索する。ステップＳ３０９では、当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する失効情報_{Ｉｓｓｕｅｒ}がある場合、Ｉｓｓｕｅｒ失効情報取得部３４３が、失効情報キャッシュ部３７０から失効情報_{Ｉｓｓｕｅｒ}を取得する。

【0091】

一方、当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する失効情報_{Ｉｓｓｕｅｒ}がない場合、ステップＳ３１０では、Ｉｓｓｕｅｒ失効情報取得部３４３が、ＩＤ_{Ｉｓｓｕｅｒ}に基づいてＶＤＲ４００を検索する。ステップＳ３１１では、当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する失効情報_{Ｉｓｓｕｅｒ}がある場合、Ｉｓｓｕｅｒ失効情報取得部３４３が、ＶＤＲ４００から失効情報_{Ｉｓｓｕｅｒ}を取得する。当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する失効情報_{Ｉｓｓｕｅｒ}があった場合、ステップＳ３１２では、Ｉｓｓｕｅｒ失効情報取得部３４３が、失効情報_{Ｉｓｓｕｅｒ}を失効情報キャッシュ部３７０に格納する。一方、当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する失効情報_{Ｉｓｓｕｅｒ}を取得できなかった場合、Ｉｓｓｕｅｒ失効情報取得部３４３は、失効情報キャッシュ部３７０にアクセスしない。

【0092】

ステップＳ３１３では、Ｉｓｓｕｅｒ有効性検証部３４４がＩｓｓｕｅｒについて有効性を検証する。次に、ステップＳ３１４では、失効ＶＣ分析部３２３が、上述したステップＳ３０７と同様にＶＣの有効性の検証を行う。

【0093】

図１６に示すステップＳ３１５では、ＶＣ失効情報取得部３４５が、ＩＤ_ＶＣに基づいて失効情報キャッシュ部３７０を検索する。ステップＳ３１６では、当該ＩＤ_ＶＣに該当する失効情報_ＶＣがある場合、ＶＣ失効情報取得部３４５が、失効情報キャッシュ部３７０から失効情報_ＶＣを取得する。一方、当該ＩＤ_ＶＣに該当する失効情報_ＶＣがない場合、ＶＣ失効情報取得部３４５は、ステップＳ３１７を実行する。

【0094】

ステップＳ３１７では、ＶＣ失効情報取得部３４５が、ＩＤ_ＶＣに基づいてＶＤＲ４００を検索する。ステップＳ２０４では、当該ＩＤ_ＶＣに該当する失効情報_ＶＣがある場合、ＶＣ失効情報取得部３４５が、ＶＤＲ４００から失効情報_ＶＣを取得する。当該ＩＤ_ＶＣに該当する失効情報_ＶＣがある場合、ステップＳ２０５では、ＶＣ失効情報取得部３４５が、失効情報_ＶＣを失効情報キャッシュ部３７０に格納する。一方、当該ＩＤ_ＶＣに該当する失効情報_ＶＣを取得できなかった場合、ＶＣ失効情報取得部３４５は、失効情報キャッシュ部３７０にアクセスしない。

【0095】

ステップＳ３２０では、ＶＣ有効性検証部３４６がＶＣについて有効性を検証する。次に、ステップＳ３２１では、失効ＶＣ分析部３２３が、上述したステップＳ３０７と同様にＶＣの有効性の検証を行う。

【0096】

ＶＣが有効性である場合、ステップＳ３２２では、Ｉｓｓｕｅｒ公開鍵取得部３４７が、ＩＤ_{Ｉｓｓｕｅｒ}に基づいて公開鍵キャッシュ部３８０を検索する。ステップＳ３２３では、当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する公開鍵_{Ｉｓｓｕｅｒ}がある場合、Ｉｓｓｕｅｒ公開鍵取得部３４７が、公開鍵キャッシュ部３８０から公開鍵_{Ｉｓｓｕｅｒ}を取得する。

【0097】

ステップＳ３２４では、Ｉｓｓｕｅｒ公開鍵取得部３４７が、ＩＤ_{Ｉｓｓｕｅｒ}に基づいてＶＤＲ４００を検索する。ステップＳ３２５では、当該ＩＤ_{Ｉｓｓｕｅｒ}に該当する公開鍵_{Ｉｓｓｕｅｒ}がある場合、Ｉｓｓｕｅｒ公開鍵取得部３４７が、ＶＤＲ４００から公開鍵_{Ｉｓｓｕｅｒ}を取得する。ステップＳ３２６では、Ｉｓｓｕｅｒ公開鍵取得部３４７が、公開鍵_{Ｉｓｓｕｅｒ}を公開鍵キャッシュ部３８０に格納する。

【0098】

ステップＳ２２７では、Ｉｓｓｕｅｒ署名検証部３４８が電子署名を検証する。次に、ステップＳ３２８では、失効ＶＣ分析部３２３が、上述したステップＳ３０７と同様にＶＣの有効性の検証を行う。

【0099】

図１７及び図１８は、失効によりＶＣが無効となる場合の一例を示している。図１７は、発行対象者の失効によりＶＣが無効となる場合の一例であり、図１８は、Ｉｓｓｕｅｒの失効によりＶＣが無効となる場合の一例を示している。

【0100】

図１７に示す発行対象者ベースＶＰ構造化データでは、発行対象者ａが失効しており、発行対象者ａにぶらさがるＶＣ_１及びＶＣ_２が無効となっている。したがって、これらＶＣ_１及びＶＣ_２が含められるＶＣ_３は無効なものと取り扱われる。

【0101】

一方、図１８に示すＩｓｓｕｅｒベースＶＰ構造化データでは、ＩｓｓｕｅｒＡが失効しており、ＩｓｓｕｅｒＡにぶらさがるＶＣ_１及びＶＣ_４が無効となっている。したがって、ＩｓｓｕｅｒＡ、ＶＣ_１及びＶＣ_４は無効なものと取り扱われる。

【0102】

（ＶＰ構造分析処理（２回目以降））
図１９は、ＶＰ構造分析処理（２回目以降）の手順の一例を示すフローチャートである。図１９に示すＶＰ構造分析処理は、ＶＰ構造分析部３２０によって２回目以降に実行されるＶＰ構造分析処理である。すなわち、図１９に示すＶＰ構造分析処理は、図１１に示す初回のＶＰ構造分析処理が実行された後に実行される。

【0103】

ステップＳ１２１では、失効ＶＣ分析部３２３が、失効情報を受け取る。ステップＳ１２２では、失効ＶＣ分析部３２３が、発行対象者が失効しているか否かを判断する。

【0104】

失効ＶＣ分析部３２３は、発行対象者が失効していない場合にはステップＳ１２３を実行する。ステップＳ１２３では、失効ＶＣ分析部３２３が、失効しているか否かを判断する。失効ＶＣ分析部３２３は、Ｉｓｓｕｅｒが失効していない場合にはステップＳ１２４を実行する。ステップＳ１２４では、失効ＶＣ分析部３２３が、Ｉｓｓｕｅｒベース有効ＶＰ構造化データの内、失効したＶＣ全てを削除としたものを新たなＩｓｓｕｅｒベース有効ＶＰ構造化データとする。なお、このようにステップＳ１２４が実行されるのは、ＶＣが失効している場合であり、ＶＣが失効しているのは、主として２つの場合である。まず、第１には、ＶＣ有効性検証において失効している場合であり、第２には、Ｉｓｓｕｅｒの署名検証で検証に失敗した場合である。次にステップＳ１２５では、失効ＶＣ分析部３２３が、発行対象者ベース有効ＶＰ構造化データの内、失効したＶＣ全てを削除としたものを新たな発行対象者ベース有効ＶＰ構造化データとする。

【0105】

一方、失効ＶＣ分析部３２３は、Ｉｓｓｕｅｒが失効している場合にはステップＳ１２６を実行する。

【0106】

ステップＳ１２６では、失効ＶＣ分析部３２３が、Ｉｓｓｕｅｒベース有効ＶＰ構造化データの内、失効したＩｓｓｕｅｒおよびそのＩｓｓｕｅｒにぶら下がるＶＣ全てを削除としたものを新たなＩｓｓｕｅｒベース有効ＶＰ構造化データとする。次にステップＳ１２７では、失効ＶＣ分析部３２３が、削除されたＶＣを、発行対象者ベース有効ＶＰ構造化データから削除し、新たな発行対象者ベース有効ＶＰ構造化データとする。

【0107】

一方、失効ＶＣ分析部３２３は、発行対象者が失効している場合にはステップＳ１２８を実行する。ステップＳ１２８では、失効ＶＣ分析部３２３が、発行対象者ベース有効ＶＰ構造化データの内、失効した発行対象者およびその発行対象者にぶら下がるＶＣ全てを削除としたものを新たな発行対象者ベース有効ＶＰ構造化データとする。ステップＳ１２９では、失効ＶＣ分析部３２３が、削除されたＶＣを、Ｉｓｓｕｅｒベース有効ＶＰ構造化データから削除し、新たなＩｓｓｕｅｒベース有効ＶＰ構造化データとする。

【0108】

図２０は、認可ポリシ検証処理の手順の一例を示すシーケンスチャートである。当該認可ポリシ検証処理は、認可ポリシ検証部３５０によって実行される。当該認可ポリシ検証処理は、Ｉｓｓｕｅｒベース有効ＶＰ構造化データに含まれる各ＶＣもしくは発行対象者ベース有効ＶＰ構造化データに含まれるＶＣに基づき、サービスの提供を認可すべきか否かを判断する。

【0109】

まず、ステップＳ４０１では、認可ポリシ取得部３５１が、認可ポリシ要求を発行する。ステップＳ４０２では、その認可ポリシ要求に該当する認可ポリシがある場合、当該認可ポリシを取得する（ステップＳ４０２）。

【0110】

次に、ステップＳ４０３では、属性情報検証部３５２が、当該ＶＰに含まれる属性情報を検証する。当該ＶＰには、委任者（Ｈｏｌｄｅｒ１）の属性情報を含むＶＣ_１、委任者から受任者（Ｈｏｌｄｅｒ２）への属性情報を含むＶＣ_２、及び、受託者（Ｈｏｌｄｅｒ２）の属性情報を含むＶＣ_３が含まれている。

【0111】

次に、ステップＳ４０３では、属性情報検証部３５２がこれらの属性情報の関係性が辿れるか検証する。

【0112】

ステップＳ４０４では、Ｉｓｓｕｅｒトラスト検証部３５３が、ＶＤＲ４００に対してＩｓｓｕｅｒのトラスト情報要求を発行する。ステップＳ４０５では、ＶＤＰ４００に、該当するトラスト情報がある場合、Ｉｓｓｕｅｒトラスト検証部３５３が、当該トラスト情報としてＩｓｓｕｅｒトラスト情報を取得する。

【0113】

本実施形態による認可システム１０００は、委任者の属性情報を含む第１の検証可能証明書の一例としてのＶＣ_１を発行するとともに、委任者として受任者に対する委任情報として委任者の属性情報（例えば委任者の署名やＩＤ_委任者を含む）を含む第２の検証可能証明書の一例としてのＶＣ_２を発行する発行者装置の一例としてのＩｓｓｕｅｒサーバ１００、受任者がＶＣ_２及びＶＣ_１を受け取ると、受任者の属性情報を含む第３の検証可能証明書の一例としてのＶＣ_３をＶＣ_１及びＶＣ_２に付加して構成したＶＰを発行する認可依頼装置の一例としてのＨｏｌｄｅｒ端末２００と、Ｈｏｌｄｅｒ端末２００から受け取った前記ＶＰが真正なものであるか否かを認可する認可装置の一例としてのＶｅｒｉｆｉｅｒサーバ３００と、を備える。このＶｅｒｉｆｉｅｒサーバ３００は、Ｈｏｌｄｅｒ端末２００からＶＰを受け取ると、ＶＣ_２に含まれる委任者の属性情報が、ＶＣ_１に含まれる委任者の属性情報と不整合がなく辿れ、かつ、ＶＣ_３における受任者の属性情報が、ＶＣ_１における委任者、並びに、ＶＣ_２における委任者及び受任者の属性情報と不整合なく辿れる場合、ＶＣ_３を含むＶＰが真正なものと判断するＶＰ構造分析部３２０を有する。

【0114】

本実施形態による認可方法は、Ｉｓｓｕｅｒサーバ１００が、委任者の属性情報を含むＶＣ_１を発行する第１の発行ステップと、Ｉｓｓｕｅｒサーバ１００が、委任者として受任者に対する委任情報として委任者の属性情報を含むＶＣ_２を発行する第２の発行ステップと、Ｈｏｌｄｅｒ端末２００が、受任者がＶＣ_２及びＶＣ_１を受け取ると、受任者の属性情報を含むＶＣ_３をＶＣ_１及びＶＣ_２に付加して構成したＶＰを発行する第２の発行ステップと、Ｖｅｒｉｆｉｅｒサーバ３００のＶＰ構造分析部３２０が、Ｈｏｌｄｅｒ端末２００からＶＰを受け取ると、ＶＣ_２に含まれる委任者の属性情報が、ＶＣ_１に含まれる委任者の属性情報と不整合がなく辿れ、かつ、ＶＣ_３における受任者の属性情報が、ＶＣ_１における委任者、並びに、ＶＣ_２における委任者及び受任者の属性情報と不整合なく辿れる場合、ＶＣ_３を含むＶＰが真正なものと判断する検証可能依頼要求検証ステップと、を有する。このようにすると、例えば受任者による無効なＶＣを用いたなりすましを防止することができる。

【0115】

本実施形態において、ＶＰ構造分析部３２０は、上述したように不整合なく辿れない場合、それ以降検証プロセスの検証対象から除外する。このようにすると、ＶＣ検証部３４０が当該一部のＶＣについて検証する必要がなくなる分、処理コストを抑制することができる。

【0116】

本実施形態において、認可装置の一例としてのＶｅｒｉｆｉｅｒ３００は、複数のＶＣの関係性を構造化したデータである構造化データの一部のＶＣが失効していると判断した場合、構造化データから当該一部のＶＤを削除した残りの構造化データを検証の対象とするＶＣ検証部３４０を備える。このようにすると、ＶＣ検証部３４０が当該一部のＶＣについて検証する必要がなくなる分、処理コストを抑制することができる。

【0117】

本実施形態において、Ｖｅｒｉｆｉｅｒ３００は、複数のＶＣの関係性を構造化したデータである構造化データの一部のＶＣが失効していると判断した場合、構造化データから一部の検証可能証明書を削除した残りの構造化データを検証の対象とする認可ポリシ検証部３５０を備える。このようにすると、認可ポリシ検証部３５０が当該一部のＶＣについて検証する必要がなくなる分、処理コストを抑制することができる。

【0118】

本実施形態による認可システム１０００は、所定のサービスの提供を認可すべきか否かに関する判断基準を示す認可ポリシを格納する認可ポリシ格納部３９０（図６参照）を備え、認可ポリシ検証部３５０は、複数のＶＣの関係性を構造化したデータである構造化データが認可ポリシに反しない場合にはサービスの提供を認可する一方、当該構造化データが認可ポリシに反する場合にはサービスの提供を認可しない。このようにすると、認可ポリシ格納部３９０に適切な認可ポリシを設定しておけば、認可ポリシ検証部３５０が、サービスを提供すべき相手を的確に選択することができる。

【0119】

本実施形態による認可システム１０００は、Ｉｓｓｕｅｒトラスト情報と、認可ポリシに記載されているＩｓｓｕｅｒトラストに関する条件、Ｉｓｓｕｅｒベース有効ＶＰ構造化データに含まれる発行者の情報から、認可ポリシを満たしているか検証を行うトラスト検証部を備える。

【0120】

本実施形態による認可システム１０００は、電子署名の認証に用いられる公開鍵が格納される公開鍵キャッシュ部３８０を備える。このようにすると、電子署名の改ざんを発見することができる。

【0121】

本実施形態による認可システム１０００は、検証対象（例えばＶＣ_１、ＶＣ_２、ＶＣ_３、ＶＰ）の失効情報が格納される失効情報キャッシュ部３７０を備える。このようにすると、失効情報キャッシュ部３７０に失効情報が格納されているＶＣ_１、ＶＣ_２、ＶＣ_３、ＶＰのいずれかが検証対象となった場合に不正であることを把握することができる。

【0122】

本実施形態において、検証可能証明書は、一例としてＶＣ（Verifiable Credential）であり、検証可能依頼要求は、一例としてＶＰ（Verifiable Presentation）である。

【0123】

（２）第２の実施形態
第２の実施形態による認可システムは、第１の実施形態による認可システム１０００とほぼ同様の構成及び動作であるため、以下、主として相違する点について説明する。図２１は、第２の実施形態による認可システムの構成例示すブロック図である。なお、図２１において図６の各構成に対応する詳細な構成は省略されている。

【0124】

第２の実施形態による認可システムでは、第１の実施形態による認可システム１０００においてＶｅｒｉｆｉｅｒサーバ３００上に全て搭載されていたＶＰ構造分析部３２０、ＶＰ検証部３３０、ＶＣ検証部３４０、認可ポリシ検証部３５０、ＶＰ構造データ格納部３６０、失効情報キャッシュ部３７０、公開鍵キャッシュ部３８０及び認可ポリシ格納部３９０と、上述したＶｅｒｉｆｉｅｒ３９７とが別体とされている。

【0125】

具体的には、第２の実施形態による認可システムでは、ＶＰ構造分析部３２０、ＶＰ検証部３３０、ＶＣ検証部３４０、認可ポリシ検証部３５０、ＶＰ構造データ格納部３６０、失効情報キャッシュ部３７０、公開鍵キャッシュ部３８０及び認可ポリシ格納部３９０がＶＰ検証サーバ３９９上に搭載されており、ＶＰ検証サーバ３９９は、委任者及び受任者等（やＩｓｓｕｅｒサーバ１００、Ｈｏｌｄｅｒ端末２００及びＶＤＲ４００等）とＶＣをやり取りするインターフェース３９８を有するＶｅｒｉｆｉｅｒとは別体となっている。

【0126】

ＶＰ検証サーバ３９９とＶｅｒｉｆｉｅｒ３９７とは、図示しないネットワークによって接続されている。ＶＰ検証サーバ３９９は、Ｖｅｒｉｆｉｅｒ３９７からＶＰを受け取ると、第１の実施形態と同様に、ＶＰ構造分析部３２０、ＶＰ検証部３３０、ＶＣ検証部３４０及び認可ポリシ検証部３５０が、ＶＰ構造データ格納部３６０、失効情報キャッシュ部３７０、公開鍵キャッシュ部３８０及び認可ポリシ格納部３９０を用いて認可を行い、その認可判断結果をＶｅｒｉｆｉｅｒ３９７（のインターフェース３９８）に返答する。インターフェース３９８は、この返答内容を外部（受任者等）に返答する。

【0127】

本実施形態において、委任者及び受任者とやり取りを行うインターフェース３９８と、少なくとも、ＶＰ構造分析部３２０、ＶＰ検証部３３０、ＶＣ検証部３４０及び認可ポリシ検証部３５０を有する検証可能依頼要求認可サーバの一例としてのＶＰ検証サーバ３９９と、が別体である。このようにＶＰ検証サーバ３９９を用いると、各処理を分散することができる分、ＶＰ検証サーバ３９９の処理負担が抑制されるため、処理コストを低減することができるとともに、高速ながら高価なデバイスを用いる必要がなくなるため、システム全体として費用を抑制することができる。

【0128】

なお、本発明は前述した実施形態に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、本実施形態において並列的に記載された各要素は、各要素の少なくとも１つが他の要素に対して直列的に接続された態様であっても良い。

【産業上の利用可能性】

【0129】

本発明は、例えばVerifiable Credentialsを活用する際におけるなりすましを防止する技術に関する認可システムに適用することができる。

【符号の説明】

【0130】

１００……Ｉｓｓｕｅｒサーバ、２００……Ｈｏｌｄｅｒ端末、３００……Ｖｅｒｉｆｉｅｒサーバ、３２０……ＶＰ構造分析部、３３０……ＶＰ検証部、３４０……ＶＣ検証部、３５０……許可ポリシ検証部、３９９……ＶＰ検証サーバ、１０００……認可システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】