2024年6月13日木曜日

cheqdのDID Resolverを試してみる②

こんにちは、富士榮です。

一昨日に引き続きcheqdのDID Resolverを試してみます。

今回は手元に環境をセットアップしてみようと思います。


まずは、gitのレポジトリのクローンをします。

git clone https://github.com/cheqd/did-resolver.git

そしてdocker compose。これでおしまいです。もちろんdocker-compose.ymlをいじってカスタマイズすることもできます。

docker compose -f docker/docker-compose.yml up --detach


これでlocalhostの8080で起動してきますので、curlなどでDIDを投げ込んで解決してみましょう。

まぁ、当たり前ですがちゃんと動きますね。

手軽にDID Resolverが手元で動かせる時代になってきましたね。良い意味でUniversal Resolverのみに頼らなくても良い時代がもう少しで到来しそうです。何しろ最終的にはリゾルバの信頼性が問題になってきてしまうので。

2024年6月12日水曜日

Verifiable Credentials改めReusable Identity?何をどこまで検証すべきなのか

こんにちは、富士榮です。

先日のIdentiverseやEuropean Identity & Cloud Conferenceで目についたのが「Reusable Identity」というキーワード。

どうも話の流れを聞いていると、一般名詞としてのVerifiable Credentials(mDocやSD-JWT-VCやW3C VCDM、anonCredまで含む)の中でIdentity Verificationに使うものをReusable IdentityとかDecentralized Reusable Identityと呼ぶことに(誰かが)したらしいです。

openart.aiに描かせてみたら、なんだか資源ごみみたいになってしまった。

ちょっと検索してみると、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による機械翻訳) 

https://www.identity.com/what-is-reusable-identity/


この話とWalletのセキュリティの話がかなり密接に結びついて分類が始まってきているように思えているので、今日はその辺りの話を整理し始めようかと思います。

WalletとHolderの違い

そもそもWalletとHolderが同じものとして扱われてしまうことが多いのですが、EICのパネルでも少し話題に登った通り、IssuerはクレデンシャルをWalletに対して発行するのではなく、Holderに対して発行するんですよね。

W3C VCDM1.1のいつもの図を見てもそのように記載されています。

どうもこのHolder=Walletというイメージが先行し過ぎてしまっていることが混乱を招く一因になってしまっていると思います。


WalletとHolderとクレデンシャルのバインディング

ここでは3つの話があります。

  1. Holder-クレデンシャルのバインディング
  2. Wallet-クレデンシャルのバインディング
  3. 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などを使うのか?など非常に無理がある話です)


こうなると、Verifierの視点で何をどこまで検証すべきなのか?についてはシナリオと資格情報の種別によって変わってきそうです。
  • シナリオは、対面なのかリモートなのか
  • 資格情報の種別は、身元確認(Identity Verification)に使うものなのか単なる資格確認なのか
こんな視点で分類ができると思います。

また、「検証」という言葉についても何を?という話があります。NIST SP800-63A-3的に言うと、
  • Validation:エビデンスの真正性の確認
  • Verification:持参人がエビデンスが指し示すエンティティと同一であることの確認
だと思います。(NIST SP800-63の中でもValidationとVerificationの使い分けは混乱が見られるので全体にこの定義が当てはまるわけではありませんが)

これらの視点で考えると、Verifierは対面(デジタル)でもリモートでも
  • 受け取ったクレデンシャルのValidationは行いたい
  • 持参人の検証はシナリオによる
ということが言えると思います。

また、対面かリモートかによって、Verificationの方法は若干変わります。
  • 対面ならValidateされたクレデンシャル内の顔写真などと持参人を比較(Verify)する
  • リモートならValidateされたクレデンシャルが指し示すエンティティと同一であることを別途本人確認(例えばeKYCを含む)した結果と比較する

おそらく、Reusable Identityの文脈においてはこのリモートにおけるVerificationも一つのクレデンシャルの中で閉じて実施する必要があるので、先に挙げた3つのバインディングにかなり気を使うことになります。(要するにパスキーのように一回の動作で多要素認証と同等のことを行う)
しかしながら、単なる資格確認であればVerificationについては他のオプション(eKYCなど)と組み合わせることで実現が可能な話なので、Walletの作り方を含めそこまで気にし過ぎなくても良いのではないか、と思います。(現に、OpenBadgeなどではバッジと持参人の紐付けの確認は検証側の仕事として整理されています)

ちょっとダラダラと書きましたが、Walletのエコシステムを拡充させるためにはApple Walletがマイナンバーカードを格納できるようになった!万歳!で思考停止せずにちゃんと考える必要がありそうです。

2024年6月11日火曜日

cheqdのDID Resolverを試してみる①

こんにちは、富士榮です。

そういえばDIFのUniversal Resolverばっかり使っていましたが、他にもオープンソースのDID ResolverとしてcheqdのDID Resolverもあるなぁ、ということでセットアップしてみたいと思います。

cheqdのWebサイト。最近よくあるVC関係のプラットフォームを提供している会社ですね。(VC-JWT、JSON-LD、AconCredに対応しているようです)


こちらに開発者向けドキュメントがあり、dockerにセットアップする方法が書かれています。

https://docs.cheqd.io/identity/advanced/did-resolver


なお、https://resolver.cheqd.net/でホストされているものをそのまま使うことも可能ですので手軽に試したい場合はこちらでも良いと思います。

まずは今日は手始めにこちらから試してみようと思います。

こんな感じのサンプルが掲載されています。

curl -X GET https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47

細かいですが、サンプルのDIDのDID Documentが帰ってきますね。

ちなみに、サンプルはdid:cheqdという独自メソッドですが、他のメソッドへの対応状況はどうなっているのかみてみます。とりあえず手元にあったdidがionとwebだったので試してみましたが、両方ともNGでした。。。。

    "error": "methodNotSupported",

って言われます。

 

ドキュメントを見ると、

The resolver.cheqd.net API endpoint is run by the cheqd team and only handles did:cheqd credentials.

If you want to resolve DIDs from multiple DID methods, the Universal Resolver project provides a multi DID method resolver.

とありますね。要するに他のDIDを解決したければUniversal Resolverを使え、と。まぁ仕方がないですね。

ちなみに逆にUniversal Resolverでdid:cheqdのDIDは解決することができました。



次回は手元にセットアップしてみたいと思います。






2024年6月10日月曜日

いよいよInteropカンファレンスが迫ってきました

こんにちは、富士榮です。

以前告知させていただいた通り、明後日6月12日〜14日でInteropカンファレンスが幕張で開催されます。

今回は(も)、Trusted Webの話を2コマにわたってお届けしますので、ぜひお越しください。QAも対応する予定なのでぜひ質問してくださいね。(某林檎の件とか質問くるのかなぁ)


YB2-01

Trusted Web(1)  デジタル空間におけるトラストをいかにして実現するか?


YB2-02

Trusted Web(2)  実社会での本格利用に向けて動き始めた 分散型IDとデジタルIDウォレット



素晴らしいパネリストの方々と議論できるのが私も楽しみです!


2024年6月9日日曜日

Internet Identity Workshop 2024Bの申し込みが始まりました

こんにちは、富士榮です。

Identiverse、EICが終わったところですが、今日からInternet Identity Workshop(IIW)の申し込みが開始されました。
次は10月29日〜31日、場所は変わらずMountainViewのComputer History Museumです。



ちなみに、今ならEarly Bird Registrationができるので安いですよ。
ギリギリになると満席になって申し込めなかったりすることもあるので行く予定の方はお早めに。

ちなみにIIWの前の週はSIDI Hubの東京イベント、翌週はIETF(ダブリン)ですので、全部参加する人は大変ですね・・・(多分私もその一人)

2024年6月8日土曜日

OpenID Federation Implementer's Draft4のパブリックレビュー期間が始まっています

こんにちは、富士榮です。

Identiverse、EICで全然書く暇がありませんでしたが、OpenID FederationのImplementer's Draft 4のパブリックレビュー期間が始まっています。



X.509と並びトラストを確保するためのプロトコルとして注目が集まっている仕様なので要注目ですね。

European Identity & Cloud Conference クィックレビュー Day4

こんにちは、富士榮です。

いよいよEICも最終日です。
そして私の出番でもあります。出番が最終日にあるとずっと落ち着かないんですよねぇ。

まあ、私もコマはそのうち国内でもご説明する機会があると思うのでその際に詳細は、ということで。
DNPの岡本さんに写真いただきました。ありがとうございます。

しかしキーノート部屋がアサインされるとは思わなかったので無駄に広い空間でビビりました。
ちなみに舞台裏はこんな感じになっております。


ということで自分の出番が終わると一気に気が抜けてしまったのですが、午後もちょっとだけセッションを聞きました。

Food Supply Chain: Pioneering a Digital Farm Wallet with a Consortium in New Zealand - Klaeri Schelhowe

Identiverseの初日にPaul Ashleyが話していた農業領域でのVerifiable Credentialsの利活用ユースケースの話です。
主に農業の中で発生するデータマネジメントについてフォーカスしている内容ですね。


農業セクターもグローバルサプライチェーンですし、当然データの真正性や相互運用性は大事ですし、サステナビリティ(GHGなど)の文脈におけるエビデンスにも検証可能性は非常に大きな意味を持つわけです。


ということでニュー字ランドでTrust Alliance NZというアライアンスを作ったという話です。Farmer Association(農協?)に加えて技術スタックを持った人たちも含めアライアンスを組んでいるそうです。

農業領域におけるインプットデータ、アウトプットデータとして以下に着目している、と。


ユースケースは多岐に渡り、金融アクセスやGHGエミッションなどデータ共有が必要となる14のユースケースを選定しているとのことです。


期待される成果としては、
  • 市場参入、持続可能な金融、業務効率の向上を促進
  • ブランド価値の向上(信頼から証明によるブランドへ)
  • コンプライアンスへの取り組みを付加価値に変える
が挙げられています。やっぱり農業ってブランドだよなぁって思います。

実装側面から言うと、Digital Farm Wallet Pilot ProjectをAnonyomeと一緒にやっているとのこと。こちらは先日のPaulのセッションで話のあった組織ウォレットの話ですね。

農家さんにとってのメリットも色々と。

ただ、コンソーシアムモデルならではの難しさも。競争と協業のバランスなど泥臭い話は多いと思います。今後の動きに注目ですね。


Closing Keynote - Martin Kuppinger

いよいよClosingです。4日間は長いようであっという間です。


来年は2025/5/6-9、同じ場所です!