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

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

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

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

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

ということで、あっという間に来週の開催になってしまいましたが、12/5～6にIgnite Tour Tokyoがあり、こちらでAzure AD B2C + SSI/DIDの話をすることになっています。
基本的には前のde:codeやEuropean Identity & Cloud ConferenceやConsumer 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


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

ベースはこの辺りなので、事前に目を通しておいていただけると理解がはやいかも。
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


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

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に配置されます。


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

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に通訳してもらうか・・・ｗ


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

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以上になるのがいつか？という話はありますが）

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を見るとどんな属性が登録されているかがわかります。

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

MVP Renewal 10th!!

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

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

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

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

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にできるかどうか、、など
• デモ１
• WorkDayに従業員がログイン、Walletを登録する（QR読み込み）
• WorkDay側で従業員の証明情報（Verifiable Credentials）を発行すると、従業員のWalletにプッシュ通知がされ、Wallet上に情報が読み込まれる
• ATB Onlineのサイトで口座開設プロセスをスタートすると、QRコードが表示されるため、Walletで読み込むと先に発行された従業員情報を送信して良いか確認が入り、利用者が送信する属性を選択して送信するとATB Online側の開設プロセスが始まる
• ATB Online側の確認プロセスが終了すると、従業員のWalletに開設された口座番号の情報がプッシュ通知される
• 従業員がATB Onlineへログインする際は、発行された口座番号をサブミットするとWalletへ通知がくるので、承認するとログインが完了する（パスワードを登録していないので、完全にパスワードレスでのログインが実行される）
• デモ２
• 郵便局で検証済みの住所情報を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とクレデンシャルがそのまま使える
• 認可
• 見たものが全て、つまり今のままの権限を移行できる
• 簡単に使えるのか、色々と出来るのか、という軸で４象限で表すと、壁に突き当たる
• デプロイの壁（自前のデプロイの限界地点。スケーラビリティとか）
• ゼロから作るよりは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ベースのアイデンティティについてどう思うか？
• 我々の日々の行動を政府がトラッキング可能で利用可能な状態であること、に対して、ブロックチェーンを導入すればこれ以上データを取得されなくなる、というのはブロックチェーンを正当化する理由にはならないと思う

そして、来年の開催地は「デンバー」です！

非常に楽しみです！

ということで、４日間に渡ってお伝えしてきた日記もおしまいです。

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