2019年10月8日火曜日

Azure AD B2Cのリージョンに日本が選択できるようになりました

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

ずっと日本リージョンが選択できなかったAzure Active Directory B2C(Azure AD B2C)ですが、いつの間にか?(9月末~?)日本リージョンの選択が出来るようになっています。といってもデータの保管場所はAPACということですが。

むしろ大ニュースなのはこれまでデータの保管場所がEUとUSしかなかったのにAPACが追加されたことかもしれません。

・・・実はPrivate Previewがあったことは知ってたんですが、今回の突然のGAは全然アナウンスされてないのは何故なんだろうかという疑問が。。(2019/10/08時点)

※オフィシャルリリースがされていない以上、消える可能性はあります。現時点での利用は自己責任にて。

◆これまでの問題点とFeedback

Azure AD B2C自体はリージョンに依存しないサービスなので全リージョンでエンドポイントは使えましたが、データの実体の保管場所がEUとUSしか選べなかったので、個人データの保管場所を気にする業種・業界においてはブロック要素となってきました。(AWS Cognitoは日本にもデータを置けますし、Auth0には最後の手段カスタムデプロイプランがあったりするので無理やり日本にデプロイできたりしました)

過去から日本マイクロソフトの人を含めフィードバックはあげてきましたが中国が優先されてしまい、先に中国がPreviewとしてリリースされてしまっていました。

2019/05/06 中国におけるAzure Active Directory B2C
https://azure.microsoft.com/ja-jp/updates/azure-active-directory-b2c-in-china/

涙ぐましいフィードバック
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/20208730-add-japan-region-to-data-residency-location-of-azu
⇒Unplannedという悲しい状態のまま放置されています

◆これまでの回避手段

データの保管場所の問題はもちろん日本だけの話ではなく、特に政府・行政系のシステムにAzure AD B2Cを採用するケースではディレクトリ上にはPII(個人情報)を置かずにREST API連携などを使って他のデータベースに逃がす、などの手段が取られてきました。
ただ、全体としての可用性を担保しようとするとそれなりにお金がかかったり、カスタムデプロイとなるのでメンテナンスが面倒くさい、といった問題が残るためいわば最後の手段でした。

◆今回のリリース(?)の内容

ひっそりドキュメントが更新されています。

https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/active-directory-b2c-reference-tenant-type

日本を選択するとデータはアジア太平洋に保存される、と明記されています。

実際にディレクトリを作るとき、リージョンに日本の選択が出来るようになっています。


作成するとasiapasificに配置されます。


とりあえずはアナウンス待ちですね。

2019年9月24日火曜日

Consumer Identity World USA 2019に登場します

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

今週からシアトル~サンフランシスコ(というかマウンテンビュー周辺)です。

今回は9/25~27にシアトルで開催されるCIW(Consumer Identity World) USA 2019でお話し、その足で翌週マウンテンビューのComputer History Museumで開催されるIIW(Internet Identity Workshop)に顔を出してきます。

最近の私の個人的テーマがBYOID(Bring Own Your Identity/自前のIDの持ち込み)とDID(Decentralized Identity/分散台帳上でのIdentity)でして、最近の各種カンファレンスでも色々とお話させていただいていますが今回もその一環です。

最近はこのようなカンファレンスだけではなく実際の商談でも色々と手を変え品を変えてこの世界観の定着を試みているんですが、まだまだ浸透してくるのは先のような気がしています。パスワードレスのような利便性の話や、eKYCなどアイデンティティの真正性の証明など色々と違った切り口で有用性もあると思うので、引き続き啓発活動が必要ですね。


さて今回ですが、B2B/B2Cなど外部IDの管理の面倒臭さBYPODとeKYCで簡素化する方法の案についてお話させていただきます。


概要は以下のような感じで、Azure AD B2CとuPortを使ったB2Bシナリオで社員証を使った身元確認によりパートナー向けWebサイトへのID登録のBYOID化、というデモもお見せできればと思います。

タイトル:
 Boost your B2B/B2C scenario with BYOID + eKYC using Decentralized Identity
概要:
 Managing external accounts such as suppliers in B2B or consumer account is painful problem for IT administrators. In this presentation, I'll show you our scenario and demo to make it easy to manage external identities powered by BYOID + eKYC. e.g. Sign-up social media account and proof their identity using driver's license as verifiable credentials in the identity wallet.

 Key takeaways:

  1. Best practice of managing external identity on supply chain management scenario with BYOID+eKYC approach.
  2. How the Decentralized Identity approach is used in eKYC process.
  3. Implementation details of the scenario, Azure AD B2C, uPort.


また、唐突に主催のKuppingerColeからアサインされたんですが、パネルディスカッションにも参加する予定です。
最近の自己主権型アイデンティティやDID周りで色々と情報交換をさせて頂いていて今回CIWのKeynoteも担当されるKristina Yasudaさんと一緒です。
プレゼンはナントカ乗り切るだけの「慣れ」という名の精神力(英語力ではない)は身についてきましたがパネルは何が出るかわからないのでかなりビビってます。最後の手段はKristinaに通訳してもらうか・・・w


帰国後も登壇続きなので、その準備をしつつ商談もこなしつつというハードコア出張に今回はなりそうですが、新しいネタを色々と仕入れてこれそうなので可能な限りレポートしていこうと思います!

2019年9月21日土曜日

iOS13でSign in with Appleがようやく使い物になってきた

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

色々と騒動もあってついつい忘れがちなSign in with Appleですが、先週iOS13が正式に出てきてようやく使い物になってきました。
iPhone11は・・・ボトムズですよね。買ってません。

Sign in with Appleとは

いわゆるAppleのOpenID Connect実装です。iPhoneやMacを持っている人は必ず持っているApple Idを使って自前WebサイトなどへOpenID Connectを使ってログイン出来るようになります。
6月のWWDCで発表されて結構盛り上がりました。と、どうじにOpenID Connectの実装内容についても色々と意見がついてプチ炎上?してました。最近まともになっているようですが。
私もAzure AD B2CやAuth0へ組み込んでみたりしました。

 Azure AD B2Cへの実装
  https://idmlab.eidentity.jp/2019/06/sign-in-with-appleid-ad-b2c.html
 Auth0への実装
  https://idmlab.eidentity.jp/2019/06/sign-in-with-appleidaasauth0.html

8月頭には idcon でSign in with Apple特集も開催され一瞬で定員をオーバーするなど、注目度も結構高かった記憶があります。

iOS13未満の環境での課題

Sign in with Appleが発表された当時、まだiOS13はβ版でしたので人柱になっている人たち以外の一般人はあまり恩恵を受けられませんでした。
と、言うのもSign in with Appleでログインを行う都度、メールアドレス+パスワードの入力に加えてiPhoneへワンタイムコードが飛んでくる、という実装で、せっかく同じApple IdでログインしているiPhoneやiPadでも再度認証が要求されていたためです。

こんなUXでした。

iOS13からのUX

OSに統合されたのでTouch IDやFace IDでそのままログイン出来るようになりました。
素晴らしい!


日本人はiPhoneが大好きなので各種WebサイトのSign in with Apple対応も今後進んでくると思います。(みんながiOS13以上になるのがいつか?という話はありますが)

2019年8月14日水曜日

Auth0がLINE Loginに対応しました

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

先日のCEO訪日もあり色々と盛り上がっているAuth0ですが、訪日時にCEOが宣言した通り、LINE Loginに対応しました。

これまでカスタムコネクタで設定していましたが、これからはスイッチONしてclient設定をすれば使えるようになります。便利です。

ちなみに過去に投稿したカスタムコネクタでの設定方法はこちらです。
 https://idmlab.eidentity.jp/2019/01/auth0line.html


設定は非常に簡単なので解説するまでもありませんが、ざっくりと。


ConnectionsからSocialを開くとLINEのアイコンがありますのでクリックすると設定画面が開きます。



LINEの管理コンソールからChannel ID(=client_id)、Channel Secret(=client_secret)を取ってきます

Auth0側の設定画面に取得したclient_idとclient_secretを設定します

ちなみに、LINEからメールアドレスを取得したい場合は、Auth0の画面でEmail addressの項目にチェックを入れ、かつLINE管理コンソール側のOpenID Connect設定でemail属性を取得できるように申請、承認される必要があります。(私はすぐに承認されました。皆さんがすぐに申請されるものかどうかはわかりませんが)
ここまで設定すればAuth0側はおしまいですが、LINE管理コンソール側にCallback URL(redirect_uri)を設定しておく必要があります。設定するのは、「https://{テナント名}.auth0.com/login/callback」です。
ちなみに、LINE側で良くハマるのが、チャネルを作って設定したのに公開していない、というケースなので、上の図の右上の公開/非公開の部分が公開済み(Published)になっていることを確認しておいてください。


これですべて終了です。
Auth0で「try」をクリックするとLINEログイン(初回は属性提供のための認可画面)が出てきて、認可を行うとログインができます。

尚、その後メールアドレスの確認のためのメールが届きますので、VerifyをクリックするとAuth0上のメールアドレスについても確認済みのフラグが付きます。

ちなみにLINE Loginのクセなのですが、メールアドレスはid_tokenから、その他の属性はprofileエンドポイントから取得するのでAuth0のクセとの相性的に「try」の結果のjsonにはメールアドレスが載ってきません。


Auth0上に登録されたすべての属性を見たければユーザを開いて、Raw Jsonを見るとどんな属性が登録されているかがわかります。

メールアドレスもちゃんと取れてますし、うまく動いていそうです。
(実はクローズドベータの時はメールアドレスがうまくとれてなかったんです・・・)

2019年7月2日火曜日

MVP Renewal 10th!!

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

遂に10年目に突入してしまいました。
今年もEnterprise Mobilityの領域で受賞いたしました。

昨年からLINE API Expert、Auth0 Ambassadorとの平行、かつOpenIDファウンデーション・ジャパンでは理事を拝命した中での活動となっており、色々な場面で登壇させていただくことは増えた一方でBlogなどの書き物としてのアウトプットをする体力が残っていない状態が続いていますが、e-KYCや信用スコアなどビジネス面での新しい潮流や、DID・自己主権型アイデンティティなど新しい技術への注目が集まるなど、まだまだアイデンティティの分野ではやることが山積されている状態なので、引き続き活動をしていきたいと思います。

ということで、今後ともよろしくお願いいたします。

2019年6月29日土曜日

Identiverse 2019参加メモ(Day4)

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

いよいよ最終日です。
割と毎日みっちりとセッションを聞いたので、かなりの疲労度ですが何はともあれようやく最終日です。

初日から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みたいに)
    • その他

  • 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日間に渡ってお伝えしてきた日記もおしまいです。

ちなみに午後はペンタゴンの側のショッピングモールに行ってきました。屋上からペンタゴンが見えたので写真を撮りましたが上空から取らないとなんだかわかりませんね。。。


2019年6月28日金曜日

Identiverse 2019参加メモ(Day3)

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

いよいよ3日目です。そろそろ疲れてきました。
これまでの日記はこちらから。



ということで今日もはじめて行きます。
まずはキーノートから。

◆キーノート

  • Digital Identity for the People by Richard Bird
    • Chief Customer Information Officerの人
    • 人々が自分のアイデンティティをデジタル社会に持つ時代になってきた
    • シートベルトなどと同じく、Consumer保護の考え方はデジタル社会が始まった当時は存在せず、後からポリシーがついてきた
    • GDPR、CCPAは果たしてConsumerの保護になっているのか?
      • 現実問題、施行後にも4億以上のアカウント漏洩が発生している
    • では何が足りないのか?
      • データ保護≠アイデンティティ保護
    • 結局のところ、アイデンティティの保護は人を守ること
      • いくらそのリンクをクリックしてはいけないと言ってもクリックする
      • 現実の数字として、
        • US国民の20%が家に鍵をかけない
        • 63%の強盗は押しいらなくても犯行ができてしまっている
    • デジタル社会で自分を守るということは?
      • データ保護とアイデンティティ保護は同一ではないことを認識する
      • MFAなどでアイデンティティを守ることが必要


  • Digital Identity - A Strategic Imperative by Grant Schneider
    • US FederalのCISOの人
    • 資料なしのプレゼンだったのであんまり拾えてないです
    • アイデンティティ管理はセキュリティのために非常に重要なものであると考えている
    • US連邦のサイバーセキュリティ戦略目標はデジタル社会におけるナショナルセキュリティと経済的なセキュリティを高めること、つまり「いかにして国家と国民の資産を保護するか」が命題
    • そのために、色々と守らなきゃダメ
      • Federal Cyber Security(税金や年金など)
      • 重大インフラのセキュリティ(金融システムや交通システムなど)
    • CEOやCIOがリスクマネージメントをできるように教育することも大事
    • もちろんプライバシーも大事なので、ペルソナの使い分けなども意識しないとだめ
    • アイデンティティ保証も大事だよ
  • The next wave of Identity Standard by Alex Simons
    • アイデンティティに関する標準の3つの波
      • オンプレミス
      • クラウドとモバイル
      • 分権とプライバシー by デザイン
    • オンプレミスにおける相互運用性と利便性の向上
      • 全てがFirewallの内側にある前提
      • ESSO、LDAPの組み合わせによるPasswordインジェクション
      • KerberosによるトークンベースのSSO
      • このころの攻撃はSlammerなどサーバの脆弱性を狙ったものが多かった
    • クラウドとモバイルの世界のためのアイデンティティ
      • SAML:広く使われるようになった最初の標準技術
      • OAuth1.0:実装が難しかったよね
      • OAuth2.0、OpenID Connect:現在のマイクロソフトのソフトウェアはPowerPointからAzureまでこの標準に従っている
        • 2019年6月のデータではAzure ADに接続されているアプリケーションの95%がOAuthもしくはOpenID Connectを使っている
      • このころになると攻撃手段が変わってきて、パスワード盗難がメインとなってきた
        • 81%のデータ漏洩の原因がパスワード盗難に起因している
      • こうなると多要素認証が必要となる
        • FIDO2。すでにWindows10やAndroidは準拠している
      • 次はパスワードレスの時代へ向かっている
        • Azure ADのパスワードレスのデモ(YubikeyでOffice365ポータルへログオンしてます)
        • 2019年7月にようやくAzure AD+FIDOのパブリックプレビューがリリースされる
        • 現状8億のユーザがパスワードレスを有効化している
        • 月間8500万ユーザがパスワードレスでログインしている
      • Token Binding
        • TLSだけじゃない
        • dPOPも
      • SCIM
        • 2019年6月のデータでは675万ユーザがSCIMでプロビジョニングされた
        • Mark Wahlが新しいSCIMのプロファイルを提案している
    • 分権とプライバシー by デザイン
      • 全ての人が自分のアイデンティティを自分でコントロールできる世界へ
      • DIDのデモ(昨日と同じもの) by Ankur Patel
      • まだまだこれから
    • とりあえず、今すぐやるべきこと
      • OpenID Connect、OAuthを使いましょう
      • モダンプロトコルに対応しましょう
      • パスワードレスの時代です
      • とにかく多要素認証を有効化しましょう。99%のID盗難は防げるよ

  • Standards: The Bedrock of Identity
    • パネルディスカッション
      • モデレーター:Pamela Dingle
      • パネリスト:Kim Cameron, Vittorio Bertocci, Brian Campbell, Annabel Backman
    • パネルはきつい。。。あんまり拾えてないです
    • それぞれがフォーカスしている/してきた標準仕様について紹介
    • そういえばVittorioはws-*の人だったなぁ
    • 標準化関連のミーティングはグローバルのあちこちで開催されるのは、みんなに参加してもらいたいから
    • しかしSAMLはなんで800ページにも及ぶ巨大なモノリスになってしまったのか
      • 何にでも対応できるように色々と組み込んでしまった
      • 結果、拡張が難しい巨大な仕様になってしまった
    • その反省を踏まえ、OAuth、OpenID Connectではシンプルなことをシンプルに実装できるように、という原則に則って設計をした
    • SecEventの話し。
      • SSOの世界ではリスクが顕在化した時にドミノ現象で伝搬してしまうので、リスクイベントの標準的な伝達方法が必要となった
    • プロトコル設計をする時はシンプルにすることが大事
      • DIDとOIDC、FIDOを組み合わせることで使いやすい姿を模索するなど
    • これからこの世界をドライブしていこうとしている人たちへメッセージは?
      • 標準化の世界へぜひ参加して
      • コミュニティへ参加すること。メーリングリストがあるので、そこでユースケースや考えたことを共有するところから。Don't be shy!
      • 言語の壁もあるかも知れないけど気にするな

◆ブレークアウトセッション

  • The Identity Architecture Panel
    • パネルディスカッション
      • モデレーター:Barber Amin
      • パネリスト:Kristina Williams, Greg Smith, Stephanie Kesler, Kim Cameron
    • やっぱりパネルはきつい・・・
    • ゼロ・トラストの世界。ブロックからモニター、緩和へ
    • 企業は従業員にとってのIdentity Providerが、管理者はSAMLを知っているわけではないし、我々(IDaaS事業者)はインフラの形を変え管理者が何もしなくても良い世界を作ろうとしている
    • プライバシーはコンシューマだけでなく従業員にとっても非常に重要
      • CIAMのアプローチでは管理者はアイデンティティを管理することができない
      • エンタープライズIAMの世界では管理者が従業員のアイデンティティを管理する
      • コンテキストに合わせた柔軟なユーザージャーニーが必要である
      • マイクロソフトは固定的なログインを柔軟にするためにIdentity Experience Framework(IEF)を提供している
      • IEFを使えば、コンテキストに合わせた柔軟なユーザージャーニーを提供することが可能である
      • 例えば、HRシステムの重要なデータへアクセスする際は追加の認証を要求する、なども考えなければならない
    • どのようにして開発者にプライバシーを保護を意識させるのか?
      • 教育なども重要
      • データの分類と評価がまずは大事
    • 昨年、テレコム企業の課金システムのリプレイスを行なった
      • アーキテクチャの全面書き換えを行った
      • 保護されたAPIやデータへのアクセスをトークンを使って制御することにした
    • CCPAがあるけど、何かアドバイスは?
      • まずはデータを特定して分類するところから始めましょう
    • DIDについて
      • iPhone上のデータは誰の持ち物?Appleもデータのコントロールできちゃうよね
      • 個人データは借財。これは長くは続かない。DIDとかブロックチェーンが解決の糸口になるかもしれない
      • 5年から10年くらいはかかるかな
    • 今後我々はどんなテクノロジーをキャッチアップしていけばいい?
      • AI(プライバシーも考慮して)
      • FIDO2
      • コンテキストに合わせたユーザージャーニー(IEF)
      • マシンラーニング
      • Decentralized Identity

  • Blurring the boundaries between CIAM and IAM / Microsoft
    • アイデンティティはセキュリティの要である
    • 社内外とのコラボレーションのあり方の変化
      • B2Bシナリオ
        • パートナー側でアイデンティティを管理する
        • つまりBYOID
      • B2Cシナリオ
        • セルフサインアップ
        • 同じくBYOID
    • こうやってみるとB2BもB2Cも同じ
      • アカウントを作って
      • 承認して
      • アクセスできるようになる
    • 共通しているのは人を中心に据えていること
    • サンプルケース1
      • 個人が複数のロールを担うことがある(不動産のオーナーだったり、売主だったり、従業員だったり)
      • 一つのGoogleアカウントでサインアップ〜サインインする(Azure AD B2B)
      • システム側でロールを切り替えられるような実装をすることで、役割ごとにユーザアカウントを個別に作る必要がなくなる
    • サンプルケース2
      • 大学のケース
      • 入学希望して、受験生となって、学生になって、卒業生になって、大学院に入ってまた学生になって、学校に就職して職員となって。。というライフサイクル単位でアカウントを作るのではなく、一つのアカウントの状態を変えていく
    • 共通するのは、一つのアカウントを関係性に応じて変化させていく、という考え方

  • Identity Proofing - What Happens Before Authentication by Capital One
    • Identity Proofingとは
      • 個人に関する情報を集めて検証するプロセス
      • アカウントをオープンする時に実行したりする
      • 認証とは異なる
    • なぜIdentity Proofingが重要なのか
      • 認証して認可してシステムやデータへアクセスさせるが、そもそも「誰?」という部分を知らなければならないため
    • NIST SP800-63Aにおける定義
      • Resolution
      • Validation
      • Verification
    • Identity Assurance Levelとは
      • 検証に使うエビデンスと方法の品質
    • 企業におけるシナリオ
      • 雇用時
        • バックグラウンドチェック
        • 対面での書類確認
        • 初期クレデンシャルの発行
      • クレデンシャルのリカバリ時
        • パスワードレスのシナリオの場合
        • 免許証などのドキュメントをビデオ会議で見せて確認する
    • コンシューマの世界におけるIdentity Proofing
      • スピードと正確性とコストが大切
      • 時間がかかると顧客はドロップしてしまう
    • 色々な方法
      • モバイルデバイスを使った確認
        • SMSへのコード送信
      • ドキュメントを使った確認
        • 券面のスキャン、バーコードのスキャン
        • 券面のスキャンはPhotoShop対策も合わせて必要
    • リスクベースアプローチが必要
      • Identity ProofingはRiskスコアと同義でもある
    • まとめ
      • 一般的にユーザが提供したり手動で入力した個人データは不正確である
      • システム横断で使えるRiskスコアが必要
      • データソースを増やして、検証の精度を高めるためには外部ベンダーとの協業が必要である(Capital Oneとか)

  • Frictionless Identity Verification by ADP
    • ADP自体はセキュリティの会社ではなく、HCMの会社
    • 40Mくらいのアクティブユーザー数がある
    • 次のチャレンジはユーザエクスペリエンスの改善
    • 現状、ADPのサービスに従業員がセルフ登録する方法は以下の通り
      • Federated SSO
      • Personal Code
      • Company Code
      • Codeless Registration(モバイル向け)
    • これまでIdentity Assuranceを担保するためにやってきたこと
      • Bot Protection(ロボットよけ)
      • AIベースのアイデンティティ確認
      • 知識ベースの認証
      • デバイスベースのリスク管理
      • 外部ベンダとの協業(Capital One)
    • 登録時のユーザージャーニーを整理し、70%のコンバージョンを実現した

  • So You Think You Can Two Factor by Nishant
    • 多要素認証を使う時
      • PSD2など法令により必須な時
    • 認証要素は非常に多岐にわたっている
    • これらを単純に提供するのは説明書なしで家具を組み立てさせるようなもの
    • どのように利用させる要素を考えるか
      • ユーザが使いやすいもの
      • コスト
      • 対応する脅威モデル
      • 効果
      • 法令遵守
    • 生体認証はセキュリティではなく、利便性のためにある
    • 生体情報(いわゆる身体的な特徴情報)はすでに必須ではない
    • ユーザの行動、デバイスID(Fingerpirnt)を使ったアノマリ検知も可能(機械学習ベース)
    • ユーザへの浸透(使い慣れているものを使う)
      • Googleは7年前から2要素認証を提供しているが利用している人は10%程度だった
      • Yubikeyに対応したら登録者が増えた、なぜならYubikeyを使っている人が増えたから
      • ユーザはリスクを理解しているわけではない
      • Googleは2要素認証を強制はしていない。なぜならサービスを使わせたいから
    • オムニチャネルの検討
      • UX向上の別の例
      • コンタクトセンターでの認証をスマホで行う、などチャネルを分離することによるUX向上とセキュリティ向上の両方を実現
    • プロセス自体の検討
      • 付与
        • 第1要素を付与する時に同時に2要素目の登録を行う
        • 間が空くと弱いタイミングができてしまう
      • バックアップを取得する
      • 緊急避難のパスを作っておく
      • リカバリプロセスを作っておく(例えばSMSや免許証での検証など)
      • 第2要素の破棄の方法を考えておく
    • まとめると以下が大事
      • ちゃんと使えること
      • 複数の方法を用意しておくこと
      • ユーザが受け入れられること
      • オムニチャネルの検討
      • 管理プロセスの検討

  • Why Governments are still important even in a Self-Sovereign Context by Adam Cooper
    • 近い将来、デジタルアイデンティティが人々のプライマリのIDになったと仮定するとどうなるだろうか
    • 政府機関の役割
      • 法律を整備する
      • アイデンティティドキュメントを交付する
      • 住民登録データを記録・保管する
    • SSIやDIDのような新しい仕組みはそれらの役割を代替するものではなく、相互運用するものである
    • 実際にアイデンティティを使う際にはアイデンティティそのものよりも適格であるかどうかの方がはるかに大切である
      • 例えば、支払い能力はあるか、など
    • そうなると、政府機関の提供するアイデンティティはトラストの源泉としての役割を持つ
    • 個人は自身のアイデンティティを提示する際に、信頼できて検証可能であることを望む
    • つまり、ポータブルで信頼に裏打ちされた状態において、自身でアイデンティティの管理を行える状態が望ましい
    • 結局トラストフレームワークが鍵となる

  • Developing World Identity
    • パネルディスカッション
      • モデレーター:Jeremy Grant
      • パネリスト:Adam Cooper, Vyjayanti Desal, Kaliya Young
    • ID4Dの取り組みの紹介(World Bank)
      • LIC(Low Income Countries)にフォーカスしている
        • ペルー、インド、パキスタン、タイなどで活動
      • デジタルIDは全ての基盤となる
        • Financial Inclusion
        • Healthcare
        • Women's Empowerment
        • Social Protection
        • Education
      • 他にもペーパーレス・トランザクション(Paymentなど)を行う上でも必要なものである
      • ID4Dの3つのアプローチ
        • Thought Leadership & Analytics
        • Country & Regional Action
        • Global Platform & Convening
      • 啓発活動を含め各種ドキュメントの発行なども行なったり、原則をプラクティスへ落とし込む活動をしている
      • グローバルで一つの大きなIDシステムを作ろうとしているわけではなく、各国がオープンなIDシステムをもち、相互運用性を持てるような世界を目指していく
    • Aadhaarの話(Kaliya)
      • 2000年代初頭、IDシステムをどうやって変えていくか考えた
      • 国民を登録する台帳は存在、ローカルガバメントが誕生・死亡の登録を管理していた
      • Nandan Nilekani氏が閣僚となり、インドのユニークIDのオーソリティを作ることとなった
      • 最低限実行可能なID基盤として以下をもつ
        • 名前、生年月日、性別、住所
        • 生体情報(写真、2つの虹彩情報、10の指紋情報)
        • (ボーナス。必要か?)電話番号、メールアドレス、銀行口座情報
      • 登録時はセントラルレポジトリへデータが送られ、ユニーク性のチェック後、IDが発行され、カードが送付される(なんのセキュリティ機能もないカード)
      • Aadhaarを使った認証の方式
        • Aadhaar番号と名前、住所
        • Aadhaar番号と生体情報
        • Aadhaar番号とワンタイムパスワード
        • Aadhaar番号と多要素認証
        • (KYC時は)Aadhaar番号と生体情報+eKYCドキュメントの名前と住所
      • 問題点
        • 住民のゴールデンレコードができてしまう
        • セキュリティ保護されていないカードが存在する
        • 地方の支局に行くと生体情報の確認ができないことがある
        • ワンタイムパスワードを使おうとしても携帯電話番号を持っていない人がいる
      • 良い点
        • みんなが持っている
        • ユニバーサルである



と、本編はここまでです。
この後、イベントのFounderであるPing IdentityのCEO、Andre主催のパーティに参加してきました。Newseumという報道関係の博物館を貸し切っての大イベントでした。
ちなみにベルリンの壁とかがありました。
しかし何と言っても目玉はID厨だけで構成されているバンド、ZZAuthです。
メンバが以上に豪華です。Eve Malar, Justin Ritcher, Alex Weinert, Pamela Dingle, Sofia-Cristineなどなど・・・





ということでいよいよ次回は最終日です。

2019年6月27日木曜日

Identiverse 2019参加メモ(Day2)

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

昨日に引き続きワシントンDCで開かれているIdentiverse 2019への参加メモです。
※Identiverseとはなんぞや?という方は昨日のポストをご覧下さい。

2日目となる本日はKeynoteから始まるある意味本格的にイベントがスタートする日でした。しかしイベントをホストしているPing IdentityのCEOのAndre Durandさんのパワーはすごいですね。10年間この規模になるまでイベントを続けている気力もそうですし、毎回どこからともなく物凄いゲストを連れて来ているのが驚きです。以前はレオナルド・ディカプリオ主演の映画「キャッチ・ミー・イフ・ユー・キャン」の主人公のモデルとなったフランク・アバグネイル氏が出て来て金融詐欺(まさにID盗難)についてKeynoteで語ってくれたりしましたし、今回の目玉はもちろんSteve Wozniak氏ですが、さらにKeynoteスピーカーとしてイリノイ州議員のBill Foster氏が登場してデジタル・アイデンティティについて語る、という豪華なKeynoteから始まりました。

と言うことで2日目のおさらい+αをお届けしたいと思います。

◆キーノート

  • Weathering the Storm: Future Proofing with Identity by Andre Durand
    • Internetとmobilityの発達により、いたるところにアプリケーションが組み込まれる時代となった結果、脅威もいたるところに存在する、と言う状態となっている
    • このようなDisruptionに対して効果的に適応して生き延びていくには重大かつ予測可能な領域を見据えて効率的に投資をしていく必要がある
    • 例えば、自然現象を整理すると以下のように分類可能である
      • メキシコに落下した隕石による破壊は重大だが予測不可能だった
      • 竜巻による破壊の重大性はそれほど大きくなく、かつ予測も難しい
      • 嵐の重大性はそれほど大きくないが、予測はある程度可能である
      • 大型台風による破壊の重大性は大きく、予測も可能である
    • 我々はこの中の重大性が高く、予測可能な領域(大型台風)へ投資を集中しなければならない
    • 例えばこの領域としてあげられるのが、以下の項目である
      • イノベーションの速度
      • カスタマー体験
      • プライバシーとコンプライアンス
      • スマートなアイデンティティ(AI)
      • 境界の消滅
    • それぞれに対する対応は以下の通りである
      • イノベーションの速度
        • 基本方針はAgilityを持つこと
        • 標準に対応する
          • 使うもの;SAML、OAuth、OpenID Connect
          • 投資するもの:SCIM、PSD2、OpenBanking
          • 新しく出て来たもの:WebAuthn、Secevent
        • APIを有効活用する
        • クラウドを活用する
      • カスタマー体験
        • UXの質により顧客が支払う額は変わってくる
          • 86%の顧客がより良いカスタマー体験に対して支払う
          • 82%の顧客が貧弱なカスタマー体験により去る
        • アイデンティティに関する良いカスタマー体験とは、フリクションレスでパーソナライズされた世界のことである
        • より良い体験とは体験していることに気が付かないことである
          • パスワードレス:QR、NFC、BLE
          • 標準:WebAuthn、OpenID Connect
          • ウェアラブル:AppleWatch
      • プライバシーとコンプライアンス
        • FacebookやMicrosoftなど事故もあったけどコンプライアンスが重要って言っている
        • 同意の管理が主なキーワードとなる
      • スマートなアイデンティティ(AI)
        • 過去4年間で270%の成長を見せた
        • センサーとシグナルをスマートなアイデンティティ(Intelligent Identity)により機会と脅威に分類、パーソナライズした世界を実現することができる
      • 境界の消滅
        • クラウドの台頭、デバイスの普及によりネットワーク境界は消滅、アイデンティティが境界となっている
        • アイデンティティによりゼロトラストセキュリティを実現することができる
    • 結局のところ、勝者となるには以下のことが必要
      • ディスラプションを予測・理解する
      • 何が起きるかを予測する
      • プロアクティブにディスラプションを乗りこなす
    • 波を乗りこなしましょう!

  • Aspiring the Future by Bill Foster
    • 元々は科学者で議員
    • 議員の出身を科学者、法律家、政治家の3つに分けると、
      • US議会には科学者がほとんどいない
      • 中国の議会には科学者出身者が多い
      • EUはバランスが良い
    • 科学者の頃は陽子の減衰の研究をやったり、加速器を開発して衝突の観測をしたりしていた
    • 両親がキャピトルヒルで出会った、という過去もあり政治の道へ(科学と政治がUNIONIZED)
    • 2006年に秘書としてキャリアをスタートし、2008年に初当選した
    • セキュアなデジタルアイデンティティは重要である
      • オンラインセキュリティの要であると考えている
      • Fintechなどのテクノロジーに必要である
      • USはエストニアや韓国に対して後塵を拝している
    • 先般、大きな勝利を収めた
      • 電子健康レコードからユニーク識別子を消す、ことを廃止できた
      • 過去21年間にわたり、連邦はユニーク識別子を消して来た
      • このことにより毎年数千人が亡くなっていた
      • また、医者が麻薬を購入することが可能となっていた
    • 米国政府はデジタルアイデンティティの重要性を理解して来ている
      • 誰もJUNKやSPAMを望まず
      • 政府は個人の識別子を付与する役割を持つ
    • これからはAIが搭載されたスマートフォンが普及してくる
      • 多要素認証デバイスとしても利用できる
      • PIIを持ち運ぶこともできる
      • 選択的開示がもっと浸透してくる



  • Next Generation IDM: managing identities for people by Andrew Nash
    • おなじみAndrew Nashのセッション
    • アイデンティティ管理の歴史を振り返りつつ未来を語る
      • LDAP、X.400・・・
      • Identrus、Federal CA・・・
      • MS Passport、SAML、Liberty、Hailstorm・・・
      • OpenID、Infocard、7 Laws of Identity、PayPal・・・
      • OIX、OpenID Connect、NSTIC・・・
    • アイデンティティ情報は新しいユーザ体験の時代へ
      • CapitalOneのアカウントで他のサービスへサインアップ
      • 免許証で他のサービスへサインアップ
    • 新しいアイデンティティの姿とは
      • 自分の情報を
      • 自分のデバイスで
      • 同意に基づき、最低限の共有を行うことにより
      • KYCコストを削減したり、Identity Verificationの最適化を行う
    • Identity Providerが中心の世界からユーザが中心となる世界へ


  • Building Identity Professionals by Sarah Squire
    • IDPro枠ですね
    • 基本的な考え方として希少価値の高いものは高価である
    • アイデンティティオタクも同様である
    • みんなアイデンティティオタクになろう!そして市場価値を高めよう
    • IDProのメンバにサーベイしたところ、41%がIdentityのプロになるには5年から10年はかかると回答した
    • 学校では教えてくれない領域なのでどうすれば良いのか??
    • プロジェクトマネージャーも同じような状況なので、調べてみると、1996年にPMBOKが出てからPM人口が一気に増加したことがわかった
    • そこで、IDPro Body of Knowledgeの作成に取り掛かった
      • 基本的な考え方は、対象の領域について自分よりも知っている人間は誰か?というアプローチ
      • 40のセクションと88のサブセクションで構成
    • 今ではたくさんの企業会員、個人会員に支えられている。Come an Join us!

◆ブレークアウトセッション

ここからはブレークアウトセッションです。
  • A Modern Architecture for Customer Identity Services by GM
    • GMのIdentityアーキテクトによるGMの顧客ID管理のアーキテクチャの解説
    • サービスと顧客を接続するためにアイデンティティを整備する必要性があった
    • しかし、アイデンティティは見えないくらいがちょうどよく、シームレスな顧客体験が重要であると考えている(Invisible Identity)
    • その考えのもと、CIAMを以下の4つのコンポーネントに分離してデザインした
      • Identity
      • Profile
      • Preference
      • Intelligence
    • IDaaSにするかOnpremにするか悩んだけどアタックへの対応などはIDaaSに一日の長があるのでIDaaS(Azure AD?)を選んだ
    • OIDCなどの標準に対応するのはもうすでにオプションではなく必須である
    • 結局大事なのは、
      • 標準を乗りこなす
      • 統制の効いたアーキテクチャをデザイン・実行する
      • 戦略と同期する


  • Bring Your Own Identity: A Skeptical look at Social Login and Single SignOn by Gerry Gebel
    • 元Burtonグループの人でBYOI(今でいうBYOID)のコンセプトを2008年に発表した人
    • モチベーションとしては、
      • 多くのクレデンシャルがサービス提供者によって管理されている状況がいやだ
      • 登録プロセスが面倒だ
      • UXの改善が必要だ
    • プライバシーに関する再考も必要
      • モダンなテクノロジー(スマホなど)
      • Techジャイアント(MSやUberなど)
    • Identity/Credentialの集中化により容易になってしまうこと
      • トラッキング
      • 紐付け
      • データコントロールの弱さ
      • 透明性の欠如
      • 監視
    • 実際、US連邦政府による電話のモニタリングとかあったよね
    • 最近は進歩したのか?
      • VerizonやAT&Tは顧客データを売るのをやめた
      • Apple login?
      • UMA、SSI
    • 今、できることは?
      • アイデンティティとCredentialを分離する
      • Techジャイアントからログオフする


ここから午後のセッションはお休みしてスミソニアン博物館へ出かけました!

◆(おまけ)スミソニアン博物館(航空宇宙博物館)

スミソニアン博物館ってライト兄弟のイメージしかなかったんですが、一つの博物館を指しているのではなく、博物館群を指しているそうです。知りませんでした。今回は時間もなかったので航空宇宙博物館へ行ってきました。

入り口

入り口を入った瞬間にスタートレックがあるのはご愛嬌

月面着陸艇のレプリカ

ライト兄弟のフライヤー号!

他にも色々ありましたが、この辺りで。
しかし日差しが強く、外はものすごく暑かったです。。

◆夕方からのブレークアウトセッション

夕方になり、セッションへ復帰しました。
  • Microsoft Presents: Designing for Decentralized identity and claim-based identity management by Ankur Patel
    • IONの話です。デモもあり面白かったです。
    • 感じている課題感としては、アプリケーション毎にUsernameとパスワードを保持していることによる不便さや結果発生する漏洩、監査が困難になることによる余計なコストの発生など
    • カスタマーのニーズを追っていくとそれぞれ以下のテーマがある
      • 個人
        • プライバシー
        • 個人でデータをコントロールしたい
        • 情報漏洩から保護してほしい
      • 組織
        • 信頼できVerifyできるアイデンティティ
        • コラボレーション(B2BのID管理は大変)
        • GDPR、KYC、AMLのコストを削減したい
      • 政府
        • クロスボーダー、クロスエージェンシーのID
        • 難民向けのID付与
        • 社会的、経済的なインクルージョン
    • IONを使ったデモ
      • シナリオは、
        • 学位の付与(学生証)
        • 学割で本が購入できる
    • IONの設計思想
      • ユーザは一つ以上のDIDを持つことができる
      • DIDはDLTの系をまたいで解決できる必要がある
      • DIDのパーミションはユーザだけがアクセスできる鍵により管理される
      • 属性情報はオフチェインに保存される
      • ユーザは複数のIdentityHubを持つ
    • 次のステップ
      • 簡単に使えるようにする:エコシステムの構築
      • 性能とスケーラビリティ:IONがまさに目指すところ
      • DIFへの参加とコラボレーション・コントリビューション




ここまでです。

この後、OpenID Foundation x Financial Data Exchangeの会食があり参加させてもらいましたが、みなさんAPI保護、KYCなどについて熱く議論をしていて非常に面白かったです。この辺は書けませんが。

後、会食からの帰り道にホワイトハウスも眺めてきました。
G20でトランプ大統領は大阪にいるはずなので、入れ替わりだな・・・とか思ったりしつつw
夜なので、あんまり綺麗に写りませんでしたが。


ということでまた明日。