Identity Deep Dive

openid/dchp

元ファイル (GitHub)

一言で言うと: OpenID Foundation の Digital Credentials Harmonized Presentation (DCHP) Working Group が ISO/IEC JTC 1/SC 17 WG 10 と共同で書いている、CBOR でエンコードする credential の要求・応答プロトコルである。ISO/IEC 18013-5 と OpenID for Verifiable Presentations を一本化し、ISO mdoc と SD-JWT VC を対面でもオンラインでも提示できるようにするのが狙い。

概要

  • リポジトリにある仕様は draft/digital-credentials-harmonized-presentation.md の 1 本だけで、main が更新されるたびに Editor's Copy として公開される。README は、この版は「承認された Working Group Draft ではない」と明記している。このページは main のコミット 4ddd238 (2026 年 11 月 9 日) を読んでおり、その Document History は「-00」である。
  • Foreword によれば、本文は ISO/IEC JTC 1/SC 17 WG 10 のメンバーと OpenID Foundation の Digital Credentials Protocols (DCP) Working Group のメンバーが共同で作っている。出発点は初期提案 (pull request #29、2026 年 8 月 16 日マージ) である。中核の各節 (Credential Request、Response Encryption、Reader Authentication、Transaction Transcript、Credential Response) の冒頭には「まだワーキンググループの合意がない」という注記があり、issue #24 から #28 で追跡されている。
  • メッセージはすべて小さな整数をキーとする CBOR map で、CDDL で定義されている。credential_types のようなフィールド名は本文と CDDL の上のラベルで、ワイヤーには載らない。2026 年 11 月 5 日、ワーキンググループは大文字小文字を直す pull request #83 を「map のキーは整数なので」編集上の変更と判断し、このことを確認している。
  • verifier は CredentialRequest を送る。欲しい credential を CredentialQueries で指定し、それを AND/OR の組み合わせを持つ ScenarioSets にまとめる。wallet は CredentialResponse を返す。中身は平文の envelope、暗号化された envelope、またはその両方である。
  • 中核部分は credential 形式に依存しない。pull request #57 (2026 年 11 月 9 日マージ) 以降、形式に固有の事項はすべて「credential format definition」に置かれる。文書には附属書として ISO mdoc (mso_mdoc) と SD-JWT VC (dc+sd-jwt) の 2 つがある。
  • Scope、用語、略語、value matching、transaction data、SD-JWT VC の path、mdoc の SessionTranscript に transcript をどう入れるかは、まだ「To be completed」である。

仕組み

図
sequenceDiagram
    participant V as Verifier (reader)
    participant W as Wallet
    V->>W: CredentialRequest: payload (RequestPayload) と任意の reader_auth (COSE_Sign)
    W->>W: reader_auth があれば RequestPayload と ReaderTransactionTranscript に対して検証
    W->>W: ScenarioSets と CredentialQueries を満たす credential を選ぶ
    W->>W: 各 credential を WalletTransactionTranscript に束縛
    W-->>V: CredentialResponse: 平文の Envelope と HPKE で暗号化した Envelope (どちらか、または両方)
  1. verifier は RequestPayload を作る。中身は ScenarioSets (キー 1)、CredentialQueries (キー 2)、encryption_context (キー 3。ISO/IEC 18013-5 のセッション暗号を使うときは省く)、任意の additional_encryption_contexts (キー 4) である。CredentialRequest は、CBOR エンコードした payload をバイト列として payload (キー 1) に入れ、任意で reader_auth (キー 2) を付ける。reader_auth は COSE_Sign で、detached payload は RequestPayload のバイト列と transaction transcript である (Credential Request 節、Reader Authentication 節)。
  2. 双方が transaction transcript を組み立てる。決定的エンコーディング (RFC 8949 Section 4.2) の CBOR map で、RequestPayload バイト列の SHA-256 と ChannelBinding を持つ。ChannelBinding は、セッションがどう始まったか (QR、NFC、OpenID4VP の request_uri か client_id、Digital Credentials API の origin) と、どの伝送路を使っているかを記録する (Transaction Transcript 節)。
  3. wallet が credential を選ぶ。各 CredentialQuery には credential_format、受け付ける credential_types の配列、データ要素の辞書、連言標準形 (AND の OR の AND) の requested_elements がある。ScenarioSet は combinations を並べ、wallet はそのうち 1 つの組み合わせに含まれる credential をすべて提示する。
  4. 提示する各 credential は WalletTransactionTranscript に束縛される。これは reader 側の transcript に、そのクエリの encryption_ref を加えたものである。mdoc では、署名または MAC して DeviceAuth を作る SessionTranscript の中に埋め込む。SD-JWT VC では、その SHA-256 を KB-JWT の nonce に使う (各形式の附属書)。
  5. セッション層の暗号がない場合 (本文は Digital Credentials API とスキームによる起動を挙げる)、応答の暗号化は必須で、量子耐性でない用途には HPKE を使う。encrypted の各要素は COSE_Encrypt で、復号すると Envelope になる。encryption_ref を使えばクエリごとに別の鍵を指定できる (Response Encryption 節)。
  6. Envelope は、要求と同じ整数 CredentialRef をキーにした credentials プールと、満たした ScenarioRef ごとにそれを満たす CredentialRef を並べた scenarios map を持つ (Credential Response 節)。

ユースケース

  • ISO/IEC 18013-5 の近接提示と OpenID4VP のオンライン提示の両方に対応している wallet が、要求・応答のモデルを 1 つにまとめたい場合。transcript の ChannelBinding には、18013-5 の QR と NFC による engagement、BLE と NFC の伝送路、OpenID4VP、Digital Credentials API のフィールドがそろっている。
  • 年齢確認のような同じ目的に対して mDL と SD-JWT VC のどちらでも受け付ける verifier。1 つの ScenarioSet に 2 つの組み合わせを書けば表せる。
  • 「姓、かつ (18 歳以上 または 生年月日)」を 1 つのクエリで要求する verifier。requested_elements の論理木で書ける。
  • 1 つの応答の中で、身分証明の credential はあるバックエンドへ、決済の credential は別のバックエンドへ送る構成。encryption_ref と additional_encryption_contexts を使う (本文の「Multi-Key Routing」の例)。
  • 特定の発行者だけを信頼し、その鍵識別子を issuer_identifiers.x509_ref に並べる verifier。wallet は、mdoc の x5chain または SD-JWT の x5c ヘッダーにある証明書の Authority Key Identifier と突き合わせる。

なぜ今重要か

  • Trigger: radar の注記は「4 日間で 23 コミット、フィールド名の変更と credential_types の配列化を含む」だった。main で見ると、rebase マージされた 2 つの pull request で計 31 コミットが入っている。#61 (8 コミット、2026 年 11 月 4 日) が credential_type を配列にし、#57 (23 コミット、2026 年 11 月 9 日) が形式固有の事項を附属書に移した。23 コミットは #57 だけのもので、書かれたのは 9 月 7 日から 10 月 22 日にかけてである。
  • Source evidence: pull request #57 の説明とコミット (ce98c33 から 4ddd238)、pull request #61 (head は f669188、issue #46 を close)。issue #72 は「Digital Credentials Harmonized Presentation 1.0 - Draft 00」の公開を提案しているが、2026 年 11 月 4 日の issue へのコメントは、pull request がもっと入ってから「1〜2 か月ほど」後に再検討するとしている。公開に必要な Security Considerations のプレースホルダーと Notices 附属書は、未マージの pull request #85 が追加する。
  • Expected impact: Editor's Copy から実装している人は、フィールド単位の変更を追い続ける必要がある。未マージの pull request #77 は応答の credentials プールを map から配列に変え、#76 は ChannelBinding のキー番号を振り直す。中核の節にはまだ合意がなく、ワイヤー形式は安定していない。

変更点

  • Spec/document change summary:
    • pull request #61: credential_type (キー 2、tstr) が credential_types (キー 2、[ + tstr ]) になった。n 個の type を持つクエリは n 個のクエリとして処理し、それを参照する組み合わせも同じように展開する。issue #46 はこれを、近い関係にある type (同じ type の新しい版など) 向けの「主にサイズの最適化」と説明している。
    • pull request #57: 新しい「Credential Formats」節が、credential format definition が定めるべき 10 項目を挙げる。format_extensions と CredentialItem.data は CDDL の socket ($formatExtensions、$CredentialData) になり、定義のなかった ZkDocument と zkFormatExtensions は消えた。CredentialItem.format は credential_format に改名された。pull request は「map のキーは変わらないのでエンコーディングは変わらない」と書いている。SD-JWT VC の形式識別子は vc+sd-jwt から dc+sd-jwt に変わった。ISO/IEC 18013-5、RFC 5280、RFC 7515、RFC 9901、draft-ietf-oauth-sd-jwt-vc が規範的参照になった。
    • pull request #57 で入った新しい規則: credential_types の照合は大文字小文字を区別する。mdoc の要素を issuer-signed にするか device-signed にするかは、MSO の KeyAuthorizations の範囲内で wallet が決める。要素の定義が認める場合 (age_over_NN) は、wallet は代わりの要素を返してよい。発行者識別子は Authority Key Identifier の keyIdentifier と照合する。鍵に束縛されていない mdoc と、KB-JWT のない SD-JWT VC を返してよいのは、support_no_cryptographic_binding が true のときだけである。
  • Compatibility or migration concerns:
    • ワイヤーに現れる変更は 2 つある。CredentialQuery のキー 2 の型が文字列から配列に変わったことと、SD-JWT VC の credential_format の値が vc+sd-jwt から dc+sd-jwt に変わったことである。format から credential_format への改名や、#83 のような大文字小文字の修正は名前が変わるだけである。
    • 未マージの pull request #81 は、reader_auth を verifier_auth に、ReaderTransactionTranscript を VerifierTransactionTranscript に改名する。これも名前だけの変更である。

技術分析

  • Threat model implications: リプレイ対策の中心は transcript である。要求のハッシュと、engagement または起動のチャネルを、reader の署名、応答の暗号化、credential 自体の束縛のすべてに入れることで、「あるセッションのメッセージを別のセッションで再利用できない」ようにしている。Security Considerations 節はまだ存在しない (未マージの pull request #85 が「To be completed」として追加する)。Reader Authentication 節は、reader の鍵をどう伝えるかをまだ定めていない。未マージの pull request #65 は、COSE_Signature の protected header に X.509 の x5chain (RFC 9360) を入れることを求める。support_no_cryptographic_binding を使えば、verifier は holder binding のない credential を受け入れられる。両附属書とも、束縛なしの場合をこのフラグに結び付けている。
  • Protocol flow implications: 応答の暗号化が必須になるのはセッション層の暗号がない場合だけなので、同じメッセージ形式が 18013-5 の BLE/NFC セッションでも Digital Credentials API でも動く。mdoc で WalletTransactionTranscript から SessionTranscript を導く方法は「to be completed」である (issue #10)。KB-JWT の nonce の文字列エンコーディングと aud の値も同じく未定なので、どちらの形式の束縛もまだ最後まで実装できない。
  • Interop concerns:
    • main では本文と CDDL で整数キーが食い違っている。ChannelBinding の engagement フィールドは本文の表では 8 個で、oidc4vp_request_uri が 6、oidc4vp_client_id が 7、dc_api_origin が 8 である。CDDL では 7 個で、この 3 つが 5、6、7 になっている。伝送路フィールドも違い、本文は ble_gatt と整数の ble_l2cap、CDDL は ble_uuid、map 値の ble_l2cap、キー 12〜15 を持つ。issue #75 がこれらを挙げ、未マージの pull request #76 が修正する。#76 は CDDL を本文の番号に合わせ (キー 5 に cce_handover を追加)、oidc4vp_* を openid4vp_* に、nfcv2 を cce に改名する。
    • 応答の暗号化に使う transcript について、本文の記述が割れている。transcript の説明の箇条書きと CDDL のコメントは ReaderTransactionTranscript を応答の暗号化に使うとし、「Use in Protocol Operations」の表は WalletTransactionTranscript を HPKE の info パラメータとしている。
    • 未マージの pull request #77 は、credentials map を CredentialItem の配列に置き換え、各要素に新しい query_refs フィールド (キー 3) を足し、CredentialRef を QueryRef に改名する。これで 1 つの credential を重複させずに複数のクエリへの回答にでき、allow_multiple が立っていれば 1 つのクエリに複数の credential を返せる。
    • 本文は決定的 CBOR を「このプロトコル全体で」必須としているが、RFC 8949 Section 4.2 に軽く触れているだけである。未マージの pull request #64 は専用の節を追加する。RFC 8949 Section 4.2.1 の core deterministic encoding を使い、NaN と無限大を禁じ、transcript は送信されないので双方がそれぞれエンコードする、と注記する。

未解決の問い

  • 文書をどう公開するか。issue #13 によれば、ISO/IEC の成果物は Publicly Available Specification (PAS) か、Partner Standards Development Organization (PSDO) の枠組みで出る。ソースファイルには、Internet-Draft のヘッダーはツールのための足場で、IETF 文書であるという主張ではない、という注記がある。OpenID の WG Draft -00 (issue #72) は 2026 年 11 月 4 日に先送りされた。
  • ISO/IEC 18013-5 第 2 版との関係は、編集者注 2 か所からしか読み取れない。issuer_identifiers は「第 2 版で定義中の IssuerIdentifiers 構造と同じ規則」であり、鍵に束縛されていない mdoc の記述は「DIS 投票向けに提案された変更に従う」(issue #56)。18013-5 の改訂について、リポジトリはこれ以上何も述べていない。
  • SD-JWT VC の path。issue #52 は、[ + tstr ] では配列の要素を指せないと指摘している。2026 年 11 月 5 日、ワーキンググループは [ + tstr / int / null / bool / bstr ] への拡張に「異論なし」とし、11 月 9 日には pull request を書くという申し出があった。2026 年 11 月 11 日時点で該当する pull request は出ていない。
  • vct のクエリが継承した type にも一致するか (issue #53)、X.509 を使わない SD-JWT VC 発行者をどう要求するか、両形式の value matching (issue #9) と transaction data (issue #4)。
  • 未マージの pull request #64、#65、#74、#76、#77、#81、#83、#85 のどれが、どういう形で入るか。

実験

  • Lab 1: main の要求 CDDL を取り出し、2 つのシナリオ (年齢確認のために mdoc または SD-JWT VC) を持つ要求を CDDL ツールで検証する。次に同じ要求を本文の表に従ってエンコードし、整数キーが食い違う箇所をすべて洗い出す (ChannelBinding で食い違うはず)。
  • Lab 2: Digital Credentials API のセッションについて ReaderTransactionTranscript を 2 つの CBOR ライブラリで決定的エンコーディングを有効にして作り、バイト列と SHA-256 が一致するか確かめる。
  • Lab 3: pull request #77 の head と main からそれぞれ Editor's Copy を作り直し、2 つのクエリを満たす credential を 1 つ含む応答を両方の定義でエンコードして、ワイヤー上で何が変わるかを見る。

参考資料

背景

きっかけ

  • radar が検出したイベント: 「4 日間で 23 コミット、フィールド名の変更と credential_types の配列化を含む」(トラック openid)。main で見ると、rebase マージされた 2 つの pull request である。#61 は 2026 年 11 月 4 日に 8 コミットを入れ、credential_type を配列にした。#57 は 2026 年 11 月 9 日に 23 コミットを入れ、形式固有の事項を形式別の附属書に移し、CredentialItem.format を credential_format に改名した。
  • 関連するリポジトリ / PR / Issue: https://github.com/openid/dchp、pull request #57 と #61、issue #46。

なぜ重要か

このリポジトリは、OpenID Foundation の Digital Credentials Harmonized Presentation Working Group の作業場所である。仕様の Foreword によれば、本文は ISO/IEC JTC 1/SC 17 WG 10 のメンバーと OpenID Foundation の DCP Working Group のメンバーが共同で作っている。定めているのは、transcript によるチャネル束縛を備えた CBOR の要求・応答モデル 1 つである。ISO/IEC 18013-5 の近接セッション、OpenID4VP、Digital Credentials API のいずれの上でも、ISO mdoc と SD-JWT VC の両方に使えることを目指している。本文は Editor's Copy で、中核の節にはワーキンググループの合意がない。未マージの pull request のいくつか (#76、#77、#81) は整数キー、構造、名前を変える。今実装するなら、どのコミットに従うかを固定する必要がある。

未解決の問い

  • WG Draft より前に、本文と CDDL はそろうのか。現状は ChannelBinding のキーと purpose_id (本文は controller_id、CDDL は controlled_id) で食い違っている。未マージの pull request #76 がこれを直す。
  • mdoc の SessionTranscript に transcript をどう入れるのか。KB-JWT の nonce と aud はどうエンコードするのか (issue #10)。
  • 最初の Working Group Draft はいつ出るのか (issue #72。2026 年 11 月 4 日に 1〜2 か月ほど先送り)。ISO/IEC 側はどの経路で出すのか (issue #13: PAS か PSDO)。

仕様メモ

参照

4ddd238 時点の draft/digital-credentials-harmonized-presentation.md にある規範的参照 (一覧の最後は「To be completed」):

  • ISO/IEC 18013-5、Mobile driving licence (mDL) application。
  • RFC 5280 (X.509 証明書と CRL のプロファイル)。発行者照合で使う Authority Key Identifier のため。
  • RFC 7515 (JWS)。SD-JWT VC の Issuer-signed JWT の x5c ヘッダーのため。
  • RFC 9901 (SD-JWT) と draft-ietf-oauth-sd-jwt-vc (SD-JWT VC)。

これらはすべて pull request #57 で追加された (RFC 7515 はコミット 13ca44e)。本文はこの一覧の外でも、RFC 8610 (CDDL、socket を含む)、RFC 9052 (COSE_Sign、COSE_Key、COSE_Encrypt)、RFC 9360 (COSE_X509)、RFC 8949 Section 4.2 (決定的 CBOR)、RFC 8943 (full-date)、draft-ietf-cose-hpke、ISO/IEC TS 23220-2 (age_over_NN) を引いている。「shall/should/may/can」の使い方は ISO/IEC Directives, Part 2 に従う。

README は ISO/IEC 18013-5 (https://www.iso.org/standard/69084.html)、OpenID for Verifiable Presentations 1.0 (https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)、Editor's Copy (https://openid.github.io/dchp/digital-credentials-harmonized-presentation-editors-copy.html) にリンクしている。

主な変更

マージ済み:

  • #61 (2026 年 11 月 4 日、8 コミット、issue #46 を close): credential_type: tstr が credential_types: [ + tstr ] (キー 2) になった。配列に n 個の値があるときの要求の処理方法も定めている。
  • #57 (2026 年 11 月 9 日、23 コミット、issue #21、#22、#36 を close): 「Credential Formats」節と、format definition に課す 10 項目の要件。ISO mdoc と SD-JWT VC の附属書。$formatExtensions と $CredentialData の socket。CredentialItem.format から credential_format への改名 (map のキーは同じ)。vc+sd-jwt から dc+sd-jwt への変更。新しい規範的参照。個々のコミットでは、SD-JWT VC の path の意味論を issue #52 に回し (c029b57)、authority key identifier に RFC 5280 の名前を使い (4fae852)、support_no_cryptographic_binding から DocRequestInfo への対応付けを削除した (dfd7dd4)。
  • #29 (2026 年 8 月 16 日): 初期提案。出発点として受け入れられたが、「内容全体についての合意ではまだない」。#7、#11、#15 はリポジトリとビルドの整備である。

未マージ (2026 年 11 月 11 日時点、各 diff の中身):

  • #64: 「CBOR Encoding」節を追加する。RFC 8949 Section 4.2.1 の core deterministic encoding を必須にし、NaN と無限大を禁じ、transcript は送信されないと明記する。
  • #65: reader authentication に X.509 を使う場合、証明書は COSE_Signature の protected header の x5chain (RFC 9360) に入れる。先頭の証明書が reader の鍵を持つ。
  • #74: M (Mandatory)、C (Conditional)、O (Optional) の略語表を追加する。
  • #76 (issue #75 を close): CDDL を本文に合わせる。ChannelBinding の番号を振り直し、cce_handover を足し、oidc4vp_* を openid4vp_* に、nfcv2 を cce に改名する。controlled_id を controller_id に直し、使われていない full-date を消し、* (int / tstr) => any と括弧付きで書く。
  • #77 (issue #69 と #70 を close): Envelope.credentials を map から配列にし、CredentialItem に query_refs (キー 3) を足し、CredentialRef を QueryRef に改名する。1 つのクエリに複数の item を返してよいかは allow_multiple で決まる。
  • #81 (issue #67 を close): 「reader」を「verifier」に置き換える。reader_auth は verifier_auth に、ReaderTransactionTranscript は VerifierTransactionTranscript になる。
  • #83 (issue #58 を修正): scenario_sets や credential_queries を snake_case にするなど、大文字小文字をそろえる。ワーキンググループは「map のキーは整数なので」編集上の変更と判断した。
  • #85 (issue #72 を参照): 「To be completed」とだけ書いた Security Considerations 節と、OIDF の Notices 附属書を追加する。WG Draft を公開できるようにするためである。

マージされずにクローズ:

  • #84: 2026 年 11 月 4 日に作られ、1 分以内にクローズされた。#85 は同じブランチ (72-required-sections) から、同じ題名、同じ diff で出されている。
  • #59、#73、#82: 大文字小文字を直す修正の前の版。#59 と #73 は次の pull request に引き継ぐ形でクローズされ、#82 はマージ競合のため #83 に置き換えられた。

影響分析

  • Upstream: mdoc の附属書は ISO/IEC 18013-5 の構造 (Document、DeviceAuth、SessionTranscript、KeyAuthorizations) をそのまま使う。18013-5 第 2 版との関係を示すのは編集者注の 2 か所である。発行者識別子は「第 2 版で定義中の IssuerIdentifiers 構造と同じ規則」に従い、鍵に束縛されていない mdoc は「DIS 投票向けに提案された変更」に従う (issue #56)。SD-JWT VC の附属書は RFC 9901 と draft-ietf-oauth-sd-jwt-vc の上に立つ。issue #53 は vct の継承を OpenID4VP と同じように扱うべきかを問い、issue #52 は path を OpenID4VP と 18013-5 の claims path pointer にそろえようとしている。
  • Downstream: 近接提示とオンライン提示で 1 つのモデルを使いたい wallet と verifier、そしてこのメッセージを運ぶプロトコル。ChannelBinding には OpenID4VP と Digital Credentials API のフィールドがすでにある。リポジトリは実装を挙げていない。
  • Compatibility: #61 より前に作った要求はキー 2 に文字列を入れているので、配列型に合わない。#57 より前の SD-JWT VC のクエリは vc+sd-jwt を使っている。#77 がマージされれば、それ以前に作った応答は Envelope の CDDL に合わなくなる。#76 がマージされれば、main の CDDL から作った ChannelBinding のキーが変わり、transcript のバイト列とハッシュ値も変わる。

相互運用チェックリスト

  • 実装の対象にした openid/dchp のコミット (例: 4ddd238) を記録する。README は Editor's Copy が承認された Working Group Draft ではないと述べており、中核の節はどれもまだワーキンググループの合意を得ていない。
  • CredentialQuery.credential_types (キー 2) を文字列の配列としてエンコードする (pull request #61)。n 個の type を持つクエリが n 個のクエリとして処理され、それを参照する組み合わせも同じように展開されることを確かめる。
  • SD-JWT VC の credential_format には vc+sd-jwt ではなく dc+sd-jwt を使う (pull request #57)。credential_types は mdoc の docType または SD-JWT VC の vct と、大文字小文字を区別する文字列比較で照合する。
  • ChannelBinding の整数キーは、相手と合意した 1 つの出典から取る。main では本文と CDDL が食い違っており、dc_api_origin は本文ではキー 8、CDDL ではキー 7 で、BLE のフィールドも違う。未マージの pull request #76 は本文の番号にそろえる。
  • 2 種類の transaction transcript を決定的 CBOR (RFC 8949 Section 4.2。未マージの pull request #64 は Section 4.2.1 に限定する) でエンコードし、verifier と wallet が RequestPayload バイト列について同じ SHA-256 を得ることを確かめる。
  • 応答の暗号化で HPKE の info にどちらの transcript を使うかを相手と決めておく。transcript の説明の箇条書きと CDDL のコメントは ReaderTransactionTranscript、「Use in Protocol Operations」の表は WalletTransactionTranscript としている。
  • セッション層の暗号がない場合 (Digital Credentials API、スキームによる起動) は必ず応答を暗号化する。encrypted の各要素が復号すると Envelope になる COSE_Encrypt であること、encryption_ref が additional_encryption_contexts の正しい要素を指していることを確かめる。
  • reader_auth を、RequestPayload バイト列と ReaderTransactionTranscript を detached payload とする COSE_Sign として検証する。reader の鍵の伝え方は未定で、pull request #65 は protected header に x5chain を入れる案を出している。
  • issuer_identifiers.x509_ref を、mdoc の IssuerAuth の x5chain または SD-JWT VC の x5c ヘッダーにある各証明書の Authority Key Identifier (RFC 5280) の keyIdentifier と照合する。
  • 鍵に束縛されていない mdoc や KB-JWT のない SD-JWT VC は、support_no_cryptographic_binding が true のときだけ返す。本文が定めているのはこの wallet 側の規則だけなので、フラグを立てていないのにそうした credential が届いた場合の verifier の扱いは自分で決める。
  • SD-JWT VC の束縛ではまだ相互運用しない。KB-JWT の nonce は WalletTransactionTranscript の SHA-256 だが、その文字列エンコーディングと aud の値は未定である (issue #10)。SD-JWT VC の path も未定である (issue #52)。
  • pull request #77 がマージされたら、応答の解析を CredentialRef をキーとする map から query_refs を持つ配列に移す。1 つの credential が 2 つのクエリに答える場合と、allow_multiple のもとで 2 つの credential が 1 つのクエリに答える場合を試験する。
  • Security Considerations の本文には頼らない。main には存在せず、pull request #85 もプレースホルダーを足すだけである。

検証ログ

環境

  • ランタイム:
  • ツール:
  • バージョン:

手順

結果

失敗パターン

次にやること