VCデータモデルv2.1草案で何が変わる？卒業証明書のデータ例で解説

ニュース原文：Verifiable Credentials Data Model v2.1 編集者ドラフト

W3Cで策定が進むVerifiable Credentials Data Model v2.1では、資格情報の名前や説明を複数の言語で扱う規定が明確化され、安全性やプライバシーに関する説明も整理されています。2026年9月27日付のドラフトが公開されており、現在も変更され得る開発中の仕様です。

本稿では2025年5月15日のv2.0勧告と比較し、「データに何を書けるか」「受け取ったシステムがどう使うか」を卒業証明書の例で説明します。多言語表現や拡張項目には既存の仕組みも含まれるため、今回明確になった規定と、関連仕様で具体化された使い方を分けて見ていきます。

一枚の証明書に日本語と英語の名前・説明を入れる

nameは「この証明書の名前」、descriptionは「この証明書が何を示すかの説明」です。まず、表示する文言を一つずつ入れる書き方を見ます。

以下のJSONは説明用の抜粋です。発行者、コンテキスト、署名などを省いており、単体で検証可能なVCではありません。後の例も同様です。

{
  "name": "卒業証明書",
  "description": "大学の卒業を証明します。"
}

このデータには表示文言が一組入っています。日本語と英語の両方を同じ証明書に持たせたい場合は、各文言に言語情報を付けて配列にまとめます。

{
  "name": [
    { "@value": "卒業証明書", "@language": "ja" },
    { "@value": "Graduation Certificate", "@language": "en" }
  ],
  "description": [
    { "@value": "大学の卒業を証明します。", "@language": "ja" },
    { "@value": "Certifies graduation from the university.", "@language": "en" }
  ]
}

@valueが表示する文言、@languageがその言語です。jaは日本語、enは英語を示します。ウォレット側で言語を選ぶ処理を実装すれば、日本語設定では「卒業証明書」、英語設定では「Graduation Certificate」を表示できます。ここで増えているのは、同じ資格情報を説明する表示文言の選択肢です。卒業したという主張そのものは、対象者の情報を入れるcredentialSubjectで別に表します。

v2.0のプロパティ定義は「文字列または言語情報付きの値」としていました。v2.1では、これらを「一つ以上」持てると明記されています。多言語の配列はv2.0にも説明されており、この例は規定が明確になった表現を示しています。単一値の例から配列への変更を、v2.0では不可能だった機能の追加と捉えるのは適切ではありません。名前と説明の規定

文言だけの値と言語付きの値を一緒に扱う

ドラフトには、通常の文字列と言語情報付きの値を同じ配列に入れる例も追加されています。卒業証明書の名前なら、次のような形です。

{
  "name": [
    "卒業証明書",
    { "@value": "Graduation Certificate", "@language": "en" }
  ]
}

これは「言語を指定していない名称」と「英語と明示した名称」を一緒に持つ表現です。最初の値が日本語の文字で書かれていても、この抜粋には機械が使うjaの指定はありません。証明書全体のデフォルト言語も設定されていなければ、言語未指定の値として扱います。日本語であることまで伝えたい場合は、前の例のように@languageを付けます。

さらに、アラビア語などの右から左へ書く文言には、言語情報に加えて@directionをrtlと指定できます。文字方向を指定する仕組み自体は既存機能です。言語と文字方向の説明

こうしたデータを受け取るウォレットには、文字列とオブジェクトの両方を読む処理が必要になります。対応する言語の値がない場合の表示も実装側で決めます。自動翻訳や、配列の先頭を優先言語とする規則が付くわけではありません。

証明書に対象者の鍵と表示方法を関連付ける

confidenceMethodとrenderMethodはv2.0ですでに予約されていた拡張項目です。v2.1では使い方を扱う別仕様への参照が加わっています。ここからの例は、その開発中の関連仕様に基づくものです。VCDM本体で新たに必須になった項目ではありません。予約済みの拡張項目

対象者に結び付けられた鍵を示す

confidenceMethodを使うと、発行者が対象者に結び付けた公開鍵を示せます。次の例では、山田花子さんについて記す場所に、その人に結び付いた鍵への参照を入れています。

{
  "credentialSubject": {
    "name": "山田花子",
    "confidenceMethod": [
      { "id": "did:example:alice#key-1", "type": "Multikey" }
    ]
  }
}

idは確認に使う鍵の識別子で、Multikeyは鍵の表現形式を示します。検証者は提示者にその場で用意した確認用データを送り、対応する秘密鍵で署名してもらいます。その署名を公開鍵で確認することで、提示者が、発行者の結び付けた鍵を使えると確かめられます。これはConfidence Methods仕様の鍵による確認方法に沿った説明です。

ここで表現しているのは「対象者との関係を確認するために使う鍵」です。証明書を発行した大学の署名とは役割が異なります。この確認が成功した後も、大学を信頼するか、その証明書を今回の手続きで受け入れるかの判断は残ります。

カード表示用のテンプレートを示す

renderMethodには、証明書をどう表示するかの手掛かりを入れられます。例えば、卒業証明書をカードとして表示するためのテンプレートを参照できます。

{
  "renderMethod": {
    "type": "TemplateRenderMethod",
    "renderSuite": "card",
    "template": {
      "id": "https://university.example/templates/degree-card.json",
      "mediaType": "application/json"
    }
  }
}

この例は「card方式で、このJSONテンプレートを使って表示する」という指定です。対応するウォレットはテンプレートと証明書の値を使い、例えば大学名や学位名を並べたカードを生成できます。上のURLは説明用で、実在するテンプレートではありません。Rendering Methods仕様のカード表示

学位などの証明内容はcredentialSubject、見せ方の指定はrenderMethodという形で役割を分けられます。実際の表示にはウォレットの方式対応が必要です。参照先が改ざんされていないかの確認や、安全な表示環境も検討します。例では完全性確認用の値を省略しています。

脅威モデルで発行から提示後までを確認

データの書き方に加えて、v2.1では関連する脅威モデルを参照しながら、セキュリティとプライバシーの検討事項を整理しています。脅威モデルでは、発行時の本人確認の失敗、端末の盗難、過剰な情報開示、提示後のデータ利用などを扱います。

例えば発行者が他人の情報を使った申請を受け入れてしまうと、誤った相手に正規のVCを発行する可能性があります。この場合、発行者による署名を確認できても、発行前の本人確認に問題が残ります。本人確認の方法や強度は、発行側と受入側の両方が用途に応じて検討する必要があります。

プライバシーでは、複数のサービスに同じ識別子を示すことで利用履歴が結び付けられる問題が挙げられます。氏名や生年月日の開示を減らす設計と、異なる提示を同じ人のものとして結び付けにくくする設計は、それぞれ検討が必要です。識別子に加え、署名や提示のパターンなどによる相関も考慮します。

これらは発行システム、ウォレット、提示の手順、受領後のデータ管理まで含めた全体のセキュリティ向上のための記述と言えます。

SD-JWT VCとの形式の違いを明示

のエコシステムの互換性では、IETFのSD-JWT VCとW3CのVCの関係について説明が加わっています。SD-JWT VCという名称に「VC」が含まれていても、W3C VCと互換の形式にはなりません。

ここで区別したいのが、資格情報の形式と、それを保護する方式です。W3C VCをSD-JWTで保護する方法は、別のVC JOSE/COSE仕様に定義されています。「SD-JWTを使う」という説明だけでは、どのデータモデルに従うかまでは分かりません。

サービス間の接続を検討するときは、対応する資格情報の形式と検証規則を具体的に確認する必要があります。

署名の確認と業務上の受入判断を分ける

v2.1では、VerificationとValidationの区別も導入部で説明されています。Verificationは、仕様への適合、暗号学的な保護、必要に応じたステータスなどを確認する処理です。Validationは、その発行者の主張を特定の用途で受け入れられるかという判断を扱います。検証者の役割

例えば学位を確認する採用手続きでは、署名を確かめたうえで、その発行者が当該学位を証明する主体として適切かを判断します。この例は業務上の受入方針を説明するためのものです。VCを導入する事業者は、信頼する発行元、資格情報の種類、利用目的などの条件を明確にしておく必要があります。

まとめ

v2.1は策定中であり、現行ドラフトから将来の確定版の互換性まで保証することはできません。実装者には、採用している仕様の版と実装上の前提を記録し、規定の明確化が自社の表示・検証・受入処理にどう関わるかを追うことが求められます。