JP7462910B2 - クレデンシャル・サービス・プロバイダを通じたクレデンシャルの検証及び発行 - Google Patents

Description

本発明は、クレデンシャル（ｃｒｅｄｅｎｔｉａｌ）の検証及び／又は発行に関し、より詳細には、１つ又は複数のクレデンシャル・サービス・プロバイダを通じたクレデンシャルの検証及び／又は発行に関する。

クレデンシャルを検証又は発行する際、クレデンシャル所有者は、クレデンシャルが本物で、検証又は発行に必要な情報を含むかどうかを検証するため、例えば、紙、プラスチック・カード、磁気ストライプ・カード、チップ・カード等の形態の１つを取る少なくとも１つの従来のクレデンシャルを当該所有者のための人（検証者／発行者）又は検証者／発行者のデバイス／機構に提示しなければならない。クレデンシャル所有者の観点からすると、従来のクレデンシャルは、こうした物理的形式の物を携行するのが不満であったり、紛失又は盗難されやすいことに加えて、次の例から明らかな以下の欠点も有する。

まず、国民ＩＤカードを一例とすると、従来の紙／プラスチックＩＤカード、又はより高度な状況ではスマートＩＤカード（チップ・カード若しくはＩＣカード）が国民ＩＤの検証の実施に採用されることがある。いずれかの状況において、技術的な出発点は、本質的に、集中国民ＩＤデータベースを必要とし、この集中国民ＩＤデータベースは、国の民間人の情報を保存し、通常、より古いデータベース技術と共に数十年にわたって構築される。したがって、検証のため、警察官等の検証者が、民間人の身元の検証を求める際、国民ＩＤカードを所有する民間人は、ＩＤカードを警察官に提示することができる。警察官は、ＩＤカードを受け取った後、カード上の写真を確認し、警察署を呼び出し、警察署からアクセス可能な集中データベースでＩＤ番号、氏名、住所等を検証することができる。より高度なシナリオでは、警察官は、（スマート・カードの状況ではカードの認証後）路上でデータベースに直接照会することができる携帯デバイスを有し、時間を節約することができる。このような手法は、そのような検証基盤を構築／維持するのにかなり費用がかかること、プライバシー・データ保護に関する問題のために、通常、データベースが一般大衆には利用不可能であること、ＩＤを検証するには検証者が集中サーバに交信しなければならないこと、及び集中サーバが機能停止していると、検証が停止することといった欠点を有する。

第２に、会社／建物へのアクセス・バッジを別の例として取ると、従来、検証は、ＱＲコード（登録商標）を事前発行し、後に受付で登録することによって実施することができる。このような場合、訪問者が会社を訪問する前に、会社の従業員は、訪問者の招待を会社のシステム内に登録するため、招待リンクを訪問者に送信し、訪問者は、リンクからＱＲコードを印刷し、次に、訪問者が招待された建物を訪問する。到着時、受付係はＱＲコードをスキャンし、会社の登録データベースで確認する。ＱＲコードが有効である場合、訪問者は建物へのアクセスを許可される。このような手法は、リンクの電子メールが盗難される可能性があること、ＱＲコードが建物にアクセスする権限のない者によって印刷される可能性があること、印刷したＱＲコードも盗難される可能性があること、又は何者かがＱＲコードの写真を撮影し、建物にアクセスする可能性があることといった欠点を有するため、この手法の安全性を低下させ、中間者攻撃によって容易に損なわれることになる。
代替的に、あらゆる事前登録がない場合、訪問者は、受付に直接行き、訪問者のＩＤを提示する。訪問者又は受付係は、ＩＤの情報をコンソールで入力するかもしれない。次に、受付係は、訪問者のＩＤ及び情報を検証し、訪問者にバッジを渡す。このような手法は、より非効率であり、訪問者が到着時に受付で登録する必要があるという欠点を有する。更に、検証工程で使用されるＩＤは、偽造されることがあり、ＩＤの真正性を確認することは困難である。

検証及び発行で使用される従来のクレデンシャルに起因する上記の欠点を処理するため、デジタル・クレデンシャルは、解決策の１つであり、将来の傾向であると思われる。本開示は、より信頼でき、安全な様態のデジタル・クレデンシャルのためのクレデンシャル・サービス配信方法を記載する。したがって、本開示は、様々なクレデンシャル・サービス・プロバイダ、例えば、世界中の様々な通信事業者にわたる分散システム基盤及びクレデンシャル・サービスを記載し、これにより、クレデンシャル管理サービスが集中クレデンシャル・サービス・プロバイダのみに依存しないことを保証する。

本開示は、１つ又は複数のクレデンシャル・サービス・プロバイダを通じて、クレデンシャル所有者がリクエストしたクレデンシャルを検証する及び／又は新たなクレデンシャルを発行する、１つ又は複数の方法、システム、装置、及びプロセッサ実行可能プロセス・ステップを保存するコンピュータ可読媒体を対象とする。方法は、（ａ）リクエストに応じて、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムによって、クレデンシャル所有者のリクエスト・デバイスに共有クレデンシャル・トークン及びサービス・エンドポイントを提供することと、（ｂ）第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムによって、検証者の検証デバイスから、リクエスト・デバイスを通じて、共有クレデンシャル・トークン及びサービス・エンドポイントを受信することと、（ｃ）サービス・エンドポイントに基づき、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムによって、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムに証明リクエストを送信することと、（ｄ）第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムによって、証明リクエストに基づく証明を生成することと、（ｅ）前記第２のクレデンシャル・サービス・プロバイダの前記第２のクレデンシャル管理システムによって、分散台帳から抽出したクレデンシャル暗号情報に基づき、証明を検証することとを含む。一実施形態では、クレデンシャル所有者は、第１のクレデンシャル・サービス・プロバイダからの第１のクレデンシャル管理システムのサービスに加入する一方で、検証者は、第２のクレデンシャル・サービス・プロバイダからの第２のクレデンシャル管理システムのサービスに加入する。第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムは、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムと同じでも、異なっていてもよい。

従来のクレデンシャル・サービスと比較した、本開示の１つの利点は、分散台帳を介したリアルタイムの検証をもたらすことである。従来、検証者は、クレデンシャル発行者に連絡し、そのようなクレデンシャルが本物であるかどうかを検証する必要があり、達成に長時間かかることがある。更に、検証者は、クレデンシャルの種類に応じて、様々な異なるクレデンシャル発行者に連絡する必要がある。各クレデンシャル発行者は、検証を得るために順守すべきかなり異なる手順又は要件を有することがある。

クレデンシャルがクレデンシャル所有者の携帯デバイスに保存される他のデジタル・クレデンシャル・サービスと比較すると、本開示の１つの利点は、クレデンシャル所有者が携帯デバイスを紛失した場合、このクレデンシャル所有者のクレデンシャルが紛失しないことである。

本開示の更なる特徴及び利点は、以下の説明で示され、部分的に説明から明らかになるか、又は本開示の実行によって学習することができる。本開示の目的及び他の利点は、明細書及び特許請求の範囲、並びに添付の図面で具体的に指摘される構成及び方法によって実現、達成される。

上記の一般的な説明及び以下の詳細な説明は、例示的、説明的なものであり、請求する発明に対する更なる説明をもたらすことを意図すると理解されたい。

クレデンシャル所有者のリクエスト・デバイスと、検証者の検証デバイスと、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムと、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムと、分散アイデンティティ・ブロックチェーンの第１のノードと、第２のノードとの間の関係を示す概略図である。 クレデンシャル保有者がリクエストしたクレデンシャルを検証するステップの一実施形態を示すプロセス・フロー図である。 検証要件ドキュメントの一実施形態を示す概略図である。 クレデンシャル所有者のリクエスト・デバイスと、発行者の発行デバイスと、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムと、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムと、分散アイデンティティ・ブロックチェーンの第１のノードと、第２のノードとの間の関係を示す概略図である。 新たなクレデンシャルを発行するステップの一実施形態を示すプロセス・フロー図である。

以下で提示する説明で使用する用語は、本技術のある特定の実施形態に対する詳細な説明と共に用語を使用するが、最も広範囲に妥当な様式で解釈することを意図する。特定の用語は、以下で強調することさえあるが、制限的に解釈されることが意図されるあらゆる用語は、本項「発明を実施するための形態」でそのようなものとして具体的に定義される。

以下で紹介する実施形態は、プログラム可能回路によって実施することができ、このプログラム可能回路は、ソフトウェア及び／若しくはファームウェアによって、又は全体的に専用回路によって、又はこのような形態の組合せにおいてプログラム又は構成される。このような専用回路（ある場合）は、例えば、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）等の形態とすることができる。

説明する実施形態は、１つ又は複数のクレデンシャル・サービス・プロバイダを通じて、クレデンシャル所有者がリクエストしたクレデンシャルを検証する及び／又は新たなクレデンシャルを発行する、１つ又は複数の方法、システム、装置、及びプロセッサ実行可能プロセス・ステップを保存するコンピュータ可読媒体に関係する。

各個人は、クレデンシャルの証明を様々な状況で提示する必要がある。例えば、個人は、銀行口座を開設するには、運転免許証及び／又は他の身分証明書を提示する必要がある。個人は、事務所の建物にアクセスするには、運転免許証及び／又は在職証明書を提示する必要がある。個人は、バーでアルコールを購入するには、運転免許証及び／又は誕生日が記載された他の文書を提示する必要がある。高度なブロックチェーン技術の場合、デジタル・クレデンシャルは、従来の印刷されたクレデンシャルに取って代わることができる。この詳細な説明では、クレデンシャル・サービス・プロバイダを通じたデジタル・クレデンシャルの検証及び発行を説明する。

図１は、検証者、例えばＩＢＭ（登録商標）事務所管理者が、クレデンシャル所有者、例えば訪問者Ｊｏｈｎ Ｓｍｉｔｈがリクエストしたクレデンシャルの証明を、直接的に検証者とクレデンシャル所有者との間を通じてではなく、対応するクレデンシャル・サービス・プロバイダ、例えばＩＢＭ及び訪問者の通信事業者を通じて達成する一実施形態を示す。
検証者であるＩＢＭ事務所管理者は、クレデンシャル所有者であるＪｏｈｎ Ｓｍｉｔｈに、彼のクレデンシャル、ここでは、運転免許証及び社員バッジに関する情報の両方の提示を求める。クレデンシャル所有者であるＪｏｈｎ Ｓｍｉｔｈは、リクエスト・デバイス１１０、例えば携帯電話又は他のインターネット・デバイスを使用し、第１のクレデンシャル・サービス・プロバイダ、例えば、Ｊｏｈｎが加入する日本の通信事業者であるソフトバンク（登録商標）社の第１のクレデンシャル管理システム１２０にリクエストを送信する。別の実施形態では、クレデンシャル所有者及び検証者は、同じクレデンシャル・サービス・プロバイダからのクレデンシャル管理サービスに加入する。この状況では、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムは、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムと同じとすることができる。

第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システム１２０は、ＱＲコードを生成し、ＱＲコードをリクエスト・デバイス１１０に返送する。ＱＲコードは、第１のクレデンシャル管理システムの共有クレデンシャル・トークン及びサービス・エンドポイントに関する情報を含む。このような情報は、他の形態及び形式で表され、送信することができる。次に、クレデンシャル所有者であるＪｏｈｎは、リクエスト・デバイス１１０上のＱＲコードを検証者であるＩＢＭ事務所管理者に提示し、検証者は、検証デバイス１４０、例えば携帯電話又はインターネット・デバイスを使用してＱＲコードをスキャンする。検証デバイス１４０は、第２のクレデンシャル・サービス・プロバイダ、例えば、ＩＢＭが加入する米国の通信事業者ＡＴＴにＱＲコードを送信する。第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システム１５０は、ＱＲコードを受信する。第２のクレデンシャル管理システム１５０は、ＱＲコード内の情報から、クレデンシャルの証明のために交信される第１のクレデンシャル管理システム１２０を識別する。次に、ＡＴＴの第２のクレデンシャル管理システム１５０は、ソフトバンクの第１のクレデンシャル管理システム１２０と直接通信し、クレデンシャルの証明を得る。

検証を実施するため、第２のクレデンシャル管理システム１５０は、分散アイデンティティ・ブロックチェーン１７０内に保存した分散台帳からブロックチェーン１７０の第２のノード１６０を介してクレデンシャル検証情報を抽出することも必要とする。一実施形態では、ブロックチェーン１７０の第１のノード１３０は、第１のクレデンシャル・サービス・プロバイダ、例えばソフトバンクによって稼働され、ブロックチェーン１７０の第２のノード１６０は、第２のクレデンシャル・サービス・プロバイダ、例えばＡＴＴによって稼働される。検証者であるＩＢＭ事務所管理者が、リクエストされたクレデンシャルの検証に成功すると、検証者は、事務所へのアクセス許可（新たなクレデンシャル）をクレデンシャル所有者、例えばＪｏｈｎ Ｓｍｉｔｈに発行する。事務所へのアクセス許可は、個別のＱＲコードによって表すか、又は更には他の形態／形式で表すことができる。

第１のクレデンシャル管理システム及び第２のクレデンシャル管理システムのそれぞれは、安全なデータベース、プロセッサ、メモリ、入出力インターフェース、ワイヤレス通信構成要素等を有するサーバとすることができる。通信事業者の他に、第１のクレデンシャル・サービス・プロバイダ及び第２のクレデンシャル・サービス・プロバイダのそれぞれは、あらゆる他の種類の会社、組織及び協会とすることができる。

クレデンシャル所有者は、個人、法人、又は会社、組合及び政府等の組織とすることができる。個人は、運転免許証、パスポート、卒業証明書、雇用記録等、広範囲の様々なクレデンシャルを所有することができる。法人も、会社設立認可証、特許証等、様々なクレデンシャルを所有することができる。
各クレデンシャル所有者は、ｄｉｄ．ｓｏｖｒｉｎ．Ｖ４ＳＤＲＮ８４Ｚ５６ｄ７ＹＶ７ＰＢＵｅ６ｆ等のＤＩＤ（分散識別子、ｄｅｃｅｎｔｒａｌｉｚｅｄ ｉｄｅｎｔｉｆｉｅｒ）を有する。ＤＩＤは、ウォレット・アドレスと同様に、所有者又は所有者のクレデンシャル・サービス・プロバイダによって生成されるグローバル固有識別子である。ＤＩＤは、関連する公開鍵及び通信エンドポイントを有する。通信エンドポイントとは、ＤＩＤ識別のため、メッセージを配信することができるアドレスがある場所である。ＤＩＤのクレデンシャル所有者は、ウォレット内に対応する秘密鍵を保持し、秘密鍵は、クレデンシャル・サービス・プロバイダによって管理することができる。各ウォレット・アドレスが仮想ウォレットに変化するのと同様に、各ＤＩＤは、ＤＩＤを記述するデータ・セットを含むＤＩＤドキュメントに変化し、ＤＩＤの所有権及び管理を証明し、暗号鍵及びリソース・ポインタ（エンドポイント）を共有する。

各クレデンシャルは、いくつかの属性を有する。例えば、運転免許クレデンシャルは、運転免許番号、姓、名、誕生日、身長、体重、性別、写真、署名、有効期限及び発行日といった属性を有することができる。クレデンシャル・スキーマは、属性データ種及び形式のセットの機械可読定義であり、クレデンシャルに関する請求に使用することができる。各クレデンシャルは、クレデンシャル・スキーマを有する。例えば、運転免許証クレデンシャルを生成するスキーマは、上記した属性の定義を含む。発行者は、スキーマを使用し、スキーマ及び属性に固有の公開検証鍵を含む独自のクレデンシャル定義を生成することができ、この公開検証鍵は、発行者の秘密署名鍵と対になっている。例えば、カリフォルニア州ＤＭＶ（車両管理局）は、分散アイデンティティ・ブロックチェーン内に保存した独自の運転免許証クレデンシャル定義を有する。したがって、検証者又はクレデンシャル・サービス・プロバイダは、カリフォルニア州運転免許証クレデンシャル定義を抽出し、クレデンシャル所有者又はクレデンシャル・サービス・プロバイダが提供したデータの出所及び完全性を検証することができる。

発行者は、通常、政府機関、教育機関及び会社である。例えば、カリフォルニア州ＤＭＶは、カリフォルニア州運転免許証を発行することができる。国務省は、パスポートを米国民に発行することができる。スタンフォード大学は、卒業生に卒業証書／証明書を発行することができる。ＩＢＭは、社員バッジを従業員に発行することができる。
いくつかの必要とされるクレデンシャルを検証した後、発行者、例えばカリフォルニア州ＤＭＶは、クレデンシャル、例えば、カリフォルニア州運転免許証を個人、例えばＪｏｈｎ Ｓｍｉｔｈに発行することができる。発行者又は発行者のクレデンシャル・サービス・プロバイダは、個人又は個人のクレデンシャル・サービス・プロバイダにクレデンシャル・オファーを送信する。このようなクレデンシャル・オファーは、クレデンシャル所有者の秘密鍵で署名され、クレデンシャル・リクエストを生成し、クレデンシャル・リクエストを発行者に返送する。次に、クレデンシャル・リクエストは、発行者の秘密鍵で署名され、クレデンシャル、例えば運転免許証を生成し、クレデンシャルは、携帯デバイスのウォレット内にクレデンシャルを保存するクレデンシャル所有者、又はクレデンシャル所有者のクレデンシャル・サービス・プロバイダのクレデンシャル管理システムに送信される。

分散アイデンティティ・ブロックチェーン１７０は、複数のノードを含む。一実施形態では、第１のノード１３０は、第１のクレデンシャル・サービス・プロバイダによって稼働され、第２のノード１６０は、第２のクレデンシャル・サービス・プロバイダによって稼働される。一実施形態では、ＴＢＣＡＳＯＦＴ社（「ＴＢＣＡ」）は、分散アイデンティティ・ブロックチェーン１７０の管理者とすることができる。ＴＢＣＡは、クレデンシャル・サービス・プロバイダが、ブロックチェーン１７０のノードを稼働し、ノードの一部を選択し、合意機構のための検証者として働かせるのを許可することができる。
発行者及びクレデンシャル所有者は、クレデンシャル・サービス・プロバイダを通じて、分散台帳のブロック内の関連情報を記録することによって、ＤＩＤを生成し、ＤＩＤ、関連する公開鍵、クレデンシャル・スキーマ、クレデンシャル定義、及びリボケーション・アキュミュレータをブロックチェーン１７０内で発行する。プライバシ保護のため、クレデンシャル、生体情報（写真及び指紋等）、ＤＩＤに関連する秘密鍵、検証ログ、リボケーション・テイル・ファイルは、ブロックチェーン１７０内に記録されない。一実施形態では、これらの一部又は全部を、クレデンシャル・サービス・プロバイダが稼働するクレデンシャル管理システム内に保存することができる。生体情報データのサイズのため、生体情報は、契約業者が稼働するデータベース内に個別に保存することができる。

クレデンシャルは、クレデンシャル所有者の携帯デバイスではなく、クレデンシャル・サービス・プロバイダが稼働するクレデンシャル管理システム内に保存することが有益である。これにより、証明の生成及び検証の両方がクレデンシャル・サービス・プロバイダによって実施され、証明がクレデンシャル・サービス・プロバイダの間で直接転送されるようにする。このような構成は、クレデンシャル所有者と検証者との間の連携を簡略化し得るため、クレデンシャル検証工程を促進し、ユーザ・エクスペリエンスを改善することができる。例えば、双方向通信ではなく、クレデンシャル所有者は、共有クレデンシャル・トークン及びサービス・エンドポイントに関する情報を含むＱＲコードを検証者に提示するだけでよく、全ての他の工程は、クレデンシャル・サービス・プロバイダによって賄われる。更に、上記のように、一実施形態では、第１のクレデンシャル・サービス・プロバイダ及び第２のクレデンシャル・サービス・プロバイダが、通信事業者（ｔｅｌｃｏ）であることが有益である。通信事業者は、トラスト・アンカーとして機能することが有益である。というのは、通信事業者は、高度に規制された産業であり、より良好なプライバシ安全性及び保護をクレデンシャル保有者に提供することができるためである。更に、クレデンシャル所有者の携帯デバイスにクレデンシャルを保存することと比較して、このような構成では、クレデンシャル所有者は、携帯デバイスを紛失してもクレデンシャルを紛失することがない。

図２は、リクエストされたクレデンシャルを検証するプロセス・フローの一実施形態を示す。ステップ２１０において、リクエスト・デバイス１１０は、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システム１２０にリクエストを送信する。一実施形態では、リクエストは、検証要件ドキュメント（ｖｅｒｉｆｉｃａｔｉｏｎ ｒｅｑｕｉｒｅｍｅｎｔ ｄｏｃｕｍｅｎｔ、「ＶＲＤ」）を含むことができ、検証要件ドキュメントには、必要とされる属性のリスト、及び１つ又は複数の許容可能なクレデンシャルを含み、各属性は、１つ又は複数の許容可能なクレデンシャルから選択することができる。
ＶＲＤは、検証の目的に基づき、検証者によって最初に生成される。しかし、適切な証明を生成するため、第１のクレデンシャル管理システムは、ＶＲＤをいくつかの異なる経路から受信することができる。第１の経路において、リクエストは、ＶＲＤを含む。というのは、クレデンシャル所有者は、検証者からＶＲＤを事前に受信しているか、又は発行者のＶＲＤを維持するデータベース若しくはルックアップ・テーブルからＶＲＤを得ているためである。別の実施形態では、全ての発行者のＶＲＤは、データベース内に保存することができ、各ＶＲＤにＩＤが割り当てられる。したがって、リクエストは、クレデンシャル検証識別情報を含むことができ、クレデンシャル検証識別情報は、ＶＲＤ ＩＤを更に含むことができる。ＶＲＤ ＩＤは、第１のクレデンシャル管理システムに提供され、次に、第１のクレデンシャル管理システムは、全ＶＲＤをデータベースから抽出することができる。代替的に、検証者のＶＲＤ又はＶＲＤ ＩＤは、ステップ２３０で送信される証明リクエストに関連して、第２のクレデンシャル管理システムによって第１のクレデンシャル管理システムに提供することができる。

リクエスト・デバイスは、第１のクレデンシャル管理システム及び検証デバイスと通信し得る携帯電話又はあらゆる他の可搬電子デバイスとすることができる。共有クレデンシャル・トークン及びサービス・エンドポイントを提供する前に、第１のクレデンシャル管理システムは、リクエスト・デバイスのＩＤに基づき、クレデンシャル所有者のリクエスト・デバイスを認証することができる。一実施形態では、リクエスト・デバイスのＩＤは、国際移動体装置識別番号である。

図３は、検証要件ドキュメントの一実施形態を示す。図３に示す検証要件ドキュメントは、４つの属性、即ち、名前、誕生日、社会保障番号及び雇用主を必要とする。これらの属性のそれぞれは、所定の許容可能なクレデンシャルの１つから選択する必要がある。例えば、「名前」属性の内容は、運転免許証クレデンシャル又はパスポート・クレデンシャルのいずれかから選択する必要がある。「誕生日」属性の内容は、運転免許証クレデンシャル又はパスポート・クレデンシャルのいずれかから選択する必要がある。「社会保障番号」属性の内容は、社会保障カード・クレデンシャルから選択する必要がある。「雇用主」属性の内容は、クレデンシャル・サービス・プロバイダによって検証された任意の発行者から選択する必要がある。各クレデンシャルは、ｖ１及びｖ２等、クレデンシャル・バージョンのバージョンで関連付けられる。いくつかの属性の事実データは、検証者に明らかにする必要がある。その他の属性に関しては、属性の述語で十分である（ゼロ知識証明）。

図２に示すステップ２２０において、第１のクレデンシャル管理システム１２０は、共有クレデンシャル・トークン及びサービス・エンドポイントを生成する。共有クレデンシャル・トークンは、タイムスタンプに基づき生成されるグローバル固有ＩＤを含む。サービス・エンドポイントは、ポートであり、このポート上で、第２のクレデンシャル管理システム１５０は、第１のクレデンシャル管理システム１２０と接続し、証明リクエストを送信することができる。一実施形態では、サービス・エンドポイントは、８．８．９．９：９０９０のように見える。一実施形態では、共有クレデンシャル・トークン及びサービス・エンドポイントの両方の情報は、ＱＲコードに変換される。一実施形態では、共有クレデンシャル・トークン及びサービス・エンドポイントを含むＱＲコードは、クレデンシャル所有者の事前承認として事前に生成することができ、このクレデンシャルは、後に検証される。
ステップ２２２において、共有クレデンシャル・トークン及びサービス・エンドポイントの両方（又はそのような情報を含むＱＲコード）は、クレデンシャル所有者のリクエスト・デバイス１１０に返送される。ステップ２２４において、共有クレデンシャル・トークン及びサービス・エンドポイントの両方は、クレデンシャル所有者のリクエスト・デバイス１１０によって、短距離通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ（登録商標）又は他の手段を介して検証者の検証デバイス１４０に提供することができる。代替的に、クレデンシャル所有者は、リクエスト・デバイス１３０内の共有クレデンシャル・トークン及びサービス・エンドポイントの情報を含むＱＲコードを検証者に提示することができ、検証者は、検証デバイス１４０でＱＲコードをスキャンする。ステップ２２６において、共有クレデンシャル・トークン及びサービス・エンドポイントの両方（又はそのような情報を含むＱＲコード）は、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システム１５０に提供される。

第２のクレデンシャル管理システム１５０は、ポートを識別し、サービス・エンドポイントに基づき、第１のクレデンシャル管理システム１２０に接続する。ステップ２３０において、第２のクレデンシャル管理システム１５０は、証明リクエストを第１のクレデンシャル管理システム１２０に送信する。証明リクエストは、共有クレデンシャル・トークンを含むことができる。一実施形態では、第２のクレデンシャル管理システム１５０は、検証者のＶＲＤ又はＶＲＤ ＩＤも第１のクレデンシャル管理システム１２０に送信する。

ステップ２４０において、第１のクレデンシャル管理システム１２０は、共有クレデンシャル・トークンが有効であるかどうかを決定する。一実施形態では、共有クレデンシャル・トークンは、経過時間が所定の期間を超えた場合、無効である。次に、共有クレデンシャル・トークンが有効である場合、ステップ２４２において、第１のクレデンシャル管理システム１２０は、ＶＲＤに基づき、１つ又は複数のクレデンシャルから１つ又は複数の属性をそれぞれ選択する。共有クレデンシャル・トークンが無効である場合、検証は失敗する。ステップ２４４において、第１のクレデンシャル管理システム１２０は、各選択属性に対し、明らかにされる属性及び／又はゼロ知識証明アルゴリズムによる述語属性を生成し、次に、各選択属性を含む証明を生成する。

ステップ２４６において、第１のクレデンシャル管理システム１２０は、証明を第２のクレデンシャル管理システム１５０に送信する。ステップ２５０において、第２のクレデンシャル管理システム１５０は、分散アイデンティティ・ブロックチェーン１７０の第２のノード１６０に、分散アイデンティティ・ブロックチェーン１７０内に保存した分散台帳からクレデンシャル暗号情報を抽出することをリクエストする。クレデンシャル暗号情報には、スキーマ、スキーマ定義、発行者の公開鍵、クレデンシャル所有者の公開鍵を含む。

ステップ２５５において、第２のノード１６０は、上記クレデンシャル暗号情報を第２のクレデンシャル管理システム１５０に戻す。ステップ２６０において、第２のクレデンシャル管理システム１５０は、分散台帳から抽出した上記クレデンシャル暗号情報に基づき、証明を検証する。ゼロ知識証明アルゴリズムは、証明を検証するために使用することができる。

図４は、図１と同様の一実施形態を示し、発行者、例えばＩＢＭ事務所管理者は、新たなクレデンシャル、即ち、事務所への１日アクセス許可を、クレデンシャル所有者、例えば訪問者であるＪｏｈｎ Ｓｍｉｔｈに、発行者とクレデンシャル所有者との間で直接発行するのではなく、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システム１２０、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システム１５０、例えばＩＢＭの通信事業者であるＡＴＴ、及び訪問者の通信事業者であるソフトバンクを通じて発行する。
別の実施形態では、クレデンシャル所有者及び発行者は、同じクレデンシャル・サービス・プロバイダからのクレデンシャル管理サービスに加入することができる。この状況では、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムは、第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムと同じとすることができる。

図５は、新たなクレデンシャルを発行するプロセス・フローの一実施形態を示す。本実施形態は、第２のサービス・プロバイダの第２のクレデンシャル管理システム１５０が、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システム１２０のサービス・エンドポイントを有すると仮定する。１つの可能性として、第２のクレデンシャル管理システム１５０が、クレデンシャル検証を実施した際に、以前は検証者としての役割を果たした発行者のためにサービス・エンドポイントを受信したということがある。別の実施形態では、クレデンシャル所有者のリクエスト・デバイス１１０は、このようなサービス・エンドポイントを、検証者を介して第２のクレデンシャル管理システムに提供することができる。始めに、クレデンシャル所有者は、新たなクレデンシャルをリクエストする。発行者は、発行者が新たなクレデンシャル・リクエストを承認した場合、第２のクレデンシャル管理システムに通知する。
ステップ５１０において、第２のクレデンシャル管理システムは、発行者のためにクレデンシャル・オファーを生成し、このクレデンシャルには、新たなクレデンシャルに対して必要とされる属性のデータ、例えば、訪問者の名前及び事務所への１日アクセス許可日を含む。ステップ５２０において、第２のクレデンシャル管理システム１５０は、クレデンシャル・オファーを第１のクレデンシャル管理システム１２０に送信する。ステップ５３０において、第１のクレデンシャル管理システム１２０は、クレデンシャル所有者の秘密鍵でクレデンシャル・オファーに署名し、クレデンシャル・リクエストを生成する。ステップ５４０において、第１のクレデンシャル管理システム１２０は、クレデンシャル・リクエストを第２のクレデンシャル管理システム１５０に返送する。ステップ５５０において、第２のクレデンシャル管理システム１５０は、発行者の秘密鍵でクレデンシャル・リクエストに署名し、新たなクレデンシャルを生成する。ステップ５６０において、第２のクレデンシャル管理システム１５０は、新たなクレデンシャルを第１のクレデンシャル管理システム１２０に送信する。ステップ５７０において、第１のクレデンシャル管理システム１２０は、クレデンシャル所有者のための新たなクレデンシャルを保存し、クレデンシャル所有者に通知する。
以下は、以下のプロセス・ステップを実施する擬似コードの一実施形態であり、検証者は、検証に成功した場合、第２の段階で発行者になる。
１．クレデンシャル所有者のリクエスト・デバイスは、共有クレデンシャル・トークン及びサービス・エンドポイントの情報を含むＱＲコードをリクエストする。
２．第１のクレデンシャル管理システムは、共有クレデンシャル・トークン及びサービス・エンドポイントの情報を含むＱＲコードを生成する。
３．検証者の検証デバイスは、リクエスト・デバイスからのＱＲコードをスキャンする。検証デバイスは、第２のクレデンシャル管理システムを呼び出し、クレデンシャルを検証する。
４．第２のクレデンシャル管理システムは、検証を必要とするクレデンシャル所有者の許容可能クレデンシャルの属性を載せたＶＲＤに基づき、証明リクエストを生成する。第１のクレデンシャル管理システムは、検証デバイスが提供したサービス・エンドポイントに基づき識別される。
５．第１のクレデンシャル管理システムは、証明リクエストに基づき証明を生成する。証明は、第２のクレデンシャル管理システムに送信される。
６．第２のクレデンシャル管理システムは、証明を検証する。
７．検証に成功した場合、発行者（以前の検証者）の発行デバイス（例えば以前の検証デバイス）は、「発行」ＡＰＩを呼び出すことによってフォームに書き込み、このフォームを第２のクレデンシャル管理システムに送信する。
８．第２のクレデンシャル管理システムは、クレデンシャル・オファーを生成し、次に、クレデンシャル・オファーを第１のクレデンシャル管理システムに送信する。
９．第１のクレデンシャル管理システムは、クレデンシャル・リクエストを生成し、次に、クレデンシャル・リクエストを第２のクレデンシャル管理システムに返送する。
１０．第２のクレデンシャル管理システムは、新たなクレデンシャルを生成し、次に、新たなクレデンシャルを第１のクレデンシャル管理システムに送信する。
１１．第１のクレデンシャル管理システムは、新たなクレデンシャルをクレデンシャル所有者のウォレット内に保存する。

本発明のクレデンシャルの検証及び発行方法、並びに関連する装置において、本発明の趣旨又は範囲から逸脱することなく様々な修正形態及び変形形態を行い得ることは当業者に明らかであろう。したがって、本発明は、添付の特許請求の範囲及びこれらの等価物の範囲内にある修正形態及び変形形態を含むことが意図される。

Claims (21)

1. クレデンシャル所有者がリクエストしたクレデンシャルを検証する方法であって、
   （ａ）リクエストに応じて、第１のクレデンシャル・サービス・プロバイダの第１のクレデンシャル管理システムによって、前記クレデンシャル所有者のリクエスト・デバイスに共有クレデンシャル・トークン及びサービス・エンドポイントを提供することと、
   （ｂ）第２のクレデンシャル・サービス・プロバイダの第２のクレデンシャル管理システムによって、検証者の検証デバイスから、前記クレデンシャル所有者の前記リクエスト・デバイスを通じて、前記共有クレデンシャル・トークン及び前記サービス・エンドポイントを受信することと、
   （ｃ）前記サービス・エンドポイントに基づき、前記第２のクレデンシャル・サービス・プロバイダの前記第２のクレデンシャル管理システムによって、前記第１のクレデンシャル・サービス・プロバイダの前記第１のクレデンシャル管理システムに証明リクエストを送信することと、
   （ｄ）前記第１のクレデンシャル・サービス・プロバイダの前記第１のクレデンシャル管理システムによって、前記証明リクエストに基づく証明を生成することと、
   （ｅ）前記第２のクレデンシャル・サービス・プロバイダの前記第２のクレデンシャル管理システムによって、分散台帳から抽出したクレデンシャル暗号情報に基づき、前記証明を検証することと、を含む、
   方法。
2. 前記ステップ（ａ）は、前記第１のクレデンシャル・サービス・プロバイダによって、前記リクエスト・デバイスのＩＤに基づき、前記クレデンシャル所有者の前記リクエスト・デバイスを認証することを更に含むことを特徴とする、請求項１に記載の方法。
3. 前記リクエスト・デバイスは、携帯電話であり、前記ＩＤは、国際移動体装置識別番号であることを特徴とする、請求項２に記載の方法。
4. 前記リクエストは、検証要件ドキュメントを含み、前記検証要件ドキュメントは、元来、前記検証者からのものであることを特徴とする、請求項１に記載の方法。
5. 前記検証要件ドキュメントは、１つ又は複数の属性、及び前記属性のそれぞれを選択し得る１つ又は複数のクレデンシャルを含むことを特徴とする、請求項４に記載の方法。
6. 前記リクエストは、クレデンシャル・リクエスト識別情報を含み、前記第１のクレデンシャル管理システムは、前記クレデンシャル・リクエスト識別情報に基づき、データベース又は分散台帳から、対応する１つ又は複数の属性、及び前記属性のそれぞれを選択し得る１つ又は複数のクレデンシャルを得ることを特徴とする、請求項１に記載の方法。
7. 前記クレデンシャル・リクエスト識別情報は、検証要件ドキュメントＩＤを含むことを特徴とする、請求項６に記載の方法。
8. 前記ステップ（ｃ）は、前記サービス・エンドポイントに基づき、前記第２のクレデンシャル・サービス・プロバイダの前記第２のクレデンシャル管理システムによって、前記第１のクレデンシャル・サービス・プロバイダの前記第１のクレデンシャル管理システムに証明リクエスト及び検証要件ドキュメントＩＤを送信することを含むことを特徴とする、請求項１に記載の方法。
9. 前記証明リクエストは、共有クレデンシャル・トークンを含むことを特徴とする、請求項１に記載の方法。
10. 前記共有クレデンシャル・トークンは、タイムスタンプに基づき生成されるグローバル固有ＩＤを含むことを特徴とする、請求項９に記載の方法。
11. 前記第１のクレデンシャル管理システムは、前記共有クレデンシャル・トークン及び前記サービス・エンドポイントをＱＲコード（登録商標）形式で提供することを特徴とする、請求項１に記載の方法。
12. 前記ステップ（ｄ）は、（ｄ１）前記共有クレデンシャル・トークンを認証することと、（ｄ１）検証要件ドキュメントに基づき、１つ又は複数のクレデンシャルから１つ又は複数の属性をそれぞれ選択することと、（ｄ２）前記第１のクレデンシャル・サービス・プロバイダの前記第１のクレデンシャル管理システムによって証明を生成するため、各選択属性に対し、明らかにされる属性、又はゼロ知識証明アルゴリズムによる述語属性を生成することと、を含むことを特徴とする、請求項１に記載の方法。
13. 前記証明は、検証要件ドキュメントに基づく属性の事実データ、又は前記属性の述語のいずれかを含むことを特徴とする、請求項１に記載の方法。
14. 前記クレデンシャル暗号情報は、クレデンシャル・スキーマ、クレデンシャル定義、クレデンシャル所有者の公開鍵、及び発行者の公開鍵を含むことを特徴とする、請求項１に記載の方法。
15. 前記第１のクレデンシャル・サービス・プロバイダ及び前記第２のクレデンシャル・サービス・プロバイダは、通信事業者であることを特徴とする、請求項１に記載の方法。
16. 前記第１のクレデンシャル・サービス・プロバイダは、前記第２のクレデンシャル・サービス・プロバイダと同じであることを特徴とする、請求項１に記載の方法。
17. 前記第１のクレデンシャル管理システムは、前記第２のクレデンシャル管理システムと同じであることを特徴とする、請求項１６に記載の方法。
18. （ｆ）前記第１のクレデンシャル管理システムによって、前記第２のクレデンシャル管理システムからクレデンシャル・オファーを受信することと、（ｇ）前記第１のクレデンシャル管理システムによって、前記クレデンシャル・オファーに基づき、クレデンシャル・リクエストを生成することと、（ｈ）前記第２のクレデンシャル管理システムによって、前記第１のクレデンシャル管理システムから受信した前記クレデンシャル・リクエストに基づき、新たなクレデンシャルを生成することと、を更に含む、請求項１に記載の方法。
19. （ｉ）前記第１のクレデンシャル管理システム又は前記リクエスト・デバイスによって、前記新たなクレデンシャルを受信し、保存すること、を更に含む、請求項１８に記載の方法。
20. 前記ステップ（ｇ）において、前記クレデンシャル・リクエストは、クレデンシャル所有者の秘密鍵で前記クレデンシャル・オファーに署名することによって生成されることを特徴とする、請求項１８に記載の方法。
21. 前記ステップ（ｈ）において、前記新たなクレデンシャルは、発行者の秘密鍵で前記クレデンシャル・リクエストに署名することによって生成されることを特徴とする、請求項１８に記載の方法。
    

Images