2019年12月31日火曜日

年忘れはFIDOで!指紋認証付きのeWBM Goldengateを試す

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

世の中は大晦日ですが、今日になってeWBMさんよりGoldengate G310が届いたので軽く試してみます。

届いたのは、G310というFIDO2対応のキーです。
https://www.ewbm.com/security-keys/goldengate-g310/



韓国から直送で送られてきたっぽいです。
まだ日本のAmazonでは買えないので、直販サイトか米国Amazonで買うのがいいみたいです。
 直販サイト
  https://www.ewbm.com/store/products/goldengate-g310/
 米国Amazon
  https://www.amazon.com/s?k=ewbm+g310&ref=nb_sb_noss_2

定価は60ドルですが、直販サイトだと初回は45ドルで買えるみたいです。
(私はMVPのサードパーティ特典で頂きました)


なんだかキーばっかり増えちゃって微妙な感じですが、Yubikeyとの大きな違いは指紋認証機能があることですね。
キーだらけ・・・


やれることは正直他のFIDO2対応のキーと変わらないので、今更動きについて解説する必要もないと思いますので、先日のAXIES(大学ICT推進協議会)の年次大会でお見せしたG SuiteへAzure AD B2C+FIDO実装を使ってパスワードレスでログインするデモを張っておきます。



最大の特徴の指紋登録ですが、以下の2通りの方法で設定できます。
1.公式のツール「Goldengate BioManager」を使う
2.Windowsのアカウント設定を使う

それぞれ簡単に。
まずは公式ツール「Goldengate BioManager」を使う方式から。

ツールはこの辺りからダウンロードできます。
 https://www.ewbm.com/support/BioManager/

ちなみにダウンロードしてセットアップしようとするとWindowsに実行をブロックされますが無視して進めます・・・

セットアップが終わりツールを起動するとこんな画面が出てきます。
言語の切り替えもできて、日本語も選べます。


次は指紋の登録です。

指紋追加を選ぶとタッチする様に促されるのでベタベタ触ります。


登録が終わると、登録済みの指紋以外でタッチしてもキーが反応しなくなります。
あと、PINが聞かれなくなります。
※指紋登録していない状態だと単純にタッチ+PINだけでサインインできる(Yubikeyと同じ挙動)が、指紋登録をすると登録していない指だとサインインできない。


ちなみに、2つ目の登録手段であるWindowsの標準の設定です。
設定⇒アカウントのセットアップから登録できます。

ちなみにWindows Helloの設定も同じ設定メニュー内にありますが、あくまでセキュリティキーの設定なのでここでセットアップしてもセキュリティキーでWindowsログインが出来るようになるわけではありません。もしOSログインにも使いたければ使うアカウントの設定をMicrosoftアカウントなりAzure ADアカウントなりで設定する必要があります。

指紋の追加は先ほどのBioManagerとほぼ同じです。




セキュリティキー+PINだけでは不安な方は指紋認証機能も付いているGoldengateも一つの選択肢となりえますね!

2019年11月30日土曜日

Hyperledger Indy, Ursa, Ariesのオンラインコースで自己主権型アイデンティティについて学習する

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

先日開催されたW3C/TPAC@福岡でDID WGが正式に発足したり、DIFやSovrin Foundationが活発に活動していたり、と自己主権型アイデンティティ(Self Sovereign Identity/SSI)や分散型アイデンティティ(Decentralized Identifier/DID)のムーブメントも本格化してきましたね。

そういえば@IdentityWomanことKaliya姉さんがおそらく世界初のSSIの本「A Comprehensive Guide to Self Sovereign Identity」を出版したのも今年の4月だったのでまだ半年ちょっとしか経ってないんですよね。


そんな中、元々Evernym~Sovrin Foundationが開発してきたSSIのための分散台帳技術でLinux Foundationの進めるHyperledgerプロジェクトの一員となったHyperledger Indyや、Wallet間のPeer to peer通信のプロトコルの標準化を進めようとしているHyperledger Aries、暗号化ライブラリであるHyperledger UrsaのオンラインのトレーニングコースがedXで公開されました。
※日本語記事あり:https://crypto.watch.impress.co.jp/docs/news/1220/815/index.html

HyperledgerファミリーとIndy, Ursa, Aries(出典:Evernym)

ざっくりいうと、Indyが分散台帳技術そのものであるのに対して、UrsaはZKP(ゼロ知識証明)などに使う暗号化技術、AriesはWalletやAgent間の通信に関する技術、という整理っぽいですね。(私もまだ勉強中なので間違っていたらすみません)

IndyとAriesの関係の整理(出典:Evernym)



ということで、もう少し深く勉強してみるいい機会なのでコースを受講してみようと思います。(せっかくなので受講証明がもらえる有料コース/99USドルにしました。12/2までならクーポンコード「CYBER20」を入れると20ドルくらい割引になります)

以下、コース登録までの道のりです。(実際の内容はこれからなので、また気づきがあれば書こうと思います)

1.edXのコースサイトを開く

こちらが今回のターゲットとなるコースのURLです。
https://www.edx.org/course/identity-in-hyperledger-aries-indy-and-ursa


ここからEnrollを押してスタートしていきます。

2.会員登録を行う

メールアドレスで登録するか、Facebook、Google、Microsoftアカウントでアカウントを作成します。


作成が終わると、有料会員に誘われますw。せっかくなのでお金を払ってみようと思います。

3.有料会員登録を行う

会員登録後、誘われるがままに登録をしてみます。

どうやら有料登録をすると色々と特典があるようです。(最後のは特典なのか?)

  • Unlimited Course Access
  • Graded Assignments
  • Easily Sharable
  • Support our Mission
「Pursue the Verified Track」で迷わず購入へ進めましょう。

左の中央に「Add coupon code」があるので先ほどの「CYBER20」を登録すると20ドルくらい安くなります。(12/2までらしいですが)
クレジットカードがPayPalで支払えますが、私はPayPalで支払いました。

購入が終わると登録者の本人確認が行われます。

4.本人確認を行う(eKYC!!)

方法としてはWebカメラで顔とIDドキュメント(パスポートや免許証など。名前と顔写真が一致していることを見るっぽいので、実質日本人で使えるのはパスポートだけだと思いますが)の写真を撮り1日~2日くらい審査があるようです。


まずは顔写真を撮ります。(黒線は筆者都合w)

次にパスポートの写真を撮ります。

両方揃えてアップロードして審査待ちです。



5.コースの受講を開始する

とりあえず登録はこれで終わりなので、ゆっくりコースを受講していきます。


コース目次は以下の通りです。ゆっくり学習していこうかと。

  • Welcome!
  • Chapter 1: Something Is Missing
  • Chapter 2: Adding a Layer of Trust to the Internet
  • Chapter 3: SSI Using Indy, Aries and Ursa
  • Chapter 4: A Blockchain for Identity
  • Chapter 5: The All-Important Agent, Or Rather, Agents!
  • Chapter 6: When Things Go Wrong
  • Chapter 7: Possibilities
  • Final Exam

なかなか興味深いです。





2019年11月29日金曜日

Ignite Tour TokyoでAzure AD B2C + SSI/DIDの話をします

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

あっという間に11月も終わりですね・・・

なんだか最近、月に2~3本の勢いでイベントでお話をしている気がします。おかげで色々と実験はしているもののBlogへのアウトプットが後手後手に回ってしまっていて反省です。

まぁ、その分講演の中では実験した内容を含めじっくりお話させていただいているつもりなので、是非機会があれば見に来ていただければ、ということで。

ということで、あっという間に来週の開催になってしまいましたが、12/5~6にIgnite Tour Tokyoがあり、こちらでAzure AD B2C + SSI/DIDの話をすることになっています。
基本的には前のde:codeEuropean Identity & Cloud ConferenceConsumer Identity World USAでお話してきた内容の続きではありますが、この自己主権型アイデンティティや分権型IDってキーワードが全くもってキャッチーじゃないので、地道に世界観を浸透させていくしかないのかな?と思っています。

ということでIgnite Tour Tokyoでは「分権型IDテクノロジーによる効率的な外部ユーザのID管理」というタイトルで「B2BやB2Cのシナリオにおいて外部アイデンティティの管理、特にIDの確認(KYCなど)は管理者にとって非常に頭の痛い問題です。本セッションではそれらの問題をAzure AD B2Cとブロックチェーンを使った自己主権型アイデンティティのシナリオでどのように解決するのかについて説明します。」という話をする予定です。

セッションコード:BRK30053
セッションURLはこちら)
https://tokyo.myignitetour.techcommunity.microsoft.com/sessions/87724


絶賛、過去のスライドをかき集めて準備中ですw

ベースはこの辺りなので、事前に目を通しておいていただけると理解がはやいかも。
de:codeの資料
 https://www.slideshare.net/naohiro.fujie/kyc-identity-on-blockchain
OSSコンソーシアムの資料
 https://www.slideshare.net/naohiro.fujie/kyc-153297605
didconの資料
 https://www.slideshare.net/naohiro.fujie/ssidid


では、当日お会いしましょう。

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などなど・・・





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