いよいよ最終日です。
割と毎日みっちりとセッションを聞いたので、かなりの疲労度ですが何はともあれようやく最終日です。
初日から3日までの記録はこちらです。
本日は午前中にブレークアウトセッションやマスタークラス(ベンダーによる製品解説)があった後、お昼の時間帯にクロージングキーノートとして待ちに待ったSteve Wozniakの登場、というスケジュールです。
では、早速参加したセッションについてメモを記録しておきます。
◆ブレークアウトセッション・マスタークラス
- Adventures in Self-Sovereign Identity: From Hyperledger Indy to W3C Verifiable Credentials by Workday
 - 実はDIFのメンバーになぜWorkdayがいるのか結構疑問だったので、このセッションには期待していました。結果非常に有益でした。
 - スピーカーはCSOの人で、ここ最近Self Sovereign Identityのリサーチを担当してきたとのこと
 - 昨年よりIBMと一緒にHyperledger IndyベースでPoCをやってきた
 - 本日はその結果をデモを交えて紹介してくれるとのこと
 - まずはお決まり通り、SSIで解決したいことの例
 - 成績の情報を大学が学生に付与
 - 学生は就職したい企業に成績情報を提示
 - 企業が内容の検証をする
 - このシナリオで確認に時間がかかったり、プライバシーの問題を抱えていたりする(例えば、2018年以降に卒業していることがわかれば良いので、実際の卒業年度がわかる必要がなかったり、成績の平均が3よりよければ良いので実際の細かい点数までは必要ないはず、という話。ゼロ知識証明ですね)
 - 昨年、IBM、Workday、Evernym、ATB Financialで実証実験を行った
 - 学生のシナリオ以外に、以下のシナリオを各役割を持って実行した(要はオンラインでのKYCと銀行口座の即時開設のシナリオです)
 - Workday:従業員証の発行
 - ADOT(アリゾナ州の交通局):免許証の発行
 - Evernym:Identity Walletの提供
 - ATB Financial:銀行口座の開設
 - IBM:Hyperledger周りのインフラの提供
 - 環境を設計するにあたり、色々と検討したこと(この辺りはかなり細かく資料では説明されていたので今後資料が公開されることがあれば是非見てみるべきだと思います。そのくらい参考になりました。写真は結構撮りましたが、今回はとりあえずのメモだけ記録しておきます)
 - 暗号アルゴリズムの選定
 - Ed25519:署名・署名検証に利用
 - Curve25519:Key Agreementに利用
 - 属性のブラインディング(匿名化)
 - ゼロ知識証明の利用
 - Walletとの接続の方式
 - Schemaの設計
 - Credentialsの設計
 - Pairwiseにできるかどうか、、など
 - デモ1
 - WorkDayに従業員がログイン、Walletを登録する(QR読み込み)
 - WorkDay側で従業員の証明情報(Verifiable Credentials)を発行すると、従業員のWalletにプッシュ通知がされ、Wallet上に情報が読み込まれる
 - ATB Onlineのサイトで口座開設プロセスをスタートすると、QRコードが表示されるため、Walletで読み込むと先に発行された従業員情報を送信して良いか確認が入り、利用者が送信する属性を選択して送信するとATB Online側の開設プロセスが始まる
 - ATB Online側の確認プロセスが終了すると、従業員のWalletに開設された口座番号の情報がプッシュ通知される
 - 従業員がATB Onlineへログインする際は、発行された口座番号をサブミットするとWalletへ通知がくるので、承認するとログインが完了する(パスワードを登録していないので、完全にパスワードレスでのログインが実行される)
 - デモ2
 - 郵便局で検証済みの住所情報をWalletへ発行する
 - アイスクリーム屋さんのキャンペーンサイトで特定の住所に住んでいることが確認できれば無料でアイスクリームがもらえるクーポンが発行される
 - 利用者がアイスクリーム屋さんのWebサイトに表示されるQRコードをWalletで読み取り、郵便局で発行された検証済み住所を提示するとクーポンのバーコードが発行される
 - これらのシナリオをHyperledgeIndyと、素のW3CのVerifiable Credentialsを使って検証をしてPros/Consを出してみた。
 - まずはHyperledgerIndy
 - Pros
 - デフォルトでPairwiseなDIDが発行されるのでVerifier(RP)側での名寄せの心配がない
 - ゼロ知識証明をサポートしている
 - エコシステムが存在する(Ledger、Wallet、プロトコル)
 - 相互運用性の実験を行うプロジェクト(Project Aries)も存在する
 - PIIはLedger上には載らない
 - Cons
 - 暗号が難しいのでプロにしか良さがわからない(顧客や監査人への説明が難しい)
 - プロジェクトが同時並行して動いているのでパーツ単位で成熟度が異なる
 - プロトコルがLedgerと密接に紐づいている(今の所)
 - 次にW3C Credentials
 - Pros
 - 暗号モデルがシンプル
 - 相互運用性が高い
 - Ledgerの種類に依存しない
 - PIIはLedger上には載らない
 - Cons
 - DIDがPairwiseではないため名寄せが出来てしまう(注釈:実装の仕方次第だと思いますが)
 - Verifiable Credentialsのフォーマットは標準化されているが、伝搬のためのプロトコルは標準化されていない
 - 標準が最終化されていない
 - 標準がオープンすぎる。JSON-LD vs JSON vs JWT
 - プロジェクトから学んだこと
 - W3Cの方が開発しやすい(開発者にとって開発しやすい)
 - 標準仕様を見て素で開発するか、OSSのプロジェクトを使って開発するか考えないといけない
 - 何よりもSovrin/HyperledgerIndyが動いた
 - PoCではRevocationのシナリオはやらなかったのでその部分は注意
 - このテクノロジーに感じるポテンシャル
 - パスワードレス・ログインにも使える(強固な認証をスケーラブルに実装できる可能性がある)
 - この方式が標準として普及していくといいかも(SAMLみたいに)
 - その他
 - Githubに色々と公開されているのでぜひみなさん試してみましょう。
 - https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md
 
- Auth0 Masterclass: Identity and the Yellow Brick Road - The Last Few Steps Are Always the Hardest by Vittorio Bertocci
 - クロージング・キーノート前最後のセッションはやはりVittorioのセッションで締めておこうと思います。
 - どういう状態がID基盤の理想の状態なのか?
 - 色々なプロトコルのアプリケーションやAPIに対応している
 - 色々なプロトコルのデータソースやディレクトリに対応している
 - 色々なデバイス(ブラウザ、モバイル、デスクトップアプリ)に対応している
 - 多くの場合、暗黙の前提事項がある
 - Identity Provider
 - サポートされること
 - IDaaSが対応しているプロトコルの一つに対応している
 - 移行できること
 - 認証ロジック
 - 標準に置き換えが可能である
 - そのまま(Out-of-box)で使える
 - 過去のIDとクレデンシャルがそのまま使える
 - 認可
 - 見たものが全て、つまり今のままの権限を移行できる
 - 簡単に使えるのか、色々と出来るのか、という軸で4象限で表すと、壁に突き当たる
 - デプロイの壁(自前のデプロイの限界地点。スケーラビリティとか)
 - ゼロから作るよりはSDKを使った方が簡単になるが、出来ることは減る
 - SDKより製品を使えば簡単になるが、出来ることは更に減る
 - どんなに頑張っても自前でデプロイするには専業クラウドを超えられない地点がある(コストが無限にあれば別だが)
 - コードの壁(汎用サービスではどうしても実現できない限界地点)
 - SaaS(IDaaSを含む)を使えば簡単に使えるがカスタマイズの自由度はほとんどない
 - PaaSなどに落とし込んでいけばカスタマイズの自由度はある程度上がるが難しくなってくる
 - いずれは自前でコードを書かないとなんともならない限界点に突き当たる
 - この問題へのある程度の答えが拡張可能なIDaaSである
 - 順に導入時の課題へのAuth0での対応を見ていく
 - Identity Source
 - 標準でサポートしていないIdPとの接続
 - 最近リリース(ベータ)された汎用OIDC接続を使う
 - 標準に対応していないIdPとの接続(Apple IDとか)
 - Extensionで接続する
 - 移行できないDBとの接続
 - カスタムDB接続を使う(無理に移行せずに、一旦は繋いでしまって時期を待つ)
 - UXのカスタマイズ
 - https://flows.auth0.comで簡単に画面デザインが出来る
 - 会社名を入れて検索すると勝手に会社のロゴをとってきてセットしてくれたりする
 - ユーザーライフサイクル
 - Pre-Signup、Post-SignupのルールをJavaScriptで拡張できるので、例えばIdentity Verificationを挟んだり、と色々と出来る
 - 追加の属性を他のDBからとってきたりも可能
 - 同意をとったり、外部のページへ飛ばすことも可能
 
ちなみにTシャツとダイアグラムの書かれた画用紙を貰いました
◆クロージング・キーノート
いよいよクロージングです。会場となるBall Roomが開くのを大勢の参加者が扉の前に押し寄せて待っています。
開場とともに人の群が良い席を求めて雪崩れ込んでいくのは圧巻でした。やはり参加者の一番の期待はSteve Wozniakですね。あっという間に会場は満席に。最終日の最後のセッションまでこんなに熱気があるカンファレンスも滅多にないんじゃないでしょうか?
会場から開演まで20分程度の間があったのですが、その間Electricヴァイオリンのライブ演奏がステージでは行われていました。Mark Woodの使っているような楽器を使っていて非常にかっこよかったです。ちなみにElectricヴァイオリンってフレットが付いているギターとヴァイオリンの合いの子みたいなモデルと、フレットレスのヴァイオリンをそのまま電子楽器にしたモデルがあるのですが、今回の方は前者のモデルをお使いでした。私も最近ヴァイオリンを弾くので、久しぶりにMark Woodを聴きたくなりました&楽器が欲しくなりましたw
さて、ようやく開演です。
Andre DurandのリードでSteve Wozniakがステージに登場すると会場は大盛り上がりです。
ステージはAndreとSteveの対談形式なので、正直なところ話の内容は拾いきれていませんが、いちいちジョークを挟みながらAndreの色々な問いに答えていくので、会場は度々爆笑の渦、でした。(付いていけない部分が多々ありましたが。名刺でステーキを切った?エピソードとか)
細かい内容は動画が公開されれば皆さんでも見ることも可能だと思いますし、私も追いきれなかったのでその時に改めて確認しようと思いますが、何点か重要だな、と思った点のみを。(かつ聞き取れた部分)
- 注目しているテクノロジーは?AIとか。
 - 我々は脳がどのようになっているのかも分かっていないし、記憶がどこにストアされているのかすらも分かっていない
 - そんな状態なので、AIはインテリジェンスを持っていないし、シンギュラリティにはなり得ない
 - Googleは人間よりも犬の画像を認識するのは得意かもしれないが、犬が何であるかを知っているわけではない
 - 人間の脳は機械よりも優れているので、まだ存在しないものを想像して創造することが大切
 - Appleの起こしたInnovationでもっとも大切だったものは
 - iPhoneではない
 - Appストアでサードパーティにマーケットを解放したことである
 - それがなければ今、我々はUberやLyftを使うことができていないはずである
 - Blockchainベースのアイデンティティについてどう思うか?
 - 我々の日々の行動を政府がトラッキング可能で利用可能な状態であること、に対して、ブロックチェーンを導入すればこれ以上データを取得されなくなる、というのはブロックチェーンを正当化する理由にはならないと思う
 
そして、来年の開催地は「デンバー」です!
非常に楽しみです!
ということで、4日間に渡ってお伝えしてきた日記もおしまいです。
ちなみに午後はペンタゴンの側のショッピングモールに行ってきました。屋上からペンタゴンが見えたので写真を撮りましたが上空から取らないとなんだかわかりませんね。。。



0 件のコメント:
コメントを投稿