年齢・資格の確認を生年月日なしで行うには？VCの選択的開示と名寄せの防ぎ方

あるお酒のネット通販が、購入時の年齢確認をデジタルの証明に切り替えようとしています。お客様はスマホのウォレットに入った証明を見せ、店は「20歳以上」を確かめてから決済を通す、という流れです。

このとき店が知りたいのは「20歳以上かどうか」です。生年月日そのものではありません。資格の確認でも同じです。現場で知りたいのは「いま有効な資格を持っているか」で、資格証の全項目ではありません。「18歳以上」のような別の年齢条件でも、考え方は変わりません。

ところが、生年月日を丸ごと受け取る作りにすると、店は要らない個人情報を抱えます。逆に、判定結果だけを受け取る作りにすると、店は自分で年齢を計算できません。そのうえで、受け取った証明そのものを信じてよいかも確かめる必要があります。

• その証明を出した発行元は本物か
• 見せている人は、証明の持ち主本人か
• 期限切れや失効ではないか。前の提示の使い回しではないか

以下では、酒類販売の「20歳以上」を例に、必要以上の情報を受け取らずに確かめる作り方をまとめます。障害が起きたときの扱いまで含めて、店の側・発行する側・お客様の側から順に見ていきます。

VCの仕組みそのものの基礎は「Verifiable Credentialsとは」で解説しています。

最初に「何を判定し、何を受け取らないか」を決める

方式を選ぶより先に、店の側の判断を1行で書きます。酒類販売なら「確認した時点で20歳以上」です。業務システムなら「対象の資格が有効で、許可された業務範囲を含む」のようになります。判定、基準の時刻、対象の国・地域、必要な確かさの水準は、分けて書いておきます。

要求する項目は、年齢でも資格でも同じ形で書けます。

受け取らない情報も、同じ項目ごとに決めておきます。

• 判定・適用範囲：判定に要らない元の属性。住所や、ほかの資格
• 基準時刻：要らない提示の履歴
• 信頼の起点・異常時：認められていない発行者の自己申告。状態不明を有効とみなす処理

W3C Verifiable Credentials Data Model 2.0は、2つの確認を区別しています。暗号的に正しいかの検証（verification）と、いまの業務に使えるかの妥当性確認（validation）です。署名が正しいだけで、年齢や資格の条件を満たしたとは扱いません。上の取り決めの判定は、1つずつ記録します。

生年月日を隠して「20歳以上」だけを示すには、何が要るか

選択的開示には2つのやり方があります。証明の中の項目を選んで見せる方法と、元の値から導いた条件だけを示す方法です。

項目を選んで見せる方法では、見せた項目の値がそのまま店に渡ります。生年月日の項目を隠せば、店の手元には年齢を判断する材料が残りません。だから「生年月日は隠すが、20歳以上は示す」には、後者が要ります。発行時に判定結果を入れておく証明（派生属性）か、ゼロ知識証明などによる条件式（predicate）の証明です。

どの方式にも限界があります。採用前に確かめておきます。

• 項目ごとの部分開示：見せた値そのものは店に渡る
• 派生属性の証明書：閾値や用途ごとに、発行と更新が要る
• ゼロ知識証明による条件式：対応する形式、ウォレット、検証する側、監査の方法
• オンライン照会のトークン：発行者が提示先を追えてしまう。障害の影響を受ける

ゼロ知識証明の考え方そのものは「ゼロ知識証明とは」で解説しています。

項目を選んで見せる仕様の1つにRFC 9901（SD-JWT）があります。ただし、生年月日の項目を見せなければ「20歳以上」を自動で計算して示せる、というわけではありません。必要な条件式が、採用する形式と実装で使えるかをPoCの前に確かめます。仕組みの詳細は後半にまとめました。

個人の情報をどこに置くか

生年月日や資格証の本文は、削除や訂正が必要になることがある情報です。ハッシュにしても安心はできません。生年月日や資格番号は候補が少ないので、総当たりで突き合わされるおそれがあります。

だから、変更できない公開の台帳には置きません。元データ、スマホの中の証明、共有する信頼情報、店側の記録の4つに分けて持ちます。

ブロックチェーンは必須ではありません。候補になるのは、独立した複数の組織が、1つの運営者を通さずに更新の履歴を確かめたい場合です。そのときも、使うのは信頼情報の置き場所だけです。

• 元データ（発行する側）：本人確認の原本、資格台帳、審査結果を、発行者の正本の業務システムで管理します。
• スマホの中（お客様の側）：ウォレットが証明書と秘密鍵を持ち、求められた属性か判定だけを見せます。
• 共有する信頼情報：発行者の認定、公開鍵、スキーマ（証明の項目の型）、まとめた状態情報を配ります。ブロックチェーンを使う場合も、個人ごとのハッシュや提示の記録は置きません。
• 店側の記録：要求ID、判定方針の版、判定結果、処理結果を残します。証明書の全文は普段のログに残しません。

その提示が「いま、この店あて」かを確かめる

ウォレットは、求められた属性を画面に出します。お客様が、提示先と目的を確かめられるようにするためです。店の側は、応答をそのやり取りの中だけで受け付けます。別のサイトや、後のやり取りに使い回されないようにします。

1. 店が、証明書の種類、必要な属性か条件式、目的、保持期間を含む要求を作ります。
2. ウォレットが、店の身元と要求の中身を確かめ、お客様に見せます。
3. お客様が承認し、ウォレットは必要最小限の提示データ（presentation）を作ります。
4. 店が、その証明が今回この店あてに、いま作られたものかを確かめます。使い回しや横流しではないかを見るのです。
5. 業務システムは結果にもとづき、許可、拒否、別の確認手段のどれかへ進みます。

4で確かめる項目の一覧は、後半の「実装する人向けの詳細」にまとめています。この流れの仕様はOpenID for Verifiable Presentations 1.0 Finalが定めています。ログインと証明の提示を1つの流れにまとめる場合の判定の分け方は「VC提示でログインする設計」で扱います。

名寄せを防ぐには、氏名を隠すだけでは足りない

氏名がなくても、提示同士が結びつくことがあります。複数の店に次のものを見せた場合です。

• 同じ証明書や、本人を指すID
• お客様の鍵や、状態を問い合わせる先
• 珍しい属性の組合せ

W3C VC Data Model 2.0も、識別子による相関と、提示同士を結びつけにくい開示（unlinkable disclosure）を区別しています。対策は次のとおりです。

• 店ごとに、同じ固定の識別子を求めない。
• 証明書1件ごとの状態の問い合わせを発行者に送らない。まとめたステータスリストや、適切なキャッシュを検討する。
• IPアドレス、端末のフィンガープリント（端末を見分ける特徴の組合せ）、アクセス解析、QR読取ログも、データの流れに含めて評価する。
• 資格の区分、勤務地、珍しい属性の組合せが、個人を特定し直す手がかりにならないかを試す。
• 「選択的開示に対応」と「店同士で結びつけられない」を同じ意味で表示しない。

デジタル庁の「令和6年度DIWアドバイザリーボード報告書」も、この考え方を取り上げています。官民のサービスで必要最小限の情報を見せる選択的開示を、DIW（デジタル・アイデンティティ・ウォレット）の主な使い方として整理しました。技術方式だけでは足りません。求める事業者の側も、受け取るデータを絞る必要があります。

資格の変更や障害のとき、結果をどう分けるか

資格の証明には、更新審査中、一時停止、状態情報の配信障害、発行者の鍵の事故といった場面もあります。「発行済み」か「失効済み」かの2つでは、これらを表せません。そこで結果を5つに分け、それぞれの業務の扱いを決めておきます。

元に戻す条件は、結果ごとに違います。

• 有効：処理した時刻と判定方針を記録する
• 期限切れ：新しい証明書を発行する
• 一時停止：解除の記録と、新しい状態情報を確かめる
• 失効：再審査のあと、別のIDで再発行する
• 状態不明：あらかじめ決めたキャッシュか、別の確認手段を使う

W3C Bitstring Status List v1.0は、多くの証明書の状態をまとめて配る方式です。1件ずつの問い合わせで追跡されるのを抑えられます。

ただし、手元に取っておく時間を長くすると、止まりにくくなる代わりに失効の反映が遅れます。年齢確認、施設の入場、医療・設備の資格では、許せる時間が違います。状態情報をどこまで古くても受け入れるかと、状態不明のときの代わりの手段は、証明書の種類ごとに決めます。鮮度の決め方と配信障害時の判定は「VCの失効設計」、発行者の認定の管理は「VCの信頼レジストリ設計」で詳しく扱います。

スマホをなくしたとき、古い証明をどう止めるか

ウォレットの端末をなくしても、その端末の中には証明書が残っています。新しい端末に鍵を戻すだけでは、古い端末の証明書は使えるままです。だから、古い証明書を止めるか失効させ、新しい鍵に向けて出し直します。

1. 今のID基盤か対面の手続きで、持ち主を確かめ直します。
2. 古い証明書を一時停止（SUSPENDED）か失効（REVOKED）にします。
3. 新しい鍵へ証明書を出し直します。新旧の対応は、発行者の監査DBにだけ残します。
4. 状態情報がすべての店に届くまでの時間を測ります。新旧が重なる間は、追加の確認を求めます。
5. 端末が見つかっても、古い証明書を自動で有効に戻しません。

持ち主の鍵と証明書の寿命を分ける基本の設計は「DID・VCの導入設計」、端末認証の選択肢は「PasskeyとWebAuthnを使うWallet設計」で補足しています。

PoCでは、出しすぎ・名寄せ・状態不明をわざと起こして確かめる

採用を決めるのに要るのは、出しすぎ・名寄せ・状態不明が起きたときの動きです。正常なQRの提示が通るだけでは、それは分かりません。年齢の閾値か資格を1つに絞り、次の結果を自動の試験と運用の演習で確かめます。

• 求めていない氏名、生年月日、住所、資格番号が、通信内容、ログ、アクセス解析に残らない。
• 認められていない発行者、期限切れの鍵、許可していない署名方式、違う版のスキーマを拒否する。
• 同じ提示データの再送、別の店への転送、期限切れのnonce（使い回し防止の番号）を拒否する。
• 店を2つ用意し、固定の識別子、お客様の鍵、状態の問い合わせ、付随情報で名寄せできてしまうかを測る。
• 失効の反映の遅れ、状態情報の配信先の停止、古いキャッシュ、発行者の鍵の更新で、決めた処理へ進む。
• ウォレットをなくした後、古い証明書が拒否され、新しい証明書だけが通るまでの時間を測る。
• 同じ要求IDを処理し直しても、二重の入場、二重の権限付与、重複した監査記録が起きない。

合格の目安は「選択的開示に対応した」ではありません。次の5つです。

• 求めていない属性の送信が0件
• 許せる時間内に失効が反映される
• 再送の拒否率が100%
• 状態不明（UNKNOWN）のとき、決めておいた代わりの手段が成功する
• 監査ログから証明書の全文を組み立て直せない

ブロックチェーンを使わない方がよいのはどんなときか

次の条件がそろうなら、ブロックチェーンより、OIDC、有効期間の短い署名付きトークン、中央の照会APIの方が単純です。

• 関係者が1つの企業の中に閉じている
• 発行者のAPIへ常につなげ、資格の状態がよく変わる
• 共有の台帳を運営する組織を決められない

ブロックチェーンを使っても、置き換わらないものがあります。本人確認、資格の審査、ウォレットの復旧、状態情報の更新、法的な効力の判断です。

一方、独立した複数の組織が、発行者の認定や鍵の変更を一緒に確かめたい場合もあります。1つの運営者に頼る度合いを減らしたいなら、信頼情報の置き場所だけをブロックチェーンにする価値があります。判断の軸は「個人データを載せられるか」ではありません。「公開してよい個人以外の情報を、誰がどのルールで更新し、障害のときにどう戻すか」です。

実装する人向けの詳細

ここからは、さきほどの店や発行者の側で、実際に仕組みを組む担当者向けの補足です。

SD-JWTで開示を選ぶ仕組み

RFC 9901（SD-JWT）は、JSONの個別の要素をソルト付きハッシュに対応付けます。ソルトは、ハッシュを推測されにくくするために混ぜる乱数です。これで、選んだ値だけを開示できます。あわせて、任意で使える鍵による結びつけ（key binding）も定義しています。提示した人が、証明の持ち主の鍵を持っていることを示す仕組みです。

提示を受けた店が検証する項目

流れの4で、店の側は次の項目を検証します。

• 署名、発行者、所持者との結びつき
• nonce（使い回し防止の番号）、audience（あて先）、期限
• 状態情報、判定方針の版

OpenID for Verifiable Presentations 1.0 Finalは、検証者が必要な証明書や属性を求める仕組みを定めています。応答を、要求元（client）と取引（transaction）に結びつけるのも、この仕様の役割です。実装では次のことを試験します。

• nonceが一度しか使えないこと
• 要求URIの改ざん、別の検証者への応答の転送
• QRコードのすり替え

XTELAができること

私たちは、年齢・資格確認で「何を判定し何を受け取らないか」の要求整理から、データの流れ、ウォレットと発行・検証API、状態情報の配信、過剰開示や状態不明を再現する異常系のPoCまでを設計・開発しています。貴社の業務に合わせ、部分開示・派生属性・ゼロ知識証明のどれで足りるかを1つの閾値から検証できます。年齢確認義務や資格の法的効力に関わる判断は、弁護士と連携して進めます。技術構成を整理する場合はお問い合わせください。

参考資料

• W3C Verifiable Credentials Data Model 2.0
• RFC 9901: Selective Disclosure for JWTs
• OpenID for Verifiable Presentations 1.0 Final
• W3C Bitstring Status List v1.0
• デジタル庁 令和6年度DIWアドバイザリーボード報告書
• EU Digital Identity Wallet: The Age Verification Manual

資料の確認日

仕様と公的資料は、2026年9月24日に最終確認しました。