2019年4月26日金曜日

自己主権型アイデンティティとブロックチェーンの話し

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

ちょうど先日のidconでこの辺りの話をしたので、少し自分のためのおさらいの意味も込めて整理しておこうと思います。

まず背景として、昨年度から理事を務めさせていただいているOpenIDファウンデーションジャパンで、本人確認に関する新しいワーキンググループである「KYC(Know Your Customer) WG」を2019年1月に立ち上げ、WGリーダーを務めさせていただいております。
WGでは犯罪収益移転防止法や携帯電話不正利用防止法など各業界における本人確認のルールの調査や、Decentralized Identifier(DID)などの最近KYCと関連づけて語られる技術の調査をしたりしている訳です。
ちょうどパスポートの真正性確認に使う公開鍵を外務省が公開する・しない、という話が盛り上がっているあたりの領域です。

本人確認とアイデンティティとブロックチェーン

そして、何故かこの領域になると、自己主権型アイデンティティ(Self Sovereign Identity/SSI)とか、先ほど出てきたDIDだ、とかいうキーワードがどこからともなく持ち上がってきてやたらとブロックチェーンが銀の弾的に扱われてしまう、というのがID業界?の中の人としても結構な謎だったりするわけです。

そもそもブロックチェーンを仮想通貨以外にも適用しよう、という話は数年前からあり、例えば2016年のCloud Identity Summit 2016(CIS、現Identiverse)でもPingIdentityがSwirds社と提携してセッションの正当性の管理にHashgraphを使うPoCをやったりしていました。以前このブログでも少し紹介しましたね。

また、自己主権型アイデンティティという話もUser Centric IdentityとかDoc Sealsが提唱したIntention EconomyのVRMという形で以前からあった文脈と繋がっているものだと思われますので、特にブロックチェーンの出現によって新たに出現した話ではありません。

そして、当然の事ながら本人確認とブロックチェーンにはかなりの距離があります。ブロックチェーンが出てきたから本人確認が劇的に変わるわけでもなさそうですし。

ブロックチェーンで解決できるアイデンティティにまつわる課題とは?

となると、結局ブロックチェーンをアイデンティティの領域に応用することで何がうれしいんだろうか?という話になるわけですが、よく出てくる話としては、

  • プライバシーの保護
  • アイデンティティの証明

あたりがメジャーなのかな?と思います。他にも先のPingIdentity+Hashgraphでシングルサインオンのセッション管理を分散データベースとしてのブロックチェーンで行うことでシングルログアウト問題を解こうとした、というような話はありますがいまいち普及していません。(わかりやすいユースケースだったので個人的には良かったと思うのですが)

それぞれの話題を見ていくと何か見えてくるのか?と思うのですが、まだブロックチェーンの必然性が見えてきていないな、というのが個人的な感覚です。

プライバシーの保護とブロックチェーン

ここはまさに自己主権型アイデンティティという話なわけですが、課題意識としては、「個人が自分の意思でコンテキストに応じた自己像を提示できるようにする」、そして「個人の意思に反してコンテキスト外の自己像を推測されたり形成されたりしたくない」という話なので、必要なこととしては、

  • ユーザがアプリケーション(Relying Party)へログインする際に、Identity Providerへ認証要求を行うことによる、Identity Providerによるユーザ行動の把握を防ぎたい
  • ユーザがアプリケーション毎に提示するアイデンティティを選択的に形成したい(要はどの属性を渡すか、もしくは値そのものを渡さなくてもアプリケーションが要求している属性を満たすことを証明する)
  • アプリケーション同士が結託することで属性を補完しあって提示するつもりのないアイデンティティを勝手に形成されることを防ぎたい

というようなことなわけです。

こうなってくると、ブロックチェーンというよりもゼロ知識証明とか仮名(SAMLのnameid-formatのtransientとか、OpenID Connectのsub_type=pairwise)の方がしっくりくる領域です。今更ながら2012年くらいに盛り上がったU-ProveとかIdentity Mixerバンザイです。そういえば昔Kantaraのセミナで話したなぁ。

アイデンティティの証明とブロックチェーン

一方でアイデンティティの証明をするためにブロックチェーンを、という話については見方によってはある程度芽はあるのかもしれません。
ブロックチェーンの「一度記録すると変更しにくい」といういわゆるImmutabilityの特徴を考えると、一度発行した属性を過去にさかのぼって改竄する、というような属性値ロンダリングみたいな話は難しくなるのかもしれません。

経済産業省が主催で2月に開催されたブロックチェーン・ハッカソン2019では学位や職歴をブロックチェーンを使って確実に証明できないか?ということがテーマでした(私も審査員+ワークショップの実施という形でかかわらせていただき、非常に面白かったです)。つい先日、調査報告書も公開されたので時間がある方は見てみると面白いです。

ここはEthereum勢はERC725や735という形でこの領域に注目していて、OriginProtocolがPlaygroudを公開していたりもして、今後も発展していく可能性は十分にあるのかな?と個人的には思います。

しかし、よく考えると結局はアイデンティティの発行元がきちんと発行したアイデンティティである、ということの担保はこれまでもデジタル署名でしてきたわけで、ブロックチェーンがあるから劇的にこれが改善するわけではありませんし、ブロックチェーン上に発行されたアイデンティティ(属性の値)そのものを全部公開する、というのはあまりにも乱暴なわけです。

PKIを補完する意味でのブロックチェーン

そうなるとどうやって落としどころをつくるんだ?というだんだん本末転倒な話の方向に進んでくるわけですが、「あー確かにな」という課題の一つである「アイデンティティの発行元が消滅したり、発行元によってアイデンティティを否認や改竄されるリスクへの対応」というユースケースがにわかに持ち上がってくるわけです。

この辺りが、ID2020プロジェクトでUNHCRがMicrosoftとAccentureと共同でやっているような難民=国家(アイデンティティ発行者)によってアイデンティティを否認された人々の身元を保証するためにブロックチェーンを活用しよう、という話につながったり、先の経産省のハッカソンの大きなテーマである少子化に伴い教育機関がつぶれていくという予想がつく中で如何にして自分の学位を証明するか(要は卒業した大学が消滅してしまった場合に誰が卒業証明書を発行してくれるのか?)という話がブロックチェーンと繋がって出てくる所以だったりします。

確かに、国家等のアイデンティティの発行元によって自分のアイデンティティが消される、という緊急事態(プライバシーに優先するくらいの状況)において自分のアイデンティティを改竄出来ない状態にする緊急避難先としてブロックチェーンを選ぶのは確かに悪くないかも知れません。
また、同様にアイデンティティ発行者が消滅したとしても以前に発行されたアイデンティティ(署名されたアサーション)の検証をするための公開鍵をブロックチェーン上に保管しておけば、誰かが勝手に「過去にこの大学を卒業した。その証明はこのアサーションである。すでに誰も公開鍵を持っていないから署名検証は出来ないけどね」というようなことを言い張るというリスクへの対応は出来るでしょう。

ブロックチェーンも色々、標準化は?

ある程度ユースケースが見えてきたところで考えないといけないのは、ブロックチェーンも色々、という話です。EthereumもありますしBitcoinブロックチェーンもあります。またパーミッションドなのかパブリックなのか、などの分類も様々です。
そして最も重要なのはいかに耐改竄性が高いといってもブロックチェーンの系自体が消滅したりクローズする可能性は当然ゼロではない、というところです。

こうなると、

  • 特定の系に依存しない
  • 必要に応じて系を引っ越せる
ような仕組みというか標準を定めていく必要性が出てきます。

その辺りに取り組んでいるのがDecentralized Identity Foundation(DIF)というわけです。
ここでは主に、リファレンスモデルの策定やDecentralized Identifier(DID)や関連するメタデータ(DID Document)、検証可能なアイデンティティ情報の表現方法(Verifiable Claims/Presentation)などの標準化と、複数のブロックチェーンの系を跨いで存在するアイデンティティ情報のLookupをするためのUniversal Resolver(DNSみたいなもの)の仕組みを定義しています。

この辺りは、先日のidcon(didcon)でお話したので、こちらの資料を見て頂ければと。(まだ私の調査も浅いのと、DIF自体の定義も議論の途中で非常にふわふわした状態ですが)


当日のまとめはこちら

いずれにしても、この領域が今後どうなっていくのか?については興味深く思っているので、引き続き調べて行こうと思います。


2019年4月11日木曜日

[Azure AD B2C]各種エンドポイントにつくポリシー指定用パラメータが邪魔な件

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

完全に自分メモです。
Azure Active Directory B2Cって色々と器用なことが出来るのですが、その動作はポリシー(ユーザーフロー)という単位で定義され、クライアント(アプリケーション)から呼び出されます。
図)標準のポリシー(ユーザーフロー)定義

図)カスタムポリシー

サインアップとか、サインインとか、プロファイル編集などなど、各種動作を統一されたエンドポイントで実行するために、このポリシーを各種エンドポイントを呼び出す際、「https://hoge.b2clogin.com/hoge.onmicrosoft.com/oauth2.0/v2.0/authorize?p=B2C_1_XXXX」のようにクエリパラメータにp=ポリシー名という形でポリシーを指定して動きを変えていきます。

※ちなみにポリシー名のPrefixは、
・標準ポリシー(ユーザーフロー)だと、「B2C_1_XXX」
・カスタムポリシーだと、「B2C_1A_XXX」
です。

しかし、OAuthやOpenID Connectの非MS製ライブラリを使うとき、かなりの確率で問題になるのが、エンドポイントにクエリパラメータが付いた状態がスタート、というところです。

なぜなら、よくあるライブラリにはエンドポイントアドレスを設定、client_idなど各エンドポイントへのアクセスを行う際にクエリ指定するパラメータは個別に指定、ライブラリが自動的に
 https://hogehoge.com/oauth2/authorize?client_id=aaa....
みたいに連結して動こうとするため、最初からエンドポイントアドレスにクエリが付いているAzure AD B2Cだと、
 https://hogehoge.com/oauth2/authorize?p=B2C_A_xxx?client_id=aaa....
のように?をつけてしまったりするんです。※本来はもともとパラメータが付いているので、追加パラメータは&で繋いでほしいのですが、想定されてないのだと思います。


ということで、今回はAzure AD B2Cのエンドポイントアドレスにクエリパラメータを使わない方法の紹介です。

といっても単純に以下を使うだけです。
(.well-known/openid-configurationのアドレスです。これを叩けば対応するauthorizationとかtokenエンドポイントのアドレスが取れます)

ドメインデフォルト(パラメータあり)パラメータ無
b2cloginhttps://テナント名.b2clogin.com/テナント名.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_ポリシー名https://テナント名.b2clogin.com/tfp/テナント名.onmicrosoft.com/B2C_1_ポリシー名/v2.0/.well-known/openid-configuration
onmicrosoft(非推奨)https://login.microsoftonline.com/テナント名.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_ポリシー名https://login.microsoftonline.com/te/テナント名.onmicrosoft.com/B2C_1_ポリシー名/v2.0/.well-known/openid-configuration


エンドポイントアドレスがかなり長いですが、既存のクライアントとの連携などを行う場合は、こちらを使った方がベターです。