JP2023111292A - 属性情報変換装置、属性情報変換プログラム及び属性情報変換方法 - Google Patents

Abstract

【課題】第１ＤＩＤ基盤において利用可能なユーザの属性情報を第２ＤＩＤ基盤において利用可能な属性情報に変換する。
【解決手段】変換要求受信部が、１つのＤＩＤ基盤において利用可能な利用者の署名付きの証明書を、他のＤＩＤ基盤において利用可能な署名付きの証明書に変換する要求（変換要求）を受け付ける。ＵＲＬ生成・発行部は、変換要求に対して互いに紐づけられた、検証要求用ＵＲＬと発行要求用ＵＲＬを発行する。検証部は、検証要求用ＵＲＬを通じてスマートフォンから送信されてきた署名付き証明書を取得すると、署名の検証を行う。変換部は、検証に成功した場合に、署名付きの証明書の変換を行う。そして、発行部は、発行要求用ＵＲＬを通じてアクセスしてきたスマートフォンに対して、変換後の署名付きの証明書を送信する。
【選択図】図９

Description

本発明は、属性情報変換装置、属性情報変換プログラム及び属性情報変換方法に関する。

近年、巨大私企業が多くの個人データを管理する世の中に対抗するため、個人が自分自身のアイデンティティをコントロールすることを目指す自己主権型アイデンティティ（ＳＳＩ：Self-Sovereign Identity）という理念が注目されている。また、ＳＳＩを実現するため、分散ＰＫＩ（Public Key Infrastructure）を利用した分散型アイデンティティ（ＤＩＤ：Decentralized IDentity）基盤の開発が進んでいる。ＤＩＤ基盤は、個人の属性情報（年齢、性別など）を、属性情報の真正性を担保する発行者の署名付きで個人管理する仕組みである。現在、様々な企業や団体がＤＩＤ基盤の開発を行っており、今後、ＤＩＤ基盤自体の管理主体（コンソーシアム）も多岐にわたると予想される。

例えばＤＩＤ基盤では、利用者（Holder）は発行者（Issuer）から、利用者の属性情報が記載された証明書を受け取る。証明書は平文の文字データであり、その証明書には発行者のデジタル署名（以下、単に「署名」という）が付与される。利用者は検証者(Verifier)に、発行者の署名付きの証明書を提示することで、自身の属性を証明することができる。例えば、免許センター（発行者）が、ドライバー（利用者）に対して運転免許証（証明書）を発行すると、ドライバーは、ＤＩＤ基盤を利用して運転免許証を酒屋（検証者）に提示することで、自分が２０歳以上であることを証明することができる。また、例えば、学校（発行者）が、卒業生（利用者）に対して卒業証明書を発行すると、卒業生は、ＤＩＤ基盤を利用して卒業証明書を企業（検証者）に提示することで、自分がその学校の卒業生であることを証明することができる。

特開２０１０－１１８０６９号公報 特開２００３－４４６０７号公報 米国特許出願公開第２０１７／０２２３００１号明細書 米国特許出願公開第２０１０／０１５４０４１号明細書

複数のＤＩＤ基盤が存在する場合、ＤＩＤ基盤ごとに署名・検証方式が異なる。そのため、例えば発行者が証明書の発行に利用したＤＩＤ基盤と、検証者が利用可能なＤＩＤ基盤とが異なる場合、検証ができない。

１つの側面では、本発明は、第１のサービスにおいて利用可能なユーザの属性情報を第２のサービスにおいて利用可能な属性情報に変換することが可能な属性情報変換装置、属性情報変換プログラム及び属性情報変換方法を提供することを目的とする。

一つの態様では、属性情報変換装置は、第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行するアクセス情報発行部と、前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する変換処理部と、を備える。

第１のサービスにおいて利用可能なユーザの属性情報を第２のサービスにおいて利用可能な属性情報に変換することができる。

一実施形態に係る情報処理システムの構成を概略的に示す図である。 変換装置のハードウェア構成の一例を示す図である。 同一ＤＩＤ基盤内での属性情報の証明手順の一例を示す図である。 図３のスマートフォンにおいて動作するIdentity Walletアプリが有する機能を示す図である。 変換装置を用いて、署名付きの証明書を変換する処理の流れを概略的に示す図である。 変換装置が有する機能を示す機能ブロック図である 変換装置の処理を示すフローチャートである。 図８（ａ）～図８（ｃ）は、ブラウザに表示される画面の一例を示す図である。 ２人の利用者（Ｘさん、Ｙさん）が変換装置を利用する場合について模式的に示す図である。 比較例を示す図である。

以下、一実施形態について、図１～図１０に基づいて詳細に説明する。本実施形態の情報処理システム１０は、署名方式や検証方式が異なる２つのＤＩＤ基盤（第１ＤＩＤ基盤１００と第２ＤＩＤ基盤２００）を相互接続できるようにしたものである。すなわち、第１ＤＩＤ基盤１００が、ユーザ（利用者）の第１の種類の属性情報を利用可能な第１のサービスに相当し、第２ＤＩＤ基盤２００が、ユーザの第２の種類の属性情報を利用可能な第２のサービスに相当する。第１ＤＩＤ基盤１００と第２ＤＩＤ基盤２００においては、個人の属性情報を本人が管理できるようになっている。

図１は、情報処理システム１０の構成を概略的に示す図である。図１に示すように、情報処理システム１０は、ネットワーク３００を有しており、ネットワーク３００には第１ＤＩＤ基盤１００と第２ＤＩＤ基盤２００それぞれに属する装置が接続されている。

第１ＤＩＤ基盤１００には、発行者装置１２、利用者が利用するＰＣ（Personal Computer）１４、利用者が利用する端末としてのスマートフォン１６、検証者端末１８、分散ＰＫＩシステム２０、及び属性情報変換装置としての変換装置３０が属している。また、第２ＤＩＤ基盤２００には、発行者装置４２、ＰＣ４４、スマートフォン４６、検証者端末４８、分散ＰＫＩシステム５０、及び変換装置３０が属している。

発行者装置１２、４２は、証明書を発行する発行者が管理する１または複数のコンピュータである。例えば、発行者装置１２、４２を利用する発行者が、大学であれば、発行者装置１２，４２は、大学の卒業生に対して卒業証明書を発行する。

ＰＣ１４、４４は、証明書を利用して自身の属性を証明する利用者が利用するコンピュータである。スマートフォン１６、４６は、利用者が証明書の発行を受けたり、証明書を利用する際に用いる端末である。

検証者端末１８、４８は、スマートフォン１６、４６を介して利用者から提示される証明書に基づいて、利用者の属性を検証する検証者が管理するコンピュータである。

分散ＰＫＩシステム２０、５０は、公開鍵を管理する１または複数のコンピュータである。分散ＰＫＩシステム２０、５０は、ブロックチェーンのような分散型台帳で公開鍵を管理してもよい。

変換装置３０は、第１ＤＩＤ基盤１００（又は第２ＤＩＤ基盤２００）で利用可能な証明書を、第２ＤＩＤ基盤２００（又は第１ＤＩＤ基盤１００）で利用可能な証明書に変換するサービスを行う中間事業者が管理するコンピュータである。図１に示すように、変換装置３０は、第１ＤＩＤ基盤１００と第２ＤＩＤ基盤２００の両方に属している。

図２は、変換装置３０のハードウェア構成の一例を示す図である。図２に示すように、変換装置３０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、ストレージ（ＨＤＤやＳＳＤ）９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９、表示部９３、入力部９５等を備えている。これら変換装置３０の構成各部は、バス９８に接続されている。表示部９３は液晶ディスプレイや有機ＥＬディスプレイ等を含み、入力部９５は、マウスやキーボード、タッチパネル等を含む。変換装置３０では、ＲＯＭ９２あるいはストレージ９６に格納されているプログラム（属性情報変換プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、図６に示す各部の機能が実現される。なお、図６の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。なお、図１のその他の装置（発行者装置１２，４２、ＰＣ１４，４４、スマートフォン１６，４６、検証者端末１８，４８、分散ＰＫＩシステム２０，５０）についても、変換装置３０と同様のハードウェアにより実現することができる。

ここで、図１に示すように２つのＤＩＤ基盤が存在する場合において、同じＤＩＤ基盤内で、利用者が自身の属性情報を検証者に証明する方法について、図３に基づいて説明する。

図３は、同一ＤＩＤ基盤内での属性情報の証明手順の一例を示す図である。図３の例では、第１ＤＩＤ基盤１００に属する利用者が、同じ第１ＤＩＤ基盤１００に属する検証者に、自身の属性を示す属性情報の正当性を証明するものとする。

発行者装置１２は、発行者の秘密鍵１１１と公開鍵１１２とのペアを生成する。発行者装置１２は、公開鍵１１２を分散ＰＫＩシステム２０に登録することで、第１ＤＩＤ基盤１００に属する他の装置からの公開鍵１１２の利用を可能とする。

発行者装置１２は、例えば利用者からの要求に応じて、署名１１４付きの証明書１１６（「クレデンシャル」とも呼ばれる）を発行する。証明書１１６には、利用者の個人情報が含まれている。例えば証明書１１６が卒業証明書であれば、証明書１１６には、利用者の氏名、学籍番号、卒業年度、大学名、学科名などが含まれる。署名１１４は、第１ＤＩＤ基盤１００の仕様に従って、発行者の秘密鍵１１１を用いて生成された電子署名である。

利用者は、発行者装置１２で発行された署名１１４付きの証明書１１６をスマートフォン１６で受信する。スマートフォン１６は、署名１１４付きの証明書１１６をストレージ内に保存する。利用者が検証者に個人の属性情報を証明する場合、スマートフォン１６から検証者端末１８へ、署名１１４付きの証明書１１６を送信する。

検証者端末１８は、分散ＰＫＩシステム２０に発行者の公開鍵１１２を問い合わせる。分散ＰＫＩシステム２０は、該当する公開鍵１１２を検証者端末１８に送信する。検証者端末１８は、公開鍵１１２を用いて署名１１４を検証し、証明書１１６の内容が発行者装置１２によって証明されていることを確認する。これにより、利用者は、自身の属性を検証者に証明することができる。

なお、第２ＤＩＤ基盤２００においても、同様の処理により、利用者が自身の属性を検証者に対して証明することができる。

図４には、図３のスマートフォン１６において動作するIdentity Walletアプリ（以下、「ID Walletアプリ」という）が有する機能が示されている。ID Walletアプリは、発行要求部５２と、検証要求部５４と、の機能を有する。

発行要求部５２は、発行者装置１２に対し、署名付きの証明書を発行するよう要求する機能を有する。また、発行要求部５２は、発行者装置１２において発行された署名付きの証明書を取得する機能を有する。なお、利用者は、例えば、ＰＣ１４のブラウザ上において発行者装置１２に対してアクセスし、利用者認証後に、発行者装置１２から発行者装置１２のＵＲＬを含むアクセス用データを受け取る。そして、利用者は、受け取ったアクセス用データを用いてID Walletアプリ（発行要求部５２）から発行者装置１２にアクセスすることで、署名付きの証明書の発行要求を行う。

検証要求部５４は、検証者端末１８に対し、署名付きの証明書を開示し、利用者の属性を検証者に証明する機能を有する。また、検証要求部５４は、検証者端末１８において検証に成功した場合に、検証に成功した旨の情報を検証者端末１８から取得する機能を有する。なお、利用者は、例えば、ＰＣ１４のブラウザ上において検証者端末１８に対してアクセスし、検証者端末１８からＵＲＬを含むアクセス用データを受け取る。そして、利用者は、受け取ったアクセス用データを用いてID Walletアプリ（検証要求部５４）から検証者端末１８にアクセスすることで、署名付きの証明書を開示する。

図３を用いて説明した通り、第１ＤＩＤ基盤１００に属する利用者であれば、同じ第１ＤＩＤ基盤１００に属する検証者に対して、自身の属性を示す属性情報の正当性を証明することは可能である。しかしながら、利用者が、第１ＤＩＤ基盤１００の発行者装置１２において発行された署名１１４付きの証明書１１６を、第２ＤＩＤ基盤２００の検証者端末４８に提示したとしても、利用者の属性情報の正当性を検証者に証明することはできない。証明書１１６は、第１ＤＩＤ基盤１００のフォーマットに従って作成されたものであり、署名１１４は、第１ＤＩＤ基盤１００の仕様に従って、発行者の秘密鍵１１１を用いて生成されたものであるからである。そこで、本実施形態においては、一方のＤＩＤ基盤で発行された署名付きの証明書を、他方のＤＩＤ基盤での検証に利用可能なように変換する変換装置３０を、第１ＤＩＤ基盤１００及び第２ＤＩＤ基盤２００の両方に属する形で設けることとした。

図５には、変換装置３０を用いて、署名付きの証明書を変換する処理の流れが概略的に示されている。なお、図５においては、説明の便宜上、変換前の署名付きの証明書（クレデンシャル）を「証明書Ａ」、変換後の署名付きの証明書（クレデンシャル）を「証明書Ｂ」と呼ぶものとする。また、スマートフォン１６，４６にインストールされている証明書Ａを利用可能なID Walletアプリを「アプリＡ」と呼び、証明書Ｂを利用可能なID Walletアプリを「アプリＢ」と呼ぶものとする。アプリＡは、証明書Ａを利用可能なＤＩＤ基盤のプロトコルに則って証明書Ａを送受信可能であり、アプリＢは、証明書Ｂを利用可能なＤＩＤ基盤のプロトコルに則って証明書Ｂを送受信可能である。

利用者は、証明書Ａを証明書Ｂに変換して利用したい場合、ＰＣのブラウザから変換装置３０に対して、変換要求を送信する（図５の（１）参照）。この変換要求を受信した変換装置３０は、変換要求に対応する識別情報（変換ＩＤ）を生成する。また、変換装置３０は、生成した変換ＩＤを含む検証要求用ＵＲＬ（第１のアクセス情報）と、変換ＩＤを含む発行要求用ＵＲＬ（第２のアクセス情報）を生成する（図５の（２）参照）。そして、変換装置３０は、生成した検証要求用ＵＲＬと発行要求用ＵＲＬをブラウザに送信する（図５の（３）、（４）参照）。

次いで、利用者は、アプリＡを用いてブラウザから検証要求用ＵＲＬを取得し（図５の（５）参照）、当該検証要求用ＵＲＬにアクセスすることで、変換装置３０に対し証明書Ａの検証を要求する（図５の（６）参照）。

変換装置３０では、証明書Ａの正当性についての検証を行い（図５の（７）参照）、検証に成功した場合には、その旨をアプリＡに通知する（図５の（８）参照）。また、変換装置３０は、検証に成功した証明書Ａを証明書Ｂに変換して、再署名を実行する。例えば、証明書のフォーマットには、ＪＷＴ（JSON Web Token）形式や、ＪＳＯＮ－ＬＤ形式がある。また、署名の方式には、ＥＣＤＳＡ（Elliptic Curve Digital Signature Algorithm）のような一般的なデジタル署名方式や、ＣＬ署名のような証明書の一部を秘匿して開示することを可能にする署名方式などがある。変換装置３０は、各ＤＩＤ基盤において利用可能な証明書のフォーマットや署名の方式に合わせて、処理を実行する。

次いで、利用者は、アプリＢを用いてブラウザから発行要求用ＵＲＬを取得し（図５の（１０）参照）、当該発行要求用ＵＲＬにアクセスすることで、変換装置３０に対し証明書Ｂの発行を要求する（図５の（１１）参照）。

変換装置３０は、アプリＢからの要求に応じて証明書Ｂを発行し、アプリＢに対して送信する（図５の（１２）参照）。これにより、アプリＡに対応するＤＩＤ基盤において利用可能な証明書Ａを、アプリＢに対応するＤＩＤ基盤において利用可能な証明書Ｂに変換することが可能である。

図６は、変換装置３０が有する機能を示す機能ブロック図である。なお、図６には、ＰＣ１４、４４のブラウザが有する機能、及びスマートフォン１６、４６において動作するID Walletアプリが有する機能についても図示されている。

図６に示すように、変換装置３０は、変換要求受信部７０、アクセス情報発行部としてのＵＲＬ生成・発行部７２、検証要求受信部７４、検証部７６、変換部７８、発行要求受信部８０、及び発行部８２の機能を有する。

変換要求受信部７０は、ブラウザの変換要求部６２から、署名付きの証明書の変換要求（例えば、証明書Ａから証明書Ｂへの変換要求）を受信する。

ＵＲＬ生成・発行部７２は、変換要求受信部７０が証明書Ａから証明書Ｂへの変換要求を受信すると、当該変換要求に対応する変換ＩＤを生成する。また、ＵＲＬ生成・発行部７２は、生成した変換ＩＤを含む検証要求用ＵＲＬと、生成した変換ＩＤを含む発行要求用ＵＲＬを生成し、ブラウザに向けて送信（発行）する。一例として、ＵＲＬ生成・発行部７２は、変換ＩＤとして「0001」を生成した場合、検証要求用ＵＲＬとして、「XXX.com/verify0001」を生成し、発行要求用ＵＲＬとして、「XXX.com/issue0001」を生成する。また、ＵＲＬ生成・発行部７２は、変換ＩＤとして「0002」を生成した場合、検証要求用ＵＲＬとして、「XXX.com/verify0002」を生成し、発行要求用ＵＲＬとして、「XXX.com/issue0002」を生成する。このように変換要求ごとに生成される検証要求用ＵＲＬと発行要求用ＵＲＬは、同一の変換ＩＤを含んでいるため、互いに紐づいていると言える。ＵＲＬ生成・発行部７２は、生成した検証要求用ＵＲＬにおいて検証部７６、変換部７８を起動し、生成した発行要求用ＵＲＬにおいて発行部８２を起動する。すなわち、生成した検証要求用ＵＲＬにおいて、検証部７６と変換部７８のサービスが提供され、生成した発行要求用ＵＲＬにおいて、発行部８２のサービスが提供される。

なお、ブラウザのＵＲＬ受信・表示部６４は、検証要求用ＵＲＬを受信すると、検証要求用ＵＲＬの情報を埋め込んだ二次元コードを生成し、ブラウザ上に表示する。利用者は、スマートフォン１６においてアプリＡを起動した状態でカメラを用いて二次元コードを撮影する。これにより、アプリＡの検証要求部５４が検証要求用ＵＲＬにアクセス可能になる。また、ＵＲＬ受信・表示部６４は、発行要求用ＵＲＬを受信すると、発行要求用ＵＲＬの情報を埋め込んだ二次元コードを生成し、ブラウザ上に表示する。利用者は、スマートフォン１６においてアプリＢを起動した状態でカメラを用いて二次元コードを撮影する。これにより、アプリＢの発行要求部５２が発行要求用ＵＲＬにアクセス可能になる。

検証要求受信部７４は、アプリＡの検証要求部５４が検証要求用ＵＲＬを通じて、証明書Ａを送信してくると、当該証明書Ａを取得し、検証要求用ＵＲＬにおいて起動されている検証部７６に受け渡す。

検証部７６は、例えば、取得した証明書Ａを利用可能なＤＩＤ基盤に属する分散ＰＫＩシステムから発行者の公開鍵を取得し、取得した公開鍵を用いて検証を行う。検証部７６は、検証結果を検証要求部５４に通知する。

変換部７８は、検証部７６が検証に成功した場合に、証明書Ａのフォーマットを証明書Ｂのフォーマットに変換するとともに、新たな秘密鍵を用いて再署名を行う。なお、再署名に用いた秘密鍵とペアをなす公開鍵は、証明書Ｂを利用可能なＤＩＤ基盤に属する分散ＰＫＩシステムに登録する。なお、変換部７８は変換後の証明書Ｂを、同一の変換ＩＤを含む発行要求用ＵＲＬで起動されている（サービスを提供している）発行部８２に対して送信する。

発行要求受信部８０は、アプリＢの発行要求部５２が発行要求用ＵＲＬを通じて、証明書Ｂの発行要求を送信してきた場合に、その旨を発行部８２に通知する。

発行部８２は、発行要求用ＵＲＬに対応する証明書Ｂを取得し、発行要求用ＵＲＬにアクセスしてきたアプリＢの発行要求部５２に対して証明書Ｂを送信する。

なお、上述した検証要求受信部７４、検証部７６、変換部７８、発行要求受信部８０、及び発行部８２により、端末からのアクセスに応じて署名付きの証明書を変換し、出力する変換処理部としての機能が実現されている。

ここで、図６のアプリＡ、Ｂが有する機能は、図４のID Walletアプリが有する機能と同様となっている。すなわち、本実施形態では、情報処理システム１０に変換装置３０を設けることとしても、アプリＡ，Ｂには、新たな機能を追加しなくてもよいようになっている。

（変換装置３０の処理について）
次に、変換装置３０の処理について、図７のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。

図７の処理が開始されると、まず、ステップＳ１０において、変換要求受信部７０は、ブラウザから変換要求が入力されるまで待機する。ここで、利用者は、ＰＣのブラウザにおいて、図８（ａ）に示すような画面を表示し、変換元と変換先を選択した後、「変換要求」ボタンを押すことで、変換要求を行う。利用者が図８（ａ）の画面上で「変換要求」ボタンを押すと、ブラウザの変換要求部６２は、変換装置３０に対して変換要求を送信する。変換要求受信部７０は、変換要求を受信すると、ステップＳ１２に移行し、変換要求を取得する。なお、図８（ａ）の「方式Ａ」は、証明書Ａを利用可能なＤＩＤ基盤で運用されている方式を意味し、「方式Ｂ」は、証明書Ｂを利用可能なＤＩＤ基盤で運用されている方式を意味するものとする。

次いで、ステップＳ１４では、ＵＲＬ生成・発行部７２が、変換ＩＤ（例えば「0001」）を生成する。また、ＵＲＬ生成・発行部７２は、変換ＩＤを含む検証要求用ＵＲＬ（例えば「XXX.com/verify0001」）、変換ＩＤを含む発行要求用ＵＲＬ（例えば「XXX.com/issue0001」）を発行して、ブラウザに送信する。このとき、ブラウザは、図８（ｂ）に示すような、検証要求用ＵＲＬ（例えば「XXX.com/verify0001」）の情報を埋め込んだ二次元コードを表示する画面を生成し、表示する。利用者は、図８（ｂ）の画面に表示されている内容に従って、変換前の証明書Ａを利用可能なＤＩＤ基盤に対応するアプリ（アプリＡ）を起動し、二次元コードを撮影する。これにより、アプリＡから検証要求用ＵＲＬ（例えば「XXX.com/verify0001」）へのアクセスが可能になる。

利用者が、アプリＡから検証要求用ＵＲＬにアクセスすると、アプリＡは、変換装置３０に対して、変換前の証明書（証明書Ａ）を送信し、検証要求を行う。図７のステップＳ１４の後、検証要求受信部７４は、ステップＳ１６において、検証要求があるまで待機しているので、アプリＡから検証要求があると、ステップＳ１８に移行する。

ステップＳ１８に移行すると、検証要求受信部７４は、受信した変換前の証明書（証明書Ａ）を検証要求用ＵＲＬで起動している検証部７６に通知する。そして、検証部７６は、変換前の証明書の検証を行う。この検証においては、証明書Ａが発行されたＤＩＤ基盤に属する分散ＰＫＩシステムにおいて管理されている公開鍵を用いた検証を行う。

次のステップＳ２０では、検証部７６が検証に成功したか否かを判断する。このステップＳ２０の判断が否定された場合には、ステップＳ２２に移行し、検証部７６は、検証に失敗した旨をアプリＡに通知して、図７の全処理を終了する。

一方、ステップＳ２０の判断が肯定された場合には、ステップＳ２４に移行し、検証部７６は、検証に成功した旨をアプリＡに通知する。次いで、ステップＳ２６では、変換部７８が、証明書のフォーマットを変換し、再署名を実行する。変換部７８は、再署名に用いた秘密鍵に対応する公開鍵を、変換後の証明書が利用可能なＤＩＤ基盤に属する分散ＰＫＩシステムに登録する。また、変換部７８は、変換後の証明書を、検証要求時にアプリＡがアクセスした検証要求用ＵＲＬに対応する発行要求用ＵＲＬにおいて起動されている（サービスを提供している）発行部８２に対して受け渡す。

次いで、ステップＳ２８では、発行要求受信部８０が、発行要求を受信するまで待機する。ここで、ブラウザは、図８（ｃ）に示すような、発行要求用ＵＲＬ（例えば「XXX.com/issue0001」）の情報を埋め込んだ二次元コードを表示する画面を生成し、表示している。利用者は、図８（ｃ）の画面に表示されている内容に従って、変換後の証明書を利用可能なＤＩＤ基盤に対応するアプリ（アプリＢ）を起動し、二次元コードを撮影する。これにより、アプリＢから発行要求用ＵＲＬへのアクセスが可能になる。アプリＢから発行要求用ＵＲＬへのアクセスがあると、ステップＳ３０に移行し、発行部８２は、変換後の証明書をアプリＢに対して発行（送信）する。

図９には、２人の利用者（Ｘさん、Ｙさん）が変換装置３０を利用する場合について模式的に示す図である。変換装置３０では、変換要求のたびに異なる変換ＩＤが生成される。例えば、ＸさんとＹさんが変換要求を行うと、異なる変換ＩＤ（＝0001,0002）が生成されることになる。また、変換要求のたびに生成される検証要求用ＵＲＬと発行要求用ＵＲＬは、変換ＩＤを含み、互いに紐づいている。これにより、Ｘさんが、変換装置３０に対して、通知された検証要求用ＵＲＬを用いて証明書Ａの検証要求を出し、通知された発行要求用ＵＲＬを用いて証明書Ｂの発行要求を出せば、Ｘさん自身の証明書Ｂを取得することができるようになっている。また、Ｙさんが、変換装置３０に対して、通知された検証要求用ＵＲＬを用いて証明書Ａの検証要求を出し、通知された発行要求用ＵＲＬを用いて証明書Ｂの発行要求を出せば、Ｙさん自身の証明書Ｂを取得することができるようになっている。ここで、ＸさんとＹさんに通知されるＵＲＬは異なるため、Ｘさんの証明書ＢをＹさんが取得してしまうようなことは一切ない。

図１０は、比較例を説明するための図である。図１０の例は、アプリＡから変換装置３０に証明書Ａを送り、変換装置３０で変換された証明書ＢをアプリＢが取得する点で、本実施形態と共通する。しかしながら、図１０の例の場合、アプリＡ、Ｂのいずれにおいても、利用者ＩＤ、パスワード等を用いて変換装置３０に対してログインする必要がある。アプリＡを用いて変換要求を行った利用者と、アプリＢを用いて発行要求を行った利用者が一致しており、かつ正当な利用者であるかを確認する必要があるからである。図１０の例を実現する場合、図４のアプリＡ，Ｂに対して、認証用の機能を追加する必要がある。また、変換装置３０では、利用者ＩＤやパスワードなどを管理する必要がある。更に、利用者は、変換装置３０にアクセスするための利用者ＩＤやパスワードを管理する必要がある。一方、本実施形態では、図４のアプリＡ、Ｂに新たに機能を追加する必要が無い。また、利用者は、変換装置３０にアクセスするための利用者ＩＤやパスワードを管理する必要がない。

以上、詳細に説明したように、本実施形態によると、変換要求受信部７０が、１つのＤＩＤ基盤において利用可能な利用者の署名付きの証明書を、他のＤＩＤ基盤において利用可能な署名付きの証明書に変換する要求（変換要求）を受け付ける。ＵＲＬ生成・発行部７２は、変換要求に対して互いに紐づけられた、検証要求用ＵＲＬと発行要求用ＵＲＬを発行する。検証部７６は、検証要求用ＵＲＬを通じてスマートフォン１６から送信されてきた署名付き証明書を取得すると、署名の検証を行う。変換部７８は、検証に成功した場合に、署名付きの証明書の変換を行う。そして、発行部８２は、発行要求用ＵＲＬを通じてアクセスしてきたスマートフォン１６に対して、変換後の署名付きの証明書を送信する。このように、本実施形態によると、１つのＤＩＤ基盤において利用可能な利用者の署名付きの証明書を、他のＤＩＤ基盤において利用可能な署名付きの証明書に変換することができる。また、変換要求に対して互いに紐づけられた検証要求用ＵＲＬと発行要求用ＵＲＬを発行するため、利用者が複数存在する場合であっても、変換後の署名付きの証明書を適切な利用者に対して発行することができる。また、本実施形態では、既存のID Walletアプリ（図４）に対して新たな機能（例えば利用者認証機能）を追加する必要が無いという利点がある。

また、本実施形態によると、ＵＲＬ生成・発行部７２は、変換要求ごとに変換ＩＤを発行し、変換ＩＤを含む検証要求用ＵＲＬと、変換ＩＤを含む発行要求用ＵＲＬを発行する。これにより、変換装置３０内においてテーブル等を用いて検証要求用ＵＲＬと発行要求用ＵＲＬとを紐付けて管理しなくても、変換要求に対応する検証要求用ＵＲＬと発行要求用ＵＲＬとを紐付けることができる。ただし、本実施形態では、変換装置３０内においてテーブル等を用いて検証要求用ＵＲＬと発行要求用ＵＲＬとを紐付けて管理してもよい。この場合、変換ＩＤを生成しなくてもよくなり、検証要求用ＵＲＬと発行要求用ＵＲＬをランダムに生成してもよくなる。

なお、上記実施形態では、利用者が、ＰＣとスマートフォンの両方を利用する場合について説明したが、これに限られるものではない。例えば、ブラウザとID WalletアプリのいずれもＰＣ上で動作してもよいし、ブラウザとID Walletアプリのいずれもスマートフォン上で動作してもよい。この場合、ブラウザからID Walletアプリへの検証要求用ＵＲＬと発行要求用ＵＲＬの受け渡しには二次元コードを用いなくてもよい。

なお、上記実施形態では、図６のID Walletアプリ（アプリＡ）と、ID Walletアプリ（アプリＢ）が同一のスマートフォン上にインストールされたものである場合について説明したが、これに限られるものではない。すなわち、アプリＡとアプリＢが異なるスマートフォンにインストールされていてもよい。

なお、上記実施形態では、変換装置３０は、図５の（３）、（４）のように、検証要求用ＵＲＬと発行要求用ＵＲＬをほぼ同一のタイミングでブラウザに送信する場合について説明したが、これに限られるものではない。例えば、変換装置３０は、発行要求用ＵＲＬを、（９）の証明書の変換及び再署名後にブラウザに送信するようにしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行するアクセス情報発行部と、
前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する変換処理部と、
を備える属性情報変換装置。
（付記２） 前記アクセス情報発行部は、前記要求ごとに識別情報を発行し、前記第１のアクセス情報と前記第２のアクセス情報に前記識別情報を含めることで、前記第１のアクセス情報と前記第２のアクセス情報を紐づける、ことを特徴とする付記１に記載の属性情報変換装置。
（付記３） 前記変換処理部は、前記ユーザの属性情報を取得すると、取得した前記属性情報が有する署名情報の検証を行い、検証に成功した場合に、前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、再署名を行う、ことを特徴とする付記１又は２に記載の属性情報変換装置。
（付記４） 第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行し、
前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する、
処理をコンピュータに実行させることを特徴とする属性情報変換プログラム。
（付記５） 前記第１のアクセス情報と前記第２のアクセス情報とを発行する処理では、前記要求ごとに識別情報を発行し、前記第１のアクセス情報と前記第２のアクセス情報に前記識別情報を含めることで、前記第１のアクセス情報と前記第２のアクセス情報を紐づける、ことを特徴とする付記４に記載の属性情報変換プログラム。
（付記６） 前記出力する処理では、前記ユーザの属性情報を取得すると、取得した前記属性情報が有する署名情報の検証を行い、検証に成功した場合に、前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、再署名を行う、ことを特徴とする付記４又は５に記載の属性情報変換プログラム。
（付記７） 第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行し、
前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する、
処理をコンピュータが実行することを特徴とする属性情報変換方法。

１６ スマートフォン（端末）
３０ 変換装置（属性情報変換装置）
４６ スマートフォン（端末）
７２ ＵＲＬ生成・発行部（アクセス情報発行部）
７４ 検証要求受信部（変換処理部の一部）
７６ 検証部（変換処理部の一部）
７８ 変換部（変換処理部の一部）
８０ 発行要求受信部（変換処理部の一部）
８２ 発行部（変換処理部の一部）
１００ 第１ＤＩＤ基盤（第１のサービス）
２００ 第２ＤＩＤ基盤（第２のサービス）

Claims (5)

1. 第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行するアクセス情報発行部と、
   前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する変換処理部と、
   を備える属性情報変換装置。
2. 前記アクセス情報発行部は、前記要求ごとに識別情報を発行し、前記第１のアクセス情報と前記第２のアクセス情報に前記識別情報を含めることで、前記第１のアクセス情報と前記第２のアクセス情報を紐づける、ことを特徴とする請求項１に記載の属性情報変換装置。
3. 前記変換処理部は、前記ユーザの属性情報を取得すると、取得した前記属性情報が有する署名情報の検証を行い、検証に成功した場合に、前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、再署名を行う、ことを特徴とする請求項１又は２に記載の属性情報変換装置。
4. 第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行し、
   前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する、
   処理をコンピュータに実行させることを特徴とする属性情報変換プログラム。
5. 第１のサービスにおいて利用可能なユーザの第１の種類の属性情報を、前記第１のサービスと異なる第２のサービスにおいて利用可能な第２の種類の属性情報に変換する要求を受け付けると、要求に対して互いに紐づけられた第１のアクセス情報と第２のアクセス情報とを発行し、
   前記第１のアクセス情報を通じて端末からユーザの属性情報を取得すると、取得した属性情報を前記第１の種類の属性情報から前記第２の種類の属性情報に変換し、変換後の属性情報を、前記第２のアクセス情報を通じてアクセスしてきた端末に対して出力する、
   処理をコンピュータが実行することを特徴とする属性情報変換方法。
   

Images