WO2023281799A1 - 情報処理装置および方法、並びにプログラム - Google Patents

Abstract

本技術は、より簡単に自己主権的なユーザ認証を実現することができるようにする情報処理装置および方法、並びにプログラムに関する。 情報処理装置は、DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、招待コードを読み取った接続先の装置からDIDcomm接続を介して受信したセッションIDと、招待コード要求に含まれている送信元の装置を識別するクライアントIDとを対応付けて記録させるセッション管理部と、接続先の装置との間でDIDcomm接続を介した通信を行う通信部とを備え、セッション管理部は、既に接続先の装置とのDIDcomm接続が確立されている場合、接続先の装置とのDIDcomm接続を再利用する。本技術は検証サーバに適用することができる。

Description

情報処理装置および方法、並びにプログラム

　本技術は、情報処理装置および方法、並びにプログラムに関し、特に、より簡単に自己主権的なユーザ認証を実現できるようにした情報処理装置および方法、並びにプログラムに関する。

　従来、ネットワーク上のサービスサイトにおいてユーザ認証を行う場合に、ユーザ名とパスワードを用いた認証が行われることが多い。

　そのような場合、サービスサイトは予め利用者（ユーザ）にIDとパスワードを登録させることによりアカウント情報を作成しておく。そして、利用者を認証する際には、登録済みのIDとパスワードを入力させることにより、サービスサイトへのアクセスを許可する。

　しかし、利用者はサービスごとに異なるIDとパスワードを管理する必要があり、また、サービスサイト側も、個別にアカウント登録ページや認証サーバを用意し、利用者の秘密情報を安全に管理する必要がある。

　一方、中央集権的なID基盤であるOpenID Connect（OIDC）などのID連携システムでは、利用者のIDを外部の認証サーバと紐づけることが可能となり、利用者は単一のアカウントを使いまわすことができるようになった。また、サービスサイトも個別にアカウント登録ページや認証サーバを用意し、利用者の秘密情報を管理することが不要となった。

　さらに、中央集権的なID基盤に関する技術として、IDとパスワードを用いて認証を行い、パスワードに応じて権限を切り替えるという技術（例えば、特許文献１参照）や、ソフトウェアモジュール設計における効率化のために、利用者を認証する部分と利用者の権限を証明する部分に分離するという技術（例えば、特許文献２参照）も提案されている。

　しかし、このような中央集権的なID基盤においては、個人情報が一箇所に集中することによって生じる様々なリスクがある。

　例えば、データ流出のリスクや、個人情報を利用者の意思とは無関係に目的外の用途で利用されてしまうといったリスクが考えられる。また、IDを自己管理できないということは、IDを管理する側のポリシー変更によって、利用者が突然自らのIDを失うことがあり得る。そのような場合、利用者は連携する様々なサービスの利用が出来なくなってしまうことになる。

　そこで、VC（Verifiable Credential）を用いたSSI（Self-Sovereign Identity）と呼ばれる技術が注目を集めている。

　VCとは、資格情報を電子的に検証可能な方法で表現するためのデータモデルを定義するW3C標準の勧告（例えばhttps://www.w3.org/TR/vc-data-model/参照）である。

　SSIは、VCを用いることにより、発行された資格情報を自己主権的な方法で電子的に検証することを可能とする技術である。

国際公開第２０１５／０９７９２７号 特開２００７－９４６７４号公報

　しかしながら、上述のSSIを利用して自己主権的なユーザ認証を実現することは、容易ではなかった。

　すなわち、例えば自己主権的なユーザ認証を実現するためにVerifiable Credentialを既存システムに実装するためには、サービスサイト等においてSSIの機能を統合する必要がある。

　また、SSIにおけるDIDcomm接続（例えばhttps://github.com/hyperledger/aries-rfcs/blob/master/concepts/0005-didcomm/README.md参照）を確立するためには、まず、接続先で生成された招待コードをモバイルアプリケーションで読み取る必要がある。

　このとき、サービスサイト等にログインしようとする者が既に接続済みであるかは分からないので、ログインに必要な招待コードを毎回提示しておく必要があるが、その結果、ログインする度に新しいDIDcomm接続が確立されることとなる。そのため、ログインするたびに新規接続の手順が実行されるので、利用者の操作手順が多くなり、手間を要する。

　さらに、利用者登録画面に表示された招待コードをモバイルアプリケーションでスキャンすることによってVCの発行処理を開始する場合、VC発行サーバは、利用者が、どの利用者登録画面に表示された招待コードをスキャンしたのかを識別する必要がある。

　同様に、ログイン画面に表示された招待コードをモバイルアプリケーションでスキャンしてログインする場合、検証サーバは、利用者がどのログイン画面に表示された招待コードをスキャンしたのかを識別する必要がある。

　そのため、DIDcomm接続を開始した後、スキャンした招待コードが、どの画面に表示されていたものであるかを識別する仕組みが必要である。

　本技術は、このような状況に鑑みてなされたものであり、より簡単に自己主権的なユーザ認証を実現できるようにするものである。

　本技術の第１の側面の情報処理装置は、DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させるセッション管理部と、前記接続先の装置との間でDIDcomm接続を介した通信を行う通信部とを備え、前記セッション管理部は、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する。

　本技術の第１の側面の情報処理方法またはプログラムは、DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させ、前記接続先の装置との間でDIDcomm接続を介した通信を行うステップを含み、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する。

　本技術の第１の側面においては、DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードが生成され、前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとが対応付けられて記録され、前記接続先の装置との間でDIDcomm接続を介した通信が行われる。また、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続が再利用される。

　本技術の第２の側面の情報処理装置は、提示されたDIDcomm接続のための招待コードを読み取る読み取り部と、前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する制御部と、前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する通信部とを備える。

　本技術の第２の側面の情報処理方法またはプログラムは、提示されたDIDcomm接続のための招待コードを読み取り、前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用し、前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する。

　本技術の第２の側面においては、提示されたDIDcomm接続のための招待コードが読み取られ、前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかが特定され、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続が再利用され、前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDが、DIDcomm接続を介して前記接続先の装置に送信される。

本技術について説明する図である。 中央集権的なID連携の手法と、本技術の手法について説明する図である。 サービス提供システムの構成例を示す図である。 VC発行時の処理を説明するフローチャートである。 VC発行時の処理を説明するフローチャートである。 招待コード要求の例を示す図である。 VC発行サーバの設定情報の例を示す図である。 招待コードの例を示す図である。 実際の招待コードの例を示す図である。 セッション情報の例を示す図である。 接続情報の例を示す図である。 開始要求の例を示す図である。 SSI証明を用いた認証時の処理を説明するフローチャートである。 SSI証明を用いた認証時の処理を説明するフローチャートである。 検証サーバの設定情報の例を示す図である。 認証情報の例を示す図である。 IDトークンの例を示す図である。 IDトークンの生成について説明する図である。 コンピュータの構成例を示す図である。

　以下、図面を参照して、本技術を適用した実施の形態について説明する。

〈第１の実施の形態〉
〈本技術について〉
　本技術は、既に普及しているOpenID Connect等で利用されているIDトークンを利用することによって、資格情報であるVC（Verifiable Credential）を用いた自己主権的なユーザ認証を最小限の拡張で利用可能とするものである。

　本技術では、例えば図１に示すように検証主体である検証サーバが、依拠当事者であるアプリケーションから利用者（ユーザ）についてのVC検証要求を受け取ると、SessionID（セッションID）を含む招待コードを生成し、アプリケーションに返す。

　ここで、SessionIDは、検証サーバにおいて、検証サーバと利用者のスマートフォン等の装置との間におけるSSIネットワークでのDIDcomm接続を識別する一意なID情報（識別情報）である。

　また、利用者は、アプリケーションから提示された招待コードをスマートフォンのIDウォレットアプリケーションで読み取ることにより、アプリケーションが指定した検証サーバに接続することができる。

　このとき、既に検証サーバとのDIDcomm接続が行われている場合、すなわち、過去に検証サーバとのDIDcomm接続を行ったことがある場合には、そのDIDcomm接続が再利用される。これにより、利用者は、アプリケーションへのログインごとにDIDcomm接続手続きを行う必要がなくなる。すなわち、利用者の操作手順を少なくし、手間を省くことができる。

　また、利用者のIDウォレットアプリケーションは、DIDcomm接続を通じて検証サーバへと、招待コードから抽出したSessionIDを送信する。これにより、検証サーバでは、SessionIDによって、利用者とアプリケーションを対応付けることができる。換言すれば、検証サーバは、利用者がどのログイン画面に表示された招待コードをスキャンした（読み取った）のかを識別することができる。

　さらに、検証サーバは、DIDcomm接続が確立されると、利用者のスマートフォンに対して、ユーザ認証のためのSSI証明要求を送信する。

　すると、利用者のスマートフォンは、そのSSI証明要求に応じて、自身が保持しているVCに基づいてSSI証明を生成し、検証サーバに提示する。

　検証サーバは、提示されたSSI証明を検証することで、利用者が条件を満たすクレデンシャル（VC）を所有していることが検証できると、変換テーブルに基づいてIDトークンを生成する。すなわち、検証サーバは変換テーブルに基づいて、VCに基づく資格情報であるSSI証明を、そのSSI証明とは異なる形式の資格情報であるIDトークンへと変換（フォーマット変換）する。

　IDトークンは、OpenID Connectなど、一般的に広く普及しているプロトコルで利用されている資格情報である。

　検証サーバは、このようにして得られたIDトークンをアプリケーションに送信し、アプリケーションは、IDトークンを検証することで利用者（ユーザ）を認証し、利用者のログインが完了する。

　このようにすることで、アプリケーションは、VCを用いたユーザ認証を行うために、SSIのプロトコルを直接実装する必要が無いので、比較的簡単な仕組みで、すなわち最小限の拡張で自己主権的なユーザ認証を実現することができる。

　また、検証サーバは、利用者のスマートフォンについて、既に認証が完了しているDIDcomm接続に関する情報、つまりDIDcomm接続のための情報を記録しておくことで、２回目以降の認証処理を省略することができる。

　ここで、図２を参照して、中央集権的なID連携の手法と、SSIおよびIDトークンを組み合わせた本技術の手法とを対比して説明する。

　図２では、図中、上側にはIDトークンを利用する中央集権的なID連携の手法が示されている。このID連携の手法では、利用者は、認可プロバイダにログインし、認可プロバイダは、利用者の認証（ユーザ認証）を行い、利用者を識別するユーザID（UID）を得るとともに、利用者に対して認可コードを供給する。

　利用者は、このようにして得られた認可コードを、サービスの提供を受けようとする任意のアプリケーションへと供給し、アプリケーションはその認可コードを認可プロバイダに提示することで、認可プロバイダから利用者を識別するIDトークンを得る。

　そしてアプリケーションは、利用者のIDトークンをリソースサーバに送信することで、リソースサーバに記録されている、利用者へのサービスの提供に必要となる、利用者に関するデータ（リソース）へのアクセスの許可を得る。

　以上のようなID連携の手法では、IDトークンの発行者である認可プロバイダと、利用者の認証者であり、IDトークンを利用するアプリケーションとが利用者を介さずに接続される。そのため、上述のように利用者の個人情報の目的外の利用などのリスクがある。

　これに対して、図中、下側に示すように、SSIおよびIDトークンを組み合わせた本技術の手法では、利用者自身がVCを管理する。

　すなわち、利用者がVC発行サーバにログインすると、VC発行サーバは、利用者の認証を行ってユーザID（UID）を得ると、利用者に対してVC（クレデンシャル）を発行する。利用者は、発行されたVCを自身の装置のウォレットでセキュアに保持する。

　また、利用者は、任意のアプリケーションによるサービスの提供を受けるときには、保持しているVCに基づき生成されたSSI証明を検証サーバに対して提示する。

　すると、検証サーバは、提示されたSSI証明を検証し、SSI証明からIDトークンを生成してアプリケーションへと供給する。

　アプリケーションは、このようにして供給されたIDトークンを検証することで、利用者を認証し、利用者のIDトークンをリソースサーバに送信することで、リソースサーバに記録されている利用者に関するデータ（リソース）へのアクセスの許可を得る。

　以上のような本技術の手法では、VCの発行者であるVC発行サーバと、認証者であるアプリケーションとは直接接続されず、全て利用者を介した接続となる。これにより、自己主権的なユーザ認証が実現され、個人情報の目的外の利用などのリスクを低減させることができる。

　しかも、本技術の手法では、サービスの提供を行うアプリケーションは、広く普及しているIDトークンをそのまま利用することができるため、システム全体でみると、SSIとIDトークンを組み合わせるにあたり、最小限の変更で済む。

〈サービス提供システムの構成例〉
　続いて、本技術を適用したサービス提供システムについて説明する。

　図３は、本技術を適用したサービス提供システムの一実施の形態の構成例を示す図である。

　図３に示すサービス提供システムは、モバイル端末１１、ユーザ管理サイトアプリケーション１２、VC発行サーバ１３、サービスサイトアプリケーション１４、検証サーバ１５、リソースサーバ１６、およびSSIネットワーク１７を有している。

　この例では、モバイル端末１１、VC発行サーバ１３、および検証サーバ１５は、P2P（ピアツーピア）ネットワークであるSSIネットワーク１７を介して相互に接続されている。

　また、SSIネットワーク１７の構成要素としてSSIブロックチェーン２１やSSIメディエータエージェント２２が含まれている。

　例えばSSIブロックチェーン２１には、VC発行サーバ１３により発行されるVCに関する情報や、VC発行サーバ１３が保持する秘密鍵に対応する公開鍵などが記録される。

　SSIメディエータエージェント２２は、モバイル端末１１の通信の仲介を行う。すなわち、モバイル端末１１から送信された情報は、SSIネットワーク１７により、直接、VC発行サーバ１３や検証サーバ１５へと伝送される。これに対して、VC発行サーバ１３や検証サーバ１５から送信されたモバイル端末１１宛の情報は、一旦、SSIメディエータエージェント２２に保持されて、SSIメディエータエージェント２２からモバイル端末１１へと供給される。

　なお、この例ではユーザ管理サイトアプリケーション１２、サービスサイトアプリケーション１４、およびリソースサーバ１６は、SSIネットワーク１７には接続されていない。そのため、ユーザ管理サイトアプリケーション１２、サービスサイトアプリケーション１４、およびリソースサーバ１６には、SSIのプロトコルを直接実装する必要はない。

　モバイル端末１１は、ユーザ（利用者）が所有するスマートフォンやタブレットなどの情報処理装置からなり、記録部３１、読み取り部として機能するカメラ３２、SSIモバイルエージェント３３、通信部３４、および表示部３５を有している。

　例えばSSIモバイルエージェント３３は、モバイル端末１１の図示せぬCPU（Central Processing Unit）等が記録部３１に記録されているプログラムを実行することにより実現され、SSIネットワーク１７を介して行われるVCの発行やSSI証明の提示等に関する処理を実行する。このSSIモバイルエージェント３３は、例えば図１を参照して説明したIDウォレットアプリケーションに対応し、制御部として機能する。

　通信部３４は、SSIモバイルエージェント３３の指示に従って、DIDcomm接続を介した通信など、SSIネットワーク１７を介した通信を行う。また、通信部３４は、SSIネットワーク１７とは異なる他のネットワークを介してユーザ管理サイトアプリケーション１２やサービスサイトアプリケーション１４との通信を行う。

　ユーザ管理サイトアプリケーション１２は、例えばユーザが受けるサービスに関するVCの発行についてのユーザ管理サイトを運営するサーバ等の情報処理装置からなる。

　VC発行サーバ１３は、サーバ等の情報処理装置からなり、ユーザ管理サイトアプリケーション１２からの要求に応じて、ユーザに対してVCを発行する。

　VC発行サーバ１３により発行されるVCは、電子的に検証可能なデジタルの資格情報、すなわちデジタルな個人情報である。より詳細には、例えばVCは運転免許証、有資格証明書、学位証、保険証などに相当し、ユーザの氏名、年齢、住所などといった１または複数のクレデンシャル項目の情報（個人情報）から構成される。

　VC発行サーバ１３は、通信部４１、セッション管理部４２、SSIクラウドエージェント４３、および記録部４４を有している。

　例えば、セッション管理部４２およびSSIクラウドエージェント４３は、VC発行サーバ１３の図示せぬCPU等が、記録部４４に記録されているプログラムを実行することにより実現される。

　通信部４１は、SSIクラウドエージェント４３の指示に従って、DIDcomm接続を介した通信など、SSIネットワーク１７を介した通信を行う。また、通信部４１は、SSIネットワーク１７とは異なる他のネットワークを介してユーザ管理サイトアプリケーション１２との通信を行う。

　セッション管理部４２は、SSIネットワーク１７を介したモバイル端末１１（SSIモバイルエージェント３３）とのDIDcomm接続による通信（セッション）を管理する。

　SSIクラウドエージェント４３は、VC発行処理部として機能し、ユーザに対するVCの発行に関する処理を実行する。

　サービスサイトアプリケーション１４は、モバイル端末１１の所有者であるユーザに対して、所定のサービスを提供する。

　このときサービスサイトアプリケーション１４は、検証サーバ１５に対してユーザの認証を要求し、その要求に応じて発行された、OpenID Connect等で利用されているIDトークンを取得したり、IDトークンを利用してリソースサーバ１６にアクセスしたりする。

　検証サーバ１５は、例えばサーバ等の情報処理装置からなり、サービスサイトアプリケーション１４の要求に応じて、モバイル端末１１が提示するSSI証明に基づいてIDトークンを生成（発行）し、サービスサイトアプリケーション１４に供給する。

　検証サーバ１５は、通信部５１、セッション管理部５２、SSIクラウドエージェント５３、IDトークン生成部５４、および記録部５５を有している。

　例えば、セッション管理部５２、SSIクラウドエージェント５３、IDトークン生成部５４は、検証サーバ１５の図示せぬCPU等が、記録部５５に記録されているプログラムを実行することにより実現される。

　通信部５１は、SSIクラウドエージェント５３の指示に従って、例えばDIDcomm接続を介した通信など、SSIネットワーク１７を介した通信を行う。また、通信部５１は、SSIネットワーク１７とは異なる他のネットワークを介してサービスサイトアプリケーション１４との通信を行う。

　セッション管理部５２は、SSIネットワーク１７を介したモバイル端末１１（SSIモバイルエージェント３３）とのDIDcomm接続による通信（セッション）を管理する。

　SSIクラウドエージェント５３は、証明検証部として機能し、ユーザに対するSSI証明の要求や検証に関する処理を実行する。

　IDトークン生成部５４は、ユーザにより提示されたSSI証明に基づいて、そのSSI証明に対応するIDトークンを生成する。

　リソースサーバ１６は、ユーザに関する各種のデータ（リソース）を記録しており、IDトークンの提示に応じて、サービスサイトアプリケーション１４に対して、記録しているデータを供給する。

　以上のようなサービス提供システムでは、ユーザがサービスの提供を受けるときには、大まかに、以下の処理が行われる。

　すなわち、まず、ユーザはVC発行サーバ１３から必要なVCの発行を受ける。

　具体的にはユーザ（利用者）は、自身のモバイル端末１１を操作してユーザ管理サイトアプリケーション１２のユーザ管理サイトへ、ユーザ自身に関する利用者情報を入力することで、VC発行サーバ１３に対してVCの発行を要求することができる。

　この場合、ユーザ管理サイトアプリケーション１２は、VC発行サーバ１３に対して、ユーザにより入力された利用者情報を供給するとともにVCの発行の要求を行うと、一意なSessionIDを含む招待コードをVC発行サーバ１３から受信し、招待コードを提示する。

　すると、モバイル端末１１は、提示された招待コードをカメラ３２により読み取り、読み取った招待コードに基づいてVC発行サーバ１３にDIDcomm接続する。

　VC発行サーバ１３とのDIDcomm接続が確立すると、モバイル端末１１は、招待コードに含まれているSessionIDをVC発行サーバ１３へと送信する。

　VC発行サーバ１３は、モバイル端末１１から受信したSessionIDを利用して、モバイル端末１１（SSIモバイルエージェント３３）、すなわちユーザと、ユーザの利用者情報、つまりVCの発行を要求したユーザ管理サイトアプリケーション１２との対応付けを行う。

　VC発行サーバ１３は、利用者情報を含むVCを生成し、そのVCをモバイル端末１１に送信する。すなわち、モバイル端末１１（ユーザ）に対してVCが発行される。

　VCが発行されると、ユーザは、そのVCを利用して、サービスサイトアプリケーション１４からサービスの提供を受けることができる。

　具体的には、モバイル端末１１がログインのためにサービスサイトアプリケーション１４へとアクセスすると、サービスサイトアプリケーション１４は、検証サーバ１５へとアクセスして、一意なSessionIDを含む招待コードを受信し、その招待コードをユーザに対して提示する。

　すると、モバイル端末１１は、提示された招待コードをカメラ３２により読み取り、読み取った招待コードに基づいて検証サーバ１５にDIDcomm接続する。

　検証サーバ１５とのDIDcomm接続が確立すると、モバイル端末１１は、招待コードに含まれているSessionIDを検証サーバ１５へと送信する。

　検証サーバ１５は、モバイル端末１１から送信されてくるSessionIDを利用して、モバイル端末１１（SSIモバイルエージェント３３）、すなわちユーザと、サービスサイトアプリケーション１４との対応付けを行う。

　また、検証サーバ１５は、モバイル端末１１（SSIモバイルエージェント３３）に対して、サービスサイトアプリケーション１４、すなわちサービスサイトアプリケーション１４が運営するサービスサイトへのログインに必要なSSI証明の提示を要求する。

　モバイル端末１１は、検証サーバ１５からの要求に応じて、自身が保持しているVCを用いて、要求されたSSI証明を生成し、検証サーバ１５に対して提示する。

　検証サーバ１５は、モバイル端末１１により提示されたSSI証明を検証し、その検証の証としてIDトークンを生成してサービスサイトアプリケーション１４に送信する。すなわち、SSI証明に基づいて、サービスサイトアプリケーション１４に対し、ユーザのIDトークンが発行される。

　サービスサイトアプリケーション１４は、検証サーバ１５により発行されたIDトークンを検証することで、ユーザ認証を行い、ユーザ（利用者）のログインが完了する。

　その後、サービスサイトアプリケーション１４は、IDトークンをリソースサーバ１６に送信（提示）することで、リソースサーバ１６に記録されている、ユーザに対するサービスの提供に必要となる、ユーザに関するデータ（リソース）へのアクセス権を取得する。

　そして、サービスサイトアプリケーション１４は、リソースサーバ１６から必要なデータを読み出し、読み出したデータ等に基づいて、ユーザ（モバイル端末１１）に対して所定のサービスを提供する。

〈VC発行時の処理の説明〉
　次に、サービス提供システムにおいて行われる処理について、より具体的に説明する。

　まず、図４および図５に示すフローチャートを参照して、VC発行時にモバイル端末１１、VC発行サーバ１３、およびユーザ管理サイトアプリケーション１２により行われる処理について説明する。特に図５には、図４に示すフローチャートの続きが示されている。

　まず、ステップＳ１１においてユーザ管理サイトアプリケーション１２のVC発行アプリケーションは、モバイル端末１１によるVCデータの入力を受け付ける。なお、VCデータの入力は、例えばDesktopアプリケーションなど、モバイル端末１１とは異なる他の端末等により行われるようにしてもよい。

　例えば、モバイル端末１１は、ユーザを識別する任意のユーザIDを含むVCの発行を受けるために、ユーザ管理サイトにアクセスする。

　そして、例えばユーザは、モバイル端末１１とユーザ管理サイトアプリケーション１２とが接続された状態で、モバイル端末１１を操作し、ユーザID等を含む、ユーザ自身に関する情報（個人情報）を含む利用者情報をVCデータとして入力する。

　すると、モバイル端末１１の通信部３４からユーザ管理サイトアプリケーション１２には、ユーザにより入力されたVCデータが供給（送信）されるので、ユーザ管理サイトアプリケーション１２のVC発行アプリケーションは、VCデータを取得（受信）して一時的に保持する。なお、ここでは一例として、利用者情報等のVCデータがモバイル端末１１により入力される例について説明したが、これに限らず、例えばDesktopアプリケーションなど、モバイル端末１１とは異なる他の端末等によりVCデータが入力されてもよい。

　ステップＳ１２においてユーザ管理サイトアプリケーション１２は、VCの発行を行うために、入力されたVCデータ（利用者情報）と、DIDcomm接続の確立のための招待コードの発行を要求する招待コード要求とをVC発行サーバ１３に送信する。この招待コード要求により、VCの発行が要求されたことになる。

　例えばユーザ管理サイトアプリケーション１２は、ユーザ管理サイトアプリケーション１２を識別するクライアントIDと、ユーザ管理サイトアプリケーション１２（クライアント）に発行された認証コードであるクライアントシークレットとを予め記録している。

　そしてユーザ管理サイトアプリケーション１２は、例えば図６に示すように、予め記録しているクライアントIDおよびクライアントシークレットと、応答先アドレスとを含む招待コード要求を生成する。

　この例では、クライアントIDは、VC発行サーバ１３から見て、接続元のクライアントとなるユーザ管理サイトアプリケーション１２を識別する識別子となっている。また、応答先アドレスは、招待コード要求に対する応答の送信先のアドレスを示しており、この例ではユーザ管理サイトアプリケーション１２のアドレスが応答先アドレスとされる。

　図４のフローチャートの説明に戻り、ステップＳ３１においてVC発行サーバ１３の通信部４１は、ユーザ管理サイトアプリケーション１２から送信されてきたVCデータ（利用者情報）と招待コード要求を受信する。

　ステップＳ３２においてVC発行サーバ１３のセッション管理部４２は、ステップＳ３１で受信した招待コード要求に基づいて、招待コードとセッション情報を生成する。

　例えばVC発行サーバ１３は、クライアントである各ユーザ管理サイトアプリケーション１２に対して一意なクライアントIDを付与し、VC発行サーバ１３の記録部４４には、例えば図７に示すように、予めクライアントごとの設定情報が記録されている。

　図７の例では、設定情報には、設定ID、クライアントID、送信先アドレス、および招待コード設定が設定項目として含まれている。

　設定IDは、クライアント（ユーザ管理サイトアプリケーション１２）に関する設定、すなわち設定情報ごとに発行される一意なIDである。

　クライアントIDは、設定情報が適用されるユーザ管理サイトアプリケーション１２を示すID（識別子）であり、このクライアントIDが招待コード要求に含まれている。

　また、送信先アドレスは、ユーザ管理サイトアプリケーション１２（クライアント）からの要求に対する応答の送信先のアドレス、つまりクライアントの応答受信アドレスを示している。より詳細には、招待コード要求の生成時には、この送信先アドレスが、招待コード要求に含まれている応答先アドレスの一部となるようにされる。これにより、不正なアドレス指定によって外部に情報が漏洩してしまうことが防止される。

　さらに、招待コード設定には、VC発行サーバ１３とのDIDcomm接続の表示名を示すラベル、DIDcomm接続を表すアイコン画像のアドレス、およびDIDcomm接続のために発行された招待コードの有効期間を示す情報が設定項目として含まれている。

　VC発行サーバ１３では、クライアントIDごと、つまりクライアントごとに設定情報として個別の設定を行うことが可能である。

　また、VC発行サーバ１３では、招待コード要求に対する応答処理など、VC発行サーバ１３のAPI（Application Programming Interface）を実行する際には、クライアントIDと、そのクライアントIDごとに発行されるクライアントシークレットを送信しなければならない。また、それらのクライアントIDとクライアントシークレットの値が正しくなければ、要求されたAPIの実行は許可されない。

　そのため、セッション管理部４２は、ユーザ管理サイトアプリケーション１２からの招待コード要求に含まれているクライアントIDおよびクライアントシークレットと、記録部４４に記録されている設定情報とに基づいてユーザ管理サイトアプリケーション１２を認証する。

　ユーザ管理サイトアプリケーション１２の認証が行われると、セッション管理部４２は、記録部４４に記録されている設定情報に基づいて、例えば図８に示す招待コードを生成する。

　図８の例では、招待コードには、接続先アクセス情報、接続先名称、SessionID、およびSessionIDの有効期限が含まれている。

　接続先アクセス情報は、VC発行サーバ１３とのDIDcomm接続に必要なコード（招待コード）であり、アクセス先であるVC発行サーバ１３のアドレスが含まれている。

　接続先名称は、DIDcomm接続の接続先の名称、すなわち、この例ではVC発行サーバ１３の名称を示す情報であり、セッション管理部４２は、設定情報に含まれているラベルを、そのまま接続先名称として招待コードに格納する。

　SessionIDは、VC発行サーバ１３とのDIDcomm接続を一意に識別するID情報（識別情報）である。セッション管理部４２は、後述するセッション情報に含まれるSessionIDと、そのSessionIDの有効期限とを、そのまま招待コードに格納する。

　また、セッション管理部４２は、必要に応じて、記録部４４に記録されている設定情報に含まれているアイコン画像のアドレスも招待コードに格納する。

　以上のような招待コードの実際の一例を図９に示す。この例では、「c_i」により示される部分、すなわち「c_i」の値がDIDcomm接続で規定されている接続先アクセス情報（接続情報）を示している。また、「sid」の値がSessionIDを示しており、「exp」の値がSessionIDの有効期限を示している。

　また、セッション管理部４２は、記録部４４に記録されている設定情報に基づいてセッション情報も生成する。

　セッション情報は、SSIネットワーク１７でのDIDcomm接続に関する情報であり、例えば図１０に示す情報などとされる。

　この例ではセッション情報には、SessionID、クライアントID、作成日時、有効期限、ConnectionID（コネクションID）、および交換IDが含まれている。

　例えばセッション管理部４２は、ステップＳ３１で受信した招待コード要求に含まれているクライアントIDをそのままセッション情報に格納し、現在日時をセッション情報の作成日時とする。また、セッション管理部４２は、現在日時（作成日時）に対して、記録部４４に記録されている設定情報内の招待コード設定における有効期間を加えることで得られる値（日時）を、セッション情報の有効期限としてセッション情報に格納する。

　なお、図１０の例ではセッション情報にはConnectionIDと交換IDが含まれているが、ステップＳ３２では、これらのConnectionIDと交換IDが含まれていないセッション情報が生成される。

　ConnectionIDは、接続先とのDIDcomm接続を介した通信に用いられ、その接続先とのDIDcomm接続を一意に識別するID（識別情報）である。ConnectionIDには接続先アクセス情報における場合と同様のDIDcomm接続の接続先のアドレスが含まれている。

　また、交換IDは、後述するように、ユーザの認証要求の作成時に検証サーバ１５により発行され、SSI証明の提示に付されるIDであり、VC発行サーバ１３において生成されるセッション情報には含まれていない。

　セッション管理部４２は、以上のようにして招待コードとセッション情報を生成すると、SSIクラウドエージェント４３を介して通信部４１に招待コードを供給するとともに、セッション情報を記録部４４に供給して記録させる。

　図４のフローチャートの説明に戻り、ステップＳ３３においてVC発行サーバ１３の通信部４１は、ステップＳ３２で生成された招待コードをユーザ管理サイトアプリケーション１２に送信する。

　すると、ステップＳ１３においてユーザ管理サイトアプリケーション１２は、VC発行サーバ１３により送信された、SessionIDを含む招待コードを受信する。

　ステップＳ１４においてユーザ管理サイトアプリケーション１２は、ステップＳ１３で受信した招待コードをモバイル端末１１、すなわちユーザに対して提示する。

　ステップＳ６１においてモバイル端末１１のSSIモバイルエージェント３３は、適宜、カメラ３２等を制御して、ユーザ管理サイトアプリケーション１２により提示された招待コードを読み取る（スキャンする）。

　例えば招待コードがQR（Quick Response）コード（登録商標）などのバーコードとしてユーザ管理サイトアプリケーション１２の表示画面に表示された場合、SSIモバイルエージェント３３は、カメラ３２にそのバーコードを撮像させることにより招待コードを読み取る。

　なお、招待コードがバーコードとして紙媒体等に印刷されており、カメラ３２がそのバーコードを撮像することにより、招待コードを読み取るようにしてもよい。

　その他、招待コードの読み取り方法は、バーコードを読み取る方法に限らず、他のどのような方法であってもよい。

　例えばモバイル端末１１の表示部３５の画面上に表示されたボタンが押されると、Deep linkを介してSSIモバイルエージェント３３が起動し、招待コードが読み取られるようにしてもよい。また、モバイル端末１１がユーザ管理サイトアプリケーション１２から受信した電子メールやSMS（Short Message Service）等のメッセージから、Deep linkを介してSSIモバイルエージェント３３が起動し、招待コードが読み取られるようにしてもよい。

　さらに、招待コード読み取り用のRFID（Radio Frequency IDentification）タグやユーザ管理サイトアプリケーション１２等のNFC（Near Field Communication）ポートに、モバイル端末１１としてのスマートフォン等をかざすことにより、無線通信で招待コードが読み取られるようにしてもよい。招待コード読み取り時の無線通信は、Bluetooth（登録商標）やWiFi direct（登録商標）などにより行われてもよい。

　その他、招待コードは、ユーザ管理サイトアプリケーション１２により、IR（Infrared）通信などの光通信や可視光通信により送信されてもよい。そのような場合、モバイル端末１１としてのスマートフォン等は、通信部３４としてのIR受光部や他の受光部、カメラ３２等によって、送信されてきた招待コードを受信することで招待コードを読み取る。

　さらに招待コードは、スピーカ等により音声信号として送信され、モバイル端末１１側でのマイクロフォンによる収音によって読み取られるようにしてもよいし、USB（Universal Serial Bus）（登録商標）などの有線接続を介してモバイル端末１１へと送信されるようにしてもよい。

　ステップＳ６２においてモバイル端末１１のSSIモバイルエージェント３３は、適宜、記録部３１に記録されている情報を参照し、読み取られた招待コードの内容を確認することで、既にVC発行サーバ１３とのDIDcomm接続が確立済みであるかを確認する。

　例えば、DIDcomm接続が確立済みであるかの確認（特定）は、ステップＳ６１で読み取られた招待コードに基づき行われる。

　具体的には、例えばSSIモバイルエージェント３３は、招待コードに含まれている接続先アクセス情報や接続先名称と、記録部３１に記録されている過去のDIDcomm接続に関する記録（情報）とから、過去にモバイル端末１１がVC発行サーバ１３とDIDcomm接続を行っていることが確認された場合、DIDcomm接続が確立済みであるとする。

　例えば記録部３１には、過去のDIDcomm接続に関する記録としてConnectionID等が記録されており、ConnectionIDにより示されるアドレスと、招待コードの接続先アクセス情報により示されるアドレスが一致する場合、DIDcomm接続が確立済みであるとされる。

　ステップＳ６２においてDIDcomm接続が確立済みであると確認（判定）された場合、その後、ステップＳ６３およびステップＳ６４の処理は行われず、処理はステップＳ６５へと進む。

　このとき、SSIモバイルエージェント３３は、記録部３１に記録されているConnectionID等の過去のDIDcomm接続に関する情報を再利用して、VC発行サーバ１３にDIDcomm接続する。すなわち、既に確立されているVC発行サーバ１３とのDIDcomm接続が再利用される。

　一方、ステップＳ６２においてDIDcomm接続が確立済みでないことが確認された場合、すなわち、過去に一度もVC発行サーバ１３にDIDcomm接続したことがない場合には、ステップＳ６３およびステップＳ６４の処理が行われ、DIDcomm接続が確立される。このとき、VC発行サーバ１３では、ステップＳ６３およびステップＳ６４の処理に応じて、ステップＳ３４およびステップＳ３５の処理が行われる。

　具体的には、表示部３５は、招待コードに基づいて、VC発行サーバ１３とのDIDcomm接続を行うための接続確認画面を表示する。この接続確認画面には、例えば招待コードに含まれている接続先名称や、アイコン画像、接続の可否の確認のための確認ボタンなどが表示される。

　ユーザが表示された接続確認画面を確認し、モバイル端末１１を操作することで確認ボタンを押すと、ステップＳ６３の処理が行われる。

　ステップＳ６３においてSSIモバイルエージェント３３は、適宜、記録部３１に記録されているモバイル端末１１、すなわちユーザに関する情報を読み出して、読み出した情報からDIDcomm接続要求を生成し、そのDIDcomm接続要求を通信部３４により送信する。

　例えばDIDcomm接続要求は、モバイル端末１１の識別名を示すラベルと、モバイル端末１１のDIDおよびアクセス情報とを含むメッセージからなる。

　メッセージに含まれるDIDは、SSIブロックチェーン２１で管理され、SSIネットワーク１７におけるVC発行サーバ１３とのDIDcomm接続において、モバイル端末１１を一意に識別するID（識別情報）である。

　また、モバイル端末１１のアクセス情報は、例えばDIDcomm接続においてモバイル端末１１との通信（アクセス）に必要となる情報であって、モバイル端末１１の公開鍵などが含まれるDID documentなどとされる。

　さらに、より詳細には、招待コードにはVC発行サーバ１３の公開鍵が含まれている。SSIモバイルエージェント３３は、モバイル端末１１のラベル、DID、およびアクセス情報を含むメッセージを、VC発行サーバ１３の公開鍵で暗号化してDIDcomm接続要求を生成し、通信部３４に供給する。

　通信部３４は、SSIモバイルエージェント３３から供給されたDIDcomm接続要求を、SSIネットワーク１７を介してVC発行サーバ１３に送信する。

　すると、ステップＳ３４においてVC発行サーバ１３の通信部４１は、モバイル端末１１から送信されてきたDIDcomm接続要求を受信する。

　セッション管理部４２は、受信されたDIDcomm接続要求のメッセージを、記録部４４に記録されているVC発行サーバ１３の秘密鍵で復号することで、DIDcomm接続要求からモバイル端末１１のラベル、DID、およびアクセス情報を抽出する。これらのラベル、DID、およびアクセス情報は、適宜、記録部４４に供給され、記録されてもよい。

　また、セッション管理部４２は、DIDcomm接続要求に応じて、適宜、記録部４４から必要な情報を読み出し、VC発行サーバ１３の識別名を示すラベルと、VC発行サーバ１３のDIDおよびアクセス情報とを含むメッセージからなるDIDcomm接続応答を生成する。

　このとき、セッション管理部４２は、DIDcomm接続要求から抽出したモバイル端末１１のアクセス情報（公開鍵）に基づいて、DIDcomm接続応答のメッセージを暗号化する。また、セッション管理部４２は、生成したDIDcomm接続応答を通信部４１に供給する。

　なお、DIDcomm接続応答のメッセージに含まれているラベル、DID、およびアクセス情報は、DIDcomm接続要求に含まれているラベル、DID、およびアクセス情報と同様のものである。したがって、例えばVC発行サーバ１３のDIDは、SSIブロックチェーン２１で管理され、SSIネットワーク１７におけるモバイル端末１１とのDIDcomm接続において、VC発行サーバ１３を一意に識別するIDである。

　ステップＳ３５において通信部４１は、セッション管理部４２から供給されたDIDcomm接続応答を、SSIネットワーク１７を介してモバイル端末１１に送信する。

　すると、ステップＳ６４においてモバイル端末１１の通信部３４は、VC発行サーバ１３から送信されてきたDIDcomm接続応答を受信し、SSIモバイルエージェント３３に供給する。

　SSIモバイルエージェント３３は、受信されたDIDcomm接続応答のメッセージを、記録部３１に記録されているモバイル端末１１の秘密鍵で復号することで、DIDcomm接続応答からVC発行サーバ１３のラベル、DID、およびアクセス情報を抽出する。これらのラベル、DID、およびアクセス情報は、適宜、記録部３１に供給され、記録されてもよい。

　以上の処理により、モバイル端末１１とVC発行サーバ１３との間で、DIDcomm接続に用いる接続相手のDIDや、公開鍵を含むアクセス情報が交換され、DIDcomm接続、すなわちDIDcommの暗号化された接続が確立されたことになる。DIDcommとは、SSIネットワーク１７上に確立される暗号化された安全な通信経路である。

　なお、上述した過去（既存）のDIDcomm接続が再利用される場合、過去のDIDcomm接続に関する情報として、記録部３１に記録されているVC発行サーバ１３のラベル、DID、アクセス情報も適宜、DIDcomm接続を介した通信に再利用される。

　この場合、VC発行サーバ１３側においても、記録しているセッション情報や、後述する接続情報などから、モバイル端末１１とのDIDcomm接続が確立済みであることを確認することができ、モバイル端末１１とのDIDcomm接続が再利用される。すなわち、セッション管理部４２は、セッション情報や接続情報などのDIDcomm接続に関する情報を再利用して、モバイル端末１１とのDIDcomm接続を行う。

　DIDcomm接続が確立されると、以降においてはモバイル端末１１とVC発行サーバ１３との間の通信は、DIDcommを介して行われる。

　また、モバイル端末１１とVC発行サーバ１３の間でDIDcomm接続が確立されると、VC発行サーバ１３では、ステップＳ３６の処理が行われ、DIDcomm接続情報が更新される。

　すなわち、VC発行サーバ１３のセッション管理部４２は、現時点においてVC発行サーバ１３とDIDcomm接続されている複数のモバイル端末のリストを、DIDcomm接続情報として保持している。

　ステップＳ３６では、セッション管理部４２は、保持しているリストに、今回、新たにDIDcomm接続を開始したモバイル端末１１、より詳細にはモバイル端末１１のアドレスを追加することでDIDcomm接続情報（リスト）を更新する。

　また、このときセッション管理部４２は、モバイル端末１１とVC発行サーバ１３の間でのDIDcomm接続に関する情報である接続情報を生成して記録部４４に供給し、記録させる。なお、接続情報が既に記録部４４に記録されている場合には、ステップＳ３６において、適宜、接続情報が更新される。その他、接続情報は、後述するステップＳ３８のタイミング等で生成されるようにしてもよい。

　例えばセッション管理部４２は、モバイル端末１１との間で確立されたDIDcomm接続に関するDIDcomm接続要求やDIDcomm接続応答のメッセージに基づいて、図１１に示す接続情報を生成する。

　この例では、接続情報には、モバイル端末１１とVC発行サーバ１３とのDIDcomm接続を一意に識別するConnectionID、接続先識別子、接続先名称、接続元識別子、および接続状態が含まれている。

　接続先識別子および接続先名称は、VC発行サーバ１３から見たDIDcomm接続の接続先であるモバイル端末１１（ユーザ）のDIDおよび表示名を示している。したがって、この例では、DIDcomm接続要求に含まれているモバイル端末１１のDIDおよびラベルが、そのまま接続先識別子および接続先名称として用いられる。

　また、接続情報における接続元識別子は、DIDcomm接続の接続元、つまりVC発行サーバ１３自身のモバイル端末１１とのDIDcomm接続におけるDIDを示している。したがって、この例ではDIDcomm接続応答に含まれているVC発行サーバ１３のDIDが、そのまま接続元識別子として用いられる。

　さらに、接続情報における接続状態は、例えば接続中や非接続（接続停止）など、現時点におけるDIDcomm接続の状態（ステータス）を示している。

　ステップＳ６５においてモバイル端末１１の通信部３４は、DIDcomm接続を介して、SessionIDを含む開始要求をVC発行サーバ１３に送信する。

　例えばSSIモバイルエージェント３３は、ステップＳ６１で読み取った（受信した）招待コード内のSessionIDを含み、DIDcomm接続を介したVCの発行のための通信（処理）の開始を要求する開始要求を生成し、その開始要求を通信部３４に供給する。

　この場合、SSIモバイルエージェント３３は、例えば図１２に示す開始要求を生成する。なお、図１２の例では、開始要求には、SessionIDおよび認証保存フラグが含まれているが、より詳細には、ステップＳ６５の実行時にSSIモバイルエージェント３３により生成される開始要求には認証保存フラグは含まれていない。

　認証保存フラグは、後述するように、検証サーバ１５において、記録済みであるユーザ（モバイル端末１１）の認証のための認証情報を削除するか否かを示すフラグ情報である。

　また、開始要求が生成されると、通信部３４は、SSIモバイルエージェント３３から供給された開始要求をVC発行サーバ１３に送信する。このとき通信部３４は、ステップＳ６１で取得した招待コードの接続先アクセス情報により示されるVC発行サーバ１３のアドレスを宛先として、開始要求の送信を行う。

　すると、ステップＳ３７においてVC発行サーバ１３の通信部４１は、モバイル端末１１から送信されてきた開始要求を受信する。

　これにより、招待コードを読み取ったDIDcomm接続の接続先の装置であるモバイル端末１１から、その招待コードに含まれているSessionIDを受信したことになる。

　ステップＳ３８においてVC発行サーバ１３のセッション管理部４２は、受信した開始要求に応じて、接続情報のConnectionIDをセッション情報に追加して保存する。

　すなわち、セッション管理部４２は、受信した開始要求に含まれているSessionIDと、ステップＳ３２で生成され、記録部４４に記録されているセッション情報に含まれているSessionIDとが一致することを確認する。

　次に、セッション管理部４２は、現時点で行われているDIDcomm接続を一意に識別する接続情報のConnectionIDを、ステップＳ３２で生成したセッション情報に追加し、ConnectionIDが追加された（含まれた）セッション情報を記録部４４に記録させる。

　但し、既にセッション情報にConnectionIDが記録されていた場合には、ステップＳ３８の処理は行われない。また、上述のようにセッション情報には、有効期限が設定されており、その有効期限が過ぎたセッション情報は無効とされ、セッション管理部４２によって記録部４４から削除される。

　以上の処理によってVC発行サーバ１３では、セッション情報によって、クライアントIDと、SessionIDと、ConnectionIDとの対応付けができたことになる。

　例えばステップＳ３１においてクライアントID「A01」を含む招待コード要求が受信され、ステップＳ３３でSessionID「S02」を含む招待コードが送信され、モバイル端末１１との間でConnectionID「C03」により識別されるDIDcomm接続が確立されたとする。

　そのような場合、ステップＳ３８では、クライアントID「A01」、SessionID「S02」、およびConnectionID「C03」を含むセッション情報が得られる。

　換言すれば、セッション管理部４２によって、クライアントID「A01」、SessionID「S02」、およびConnectionID「C03」が対応付けられて記録されたことになる。

　これにより、VC発行サーバ１３では、開始要求を送信したモバイル端末１１と、VCの発行を要求してきたユーザ管理サイトアプリケーション１２とを紐づけることができる。したがって、VC発行サーバ１３では、ユーザが複数のユーザ管理サイトアプリケーション１２のうちのどのユーザ管理サイトアプリケーション１２の招待コードを読み取ったのかを特定することができる。

　図４から図５の説明へと移り、ステップＳ３９においてSSIクラウドエージェント４３は、開始要求を送信してきた、セッション情報のConnectionIDにより一意に識別される接続先、すなわちモバイル端末１１に対してSSIクレデンシャル提案を生成する。

　例えばSSIクラウドエージェント４３は、ステップＳ３１で受信されたVCデータ（利用者情報）に基づいて、ユーザ管理サイトアプリケーション１２が提供するサービスごとなどに定められた定義情報に従ったフォーマットのVCをSSIクレデンシャル提案として生成する。SSIクラウドエージェント４３は、生成したSSIクレデンシャル提案を通信部４１に供給する。

　例えば定義情報では、VCに含まれるべきクレデンシャル項目等の情報や、VCのデータ構造などが定められている。

　SSIクレデンシャル提案（VC）には、例えばユーザID等のVCデータ（利用者情報）に含まれるユーザの個人情報などがクレデンシャル項目として含まれている。また、SSIクレデンシャル提案は、VC発行サーバ１３の秘密鍵により署名されており、クレデンシャル項目ごとに暗号的に検証可能な状態となっている。

　ステップＳ４０において通信部４１は、SSIメディエータエージェント２２を介して、ステップＳ３９で生成されたSSIクレデンシャル提案をモバイル端末１１に送信する。

　なお、VC発行サーバ１３は、SSIクレデンシャル提案の送信後、SSIクレデンシャル提案を行った旨のイベント通知をユーザ管理サイトアプリケーション１２に対して行うようにしてもよい。そうすることで、ユーザ管理サイトアプリケーション１２は、VC発行に関する処理が開始されたことを、ユーザ（モバイル端末１１）に通知（提示）することができる。

　ステップＳ６６においてモバイル端末１１の通信部３４は、VC発行サーバ１３から送信されてきたSSIクレデンシャル提案を受信する。

　ステップＳ６７においてSSIモバイルエージェント３３は、受信したSSIクレデンシャル提案を表示部３５に供給し、ユーザに対してSSIクレデンシャル提案を提示（表示）させることで、そのSSIクレデンシャル提案の内容の確認を促す。すなわち、提案されたVC（SSIクレデンシャル提案）の内容に誤りがなく、このままVC発行の処理を継続してよいかの確認（同意）が求められる。

　ユーザがモバイル端末１１を操作し、処理の継続に同意すると、SSIモバイルエージェント３３は、SSIクレデンシャル提案の内容でのVCの発行を要求するクレデンシャル要求を生成し、通信部３４に供給する。

　ステップＳ６８において通信部３４は、SSIモバイルエージェント３３から供給されたクレデンシャル要求を、DIDcomm接続を介してVC発行サーバ１３に送信する。

　すると、ステップＳ４１においてVC発行サーバ１３の通信部４１は、モバイル端末１１から送信されてきたクレデンシャル要求を受信する。

　ステップＳ４２においてSSIクラウドエージェント４３は、クレデンシャル要求に応じて、モバイル端末１１、すなわちユーザに対してVC（SSIクレデンシャル）を発行する。

　具体的には、例えばSSIクラウドエージェント４３は、ステップＳ３９で生成したSSIクレデンシャル提案をそのまま最終的なVCとして発行し、通信部４１に供給する。

　また、SSIクラウドエージェント４３は、例えばVC発行サーバ１３のモバイル端末１１とのDIDcomm接続におけるDIDや公開鍵、定義情報、リボケーションリストなどといった、発行したVCに関する情報をSSIブロックチェーン２１に登録（記録）する。

　ステップＳ４３において通信部４１は、ステップＳ４２で発行されたVC（SSIクレデンシャル）を、SSIメディエータエージェント２２を介してモバイル端末１１に送信する。

　なお、VC発行サーバ１３は、VCの送信後、VCを発行した旨のイベント通知をユーザ管理サイトアプリケーション１２に対して行うようにしてもよい。そうすることで、ユーザ管理サイトアプリケーション１２は、VCが発行されたことを、ユーザ（モバイル端末１１）に通知（提示）することができる。

　ステップＳ６９においてモバイル端末１１の通信部３４は、VC発行サーバ１３から送信されてきたVCを受信する。

　そしてステップＳ７０においてSSIモバイルエージェント３３は、受信したVCを記録部３１、より詳細には記録部３１におけるウォレットに供給し、記録させる。

　以上の処理により、VC発行サーバ１３によってモバイル端末１１に対してVCが発行されたことになり、VC発行時にユーザ管理サイトアプリケーション１２、VC発行サーバ１３、およびモバイル端末１１により行われる処理は終了する。

　以上のようにしてモバイル端末１１およびVC発行サーバ１３は、DIDcomm接続を介して通信を行う場合に、既に（過去に）DIDcomm接続が確立されているときには、そのDIDcomm接続を再利用する。これにより、ユーザは、DIDcomm接続（ログイン）を行うたびに新規接続の手順を実行する必要がなくなるので、より簡単に自己主権的なユーザ認証を実現することができる。

　しかも、図３に示したサービス提供システムでは、ユーザ管理サイトアプリケーション１２にSSIのプロトコルを直接実装する必要がなく、VC発行サーバ１３においてセッション情報によりモバイル端末１１とユーザ管理サイトアプリケーション１２とを紐づける（対応付ける）ことができる。これにより、さらに簡単な仕組みで自己主権的なユーザ認証を実現することができる。

〈SSI証明を用いた認証時の処理の説明〉
　続いて、ユーザがサービスサイトアプリケーション１４により提供されるサービスを受けるときに行われる処理について説明する。

　すなわち、以下、図１３および図１４に示すフローチャートを参照して、SSI証明を用いた認証時にモバイル端末１１、検証サーバ１５、およびサービスサイトアプリケーション１４により行われる処理について説明する。特に図１４には、図１３に示すフローチャートの続きが示されている。

　また、ステップＳ２０１乃至ステップＳ２０３、ステップＳ２３１乃至ステップＳ２３８、およびステップＳ２６１乃至ステップＳ２６５の処理は、図４のステップＳ１２乃至ステップＳ１４、ステップＳ３１乃至ステップＳ３８、およびステップＳ６１乃至ステップＳ６５の処理と同様であるため、ここではそれらの処理については、簡単に説明する。

　まず、モバイル端末１１は、サービスサイトアプリケーション１４により運営されるサービスサイトへのログインのため、サービスサイトアプリケーション１４にアクセスし、ログインページを開く（表示させる）。

　すると、ステップＳ２０１においてサービスサイトアプリケーション１４のサービス提供のためのアプリケーションは、ユーザ認証を行うために、DIDcomm接続の確立のための招待コードの発行を要求する招待コード要求を検証サーバ１５に送信する。

　例えばサービスサイトアプリケーション１４は、図６に示した招待コード要求を送信する。これにより、検証サーバ１５に対してユーザの認証、より詳細にはユーザが有するVCから生成されるSSI証明の検証が要求されたことになる。

　なお、この場合、招待コード要求に含まれるクライアントIDやクライアントシークレット、応答先アドレスは、サービスサイトアプリケーション１４のものとされる。

　ステップＳ２３１において検証サーバ１５の通信部５１は、サービスサイトアプリケーション１４から送信されてきた招待コード要求を受信する。

　ステップＳ２３２において検証サーバ１５のセッション管理部５２は、受信した招待コード要求に基づいて、招待コードとセッション情報を生成する。

　例えば検証サーバ１５は、クライアントである各サービスサイトアプリケーション１４に対して一意なクライアントIDを付与し、検証サーバ１５の記録部５５には、例えば図１５に示すように、予めクライアントごとの設定情報が記録されている。

　図１５の例では、設定情報には、設定ID、クライアントID、送信先アドレス、招待コード設定、証明要求設定、およびIDトークン設定が設定項目として含まれている。

　設定IDは、クライアント（サービスサイトアプリケーション１４）の設定情報ごとに発行される一意なIDである。また、クライアントIDは、設定情報が適用されるサービスサイトアプリケーション１４を示すID（識別子）であり、このクライアントIDが招待コード要求に含まれている。

　送信先アドレスは、サービスサイトアプリケーション１４（クライアント）、つまりクライアントの応答受信アドレスを示している。より詳細には、招待コード要求の生成時には、この送信先アドレスが、招待コード要求に含まれている応答先アドレスの一部となるようにされる。これにより、不正なアドレス指定によって外部に情報が漏洩してしまうことが防止される。

　招待コード設定には、検証サーバ１５とのDIDcomm接続の表示名を示すラベル、DIDcomm接続を表すアイコン画像のアドレス、およびDIDcomm接続のために発行された招待コードの有効期間を示す情報が設定項目として含まれている。

　証明要求設定には、SSI証明の要求（証明要求）の表示名を示すラベル、後述するSSI証明（ユーザ）に関する認証情報の有効期間、およびSSI証明の項目リストが設定項目として含まれている。

　項目リストは、証明を要求するクレデンシャル項目、すなわちSSI証明に含まれるべきクレデンシャル項目についての項目名と制約の組み合わせのリストである。

　具体的には、項目リストには証明を要求するクレデンシャル項目の項目名を示す情報と、各クレデンシャル項目を取り出すことができるクレデンシャル（VC）の条件、すなわち制約を示す情報とが含まれている。ここでいう条件（制約）とは、例えば所定のクレデンシャル項目は、VCとしての免許証または保険証から取り出されたものでなければならないなどといった、クレデンシャル項目の抽出元（出力元）等に関する条件である。

　また、IDトークン設定には、IDトークンに設定する発行者識別子、IDトークンに設定する有効期間、およびSSI証明のIDトークへの変換に用いる変換テーブルが設定項目として含まれている。

　検証サーバ１５では、クライアントID（クライアント）ごとに設定情報として個別の設定を行うことが可能である。

　また、検証サーバ１５では、招待コード要求に対する応答処理など、検証サーバ１５のAPIを実行する際には、クライアントIDと、そのクライアントIDごとに発行されるクライアントシークレットを送信しなければならない。また、それらのクライアントIDとクライアントシークレットの値が正しくなければ、要求されたAPIの実行は許可されない。

　そのため、セッション管理部５２は、サービスサイトアプリケーション１４からの招待コード要求に含まれているクライアントIDおよびクライアントシークレットと、記録部５５に記録されている設定情報とに基づいてサービスサイトアプリケーション１４を認証する。

　認証が行われると、セッション管理部５２は、招待コード要求の送信元の装置であるサービスサイトアプリケーション１４に対して、SessionIDを含む招待コードを生成する。

　すなわち、セッション管理部５２は、記録部５５に記録されている設定情報の招待コード設定に基づいて、図４のステップＳ３２における場合と同様にして、例えば図８に示した招待コードを生成する。

　また、セッション管理部５２は、記録部５５に記録されている設定情報に基づいて、例えば図１０に示したセッション情報も生成する。

　例えばセッション管理部５２は、ステップＳ２３１で受信した招待コード要求に含まれているクライアントIDをそのままセッション情報に格納し、現在日時をセッション情報の作成日時とする。また、セッション管理部５２は、現在日時（作成日時）に対して、記録部５５に記録されている設定情報内の招待コード設定における有効期間を加えることで得られる値を、セッション情報の有効期限としてセッション情報に格納する。

　なお、この時点では、セッション情報にはConnectionIDと交換IDは含まれていない。

　セッション管理部５２は、以上のようにして招待コードとセッション情報を生成すると、SSIクラウドエージェント５３を介して通信部５１に招待コードを供給するとともに、セッション情報を記録部５５に供給して記録させる。

　図１３のフローチャートの説明に戻り、ステップＳ２３３において検証サーバ１５の通信部５１は、ステップＳ２３２で生成された招待コードをサービスサイトアプリケーション１４に送信する。

　すると、ステップＳ２０２においてサービスサイトアプリケーション１４は、検証サーバ１５により送信された、SessionIDを含む招待コードを受信する。

　ステップＳ２０３においてサービスサイトアプリケーション１４は、受信した招待コードをモバイル端末１１、すなわちユーザに対して提示する。

　ステップＳ２６１においてモバイル端末１１のSSIモバイルエージェント３３は、適宜、カメラ３２等を制御し、サービスサイトアプリケーション１４により提示された招待コードを読み取る。なお、招待コードの読み取り方法は、図４のステップＳ６１における場合と同様に、バーコードを利用した読み取りや無線通信による読み取りなど、どのような方法であってもよい。

　ステップＳ２６２においてモバイル端末１１のSSIモバイルエージェント３３は、適宜、記録部３１に記録されている情報を参照し、読み取られた招待コードの内容を確認することで、既に検証サーバ１５とのDIDcomm接続が確立済みであるかを確認（特定）する。

　例えばステップＳ２６２では、図４のステップＳ６２における場合と同様に、招待コードに含まれている接続先アクセス情報や接続先名称などに基づいて、DIDcomm接続が確立済みであるかの確認が行われる。

　ステップＳ２６２においてDIDcomm接続が確立済みであると確認（判定）された場合、その後、ステップＳ２６３およびステップＳ２６４の処理は行われず、処理はステップＳ２６５へと進む。

　このとき、SSIモバイルエージェント３３は、記録部３１に記録されているConnectionIDや、検証サーバ１５のラベル、DID、アクセス情報など、検証サーバ１５との過去のDIDcomm接続に関する情報を再利用して検証サーバ１５にDIDcomm接続する。すなわち、既に確立されているDIDcomm接続が再利用される。

　この場合、検証サーバ１５側においても、モバイル端末１１とのDIDcomm接続が再利用される。すなわち、セッション管理部５２は、セッション情報や接続情報などのDIDcomm接続に関する情報を再利用して、モバイル端末１１とのDIDcomm接続を行う。

　一方、ステップＳ２６２においてDIDcomm接続が確立済みでないことが確認された場合、ステップＳ２６３およびステップＳ２６４の処理が行われ、DIDcomm接続が確立される。このとき、検証サーバ１５では、ステップＳ２６３およびステップＳ２６４の処理に応じて、ステップＳ２３４およびステップＳ２３５の処理が行われる。

　具体的には、表示部３５は、招待コードに基づいて、検証サーバ１５とのDIDcomm接続を行うための接続確認画面を表示する。ユーザが表示された接続確認画面を確認し、モバイル端末１１を操作して確認ボタンを押すと、ステップＳ２６３の処理が行われる。

　ステップＳ２６３においてSSIモバイルエージェント３３は、適宜、記録部３１に記録されているモバイル端末１１（ユーザ）に関する情報を読み出して、読み出した情報からDIDcomm接続要求を生成し、そのDIDcomm接続要求を通信部３４により送信する。

　例えばDIDcomm接続要求には、図４のステップＳ６３における場合と同様に、モバイル端末１１のラベル、DID、およびアクセス情報が含まれている。

　通信部３４は、SSIモバイルエージェント３３により生成されたDIDcomm接続要求を、SSIネットワーク１７を介して検証サーバ１５に送信する。

　すると、ステップＳ２３４において検証サーバ１５の通信部５１は、モバイル端末１１から送信されてきたDIDcomm接続要求を受信する。

　そしてセッション管理部５２は、受信されたDIDcomm接続要求のメッセージを、記録部５５に記録されている検証サーバ１５の秘密鍵で復号することで、DIDcomm接続要求からモバイル端末１１のラベル、DID、およびアクセス情報を抽出する。これらのラベル、DID、およびアクセス情報は、適宜、記録部５５に供給され、記録されてもよい。

　また、セッション管理部５２は、DIDcomm接続要求に応じて、適宜、記録部５５から必要な情報を読み出し、検証サーバ１５のラベル、DID、およびアクセス情報を含むメッセージからなる、モバイル端末１１のアクセス情報により暗号化されたDIDcomm接続応答を生成する。

　ステップＳ２３５において通信部５１は、セッション管理部５２により生成されたDIDcomm接続応答を、SSIネットワーク１７を介してモバイル端末１１に送信する。

　すると、ステップＳ２６４においてモバイル端末１１の通信部３４は、検証サーバ１５から送信されてきたDIDcomm接続応答を受信し、SSIモバイルエージェント３３に供給する。

　SSIモバイルエージェント３３は、受信されたDIDcomm接続応答のメッセージを、記録部３１に記録されているモバイル端末１１の秘密鍵で復号することで、DIDcomm接続応答から検証サーバ１５のラベル、DID、およびアクセス情報を抽出する。これらのラベル、DID、およびアクセス情報は、適宜、記録部３１に供給され、記録されてもよい。

　以上の処理により、モバイル端末１１と検証サーバ１５との間でDIDcomm接続が確立されたことになる。DIDcomm接続が確立されると、以降においてはモバイル端末１１と検証サーバ１５との間の通信は、DIDcommを介して行われる。

　また、モバイル端末１１と検証サーバ１５の間でDIDcomm接続が確立されると、検証サーバ１５では、ステップＳ２３６の処理が行われ、DIDcomm接続情報が更新される。

　すなわち、ステップＳ２３６では、図４のステップＳ３６における場合と同様に、セッション管理部５２は、現時点において検証サーバ１５とDIDcomm接続されている複数のモバイル端末のリストにモバイル端末１１を追加し、更新後のDIDcomm接続情報として保持する。

　また、このときセッション管理部５２は、モバイル端末１１と検証サーバ１５の間でのDIDcomm接続に関する情報である接続情報を生成して記録部５５に供給し、記録させる。

　この場合、例えば図１１に示した接続情報が生成され、その接続情報における接続先識別子および接続元識別子は、それぞれモバイル端末１１のDIDおよび検証サーバ１５のDIDとされる。

　ステップＳ２６５においてモバイル端末１１の通信部３４は、DIDcomm接続を介して、SessionIDを含む開始要求を検証サーバ１５に送信する。

　例えばSSIモバイルエージェント３３は、ステップＳ２６１で読み取った招待コード内のSessionIDを含み、DIDcomm接続を介したSSI証明によるユーザ認証のための通信（処理）の開始を要求する開始要求を生成し、その開始要求を通信部３４に供給する。

　例えばSSIモバイルエージェント３３は、図１２に示した開始要求を生成する。なお、上述のステップＳ６５の実行時とは異なり、ステップＳ２６５においては、SessionIDおよび認証保存フラグが含まれた開始要求が生成される。この場合、ユーザは認証保存フラグを「真」または「偽」に設定することができる。

　認証保存フラグが「真」とされた場合、検証サーバ１５では、後述するユーザの認証情報が削除されずにそのまま記録され、認証保存フラグが「偽」とされた場合、検証サーバ１５では、ユーザの認証情報が削除される。すなわち、値が「偽」である認証保存フラグは、認証情報の削除を要求する旨のフラグ情報となる。

　例えばユーザは、自身のログインに関する情報などを更新（リセット）したいときなどに、認証保存フラグの値を「偽」に設定する。

　また、通信部３４は、SSIモバイルエージェント３３から開始要求が供給されると、その開始要求を検証サーバ１５に送信する。ステップＳ２６５では、ステップＳ２６１で取得した招待コードの接続先アクセス情報により示される検証サーバ１５のアドレスが宛先とされて開始要求が送信される。

　すると、ステップＳ２３７において検証サーバ１５の通信部５１は、モバイル端末１１から送信されてきた開始要求を受信する。これにより、招待コードを読み取ったDIDcomm接続の接続先の装置であるモバイル端末１１から、その招待コードに含まれているSessionIDを受信したことになる。

　ステップＳ２３８において検証サーバ１５のセッション管理部５２は、受信した開始要求に応じて、接続情報のConnectionIDをセッション情報に追加して保存する。

　すなわち、セッション管理部５２は、受信した開始要求に含まれているSessionIDと、ステップＳ２３２で生成され、記録部５５に記録されているセッション情報に含まれているSessionIDとが一致することを確認する。

　次に、セッション管理部５２は、現時点で行われているモバイル端末１１とのDIDcomm接続を一意に識別する接続情報のConnectionIDをステップＳ２３２で生成したセッション情報に追加し、ConnectionIDが追加されたセッション情報を記録部５５に記録させる。

　換言すれば、セッション管理部５２は、招待コード要求の送信元の装置であるサービスサイトアプリケーション１４を識別するクライアントIDと、招待コードを読み取った接続先の装置であるモバイル端末１１から受信したSessionIDと、モバイル端末１１とのDIDcomm接続に用いるConnectionIDとを対応付けて記録部５５に記録させる。

　但し、既にセッション情報にConnectionIDが記録されていた場合には、ステップＳ２３８の処理は行われない。また、セッション情報の有効期限が過ぎている場合には、そのセッション情報は無効とされ、セッション管理部５２により削除される。

　以上の処理によって検証サーバ１５では、セッション情報によって、クライアントIDと、SessionIDと、ConnectionIDとの対応付けができたことになる。

　ステップＳ２３９において検証サーバ１５のSSIクラウドエージェント５３は、ステップＳ２３７で受信された開始要求において認証保存フラグが「偽」とされており、かつ記録部５５に認証情報が記録（保存）されている場合、その認証情報を削除する。

　例えば記録部５５には、DIDcomm接続の接続相手であるモバイル端末１１（ユーザ）の認証が行われたことがある場合、その認証（ユーザ認証）に関する情報として、図１６に示す認証情報が記録されている。

　図１６の例では、認証情報にはConnectionID、作成日時、有効期限、およびSSI証明が含まれている。

　ここで、認証情報に含まれるSSI証明は、ユーザ認証のためにモバイル端末１１（ユーザ）から提示されたものであり、認証情報に含まれるConnectionIDは、そのSSI証明を提示したモバイル端末１１とのDIDcomm接続を示すConnectionIDである。

　SSIクラウドエージェント５３は、認証保存フラグが「偽」にセットされた開始要求が受信された場合、すなわち認証保存フラグにより認証情報の削除の要求があった場合、該当する認証情報を検索する。

　具体的には、SSIクラウドエージェント５３は、モバイル端末１１とのDIDcomm接続についてのセッション情報に含まれているConnectionIDと同じConnectionIDを含む認証情報を記録部５５から検索する。

　そしてSSIクラウドエージェント５３は、検索により得られた認証情報を記録部５５から削除させる。なお、ConnectionIDがセッション情報のものと同じ認証情報が記録部５５にない場合や、認証保存フラグが「真」である場合には、ステップＳ２３９の処理は行われない。

　図１３から図１４の説明へと移り、モバイル端末１１とのDIDcomm接続についてのセッション情報に含まれているものと同じConnectionIDを含む認証情報が記録部５５に記録されていない場合、すなわち有効な認証情報が存在しない場合、以降のステップＳ２４０乃至ステップＳ２４３の処理が行われる。例えばステップＳ２３９の処理が行われた場合には、有効な認証情報がないとされる。また、有効な認証情報がない場合、モバイル端末１１においては、ステップＳ２６６乃至ステップＳ２６８の処理が行われる。

　ステップＳ２４０において検証サーバ１５の通信部５１は、ユーザ認証のためのSSI証明の提示を要求するSSI証明要求を、DIDcomm接続、すなわちSSIメディエータエージェント２２を介してモバイル端末１１に送信する。

　例えばSSIクラウドエージェント５３は、図１５に示した検証サーバ１５の設定情報における証明要求設定の項目リストを含むSSI証明要求を生成するとともに、そのSSI証明要求に対して一意な交換IDを発行し、SSI証明要求と交換IDを通信部５１に供給する。

　通信部５１は、SSIクラウドエージェント５３から供給されたSSI証明要求と交換IDをモバイル端末１１へと送信する。このときSSI証明要求と交換IDの送信先は、DIDcomm接続を示すセッション情報のConnectionIDで識別される接続先、すなわちConnectionIDにより特定されるモバイル端末１１である。

　SSI証明要求の送信によって、モバイル端末１１に対して、SSIクラウドエージェント５３によりSSI証明の提示が要求されたことになる。

　なお、検証サーバ１５は、SSI証明要求の送信後、SSI証明の要求を行った旨のイベント通知をサービスサイトアプリケーション１４に対して行うようにしてもよい。そうすれば、サービスサイトアプリケーション１４は、SSI証明の要求、すなわちユーザ認証の処理が開始されたことをユーザ（モバイル端末１１）に通知（提示）することができる。このとき、ユーザ認証の処理が開始されたことの通知先は、モバイル端末１１に限らず、Desktopアプリケーションなど、モバイル端末１１とは異なる他の端末等であってもよい。一例として、例えば招待コードとしてのQRコード（登録商標）等がログイン画面に表示されている状態においてイベント通知が行われると、招待コードの表示が消えて処理中である旨のメッセージが表示された状態となるようにすることができる。

　ステップＳ２４１においてSSIクラウドエージェント５３は、記録部５５に記録されている、モバイル端末１１とのDIDcomm接続についてのセッション情報に、SSI証明要求に対して発行した交換IDを追加することで、セッション情報を更新する。

　また、ステップＳ２４０の処理が行われると、モバイル端末１１ではステップＳ２６６乃至ステップＳ２６８の処理が行われる。

　すなわち、ステップＳ２６６においてモバイル端末１１の通信部３４は、検証サーバ１５から送信されてきたSSI証明要求と交換IDを受信する。

　ステップＳ２６７においてSSIモバイルエージェント３３は、受信したSSI証明要求の内容に応じたSSI証明を生成するとともに、その生成したSSI証明を表示部３５に供給して表示させることで、ユーザにSSI証明の内容確認を行わせる。

　すなわち、SSIモバイルエージェント３３は、受信したSSI証明要求に含まれる項目リストと、記録部３１（ウォレット）に記録されているユーザの発行済みのVCとに基づいてSSI証明を生成する。このとき、項目リストにより示される条件（制約）を満たすVCから、項目リストにより示される項目名のクレデンシャル項目が抽出され、抽出された１または複数のクレデンシャル項目を含むSSI証明が生成される。

　なお、SSIモバイルエージェント３３は、SSI証明の生成に利用可能なVCが複数存在する場合、それらの利用可能（選択可能）なVCのリストを表示部３５に表示させ、SSI証明の生成に利用するVCをユーザに指定（選択）させるようにしてもよい。

　また、SSIモバイルエージェント３３は、生成したSSI証明を表示部３５に提示（表示）させることで、そのSSI証明の内容の確認を促す。すなわち、提示したSSI証明の内容で、その後の処理を継続してよいかの確認（同意）が求められる。

　ユーザがモバイル端末１１を操作し、処理の継続に同意すると、SSIモバイルエージェント３３は、生成したSSI証明と、ステップＳ２６６で受信した交換IDとを通信部３４に供給する。

　ステップＳ２６８において通信部３４は、SSIモバイルエージェント３３から供給されたSSI証明と交換IDを、DIDcomm接続を介して検証サーバ１５に送信する。

　すると、ステップＳ２４２において検証サーバ１５の通信部５１は、モバイル端末１１から送信されてきたSSI証明と交換IDを受信する。

　ステップＳ２４３において検証サーバ１５のSSIクラウドエージェント５３は、受信したSSI証明に応じて認証情報を生成し、記録部５５に記録させる。

　具体的には、まずSSIクラウドエージェント５３は、ステップＳ２４２で受信された交換IDと、ステップＳ２４１でセッション情報に追加した交換IDとが一致することを確認する。これにより、ステップＳ２４２で受信したSSI証明が、検証サーバ１５がSSI証明の提示を要求したモバイル端末１１からのものであることが確認される。

　次に、SSIクラウドエージェント５３は、DIDcomm接続を介して受信したSSI証明と、SSIブロックチェーン２１に登録されている定義情報やリボケーションリストなどのVCに関する情報とに基づいて、受信したSSI証明を検証する。

　さらにSSIクラウドエージェント５３は、受信したSSI証明と、モバイル端末１１とのDIDcomm接続についてのセッション情報と、記録部５５に記録されているクライアント（サービスサイトアプリケーション１４）ごとの設定情報における証明要求設定とに基づいて、図１６に示した認証情報を生成する。

　例えばSSIクラウドエージェント５３は、受信したSSI証明と、モバイル端末１１とのDIDcomm接続についてのセッション情報に含まれているConnectionIDとを認証情報に格納する。また、SSIクラウドエージェント５３は、現在日時を認証情報の作成日時として認証情報に格納するとともに、その作成日時に対して、記録部５５に記録されている設定情報内の証明要求設定における有効期間を加えることで得られる値を、認証情報の有効期限として認証情報に格納する。

　これにより、SSI証明の検証が完了したDIDcomm接続を示す認証情報が得られたことになる。SSIクラウドエージェント５３は、このようにして得られた認証情報を記録部５５に供給し、記録させる。

　なお、有効期限が経過して認証情報が無効になっていたり、認証保存フラグが「偽」にセットされた開始要求が受信されたりした場合、認証情報は、SSIクラウドエージェント５３により削除される。また、モバイル端末１１とのDIDcomm接続についてのセッション情報が既に無効となっている場合には、ステップＳ２４３の処理は行われない。

　以上のように、有効な認証情報が記録部５５に記録されていない場合、検証サーバ１５においてステップＳ２４０乃至ステップＳ２４３の処理が行われるとともに、モバイル端末１１においてステップＳ２６６乃至ステップＳ２６８の処理が行われる。そして、その後、ステップＳ２４４の処理が行われ、IDトークンが生成される。

　一方、モバイル端末１１とのDIDcomm接続についてのセッション情報に含まれているものと同じConnectionIDを含む認証情報が既に記録部５５に記録されている場合、すなわち有効な認証情報がある場合、SSI証明要求は送信されず、直ちにIDトークンが生成される。すなわち、ステップＳ２４０乃至ステップＳ２４３の処理、およびステップＳ２６６乃至ステップＳ２６８の処理は行われず、直ちにステップＳ２４４の処理が行われる。

　有効な認証情報が既に記録部５５に記録されている場合、SSIクラウドエージェント５３は、その認証情報から、DIDcomm接続の接続先であるモバイル端末１１によって過去にSSI証明が提示され、そのSSI証明が検証済みであることを特定することができる。

　ステップＳ２４４においてIDトークン生成部５４は、モバイル端末１１のSSI証明と、記録部５５に記録されている図１５に示した設定情報におけるIDトークン設定とに基づいて、例えば図１７に示すIDトークンを生成する。

　図１７の例では、IDトークンには、発行者識別子、クライアントID、作成日時、有効期限、およびクレームが含まれている。

　IDトークンの発行者識別子は、IDトークン設定における発行者識別子とされ、この例では検証サーバ１５を示す識別子が発行者識別子としてIDトークンに格納される。

　また、クライアントIDは、ステップＳ２３１で受信した招待コード要求に含まれているクライアントIDとされる。IDトークンの作成日時は、ステップＳ２４４の処理が行われるときの現在日時とされ、その現在日時に、IDトークン設定における有効期間を加えることで得られる値（日時）がIDトークンの有効期限とされる。

　さらに、IDトークンに含まれるクレームは、IDトークン設定における変換テーブルによってSSI証明から抽出されたクレデンシャル項目の値とされる。

　ここで、図１８を参照して、IDトークンの生成の具体的な例について説明する。

　この例では、変換テーブルTB11が用いられて、SSI証明T11がIDトークンT12へと変換される。

　SSI証明T11には、各クレデンシャル項目の項目名「name」として、ユーザIDを示す「ID」、ユーザのファーストネーム（名）を示す「first_name」、ユーザのラストネーム（姓）を示す「last_name」、およびユーザの電子メールのアドレスを示す「email」が含まれている。また、SSI証明T11には、それらの各クレデンシャル項目の値「value」として、「User01」、「Tom」、「Smith」、および「user＠example.com」が含まれている。

　これに対して、IDトークンT12には、IDトークンの各項目として「iss」、「sub」、「aud」、「exp」、「iat」、「email」、および「first_name」が含まれている。この例では、それらの各項目の値は「https://vc.example.com」、「User01」、「kjsdafjh」、「1311281970」、「1311280970」、「user@example.com」、および「Tom」となっている。

　また、変換テーブルTB11は、SSI証明における項目名「ID」、「email」、および「first_name」の値をIDトークンの項目「sub」、「email」、および「first_name」に書き出すことが規定されたテーブルとなっている。

　このような変換テーブルTB11は、検証サーバ１５の設定情報によって、クライアントIDごとに定義されている。

　この例では、IDトークン生成部５４は、図１５に示した設定情報におけるIDトークン設定の発行者識別子の値をIDトークンT12の項目「iss」の値とする。

　また、IDトークン生成部５４は、変換テーブルTB11に基づき、SSI証明T11における項目名「ID」、「email」、および「first_name」の値を、そのままIDトークンT12の項目「sub」、「email」、および「first_name」の値として格納する。

　これらのIDトークンT12の項目「sub」、「email」、および「first_name」の値が図１７に示した例におけるIDトークンのクレームの値となる。

　IDトークン生成部５４は、図１５に示した設定情報におけるクライアントIDを、IDトークンT12の項目「aud」の値として格納し、現在日時をIDトークンT12の項目「iat」の値として格納する。さらにIDトークン生成部５４は、項目「iat」の値（現在日時）に、図１５に示した設定情報におけるIDトークン設定の有効期間を加えて得られる有効期限を、IDトークンT12の項目「exp」の値として格納する。

　以上の処理により、SSIネットワーク１７で用いられるSSI証明が、そのSSI証明とは異なる形式の証明であるIDトークンに変換される。

　図１４の説明に戻り、IDトークン生成部５４は、生成したIDトークンを通信部５１に供給する。

　ステップＳ２４５において検証サーバ１５の通信部５１は、IDトークン生成部５４から供給されたIDトークンをサービスサイトアプリケーション１４に送信する。より詳細には、セッション情報のクライアントIDと同じものが含まれている、ステップＳ２３１で受信された招待コード要求が参照され、その招待コード要求に含まれる応答先アドレスへとIDトークンが送信される。

　ステップＳ２０４においてサービスサイトアプリケーション１４は、検証サーバ１５から送信されてきたIDトークンを受信する。

　そしてステップＳ２０５においてサービスサイトアプリケーション１４は、受信したIDトークンを検証する。

　例えばIDトークンには、IDトークンに基づきIDトークン生成部５４により生成された電子署名が付加されており、サービスサイトアプリケーション１４は、その電子署名を検証することでIDトークンの有効性を検証（確認）する。

　IDトークンの検証方法には、サービスサイトアプリケーション１４が予め電子署名の公開鍵を受け取っておき、その公開鍵を用いて電子署名を検証する方法が考えられる。

　また、例えばサービスサイトアプリケーション１４が、検証サーバ１５により提供される検証APIにIDトークンを送信し、検証サーバ１５から検証結果とIDトークンのデコード結果を受け取るようにしてもよい。

　さらに、サービスサイトアプリケーション１４は、IDトークンに含まれているクライアントIDや有効期限を確認することで、IDトークンが有効であることを確認する。

　IDトークンの有効性が検証されると、ユーザ認証がなされたことになり、その結果、ユーザのサービスサイトへのログインが完了したことになる。

　ログインが完了すると、サービスサイトアプリケーション１４は、適宜、ユーザへのサービスの提供のためにリソースサーバ１６へとIDトークンを送信（提示）し、リソースサーバ１６が管理するデータへのアクセス等を行うことができる。

　以上の処理により、SSI証明を用いたユーザ認証が行われたことになり、ユーザ認証時にモバイル端末１１、検証サーバ１５、およびサービスサイトアプリケーション１４により行われる処理は終了する。

　以上のようにしてモバイル端末１１および検証サーバ１５は、DIDcomm接続を介して通信を行う場合に、既にDIDcomm接続が確立されているときには、そのDIDcomm接続を再利用する。これにより、ユーザは、DIDcomm接続を行うたびに新規接続の手順を実行する必要がなくなるので、より簡単に自己主権的なユーザ認証を実現することができる。

　しかも、図３に示したサービス提供システムでは、サービスサイトアプリケーション１４にSSIのプロトコルを直接実装する必要がなく、サービスサイトアプリケーション１４は、一般的に広く用いられているIDトークンをそのまま利用することができる。また、検証サーバ１５においてセッション情報によりモバイル端末１１とサービスサイトアプリケーション１４とを紐づけることができる。これにより、さらに簡単な仕組みで、すなわち最小限のシステムの変更で自己主権的なユーザ認証を実現することができる。

〈本技術の適用例〉
　ここで、以上において説明した本技術の具体的な適用例について説明する。

　まず、本技術のVCを商品等の電子的な引換券として利用する例について説明する。

　例えば、限定商品を抽選販売する際に、その引換券を電子的に発行することができる。

　利用者は、スマートフォン（モバイル端末１１）を利用して商品購入のための予約サイト（ユーザ管理サイトアプリケーション１２）へアクセスし、抽選アプリケーションを実行する。その結果、当選した場合は、画面上に招待コードを取得するためのボタンが現れる。利用者がこのボタンを押下すると、モバイルエージェントアプリケーション（モバイル端末１１）に対して当選結果を証明するVCが電子的な引換券として発行される。

　商品発売日以降、利用者が商品購入のために来店すると、モバイルエージェントアプリケーション（モバイル端末１１）を使って店頭に表示されているQRコード（登録商標）を読み取る。これにより、利用者が当選者であることが電子的に証明され、限定販売の商品を購入することができる。

　この引換券（VC）は、当選者のウォレットに対して電子的に発行されるため、他人に転売等することは困難である。また、利用時に発行元である抽選サイト（予約サイト）のサーバに接続する必要がなく、万が一、サーバへの接続が出来ない場合や、サーバが停止したり、サーバ上のデータが紛失したりした場合でも、当選者の権利を証明することが可能である。

　また、本技術は、予防接種証明書等にも利用することができる。

　すなわち、例えば自治体は、住民のうち予防接種の対象者に対して、電子メールあるいは郵送にて招待コードを含むQRコード（登録商標）を送付する。予防接種の対象者である利用者は、その招待コードを、モバイルエージェントアプリケーション（モバイル端末１１）で読み取ることにより、氏名・生年月日・性別・住所・連絡先・病院名・実施日時などの情報を含む予約券VCが発行される。

　後日、利用者が病院に設置されたNFCポートをモバイルエージェントアプリケーションでスキャンすることにより、予約券VCによる証明提示が行われる。病院は、予約券VCに含まれた情報を受け取ると、患者データベースとの紐付けを行う。そして、病院は、病院名や実施日時が正しいことを確認すると、利用者は予防接種を受けることができる。

　接種完了後、利用者が病院に設置されたNFCポートを再びモバイルエージェントアプリケーションでスキャンすることにより、氏名・生年月日・性別・病院名・医師名・接種日・接種内容・製造番号などの情報を含む予防接種証明VCが発行される。病院は、最初に予約券VCを受け取った段階で患者（利用者）のIDを特定しているため、同じモバイルエージェントアプリケーション（モバイル端末１１）を使ってスキャンした場合、その利用者の予防接種証明VCを直ちに発行することができる。

　その後、利用者がモバイルエージェントアプリケーション（モバイル端末１１）により、地域のレストランに表示されたQRコード（登録商標）を読み込むと、予防接種証明VCによる証明提示が行われ、３か月以内に予防接種を受けた利用者に対する割引などのサービスを受けることができる。このとき、レストランでは予防接種証明VCの接種日だけを証明要求するため、利用者はその他の個人情報を提示する必要は無い。

　また、例えば利用者は、後日、入国時に要求があった場合に、モバイルエージェントアプリケーション（モバイル端末１１）により検疫ゲートにあるQRコード（登録商標）を読み取ることによって、この予防接種証明VCを使った証明提示を行うことができる。

〈コンピュータの構成例〉
　ところで、上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

　図１９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。

　コンピュータにおいて、CPU５０１，ROM（Read Only Memory）５０２，RAM（Random Access Memory）５０３は、バス５０４により相互に接続されている。

　バス５０４には、さらに、入出力インターフェース５０５が接続されている。入出力インターフェース５０５には、入力部５０６、出力部５０７、記録部５０８、通信部５０９、及びドライブ５１０が接続されている。

　入力部５０６は、キーボード、マウス、マイクロフォン、撮像素子などよりなる。出力部５０７は、ディスプレイ、スピーカなどよりなる。記録部５０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部５０９は、ネットワークインターフェースなどよりなる。ドライブ５１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体５１１を駆動する。

　以上のように構成されるコンピュータでは、CPU５０１が、例えば、記録部５０８に記録されているプログラムを、入出力インターフェース５０５及びバス５０４を介して、RAM５０３にロードして実行することにより、上述した一連の処理が行われる。

　コンピュータ（CPU５０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体５１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

　コンピュータでは、プログラムは、リムーバブル記録媒体５１１をドライブ５１０に装着することにより、入出力インターフェース５０５を介して、記録部５０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部５０９で受信し、記録部５０８にインストールすることができる。その他、プログラムは、ROM５０２や記録部５０８に、あらかじめインストールしておくことができる。

　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

　また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

　例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

　さらに、本技術は、以下の構成とすることも可能である。

（１）
　DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させるセッション管理部と、
　前記接続先の装置との間でDIDcomm接続を介した通信を行う通信部と
　を備え、
　前記セッション管理部は、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する
　情報処理装置。
（２）
　前記セッション管理部は、前記セッションIDと、前記クライアントIDと、前記接続先の装置とのDIDcomm接続に用いるコネクションIDとを対応付けて記録させる
　（１）に記載の情報処理装置。
（３）
　VCに基づき生成された証明を、DIDcomm接続を介して前記接続先の装置から受信した場合、前記証明を検証する証明検証部と、
　前記証明を、前記証明とは異なる形式の他の証明に変換する生成部と
　をさらに備える（１）または（２）に記載の情報処理装置。
（４）
　前記他の証明はIDトークンである
　（３）に記載の情報処理装置。
（５）
　前記生成部は、予め記録している変換テーブルに基づいて、前記証明を前記他の証明に変換する
　（３）または（４）に記載の情報処理装置。
（６）
　前記通信部は、前記他の証明を前記送信元の装置に送信する
　（３）乃至（５）の何れか一項に記載の情報処理装置。
（７）
　前記証明検証部は、前記接続先の装置とのDIDcomm接続に用いるコネクションIDと、前記証明とを含む認証情報を生成して前記認証情報を記録させる
　（３）乃至（６）の何れか一項に記載の情報処理装置。
（８）
　前記証明検証部は、前記認証情報が記録されていない場合、前記接続先の装置に対して前記証明の提示を要求する
　（７）に記載の情報処理装置。
（９）
　前記証明検証部は、前記接続先の装置から前記認証情報の削除の要求があった場合、記録されている前記認証情報を削除させる
　（７）または（８）に記載の情報処理装置。
（１０）
　情報処理装置が、
　DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、
　前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させ、
　前記接続先の装置との間でDIDcomm接続を介した通信を行う
　ステップを含み、
　既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する
　情報処理方法。
（１１）
　DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、
　前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させ、
　前記接続先の装置との間でDIDcomm接続を介した通信を行う
　ステップを含む処理をコンピュータに実行させ、
　既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する
　プログラム。
（１２）
　提示されたDIDcomm接続のための招待コードを読み取る読み取り部と、
　前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する制御部と、
　前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する通信部と
　を備える情報処理装置。
（１３）
　前記制御部は、ウォレットに記録されているVCに基づいて、前記接続先の装置からの要求に応じた証明を生成し、
　前記通信部は、DIDcomm接続を介して、前記証明を前記接続先の装置に送信する
　（１２）に記載の情報処理装置。
（１４）
　前記通信部は、前記接続先の装置に記録されている、前記接続先の装置とのDIDcomm接続に用いるコネクションIDと前記証明とを含む認証情報の削除を要求する旨のフラグ情報を、DIDcomm接続を介して前記接続先の装置に送信する
　（１３）に記載の情報処理装置。
（１５）
　情報処理装置が、
　提示されたDIDcomm接続のための招待コードを読み取り、
　前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用し、
　前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する
　ステップを含む情報処理方法。
（１６）
　提示されたDIDcomm接続のための招待コードを読み取り、
　前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用し、
　前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する
　ステップを含む処理をコンピュータに実行させるプログラム。

　１１　モバイル端末，　１２　ユーザ管理サイトアプリケーション，　１３　VC発行サーバ，　１４　サービスサイトアプリケーション，　１５　検証サーバ，　１７　SSIネットワーク，　３１　記録部，　３２　カメラ，　３３　SSIモバイルエージェント，　３４　通信部，　３５　表示部，　５１　通信部，　５２　セッション管理部，　５３　SSIクラウドエージェント，　５４　IDトークン生成部，　５５　記録部

Claims (16)

1. 　DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させるセッション管理部と、
   　前記接続先の装置との間でDIDcomm接続を介した通信を行う通信部と
   　を備え、
   　前記セッション管理部は、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する
   　情報処理装置。
2. 　前記セッション管理部は、前記セッションIDと、前記クライアントIDと、前記接続先の装置とのDIDcomm接続に用いるコネクションIDとを対応付けて記録させる
   　請求項１に記載の情報処理装置。
3. 　VCに基づき生成された証明を、DIDcomm接続を介して前記接続先の装置から受信した場合、前記証明を検証する証明検証部と、
   　前記証明を、前記証明とは異なる形式の他の証明に変換する生成部と
   　をさらに備える請求項１に記載の情報処理装置。
4. 　前記他の証明はIDトークンである
   　請求項３に記載の情報処理装置。
5. 　前記生成部は、予め記録している変換テーブルに基づいて、前記証明を前記他の証明に変換する
   　請求項３に記載の情報処理装置。
6. 　前記通信部は、前記他の証明を前記送信元の装置に送信する
   　請求項３に記載の情報処理装置。
7. 　前記証明検証部は、前記接続先の装置とのDIDcomm接続に用いるコネクションIDと、前記証明とを含む認証情報を生成して前記認証情報を記録させる
   　請求項３に記載の情報処理装置。
8. 　前記証明検証部は、前記認証情報が記録されていない場合、前記接続先の装置に対して前記証明の提示を要求する
   　請求項７に記載の情報処理装置。
9. 　前記証明検証部は、前記接続先の装置から前記認証情報の削除の要求があった場合、記録されている前記認証情報を削除させる
   　請求項７に記載の情報処理装置。
10. 　情報処理装置が、
    　DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、
    　前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させ、
    　前記接続先の装置との間でDIDcomm接続を介した通信を行う
    　ステップを含み、
    　既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する
    　情報処理方法。
11. 　DIDcomm接続のための招待コード要求の送信元の装置に対して、DIDcomm接続を識別するセッションIDを含む招待コードを生成し、
    　前記招待コードを読み取った接続先の装置からDIDcomm接続を介して受信した前記セッションIDと、前記招待コード要求に含まれている前記送信元の装置を識別するクライアントIDとを対応付けて記録させ、
    　前記接続先の装置との間でDIDcomm接続を介した通信を行う
    　ステップを含む処理をコンピュータに実行させ、
    　既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する
    　プログラム。
12. 　提示されたDIDcomm接続のための招待コードを読み取る読み取り部と、
    　前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用する制御部と、
    　前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する通信部と
    　を備える情報処理装置。
13. 　前記制御部は、ウォレットに記録されているVCに基づいて、前記接続先の装置からの要求に応じた証明を生成し、
    　前記通信部は、DIDcomm接続を介して、前記証明を前記接続先の装置に送信する
    　請求項１２に記載の情報処理装置。
14. 　前記通信部は、前記接続先の装置に記録されている、前記接続先の装置とのDIDcomm接続に用いるコネクションIDと前記証明とを含む認証情報の削除を要求する旨のフラグ情報を、DIDcomm接続を介して前記接続先の装置に送信する
    　請求項１３に記載の情報処理装置。
15. 　情報処理装置が、
    　提示されたDIDcomm接続のための招待コードを読み取り、
    　前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用し、
    　前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する
    　ステップを含む情報処理方法。
16. 　提示されたDIDcomm接続のための招待コードを読み取り、
    　前記招待コードに基づいて、前記招待コードにより示される接続先の装置との間で既にDIDcomm接続が確立されているかを特定し、既に前記接続先の装置とのDIDcomm接続が確立されている場合、前記接続先の装置とのDIDcomm接続を再利用し、
    　前記招待コードに含まれている、前記接続先の装置とのDIDcomm接続を識別するセッションIDを、DIDcomm接続を介して前記接続先の装置に送信する
    　ステップを含む処理をコンピュータに実行させるプログラム。

Images