こんにちは、富士榮です。
ということでInternet Identity Workshop（IIW）も2日目です。
今日は朝からワーキンググループコールも入っていたので早めの時間から会場でZoomコールをしていたのでより疲れました。
ということで、本日のレシピは、
- Delegation + Impersonation for Agents on behalf of human
- Wallet + Key Attestation
- Zero Knowledge Proof for mdoc
- Originator Profile
- JSON-LD VC with BBS Signature
の5本です。
ということで観ていきます。
Delegation + Impersonation for Agents on behalf of human… OIDC, OAuth
まずひとつ目です。最近よくきくエージェントに自分の代わりに何かをさせましょう、って話です。
まぁ、色々と話はしましたが結果的にOAuthのモデルに当てはめるとどう考えられるのか？という話だったのでそれほど目新しさはなかったですね。
当てはめとしては、
- Resource owner : End user
- Client : Agent
- Relying party : API
とおいているので、まぁそうでしょうねぇ。
Agentかどうかは置いておいて普通のOAuthですね。Token Exchangeつかえそうだね、みたいな話もありましたが。
Wallet + Key Attestations - Paul, Christian, Kristina
ドイツのWalletの検討の話です。かなりノウハウが溜まってきていますね。
検討の対象は以下の2つのアテステーションです。
- Wallet/Client Attestation：ウォレットが正しいかどうかを示す
- Key Attestation : キーストレージの状態とユーザの認証状態を示す
EUでは政府認定の民間ウォレットに対して国がクレデンシャルを発行する、というモデルを取るため、野良ウォレットでないこと、ユーザが認証されていること、秘密鍵がちゃんと管理されていることを示さないとクレデンシャルの発行など怖くてできないわけです。
チェックのタイミングについても色々と考えていて、
- Issuerがクレデンシャル発行をする際：WalletもKeyも必須
- ウォレットからVerifierへクレデンシャルを提示する際：オプション（Issuerが発行時に確認しているから推移的に確認できる、という判断もあり）
アテステーション自体はWallet Providerが発行します。
ここの発行・管理プロトコルは標準化されていませんが、いずれ標準になってくるのかもしれません。（まぁウォレットベンダーがそれぞれやってよ、でもいいんだと思いますが）
この仕組みがあることで、以下のようなシナリオに対応ができるようになります。
- スマホの機種変更
- 複数端末の利用の管理
- 端末を盗まれた、無くした
- ウォレットに脆弱性が見つかった
どう言うことかと言うと、Issuerはクレデンシャルを発行する時に発行先のWalletの情報（アテステーション）を管理しているので、ウォレットプロバイダがウォレットアテステーションをRevokeするのをトリガーにIssuerは発行済みのクレデンシャルをRevokeする、という使い方ができます。こうすることで機種変更時や盗難時などに以前の端末に入っていたクレデンシャルを一括で無効化できるので安心、というわけです。
属性証明と違って本人確認書類とし利用する身分証明書となるとやはり発行管理が必要になるので、日本のように民間のウォレットがマイナンバーカードに依拠したクレデンシャル（いわばマイナンバーカードのコピー）を身分証明書として利用できるなんて変なことは起きないわけですね。
ちなみにVerifierに提示する際にWalletアテステーションを提示するかどうか、って議論もありましたが個人的にはLinkabilityが上がっちゃうのでやめたほうがいいんじゃないかな？って思います。やっぱりIssuer側でちゃんと管理って世界なのかと。
Zero Knowledge Proof for mdoc - Google
次はGoogleの方からmdocに関するZKPの実装の話です。
先ほどのWalletアテステーションのセッションのところにも書きましたが、mdocでもSD-JWTでもプロトコルの一部としてリンク可能性を高めてしまう情報が埋め込まれてしまうことがあります。
これをなんとかできないか？って話ですね。
そうするとデバイスとのバインドを示す鍵の置き場所はSEに限られてしまう、と。
この鍵はPresentation時に使われるので、BBS+などIssue時にデバイスバインドされた鍵の変更を要求する仕組みを使うのは非常に難しいってことになってしまいます。何しろ一番下のレイヤーの変更をしなきゃいけないって話になるので。
mdocやSD-JWTで選択的情報開示をすることでデータ見にマイゼーションの問題が解決できたとしても、リンク可能性の問題が残っちゃうよね、って話は前からありましたが、いよいよそこに手をつけ始めようとしている感じですね。
Googleでは内部ロジックの高速化などを図り、BBS＋など従来の”スマートな”方法ではない方法（Hyrax）を模索していく、ということです。
Originator Profiles - Shigeya Suzuki
鈴木先生によるオリジネータープロファイルの話です。
何気に中身を詳しく聞いたことはなかったので非常に興味深かったです。
コンテンツの発行元とコンテンツの内容の真正性の両方をちゃんと検証できるようにしましょう、って話に加えて認められた場所（アグリゲーターなど）でその情報が発信されているかどうかを確認できるようにしましょう、という仕組みです。
現状はブラウザにエクステンションを入れてチェックするとブラウザの中で表示されているコンテンツ（ニュースなど）がどのメディアによって発行されたものなのか、そのメディアはどう言うプロファイルなのかなどが確認できるのと、ちゃんと許可されたサイトでコンテンツが表示されているか確認できます。
偽情報・誤情報を利用者自身で確認できるようになるのはいいですし、広告主が意図しないサイトに広告が掲載されてしまうことが防げるようになるとブランドイメージの保護などにも役立ちそうです。
今後が非常に楽しみです。
JSON-LD VC with BBS - Dan Yamamoto
最後はIIJの山本さんのBBSの話です。
BBSの部分は前回まででほぼ完成しているので今回のポイントはやはりリンク可能性です。今日はこのテーマで1日終わった感じです。やはり熱い領域です。
山本さんのアプローチはPseudonym did:keyを使うということです。
これはひとつの秘密鍵に対応する複数の公開鍵を作成できる技術をうまく使ってIssue時、Verify時にSubject Identifierとして使う署名検証鍵を含む識別子（did:key）の出汁わけができる、と言うことです。
ドメイン単位でこれを使うことでInner domain linkabilityとinter domain linkabilityの両方を実現できるわけですね。
まだ標準化へ持ち込めているわけではないそうですが、今後の標準化が望まれますね。
ということで明日は最終日です。
投稿
0 件のコメント:
コメントを投稿