こんにちは、富士榮です。
先日のIdentiverseやEuropean Identity & Cloud Conferenceで目についたのが「Reusable Identity」というキーワード。
どうも話の流れを聞いていると、一般名詞としてのVerifiable Credentials(mDocやSD-JWT-VCやW3C VCDM、anonCredまで含む)の中でIdentity Verificationに使うものをReusable IdentityとかDecentralized Reusable Identityと呼ぶことに(誰かが)したらしいです。
ちょっと検索してみると、identity.comの人のこんな記事が見つかりました。
What Is a Reusable Identity?
Reusable identity is a single set of identity credentials that allows individuals to access multiple platforms without repetitive verification. Unlike traditional centralized systems, which demand separate identity verifications for each service or platform, a reusable identity streamlines the user experience. This approach reduces the burden of multiple verifications and addresses inefficiencies and security risks linked to the repeated sharing of personal information.
再利用可能な ID とは?
再利用可能な ID とは、個人に複数のプラットフォームへのアクセスを許可する、1 セットの ID 認証情報です。従来の中央集権型システムとは異なり、各サービスやプラットフォームごとに個別の ID 認証を要求するシステムとは異なり、再利用可能な ID はユーザーエクスペリエンスを合理化します。このアプローチは、複数の認証の負担を軽減し、個人情報の繰り返し共有に伴う非効率性とセキュリティリスクに対処します。(Deeplによる機械翻訳)
この話とWalletのセキュリティの話がかなり密接に結びついて分類が始まってきているように思えているので、今日はその辺りの話を整理し始めようかと思います。
WalletとHolderの違い
そもそもWalletとHolderが同じものとして扱われてしまうことが多いのですが、EICのパネルでも少し話題に登った通り、IssuerはクレデンシャルをWalletに対して発行するのではなく、Holderに対して発行するんですよね。
W3C VCDM1.1のいつもの図を見てもそのように記載されています。
どうもこのHolder=Walletというイメージが先行し過ぎてしまっていることが混乱を招く一因になってしまっていると思います。WalletとHolderとクレデンシャルのバインディング
ここでは3つの話があります。
- Holder-クレデンシャルのバインディング
- Wallet-クレデンシャルのバインディング
- Holder-Walletのバインディング
まずHolder-クレデンシャスのバインディングです。
発行されたクレデンシャルがHolderとちゃんと紐づいているか(バインディング。要するにちゃんと対象者に対して発行されているか)はVerifierの視点からすると大切な点です。
例えば、特定の資格情報をVerifierが受け取った時に、提示してきた人(Holder)が他人のクレデンシャルを渡してきていたら問題になるケースも多いはずです。(もちろん全てのケースではない。これはVerifierのシナリオに依存する。このVerifier側の都合である、という点は非常に重要)
Verifiable Credentialsの場合、通常はVerifiable Presentationの発行者となるHolderのデジタル署名と、発行者の識別子とVerifiable Credential内のCredential Subjectの識別子が一致していることを持ってHolderとクレデンシャル発行対象が同一のエンティティであることを確認するわけです。
次に、Wallet-クレデンシャルのバインディングです。
前述のHolder-クレデンシャルのバインディングの前提はWalletが悪さをしない、ということになるので、特に国が発行する身分証明書などについては特定の基準を満たした(例えば鍵の管理がしっかりしているなど)Wallet出ないと困るわけです。こうなるとWalletとクレデンシャルの紐付け(バインディング)も検証する必要が出てきます。
このためにはWalletプロバイダが発行するWallet自体を証明するクレデンシャルと、Issuerから発行されるクレデンシャルを紐付けてデジタル署名を施す、という方法が取られたり、Secure Element等にプロビジョニングされた「管理された」鍵を使ってHolder署名をすることによりWallet自体が管理されたものであることを検証可能にする、という方法が取られたりします。
最後に、Holder-Walletのバインディングです。
要するに、他人がWalletを勝手に使っていないか?という話です。一般にWalletを起動する時にFace IDなどのOSの生体認証機能を使ってアンロックする方法が取られます。
Verifierは何をどこまで、どうやって検証するべきなのか
先に挙げたバインディングを含め全て検証をすれば確かに固い仕組みが出来上がると思います。ただし、Verifierは全ての資格情報の種別に対してそれらの検証をしたいわけではないことに注意しないといけないと思います。
例えば、単にお店の会員カードのような資格情報だった場合に持参人(Holder)とCredential Subjectが異なっても大きな問題にならないでしょうし、ビジネス機会を考えるとある程度のクレデンシャル共有は許容すべきとの意見もあると思います。
また、全てのWalletがSecure Elementに鍵を持ち、確実にIssuer等によって管理された状態となるのは非常に難しいですしToo Muchと言えます。(現実的にSecure Elementが使える端末は限定されますし、そのためにSIMを使うのか、またはマイナンバーカードやNational IDカードのICチップやクラウドHSMなどを使うのか?など非常に無理がある話です)
- シナリオは、対面なのかリモートなのか
- 資格情報の種別は、身元確認(Identity Verification)に使うものなのか単なる資格確認なのか
- Validation:エビデンスの真正性の確認
- Verification:持参人がエビデンスが指し示すエンティティと同一であることの確認
- 受け取ったクレデンシャルのValidationは行いたい
- 持参人の検証はシナリオによる
- 対面ならValidateされたクレデンシャル内の顔写真などと持参人を比較(Verify)する
- リモートならValidateされたクレデンシャルが指し示すエンティティと同一であることを別途本人確認(例えばeKYCを含む)した結果と比較する
0 件のコメント:
コメントを投稿