検証可能なクレデンシャルの確信方法 v1.0

検証可能なクレデンシャルの提示時に確信を高める

W3C ワーキングドラフト

この文書の詳細情報
このバージョン:
https://www.w3.org/TR/2026/WD-vc-confidence-method-20260910/
最新の公開バージョン:
https://www.w3.org/TR/vc-confidence-method/
最新の編集者草案:
https://w3c.github.io/vc-confidence-method/
履歴:
https://www.w3.org/standards/history/vc-confidence-method/
コミット履歴
編集者:
Joe Andrieu (Legendary Requirements)
Denken Chen (台湾デジタル発展部)
フィードバック:
GitHub w3c/vc-confidence-method (プルリクエスト, 新しい Issue, 未解決の Issue)
関連文書
検証可能なクレデンシャル・データモデル v2.0

概要

この仕様は、 検証可能なクレデンシャル・データモデル v2.0 とともに使用でき、 検証者が、 検証可能なクレデンシャルの提示者が、 実際に、その利用に適切に関連付けられていることについて確信を高めるための仕組みを定義します。最も単純な 状況では、これは提示者がクレデンシャルの本来の正当な 受領者であることを意味します。この仕様は、 検証可能な クレデンシャル内で確信方法と証拠を表現するためのデータ モデルを定義し、その使用方法の例を 提供します。

この文書のステータス

このセクションでは、この文書の 公開時点でのステータスについて説明します。現在の W3C 公開文書の一覧およびこの技術報告書の最新版は、 W3C 標準および草案 インデックスで確認できます。

これは実験的な仕様であり、定期的に 改訂されています。 本番環境への導入には適していません。

この文書は、検証可能なクレデンシャル・ワーキング グループによって、 勧告 トラックを使用したワーキングドラフトとして公開されました。

ワーキングドラフトとしての公開は、 W3C およびそのメンバーによる承認を意味するものではありません。

これは草案文書であり、いつでも他の 文書によって更新、置換、または廃止される可能性があります。この文書を進行中の作業 以外のものとして引用することは不適切です。

この文書は、 W3C 特許 ポリシーの下で活動するグループによって作成されました。 W3C は、このグループの 成果物に関連して行われた 特許開示の公開一覧を管理しており、 そのページには特許を開示するための 手順も含まれています。個人が、 必須クレームを含むと考える 特許について実際に知っている場合、その情報を W3C 特許ポリシーの第6節に従って開示しなければなりません。

この文書は、 2025年8月18日付 W3C プロセス文書に準拠します。

1. はじめに

このセクションは規範的ではありません。

この仕様は、検証可能なクレデンシャルまたは検証可能な プレゼンテーション内、あるいはそれら自体のプロパティの値が正確であることについて、 検証者が確信を高めるために使用できる仕組みを定義します。

特に、現在の提示者が サブジェクト のうち特定の 検証可能なクレデンシャルの サブジェクトであると判断することは、 検証者にとって重要な 関心事です。

そのため、この仕様では、 発行者 が、特定の検証可能なクレデンシャルの提示が正当であることについて 検証者の確信を高めるために 利用できる、2つの拡張可能な仕組みを 定義します。

confidenceMethod プロパティにより、発行者は、 候補となる当事者が VC 内のサブジェクトの1人であることについての 確信を高めるための具体的な 手法を提供できます。たとえば、婚姻証明書の 提示者が、関係する当事者の1人、すなわち 司式者、配偶者の一方、または 証人の1人であることについて確信を高める場合です。

confidenceMethod プロパティを使用すると、 提示者が VC 内の当該サブジェクトであることを実証するために使用できる、 特定の生体情報、暗号鍵、またはその他の仕組みを 指定できます。検証者は、提示者に confidence method の使用を要求するか、あるいは、 たとえば提示者が、発行者が VC 内で クレームを行った対象と同一のエンティティであるかどうかについて 確信を高めるために別の仕組みを使用するかを 判断します。このような判断は、 特定のユースケースで VC を受け入れる際の 検証者の責任に影響を与える可能性があります。

assuranceLevel プロパティにより、発行者は、 最初の受領者にクレデンシャルを発行する前に 発行者が確立した保証の レベルを宣言できます。たとえば、 発行者は、特定の本人確認 プロセスを使用したことを宣言し、 [NIST-SP-800-63-4] で定義される IAL 3 のような 標準的な保証レベルを示すことができます。これにより、 検証者は、発行時点で 発行者が有していた保証レベルを理解し、 それらを受け入れるかどうかについて自身で 情報に基づいた判断を行うための材料とすることができます。

これらの仕組みはいずれも JSON-LD を使用して拡張でき、 新しい種類の confidence method または assurance level を定義できます。

たとえば、雇用主( 発行者)が 従業員( サブジェクト)に 社員証を発行する場合、発行 プロセス中に、従業員が特定の暗号 鍵(検証 メソッド)を 検証可能なクレデンシャルに バインドすることを要求する場合があります。その 場合、発行者は この仕様を使用して、 検証者に、 最初の本人保証プロセス中にどの暗号鍵が バインドされたかを伝えることができます。

言い換えると、発行者はこの仕様を使用して、 検証可能なクレデンシャル内の クレームをバインドするために使用した 証明可能な仕組みを伝えることができ、それにより 検証者は、 以下を含むさまざまな 事柄の真実性について確信を高めることができます。

1.1 用語

この文書全体で使用される一部の用語は、 検証可能なクレデンシャル・データモデル v2.0仕様の 用語 セクション、および 制御された識別子 v1.0仕様の 用語セクションで定義されています。このセクションでは、 この仕様全体で使用される追加の 用語を定義します。

保証レベル
特定のプロセスに従い、現実世界の証拠と観察に基づいて 個人のアイデンティティを確立するための 手法であり、通常は米国の NIST や EU の eIDAS のような国内および 国際標準化機関によって定義されます。

2. 適合性

非規範的と明示されたセクションに加え、この仕様に含まれるすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様のそれ以外のすべての部分は規範的です。

この文書におけるキーワード MAYMUSTREQUIRED、および SHOULD は、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されるものとしますが、それは、ここに示すように、 すべて大文字で記述されている場合に限ります。

適合 文書とは、 セクション 4. データモデルの関連する規範的要件に従う、 データモデルの具体的な表現です。

適合 プロセッサとは、 適合 文書を生成および/または使用する、 ソフトウェアおよび/または ハードウェアとして実現された任意のアルゴリズムです。適合 プロセッサは、非適合文書を使用した場合にエラーを生成しなければなりません

3. evidence プロパティとの関係

このセクションは規範的ではありません。

検証可能なクレデンシャル仕様では、 evidence プロパティを定義しています。

発行者は、検証可能なクレデンシャル内で検証者に 追加の補足情報を提供するために 証拠を含めることができます。 これは、検証者が検証可能なクレデンシャル内の クレームを信頼する際の確信度を 確立するために使用できます。たとえば、 発行者はクレデンシャルを発行する前に、 サブジェクトから提供された物理的な文書を確認したり、 一連の身元調査を 実施したりできます。 特定の状況では、この情報は、 特定のクレデンシャルを信頼することに伴うリスクを 判断する際に検証者にとって 有用です。

このプロパティはクレデンシャルのトップレベルで使用され、 実質的にクレデンシャル全体に対する 「補足情報」を提供することが想定されています。

仕様で提供されている例は、これをどのように 使用できるかを示しています。

1: スキル達成クレデンシャルを裏付ける証拠の例
{
  ...
  "evidence": [{
      // 外部でホストされる証拠ファイル/成果物への URL
      "id": "https://videos.example/training/alice-espresso.mp4",
      "type": ["Evidence"],
      "name": "ダブルエスプレッソ調製の実況説明動画",
      "description": "これは、Alice がダブルエスプレッソ飲料の調製を実演しながら説明する動画です。",
      // mp4 動画ファイルのダイジェストハッシュ
      "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
    }
  ]
}

この例には、次の注記が付されています。

注記: Evidence は セキュリティ保護の仕組みとは異なる目的を持つ

evidence プロパティは、 使用されるセキュリティ保護の仕組みとは 異なる情報を 提供します。evidence プロパティは、 検証可能なクレデンシャルに関連する、 文書による証拠などの補足情報を 表現するために使用されます。 これに対して、セキュリティ保護の 仕組みは、 発行者の真正性と 検証可能なクレデンシャルの完全性に関連する、 機械検証可能な数学的証明を 表現するために使用されます。 セキュリティ保護の仕組みに関する 詳細については、セクション #セキュリティ保護の仕組みを参照してください。

示されているように、evidence プロパティは、 例の mp4 動画ファイルのような証拠を提供することが想定されています。

この仕様では、不要な個人 情報を開示することなく、特定のサブジェクトについて 検証者の確信を高めるための仕組みを提供する、 さらに2つの手段を示します。追加の「証拠」を提供するのではなく、 confidenceMethod および assuranceLevel という追加プロパティは、 発行者によるそれぞれ異なる証明を提供します。

evidence トップレベルのプロパティであり、発行者またはホルダーとの さらなるやり取りを必要とせず、 検証者が独立して評価可能な証拠を提示します。 たとえば、発行者はサブジェクトが ある作業を実行するなど、特定の行動を 行っている動画を提供する場合があります。
confidenceMethod サブジェクトレベルのプロパティであり、 検証者が、 VC のサブジェクトが別の やり取りのサブジェクトでもあることについて確信を 高めるために利用できる仕組みを定義します。たとえば、 発行者は、 公開鍵などの検証 メソッドを提供し、それによって 検証者は使用証明プロトコルを適用して、 現在の利用者が、サブジェクトの制御下にあると 発行者が考えているものと同じ暗号上の秘密を使用して 暗号チャレンジに署名する能力を持つことを 確立できます。これは「制御の証明」と呼ばれることがあります。
assuranceLevel サブジェクトレベルのプロパティであり、 発行者が、 NIST-SP-800-63-4 や EIDAS2 などの公開標準に従って既知の保証レベルを 確立したことを証明できます。評価すべき証拠や適用すべき仕組みを 提供するのではなく、このプロパティは単に、クレデンシャルを発行する前に サブジェクトを識別するために発行者自身が用いたプロセスを記述します。

4. データモデル

この仕様では、 検証可能な クレデンシャル内の credentialSubject で confidence method 情報を 表現するための confidenceMethod プロパティを 定義します。

confidenceMethod

存在する場合、confidenceMethod プロパティの値は、 以下で定義する1つ以上の confidence method です。各 confidence method は、 confidence method の具体的な種類と、そのメソッドを評価するために 必要となる可能性のある参照データを指定します。このメソッドは、 検証可能な クレデンシャル内の サブジェクトに バインドされ、特定の候補 当事者が、その目的においてクレデンシャルで参照される エンティティと同じであるかどうかを 検証者が 評価するために十分な情報を提供します。検証者は confidence method を評価し、そのメソッドのプロセスを実行します。評価が 成功した場合、クレデンシャルが confidence method を満たしたことを示し、検証者はその 確信を安全に信頼してサービスを提供できます。

各 confidence method は、その type必ず指定し、 id を指定してもよいものとします。各 confidence method の 正確なプロパティと意味論は、 特定の confidenceMethod 型定義によって決定されます。

assuranceLevel
(リスクのある機能)課題 1

存在する場合、assuranceLevel プロパティの値は、 以下で定義する1つ以上の保証レベルです。各保証 メソッドは、保証レベルの具体的な種類と、 そのメソッドを評価するために必要となる可能性のある 参照データを指定します。このメソッドは、 検証可能な クレデンシャル内のサブジェクトに バインドされ、発行時点で発行者が サブジェクトについて有していた保証 レベルに関する情報を提供します。これは、 検証者が、 そのサブジェクトについて自身の保証レベルを どのような手段で確立したかを理解するのに役立ちます。異なる サブジェクトは異なる保証レベルを持つことができるため、 発行者は同じクレデンシャル内の異なる サブジェクトに異なる保証レベルを使用できます。たとえば、発行者は 婚姻証明書の司式者または配偶者である サブジェクトには高い保証レベルを使用し、その式の 証人にはより低い保証レベルを 使用できます。

各保証レベルは、その type必ず指定し、 id を指定してもよいものとします。各保証レベルの 正確なプロパティと意味論は、 特定の assuranceLevel 型定義によって決定されます。

検証者は、 confidence method の使用を要求せずに 検証可能なクレデンシャル内の クレームを受け入れることを決定したり、 あるいは、たとえば ホルダーが、 発行者が検証可能なクレデンシャル内で クレームを行った対象と同じ エンティティであるかどうかについて確信を 高めるため、別の仕組みを使用することができます。 このような 判断は、特定のユースケースで 検証可能な クレデンシャルを受け入れる際の 検証者の責任に影響を与える可能性があります。

検証者は、 confidence method 内の情報を使用して 証明検証可能なプレゼンテーションについて 検証することで、 ホルダーが confidence method を 制御している、またはそれを使用する能力を 指定されていることを検証できます。confidence method には 検証鍵を含めることができ、または confidence method の型によって、 検証鍵を credentialSubject.id などの 検証可能なクレデンシャル内の 他のプロパティから推論することを 定義できます。

次の例では、公開暗号鍵、 検証メソッド、 および分散型識別子文書を含む、 使用可能なさまざまな種類の confidence method を示します。

2: VerificationKeyConfirmation 型の confirmationMethod プロパティの使用例
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "confidenceMethod": [{
      "type": "BiometricImage",
      "biometricModality": "face",
      "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD"
    }, {
      "id": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652#key-abc",
      "type": "JsonWebKey",
      "controller": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
        "kty": "OKP",
        "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
      }
    }, {
      "id": "did:example:123#key-567",
      "type": "Multikey",
      "controller": "did:example:123",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }, {
      "id": "did:example:1234",
      "type": "DecentralizedIdentifierDocument"
    }],
    "degree": {
      "type": "BachelorDegree",
      "name": "理学・文学学士"
    }
  },
  "proof": { ... }
}
注記

confidence method は、 ホルダー検証可能なクレデンシャルサブジェクトであることについての 発行者の確信度、 オーセンティケーターの具体的なフォームファクターまたは 仕組み、および/または 他の検証可能なクレデンシャルや バージョン管理された 信頼フレームワークへの参照など、さまざまなメタデータを表現できます。 たとえば、発行者は、 暗号鍵ペアに基づく confidence method について クレームを行うことができますが、 その鍵を使用して署名を生成するには、 ホルダーが 多要素認証を使用してデバイスの ロックを解除する必要があります。

5. 確信方法

VerificationConfidence

VerificationConfidence は、DID 文書などの 制御された識別子文書内の検証 メソッドを使用する方法を指定します。

BiometricImage

BiometricImage は、 クレデンシャルのサブジェクトを認識するために、 検証可能なクレデンシャル内の画像を 使用する方法を指定します。

5.1 検証信頼度

TBD

5.2 生体画像

BiometricImage は、発行者主体の画像を 検証可能なクレデンシャルに埋め込めるようにし、 それによって 検証者は その画像をクレデンシャルを提示している人物と比較し、 提示者が、発行者主張を行った主体であるという信頼度を高めることができます。

生体画像信頼度方式は、次のプロパティによって定義されます:

type
REQUIRED。値は MUST BiometricImage でなければなりません。
biometricModality
REQUIRED。画像によって取得されたモダリティ。この仕様では このフィールドに対して face という1つの値を定義します。その他の値も MAY 使用できますが、さらなる標準化なしに相互運用できることは 保証されません。
image
REQUIREDbase64 エンコーディングを使用する data: URL [RFC2397] であり、その メディアタイプは image/jpegimage/png などの画像メディアタイプです。画像は、参照解除可能なURLで参照するのではなく、検証可能な クレデンシャルに埋め込まれていなければ MUST なりません。

検証者は、 BiometricImage を、 検証可能なクレデンシャルを検証し、 image の値をデコードして、デコードされた画像をクレデンシャルを 提示している人物と比較することによって評価します。

3: 生体画像信頼度方式の使用
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "confidenceMethod": {
      "type": "BiometricImage",
      "biometricModality": "face",
      "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": { ... }
}

5.3 暗号鍵

暗号鍵信頼度方式は、発行者が、 MultikeyJsonWebKey などの形式を使用して表現された 特定の暗号公開鍵を、主体検証可能なクレデンシャル内で結び付けられるようにします。 発行者は、 発行時および提示時(使用証明)に主体によって、または主体の代理として使用可能であると推定される公開鍵を記録します。 発行者は、発行前にその公開鍵に対応する秘密鍵の使用を検証する SHOULD です。 これにより、検証者には、 提示者が対応する秘密鍵を制御していることを確認するために使用できる暗号学的アンカーが提供されます。 この結び付けは発行者によって表明され、 クレデンシャルの保護メカニズムによって保護されるため、検証者は、 暗号鍵マテリアルが発行者が発行時に検証した内容を 反映していると信頼できます。

4: 検証可能なクレデンシャルで表現された暗号鍵信頼度方式
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "EmployeeCredential"],
  "issuer": "https://example.com/issuers/42",
  "validFrom": "2026-07-15T00:00:00Z",
  "credentialSubject": {
    "name": "Alice Doe",
    "confidenceMethod": [{
      // 公開鍵をインラインで表現する
      "type": "Multikey",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }, {
      // 公開鍵を参照によって表現する
      "id": "did:example:123456789#key-1",
      "type": "Multikey"
    }, {
      // 複数の公開鍵形式がサポートされる
      "type": "JsonWebKey",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
        "kty": "OKP",
        "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
      }
    }]
  },
  "proof": { ... }
}

検証可能な プレゼンテーションの間、検証者は、信頼度方式内の公開鍵を使用して 使用証明プロトコルを実行します。検証者は、 通常はセッションに結び付けられたnonceである暗号学的チャレンジを発行し、 保持者は、 信頼度方式に記録されている公開鍵に対応する秘密鍵を使用して チャレンジに署名します。検証者は、その後、 表明された公開鍵に対してその署名を検証します。検証に成功すると、 提示者が、発行者が発行時に 主体に結び付けた秘密鍵を制御していることが確立され、 提示者が検証可能なクレデンシャルの意図された主体であるという信頼度が高まります。

5.4 制御識別子

制御識別子信頼度方式は、発行者が、 特定の鍵を検証可能なクレデンシャルに直接埋め込むのではなく、 主体を、その主体が制御する 制御識別子 文書に結び付けられるようにします。 分散型識別子(DID)は、よく知られた 制御識別子の一種です。発行者は、発行時に検証された 主体の制御識別子を記録し、 検証者が 現在の制御識別子文書を取得して、提示時に主体の authentication 検証 関係に列挙されている検証方式を発見できるようにします。このアプローチは、主体の暗号マテリアルの鍵ローテーションや その他のライフサイクル変更に対応し、 発行者検証可能なクレデンシャルを再発行する必要はありません。 ただし、主体が 識別子そのものの制御を維持していることが条件です。

5: 検証可能なクレデンシャルで表現された制御識別子信頼度方式
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "MembershipCredential"],
  "issuer": "https://example.org/issuers/7",
  "validFrom": "2026-07-01T00:00:00Z",
  "credentialSubject": {
    "name": "Alex Utopian"
    "memberOf": {
      "name": "Utopia Libraries"
    },
    "confidenceMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  },
  "proof": { ... }
}

検証可能な プレゼンテーションの間、検証者は、信頼度方式内の制御 識別子を解決して、現在の制御識別子 文書を取得します。検証者は、 その文書の authentication 検証 関係に列挙されている検証 方式を抽出し、次に暗号学的チャレンジを発行して、 保持者にそれらのauthentication 検証方式の1つを使用して証明を生成するよう要求します。保持者が 認可された鍵でチャレンジへの署名に成功した場合、検証者は、 提示者が、発行者が発行時に主体と関連付けた 識別子を制御しているという信頼度を得ます。 制御識別子文書は主体によって維持されるため、この プロトコルは鍵ローテーションに透過的に対応します。保持者は、 発行者から新しい クレデンシャルを取得する必要なく、現在認可されている任意のauthentication鍵を使用して提示できます。

5.5 生体画像信頼度

TBD

5.6 生体ベクトル 信頼度方式

(リスクのある機能) 課題 2: 生体ベクトル信頼度方式は不安定です
生体ベクトル信頼度方式は不安定であり、タスクフォースによって引き続き 改良されています。現在、次の懸念事項について積極的に 作業が進められています:
  1. 仕様は生体照合 プロバイダーに依存しないものとし、特定のプロプライエタリまたはオープンな アプローチや種類を優遇しないようにする必要があります。
  2. モデルデータとベクトルデータは互いに関連しているため、 組み合わせることが考えられます。モデルとベクトル情報を分離することは あまり意味がありません。base64url でエンコードされたCBORは、この情報を保持するための より良いアプローチである可能性があります。
  3. 仕様に存在する必要がある、オープンな照合モデルを使用した例を どのように規定すべきでしょうか?
  4. クレデンシャルの発行時に、発行者が異なる プロバイダーから複数のベクトルを提供できることを明確にします。
  5. 生体照合のための標準化されたZKPはまだありませんが、 グループはそれが理想的な最終状態であると考えています。
  6. 発行者が生体照合モデルにサービスURLを含めることは、 最良の設計ではない可能性があり、改良が必要です。保持者と検証者の間、 および保持者と発行者の間で、ネゴシエーションをどのように 実行するかを明らかにするために、さらなる作業が必要です。
  7. この情報はどこに公開すべきでしょうか? これを DID Documentに含めるのは安全でしょうか?
  8. 仕様で「理想状態」のユースケースを説明します。
  9. 保持者は「適切な」生体認証プロバイダーをどのように見つけるのでしょうか? 保持者に多くを求めすぎていないでしょうか? それはセキュリティ/プライバシー上のリスクでしょうか? 保持者にどの程度の作業を求めているのでしょうか?
  10. ローカル デバイスチェックでは、アプリケーションの完全性チェックを実行する必要がありますか?
  11. モデルにnonceを追加する必要があります。

BiometricVectorConfidenceMethod は、発行者が生体 ベクトル検証可能なクレデンシャルに埋め込めるようにし、 それによって 検証者は、 提示者が、発行者主張を行ったのと同じ 個人であるという信頼度を高めることができます。 生の生体データ(例: 写真、音声 録音)とは異なり、生体ベクトルは、照合モデルによって生成されるコンパクトな数学的 表現です。異なる モデルのベクトルには互換性がありません。

5.6.1 ユースケース

販売時点での年齢確認。 消費者が 年齢制限のある商品を購入する場合、現在は店員が 消費者の物理的な身分証明書を扱うため、氏名、住所、生年月日が すべて明らかになり、個人情報の盗難や身体的安全に関するリスクが生じます。 生体ベクトル信頼度方式では、消費者のデバイスが 生体照合を実行し、署名された検証結果のみを POSシステムに送信します。店員は消費者の個人 情報を見ることがなく、文書が真正であるかを判断する必要もありません。

アカウント復旧。 ユーザーがパスワードを忘れたりデバイスを紛失したりして アカウントへのアクセスを失った場合、サービス プロバイダーは通常、安全性の低い知識ベース認証 または手動のサポートプロセスに依存します。生体ベクトル信頼度方式は、 新たに取得した生体情報を登録時に登録されたベクトルと比較することで 自動復旧を可能にします。これは、セキュリティ 質問より強力で、カスタマーサポートより高速であり、写真を保存する必要もありません。

モバイルクレデンシャルの提示者制限。 モバイル運転免許証などのデジタル クレデンシャルは、提示者が正当かつ意図された提示者であるかを検証する仕組みがなければ、 認可されていない第三者に転送される可能性があります。生体ベクトル信頼度 方式は提示者の暗号学的検証を提供します。クレデンシャルには 登録済みベクトルが含まれ、提示者は提示時に新たな生体照合を行うことによって 認可された所有を証明します。

リモートオンボーディングと本人確認。 組織が人物の身元をリモートで検証する必要がある場合(例: 雇用、金融サービス、政府給付)、生体 ベクトル信頼度方式は、対面での立ち会いを必要とせずに、検証済みの身元を クレデンシャルに結び付けることができます。生体 照合によって、リモートで自分自身を提示している人物が、発行時に身元を証明した 人物と同一であることを確認し、プライバシーを 保護しながら不正を低減します。

生体ベクトル信頼度方式は、次のプロパティを指定しなければ MUST なりません:

id
この信頼度方式インスタンスの一意な識別子。人物が 異なるコンテキスト用に複数の生体登録を維持できるようにします。
type
値は BiometricVectorConfidenceMethod でなければ MUST なりません。
biometricModality
生体モダリティ。期待される値には facevoicefingerprintpalmprintiris、および retina が含まれます。
captureFormat
取得形式。期待される値には videostatic-imageimage-sequence、および audio が含まれます。
biometricModel
照合モデルを識別するオブジェクトで、type プロパティ (BiometricMatchingModel でなければ MUST なりません)と matchingModel プロパティ (ベンダーおよびモデル識別子、例: example-biometric-2026-v3.2)を含みます。
biometricVectors
Multibaseエンコードされた(base64url-nopad)生体ベクトル。形式は、 それを生成した照合モデルに固有です。発行者は、MAY 異なるプロバイダーから複数のベクトルを含めて、 保持者が 検証サービスを選択する際の柔軟性を高めることができます。

生体ベクトル信頼度方式は、次も指定して MAY かまいません:

service
サーバー支援型検証のためのサービスエンドポイントで、 [[DID-CORE] ][DID-CORE] のサービス定義構造に従い、 idtypeBiometricVerificationService)、および serviceEndpoint プロパティを含みます。

2つの実装シナリオがサポートされています。クライアント側ローカル処理と ユーザー選択プロバイダーです。どちらの場合も、新たな生体サンプルが 取得され、登録済みベクトルと比較されます。結果は BiometricVerificationCredential として表現されます。

5.6.2 クライアント側検証

このシナリオでは、生体検証は完全に 保持者の デバイス上で行われます。生体データがデバイスの外に出ることはなく、 ゼロ知識証明が照合を証明します。

次の例は、クライアント側検証のための生体ベクトル 信頼度方式を含むクレデンシャルを示しています:

6: クライアント側生体ベクトル信頼度 方式
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2026-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "confidenceMethod": {
      "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
      "type": "BiometricVectorConfidenceMethod",
      "biometricModality": "face",
      "captureFormat": "video",
      "biometricModel": {
        "type": "BiometricMatchingModel",
        "matchingModel": "example-biometric-2026-v3.2"
      },
      "biometricVectors": "uAVvLMv6gm...MNam"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science"
    }
  }
}

保持者の デバイスは、新たな生体サンプルを取得し、登録済みの biometricVectors と ローカルで比較して、照合を表明する BiometricVerificationCredential を生成します。検証出力内の credentialSubject.id は、上記クレデンシャルの信頼度方式 id を参照し、検証結果を特定の生体登録に結び付けていることに 注意してください:

7: クライアント側生体 照合の検証出力
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "BiometricVerificationCredential"],
  "issuer": "did:example:holder-device",
  "validFrom": "2026-05-15T14:30:00Z",
  "validUntil": "2026-05-15T14:45:00Z",
  "credentialSubject": {
    "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
    "biometricMatch": {
      "type": "BiometricMatch",
      "matchingMethod": "client-side-zkp",
      "matchDate": "2026-05-15T14:30:00Z",
      "matchResult": "verified",
      "confidence": "0.96"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "example-biometric-zkp-2028",
    "created": "2026-05-15T14:30:05Z",
    "challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
    "verificationMethod": "did:example:holder-device#key-1",
    "proofPurpose": "authentication",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
  }
}
(リスクのある機能) 課題 3

example-biometric-zkp-2028 暗号スイートは、この文書の 執筆時点では存在しません。これは、将来の ゼロ知識証明暗号スイートをクライアント側 生体検証にどのように使用できるかを示すために含まれています。この分野では活発な研究が行われています。

5.6.3 ユーザー選択プロバイダー

このシナリオでは、保持者が、信頼できる 生体 検証サービスを選択します。ウォレットは利用可能な選択肢を提示し、 生体データが送信される前に保持者が 同意します。保持者の 生体データは、検証者ではなく、 選択したプロバイダーにのみ送信されます。

次の例は、サービスエンドポイントを含む生体ベクトル 信頼度方式を持つクレデンシャルを示しています:

8: ユーザー選択プロバイダー生体ベクトル 信頼度方式
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2026-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "confidenceMethod": {
      "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
      "type": "BiometricVectorConfidenceMethod",
      "biometricModality": "face",
      "captureFormat": "video",
      "biometricModel": {
        "type": "BiometricMatchingModel",
        "matchingModel": "example-biometric-2026-v3.2"
      },
      "service": {
        "id": "urn:uuid:service-1",
        "type": "BiometricVerificationService",
        "serviceEndpoint": "https://biometric-provider.example/verify/v3"
      },
      "biometricVectors": "uAVvLMv6gm...MNam"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science"
    }
  }
}

検証フローにより、生体認証プロバイダーと 検証者は、 互いについて知る必要がありません:

  1. 検証者は、 保持者に 生体検証を要求し、受け入れ可能な生体認証プロバイダーとチャレンジ nonceを指定します。
  2. ウォレットは、受け入れ可能なプロバイダーを保持者に提示し、 保持者は希望するプロバイダーを選択して 検証に同意します。
  3. ウォレットは、biometricVectors、新たな生体 取得データ、およびチャレンジnonceを、選択したプロバイダーの serviceEndpoint に送信します。
  4. プロバイダーは、新たな取得データを登録済み ベクトルと比較し、チャレンジnonceを埋め込んだ署名済み BiometricVerificationCredential を発行します。
  5. ウォレットは、BiometricVerificationCredential検証者に提示し、検証者は 証明を検証し、埋め込まれた チャレンジが元の要求と一致することを確認します。

チャレンジnonceはリプレイ攻撃を防止し、検証が 検証者の特定の要求に応答して実行されたことを証明します。 クライアント側シナリオと同様に、検証出力内の credentialSubject.id は、 上記クレデンシャルの信頼度方式 id を 参照します:

9: ユーザー選択プロバイダーによる 生体照合の検証出力
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "BiometricVerificationCredential"],
  "issuer": "did:web:biometric-provider.example",
  "validFrom": "2026-05-15T14:30:00Z",
  "validUntil": "2026-05-15T14:45:00Z",
  "credentialSubject": {
    "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
    "biometricMatch": {
      "type": "BiometricMatch",
      "matchingMethod": "server-assisted-video-stream",
      "matchDate": "2026-05-15T14:30:00Z",
      "domain": "https://verifier.example/",
      "matchResult": "verified",
      "confidence": "0.94"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2026-05-15T14:30:05Z",
    "challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
    "verificationMethod": "did:web:biometric-provider.example#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
  }
}

6. 保証レベル

NIST_800-63-4_LOA

NIST_800-63-4 は、 [NIST-SP-800-63-4] 仕様に基づく保証レベルを定義します。

EIDAS_LOA

EIDAS_LOA は、 [EIDAS2] に基づく保証レベルを定義します。

6.1 NIST_800-63-4_LOA

未定

6.2 EIDAS_LOA

未定

7. セキュリティに関する考慮事項

課題 4: セキュリティに関する 考慮事項セクションを追加する
少なくとも次のトピックを含むセキュリティに関する考慮事項セクションを 追加します。
  • confidence method は選択的に開示できるため、 選択的またはリンク不能な開示を可能にする証明の 仕組みを扱う高保証のユースケースでは、 検証者が confidence method を明示的に 要求する必要があります。

8. プライバシーに関する考慮事項

課題 5: プライバシーに関する 考慮事項セクションを追加する
少なくとも次のトピックを含むプライバシーに関する考慮事項セクションを 追加します。
  • confidence method は選択的に開示されることが想定されています。 多くの低保証ユースケースでは必要ない場合や、 写真との対面照合などの 別の手段によって高い保証が 達成される場合があるためです。
  • confidence method がリンク不能な形で開示されても、 公開暗号鍵 識別子など、相関可能な識別子を 明らかにする可能性があります。
  • 絶対に必要な場合を除き、confidence method に 生体情報を使用しないことを強く推奨します。検証者は生体写真を 最後の手段としてのみ要求すべきであり、取引の 完了後にその情報を破棄すべきであることを警告します。

A. 参考文献

A.1 規範的参考文献

[CID]
制御された識別子 v1.0. Michael Jones; Manu Sporny. W3C. 2025年5月15日. W3C 勧告. URL: https://www.w3.org/TR/cid-1.0/
[DID-CORE]
分散型識別子(DID)v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 2022年7月19日. W3C 勧告. URL: https://www.w3.org/TR/did-core/
[EIDAS2]
欧州デジタルアイデンティティ・フレームワークの 確立に関して規則(EU)No 910/2014を改正する、 2024年4月11日付欧州議会および理事会規則(EU)2024/1183. 欧州 議会; 欧州連合理事会. 欧州連合官報. 2024年4月30日. URL: http://data.europa.eu/eli/reg/2024/1183/oj
[NIST-SP-800-63-4]
デジタルアイデンティティ・ ガイドライン. David Temoshok; Yee-Yin Choong; Ryan Galluzzo; Connie LaSalle; Andrew Regenscheid; Diana Proud-Madruga; Sarbari Gupta; Naomi Lefkovitz. 米国国立標準技術 研究所. 2025年8月. URL: https://pages.nist.gov/800-63-4/sp800-63.html
[RFC2119]
要件レベルを示すために RFC で使用する キーワード. S. Bradner. IETF. 1997年3月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC2397]
「data」URL スキーム. L. Masinter. IETF. 1998年8月. 提案標準. URL: https://www.rfc-editor.org/info/rfc2397/
[RFC8174]
RFC 2119 のキーワードにおける大文字と小文字の曖昧性. B. Leiba. IETF. 2017年5月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc8174/
[VC-DATA-INTEGRITY]
検証可能なクレデンシャルのデータ完全性 1.0. Ivan Herman; Manu Sporny; Ted Thibodeau Jr; Dave Longley; Greg Bernstein. W3C. 2025年5月15日. W3C勧告. URL: https://www.w3.org/TR/vc-data-integrity/
[VC-DATA-MODEL-2.0]
検証可能なクレデンシャル・データモデル v2.0. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 2025年5月15日. W3C 勧告. URL: https://www.w3.org/TR/vc-data-model-2.0/