検証可能なクレデンシャル・データモデル v2.0

このセクションは非規範的です。

物理世界では、クレデンシャルは次のようなもので構成されることがあります。

• 主体を識別することに関する情報。クレデンシャルの 主体に関する情報 （たとえば、写真、名前、識別番号）
• 発行機関に関する情報（たとえば、市政府、 国家機関、認証機関）
• クレデンシャルの種類に関する情報（たとえば、 オランダのパスポート、アメリカの運転免許証、健康保険証）
• 発行機関が主体について主張する 特定の属性に関する情報（たとえば、国籍、 生年月日、運転資格のある車両区分）
• 主体が、クレデンシャルの発行に必要な 資格を満たしていることを示す証拠（たとえば、 測定値、市民権の証明、試験結果）
• クレデンシャルに対する制約に関する情報（たとえば、 有効期間、または利用条件）。

検証可能なクレデンシャルは、 物理的なクレデンシャルが表すのと同じ情報をすべて表すことができます。 デジタル署名などの技術を追加することで、検証可能なクレデンシャルを 物理的な対応物よりも改ざんが明らかで信頼できるものにできます。

保有者は、検証可能なクレデンシャルから 検証可能なプレゼンテーションを生成し、その後これらの 検証可能なプレゼンテーションを検証者と共有して、 特定の特性を持つ検証可能なクレデンシャルを保有していることを証明できます。

検証可能なクレデンシャルと検証可能なプレゼンテーションはいずれも 迅速に送信できるため、遠隔地で信頼を確立する際に、 物理的な対応物よりも便利です。

この仕様は、デジタルクレデンシャルを表現する容易さの向上を試みる一方で、 この目標と複数のプライバシー保護目標とのバランスを取ることも目指しています。 デジタル情報の永続性、および異なるデジタルデータ源を収集して相関させることの容易さは、 検証可能で容易に 機械可読なクレデンシャルの利用によって悪化するおそれのある プライバシー上の懸念を構成します。この文書は、セクション 8. プライバシー上の考慮事項で、これらの問題のいくつかを概説し、 対処を試みます。ゼロ知識証明などのプライバシー強化技術を使用して このデータモデルを利用する例も、この文書全体で提供されます。

検証可能なクレデンシャルおよび 検証可能なプレゼンテーションという用語における 「検証可能」とは、クレデンシャル またはプレゼンテーションが、この文書で定義されるように、検証者によって検証され得るという特性を指します。 クレデンシャルの検証可能性は、その中に符号化された主張の真実性を意味するものではありません。 そうではなく、検証可能なクレデンシャルまたは 検証可能なプレゼンテーションの真正性と現行性を確立した後、 検証者は、含まれる主張に依拠する前に、 自身のビジネス規則を用いてそれらを妥当性確認します。このような依拠は、 発行者、証明、主体、および主張を、1つ以上の検証者ポリシーに照らして 評価した後にのみ発生します。

このセクションは非規範的です。

このセクションでは、検証可能なクレデンシャルが 有用であると期待されるエコシステムにおける、中核的なアクターの役割と それらの関係について説明します。役割は、多くの異なる方法で実装され得る 抽象化です。役割の分離は、標準化に適したインターフェイスや プロトコルを示唆します。この仕様では、次の役割を導入します。

保有者

エンティティが、1つ以上の検証可能なクレデンシャルを保有し、それらから検証可能なプレゼンテーションを生成することによって 担う可能性のある役割です。保有者は多くの場合、常にではありませんが、 保有している検証可能なクレデンシャルの主体です。 保有者は自分のクレデンシャルをクレデンシャル・リポジトリに保存します。 保有者の例には、学生、従業員、顧客が含まれます。

発行者

エンティティが、1つ以上の 主体について主張を行い、これらの主張から検証可能なクレデンシャルを作成し、 その検証可能なクレデンシャルを保有者へ送信することによって 担うことのできる役割です。たとえば、発行者には 企業、非営利組織、業界団体、政府、個人が含まれます。

主体

主張が行われる対象となるものです。主体の例には、人間、 動物、物が含まれます。

検証者

エンティティが、処理のために1つ以上の検証可能なクレデンシャルを、任意で検証可能なプレゼンテーションの中に含めて受け取ることによって担う役割です。 検証者の例には、雇用主、警備担当者、Webサイトが含まれます。

検証可能データ・レジストリ

システムが、識別子、検証材料、およびその他の関連データの作成と検証を仲介することによって 担う可能性のある役割です。その他の関連データには、 検証可能なクレデンシャルのスキーマ、失効 レジストリなどがあり、それらは 検証可能なクレデンシャルの使用を 必要とする場合があります。一部の構成では、 主体の相関可能な識別子が必要になる場合があります。 UUIDや検証材料のためのものなど、一部のレジストリは、 識別子の名前空間として機能するだけの場合があります。 検証可能データ・レジストリの例には、信頼されたデータベース、 分散型データベース、政府IDデータベース、分散台帳が含まれます。多くの場合、 1つのエコシステムでは複数の種類の検証可能データ・レジストリが使用されます。

このエコシステムは、典型的な二者間モデルや連合アイデンティティ・ プロバイダー・モデルとは対照的です。アイデンティティ・プロバイダーは、 IdPと略されることもあり、保有者のアイデンティティ情報を作成、維持、管理しつつ、 連合または分散ネットワーク内の依拠当事者 アプリケーションに認証サービスを提供するシステムです。連合 アイデンティティ・モデルでは、保有者はアイデンティティ・プロバイダーに強く結び付けられます。 この仕様では、これらの概念を他の仕様と比較または対応付ける場合を除き、 「アイデンティティ・プロバイダー」、「連合アイデンティティ」、または 「依拠当事者」という用語の使用を避けます。この仕様は、 アイデンティティ・プロバイダーの概念を、発行者と保有者という2つの別個の概念に分離します。

検証可能なクレデンシャルのエコシステムの より深い検討と具体的なライフサイクル例については、Verifiable Credentials Overview [VC-OVERVIEW]を参照してください。

このセクションは非規範的です。

主張とは、主体についての文です。主体とは、 主張を行う対象となり得るものです。主張は、 主体- プロパティ-値の関係を使用して表現されます。

上の図2に示す主張のデータモデルは強力であり、非常に多様な文を表現するために使用できます。たとえば、 ある人が特定の大学を卒業したかどうかは、 下の図3に示すように表現できます。

個々の主張は結合され、主体に関する情報のグラフを表現できます。下の 図4に示す例では、前の主張を拡張し、 PatがSamを知っていること、およびSamが教授として雇用されていることを示す主張を追加しています。

ここまでで、主張と情報のグラフという概念を導入しました。 主張を信頼できるようにするには、 より多くの情報がグラフに追加されることが期待されます。

このセクションは非規範的です。

クレデンシャルとは、同じエンティティによって行われる、1つ以上の主張の集合です。 クレデンシャルには、発行者、有効な日時 および期間、代表画像、検証材料、ステータス 情報など、クレデンシャルのプロパティを説明する識別子やメタデータも 含まれる場合があります。 検証可能なクレデンシャルとは、だれが発行したかを暗号学的に証明する、 改ざんが明らかな主張とメタデータの集合です。検証可能なクレデンシャルの例には、 デジタル従業員識別カード、デジタル運転免許証、デジタル教育証明書などが含まれますが、 これらに限定されません。

上の図5は、 検証可能なクレデンシャルの基本構成要素を示していますが、 主張が情報グラフにどのように編成され、 さらにそれらが検証可能なクレデンシャルに どのように編成されるかについての詳細は抽象化しています。

下の図 6は、 Verifiable Credential Data Integrity 1.0に基づく埋め込み証明を使用した 検証可能なクレデンシャルの、より完全な描写を示しています。 これは少なくとも2つの情報グラフで構成されます。 これらの情報グラフの最初のもの、すなわち検証可能なクレデンシャル・グラフ （デフォルト・グラフ）は、クレデンシャル・メタデータおよびその他の主張を通じて、検証可能なクレデンシャルそのものを表現します。proofプロパティによって参照される 2つ目の情報グラフは、検証可能なクレデンシャルの 証明グラフであり、別個の 名前付きグラフです。証明グラフは デジタル証明を表現し、この場合はデジタル署名です。 複数の情報グラフが必要な理由に関心のある読者は、セクション 5.12 検証可能なクレデンシャル・グラフを参照できます。

下の図 7は、図 6と同じ検証可能なクレデンシャルを示していますが、 JOSE [VC-JOSE-COSE]を使用して保護されています。 ペイロードには、クレデンシャル・メタデータおよびその他の主張を含む検証可能なクレデンシャル・グラフである、 単一の情報グラフが含まれます。

このセクションは非規範的です。

プライバシーの強化は、この仕様の重要な設計上の特徴です。したがって、この 技術を使用するエンティティにとって、与えられた状況に適した 自分のペルソナの部分だけを表現することが重要です。自分のペルソナの一部を 表現することを検証可能なプレゼンテーションと呼びます。 異なるペルソナの例には、個人の職業上のペルソナ、 オンラインゲームのペルソナ、家族内のペルソナ、または匿名のペルソナがあります。

検証可能なプレゼンテーションは、保有者によって作成され、 複数の検証可能なクレデンシャルからのデータを表現でき、 任意の追加データを含めることができます。それらは、主張を 検証者に提示するために使用されます。検証可能なクレデンシャルを 直接提示することも可能です。

プレゼンテーション内のデータは、多くの場合、同じ主体に関するものですが、 複数の発行者によって発行されている場合があります。この情報の集約は、 人、組織、またはエンティティの一側面を表現します。

上の図8は、 検証可能なプレゼンテーションの構成要素を示していますが、 検証可能なクレデンシャルが情報 グラフにどのように編成され、 さらにそれらが検証可能なプレゼンテーションに どのように編成されるかについての詳細は抽象化しています。

下の図 9は、 Verifiable Credential Data Integrity 1.0に基づく埋め込み証明を使用した 検証可能なプレゼンテーションの、より完全な描写を示しています。 これは少なくとも4つの情報グラフで構成されます。 これらの情報グラフの最初のもの、すなわち検証可能なプレゼンテーション・グラフ （デフォルト・グラフ）は、プレゼンテーション・メタデータを通じて 検証可能なプレゼンテーションそのものを表現します。 検証可能なプレゼンテーションは、 verifiableCredentialプロパティを介して、 検証可能なクレデンシャルを参照します。 このクレデンシャルは、クレデンシャル・メタデータおよびその他の主張を含む、自己完結した検証可能なクレデンシャル・グラフです。このクレデンシャルは、 proofプロパティを介して検証可能なクレデンシャルの証明グラフを参照し、 クレデンシャルの 証明（通常はデジタル署名）を表現します。この検証可能なクレデンシャル・グラフと、それにリンクされた証明グラフは、 それぞれ2つ目と3つ目の情報グラフを構成し、それぞれが別個の 名前付きグラフです。プレゼンテーションも、 proofプロパティを介して、プレゼンテーションの証明グラフを参照します。これは 4つ目の情報グラフ（別の名前付きグラフ）です。この プレゼンテーションの証明グラフは、 検証可能なプレゼンテーション・グラフ、 検証可能なクレデンシャル・グラフ、および 検証可能なクレデンシャル・グラフからリンクされた証明グラフの デジタル署名を表します。

下の図 10は、図 9と同じ検証可能なプレゼンテーションを示していますが、 [VC-JOSE-COSE]に基づく包み込み 証明を使用しています。ペイロードには2つの情報 グラフだけが含まれます。すなわち、プレゼンテーション・メタデータを通じて検証可能なプレゼンテーションを表現する検証可能なプレゼンテーション・ グラフと、 verifiableCredential プロパティによって参照される、対応する 検証可能なクレデンシャル・グラフです。検証可能なクレデンシャル・グラフには、 data: URL [RFC2397]を介して、 図 7に示される包み込み証明で保護された 検証可能なクレデンシャルを参照する、単一の EnvelopedVerifiableCredential インスタンスが含まれます。

このセクションは非規範的です。

プライバシーには、仮名的なものから強く識別されるものまでの範囲があることを 認識することが重要です。ユースケースによって、人々は提供してもよいと考える情報や、 そこから導出され得る情報について、異なる安心度を持ちます。

プライバシー・ソリューションはユースケースに固有です。 たとえば、アルコールを購入する際、規制が購入者が特定の年齢を 超えているかどうかの確認だけであるため、多くの人は匿名のままであることを好みます。 これに対して、医療専門家が患者のために書いた処方箋を調剤する場合、 薬局は、処方者と患者の両方をより強く識別することを法的に要求されます。 すべてのユースケースに適用できる単一のプライバシー・アプローチはありません。

検証可能なクレデンシャル・データモデルは、プライバシーの全範囲をサポートすることを 目指しており、特定の取引における正しい匿名性レベルについて哲学的な立場を取りません。 以下のセクションは、プライバシーに敵対的な特定のシナリオを回避したい実装者を 導くものです。

このセクションは非規範的です。

この仕様で説明されるエコシステムには、さまざまな信頼関係が存在します。 Webブラウザーを使用する個人は、Webブラウザー（ユーザーエージェントとも呼ばれる）を、 自分の個人情報をデータブローカーへアップロードしないことによってその信頼を維持するものとして信頼します。 同様に、この仕様で説明されるエコシステムの各役割を担うエンティティは、 それらの各役割の代理として動作するソフトウェアを信頼します。 例には次が含まれます:

• 発行者の ユーザーエージェント （発行者ソフトウェア）、たとえばオンライン教育プラットフォームは、 発行者がその教育プログラムを修了したと主張する個人にのみ 検証可能なクレデンシャルを発行することが期待されます。
• 検証者の ユーザーエージェント （検証ソフトウェア）、たとえば採用Webサイトは、そのような個人によって プラットフォームに提供された検証可能なクレデンシャルおよび検証可能なプレゼンテーションについて有効な検証ステータスを持つ個人にのみ アクセスを許可することが期待されます。
• 保有者の ユーザーエージェント （保有者ソフトウェア）、たとえばデジタルウォレットは、 保有者がその情報の公開に同意した場合にのみ、 検証者へ情報を開示することが期待されます。

上記の例は網羅的ではなく、これらの役割のユーザーは、自分たちの目標を達成するために 使用するソフトウェアに対して、その他さまざまなことも期待できます。 要するに、ユーザーはソフトウェアがユーザーの最善の利益のために動作することを期待します。 この期待に対するあらゆる違反は信頼を損ない、ソフトウェアがより信頼できる代替物に 置き換えられることにつながります。実装者には、ユーザーの信頼を保つソフトウェアを 作成することが強く推奨されます。さらに、ユーザーまたは信頼された第三者が、 ソフトウェアが自らの最善の利益に沿って動作していることを検証できるようにする 監査機能を含めることも推奨されます。

読者には、単一の検証者および複数の保有者にサービスを提供するWebサイトのような 一部のソフトウェアは、両方の役割に対してユーザーエージェントとして 動作し得る一方で、必ずしもすべての当事者の最善の利益のために同時に 動作できるわけではないことに注意してください。たとえば、Webサイトが複数の保有者の間で検証可能なクレデンシャルの不正使用の試みを検出したとします。 その場合、そのような異常を検証者に報告する可能性があり、 これはすべての保有者の最善の利益にはならないと考えられるかもしれませんが、 検証者およびそのような違反をしていない保有者の最善の利益にはかなっています。 ソフトウェアがこのように動作する場合には、Webサイト利用ポリシーなどの メカニズムを通じて、そのソフトウェアが誰の最善の利益のために動作しているのかを 明確にすることが不可欠です。

このセクションは非規範的です。

credential.credentialSubjectプロパティに格納される 検証可能なクレデンシャルに関連付けられたデータは、 検証者と共有されるときにプライバシー侵害を受けやすくなります。 政府発行の識別子、配送先住所、または氏名のような個人を識別するデータは、 エンティティを判定、追跡、および相関するために 容易に使用できます。生年月日と郵便番号の組み合わせのように、 個人識別情報には見えない情報であっても、強力な相関および非匿名化の 能力を持ちます。

保有者が使用するソフトウェアの実装者には、 このような特徴を持つデータを共有する際に 保有者へ警告することが強く推奨されます。 発行者には、可能な場合にはプライバシー保護型の検証可能なクレデンシャルを提供することが強く推奨されます。たとえば、 検証者がエンティティが18歳以上かどうかを判定したい場合に使用するため、 dateOfBirth 検証可能なクレデンシャルの代わりに ageOver 検証可能なクレデンシャルを発行することです。

検証可能なクレデンシャルにはしばしば個人識別情報（PII）が含まれるため、 実装者には、検証可能なクレデンシャルの保存および転送時に、 そのデータへアクセスすべきでない者からデータを保護するメカニズムを使用することが 強く推奨されます。検討できるメカニズムには、転送中のデータを暗号化する Transport Layer Security（TLS）またはその他の手段、ならびに保存時の 検証可能なクレデンシャル内のデータを保護するための 暗号化またはアクセス制御メカニズムが含まれます。

一般に、個人には、検証可能なクレデンシャルは、 多くの物理的なクレデンシャルと同様に、共有時に個人識別情報を 漏えいさせるものと想定することが推奨されます。そのような漏えいに対抗するため、 検証可能なクレデンシャルおよびその 保護メカニズムは、相関を防ぐよう慎重に設計される必要があります。 個人識別情報の漏えいから保護するよう特別に設計された 検証可能なクレデンシャルが利用可能です。 個人および実装者には、個人識別情報を保護するよう設計されていないものよりも、 これらのクレデンシャル型を選択することが推奨されます。

このセクションは非規範的です。

検証可能なクレデンシャルには、個人を相関するために使用され得る 長寿命の識別子が含まれる場合があります。これらの識別子には、 主体 識別子、メールアドレス、政府発行の識別子、組織発行の識別子、住所、 医療上のバイタル情報、およびその他多くの長寿命識別子が含まれます。 保有者向けソフトウェアの実装者には、 個人を相関するために使用され得る検証可能なクレデンシャル内の 識別子を検出し、この情報を共有する前に 保有者へ警告することが推奨されます。 このセクションの残りでは、長寿命識別子の使用に関連するガイダンスを詳述します。

主体 of 検証可能なクレデンシャルは、 セクション4.4 識別子で定義され、 credentialSubject.idプロパティなどで使用されるid プロパティを使用して識別されます。主体を識別するために使用される識別子は、 長寿命である場合や複数のWebドメインにまたがって使用される場合、より大きな相関リスクを生みます。 このカテゴリに該当するその他の種類の識別子には、メールアドレス、政府発行の識別子、 および組織発行の識別子があります。

同様に、（例 3のように）クレデンシャル識別子を開示すると、複数の 検証者、または発行者と検証者が共謀して 保有者を相関できる状況につながる可能性があります。

相関を減らすことを目指す保有者には、 検証可能なクレデンシャルから、検証可能なプレゼンテーション内の相関識別子を 選択的に開示することをサポートする発行者のものを使用することが推奨されます。 そのようなアプローチでは、保有者が識別子を生成することが期待され、 ブラインド署名のような技術を通じて 発行者から識別子を隠すことさえ可能にしながら、 それでも識別子を検証可能なクレデンシャル内に埋め込み、署名された状態に保ちます。

保護メカニズム仕様の著者には、 選択的に開示できない相関識別子の使用を避けるよう技術を設計することにより、 識別子に基づく相関を可能にしないことが推奨されます。

検証可能なクレデンシャルシステムにおいて 強力な反相関特性が必要な場合、識別子が次の基準の1つ以上を満たすことが不可欠です:

• 選択的に開示可能である
• 単一のオリジンに結び付けられている
• 単回使用である
• 使用されず、代わりに短寿命で単回使用のベアラー・トークンに置き換えられている。

このセクションは非規範的です。

検証可能なクレデンシャルの内容は、 保護メカニズムを使用して保護されます。保護メカニズムを表す値は、 複数のセッションまたはドメインにわたって同じままである場合、より大きな 相関リスクをもたらします。これらの例には、次の値が含まれます:

• デジタル署名のバイナリ値
• デジタル署名の作成に関連付けられたタイムスタンプ情報
• 公開鍵識別子など、デジタル署名に関連付けられた暗号材料

強力な反相関特性が必要な場合、発行者には、 署名値およびメタデータを各検証可能なプレゼンテーションごとに 再生成できる検証可能なクレデンシャルを生成することが推奨されます。 これは、Data Integrity BBS Cryptosuites v1.0仕様のような、リンク不能な開示をサポートする 技術を使用して実現できます。可能な場合、検証者には、 保有者および主体のプライバシーを強化するために、 この技術を使用する検証可能なプレゼンテーションを優先することが推奨されます。

このセクションは非規範的です。

セクション 4. 基本概念およびセクション5. 高度な 概念で説明されているような異なる拡張ポイントは、 特定の拡張型または型の組み合わせを使用する発行者が比較的少ない場合、 意図せず、または望ましくない形で相関メカニズムとして機能する可能性があります。 たとえば、特定の国家に固有の暗号メソッド、特定の法域に固有の失効形式、 または特定の地域で採用されているクレデンシャル型を使用すると、 保有者が 検証者へ情報を選択的に開示する際に期待し得る仮名性を 低下させるメカニズムとして機能する可能性があります。

発行者には、仮名的な利用を意図した 検証可能なクレデンシャルを発行する際、 保有者の仮名性を低下させ得る拡張の種類を 制限することにより、メタデータに基づく相関リスクを最小化することが推奨されます。 グローバルに採用されているクレデンシャル型、拡張、および技術プロファイルが 最も望ましく、次に国家単位で使用されているものが続き、ローカルでのみ 使用されるものは最も望ましくありません。

このセクションは非規範的です。

インターネットおよびWeb上の個人を追跡し相関する、検証可能なクレデンシャルの外部にあるメカニズムが 存在します。これらのメカニズムには、インターネットプロトコル（IP）アドレス追跡、 Webブラウザー・フィンガープリンティング、evercookies、広告ネットワーク・トラッカー、 モバイルネットワーク位置情報、およびアプリ内Global Positioning System（GPS）APIが含まれます。 検証可能なクレデンシャルを使用しても、これらの他の 追跡技術の使用を防ぐことはできません。むしろ、これらの技術を 検証可能なクレデンシャルと併用することで、新たな相関可能情報が 明らかになる可能性があります。たとえば、生年月日とGPS位置を組み合わせると、 複数のWebサイトにわたって個人を強く相関できます。

プライバシーを尊重するシステムは、他の追跡技術と 検証可能なクレデンシャルの組み合わせを 防ぐことを目指すべきです。場合によっては、 保有者に代わって 検証可能なクレデンシャルを送信するデバイス上で、 追跡技術を無効にする必要があるかもしれません。

Oblivious HTTPプロトコル [RFC9458] は、 検証可能なクレデンシャルまたは検証可能なプレゼンテーションに関連付けられた外部リソースを取得する際に、 実装者が使用を検討できるメカニズムの1つです。 Oblivious HTTPにより、クライアントは、オリジンサーバーがそれらの要求を そのクライアントに結び付けることも、それらの要求が単一のクライアントから 来たものであると識別することすらできないようにしつつ、オリジンサーバーへ複数の 要求を行うことができます。その一方で、メッセージの転送に使用されるノードへの信頼は 限定的で済みます。Oblivious HTTPは、デバイス追跡およびフィンガープリンティングの 可能性を低減できる、プライバシー保護メカニズムの1つです。以下は、 Oblivious HTTPがエコシステム参加者にもたらし得る利点の具体例です。

• デジタルウォレットを使用する保有者は、 自分のデジタルウォレットに保存された 検証可能なクレデンシャル内の外部リンクへアクセスする際に、 第三者によって追跡される可能性を減らすことができます。 たとえば、デジタルウォレットはリンクされた画像を取得してレンダリングしたり、 外部リンクされた失効リストを取得することで検証可能なクレデンシャルの有効性を確認したりする場合があります。
• 検証者は、 検証者が特定の 検証可能なクレデンシャルを受け取ったことを 発行者へ知らせる可能性を低減できます。 たとえば、検証者は、 検証可能なクレデンシャルのステータスチェックを行う際に、 外部リンクされた失効リストを取得する場合があります。

このセクションは非規範的です。

発行者には、 検証可能なクレデンシャルに含める情報を、 受信者が必要以上の個人識別情報（PII）を開示することなく さまざまな状況でそれらを使用できるよう、意図された目的に必要な最小限の集合に 制限することが推奨されます。PIIを検証可能なクレデンシャルに入れることを避ける 1つの方法は、主体について過度に具体的な情報を提供することなく 検証者のニーズを満たす抽象的な プロパティを使用することです。

たとえば、この文書では、より機微なPIIを表す特定の生年月日の代わりに ageOver プロパティを使用します。 特定の市場の小売業者が購入者に一定の年齢を超えていることを一般的に要求する場合、 その市場で信頼されている発行者は、 顧客の生年月日に関する主張を含む 検証可能なクレデンシャルを提供するのではなく、 主体がその要件を満たしたと主張する 検証可能なクレデンシャルを提供することを選択できます。 この実践により、個々の顧客は必要以上のPIIを開示することなく購入できます。

このセクションは非規範的です。

あるコンテキストで開示された情報が別のコンテキストへ漏れると、プライバシー侵害が 発生します。そのような侵害を防ぐための受け入れられたベストプラクティスの1つは、 検証者が、特定の取引に絶対に必要な最小限まで、 要求し受け取る情報を制限することです。米国のHealth Insurance Portability and Accountability Act（HIPAA）や欧州連合のGeneral Data Protection Regulation（GDPR）を含む 複数の法域の規制は、このデータ最小化アプローチを義務付けています。

検証可能なクレデンシャルでは、発行者にとってのデータ最小化とは、 検証可能なクレデンシャルの内容を、 予期される利用に対して潜在的な検証者が必要とする 最小限に制限することを意味します。検証者にとっての データ最小化とは、サービスへのアクセスに要求または必要とされる情報の範囲を 制限することを意味します。

たとえば、運転者ID番号、身長、体重、誕生日、および自宅住所を含む運転免許証が 検証可能なクレデンシャルとして表現される場合、 その人物が一定の年齢を超えていることを立証するために必要な情報よりも 多くの情報が含まれます。

発行者が情報を原子化するか、 選択的開示を可能にする 保護メカニズムを使用することは、ベストプラクティスと見なされます。たとえば、 運転免許証の発行者は、運転免許証に現れるすべてのプロパティを含む 検証可能なクレデンシャルを発行し、 保有者が各プロパティを選択的に開示できるようにすることができます。 また、より抽象的な検証可能なクレデンシャル（たとえば、 ageOverプロパティのみを含む検証可能なクレデンシャル）を発行することもできます。 1つの可能な適応として、発行者が、 検証可能なクレデンシャルの仮名的な利用を促進する 単回使用のベアラー・クレデンシャルを取得するための 安全なHTTPエンドポイントを提供することが考えられます。 これが非現実的または安全でないと考える実装者は、 証明時の発行者への依存をなくし、発行者による時間的相関のリスクを 減らす選択的開示スキームの使用を検討するかもしれません。

検証者には、特定の取引を行うために厳密に必要な情報だけを 要求することが強く推奨されます。これは少なくとも次の2つの理由で重要です:

• 検証者が扱う必要のない 非常に機微な情報を処理することによる責任を減らします。
• 特定の取引に必要な情報だけを求めることで、 主体および/または保有者の プライバシーを強化します。

保有者が使用するソフトウェアの実装者には、 検証者によって要求されている情報を開示し、 保有者が取引に不要な特定の情報の共有を拒否できるようにすることが 推奨されます。保有者が使用するソフトウェアの実装者にはまた、 検証者と共有された情報のログへのアクセスを 保有者に与えることが推奨されます。これにより、 保有者は、情報の過剰要求を受けた、または特定の取引に必要以上の情報を 共有するよう強要されたと考える場合に、その情報を当局へ提供できます。

このセクションは非規範的です。

ベアラー・クレデンシャルは、 コンサートチケットのように、その保有者に、保有者が機微な情報を開示することを要求せずに 特定のリソースへの権利を与える、プライバシー強化型の情報です。 低リスクのシナリオでは、複数の保有者が同じ検証可能なクレデンシャルを提示することが 懸念ではない、または大きな経済的損失や評判上の損失につながらない場合に、 エンティティはしばしばベアラー・クレデンシャルを使用します。

ベアラー・クレデンシャルである 検証可能なクレデンシャルは、 credentialSubject プロパティにネストされた id プロパティを使用して表現される 主体識別子を指定しないことで可能になります。 たとえば、次の検証可能なクレデンシャルは ベアラー・クレデンシャルです:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    // ベアラー・クレデンシャルでは'id'プロパティが指定されていないことに注意
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-04-27T17:58:34Z",
    "verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
    "cryptosuite": "ecdsa-rdfc-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5gCBzvpHbsJoeuuy5Z54rKQwkGzBZkmapRZZAKKW4ervhBGGTaygnh4sBG6vV8MHGD8eKhXEmkXr487JwVhZ2WHQ"
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-04-27T17:58:34Z",
    "verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
    "cryptosuite": "ecdsa-sd-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0AhVhAOEMucTcwHIY19VxghifeZjhZGFI9buw5OmEiWzSpbStoG5arWcYX6NB2-ftSiNc_CMh-CemG3peCu8ZOrSCHVFgjgCQC1zlBPjThDb-LSIbpc3uzcrjmKdC3xyuQAM8DoT5zv3FYIP13m1SOplZJx47EsonA19WEGnwABCA4hlMlQS96LIQMhVhADxlyJM3iqf_jn__vvJ0KgjL5uKLmVSsOxTFUsIHJ82mS8DAo_WZUmDxMnCAjrrxPQXLaNdfcmqehQOLT4_oiiVhA74UxSBi3EedkNnN5F2WV_Hd1Pr1vPWA_Qx52meKAa0_FhKu-Gm8uk2fFxK28flIbUv5HVQgGT0nrSuSprE4JslhAGl8hwCBGr5KxrUVAcMZE3vW26KrrI6jMTDLPGb81b9-ILrXLIJKb_ZOcmLggwzgbyxE_hUDLL9b88aZ7tE4dOVhACerSusVIq25s-hjms5Ws4Uw3wmgRQp1lp228deojpcavN-n3FNe3AIBgHFbpK2SzdOzvraj-HVkMpQptXrGEhVhAujmfdq6faQbfYn4LUQCy_sDUr1WNbklcyg2XTDQKscMF0VAUU38d50UrmprSKbhrnZpgWMBFg4ibUco_HO4UToFnL2lzc3Vlcg"
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
    "cryptosuite": "bbs-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQhlm-IXSzQAaXH0xW-NU1t3ikH2xt--sFY-DtoL44DiWf3qv-nuhCc36deovk3t1GLy9JeN-vdeth8XWKMGUcyA4eWD21lxYdvK5Qdzw07ytYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArdrHmhnEXifHmmlKM3zCnc0pq4l3ZkBkIESZ4DrQomVNYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggOkuR5x7VvZAB-RbcqkcwxkQ7or0tsVOUTPlebfxRUQCBZy9pc3N1ZXI"
  }
}

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}

{
  "iat": 1745776714,
  "exp": 1746986314,
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "_AOV6RD0Jaho5ZiH1ILMwJWJQ7q-nyeoyXHAj2yWmRY"
      ]
    }
  },
  "_sd": [
    "PoZyPSPkswP287lENY02Gw85Ccs262YN_VFKHAi8fwo",
    "V4cI8h49UKzznTtjLA_MgxAnQhydt0N99eUv0Serbl4"
  ]
}

ベアラー・クレデンシャルはプライバシーを強化しますが、 発行者はなお、 ベアラー・ クレデンシャルの保有者が期待する以上の情報を意図せず開示しないよう、 設計に注意を払う必要があります。たとえば、同じベアラー・クレデンシャルを複数のサイトで 繰り返し使用すると、これらのサイトが共謀して 保有者を不正に追跡または相関することが可能になります。 同様に、生年月日と郵便番号のような、一見識別性がないように見える情報も、 同じベアラー・クレデンシャルまたはセッションで使用されると、 統計的に個人を識別するために組み合わせて使用できます。

ベアラー・ クレデンシャルの発行者は、 ベアラー・クレデンシャルが、次のような プライバシー強化の利点を提供することを確保すべきです:

• 可能な場合は単回使用である。
• 個人識別情報を含まない。
• 過度に相関可能ではない。

保有者は、機微な情報を含むベアラー・クレデンシャルが発行または要求されたこと、 または1つ以上のセッションにわたる2つ以上のベアラー・ クレデンシャルの組み合わせによって相関リスクが生じることをソフトウェアが検出した場合、 そのソフトウェアによって警告されるべきです。すべての相関リスクを検出することは 不可能かもしれませんが、確実に検出可能なものもあります。

検証者は、 保有者を不正に相関するために使用できる情報を持つことが知られている ベアラー・ クレデンシャルを要求すべきではありません。

このセクションは非規範的です。

検証可能なクレデンシャルを処理する際、 検証者は、それらに依拠する前に関連する 主張を評価します。この評価は、 妥当性確認を行う検証者の要件を満たす限り、 望まれる任意の方法で行えます。多くの検証者は、付録A. 妥当性確認に 列挙されたチェックに加え、次のようなさまざまな具体的な業務プロセス上のチェックを行います:

• 保有者の専門職免許ステータス。
• 免許更新または失効の日付。
• 個人の副資格。
• 保有者と、 保有者がやり取りしようとしている エンティティとの間に関係が存在するかどうか。
• 保有者に関連付けられた 地理位置情報。

これらのチェックを行うプロセスは、情報漏えいを引き起こし、 保有者のプライバシー侵害につながる可能性があります。 たとえば、不適切に構成された失効リストを確認するという単純な操作により、 特定の企業が保有者とやり取りしている可能性が高いことを 発行者へ通知する可能性があります。これにより、 発行者が共謀し、個人の知らないところで個人を相関できるようになる可能性があります。

発行者には、プライバシー侵害につながる可能性のある、 クレデンシャルごとに固有の失効リストのような メカニズムを検証プロセスで使用しないことが強く推奨されます。 保有者にソフトウェアを提供する組織は、 クレデンシャルに 検証プロセス中のプライバシー侵害につながる可能性のある情報が含まれる場合、 警告すべきです。検証者には、プライバシー侵害を生じる クレデンシャル、または標準未満のプライバシー慣行を可能にする クレデンシャルの拒否を検討することが強く推奨されます。

このセクションは非規範的です。

保有者が 発行者から検証可能なクレデンシャルを受け取ると、 その検証可能なクレデンシャルはどこかに保存される必要があります （たとえば、クレデンシャル・リポジトリ内）。 保有者は、 検証可能なクレデンシャル内の情報が 機微で高度に個別化されたものであり、データマイニングの主要な標的になり得ることを 認識する必要があります。検証可能なクレデンシャルの「無料」ストレージを提供するサービスは、 個人データをマイニングし、人々や組織に関する個別化されたプロファイルを構築することに 関心のある組織へ販売する可能性があります。

保有者は、自分たちの クレデンシャル・リポジトリの利用規約、 とくにサービスプロバイダーに検証可能なクレデンシャルを保存する者のために設けられている 相関およびデータマイニング保護について認識する必要があります。

データマイニングおよびプロファイリングに対する有効な緩和策には、次の使用が含まれます:

• あなたの情報を第三者へ販売しないサービスプロバイダー。
• サービスプロバイダーがクレデンシャルの内容を閲覧できないように 検証可能なクレデンシャルを暗号化するソフトウェア。
• あなたが管理し、あなたの期待を超えてあなたの情報をアップロードまたは分析しないデバイス上に、 検証可能なクレデンシャルをローカルに保存するソフトウェア。

上記の緩和策に加えて、市民社会および規制当局がベンダー分析および監査に参加することで、 個人の最善の利益に沿わない実践によって影響を受ける個人に対し、 法的保護が制定され執行されることを確保する助けになります。

このセクションは非規範的です。

同じ主体に関する2つの情報を持つことは、 それらの2つの情報の組み合わせそのもの以上に、その主体について多くを明らかにすることがよくあります。 たとえそれらの情報が異なるチャネルを通じて提供された場合でも同様です。 検証可能なクレデンシャルの集約はプライバシーリスクをもたらし、 エコシステムのすべての参加者はデータ集約のリスクを認識する必要があります。

たとえば、1つはメールアドレス用、もう1つは保有者が21歳を超えていると述べる、2つの ベアラー・クレデンシャルが、 複数のセッションにわたって同じ検証者へ提供されるとします。 情報の検証者は今や、その個人について 一意の識別子（メールアドレス）と年齢関連（「21歳超」）情報を持っています。 これにより、時間とともに漏れる情報をさらに追加しながら、保有者のプロファイルを 容易に作成できます。そのようなクレデンシャルの集約は、複数のサイトが互いに共謀して行うこともでき、 プライバシー侵害につながります。

技術的観点から、情報の集約を防ぐことは困難なプライバシー問題です。 ゼロ知識証明のような新しい暗号技術が、集約および相関の問題に対する解決策として 提案されていますが、長寿命識別子やブラウザー追跡技術の存在は、 最も現代的な暗号技術でさえ打ち負かします。

相関または集約のプライバシー上の影響に対する解決策は、 技術的な性質ではなく、むしろポリシー駆動型であることが多いです。 したがって、保有者が自分の情報の集約を避けたい場合、 送信する検証可能なプレゼンテーションの中で、 かつその検証可能なプレゼンテーションを送信する先の 保有者および検証者によって、 これを表明する必要があります。

このセクションは非規範的です。

関係するすべての者がプライバシーを確保するために最善を尽くしても、 検証可能なクレデンシャルの使用は、非匿名化および プライバシーの喪失につながる可能性があります。この相関は、次のいずれかが発生したときに 起こり得ます:

• 同じ検証可能なクレデンシャルが、同じ検証者へ 複数回提示される。検証者は、保有者が同じ個人であると推測できる可能性があります。
• 同じ検証可能なクレデンシャルが異なる 検証者へ提示され、それらの検証者が共謀する、 または第三者が両方の検証者の取引記録へアクセスできる。 観察力のある当事者は、検証可能なクレデンシャルを提示している個人が 両方のサービスで同じ人物であると推測できる可能性があります。つまり、 同じ人物が両方のアカウントを制御しています。
• クレデンシャルの 主体識別子が、複数のプレゼンテーション または検証者にわたって同じ 主体を参照する。異なるクレデンシャルが提示される場合であっても、 主体識別子が同じであれば、 検証者（および検証者ログへアクセスできる者）は、 クレデンシャルの主体が 同じエンティティであると推測できる可能性があります。
• クレデンシャル内の基礎情報は、 サービスをまたいで個人を識別するために使用され得ます。この場合、他のソースからの情報 （保有者によって 直接提供された情報を含む）を使用して、検証者はクレデンシャル内の情報を使って、 個人を既存のプロファイルと相関できます。たとえば、保有者が 郵便番号、年齢、性別を含むクレデンシャルを提示した場合、 検証者は、そのクレデンシャルの主体を既存のプロファイルと 相関できる可能性があります。詳細については[DEMOGRAPHICS]を参照してください。
• クレデンシャルの識別子を中央集権的な失効サーバーへ渡す。 中央集権サーバーは、やり取りをまたいでクレデンシャルの使用を 相関できます。たとえば、クレデンシャルがこの方法で年齢を証明するために使用される場合、 中央集権サービスは、そのクレデンシャルが提示された すべての場所（すべての酒屋、バー、成人向け店舗、宝くじ販売店など）を知ることができます。

この非匿名化およびプライバシー喪失は、部分的には次によって緩和できます:

• 保有者ソフトウェアが、任意の特定の 検証可能なクレデンシャルについて、 主体としてグローバルに一意な識別子を提供し、 その検証可能なクレデンシャルを決して再利用しない。
• 失効チェックが行われる際に発行者へ連絡されないよう、 発行者が失効のためにグローバルに分散されたサービスを使用する。
• 仕様の著者が、検証可能なクレデンシャルの一意な識別子を クエリAPIへ送信することに依存しない失効メカニズムを設計し、 代わりに、たとえばプライバシー保護型の失効リストを使用する。
• 発行者が、個人識別情報を特定の長寿命の 主体識別子と関連付けることを避ける。

残念ながら、これらの緩和技術は、実用的である場合もあれば、 必要な利用と両立しない場合さえあります。相関が要件である場合もあります。

たとえば、一部の処方薬監視プログラムでは、処方薬の使用を監視することが要件です。 執行機関は、個人が管理物質の処方箋を複数取得するためにシステムを 欺いていないことを確認できる必要があります。この法定または規制上の 処方薬使用の相関の必要性は、個人のプライバシー上の懸念に優先します。

検証可能なクレデンシャルは、サービスをまたいで個人を意図的に相関するためにも 使用されます。たとえば、複数のサービスにログインするために共通のペルソナを使用する場合、 それら各サービス上のすべての活動は、同じ個人に意図的にリンクされます。 これは、それらの各サービスが期待される方法で相関を使用する限り、 プライバシー問題ではありません。

検証可能なクレデンシャルの使用に関連するプライバシー侵害は、 それらの検証可能なクレデンシャルの提示から、 意図されていない、または予期されていない相関が生じる場合に発生します。

このセクションは非規範的です。

法的手続きにより、発行者、保有者、および検証者は、 法執行機関などの当局へ私的情報を開示するよう強制される場合があります。 同じ私的情報が、ソフトウェアのバグまたはセキュリティ障害によって、 権限のない当事者へ偶発的に開示される可能性もあります。 法的手続きおよびコンプライアンス制度の著者には、関与する 主体の私的情報が意図的または偶発的に第三者へ開示された場合に 通知することを要求するガイドラインを策定することが推奨されます。 ソフトウェアサービスの提供者には、そのような私的情報が第三者と共有される原因となり得る 既知の状況、およびそのような第三者の身元について透明性を保つことが推奨されます。

このセクションは非規範的です。

保有者が検証者と情報を共有することを選択する場合、 その検証者が悪意を持って行動し、 保有者に害を与える可能性のある情報を 要求する場合があります。たとえば、検証者が銀行口座番号を求め、 それが他の情報とともに保有者または銀行を欺くために使用される可能性があります。

発行者は、可能な限り多くの情報をトークン化するよう努めるべきです。 それにより、保有者が誤ってクレデンシャルを 誤った検証者へ送信しても、その状況が壊滅的なものにはなりません。

たとえば、個人の銀行残高を確認するために銀行口座番号を含める代わりに、 検証者が残高が一定額を上回っているかどうかを 確認できるトークンを提供します。この場合、銀行は残高確認トークンを含む 検証可能なクレデンシャルを 保有者へ発行できます。その後、保有者はその 検証可能なクレデンシャルを検証可能なプレゼンテーションに含め、 デジタル署名を用いてそのトークンを信用調査機関へ結び付けます。 その後、検証者はその検証可能なプレゼンテーションを自らの デジタル署名で包み込み、口座残高を動的に確認するため発行者へ返すことができます。

このアプローチを使用すると、保有者が口座残高トークンを 誤った相手と共有した場合であっても、攻撃者は銀行口座番号または口座の正確な値を 知ることができません。また、副署名の有効期間により、攻撃者がそのトークンへアクセスできるのは 数分間だけです。

このセクションは非規範的です。

検証可能なクレデンシャルおよび 検証可能なプレゼンテーションで表現されるデータは、 信頼された第三者（発行者など）または 個人（保有者または主体など）による真正な 陳述を含むため価値があります。このデータの保存およびアクセス可能性は、悪意のある行為者にとって 機微データのハニーポットを意図せず作り出す可能性があります。これらの敵対者は、 しばしばそのような機微情報の貯蔵庫を悪用し、そのデータを取得して金銭的利益のために 交換することを狙います。

発行者には、保有者へ検証可能なクレデンシャルを発行し、 それらのクレデンシャルのステータスおよび失効を管理するために必要な最小限のデータのみを 保持することが推奨されます。同様に、発行者には、個人識別情報（PII）またはその他の 機微データを含む公開アクセス可能なクレデンシャルを作成しないことが推奨されます。 ソフトウェア実装者には、堅牢な同意およびアクセス制御手段を用いて 検証可能なクレデンシャルを保護し、 権限のないエンティティがアクセスできない状態を確保することが推奨されます。

保有者には、転送中および保存時のデータを適切に暗号化し、 機微な材料（暗号シークレットなど）をハードウェアまたはその他のデバイスから容易に 抽出できない方法で保護する実装を使用することが推奨されます。さらに、 保有者には、自分が管理するデバイス上でのみデータを 保存および操作し、中央集権システムから離すことが提案されます。これにより、 自分のデータへの攻撃の可能性、または攻撃が成功した場合に大規模な盗難に含まれる可能性を 低減できます。さらに、保有者には、明示的な認可を持つ者にのみアクセスを許可することで、 自分のクレデンシャルおよびプレゼンテーションへのアクセスを厳格に制御することが推奨されます。

検証者には、特定の取引に必要なデータだけを求め、 その特定の取引の必要性を超えてデータを保持しないことが推奨されます。

規制当局には、既存の監査要件を再検討し、同様の執行および監査能力を達成するために よりプライバシーを保護するメカニズムを使用できるようにすることが推奨されます。 たとえば、個人識別情報の収集および長期保持を強く求める監査重視の規制は、 後に同じ情報が侵害され、攻撃者によってアクセスされた場合、個人および組織に 害を及ぼす可能性があります。この仕様で説明される技術により、 保有者は 自分自身および他者に関する性質をより容易に証明できるようになり、 検証者による長期データ保持の必要性を減らします。 代替策には、その情報が収集され確認されたことを示すログを保持することや、 コンプライアンス制度が期待どおりに運用されていることを確認するための ランダムテストが含まれます。

このセクションは非規範的です。

セクション8.14 利用パターンで詳述されているように、 利用パターンは特定の種類の行動と相関され得ます。この相関は、 保有者が 発行者の知識なしに検証可能なクレデンシャルを使用する場合に 部分的に緩和されます。しかし、発行者は、 自らの検証可能なクレデンシャルを短寿命にし、 更新を自動化することで、この保護を打ち破ることができます。

たとえば、ageOver 検証可能なクレデンシャルは、バーへの入場に役立ちます。 発行者が、そのような 検証可能なクレデンシャルを非常に短い有効期間と 自動更新メカニズム付きで発行すると、発行者は、保有者の行動を 保有者に悪影響を及ぼす形で 相関できる可能性があります。

保有者にソフトウェアを提供する組織は、 行動相関につながる可能性のある短寿命のクレデンシャルを繰り返し使用している場合、 彼らに警告すべきです。発行者は、利用パターンを相関できるような クレデンシャルの 発行を避けるべきです。

このセクションは非規範的です。

理想的なプライバシー尊重型システムでは、検証者とのやり取りに必要な情報のみを 保有者が開示することを要求します。 その後、検証者は開示要件が満たされたことを記録し、 開示された機微な情報を破棄します。多くの場合、規制上の負担などの競合する優先事項により、 この理想的なシステムを採用することは妨げられます。他の場合には、長寿命識別子が 単回使用を妨げます。任意の検証可能なクレデンシャルエコシステムの設計者は、 可能な限り単回使用の検証可能なクレデンシャルを優先することで、 それをできるだけプライバシー尊重型にするよう努めるべきです。

単回使用の検証可能なクレデンシャルを使用すると、 いくつかの利点があります。第一の利点は、検証者が 検証可能なクレデンシャル内のデータが新鮮であると確信できることです。 第二の利点は、保有者にとって、 検証可能なクレデンシャル内に長寿命識別子がなければ、 その検証可能なクレデンシャル自体をオンラインで 彼らを追跡または相関するために使用できないことを知っていることです。 最後に、攻撃者が盗むものが何もないため、エコシステム全体がより安全に 運用できるようになります。

このセクションは非規範的です。

理想的なプライベート・ブラウジングのシナリオでは、PIIは一切明らかにされません。 多くのクレデンシャルにはPIIが含まれるため、 保有者にソフトウェアを提供する組織は、 プライベート・ブラウジングモード中にクレデンシャルおよびプレゼンテーションを使用すると、この情報が 明らかになる可能性について彼らに警告すべきです。各ブラウザーベンダーは プライベート・ブラウジングを異なる方法で扱い、一部のブラウザーにはこの機能がない可能性もあるため、 実装者がプライベート・ブラウジングモードに依存してプライバシー保護を提供しないことが 重要です。代わりに、実装者には、プライバシー保証を提供するために自らのソフトウェアで 直接利用できるツールに依拠することが推奨されます。

このセクションは非規範的です。

検証可能なクレデンシャルは、 発行者への高い信頼度に依存します。 保有者が可能なプライバシー保護をどの程度活用できるかは、 そのような機能に対して発行者が提供する サポートに強く依存することがよくあります。多くの場合、ゼロ知識証明、 データ最小化技術、ベアラー・クレデンシャル、抽象的な主張、および署名に基づく相関に対する 保護を利用するプライバシー保護には、これらの能力を自らが発行する 検証可能なクレデンシャルに組み込む必要がある 発行者による能動的なサポートが必要です。

保有者は、 保有者および主体のプライバシーを保つ助けとなる 検証可能なクレデンシャル能力を提供するために、 発行者の参加に依存するだけでなく、 発行者がこれらのプライバシー保護を意図的に 破壊しないことにも依存していることに注意することが重要です。たとえば、 発行者は、署名に基づく相関から保護する署名スキームを 使用して検証可能なクレデンシャルに署名する可能性があります。 これは、署名値が検証者間で共有される際に、 保有者が署名値によって相関されることを防ぎます。 しかし、発行者が各発行済み クレデンシャルに対して一意の鍵を作成する場合、 検証者がそれを行えないにもかかわらず、 発行者がそのクレデンシャルの プレゼンテーションを追跡できる可能性があります。

前述のプライバシー保護に加えて、発行者は クレデンシャルを 発行する際に使用する識別子および主張型に関連付けられて漏えいするデータを 認識する必要があります。この例の1つは、発行者が運転免許証を発行し、 管轄権を持つ場所と主体の居住地の両方を明らかにする場合です。 検証者は、 主体が 運転を許可されていることを確認するためにクレデンシャルを要求することで、 実際にはクレデンシャルについてのメタデータ、たとえばどの 発行者がクレデンシャルを発行したかや、 発行者によって漏えいした可能性のある 周辺情報、たとえば主体の自宅住所に関心を持つ形で、 これを利用するかもしれません。このような漏えいを緩和するため、 発行者は、特定の位置情報またはその他の機微なメタデータを 隠すために共通の識別子を使用する場合があります。たとえば、郡、市、町、またはその他の より小さい自治体のレベルではなく、州または国レベルの共有された 発行者識別子を使用することです。さらに、 検証者は、正確な発行者を開示する必要なく、 発行者が信頼されたエンティティの集合内に存在することを 証明することでプライバシーを保つために、保有者証明メカニズムを 使用できます。

このセクションは非規範的です。

暗号は、この仕様で説明されるデータモデルのいくつかの側面を保護できます。 実装者が、クレデンシャルおよび プレゼンテーションの作成と処理に使用される暗号スイートおよび ライブラリを理解することは重要です。暗号システムの実装および監査には、一般に 相当な経験が必要です。効果的な レッドチーミングも、 セキュリティレビューからバイアスを取り除く助けになります。

暗号スイートとライブラリには寿命があり、最終的には新しい攻撃や技術的進歩に 屈します。本番品質のシステムはこれを考慮し、期限切れまたは破損した暗号スイートや ライブラリを容易かつ能動的にアップグレードし、既存の クレデンシャルを無効化して置き換えるメカニズムが存在することを 確保する必要があります。クレデンシャルを処理する システムの長期的な実用性を確保するには、定期的な監視が重要です。

このセクションは非規範的です。

検証可能なクレデンシャルおよび検証可能なプレゼンテーションを保護するために使用される ほとんどのデジタル署名アルゴリズムのセキュリティは、その 秘密署名鍵の品質と保護に依存します。暗号鍵の管理は、広大で複雑な分野を 包含します。包括的な推奨事項および詳細な議論については、読者は [NIST-SP-800-57-Part-1]を 参照してください。[FIPS-186-5]および [NIST-SP-800-57-Part-1]の 両方で強く推奨されているように、秘密署名鍵は複数の目的に 使用されるべきではありません。たとえば、秘密署名鍵は暗号化と署名の 両方に使用されるべきではありません。

[NIST-SP-800-57-Part-1]は、 秘密署名鍵および 公開検証鍵には限定された暗号期間を持たせることを強く助言しています。 ここで暗号期間とは、「特定の鍵が正当なエンティティによる使用を 認可される期間、または特定のシステムの鍵が有効であり続ける期間」です。 [NIST-SP-800-57-Part-1]は、 さまざまな条件下における異なる鍵種別の暗号期間について広範な ガイダンスを示し、秘密署名鍵については1年から3年の暗号期間を推奨しています。

潜在的な秘密鍵の侵害に対処するため、 [NIST-SP-800-57-Part-1]は、 保護手段、被害軽減、および失効に関する推奨事項を提供しています。 このセクションは主に秘密署名鍵のセキュリティに焦点を当てていますが、 [NIST-SP-800-57-Part-1]は、 すべての検証材料の有効性を使用前に確認することも 強く推奨しています。

このセクションは非規範的です。

検証可能なクレデンシャルには、しばしば 検証可能なクレデンシャルの外部に存在するデータへのURLが含まれます。 検証可能なクレデンシャルの外部に存在するリンクされたコンテンツ — 画像、JSON-LD拡張コンテキスト、JSONスキーマ、その他の機械可読データなど — は、データが検証可能なクレデンシャル上の 保護メカニズムによる保護の外側に存在するため、 改ざんから保護されません。

この仕様のセクション5.3 関連リソースの完全性は、外部リソースのコンテンツの 完全性を確保するための任意のメカニズムを提供します。このメカニズムは、 検証可能なクレデンシャルのセキュリティに影響しない外部リソースには 必要ありません。しかし、コンテンツの変更が潜在的にセキュリティ脆弱性を もたらし得る外部リソースでは、その実装が極めて重要です。

実装者は、保護されていない外部の機械可読コンテンツのURLに関連する 潜在的なセキュリティリスクを認識する必要があります。そのような脆弱性は、 アプリケーションに対する攻撃の成功につながる可能性があります。 外部リソースへの変更がセキュリティを損なう可能性がある場合、 実装者はこの仕様で概説されるコンテンツ完全性保護メカニズムを採用することで 利益を得られます。

このセクションは非規範的です。

この仕様は、署名または証明のないクレデンシャルの作成を可能にします。 これらのクレデンシャルクラスは、Webページ上のフォームに記入することに 類似して、中間的な保存や自己主張情報にしばしば有用です。実装者は、 これらのクレデンシャル型は、 著作者が不明であるか信頼できないため、 検証可能ではないことを認識すべきです。

このセクションは非規範的です。

データモデルは、本質的には 中間者（MITM）、 リプレイ、および なりすまし攻撃を防ぎません。 オンラインおよびオフラインのユースケースは、敵対者が送信中または保存中の 検証可能なクレデンシャルデータを傍受、変更、再利用、および/または複製する これらの攻撃を受けやすい可能性があります。

このセクションは非規範的です。

発行者が クレデンシャル内の情報を原子化するか、選択的開示を可能にする 署名スキームを使用することは、ベストプラクティスと見なされます。情報を原子化する際、 発行者によって安全に行われない場合、 保有者は、 異なるクレデンシャルからの 主張を、発行者が意図しなかった 方法で束ね合わせる可能性があります。

ある大学が個人に2つの検証可能なクレデンシャルを発行する場合を 考えてみてください。各クレデンシャルには、組み合わせると特定の「部門」における その人物の「役割」を示す2つのプロパティが含まれます。たとえば、1つの クレデンシャルの組は 「Department of Computing」の「Staff Member」を指定し、別のものは 「Department of Economics」の「Post Graduate Student」を示すかもしれません。 これらの検証可能なクレデンシャルを原子化すると、 大学はその個人に4つの別個のクレデンシャルを発行することになります。各クレデンシャルには、 「Staff Member」、「Post Graduate Student」、「Department of Computing」、または「Department of Economics」という単一の指定が含まれます。 その後、保有者は、 「Staff Member」と「Department of Economics」の検証可能なクレデンシャルを 検証者へ提示する可能性があり、それらは合わせて虚偽の 主張を構成します。

このセクションは非規範的です。

検証可能なクレデンシャルに非常に動的な情報が含まれる場合、 有効期間を慎重に検討することが極めて重要になります。意図された利用を超えて延びる 有効期間を持つ検証可能なクレデンシャルを発行すると、 悪意のある行為者が悪用できる潜在的なセキュリティ脆弱性が生じます。 検証可能なクレデンシャルによって表現される情報が 使用されると期待される期間より短い有効期間は、 保有者および検証者に負担を もたらします。したがって、検証可能なクレデンシャルの有効期間を、 ユースケースおよび検証可能なクレデンシャルに含まれる情報の期待される寿命に 適したものに設定することが重要です。

このセクションは非規範的です。

検証可能なクレデンシャルをデバイスに保存することは、 そのデバイスが紛失または盗難された場合にリスクをもたらします。そのようなデバイスを 入手した攻撃者は、被害者の検証可能なクレデンシャルを使用するシステムへの 不正アクセスを潜在的に取得します。この種の攻撃を緩和する方法には、次が含まれます:

• デバイス上でパスワード、PIN、パターン、または生体認証による画面ロック解除保護を 有効にする。
• クレデンシャル・リポジトリに対して、 パスワード、生体認証、または多要素認証を有効にする。
• 暗号鍵へアクセスする際に、パスワード、生体認証、または多要素認証を有効にする。
• 別個のハードウェアベースの署名デバイスを使用する。
• 上記のすべて、または任意の組み合わせ。

さらに、なりすましの事例は、エンティティが自らの行為を否認しようとする 状況を含め、さまざまな形で現れる可能性があります。 検証可能なクレデンシャルの領域における信頼とセキュリティを高めることは、 なりすましを回避する以上のことを含みます。それには、否認防止メカニズムの実装も 含まれます。これらのメカニズムは、エンティティの 行為または取引に対する責任を確固たるものにし、説明責任を強化し、 悪意のある行動を抑止します。否認防止の達成は多面的な取り組みであり、 保護メカニズム、所持証明、 および信頼と信頼性を促進するために設計されたさまざまなプロトコルにおける 認証スキームを含む、多様な技術を包含します。

このセクションは非規範的です。

エンティティの行為 — プレゼンテーションなど — と、 それらの行為の意図された目的との整合性を確保することは不可欠です。 これには、検証可能なクレデンシャルを使用する 認可を持つこと、および指定された範囲と目的に従う方法で クレデンシャルを使用することが含まれます。この文脈における 2つの重要な側面は、不正利用と不適切な利用です。

このセクションは非規範的です。

検証可能なクレデンシャル内のデータには、注入可能なコードや スクリプト言語のコードが含まれる可能性があります。 検証可能なクレデンシャルの著者は、 必要な場合を除き、かつ関連するリスクを可能な限り最大限に緩和した後にのみ、 そのような包含を避けることで利益を得ます。

たとえば、複数の言語または注釈を含む単一の自然言語文字列は、正しく 表示するために追加の構造またはマークアップを必要とすることがよくあります。 HTMLなどのマークアップ言語は、異なる言語のテキスト範囲にラベルを付けたり、 双方向テキストを適切に表示するために 必要な文字列内部のマークアップを提供したりできます。 そのような値をJSON-LDで正確にエンコードするために、rdf:HTMLデータ型を 使用することも可能です。

情報をHTMLとしてエンコードできるにもかかわらず、実装者には次の理由から そうしないことが強く推奨されます:

• 何らかのバージョンのHTMLプロセッサーが必要となり、言語および基底方向情報の 処理負担が増します。
• このデータモデルを使用する際のセキュリティ攻撃面が増えます。 なぜなら、HTMLを素朴に処理すると、データ生成プロセスのどこかの時点で 攻撃者が注入したscriptタグが実行される可能性があるためです。

実装者が特定のユースケースに対処するために、HTMLまたは実行可能スクリプトを含み得る その他のマークアップ言語を使用する必要があると感じる場合、攻撃者がそのマークアップを どのように使用して、マークアップの利用者に対するインジェクション攻撃を仕掛けることが できるかを分析することが推奨されます。この分析の後には、ネットワークへアクセスできない サンドボックス内でHTMLレンダリングエンジンを実行するなど、特定された攻撃に対する 緩和策を能動的に展開すべきです。

このセクションは非規範的です。

政府発行の身分証明カードなど、今日使用されている多くの物理的な クレデンシャルは、小さな文字、小さく高解像度な画像への依存、 視覚障害のある人々のためのアフォーダンスがないことなどを含むがこれらに限られない、 不十分なアクセシビリティ特性を持っています。

このデータモデルを使用して検証可能なクレデンシャルを作成する場合、 データモデル設計者にはデータ・ファーストのアプローチを使用することが 提案されます。たとえば、クレデンシャルを表すためにデータまたはグラフィカル画像の どちらを使用するかを選択できる場合、設計者は、機関の名称や専門職 クレデンシャルなど、 画像のすべての要素を、閲覧者の画像解釈に頼ってこの情報を伝えるのではなく、 機械可読な方法で表現すべきです。データ・ファーストのアプローチを使用することが 推奨されるのは、さまざまな能力を持つ人々のために異なるインターフェイスを 構築する基礎的要素を提供するためです。