Verifiable Credentials Data Modelは、証明書のデータモデルを定義する。しかし、WalletがIssuerからどう受け取り、Verifierへどう渡すかには通信プロトコルが必要である。その役割を担う代表的な仕様が、OpenID for Verifiable Credential Issuance（OID4VCI）とOpenID for Verifiable Presentations（OID4VP）である。
1. 基礎概念
OID4VCIはCredential IssuerからWalletへCredentialを発行するためのAPIと認可手順を定義する。OAuth 2.0を基礎とし、Credential Offer、Authorization Endpoint、Token Endpoint、Credential Endpointなどを組み合わせる。
OID4VPはVerifierがWalletへCredentialの提示を要求し、Walletが応答する方法を定義する。Verifierは必要なCredentialやClaimを要求し、Walletは利用者の操作を経て提示結果を返す。
両仕様は特定のCredential形式だけに限定されない。W3C VC、SD-JWT VC、ISO mdocなど、仕様が対応する形式をメタデータで表現できる。したがって、プロトコルとCredential形式は分けて考える必要がある。
2. 技術フロー
OID4VCIによる発行
Issuer ── Credential Offer ──▶ Wallet
│
Wallet ── Authorization Request ─▶ Authorization Server
Wallet ◀── Authorization Code ──── Authorization Server
Wallet ── Token Request ─────────▶ Token Endpoint
Wallet ◀── Access Token ────────── Token Endpoint
Wallet ── Credential Request ────▶ Credential Endpoint
Wallet ◀── Credential ──────────── Credential Endpoint通常のAuthorization Code Flowのほか、別経路で利用者確認が済んでいる場合に使えるPre-Authorized Code Flowもある。Credential Requestでは、Walletが管理する鍵へのProof of Possessionを示し、発行するCredentialをその鍵へ暗号学的に結び付ける構成が可能である。
OID4VPによる提示
Verifier ── Presentation Request ──▶ Wallet
│
利用者が確認
│
Verifier ◀── Presentation Response ─── Wallet
│
├─ Credentialの署名を検証
├─ Holder Bindingを検証
└─ Nonce・Audience・有効性を検証同じ端末内で完結するSame-device Flowと、PCに表示したQRコードをスマートフォンのWalletで読むようなCross-device Flowがある。提示要求では、DCQLなどを使って必要なCredentialやClaimを指定できる。
3. 何を解決できる技術か
OID4VCIとOID4VPは、Issuer、Wallet、Verifierが個別仕様を作らなくても、共通の手順でCredentialを交換できることを目指す。これにより、異なる事業者のWalletやサービス間の相互運用性を高められる。
また、OAuth 2.0やOpenID Connectで蓄積された認可・セキュリティ設計をCredential交換へ応用できる。ブラウザ遷移、認可コード、PKCE、メタデータ公開など、既存のWeb基盤と接続しやすい点も利点である。
ただし、プロトコルが共通でも、Credentialの意味やIssuerを信頼する基準までは自動的に統一されない。Walletの登録、Verifierの真正性、Credential Schema、IssuerのTrust Framework、利用者へ提示する同意画面などは、ユースケースごとの設計が必要である。
Protocolを安全に運用するための補足
OID4VCIでWalletはOAuth 2.0 Clientとして動作する。Credential Issuerは発行可能なCredential、形式、Endpointをメタデータで公開する。Authorization ServerとCredential Issuerは別システムでもよい。認可とCredential生成は異なる責務だからである。
Credential Offerは発行可能なCredentialをWalletへ知らせる。WebリンクやQRコードで渡せるが、機微情報を直接含めると画面共有やログから漏えいする。参照URIにも有効期限、一回限りの値、TLSが必要になる。
Authorization Code Flowでは、WalletはCodeをAccess Tokenへ交換してCredentialを要求する。PKCEとIssuer識別子の検証が横取りやIssuer混同への対策になる。Pre-Authorized Code Flowは店頭確認後の受領などに適するが、QRコードを撮影した第三者による先取りを防ぐため、Transaction Code、短い期限、試行制限を組み合わせる。
即時発行できない場合はDeferred Credential Endpointを使える。Walletは審査中、発行済み、拒否を表示し、無制限なPollingを避ける。
OID4VPではNonceによって応答を今回の取引へ結び付ける。VerifierはNonce、Audience、Response URIを検証し、別の提示先向け応答や過去の応答を拒否する。Cross-device Flowでは、PC側セッションとスマートフォンからの応答を安全に対応付ける。
DCQLは必要なCredentialとClaimの条件を表現する。要求を広くしすぎると過剰開示の原因になるため、Walletは要求内容と実際の送信内容を利用者へ示す。
VerifierはProtocol、Credential形式、暗号証明、Issuer Trust、業務条件の順で評価する。署名検証の成功だけで提示全体を受け入れてはならない。
標準化は専用アプリや個別APIを減らすが、「OID4VC対応」だけで必ず接続できるわけではない。Credential形式、暗号アルゴリズム、Client認証、Trust Modelが一致する必要がある。さらに、悪意あるVerifierによるCredential要求を防ぐには、WalletがVerifierの身元と目的を利用者へ示さなければならない。
参考資料
- [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)
- [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)
