CIAMとDID・Verifiable Credentials（VC）は、どちらもデジタルIDを扱うが、同じ問題を解く技術ではない。CIAMは特定サービス群の顧客アカウントを管理し、DID・VCは組織をまたいで識別子や証明を検証するために使える。両者を接続するには、役割を混同しない設計が必要である。
1. 基礎概念
CIAMが扱う中心的な責務は次のとおりである。
- アカウント登録とログイン
- 認証強度とセッション管理
- サービス内の顧客ID
- SSOとアカウント連携
- プロフィール・同意・アクセス制御
DIDは、特定事業者のアカウントに閉じない識別子と検証手段を提供する。VCは、IssuerがSubjectについて行ったClaimを、HolderがVerifierへ提示できるようにする。
したがって、CIAMの顧客ID、OIDCの`sub`、DID、VCのCredential Subjectは、すべて「ID」と呼ばれても意味が異なる。これらを一つの値へ無条件に統一すると、サービスをまたぐ追跡、アカウント誤統合、鍵紛失時の復旧困難などを招く。
接続設計では、内部アカウントと外部の識別子を分離し、必要に応じてBindingを管理する。利用目的ごとに異なる識別子を使うPairwise Identifierも、相関を抑える選択肢になる。
2. 技術フロー
VCを使ってサービス登録時の属性を確認する例を示す。
利用者
│ 1. OIDCでログイン
▼
CIAM
│ 2. 内部顧客IDとセッションを発行
│ 3. 必要な証明を要求
▼
Wallet
│ 4. 利用者が提示内容を確認
│ 5. VC / VPを提示
▼
Credential Verifier
│ 6. 署名・Issuer・状態・Holder Bindingを検証
▼
CIAM / 業務サービス
│ 7. 検証結果を内部顧客IDへ関連付け
│ 8. 同意された目的の範囲で利用
▼
サービス提供CIAMは日常的なログイン、セッション、アカウント復旧を担当する。Credential VerifierはVCの技術的検証とIssuerのTrust Policy適用を担当する。業務サービスは検証結果を使って、年齢条件、会員資格、本人確認レベルなどの判断を行う。
VCの内容をすべてCIAMへコピーする必要はない。要件によっては「有効な資格を確認済み」「確認日時」「検証したPolicy」といった最小限の結果だけを保持できる。再検証が必要な時期、有効期限、失効確認の方法も合わせて設計する。
逆方向では、CIAMで確認・管理している属性を基にCredential IssuerがVCを発行できる。その場合も、CIAMの認証結果だけで発行条件を満たすのか、追加審査が必要か、どの鍵へCredentialをBindingするかを明確にする。
3. 何を解決できる技術か
CIAMだけで組織横断の属性確認を行う場合、サービスごとに証明書画像を収集したり、外部機関のAPIへ都度問い合わせたりする必要がある。DID・VCを接続すると、利用者が保持する証明を標準化された形で提示し、サービス側が機械的に検証できる。
一方、DID・VCだけで一般的なWebサービスの認証基盤を置き換えると、セッション管理、アカウント復旧、不正検知、カスタマーサポートなどを別途構築しなければならない。既存CIAMと接続すれば、日常的なログインは成熟した仕組みを使い、組織横断で再利用したい証明だけをVCとして扱える。
この統合が解決できるのは、主に次の課題である。
- 同じ属性をサービスごとに再提出する負担
- 証明書画像の目視確認と改ざん判定
- 発行組織への都度問い合わせ
- 特定のIdentity Providerに閉じた属性連携
- 必要以上の個人情報を収集する設計
ただし、Trust Framework、識別子の相関、Wallet復旧、失効確認、同意管理は統合後も残る。CIAMとDID・VCの接続は、すべてのIDを一つにまとめることではない。それぞれの責務を保ったまま、認証結果と検証可能な証明を必要な範囲で結び付ける設計である。
統合設計を成立させる条件
CIAMはサービス群で有効なセッションを発行し、Issuerは属性を証明し、Verifierは提示を評価する。同一組織が複数役割を実装しても、論理的責務と監査記録は分ける。
OIDCの`sub`、DID、Credential Subjectは同じ人物を参照し得るが、自動的に等価とは証明されない。双方のアカウント制御、IssuerによるBinding、再認証などが必要になる。内部顧客IDを不変の主キーとし、外部識別子をLink Tableへ格納すれば、IdP変更や鍵ローテーションでも業務データを維持できる。Linkには作成根拠、確認時刻、保証水準、失効状態を記録する。
処理では、まずCIAMが認証済みセッションを作り、業務サービスが不足する保証を判定する。必要な場合だけWalletへ提示を要求する。VerifierはProtocol、署名、Holder Binding、Status、Issuer Trust、Claim条件を検証する。
検証結果にはCredential Type、Issuer、Policy Version、検証時刻、有効期限を記録すると再評価しやすい。ただし、不要なClaimは保存しない。Cache期間はCredentialの期限だけでなく、途中停止の可能性、Status更新頻度、業務リスクから決める。
CIAMのパスワード復旧だけでWalletの権限まで新端末へ移すと、CIAM復旧がWallet乗っ取りの経路になる。CIAMアカウントとHolder Keyの制御は別々に確認し、Link変更時には通知と監査を行う。
CIAMの属性からVCを発行する場合、現在のアカウントとCredential Subjectの関係、発行根拠、審査手順、Policy Versionを記録する。利用者が自由編集できるプロフィールを検証済み属性として発行してはならない。
統合は段階導入できる。すべての利用者へWalletを必須にせず、特定資格だけVC提示へ対応し、従来手段と成功率、確認時間、再提出率、サポート負荷を比較できる。
Holderを介した提示ではIssuerがすべての提示先を把握しない構成を作れるが、StatusやTrust List取得によるメタデータ漏えいは残り得る。誰が何を観測できるかをThreat Modelで確認する。
評価指標には手入力削減、確認時間、誤判定率、収集データ量、離脱率、再発行率、復旧問い合わせを含める。最終原則は最小結合である。外部識別子を恒久的に一体化せず、必要な目的と期間だけ関連付け、Credential全文ではなく検証結果で足りるなら全文を保存しない。
CIAMまたはVC基盤の一方が利用できない場合の縮退動作も決める必要がある。すべてを拒否するのか、低リスク機能だけ許可するのか、後日再検証を条件に暫定利用を認めるのかを業務リスクから定める。統合は正常系だけでなく、障害、失効、鍵更新、Trust Policy変更まで含めて完成する。
参考資料
- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)
- [Decentralized Identifiers（DIDs）v1.0](https://www.w3.org/TR/did-core/)
- [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/)
- [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)
