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

要約

検証可能なクレデンシャルとは、一連の主張を、運転免許証や学歴証明書などとして発行者が表現するための特定の方法です。この仕様では、検証可能なクレデンシャルの拡張可能なデータモデル、それらを改ざんから保護する方法、およびこれらのクレデンシャルを交換するための、発行者、保有者、ならびに検証者で構成される三者間エコシステムについて説明します。この文書では、この仕様で説明されている技術を使用するエコシステムにおけるセキュリティ、プライバシー、国際化、およびアクセシビリティに関するさまざまな考慮事項についても扱います。

この節では、この文書の後半にあるセクション5. 高度な概念に備えて、この仕様の基本概念をいくつか紹介します。

この節は非規範的です。

この仕様は、新しい種類の検証可能なクレデンシャルのプロトタイプを容易に作成できるよう設計されています。開発者は、以下のテンプレートをコピーして、一般的な検証可能なクレデンシャル用ツールに貼り付けることで、プロトタイプクレデンシャルの発行、保有、および検証を開始できます。

開発者は、以下のMyPrototypeCredentialを、作成したいクレデンシャルの型に変更します。検証可能なクレデンシャルは主体について記述するため、 credentialSubjectオブジェクト内の各プロパティと値の組は、クレデンシャル主体の特定のプロパティを表します。開発者がこれらのプロパティと値の組をいくつか追加した後、変更したオブジェクトを適合する発行者実装に送信すると、開発者向けの検証可能なクレデンシャルが作成されます。プロトタイプ作成の観点では、開発者が行う必要があるのはこれだけです。

例 1: 検証可能なクレデンシャルのプロトタイプを作成するためのテンプレート

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "MyPrototypeCredential"],
  "credentialSubject": {
    "mySubjectProperty": "mySubjectValue"
  }
}

すべてのクレデンシャルプロパティが安定した後、他の開発者との相互運用性を促進するため、安定したURLで語彙ファイルとコンテキストファイルを生成し、公開することが推奨されます。その後、上記の https://www.w3.org/ns/credentials/examples/v2 URLを、ユースケース固有のコンテキストURLに置き換えます。このプロセスについては、セクション5.2 拡張性で扱います。また、開発者は、自身のユースケースに適合する既存の語彙ファイルとコンテキストファイルを再利用できます。再利用可能なリソースについては、検証可能なクレデンシャルの拡張機能を調べることができます。

検証可能なクレデンシャルは、1つ以上の主体のプロパティと、クレデンシャル自体のプロパティを表現するために使用されます。この仕様では、検証可能なクレデンシャルについて、次のプロパティを定義します。

@context: セクション4.3 コンテキストで定義します。
id: セクション4.4 識別子で定義します。
type: セクション4.5 型で定義します。
name: セクション4.6 名前と説明で定義します。
description: セクション4.6 名前と説明で定義します。
issuer: セクション4.7 発行者で定義します。
credentialSubject: セクション4.8 クレデンシャル主体で定義します。
validFrom: セクション4.9 有効期間で定義します。
validUntil: セクション4.9 有効期間で定義します。
status: セクション4.10 ステータスで定義します。
credentialSchema: セクション4.11 データスキーマで定義します。
refreshService: セクション5.4 更新で定義します。
termsOfUse: セクション5.5 利用条件で定義します。
evidence: セクション5.6 証拠で定義します。

検証可能なクレデンシャルには、セクション5.2 拡張性で定義する拡張メカニズムを使用して、追加のプロパティを持たせることができます。

2つのソフトウェアシステムがデータを交換する必要がある場合、両方のシステムが理解できる用語を使用する必要があります。2人の人間が、同じ言語を使用することで効果的に意思疎通する方法を考えてください。その言語では、"名前"や "ウェブサイト"などの使用する語が、どちらの人にとっても同じ意味を持ちます。これは、 会話のコンテキストと呼ばれることがあります。この仕様では、通信を行うコンテキストを確立することで、ソフトウェアシステムについて同様の結果を得るために同様の概念を使用します。

検証可能なクレデンシャルおよび検証可能なプレゼンテーションを処理するソフトウェアシステムは、各用語にURLを使用して用語を識別します。ただし、それらのURLは長く、人間にとってあまり使いやすくない場合があり、短く人間にとって使いやすい別名の方が役立つことがあります。この仕様では、 @context プロパティを使用して、短い別名をURLに対応付けます。

検証可能なクレデンシャルおよび検証可能なプレゼンテーションはMUST、 @context プロパティを含めなければなりません。アプリケーション開発者はMUST、アプリケーションで使用されるすべてのJSON-LD コンテキストを、少なくともアプリケーションで使用する用語の意味に影響する範囲で理解しなければなりません。そのためのメカニズムの1つは、検証可能なクレデンシャルのデータ完全性 1.0仕様のコンテキストの検証に関する節で説明されています。この仕様を基礎とする他の仕様はMAY、JSON-LDコンテキストをセクション5.3 関連リソースの完全性で説明する relatedResource機能または実質的に同等のメカニズムによって完全性保護することを要求できます。

@context: @context プロパティの値はMUST、最初の項目が値 https://www.w3.org/ns/credentials/v2を持つURLである順序付き集合でなければなりません。順序付き集合内の後続項目はMUST、 URLとオブジェクトの任意の組み合わせで構成され、それぞれが JSON-LDコンテキストとして処理可能でなければなりません。

例 2: @contextプロパティの使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

上記の例では、基本コンテキストのURL （https://www.w3.org/ns/credentials/v2）を使用して、データ交換が検証可能なクレデンシャルに関するものであることを確立します。この概念については、セクション5.2 拡張性でさらに詳しく説明します。https://www.w3.org/ns/credentials/v2で利用可能なデータは、永続的にキャッシュできる静的文書です。その処理手順については、附属書 C.1 基本コンテキストで説明します。検証可能なクレデンシャル・データモデルに関連する人間可読な語彙文書は、 https://www.w3.org/2018/credentials/で利用できます。

2番目のURL（https://www.w3.org/ns/credentials/examples/v2）は、例を示すために使用されます。実装は、試験運用システムや実稼働システムなど、その他の目的でこのURLを使用しないことが想定されています。

注記: @contextについて詳しくは、 JSON-LDを参照してください。

@context プロパティについては、 JSON-LD 1.1仕様のセクション3.1: コンテキストでさらに詳しく説明されています。

この文書で指定される種類のオブジェクトを処理するソフトウェアシステムは、提供された検証可能なクレデンシャルまたは検証可能なプレゼンテーションが意図したユースケースに適しているかどうかを判断するために型情報を使用します。この仕様では、オブジェクトの型情報を表現するための type プロパティを定義します。この型情報は、附属書 B. 妥当性検証で説明する妥当性検証プロセスで使用できます。

検証可能なクレデンシャルおよび検証可能なプレゼンテーションはMUST、関連付けられた値を持つtype プロパティを含めなければなりません。

型: type プロパティの値はMUST、 1つ以上の用語および絶対URL文字列でなければなりません。複数の値を指定する場合、その順序は重要ではありません。

この仕様に関して、次の表は型を指定することがMUST要求されるオブジェクトを示します。

オブジェクト	型
検証可能なクレデンシャルオブジェクト	`VerifiableCredential`と、任意で、より具体的な検証可能なクレデンシャルの型。例: `"type": ["VerifiableCredential", "OpenBadgeCredential"]`
検証可能なプレゼンテーションオブジェクト	`VerifiablePresentation`と、任意で、より具体的な検証可能なプレゼンテーションの型。例: `"type": "VerifiablePresentation"`
credentialStatus オブジェクト	有効なクレデンシャルステータスの型。例: `"type": "BitstringStatusListEntry"`
termsOfUse オブジェクト	有効な利用条件の型。例: `"type": "TrustFrameworkPolicy"`
evidence オブジェクト	有効な証拠の型。例: `"type": "Evidence"`
refreshService オブジェクト	有効なrefreshServiceの型。例: `"type": "VerifiableCredentialRefreshService2021"`
credentialSchema オブジェクト	有効なcredentialSchemaの型。例: `"type": "JsonSchema"`

注記: 検証可能なクレデンシャル・データモデルはJSON-LDに基づく

検証可能なクレデンシャル・データモデルの型システムは、 JSON-LD 1.1のものと同じであり、セクション3.5: 型の指定およびセクション9: JSON-LD 文法で詳しく説明されています。JSON-LDコンテキストを使用する場合（セクション 5.2 拡張性を参照）、この仕様では、 JSON-LD文書を理解しやすくするために、 @typeキーワードの別名としてtypeを使用します。アプリケーション開発者や文書作成者はJSON-LD型システムの詳細を理解する必要はありませんが、相互運用可能な拡張性をサポートするこの仕様の実装者は理解する必要があります。

すべてのクレデンシャル、プレゼンテーション、およびカプセル化されたオブジェクトは、ソフトウェアシステムが追加情報をより容易に検出して処理できるよう、追加の、より限定的な型（たとえば ExampleDegreeCredential）を指定するか、関連付けることがSHOULD推奨されます。

credentialSubjectオブジェクトに関連付けられたオブジェクトや、その内部に深くネストされたオブジェクトなど、この仕様で定義されるカプセル化されたオブジェクトを処理する場合、ソフトウェアシステムは、階層の上位にあるカプセル化オブジェクトで指定された型情報を使用することがSHOULD推奨されます。具体的には、クレデンシャルなどのカプセル化オブジェクトは、検証者が、カプセル化オブジェクトの型に基づいて関連オブジェクトの内容を迅速に判断できるよう、関連オブジェクトの型を伝達することがSHOULD推奨されます。

たとえば、typeが ExampleDegreeCredentialであるクレデンシャルオブジェクトは、 credentialSubjectプロパティに関連付けられたオブジェクトに、次の識別子が含まれていることを検証者に示します。

idプロパティ内の主体。
typeプロパティ内の学位の種類。
nameプロパティ内の学位の名称。

これにより、実装者は検証のためにtypeプロパティに関連付けられた値に依拠できます。オブジェクトの型と、それに関連付けられた値は、少なくとも、その型のURLで参照できる人間可読な仕様に文書化されることが想定されています。たとえば、BitstringStatusList型の人間可読な定義は、 https://www.w3.org/ns/credentials/status/#BitstringStatusListで確認できます。また、同じURLで HTTPコンテントネゴシエーションを介して機械可読バージョンを提供することも推奨されます。

注記: 新しいクレデンシャル型の作成については実装ガイドを参照する

新しい種類の検証可能なクレデンシャルを作成する方法の説明は、この仕様の範囲外です。関心のある読者は、検証可能なクレデンシャル実装ガイドライン 1.0の新しいクレデンシャル型の作成の節を読むことが推奨されます。

クレデンシャルを表示する際には、発行者が提供する、そのクレデンシャルに名前と、その目的の簡潔な説明を付与するテキストがあると便利です。nameおよびdescription プロパティは、これらの目的に使用されます。

name: OPTIONALなプロパティで、クレデンシャルの名前を表します。存在する場合、name プロパティの値はMUST、文字列または言語値オブジェクトでなければなりません（ 9.1 言語と基底方向を参照）。理想的には、次のクレデンシャルの名前は簡潔で人間が読めるものであり、個人があるクレデンシャルを、自身が保有している可能性のあるほかのクレデンシャルからすばやく区別できるようにするものです。
description: OPTIONALなプロパティで、クレデンシャルに関する具体的な詳細を伝えます。存在する場合、description プロパティの値はMUST、文字列または言語値オブジェクトでなければなりません（ 9.1 言語と基底方向を参照）。理想的には、次のクレデンシャルの説明は数文以内であり、個人がその内容を思い出せるだけの情報をクレデンシャルについて伝えるものです。その際、すべての主張に目を通す必要はありません。

例 5: nameおよびdescriptionプロパティの使用

名前と説明は、異なる言語での内容の表現もサポートします。言語および基底方向の情報を伴う文字列を表現するには、 @value、@language、および @direction プロパティを含むオブジェクトを使用して、それぞれテキスト値、言語タグ、および基底方向を表現できます。詳細は、 9.1 言語と基底方向を参照してください。

注記: 単一言語の文字列には@directionは必須ではありません

以下の例の@directionプロパティは、対応する単一言語の文字列には必須ではありません。これらの既定の方向は、 @directionの値で設定された方向と同じです。ここでは、@direction プロパティを、例示を明確にし、コピー、貼り付け、編集によって機能する結果が得られるようにするために含めています。実装者には、文字列の国際化に関する節を、 JSON-LD 1.1仕様で読むことが推奨されます。

例 6: nameおよびdescriptionプロパティの使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": {
    "id": "https://university.example/issuers/565049",
    "name": [{
      "@value": "Example University",
      "@language": "en"
    }, {
      "@value": "Université Exemple",
      "@language": "fr"
    }, {
      "@value": "جامعة المثال",
      "@language": "ar",
      "@direction": "rtl"
    }],
    "description": [{
      "@value": "A public university focusing on teaching examples.",
      "@language": "en"
    }, {
      "@value": "Une université publique axée sur l'enseignement d'exemples.",
      "@language": "fr"
    }, {
      "@value": ".جامعة عامة تركز على أمثلة التدريس",
      "@language": "ar",
      "@direction": "rtl"
    }]
  },
  "validFrom": "2015-05-10T12:30:00Z",
  "name": [{
    "@value": "Example University Degree",
    "@language": "en"
  }, {
    "@value": "Exemple de Diplôme Universitaire",
    "@language": "fr"
  }, {
    "@value": "مثال الشهادة الجامعية",
    "@language": "ar",
    "@direction": "rtl"
  }],
  "description": [{
    "@value": "2015 Bachelor of Science and Arts Degree",
    "@language": "en"
  }, {
    "@value": "2015 Licence de Sciences et d'Arts",
    "@language": "fr"
  }, {
    "@value": "2015 بكالوريوس العلوم والآداب",
    "@language": "ar",
    "@direction": "rtl"
  }],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": [{
        "@value": "Bachelor of Science and Arts Degree",
        "@language": "en"
      }, {
        "@value": "Licence de Sciences et d'Arts",
        "@language": "fr"
      }, {
        "@value": "بكالوريوس العلوم والآداب",
        "@language": "ar",
        "@direction": "rtl"
      }]
    }
  }
}

この仕様は、 credentialStatus プロパティを、検証可能なクレデンシャルのステータスに関する情報（そのクレデンシャルが一時停止または失効しているかどうかなど）を取得するために定義します。

存在する場合、credentialStatus プロパティに関連付けられた値は、単一のオブジェクト、または1つ以上のオブジェクトの集合です。各オブジェクトには、次のプロパティが定義されています。

id: id プロパティはOPTIONALです。これはMAY、クレデンシャルのステータスオブジェクトに一意の識別子を付与するために使用してもかまいません。存在する場合、セクション4.4 識別子の規範的指針にMUST 従わなければなりません。
type: type プロパティはREQUIREDです。これは、オブジェクトが表すステータス情報の型を表現するために使用されます。関連する規範的指針として、セクション4.5 型にMUST従わなければなりません。

クレデンシャルのステータス情報の正確な内容は、個別の credentialStatus 型の定義によって決まり、実装が簡単か、プライバシーを強化するかといった要因に応じて異なります。その値は、クレデンシャルの現在のステータスと、機械可読情報を URLから取得できるかどうかを判断するのに十分な情報を提供します。たとえば、オブジェクトには、クレデンシャルが一時停止または失効しているかを記した外部文書へのリンクを含めることができます。

例 12: ステータスプロパティの使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialStatus": {
    "id": "https://university.example/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://university.example/credentials/status/3"
  }
}

クレデンシャルには、失効または一時停止しているかどうかなど、複数のステータスを関連付けることができます。

例 13: ステータスプロパティでの複数エントリの使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://license.example/credentials/9837",
  "type": ["VerifiableCredential", "ExampleDrivingLicenseCredential"],
  "issuer": "https://license.example/issuers/48",
  "validFrom": "2020-03-14T12:10:42Z",
  "credentialSubject": {
    "id": "did:example:f1c276e12ec21ebfeb1f712ebc6",
    "license": {
      "type": "ExampleDrivingLicense",
      "name": "License to Drive a Car"
    }
  },
  "credentialStatus": [{
    "id": "https://license.example/credentials/status/84#14278",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "14278",
    "statusListCredential": "https://license.example/credentials/status/84"
  }, {
    "id": "https://license.example/credentials/status/84#82938",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "suspension",
    "statusListIndex": "82938",
    "statusListCredential": "https://license.example/credentials/status/84"
  }]
}

実装者は、複数のステータスエントリを持つクレデンシャルに相反する情報が含まれる可能性があることに注意してください。このような矛盾の調整は、妥当性検証プロセスの一部であり、したがって検証者のビジネスロジックの一部となるため、この仕様の範囲外です。

ステータス方式のデータモデル、形式、およびプロトコルを定義することは、この仕様の範囲外です。検証可能なクレデンシャル拡張文書には、検証可能なクレデンシャルのステータス確認を実装したい実装者が利用できるステータス方式が掲載されています。

クレデンシャルのステータス仕様はMUST NOT、個人の追跡を可能にしてはなりません。たとえば、発行者が、検証者が特定の保有者または主体に関心を持ったときに、直接または間接に通知を受けることなどです。容認できない手法には、クレデンシャルを使用するたびに、特定の個人のステータスを確認するために発行者へ連絡する「ホームへの通信」や、クレデンシャルを使用するたびに発行者へ情報を要求し、その発行者がその情報を使用して、検証者が特定の個人に関心を持っていることを推測できる「仮名性の低下」が含まれます。

データスキーマは、特定のデータ集合に所定の構造を適用するときに役立ちます。この仕様では、少なくとも次の2種類のデータスキーマを考慮します。

データ検証スキーマ。これは、クレデンシャルまたは検証可能なクレデンシャルの構造と内容が公開済みのスキーマに適合していることを確定するために使用されます。
データ符号化スキーマ。これは、検証可能なクレデンシャルの内容を、ゼロ知識証明で使用される形式などの代替表現形式に対応付けるために使用されます。

データスキーマは、次のプロパティとは異なる目的を果たすことを理解することが重要です。 @contextプロパティは、データ構造もデータ構文も適用せず、代替表現形式への任意の符号化を定義することもできません。

この仕様は、データスキーマを表現するための次のプロパティを定義します。発行者は、発行する検証可能なクレデンシャルにこのプロパティを含めることができます。

credentialSchema

credentialSchema プロパティの値はMUST、1つ以上のデータスキーマでなければなりません。それらのスキーマは、提供されたデータが提供されたスキーマに適合するかどうかを判断するのに十分な情報を検証者へ提供します。各 credentialSchemaはMUST、自身のtype（たとえば、 JsonSchema）およびid プロパティを指定しなければなりません。その値はMUST、スキーマファイルを識別するURLでなければなりません。個別の型の定義によって、各データスキーマの正確な内容が決まります。

複数のスキーマが存在する場合、妥当性は、関連付けられた各typeプロパティで規定される処理規則に従って決定されます。

注記: クレデンシャルの型に固有の構文検査が可能です

credentialSchema プロパティを使用すると、型定義に注釈を付けたり、語彙の特定のバージョンに固定したりできます。検証可能なクレデンシャルの作成者は、何らかのコンテンツ完全性保護メカニズムによって保護された語彙の静的バージョンをcredentialSchemaによって含めることができます。 credentialSchema プロパティにより、クレデンシャルの構文検査を実行し、検証メカニズムを使用することもできます。たとえば、JSON Schema [VC-JSON-SCHEMA]による妥当性検証です。

例 14: credentialSchemaプロパティを使用した JSON Schemaの妥当性検証

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    },
    "alumniOf": {
      "name": "Example University"
    }
  },
  "credentialSchema": [{
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchema"
  },
  {
    "id": "https://example.org/examples/alumni.json",
    "type": "JsonSchema"
  }]
}

上の例では、発行者が2つのcredentialSchema オブジェクトを指定しています。各オブジェクトは、JSON Schema [VC-JSON-SCHEMA]ファイルを指しています。これにより、検証者は、検証可能なクレデンシャルが適正形式であるかどうかを判断できます。

この仕様では、2種類の保護メカニズムを認めます。エンベロープ証明を使用するものと、埋め込み証明を使用するものです。

エンベロープ証明は、このデータモデルのシリアライズを包み込みます。このようなRECOMMENDEDエンベロープ証明メカニズムの1つが、 JOSEおよびCOSEを使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE]で定義されています。

埋め込み証明は、データモデルのシリアライズに証明を含めるメカニズムです。このようなRECOMMENDED埋め込み証明メカニズムの1つが、検証可能なクレデンシャルのData Integrity 1.0 [VC-DATA-INTEGRITY]で定義されています。

この2種類の保護メカニズムは相互排他的ではありません。追加の保護メカニズム仕様も、セクション5.13 保護メカニズム仕様の規則に従って定義される場合があります。

例 15: 埋め込み証明を使用する検証可能なクレデンシャル

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "did:example:6fb1f712ebe12c27cc26eebfe11",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://subject.example/subject/3921",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "https://university.example/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
  }
}

上の埋め込み証明は、元のクレデンシャルを、 proofプロパティを介して元のデータにデジタル署名を付加することで保護します。その結果、最新のプログラミング環境やデータベースシステムで容易に管理できる検証可能なクレデンシャルが得られます。

例 16: SD-JWT形式のエンベロープ証明を使用する検証可能なクレデンシャル

eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0
Q3REZCb1UiLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ
.
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwcz
ovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6
Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLT
AxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIlNFOHp4bmduZTNNbWEwLUNm
S2dlYW1rNUVqU1NfOXRaNlN5NDdBdTdxRWMiLCJjT3lySEVrSlZwdEtSdURtNkNZVTREajJvRkExd0
JQRjFHcTJnWEo1NXpzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJh
Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibVNfSVBMa0JHcTIxbVA3Z0VRaHhOck
E0ZXNMc1ZKQ1E5QUpZNDFLLVRQSSJdfSwiX3NkIjpbIlhTSG9iU05Md01PVl9QNkhQMHNvMnZ1clNy
VXZ3UURYREJHQWtyTXk3TjgiXX0sIl9zZCI6WyJQNE5qWHFXa2JOc1NfRzdvdmlLdm1NOG0yckhDTm
5XVVV2SXZBbW9jb2RZIiwieFNvSHBKUXlCNGV1dmg4SkFJdDFCd1pjNFVEOHY5S3ZOTmVLMk9OSjFC
QSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2
lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNzAzNjI1OTAxLCJleHAiOjE3MzUyNDgzMDEsImNuZiI6eyJq
d2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6Inl1Zlo1SFUzcU
NfOTRMbkI3Zklzd0hmT0swQlJra0Z5bzVhd1QyX21ld0tJWUpLMVNfR0QySVB3UjRYUTZpdFEiLCJ5
IjoiRmEtV2pOd2NLQ1RWWHVDU2tCY3RkdHJOYzh6bXdBTTZWOWxudmxxd1QyQnRlQ0ZHNmR6ZDJoMF
VjeXluTDg0dCJ9fX0
.
M7BFJB9LEV_xEylSJpP00fd_4WjrOlXshh0dUv3QgOzw2MEGIfSfi9PoCkHJH7TI0InsqkD6XZVz38
MpeDKekgBW-RoDdJmxnifYOEJhKpJ5EN9PvA007UPi9QCaiEzX
~
WyJFX3F2V09NWVQ1Z3JNTkprOHNXN3BBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbG
UvY3JlZGVudGlhbHMvMTg3MiJd
~
WyJTSEc4WnpfRDVRbFMwU0ZrZFUzNXlRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIi
wgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d
~
WyJqZzJLRno5bTFVaGFiUGtIaHV4cXRRIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbX
BsZXMvZGVncmVlLmpzb24iXQ
~
WyItQmhzaE10UnlNNUVFbGt4WGVXVm5nIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJ0SEFxMEUwN
nY2ckRuUlNtSjlSUWRBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd
~
WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ

上のエンベロープ証明は、元のクレデンシャルを、元のデータをデジタル署名エンベロープにカプセル化することで保護します。その結果、検証可能なクレデンシャルは、 SD-JWT形式を理解するツールを使用して処理できるようになります。

検証可能な提示はMAY、複数の検証可能なクレデンシャルからの情報を集約するために使用してもかまいません。

検証可能な提示はSHOULD、存続期間を極めて短くし、検証者が提供するチャレンジに結び付けるべきです。その実現方法の詳細は、保護メカニズム、転送プロトコル、および検証者のポリシーによって異なります。特定の保護メカニズムまたは埋め込みプロトコルによって追加要件が定義されていない限り、検証者は通常、検証可能な提示が、提示された検証可能なクレデンシャルと相関しているとは想定できません。

デフォルトグラフは、検証可能な提示において、検証可能な提示グラフとも呼ばれます。

検証可能な提示には、次のプロパティが定義されています。

id: id プロパティは任意です。これはMAY、検証可能な提示に一意の識別子を付与するために使用してもかまいません。存在する場合、セクション4.4 識別子の規範的指針にMUST 従わなければなりません。
type: type プロパティはMUST、存在しなければなりません。これは、検証可能な提示の型を表現するために使用されます。このプロパティの値の1つはMUST、 VerifiablePresentationでなければなりませんが、追加の型をMAY含めてもかまいません。関連する規範的指針として、セクション4.5 型にMUST 従わなければなりません。
verifiableCredential: verifiableCredential プロパティはMAY、存在してもかまいません。その値は、 MUST、1つ以上の検証可能なクレデンシャルおよび／またはエンベロープされた検証可能なクレデンシャルオブジェクトでなければなりません（値はMUST NOT、数値、文字列、URLなどのオブジェクト以外の値であってはなりません）。これらのオブジェクトは、検証可能なクレデンシャルグラフと呼ばれ、 MUST、保護メカニズムを使用して保護された情報を表現しなければなりません。詳細については、セクション5.12 検証可能なクレデンシャルグラフを参照してください。
holder: 検証可能な提示にはMAY、holder プロパティを含めてもかまいません。存在する場合、その値はMUST、 URLまたは id プロパティを含むオブジェクトのいずれかでなければなりません。RECOMMENDEDとして、 URL形式のholder値、またはそのid値には、参照解決したときに、保有者に関する機械可読情報を含む文書が得られるものを使用してください。その情報は、検証に使用でき、対象となる情報は検証可能な提示で表現されたものです。 holder プロパティが存在しない場合、保有者に関する情報は保護メカニズムを介して取得されるか、または妥当性検証には関係しません。ここでいう妥当性検証の対象は検証可能な提示です。

以下の例は、検証可能な提示を示しています。

例 17: 提示の基本構造

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{ ... }]
}

上に示したverifiableCredential プロパティの内容は、この仕様で説明する検証可能なクレデンシャルグラフです。

検証可能な提示には、ペイロードを「エンベロープする」保護メカニズムを使用して保護された1つ以上の検証可能なクレデンシャルを含めることができます。たとえば、JOSEおよびCOSEを使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE]です。これは、verifiableCredentialプロパティを、typeが EnvelopedVerifiableCredentialであるオブジェクトに関連付けることで実現できます。

EnvelopedVerifiableCredential: エンベロープされた検証可能なクレデンシャルを含むオブジェクトを、 verifiableCredentialプロパティを介して検証可能な提示に関連付けるために使用されます。オブジェクトの@contextプロパティはMUST、存在し、この仕様の基底コンテキストなどのコンテキストを含まなければなりません。そのコンテキストは、この仕様が提供する基底コンテキストで定義されるid、type、および EnvelopedVerifiableCredentialの各用語を少なくとも定義します。オブジェクトのid値はMUST、 data: URL [RFC2397]でなければなりません。これは、保護された検証可能なクレデンシャルをエンベロープ型セキュリティ方式で表現します。たとえば、 JOSEおよびCOSEを使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE]です。オブジェクトのtype値はMUST、 EnvelopedVerifiableCredentialでなければなりません。

以下の例は、検証可能な提示に、エンベロープされた検証可能なクレデンシャルが含まれる例を示しています。

例 18: 提示の基本構造

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{
    "@context": "https://www.w3.org/ns/credentials/v2",
    "id": "data:application/vc+sd-jwt,QzVjV...RMjU",
    "type": "EnvelopedVerifiableCredential"
  }]
}

注記: エンベロープされたコンテンツをRDFとして処理する

実装者が、このセクションで説明したオブジェクトと、id値によって表現されたエンベロープされた提示を RDF環境で処理し、RDFに関連するオブジェクト間の関係を作成したい場合があります。これを行う必要性とメカニズムはユースケースによって異なるため、実装にも依存します。

ペイロードを「エンベロープする」メカニズムを使用して保護された検証可能な提示を表現できます。そのようなメカニズムには、たとえば、 JOSEおよびCOSEを使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE]があります。これは、 typeがEnvelopedVerifiablePresentationであるオブジェクトを使用することで実現できます。

EnvelopedVerifiablePresentation: エンベロープされた検証可能な提示を表現するために使用されます。オブジェクトの@contextプロパティはMUST、存在し、コンテキストを含まなければなりません。たとえば、この仕様の基底コンテキストです。そのコンテキストは、少なくともid、type、および EnvelopedVerifiablePresentation の各用語を、この仕様が提供する基底コンテキストで定義されるとおりに定義します。オブジェクトのid 値はMUST、data: URL [RFC2397]でなければなりません。これは、保護された検証可能な提示を、エンベロープ型保護メカニズムで表現します。たとえば、 JOSEおよびCOSEを使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE]です。オブジェクトのtype値はMUST、 EnvelopedVerifiablePresentationでなければなりません。

以下の例は、エンベロープされた検証可能な提示を示しています。

例 19: エンベロープされた検証可能な提示の基本構造

{
  "@context": "https://www.w3.org/ns/credentials/v2",
  "id": "data:application/vp+jwt,eyJraWQiO...zhwGfQ",
  "type": "EnvelopedVerifiablePresentation"
}

一部のゼロ知識暗号方式では、保有者が、主張を保有していることを間接的に証明できる場合があります。その主張は検証可能なクレデンシャルから得たものであり、その検証可能なクレデンシャルに含まれるすべての主張を開示する必要はありません。このような方式では、検証可能なクレデンシャルを使用して、提示可能なデータを導出できます。そのデータは暗号学的に表明されるため、検証者は、発行者を信頼する場合、その値を信頼できます。

一部の選択的開示方式では、主張の一部を共有できます。それらは検証可能なクレデンシャルから導出されます。

注記: ゼロ知識証明を使用する提示が可能です

ZKP形式の検証可能な提示の例として、直接埋め込まれた検証可能なクレデンシャルの代わりに派生データを含むものについては、セクション5.7 ゼロ知識証明を参照してください。

Patには、値が21である
overAgeプロパティがあります — 図11 Patが21歳を超えていることを表現する基本的な主張。

保有者はMAY、 verifiableCredential プロパティを検証可能な提示で使用して、検証可能なクレデンシャルを任意の発行者（自身を含む）から含めてもかまいません。ある発行者が、ある検証可能なクレデンシャルにおいて保有者と同一である場合、その主張は、その検証可能なクレデンシャルにおいて 自己表明とみなされます。このような自己表明された主張は、それを含む検証可能な提示を保護するものと同じメカニズム、または他の検証可能なクレデンシャルに使用できる任意のメカニズムによって保護できます。

自己表明の対象となる主体、つまり自己表明された主張の主体は限定されないため、これらの主張には、保有者、含まれている他の検証可能なクレデンシャルのいずれか、さらには検証可能な提示自体についての言明も含められます。この提示は、自己表明された検証可能なクレデンシャルを含むものです。いずれの場合も、id プロパティは、特定の主体を識別するために使用されます。これは、その主体に関する主張を記述するオブジェクト内で、検証可能なクレデンシャルが自己表明ではない場合と同様に使用されます。

検証可能な提示が、自己表明された検証可能なクレデンシャルを含み、そのクレデンシャルが、同じ検証可能な提示と同じメカニズムのみを使用して保護される場合、MUST、holder プロパティを含めなければなりません。

検証可能なクレデンシャルに対して定義されたすべての規範的要件は、自己表明された検証可能なクレデンシャルにも適用されます。

検証可能なクレデンシャルが検証可能な提示に含まれる場合、 issuer プロパティについて、その検証可能なクレデンシャルにおける値が、holder プロパティについて検証可能な提示に設定された値と同一であるとき、そのクレデンシャルは自己表明されたものとみなされます。

以下の例は、検証可能な提示が、自己表明された検証可能なクレデンシャルを埋め込む例を示しています。そのクレデンシャルは、検証可能な提示と同じメカニズムを使用して保護されます。

例 20: 埋め込みData Integrity証明で保護され、自己表明された検証可能なクレデンシャルを含む検証可能な提示

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "holder": "did:example:12345678",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
    "issuer": "did:example:12345678",
    "credentialSubject": {
      "favoriteCheese": "Gouda"
    },
    { ... }
  }],
  "proof": [{ ... }]
}

以下の例は、検証可能な提示が、自己表明された検証可能なクレデンシャルを埋め込む例を示しています。そのクレデンシャルは、主張を保持し、その対象は検証可能な提示です。そのクレデンシャルは、検証可能な提示と同じメカニズムを使用して保護されます。

例 21: 埋め込みData Integrity証明で保護され、検証可能な提示に関する自己表明された検証可能なクレデンシャルを含む検証可能な提示

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
  "holder": "did:example:12345678",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "type": ["VerifiableCredential", "ExampleAssertCredential"],
    "issuer": "did:example:12345678",
    "credentialSubject": {
      "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
      "assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
    },
    "proof": { ... }
  }],
  "proof": { ... }
}

セクション4. 基本概念で導入した概念を基礎として、このセクションでは検証可能なクレデンシャルに関するより複雑なトピックを検討します。

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

検証可能なクレデンシャルの信頼モデルは、次の前提に基づいています。

検証者は、発行者が、その検証者が受け取ったクレデンシャルを検証可能な形で発行していることを期待します。これは、次のいずれかを満たすことで確立できます。
- 発行者が、クレデンシャルを保護メカニズムで保護し、その発行者がクレデンシャルを生成したことを確立します。言い換えると、発行者が検証可能なクレデンシャルを発行します。
- クレデンシャルが、発行者がクレデンシャルを生成したこと、およびそのクレデンシャルが転送中にも保管中にも改ざんされていないことを明確に確立する方法で転送されます。この前提は、検証者のリスク評価によっては緩和される場合があります。
すべてのエンティティは、検証可能データレジストリが改ざんを検出可能であり、どのデータがどのエンティティによって制御されているかを示す正確な記録であることを期待します。これは通常、その公開方法によって実現されます。信頼できる公開者からのピアツーピアプロトコル、公開アクセス可能で広く知られたWebサイト（コンテンツハッシュ付き）、ブロックチェーンなどを使用できます。エンティティが自らに関するメタデータを公開する場合、その公開情報はエンティティの秘密鍵で保護することにより、完全性を保護できます。
保有者と検証者は、発行者が、主張、すなわちクレデンシャル内で主体について行った主張の内容を保証し続けることを期待します。また、クレデンシャルについて、もはやそこに含まれる主張を保証できなくなった場合には、速やかに失効させることも期待します。
保有者は、発行者の主張を信頼する場合があります。これは、保有者と発行者の間に事前から信頼関係が存在するためです。たとえば、雇用主が従業員に雇用関係を示す検証可能なクレデンシャルを提供したり、政府が市民に電子パスポートを発行したりする場合があります。
事前の信頼関係が存在しない場合、保有者は、発行者が、提供される検証可能なクレデンシャルを発行する資格を持つかどうかを、何らかの帯域外の手段で判断できる場合があります。

注記：保有者が発行者を常に信頼する必要はありません。発行された検証可能なクレデンシャルは、主体に関する表明であっても、その主体が保有者とは限らず、または誰を対象ともしない場合があるためです。そして保有者は、その情報の真実性に対する責任を負うことなく、検証者にその情報を中継する意思があるかもしれません。
保有者は、クレデンシャルリポジトリがクレデンシャルを安全に保管し、クレデンシャルを保有者以外の誰にも開示しないことを期待します（保有者は後にそれらを検証者に提示する場合があります）。また、リポジトリが管理している間にクレデンシャルを破損または紛失しないことも期待します。

この信頼モデルは、次の点を確保することで他の信頼モデルと異なります。

発行者と検証者は、クレデンシャルリポジトリについて何も知る必要がありません。
発行者は、検証者について何も知る必要がありません。

検証者が、どの発行者を、どのデータまたは目的について信頼するかをどのように決定するかは、この勧告の範囲外です。有名な組織などの発行者は、その評判だけを理由に、多くの検証者から信頼される場合があります。発行者と検証者が、参加規則によって全メンバーが互いを信頼するコミュニティのメンバーである場合もあります。また、検証者が、発行者を審査し、信頼リストに掲載する責任を負う特定の信頼サービスプロバイダーを信頼する場合もあります。このような信頼リストの例には、電子署名およびインフラストラクチャ（ESI）；信頼リスト [ETSI-TRUST-LISTS] で規定されたものや、 Adobe 承認済み信頼リストがあります。

発行者と検証者の間の期待を切り離すことにより、より柔軟で動的な信頼モデルが形成され、市場競争と顧客の選択肢が増えます。

この信頼モデルと、作業グループが検討したさまざまな脅威モデルとの相互作用の詳細については、検証可能なクレデンシャルのユースケース [VC-USE-CASES]を参照してください。

注記: 信頼モデルは従来の認証局システムと異なります

この仕様で詳述するデータモデルは、より従来型の認証局の信頼モデルが提供するような、推移的信頼モデルを前提としません。検証可能なクレデンシャル・データモデルでは、検証者は発行者を直接信頼するか、信頼しないかのいずれかです。検証可能なクレデンシャル・データモデルを使用して推移的信頼モデルを構築することも可能ですが、実装者には、セキュリティ上の弱点について学ぶことを強く推奨します。この弱点は、認証局システムが採用するように信頼を広範に委譲することによって生じます。

検証可能なクレデンシャルに外部リソースへのリンクを含める場合、そのリソースが検証可能なクレデンシャルの発行後に変更されたかどうかを把握できることが望まれます。これは、外部リソースをリモートから取得する場合だけでなく、発行者および／または検証者がリソースのコピーをローカルにキャッシュしている可能性がある場合にも当てはまります。また、検証可能なクレデンシャルで使用されるJSON-LDコンテキストの内容が、検証者による使用時にも、発行者による使用時と同じであることを確認できることも望まれます。

完全性保護を関連リソースにまで拡張するため、発行者は、検証可能なクレデンシャルにMAY、 relatedResourceプロパティを含めることができます：

relatedResource

relatedResourceプロパティの値はMUST、次の形式の1つ以上のオブジェクトでなければなりません：

プロパティ	説明
`id`	リソースの識別子はREQUIREDであり、セクション4.4 識別子で定義された形式に準拠します。この値は、関連リソースオブジェクトの一覧内で一意でなければなりません（MUST）。
`mediaType`	任意で（OPTIONAL）、 IANAメディアタイプレジストリに掲載されている有効なメディアタイプを指定します。
`digestSRI`	1つ以上の暗号学的ダイジェスト。これは、`hash-expression` ABNF文法として定義され、その文法はサブリソース完全性仕様のセクション3.5： `integrity`属性で定義されています。
`digestMultibase`	1つ以上の暗号学的ダイジェスト。これは、`digestMultibase` プロパティとして検証可能なクレデンシャルData Integrity 1.0仕様のセクション2.6：リソースの完全性で定義されています。

relatedResourceに関連付けられた各オブジェクトはMUST、少なくとも digestSRIまたはdigestMultibaseの値を含まなければなりません。

mediaTypeが指定されている場合、idプロパティで識別されたリソースを HTTPセマンティクスを使用して取得する実装はSHOULD、次のようにするべきです：

Accept HTTPヘッダーでそのメディアタイプを使用する。
応答に異なるメディアタイプのContent-Type HTTPヘッダーが含まれている場合、その応答を拒否する。

検証可能なクレデンシャル内で idプロパティを含む任意のオブジェクトにはMAY、 digestSRIまたはdigestMultibaseプロパティのいずれかを追加することで、完全性情報を注記できます。いずれのプロパティにもMAY、追加の任意プロパティであるmediaTypeを付加できます。

選択的開示またはリンク不能な開示を行うことが望まれるオブジェクトは、 SHOULD NOT、relatedResource配列のオブジェクトとして含めるべきではありません。

準拠する検証者実装が、 id（relatedResourceオブジェクト内）に基づいて、準拠文書内のリソースを使用し、対応する暗号学的ダイジェストが relatedResourceオブジェクトの値に示されている場合、その実装はMUST、取得したリソースのダイジェストを計算しなければなりません。発行者が提供したダイジェストと、取得したリソースについて計算されたダイジェストが一致しない場合、準拠する検証者実装はMUST、エラーを生成しなければなりません。

実装者には、最新かつ信頼できるハッシュアルゴリズムを選択できるよう、 FIPS 180-4セキュアハッシュ標準や商用国家安全保障アルゴリズムスイート2.0などの適切な情報源を参照することを推奨します。本書の執筆時点では、 sha384を、実装者が使用するハッシュアルゴリズムの最低強度とみなすべきです（SHOULD）。

JSON-LDコンテキストを参照する関連リソースの完全性オブジェクトの例を示します。

例 25: digestSRIプロパティの使用（base64でエンコードされた SHA2-384）

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestSRI":
    "sha384-l/HrjlBCNWyAX91hr6LFV2Y3heB5Tcr6IeE4/Tje8YyzYBM8IhqjHWiWpr8+ZbYU"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestSRI":
    "sha384-zNNbQTWCSUSi0bbz7dbua+RcENv7C6FvlmYJ1Y+I727HsPOHdzwELMYO9Mz68M26"
}]

例 26: digestMultibaseプロパティの使用（base64-url-nopadでエンコードされたSHA2-256）

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestMultibase": "uEiBZlVztZpfWHgPyslVv6-UwirFoQoRvW1htfx963sknNA"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestMultibase": "uEiBXOT-8adbvubm13Jy2uYgLCUQ2Cr_i6vRZyeWM8iedfA"
}]

システムで、期限切れの検証可能なクレデンシャルを手動または自動で更新できるようにすることは有用です。検証可能なクレデンシャルの有効期間について詳しくは、セクションB.7 有効期間を参照してください。この仕様では、refreshService プロパティを定義します。これにより、発行者は更新サービスへのリンクを含めることができます。

発行者は、検証可能なクレデンシャル内の要素として更新サービスを含めることができます。これは、そのサービスが検証者または保有者（あるいはその両方）向けである場合です。また、更新サービスを検証可能な提示内に含めることもできます。これは、そのサービスが保有者のみを対象とする場合です。後者の場合、保有者は、検証可能なクレデンシャルを更新してから、検証可能な提示を作成し、検証者と共有できます。前者の場合、更新サービスを検証可能なクレデンシャル内に含めることで、保有者または検証者は、将来そのクレデンシャルを更新できます。

更新サービスは、クレデンシャルが期限切れであるか、発行者がクレデンシャルのステータス情報を公開していない場合にのみ使用されることが想定されています。発行者は、 refreshService プロパティを、公開情報を含まないか、更新サービスが何らかの方法で保護されていない検証可能なクレデンシャルに含めないことが推奨されます。

refreshService: refreshService プロパティの値はMUST、受信者が検証可能なクレデンシャルを更新できるだけの十分な情報を、受信者のソフトウェアに提供する 1つ以上の更新サービスでなければなりません。各refreshService値はMUST、そのtypeを指定しなければなりません。各更新サービスの正確な内容は、個々のrefreshService 型の定義によって決まります。

例 27: 発行者によるrefreshServiceプロパティの使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/age/v1"
  ],
  "type": ["VerifiableCredential", "AgeVerificationCredential"],
  "issuer": "did:key:z6MksFxi8wnHkNq4zgEskSZF45SuWQ4HndWSAVYRRGe9qDks",
  "validFrom": "2024-04-03T00:00:00.000Z",
  "validUntil": "2024-12-15T00:00:00.000Z",
  "name": "Age Verification Credential",
  "credentialSubject": {
    "overAge": 21
  },
  "refreshService": {
    "type": "VerifiableCredentialRefreshService2021",
    "url": "https://registration.provider.example/flows/reissue-age-token",
    "refreshToken": "z2BJYfNtmWRiouWhDrbDQmC2zicUPBxsPg"
  }
}

上の例で、発行者は、自動 refreshServiceを指定しています。このサービスは、検証可能なクレデンシャルを更新サービスの urlへPOSTすることで使用できます。この特定の検証可能なクレデンシャルは、元の発行者以外の誰とも共有することを意図していない点に注意してください。

注記: 認証を伴わないクレデンシャルの更新

refreshService プロパティを検証可能なクレデンシャルに配置して、検証者が利用できるようにすると、保有者から制御権と同意する機会を奪い、検証可能なクレデンシャルを検証者へ直接発行できるようになります。これにより、保有者が迂回されます。

利用条件は、発行者または保有者が、検証可能なクレデンシャルまたは検証可能な提示が発行された際の条件を伝えるために使用できます。発行者は、自身の利用条件を検証可能なクレデンシャル内に配置します。保有者は、自身の利用条件を検証可能な提示内に配置します。この仕様では、利用条件に関する情報を表現するための termsOfUse プロパティを定義します。

termsOfUse プロパティの値は、特に次の事項の一部または全部を検証者へ伝えるために使用できます：

検証可能なクレデンシャルの発行時に使用された手続きまたはポリシー。たとえば、それらの手続きやポリシーを確認できる公開場所への参照（「発行元への問い合わせ」によるプライバシー問題を回避するため）、またはそれらを定義する標準の名称を提供します。
この発行者の規則およびポリシーのうち、検証可能なクレデンシャルを検証者に提示する際に適用されるもの。たとえば、それらの規則やポリシーを確認できる公開場所への参照（「発行元への問い合わせ」によるプライバシー問題を回避するため）を提供します。
発行者がこの特定の検証可能なクレデンシャルを発行する際に、その権限の根拠となったエンティティの識別情報。

termsOfUse: termsOfUse プロパティの値はMUST、作成者がクレデンシャルまたは提示を発行した際の利用条件ポリシーを1つ以上指定しなければなりません。受信者（保有者または検証者）が指定された利用条件に従わない場合、それは受信者自身の責任で行われ、明示された利用条件に違反すると法的責任を負う可能性があります。各termsOfUse値はMUST、その型（例：TrustFrameworkPolicy）を指定しなければならず、MAY、そのインスタンスの idを指定できます。各利用条件の正確な内容は、個々のtermsOfUse 型の定義によって決まります。

例 28: 発行者によるtermsOfUseプロパティの使用

{
  {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/undefined-terms/v2"
    ],
    "id": "urn:uuid:08e26d22-8dca-4558-9c14-6e7aa7275b9b",
    "type": [
      "VerifiableCredential",
      "VerifiableAttestation",
      "VerifiableTrustModel",
      "VerifiableAuthorisationForTrustChain"
    ],
    "issuer": "did:ebsi:zZeKyEJfUTGwajhNyNX928z",
    "validFrom": "2021-11-01T00:00:00Z",
    "validUntil": "2024-06-22T14:11:44Z",
    "credentialSubject": {
      "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
      "reservedAttributeId": "60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
      "permissionFor": [{
        "schemaId": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zHgbyz9ajVuSProgyMhsiwpcp8g8aVLFRNARm51yyYZp6",
        "types": [
          "VerifiableCredential",
          "VerifiableAttestation",
          "WorkCertificate"
        ],
        "jurisdiction": "https://publications.europa.eu/resource/authority/atu/EUR"
      }]
    },
    "termsOfUse": {
      "type": "TrustFrameworkPolicy",
      "trustFramework": "Employment&Life",
      "policyId": "https://policy.example/policies/125",
      "legalBasis": "professional qualifications directive"
    },
    "credentialStatus": {
      "id": "https://api-test.ebsi.eu/trusted-issuers-registry/v5/issuers/did:ebsi:zvHWX359A3CvfJnCYaAiAde/attributes/60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
      "type": "EbsiAccreditationEntry"
    },
    "credentialSchema": {
      "id": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zCSHSDwrkkd32eNjQsMCc1h8cnFaxyTXP5ByozyVQXZoH",
      "type": "JsonSchema"
    }
  }
}

上の例で、発行者は、検証可能なクレデンシャルの発行における法的根拠が、「Employment&Life」トラストフレームワークを使用した「professional qualifications directive」であることを、ポリシーへの具体的なリンクとともに表明しています。

この機能は、政府が発行する検証可能なクレデンシャルで使用されることが想定されています。市民の機密データが予期せず使用されることを防ぐため、デジタルウォレットに対し、その使用を同種の政府機関に限定するよう指示できます。同様に、民間企業が発行する一部の検証可能なクレデンシャルは、使用を組織内の特定部門または営業時間内に限定することが想定されています。実装者には、この発展途上の機能について、検証可能なクレデンシャル実装ガイドライン [VC-IMP-GUIDE]文書の該当セクションを参照することを推奨します。

発行者は、検証者へ追加の裏付け情報を提供するため、検証可能なクレデンシャルに証拠を含めることができます。検証者はこれを使用して、検証可能なクレデンシャル内の主張を信頼する際の確信度を判断できます。たとえば、発行者は、主体が提供した物理的文書を確認したり、クレデンシャルを発行する前に一連の経歴調査を行ったりできます。特定の状況では、この情報は検証者が、特定のクレデンシャルを信頼することに伴うリスクを判断する際に役立ちます。

この仕様では、証拠情報を表現するためのevidence プロパティを定義します。

evidence

存在する場合、evidence プロパティの値はMUST、単一のオブジェクトまたは1つ以上のオブジェクトの集合でなければなりません。すべての証拠オブジェクトについて、次のプロパティが定義されています：

id: id プロパティは任意です（OPTIONAL）。証拠オブジェクトの一意な識別子を提供するために使用してもMAY。存在する場合は、セクション 4.4 識別子の規範的指針に従わなければなりません（MUST）。
type: type プロパティは必須です（REQUIRED）。これは、そのオブジェクトが表現する証拠情報の型を示すために使用されます。セクション 4.5 型の関連する規範的指針に従わなければなりません（MUST）。

注記: 証拠を提供する方法については実装ガイドを参照してください

添付ファイル、クレデンシャルへの参照、およびクレデンシャル以外のデータがこの仕様でどのようにサポートされ得るかについては、セクション 5.3 関連リソースの完全性を参照してください。

例 29: スキル達成クレデンシャルを裏付ける証拠の例

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "id": "http://1edtech.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "OpenBadgeCredential"
  ],
  "issuer": {
    "id": "https://1edtech.edu/issuers/565049",
    "type": "Profile"
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": "AchievementSubject",
    "name": "Alice Smith",
    "activityEndDate": "2023-12-02T00:00:00Z",
    "activityStartDate": "2023-12-01T00:00:00Z",
    "awardedDate": "2024-01-01T00:00:00Z",
    "achievement": [{
      "id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64",
      "type": ["Achievement"],
      "name": "Basic Barista Training",
      "criteria": {
        "narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course."
      },
      "description": "This achievement certifies that the bearer is proficient in basic barista skills."
    }]
  },
  "evidence": [{
      // url to an externally hosted evidence file/artifact
      "id": "https://videos.example/training/alice-espresso.mp4",
      "type": ["Evidence"],
      "name": "Talk-aloud video of double espresso preparation",
      "description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
      // digest hash of the mp4 video file
      "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
    }
  ]
}

上のevidenceの例で、発行者は、主体が達成内容を実演している動画を、クレデンシャルの証拠として保有していることを表明しています。

注記: 証拠は保護メカニズムとは異なる目的を持ちます

evidence プロパティは、使用される保護メカニズムが提供する情報とは異なる追加情報を提供します。 evidence プロパティは、検証可能なクレデンシャルに関連する文書証拠などの裏付け情報を表現するために使用されます。これに対して、保護メカニズムは、発行者の真正性と検証可能なクレデンシャルの完全性に関する、機械で検証可能な数学的証明を表現するために使用されます。保護メカニズムについて詳しくは、セクション4.12 保護メカニズムを参照してください。

ゼロ知識証明は保護メカニズムであり、保有者は、ある値を含む検証可能なクレデンシャルを保持していることを、実際の値を開示せずに証明できます。たとえば、誕生日を明らかにせず、その人物が25歳を超えていることを証明できます。このデータモデルは、ゼロ知識証明を使用した保護に対応しています。

ゼロ知識証明メカニズムによって実現される、検証可能なクレデンシャルと互換性のある機能には、次のものがあります：

選択的開示：検証可能なクレデンシャル内のプロパティを、保有者が検証者へ選択的に開示します。これにより、保有者は、検証者が必要とする情報だけを正確に提供できます。また、派生した検証可能なクレデンシャルを、提示時に検証者のデータスキーマに従った形式で、発行者を関与させずに生成することもできます。これにより、保有者は、発行された検証可能なクレデンシャルを非常に柔軟に利用できます。
リンク不能な開示：検証可能なクレデンシャル内のプロパティを、保有者が検証者へリンク不能な形で開示します。ブラインド署名はリンク不能な開示を可能にします。これにより、保有者が1人以上の検証者に対して複数回提示する際に生じる、相関付けの一般的な要因を取り除けます。また、保有者は提示ごとに異なる署名値を共有できるため、共有されるデータ量も削減されます。
保有者および／または主体の、相関不能な識別。これにより、保有者は、クレデンシャルが自分に発行されたことを証明できます。また、主体は、クレデンシャルが自分について発行されたことを、相関可能な識別子を共有せずに証明できます。これにより、共有する必要のあるデータ量も削減されます。この機能を使用すると、複数の検証可能なクレデンシャルを、複数の発行者から取得して単一の検証可能な提示にまとめることもできます。その際、検証可能なクレデンシャルや主体の識別子を検証者へ開示する必要はありません。

保護メカニズムを作成する仕様の作成者はMUST NOT、検証者が、保有者について、異なる検証可能な提示を複数の異なる検証者に対して行った際に相関付けられるような情報を漏えいする設計にしてはなりません。

すべてのゼロ知識証明メカニズムが、すべての機能に対応しているわけではありません。特定のゼロ知識証明メカニズムが提供する機能と技術の詳細、およびそれらを検証可能なクレデンシャルで使用する際の規範的要件は、そのゼロ知識証明メカニズムで検証可能なクレデンシャルを保護するための仕様に記載されます。そのような仕様の例については、Data Integrity BBS暗号スイートv1.0を参照してください。

ほとんどの場合、保有者がゼロ知識メカニズムを検証可能なクレデンシャルで利用するには、発行者が、これらの機能をサポートする方法で検証可能なクレデンシャルを保護する必要があることに注意してください。

以下の図は、データモデルを使用して検証可能なクレデンシャルをゼロ知識で発行および提示する方法を示しています。

左側の検証可能な
クレデンシャル1と検証可能なクレデンシャル2が、右側の
提示内にある派生クレデンシャル1と派生クレデンシャル2に対応しています。検証可能なクレデンシャル1には、
コンテキスト、型、ID、発行者、発行日、有効期限、
クレデンシャル主体、および証明が含まれます。
クレデンシャル主体には名、姓、生年月日が含まれ、
証明には署名、正当性の証明、および属性が含まれます。
検証可能なクレデンシャル2には、コンテキスト、型、ID、発行者、発行日、有効期限、
クレデンシャル主体、および証明が含まれます。
クレデンシャル主体には大学が含まれ、大学には学部、学部には授与学位が含まれます。
証明には署名、正当性の証明、および属性が含まれます。右側の
提示の図には、コンテキスト、型、ID、
検証可能なクレデンシャル、および証明が含まれます。
検証可能なクレデンシャルには派生クレデンシャル1と
派生クレデンシャル2が含まれ、証明には共通リンク
シークレットが含まれます。派生クレデンシャル1には、コンテキスト、型、ID、
発行者、発行日、クレデンシャル主体、および証明が含まれます。
クレデンシャル主体には18歳超が含まれ、証明には
署名の知識が含まれます。派生クレデンシャル2には、
コンテキスト、型、ID、発行者、発行日、クレデンシャル主体、および証明が含まれます。
クレデンシャル主体には学位が含まれ、証明には署名の知識が含まれます。
線によって、検証可能なクレデンシャル1の生年月日と
派生クレデンシャル1の18歳超が結ばれています。別の線によって、検証可能なクレデンシャル2の授与学位と
派生クレデンシャル2の学位が結ばれています。 — 図 12 ZKP提示における、クレデンシャルと派生クレデンシャルの関係を示す図。

以下に、検証可能なクレデンシャルと検証可能な提示の例を示します。これらは、Data Integrity BBS暗号スイートv1.0のリンク不能な選択的開示の保護メカニズムを使用しています。

例 30: 基底証明を伴うData Integrity BBS 暗号スイートを使用した検証可能なクレデンシャル

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:web:utopia.example",
    "image": "data:image/png;base64,iVBORw0KGg...VORK5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgo...g==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": [
        "PermanentResidentCard"
      ],
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2026-09-05T00:00:00Z",
  "validUntil": "2027-09-05T23:59:59Z",
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2026-09-05T17:21:31Z",
      "verificationMethod": "did:web:utopia.example#zDnae...QGW8",
      "cryptosuite": "ecdsa-rdfc-2019",
      "proofPurpose": "assertionMethod",
      "proofValue": "z4fJttfr...kn9P"
    },
    {
      "type": "DataIntegrityProof",
      "verificationMethod": "did:web:utopia.example#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
      "cryptosuite": "bbs-2023",
      "proofPurpose": "assertionMethod",
      "proofValue": "u2V0ChVhQiJsvokWSE4Cq999Bw9aluhWuToMG7qGNtAx5I2_LmNjRPCMcTLoiBc_HV8gjvgvSNnrFNK50Ubf1gIN8i8sHUWwUzqdDMevqlO8qVOWgki1YQM6iv5KVLQKPLTMEAHhSEWyz3z3hrSSQJTjO8vIFJgMWaLnxEOgYUkAwn3mL9Hhr-t6oc0OXaYjMBPYyPIQUnwdYYKipusluRJ7SzUrZmv4RxeebXFP1W0GGgnhEIBufF7eulvisZDSTSVWCkn1KMnStOgmhPPjOCIDvXVY2Xxbm61KFgc2pSZJwhV5kLxZV9igRbX8uzqgdbnLyerjY7DzJdVggryiDkfzraDE3VOas9Ls5wKk4oBfAtvO0QZikpLOL1VeBZy9pc3N1ZXI"
     
    }
  ]
}

上の例は、検証可能なクレデンシャルです。この例では、発行者がBBSベースのリンク不能な開示方式を有効にして基底証明を作成しています。保有者はその基底証明を使用し、元の検証可能なクレデンシャルから特定の情報だけを開示する派生証明を作成できます。

例 31: 派生クレデンシャルおよび派生証明を伴うData Integrity BBS暗号スイートを使用した検証可能な提示

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://w3id.org/citizenship/v4rc1"
      ],
      "type": [
        "VerifiableCredential",
        "PermanentResidentCardCredential"
      ],
      "issuer": {
        "id": "did:web:vcplayground.org",
        "image": "data:image/png;base64,iVBORw0KG...YII="
      },
      "credentialSubject": {
        "type": [
          "PermanentResident",
          "Person"
        ],
        "birthCountry": "Arcadia"
      },
      "proof": [
        {
          "type": "DataIntegrityProof",
          "verificationMethod": "did:web:utopia.example#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
          "cryptosuite": "bbs-2023",
          "proofPurpose": "assertionMethod",
          "proofValue": "u2V0DhVkDEJOplpVKV9UBPos-YnSuy7u-_wuxUUcElOCVqJwekpfS8pDYv5mlIiADqJNm62CgfJMG1SeBV9Ri5DlmMAOaWayl51Aqc_fPn1V756d-P51JNwmlPQ9RmyYQPGfk3_8z0KF57H_seUFGZOYAtul85f9rypgN_emBvVApxUSMClqvNSgNVQ_sqVS1ICFkz9MIuTv6Ng6F8CNm0svtv1Tnkmjn6I4bgP0b46j57-lgiAP6Xb72RCnppHyfcuc6z9NB82BgIPCHzu2V3u8sWHyPS1JzVDLUiPVWUy6Oar0A4q9QLP4y92Q4JpJRx0Bl-x3cvCcBZp8ESDphMEDoMgEBqWVdWEZ_KQa2JrYuiWeHfK81WPNlJimOp4xl4CotHqx1NIinSB7jmrtcQ-0dIX_vz5wnYwhlP44rE7TgydrFE_16BYk0hkfKJw8sGCQNxqcUMHGh262ZOie2ASifU8OXd5TZOgTaUXRauwCrAPQZnQKnAQ8j8hBLgD_0Ujzt2Yk6dQueUv493jnmWJMnCbAy33MuRhHSqSxHVJBXOhhUX3s79HY0V-uLkGOZw_61HRpAi0W4spLv77ehUlwW5N35VFbs_THFXGA5AgY3Cg1vY-K5SyqpH5BlWhAcTRwoDKboqp0tOecM5qpZyuAORQ7fK2JddnEMHmvOKW7x_ugykAbQm6DeqhyGPtKxuiSulr-IHFK-KyGCXPAAKbk7X5Hkf29q7tOEGTIU4_9ga88PtiQKJTu7Ao8ABBEg9Gqt-KcfqfPgt8cqwxGtjW21sD3bSbtUiWNQO3ZDPelP9ToXbduEPpsNEYwxRbMtS5SF6YDqy16Bo8uyw41jnKvb-E5ABF-2MGjxB9zt8ZH_TJirGP_IMt0ssYrODZAlJbakLKiD5NH3g-xlvMTHxrD8VEzJakACnJIrm3X9J7MjUM_YTqth99oc2Yq2HLlgwYb1hD3T6jsIaY8zRPzA2ybKdXxZ3ahxyc_nbLDnP2fVNbUj8P9EX2Av_GvmnSYRsE5Wmcblhao6Ref1EF8YFF6JFT8SO2WiAAIBAIQABAUHhAABBxFYRXsiY2hhbGxlbmdlIjoiejFBREtDNVFBdW1Tb1Jud1NDSHRhUXBvQSIsImRvbWFpbiI6InZjcGxheWdyb3VuZC5vcmcifQ"
          
        }
      ]
    }
  ]
}

上の検証可能な提示には、前の例にある情報のリンク不能な部分集合を含む検証可能なクレデンシャルと、派生証明が含まれています。検証者はその派生証明を使用して、情報が想定された発行者に由来し、この特定の情報交換に結び付けられていることを検証できます。

実装者には、時刻値の表現と処理は見かけほど単純ではなく、すぐには明らかにならないうえ、世界各地で一様に扱われてもいない、さまざまな特性があることを理解するよう推奨します。例を次に示します：

さまざまな地域で、グレゴリオ暦以外の暦法が実際に使用されています。
夏時間を処理する際には、次の点を理解することが重要です。 1）すべての地域で実施されているわけではない、2）必ずしも同じ日や同じ時刻に開始または終了するわけではない、 3）調整量や調整方向が、他の類似地域と常に一致するとは限らない。
すべてのソフトウェアシステムがうるう秒を考慮するとは限りません。特に、うるう秒の導入以前の日付と時刻ではその可能性があります。うるう秒は、エポックからの正確なミリ秒オフセットに依存する高感度なシステムに影響する可能性があります。ただし、ほとんどのアプリケーションで影響を受ける時点は、うるう秒そのものの1秒間だけであることに注意してください。つまり、対象のシステムがうるう秒を理解しているかどうかにかかわらず、直近のうるう秒の後の時点は、常に翌日の最初の時点（たとえば、 2023-01-01T00:00:00Z）として表現できます。

これらは、壁時計に表示されるような実際の時刻が、ある地域には存在しても、別の地域には存在しない場合があることを示す例の一部にすぎません。このため、実装者には、夏時間の影響を受ける値よりも、Zタイムゾーンを基準とする値など、より普遍的な時刻値を使用することを推奨します。

この仕様では、dateTimeStamp構文を使用することで、普遍的に認識される日付と時刻の組み合わせを増やし、時刻値が誤って解釈される可能性を減らそうとしています。この構文は、[XMLSCHEMA11-2]仕様で最初に確立されました。異なるタイムゾーン間での誤解釈を減らすため、準拠文書で表現されるすべての時刻値はSHOULD、 dateTimeStamp形式で指定するべきです。形式には、値の末尾のZで表される協定世界時（UTC）、またはUTCを基準とするタイムゾーンオフセットを使用します。オフセットなしで誤って直列化された時刻値はMUST、UTCとして解釈しなければなりません。 UTCを基準とする有効なタイムゾーンオフセットの例には、Z、+01:00、 -08:00、および +14:00があります。許容されるすべての値の形式的な定義については、このセクション末尾の正規表現を参照してください。

タイムゾーンの定義は、その管理機関によって変更されることがあります。既存の検証可能なクレデンシャルを置き換えたり、新しいものを発行したりする際、実装者には、ローカルタイムゾーンの規則変更によって有効期間に予期しない空白が生じないよう確認することを推奨します。たとえば、標準オフセットがUTC-8であり、2024年に夏時間の実施を停止することが決定された America/Los_Angelesゾーンを考えます。ある検証可能なクレデンシャルの validUtil 値が2024-07-12T12:00:00-07:00であった場合、そのクレデンシャルが validFrom値2024-07-12T12:00:00-08:00で再発行されると、検証可能なクレデンシャルが無効となる1時間の空白が生じます。

dateTimeStamp値の妥当性を確認したい実装者は、以下に示す正規表現を使用できます。この正規表現は、便宜のため[XMLSCHEMA11-2]仕様から転載したものです。疑義を避けるために明記すると、[XMLSCHEMA11-2]にある正規表現が規範的な定義です。以下の正規表現に一致するすべての dateTimeStamp値が、有効な時点を表すとは限らないことに注意してください。たとえば、この正規表現ではすべての月に31日を許可しており、うるう年とうるう秒だけでなく、本来は存在しない日付も許容します。ただし、有効な dateTimeStamp値を生成する最新のシステムライブラリは、多くの場合、有効なdateTimeStamp値を正しく生成します。以下に示す正規表現は、ここで可読性のために含めた空白を除けば、最新システム上でライブラリが生成した日付と時刻を処理する用途には、多くの場合十分です。

例 32: 有効なXML Schema 1.1パート2のdateTimeStampを検出する正規表現

-?([1-9][0-9]{3,}|0[0-9]{3})
-(0[1-9]|1[0-2])
-(0[1-9]|[12][0-9]|3[01])
T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))

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

検証可能なクレデンシャルは、主体を確実に識別する手段として意図されています。ロールベースアクセス制御（RBAC）および属性ベースアクセス制御（ABAC）が、主体によるリソースへのアクセスを認可する手段として、この識別に依存することは認識されています。しかし、この仕様は RBACまたはABACの完全な解決策を提供するものではありません。認可フレームワークを併用しない限り、認可はこの仕様の適切な用途ではありません。

ワーキンググループは、この仕様の策定中に認可のユースケースを検討しており、この仕様の上に構築されるアーキテクチャ層として、その作業を進めています。

この仕様では、将来の拡張ポイントとして使用できるよう、いくつかのプロパティを予約しています。一部の実装者はこれらのプロパティに関心を示しましたが、この仕様に含めるのは時期尚早だと判断されました。これらのプロパティはいずれも、この仕様では定義されていない点に注意することが重要です。したがって実装者は、これらのプロパティの使用が実験的とみなされることに注意してください。

実装者はMAY、これらのプロパティを使用してもかまいません。ただし、規範的な仕様が定められる過程ではSHOULD、プロパティ自体および／またはその意味が変更されると想定するべきです。実装者はSHOULD NOT、その実装を説明する公開仕様なしにこれらのプロパティを使用するべきではありません。

以下のプロパティの使用方法に関する衝突を避けるため、実装はMUST、予約済みプロパティに関連付けられた値の中で typeプロパティを指定しなければなりません。type情報の追加について詳しくは、セクション4.5 型を参照してください。

予約済みプロパティ説明

confidenceMethod 検証可能なクレデンシャルまたは検証可能な提示の内部、あるいはそれ自体にあるプロパティの値が正確であるという検証者の確信度を高めるために使用できる、1つ以上の方法を指定するプロパティです。関連する語彙 URLはMUST、 https://www.w3.org/2018/credentials#confidenceMethodでなければなりません。使用例を含め、確信度判定方法について詳しく知りたい実装者は、検証可能なクレデンシャルの確信度判定方法v1.0仕様を参照できます。

renderMethod クレデンシャルを視覚、聴覚、触覚、またはその他の形式でレンダリングするための、 1つ以上の方法を指定するプロパティです。関連する語彙URLはMUST、 https://www.w3.org/2018/credentials#renderMethodでなければなりません。使用例を含め、レンダリング方法について詳しく知りたい実装者は、検証可能なクレデンシャルのレンダリング方法v1.0仕様を参照できます。

予約済みプロパティ	説明
`confidenceMethod`	検証可能なクレデンシャルまたは検証可能な提示の内部、あるいはそれ自体にあるプロパティの値が正確であるという検証者の確信度を高めるために使用できる、1つ以上の方法を指定するプロパティです。関連する語彙 URLはMUST、 `https://www.w3.org/2018/credentials#confidenceMethod`でなければなりません。使用例を含め、確信度判定方法について詳しく知りたい実装者は、検証可能なクレデンシャルの確信度判定方法v1.0仕様を参照できます。
`renderMethod`	クレデンシャルを視覚、聴覚、触覚、またはその他の形式でレンダリングするための、 1つ以上の方法を指定するプロパティです。関連する語彙URLはMUST、 `https://www.w3.org/2018/credentials#renderMethod`でなければなりません。使用例を含め、レンダリング方法について詳しく知りたい実装者は、検証可能なクレデンシャルのレンダリング方法v1.0仕様を参照できます。

この仕様で定義された拡張ポイント、およびこのセクションで定義された予約済み拡張ポイントに関連する仕様の非公式な一覧は、検証可能なクレデンシャル拡張で確認できます。このディレクトリ内で予約済み拡張ポイントを参照する項目は、実験的なものとして扱うべきです（SHOULD）。

この文書で提供されるデータモデルをネイティブに使用していないものの、この仕様の複数の概念と整合するデジタルクレデンシャル形式がいくつかあります。公開時点における、そのようなデジタルクレデンシャル形式の例には、 JSON Web Token（JWT）、 CBOR Web Token（CWT）、 JSON Advanced Electronic Signature（JAdES）、 ISO-18013-5:2021 （mDL）、 AnonCreds、 Gordian Envelope、および Authentic Chained Data Container（ACDC）があります。

概念的に整合するデジタルクレデンシャル形式を、このセクションに示す規則に従って準拠文書へ変換できる場合、その形式は「W3C検証可能なクレデンシャル・エコシステムと互換性がある」とみなされます。仕様の作成者には、検証可能なクレデンシャル・エコシステムとの互換性を実現する変換を文書化する際、次の規則に従うことを推奨します。変換仕様は、次の要件を満たします：

MUST、このデータモデルへの変換が一方向のみであるか、往復変換可能であるかを明示しなければなりません。
MUST、往復変換可能な変換を行う場合は@context値を保持しなければなりません。
MUST、この仕様で説明されるデータモデルへ変換する場合、結果が準拠文書でなければなりません。
MUST、入力文書に登録済みメディアタイプを指定しなければなりません。
SHOULD、この仕様のデータモデルへの指定された変換アルゴリズムによって、準拠文書が生成されることを実証するテストスイートを提供するべきです。
SHOULD、変換後の準拠文書で使用されるすべてのセマンティクスが、Linked Dataのベストプラクティスに従うことを保証するべきです。詳細な指針については、セクション4.1 はじめに、セクション 5.2 拡張性、およびLinked Data公開のベストプラクティス [LD-BP]を参照してください。

注記: 何が検証可能なクレデンシャルを構成するのか？

デジタルクレデンシャルがW3C検証可能なクレデンシャル・エコシステムと互換性があるとみなされるのは、準拠文書であり、かつ少なくとも1つの保護メカニズムを使用して、この仕様に記述されたそれぞれの要件を満たす場合に限られます。一部のコミュニティでは、準拠文書ではないデジタルクレデンシャル形式を「検証可能なクレデンシャル」と呼ぶことがありますが、そう呼んでも、そのデジタルクレデンシャルがこの仕様に準拠することには決してなりません。たとえば、 SD-JWT-VC [SD-JWT-VC]仕様では名称に「VC」という文字が使用されていますが、同仕様はW3C検証可能なクレデンシャルと互換性がないことを明示しています。

検証可能なクレデンシャルを表現する場合（たとえば、提示内で表現する場合）、ある検証可能なクレデンシャル内のデータを、別の検証可能なクレデンシャル内の同じデータだと誤認しないようにすることが重要です。たとえば、2つの検証可能なクレデンシャルがあり、それぞれに次の形式のオブジェクトが含まれているとします：{"type": "Person", "name": "Jane Doe"}。この場合、一方のオブジェクトが他方と同じ人物を記述しているかどうかは判断できません。言い換えると、同じエンティティおよび／またはプロパティについて述べていることを確認せずに、2つの検証可能なクレデンシャル間のデータを併合すると、破損したデータセットが生じる可能性があります。

異なる検証可能なクレデンシャルのデータが誤って混在しないように、検証可能なクレデンシャルグラフという概念を使用し、各検証可能なクレデンシャルをカプセル化します。単純な検証可能なクレデンシャル、すなわちJSON-LD文書に単一のクレデンシャルと、場合によっては関連する証明が含まれている場合、このグラフはデフォルトグラフです。提示では、 verifiableCredentialプロパティに関連付けられた各値は、その提示内でそれぞれ独立した名前付きグラフとなり、その型はVerifiableCredentialGraph です。このグラフには、単一の検証可能なクレデンシャルまたはエンベロープ化された検証可能なクレデンシャルが含まれます。

これらのグラフを使用すると、JSON-LD処理に具体的な効果が生じ、あるグラフ内のグラフノード識別子が、別のグラフ内の識別子から適切に分離されます。入力をアプリケーション固有のJSON-LD文書に限定する実装者も、ある検証可能なクレデンシャルのデータを別のクレデンシャルのデータと併合する場合には、この点を考慮する必要があります。たとえば、credentialSubject.idが両方の検証可能なクレデンシャルで同じであっても、それらに含まれるオブジェクトは、前の段落で説明した「Jane Doe」形式である可能性があります。類似するプロパティを持つように見えても、URLなどのグローバル識別子を使用するidプロパティを含まないオブジェクトは、併合しないことが重要です。

セクション4.12 保護メカニズムで説明したように、実装者が準拠文書を保護する際に使用できる方式は複数あります。有用性と相互運用性を最大限に高めるため、準拠文書を保護する新しい方法を策定する仕様の作成者に対し、このセクションの指針を示します。

保護メカニズム仕様はMUST、準拠文書のコンテンツ完全性を保護する規範的アルゴリズムを文書化しなければなりません。このアルゴリズムはMAY、汎用的なものとすることができ、MAY、準拠文書以外のデータを保護するために使用してもかまいません。

保護メカニズム仕様はMUST、保護された準拠文書内の情報だけを返す検証アルゴリズムを提供しなければなりません。返される情報には、proof、JOSE/COSEヘッダーパラメータ、署名などの保護メカニズム情報を含めません。検証アルゴリズムはMAY、保護メカニズムの詳細など、妥当性検証時やデバッグ目的で役立つ可能性のある追加情報を返してもかまいません。検証アルゴリズムはMUST、メディアタイプ（文字列 inputMediaType）と入力データ（バイト列またはマップとして渡されるinputData）を受け取るインターフェイスを提供しなければなりません。保護メカニズム仕様はMAY、この文書で指定されたものに加えて、別のアルゴリズムとインターフェイスを提供してもかまいません。検証アルゴリズムは、少なくとも次の項目を含む検証結果を返します：

boolean verified: 検証が成功した場合はtrue、成功しなかった場合は falseとなる検証ステータス。
map verifiedDocument: 正常に保護された情報だけを含む文書。
string mediaType: [RFC6838]で定義されたメディアタイプ。

保護メカニズム仕様はSHOULD、妥当性検証に不可欠であり、URLから参照されるすべての情報について完全性保護を提供するべきです。この保護を実現できるメカニズムについては、セクション 5.3 関連リソースの完全性およびセクション C.1 基底コンテキストで説明します。

新しい型の埋め込み証明を作成する保護メカニズム仕様は、 MUST、プロパティを指定し、そのプロパティによって検証可能なクレデンシャルまたは検証可能な提示を証明グラフに関連付けなければなりません。保護メカニズムに対する要件は次のとおりです：

保護メカニズムはMUST、証明グラフで使用されるすべての用語を定義しなければなりません。たとえば、この仕様で使用されるものと同じ方法で、語彙仕様と@contextファイルを定義できます。
保護メカニズムはMUST、検証可能なクレデンシャルまたは検証可能な提示内のすべてのグラフを保護しなければなりません。ただし、証明グラフが検証可能なクレデンシャルまたは検証可能な提示自体を保護している場合、その証明グラフは除きます。

注記

最後の要件は、保護メカニズムがデフォルトグラフを保護し、検証可能な提示では、提示に含まれる各検証可能なクレデンシャルを、それぞれの証明グラフとともに保護することを意味します。図 9または図 14も参照してください。

proofプロパティは、[VC-DATA-INTEGRITY]で定義されており、MAY、埋め込み保護メカニズムで使用してもかまいません。

保護メカニズム仕様はSHOULD、その保護メカニズムを保護メカニズムセクション（検証可能なクレデンシャル拡張文書内）に登録するべきです。

注記: 保護メカニズムの選択はユースケースによって異なります

許容される保護メカニズムは複数あり、この仕様は、検証可能なクレデンシャルまたは検証可能な提示で使用する特定の保護メカニズムを義務付けていません。この仕様を策定したワーキンググループは、次の2つの保護メカニズムを標準化しました：検証可能なクレデンシャル Data Integrity 1.0 [VC-DATA-INTEGRITY]およびJOSEおよびCOSEを使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE]です。コミュニティで知られているその他の保護メカニズムについては、保護メカニズムセクション（検証可能なクレデンシャル拡張文書内）を参照してください。

セクション3. コアデータモデル、4. 基本概念、および5. 高度な概念で説明するデータモデルは、検証可能なクレデンシャルまたは検証可能な提示の正準の構造表現です。すべての構文は、このデータモデルを特定の形式で表したものです。このセクションでは、application/vcおよびapplication/vpについて、データモデルをJSON-LDで直列化する方法を規定します。これらは、それぞれ検証可能なクレデンシャルと検証可能な提示の基本メディアタイプです。構文マッピングはJSON-LDに対してのみ提供されますが、アプリケーションやサービスは、application/vcまたはapplication/vpに戻すことができる、その他のデータ表現構文（XML、YAML、CBORなど）を使用できます。検証および妥当性検証の要件はデータモデルに基づいて定義されるため、すべての直列化構文は、処理、妥当性検証、または比較のために、決定論的な方法でデータモデルへ変換しなければなりません。

この仕様でプロパティ値に想定される多重度と、その値を格納する結果のデータ型は、プロパティによって異なる場合があります。次のプロパティは、存在する場合は単一の値として表現されます：id（セクション4.4 識別子）、issuer（セクション4.7 発行者）、および validFrom/validUntil（セクション4.9 有効期間）。その他のすべてのプロパティは、存在する場合、単一の値または値の配列として表現されます。

この仕様では、この仕様で説明するデータモデルを直列化するためにJSON-LD 1.1を使用します。JSON-LDが有用なのは、グラフベースのデータモデルを表現できるためです。このデータモデルは検証可能なクレデンシャルの基盤です。また、機械可読なセマンティクスを表現でき、データモデルを拡張する際にも有用です（セクション3. コアデータモデルおよび5.2 拡張性を参照）。

JSON-LDは、Linked Dataを直列化するために使用されるJSONベースの形式です。Linked Dataは、リソース記述フレームワーク（RDF）[RDF11-CONCEPTS]を使用してモデル化されます。 RDFは、文のグラフをモデル化する技術です。各文は、1つの主体→プロパティ→値（エンティティ→属性→値とも呼ばれます）の関係であり、この仕様では主張と呼びます。 JSON-LDは、慣用的なJSONを使ってRDFを表現できる技術であり、JSONに慣れた開発者は、RDFをJSONとして利用するアプリケーションを作成できます。詳細については、JSON-LDとRDFの関係を参照してください。

一般に、この文書で説明するデータモデルと構文により、開発者は検証可能なクレデンシャルをおおむねJSON文書として扱うことができ、例をわずかに変更して、そのままソフトウェアシステムにコピー＆ペーストできます。このアプローチの設計目標は、異種のソフトウェアシステム間のグローバルな相互運用性を確保しつつ、導入の障壁を低くすることです。このセクションでは、これを可能にするために使用されるJSON-LDの機能のうち、ほとんどの開発者には意識されないと思われるものの、その詳細が実装者の関心を引く可能性があるいくつかの機能を説明します。この仕様で使用されるJSON-LD 1.1のとりわけ注目すべき機能には、次のものがあります：

@idキーワードと@typeキーワードは、それぞれidおよびtypeにエイリアス化されており、開発者はこの仕様を慣用的なJSONとして使用できます。
整数、日付、計量単位、URLなどのデータ型は自動的に型付けされ、それを必要とするユースケースに対してより強い型保証を提供します。
verifiableCredentialプロパティは、JSON-LD 1.1グラフコンテナとして定義されています。そのため、名前付きグラフを作成し、異なるエンティティが表明したデータ集合を分離する必要があります。これにより、たとえば、各発行者が提供するデータグラフと、保有者が検証可能なクレデンシャルを提示する際に提供するデータグラフとが暗号学的に適切に分離され、各グラフの情報の出自が保持されます。
@protectedプロパティ機能は、JSON-LD 1.1の機能であり、この仕様で定義された用語が上書きされないようにするために使用されます。これは、同じ@context宣言が検証可能なクレデンシャルまたは検証可能な提示の先頭で行われる限り、データモデルの利用者がJSON-LD 1.1プロセッサを使用するかどうかにかかわらず、その利用者が理解しているすべての用語について相互運用性が保証されることを意味します。

相互運用性を高めるため、この仕様ではデータモデルのJSON-LD表現の使用を制限します。JSON-LDのコンパクト化文書形式を使用しなければなりません（MUST）。これは、application/vcまたはapplication/vpメディアタイプを使用するデータモデルのすべての表現に適用されます。

セクション 6.3 型固有のクレデンシャル処理で詳しく説明するように、一部のソフトウェアアプリケーションは汎用的なJSON-LD処理を行わない場合があります。準拠文書の作成者は、@context値内のJSON-LDキーワードを使用して、検証可能なクレデンシャルまたは検証可能な提示内の値にグローバルな影響を与えると、相互運用性が低下する可能性があることに注意してください。たとえば、@baseキーワードまたは@vocabキーワードの一方または両方を設定する場合です。これらの値を設定すると、@context値に対する誤ったJSON Schemaテストが、型固有のクレデンシャル処理を行い、@baseおよび／または@vocab値が@context値内に表現されることを想定していない実装において、失敗する可能性があります。

相互運用性を高めるため、準拠文書の作成者には、型固有のクレデンシャル処理の実行時に容易に検出できないJSON-LD機能を使用しないよう強く推奨します。これらの機能には、次のものがあります：

@context値内でのJSON-LDキーワードのインライン宣言。これらのキーワードは、@baseまたは@vocabの設定などにより、文書の用語と値の処理をグローバルに変更します
@vocabのリセットなど、以前のコンテキストの宣言を上書きするJSON-LDコンテキストの使用
@contextプロパティ内でのJSON-LDコンテキストのインライン宣言
JSON-LD用語と型について、完全なURL（たとえば、 https://www.w3.org/2018/credentials#VerifiableCredentialまたは https://vocab.example/myvocab#SomeNewType）を、それらの値の短縮形（たとえば、VerifiableCredentialまたはSomeNewType）の代わりに使用すること。これらの短縮形は、JSON-LDの@contextマッピング（たとえば、 https://www.w3.org/ns/credentials/v2）で明示的に定義されます

この仕様では@vocabの使用に注意を促していますが、実験、開発、ローカル環境への導入を容易にする場合など、この機能の正当な用途もあります。アプリケーション開発者が本番環境で@vocabを使用したい場合、用語の衝突を減らし、セマンティックな相互運用性の利点を活かすためにその使用は推奨されません。また、@vocabを使用すると「未定義の用語」エラーの報告が無効になり、後からの使用によって、以前の@vocab宣言が上書きされることを理解するよう強く推奨します。@vocabの値が異なると、文書に含まれる情報のセマンティクスが変わる可能性があるため、これらの変更が開発中のアプリケーションに影響するかどうか、およびどのように影響するかを理解することが重要です。

JSON-LD 1.1を使用すると、リスト、配列、さらにはリストのリストも表現できます。リストや配列を必要とするユースケースでRDFセマンティクスを利用したい場合は、 JSON-LD 1.1のリストに関する指針に従うことを推奨します。

一般に、JSON配列には順序がありますが、JSON-LD配列は@listキーワードを使用しない限り、順序付けられません。

注記: 配列の順序は重要でない場合があります

型固有のクレデンシャル処理を実行することでこのデータモデルを使用できますが、その方法で配列を使用する場合は、上記の指針に従わない限り、JSON-LDでは配列内の項目の順序が保証されないことに注意する必要があります。これは予期しない動作を引き起こす可能性があります。

JSON構造または順序がアプリケーションにとって重要な場合は、それらの要素を@jsonとしてマークするために、そのユースケース固有の@contextを使用することを推奨します。そのような宣言の例を以下に示します。

例 33: 行列を埋め込みJSONデータ構造として定義する@contextファイル

{
  "@context":
    {
      "matrix": {
        "@id": "https://website.example/vocabulary#matrix",
        "@type": "@json"
      }
    }
}

上に示したコンテキストを下の例で使用し、https://website.example/matrix/v1コンテキストを@contextプロパティに含めると、 credentialSubject.matrix内の値はJSONセマンティクスを保持し、2次元行列内のすべての要素の正確な順序が保持されます。

例 34: 埋め込みJSONデータ構造を含む検証可能なクレデンシャル

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://website.example/matrix/v1"
  ],
  "id": "http://university.example/credentials/1872",
  "type": [
    "VerifiableCredential",
    "ExampleMatrixCredential"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "matrix": [
      [1,2,3,4,5,6,7,8,9,10,11,12],
      [1,1,1,1,1,1,1,1,0,0,0,0],
      [0,0,1,1,1,1,1,1,1,0,0,0]
    ]
  }
}

[RFC6838]で定義されるメディアタイプは、検証可能なクレデンシャルを表現するために使用される構文と、その他の有用な処理指針を識別します。

この仕様のデータモデルを表現するために使用される構文は、メディアタイプによって識別されるべきです（SHOULD）。また、このセクションに示す慣例には従うべきです（SHOULD）。これは、検証可能なクレデンシャルとともにメディアタイプを定義または使用する場合に適用されます。

コアデータモデルに関連付けられたメディアタイプは2つあり、セクションD. IANAに関する考慮事項に記載されています： application/vcおよびapplication/vp。

application/vcおよびapplication/vpメディアタイプは、特定の保護メカニズムを意味するものではなく、保護メカニズムと併用することを意図しています。これらのメディアタイプの完全性を保護するには、保護メカニズムを適用する必要があります。コンテンツの伝達に使用されるメディアタイプにかかわらず、そのコンテンツが安全であると想定してはなりません。

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

開発者またはシステムが、精度の低いメディアタイプを使用して検証可能なクレデンシャルまたは検証可能な提示を伝達する場合があります。精度の低いメディアタイプを使用する理由には、次のものがあります：

ファイル拡張子が利用できず、メディアタイプを特定できない場合、Webサーバーはデフォルトでtext/plainまたはapplication/octet-streamを使用します。
開発者が、ファイルのコンテンツよりも具体性の低いメディアタイプに対応するファイル拡張子を追加する場合。たとえば、.jsonによってメディアタイプがapplication/jsonとなり、.jsonldによって application/ld+jsonとなる場合があります。
プロトコルが特定のトランザクションに対して、より精度の低いメディアタイプを必要とする場合。たとえば、application/jsonをapplication/vpの代わりに使用する場合です。

使用されるメディアタイプが対象のプロトコルで許容され、ペイロードから意図されたメディアタイプを特定できる場合、実装者にはエラーを発生させないことを強く推奨します。たとえば、アプリケーションがapplication/vcメディアタイプに関連付けられたルールに準拠するペイロードだけを受け入れるものの、ペイロードにapplication/jsonまたはapplication/ld+jsonが付されている場合、そのペイロードがより精度の高いメディアタイプにも準拠するかどうかを判定するため、次の手順を実行できます：

ペイロードをJSON文書として解析します。
@contextプロパティの最初の要素がhttps://www.w3.org/ns/credentials/v2と一致することを確認します。
application/vpメディアタイプであると想定します。これは、JSON文書にトップレベルのtypeプロパティがあり、そこにVerifiablePresentation要素が含まれる場合です。その後も追加のチェックを実行し、ペイロードがこの仕様に準拠した検証可能な提示を表現していることを確認することが想定されます。
application/vcメディアタイプであると想定します。これは、JSON文書にトップレベルのtypeプロパティがあり、そこにVerifiableCredential要素が含まれる場合です。その後も追加のチェックを実行し、ペイロードがこの仕様に準拠した検証可能なクレデンシャルを表現していることを確認することが想定されます。

可能な限り、実装者には、この仕様で定義されるすべてのペイロードに最も精度の高いメディアタイプを使用することを推奨します。また、精度の低いメディアタイプが付されたペイロードであっても、より精度の高いメディアタイプを付すために必要なルールを満たしていないとは限らないことを認識するよう推奨します。同様に、精度の高いメディアタイプが付されたペイロードが、必ずしもそのメディアタイプに関連付けられた要件を満たすとは限りません。ペイロードの受信者は、関連付けられたメディアタイプにかかわらず、対象のシステムで使用するための要件にペイロードが準拠していることを確認するため、適切なチェックを実行することが想定されます。

HTTPクライアントとサーバーは、Acceptヘッダー、およびコンテンツタイプを示す際に、検証可能なクレデンシャルおよび検証可能な提示に関連付けられたメディアタイプを使用します。HTTPサーバーがAcceptヘッダーを無視して別のコンテンツタイプを返す場合や、415 Unsupported Media Typeなどのエラーコードを返す場合があることに、実装者は注意してください。

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

JSONは異なる種類の情報を表現できるため、特定のJSON文書の利用者が作成者の意図を正しく解釈できるのは、その文書にコンテキストを与え、他の表現との曖昧さを解消する情報を持っている場合に限られます。この解釈を支援する情報は、JSON文書の外部に完全に置くことも、文書内からリンクすることもできます。コンパクト化JSON-LD文書には、@contextプロパティが含まれます。このプロパティは、主張を表現するためのコンテキスト情報を内部で表現するか、その情報へリンクします。これらの機能により、JSON-LD文書を1つのコンテキストから別のコンテキストへ変換する汎用プロセッサを作成できます。ただし、利用者が想定しているコンテキストと形状をすでに使用しているJSON-LD文書を受け取る場合、その処理は必要ありません。発行者が検証可能なクレデンシャルのJSON-LD文書を作成する場合など、文書の作成者は相互運用性を促進するため、適切なJSON-LDコンテキストを提供し、これらのルールに従う必要があります。

以下の説明は、JSON-LD文書の内容を利用するために変換する必要がないよう、利用者のアプリケーションがすでに理解しているコンテキストと形状で文書が表現されていることを保証する方法の理解に役立ちます。これは、利用者がコンテキストを一切理解する必要がないという意味ではありません。利用するアプリケーションは、選択したコンテキストと文書形状の組み合わせだけを理解すればよく、その他のものを理解する必要はないという意味です。発行者は、他のJSON形式のデータと同様に、コンテキストと自身の検証可能なクレデンシャルに関する情報を公開し、汎用プロセッサを使用しない利用者を支援できます。

汎用JSON-LD処理は、JSON-LDソフトウェアライブラリを使用して、準拠文書にさまざまな変換を施して処理するメカニズムと定義されます。型固有のクレデンシャル処理は、JSON-LDソフトウェアライブラリを必要とせずに準拠文書を処理する、より軽量なメカニズムと定義されます。検証可能なクレデンシャルの利用者の中には、特定の型を持つクレデンシャルだけを利用すればよい利用者もいます。これらの利用者は、汎用処理の代わりに型固有のクレデンシャル処理を使用できます。型固有のクレデンシャル処理が望ましい場面には、次のものが含まれますが、これらに限定されません：

準拠文書に保護メカニズムを適用する前、または保護メカニズムで保護された準拠文書を検証した後に、データの完全性を確保する場合。
セクション 4.11 データスキーマで説明するJSON Schemaの妥当性検証を実行する場合。
検証可能なクレデンシャルまたは検証可能な提示を、そのコンテンツを格納または索引付けするシステムに直列化または逆直列化する場合。
検証可能なクレデンシャルまたは検証可能な提示をソフトウェアアプリケーション内で操作する際に、汎用JSON-LD処理を必要とする保護メカニズムに対する検証または妥当性検証を実行した後。
アプリケーションが+json構造化メディアタイプ接尾辞を使用してメディアタイプを処理することを選択した場合。

つまり、型固有のクレデンシャル処理は、利用または生成される文書が準拠文書である限り許容されます。

型固有のクレデンシャル処理を利用したい場合、実装者には次のルールに従うことを推奨します：

@contextプロパティに関連付けられたすべての値が想定された順序になっていること、コンテキストファイルの内容が各ファイルの既知の正しい暗号学的ハッシュと一致すること、および対象領域の専門家が、その内容が意図したユースケースに適切であると判断していることを確認します。

JSON Schemaと静的コンテキストファイルを併用することは、上記のルールを実装するための許容可能なアプローチの1つです。これにより、型固有のクレデンシャル処理を実行する際に、用語の適切な識別、型付け、および順序を確保できます。

上記のルールは、@contextメカニズムを通じてリテラルなJSONキーをURIにマッピングする場合に、2つの処理メカニズム間のセマンティックな相互運用性を保証します。汎用JSON-LD処理は、そのアルゴリズムに与えられた未知の@context値を使用し、すべての用語が正しく指定されていることを検証できます。一方、型固有のクレデンシャル処理を行う実装は、事前に理解できるよう設計された特定の@context値だけを受け入れ、JSON-LD APIを呼び出すことなく同じセマンティクスを得ます。言い換えると、データ交換が行われるコンテキストは、両方の処理メカニズムに対して、@contextを同じ準拠文書のセマンティクスにつながる方法で使用することにより、明示的に示されます。

基本クラス	目的
`CredentialEvidence`	evidenceプロパティに配置される、特定の証拠タイプのスーパークラスとして機能します。
`CredentialSchema`	credentialSchemaプロパティに配置される、特定のスキーマタイプのスーパークラスとして機能します。
`CredentialStatus`	credentialStatusプロパティに配置される、特定のクレデンシャルステータスタイプのスーパークラスとして機能します。
`ConfidenceMethod`	`confidenceMethod`プロパティに配置される、特定の信頼度メソッドタイプのスーパークラスとして機能します。
`RefreshService`	credentialRefreshプロパティに配置される、特定の更新サービスタイプのスーパークラスとして機能します。
`RenderMethod`	`renderMethod`プロパティに配置される、特定のレンダリングメソッドタイプのスーパークラスとして機能します。
`TermsOfUse`	termsOfUseプロパティに配置される、特定の利用規約タイプのスーパークラスとして機能します。

タイプ名：	application
サブタイプ名：	vc
必須パラメータ：	なし
符号化に関する考慮事項：	`application/vc`メディアタイプを使用するリソースは、`application/ld+json`メディアタイプのすべての要件に準拠する必要があるため、JavaScript Object Notation（JSON）データ交換形式のセクション11で定められているものと同じ符号化上の考慮事項が適用されます。
セキュリティに関する考慮事項：	検証可能なクレデンシャル・データモデル v2.0で定義されています。
連絡先：	W3C検証可能なクレデンシャル・ワーキンググループ public-vc-wg@w3.org

タイプ名：	application
サブタイプ名：	vp
必須パラメータ：	なし
符号化に関する考慮事項：	`application/vp`メディアタイプを使用するリソースは、`application/ld+json`メディアタイプのすべての要件に準拠する必要があるため、JavaScript Object Notation（JSON）データ交換形式のセクション11で定められているものと同じ符号化上の考慮事項が適用されます。
セキュリティに関する考慮事項：	検証可能なクレデンシャル・データモデル v2.0で定義されています。
連絡先：	W3C検証可能なクレデンシャル・ワーキンググループ public-vc-wg@w3.org

JSON-LD文書とハッシュ
URL： https://www.w3.org/2018/credentials# 解決後の文書： https://www.w3.org/2018/credentials/index.jsonld SHA2-256ダイジェスト： `9db03c54d69a8ec3944f10770e342b33e58a79045c957c35d51285976fc467c4`
URL： https://w3id.org/security# 解決後の文書： https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.jsonld SHA2-256ダイジェスト： `c7a06ccc144d9d72f435f64802fdfb802a32aefe8b0bcb7504f69754b8c0faeb`

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

要約

この文書のステータス

1. はじめに

1.1 検証可能な クレデンシャルとは何か？

1.2 エコシステムの概要

1.3 適合性

2. 用語

3. コアデータモデル

3.1 主張

3.2 クレデンシャル

3.3 プレゼンテーション

4. 基本概念

4.1 利用を開始する

4.2 検証可能なクレデンシャル

4.3 コンテキスト

4.4 識別子

主張: id

主張: type

主張: id

主張: type

4.5 型

主張: id

主張: type

主張: id

主張: type

4.6 名前と説明

主張: id

主張: type

主張: id

主張: id

主張: type

4.7 発行者

主張: id

主張: type

主張: id

主張: type

主張: id

主張: type

主張: id

主張: id

主張: type

4.8 クレデンシャルの主体

主張: id

主張: type

主張: id

主張: type

4.9 有効期間

主張: id

主張: type

主張: id

主張: type

4.10 ステータス

4.11 データスキーマ

4.12 保護メカニズム

4.13 検証可能な提示

エンベロープされた検証可能なクレデンシャル

エンベロープされた検証可能な提示

派生クレデンシャルを使用する提示

保有者の主張を含む提示

5. 高度な概念

5.1 信頼モデル

5.2 拡張性

主張: id

主張: type

主張: id

意味的相互運用性

5.3 関連リソースの完全性

5.4 更新

5.5 利用条件

5.6 証拠

5.7 ゼロ知識証明

5.8 時刻の表現

5.9 認可

5.10 予約済み拡張ポイント

5.11 エコシステムとの互換性

5.12 検証可能なクレデンシャルグラフ

5.13 保護メカニズム仕様

6. 構文

6.1 JSON-LD

1.1 検証可能なクレデンシャルとは何か？

C. コンテキスト、語彙、タイプ、およびクレデンシャルスキーマ

C.3.1 `sriString`データ型

E. 検証可能な提示の追加図