ラベル Blockchain の投稿を表示しています。 すべての投稿を表示
ラベル Blockchain の投稿を表示しています。 すべての投稿を表示

2024年8月10日土曜日

選択的開示に関するReview論文を読む(5)

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

引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review

今回はブロックチェーンの利用の動向についてです。

当然でしょうが、ブロックチェーンが登場する以前の方法論に関してはブロックチェーンが使われることはありませんでしたが、著者によると2018年からは選択的開示を含むアイデンティティ・ソリューションの一部としてブロックチェーンが利用されるものが増えているとされています。
シンプルすぎる図なのでこれだけだと意味不明ですが50%のソリューションがブロックチェーンを使っている、と著者は書いています。(うーん、本当?って感じですが)
論文より


なお、ブロックチェーンを利用したアイデンティティ・ソリューションのセキュリティ・プライバシーの強化については以下の点があると記載されています。
  • Enhances security and privacy — provides a secure and tamper-proof environment for storing data;
  • セキュリティとプライバシーを強化 — データを保存するための安全で改ざん防止機能を備えた環境を提供します。
  • Full control over identity — blockchain empowers users to have complete control over identity, manage it and share it without intermediaries;
  • アイデンティティの完全な管理 — ブロックチェーンは、ユーザーにアイデンティティの完全な管理権限を与え、仲介者を介さずに管理および共有することを可能にします。
  • Inclusion and accessibility — digital identities can provide official identification to individuals who lack traditional identity documents;
  • 包含とアクセス可能性 — デジタルIDは、従来の身分証明書を持たない個人に公式な身分証明を提供することができます。
  • Data integrity and immutability — blockchain is immutable, and it provides a reliable and tamper-resistant source of information;
  • データの完全性と不変性 — ブロックチェーンは不変であり、信頼性が高く改ざん防止機能を備えた情報源を提供します。
  • Elimination of identity fraud — the risk of identity theft and fraud is reduced;
  • なりすまし詐欺の排除 — なりすましによる詐欺のリスクが低減されます。
  • Decentralization — removes the risk of a single point of failure;
  • 分散化 — 単一障害点のリスクを排除します。
  • Builds trust — approach is user-centric, enhancing user experience and building trust.
  • 信頼を構築 — ユーザー中心のアプローチで、ユーザー体験を向上させ、信頼を構築する。
一方で以下の欠点もあるとしています。

  • Scalability and performance — blockchain is a resource-intensive technology. Combined with computationally intensive methods for selective disclosure, integration can lead to challenges in scalability and performance;
  • スケーラビリティとパフォーマンス — ブロックチェーンはリソース集約型のテクノロジーです。選択的開示のための計算集約的な手法と組み合わせることで、統合はスケーラビリティとパフォーマンスの課題につながる可能性があります。
  • Complexity in implementation — both blockchain and selective disclosure require significant technical expertise;
  • 実装の複雑性 — ブロックチェーンと選択的開示の両方には、高度な技術的専門知識が必要である。
  • Regulatory and legal challenge — blockchain and selective disclosure enable privacy and, therefore, can face strict regulatory scrutiny;
  • 規制および法的課題 — ブロックチェーンと選択的開示によりプライバシーが実現されるため、厳格な規制の監視に直面する可能性がある。
  • Interoperability — lack of standardization between selective disclosure methods and blockchain platforms can cause issues in the interoperability of digital identity systems.
  • 相互運用性 — 選択的開示方法とブロックチェーンプラットフォーム間の標準化の欠如は、デジタルIDシステムの相互運用性に問題を引き起こす可能性があります。


同意しかねる内容(というかブロックチェーンは関係ないだろ、、って話)も含まれますが、一般論として言われていることかもしれませんね。

2024年4月22日月曜日

自民党web3PTの2024年版ホワイトペーパーのテーマの一つはDID/VC

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

先日リリースされた自民党のweb3PT(プロジェクトチーム)のホワイトペーパーのテーマの一つとしてDID/VCが取り上げられていますね。ブロックチェーン、DAO一筋だったころに比べると社会実装に向けて現実的な路線も取り入れられてきていて成熟してきた感があります。


新たなテクノロジーが社会基盤となる時代へweb3PTが「ホワイトペーパー2024」を策定

https://www.jimin.jp/news/information/208018.html


発行されたホワイトペーパーの要旨にはこんな感じで「VC及びDIDの利活用促進、DIWに関する検討」がテーマとして記載されています。実はこのDID→VCではなく「VC及びDID」となっているところが個人的には注目です。これまでのweb3ではDIDが全面に出てきていましたが、ようやく本質はVCだということが理解されてきたようです。事務局のみなさん本当にお疲れ様です。



ちなみに、平井卓也さんのInstagramに会合の様子が掲載されています。この会は私もお邪魔してVCとブロックチェーンの関係性の話を少しお話してきました。(あんなに細かい話をして良かったのかどうかは置いておいて)


ちなみにホワイトペーパーは平将明さんのページにダウンロードリンクが紹介されています。

https://www.taira-m.jp/2024/04/web3-3.html


2022年2月27日日曜日

分散型IDに関する10の所感(2022年2月版)

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


なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。(往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする)

※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・


また機会があればdidconでも開催してじっくりお話させていただこうと思うので思うがままに書いた乱文ですが、こんな感じかと。(いうまでもありませんが、完全に私見です。私が関与している各種団体や事業者には一切関係ありませんので悪しからず)

  1. まだ意外と誤解されているが分散型「アイデンティティ」ではない
    • DIDはDecentralized "Identifiers"でありDecentralized "Identity"ではない。
    • なぜならIdentity=Set of attribute(ISO/IEC 24760-1 2019)なのでDecentralized "Identity"という話であればOpenID ConnectのDistributed Claimsの方がよっぽど分散されている。
    • では、何が分散されているのか?というと識別子(Identifier)と関連するメタデータ(Document)が分散台帳等の上(これも特にブロックチェーンと明確に規定されているわけではなく、現に全然分散されていないDIDもある)にデプロイされることで単一事業者等への依存度をさげられたり、関連して相対的にではありますが可用性などを気にする必要性が少なくなったり、というレベルの話。
    • というか、W3Cが規定しているのはDecentralized "Identifiers"だし、決めているのは識別子とメタデータ(DID Document)の書き方くらい。

  2. 自己主権型アイデンティティは幻想?
    • そもそもデータに関する主権ってなに?という話で、先にも書いた通り目的語が不明確な中でDecentralizedが分権型なのか、分散型なのか、非中央集権型なのかもぼやけている中で何を持って自己主権なのか?というレベル。
    • パブリック/パーミッションレスな分散台帳に識別子(Identifier)と署名検証に使う公開鍵を含むメタデータ(DID Document)を公開することで特定の事業者が当該のエンティティに関するデジタル上での生殺与奪に関するコントロールしずらくなる、ということを言いたいんだ、ことはわかるんですが、それが果たして「自己主権」に繋がるのか?と言われるとうーむ、という話。
    • もう一つはVerifiable Credentialsの持つポータビリティという性質の話。後でも触れるがDIDをうまく使うことでIdPとRPの結合度を下げることは確かに可能で、結果としてVerifiable CredentialsをWalletと言われるスマートフォン等で動作するソフトウェアの中に格納して個人が持ち運ぶことも可能、という意味ではIdPからの独立性=自分で自分のアイデンティティをコントロールしている感を醸成しやすいという点は認めることはできる。
    • 結局のところ、唯一言えるのは自己主権型アイデンティティというのは思想であり、テクノロジとは切り離して考えるべきだ、ということ。たしかに現状のFederationを考えると相対的に分散台帳と紐づいたDIDと関連する鍵によって署名されたVerifable Credentialsは事業者の「支配」から逃れられている気にさせてくれる。
    • ちなみにこれは最も重要な点かも知れないが、DIDが「did:メソッド名:固有の識別子」という形式をとっている以上、メソッドを跨いでDIDや署名済みのVCを持ち運ぶ(引っ越す)ことは事実上不可能である点は見逃してはいけないと思う。

  3. Verifiable Credentialsが本命?
    • 今年度私も少しだけお手伝いさせていただいている内閣官房Trusted Web推進協議会のホワイトペーパーにも記載の通り、暗黙的な信頼から検証に基づくExplicitな信頼へという流れはDXの要になると思われる。まさにDon't trust, Verifyという言葉が全てを物語っている。
    • ただ、ここで解決しておかないといけないのはSAMLやOpenID ConnectのAssertionへのデジタル署名との違い。確かにCOVID-19のワクチン証明にVerifiable Credentialsを使ったことに新しさはあるけど、実態はデジタル庁の自己署名を打っただけのJSONなので、耐改竄性という意味においてはSAML AssertionやOpenID Connectのid_tokenと何ら変わらない。(もちろんFHIRの標準化されたSchemaをPayloadに使うという意味においてアプリケーションレイヤでの相互運用まで踏み込んだ点では非常に重要なアプローチだとは思う)
    • では、DIDとセットにする意味は?という話だが、実際問題としてメリットはゼロではない。どういうことかというと、署名検証をするための公開鍵をjwks_uriなどで公開しているケースに比べて、こんなメリットがある。
      • 事業者がIdPの可用性をそれほど考えなくて良い(IdPが落ちていても分散台帳上にDID Documentを公開してしまえば、コンロトーラビリティは下がるが相対的に可用性は向上することが多い)
      • OPがシャットダウンされた時、ユーザが署名付きクレデンシャルの真正性を証明できなくなる、という事態はなくなる
    • とはいえ、よくある話として署名アルゴリズムの危殆化の話は当然あるので、(相対的に単一事業者の都合が可用性に与える影響度合いが少ないと言える)分散台帳に公開鍵を置いているからと言って半永久的にVerifiiable Credentialsの署名を信頼できるかというとそうではなく、実運用では少なくとも数年に一度はVCの再発行は必要になると思われる。そうなるとIdPの事業継続性の観点でVCが優位というロジックは非常に限定的(つまり、少なくともIdPが潰れても数年間は資格証明が可能というレベル)だし、いわゆるソーシャル・インクルージョンの文脈で語られる国家というIdPによるネグレクトに対する銀の玉にはなりそうにもない。

  4. VC発行者に関する信頼は難しい問題
    • VCの発行に際して発行者は自身のDIDにに紐づく秘密鍵で署名するわけなので、そのDIDは誰なのか?信頼できるのか?という点が重要になってくる。
    • 実世界のビジネスモデルを考えるとDNSの持つ分散ガバナンスモデルに依拠するのが落とし所、という形でwell-known did-configurationがMSでもMattrでも実装されているが、DID/VCのモデルの外に依存している段階で分散とか分権とかいうキーワードは虚しく感じられるのは自分だけではないはず。
    • そして、結局は一番怪しいのがDIDからDID DocumentをLookupするためのResolverの信頼性。もちろんUniversal Resolverを含めオープンな実装は透明性という意味である程度信頼はできるとは思うが、結局はDriverの実装者と実インスタンスを動かしている事業者の誠実さを「信頼」するしかないのが現状。

  5. いくらVerifiableだったところで信頼されるとは限らない
    • そもそもTrust FrameworkってITの世界でクローズできるものではない。
    • 実際、いくらデジタル署名されたデータセットは改竄されにくい、と言ったところで人間はヒューリスティックな生き物で「見たことがある紙やプラスチックの物理的な身分証明書」を対面で提示されることにはかなわない。
    • これはDXの本質的な話で、Digitization〜Digitalizationなど段階を定義するのは良いが、現実論としてDigitizationとDigitalizationの間には大きな溝があると思う。みんなPDFとかExcelが大好きだし、最後の手段で紙に戻せば業務継続できると思っている段階で、最初から紙を前提としないDigitalizationの段階へは永遠に進めないと思う。
    • そういう意味ではVerifiableという特性をフルに活かすことのできるユースケースをなるべく早く見つけることが最大のミッションなのかも知れない。この辺りは先にも触れたTrusted Web推進協議会が大きな役割を果たすことが期待される。

  6. KYCというか本人確認・身元確認との相性はそれほど良くはない
    • 結局、Identity Proofingの本質はNIST SP800-63Aでいうところの、
      • Resolution
      • Validation
      • Verification
    • というステップによって構成されており、この中でVCが役に立つのはValidation(提出したエビデンスの真正性検証)。でも良く考えるとValidationの本質はオーソリティへの照会(この辺りは身元確認の「元」という文字にも現れている)なので、Evidenceが改竄されていないことの証明だけでは不十分。
    • 確かにRevokeに関するスペック(Status List 2021)も標準化が進んできているので有効性確認はできるようになるとは思われるが、Evidence発行元におけるKYCプロセスの信頼性まで担保できるわけではないし、オーソリティの信頼性の方がEvidence自体の耐改竄性よりも重要な世界。
    • また、Verification(Evidenceに記載のエンティティとEvidence持参のエンティティの同一性確認)ができるわけではない
    • となると、身元確認ではなくOpenBadgeがやっているように資格証明程度に使うのが現実的だと思われる。

  7. 結局はIdPとRPの結合度を下げることが可能、というのが最大のメリット?
    • こうなるとOpenBadgeではダメなの?という話はあるが現状のOpenBadgeのほとんどがSigned型ではなくHosted型(Issuerへの問い合わせにより真正性・有効性を検証する方式)であることを考えると、システム間の結合度を考えると一定の優位性はある状態(少なくともSigned型が普及するまでは)
    • つまり、結局のところシステム間(OPとRPの間)の結合度をさげるためのもの、という使い方が現状ではベストなのでは?と思われる。
    • 事実、去年のIIWでのユースケースに関するディスカッションをしている時に私が話した、大学のID基盤の管理負荷(ライセンス・インフラのサイジング・可用性)を下げることができるのでは?というのが一番響いたっぽい。(少なくともVittorioあたりには)

  8. 標準化の実際はどうなっているのか?
    • まだまだカオスに見える。Hyperledger勢がDecentralized Identity FoundationとかTrust over IP Foundationとかで推しているDIDcommや、OpenID FoundationでやっているSIOP v2OIDC4VPとか。
    • そもそも論、VCにJSON-LDを使うのかJSONで行くのかも議論が尽きないポイント。
    • そんな中、いろんなベンダがビジネスとして立ち上がってきており微妙な段階の仕様を実装してサンプルコードとかを公開するので、世の中の開発者が真似をしてさらにカオスな状態が出来上がり、標準化とは?という世界が出来上がりつつある。

  9. ゼロ知識証明(ZKP)、選択的開示(Selective Disclosure)が本命?
    • そもそもゼロ知識証明に関してはMSが買収したuProveとかIBMのIdeMixとか昔から研究されてきている領域だけどまだまだ実用化には遠いのが現状。(そういえば10年以上前にuProveのテストインプリがされたWindows Identity FoundationのPrivate Previewのテストをやっていたのが懐かしい)
    • またZKPとSelective Disclosureはごっちゃに語られることも多いけど、結局のところ必要なのはSelective Disclosure。この辺はBBS+とか頑張ってるがまだまだ課題はあり(隠せる範囲が限定される、など)、早稲田の佐古先生とかIIJの山本さんが拡張提案をしていたりするのでこの辺りは要ウォッチ。
    • よく言われる物理世界ではできなくてデジタルの世界でできるようになるといいよね、と言われるバーに入る時の年齢確認に免許証を出すと年齢以外の情報までガードマンに知られちゃう、という話への対応はこの辺りのテクノロジの成熟と実装に期待はされている。ただ、本当にガードマンに年齢以外に名前を知られて困るのか?という話はあるので、ユースケースについてはもっと議論しないとダメだと思う。

  10. 結局何か世の中の課題を解決できたのか?
    • よく言われるものとして、
      • プライバシー
      • 検証可能性
    • があるが、上記を見ている結局そこまで解決に至っているとはいえない。
    • それよりも、上記に書いた通りOPとRPの間の結合度を下げることによる管理面やインフラ的なコスト削減が一番のメリットになるのでは?


と、色々書きましたがテクノロジーとしては非常に面白く今後世界を変える可能性のあるものだと信じているので引き続き研究していきたいと思います。

2021年4月6日火曜日

Azure AD Verifiable Credentialsがやってきた(Public Preview)

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

ようやく出ました、Azure AD Verifiable CredentialsのPublic Preview。


AlexのBlog

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/announcing-azure-ad-verifiable-credentials/ba-p/1994711


各種リソース

https://www.microsoft.com/en-us/security/business/identity-access-management/verifiable-credentials

某社もソリューションパートナーになってます。

この辺りからチュートリアルも触れるのでガシガシ触っていけると面白いと思います。

Microsoft Authenticatorを最新版にアップデートするとこんな感じでVerifiable Credentialsをどんどん発行していけます。これで各種デジタルな証明書を持ち運んでIdPにアクセスすることなくVerifierへ証明書を提示していくことができるようになるはずです。




2020年9月26日土曜日

Microsoft IgniteでのDID/VC関連トピックス

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

先週のオンライン開催されたMicrosoft IgniteではAzure Active Directoryを始めとするアイデンティティ関連のトピックスや新機能発表が色々とありました。

個人的に気になったのは、

  • Identity ProtectionがAzure AD B2Cにもきた
  • 条件付きアクセスがGraph API経由で触れる様になった
  • ヘッダ認証が使える様になった
  • VC関係の近況と退役軍人向けの教育プログラムへの適用事例
の4点です。

1点目は先日Blogにも書いた通り、今後のB2C向けサービスの幅が非常に広がる話ですし、2点目はリスクイベントを拾ってTeamsなど外部サービスに連携させるデモなどもあり運用面で非常に有用だと思いました。また3点目は以前Ping Access連携で実現していたことがMS純正でできる様になる、というところでレガシーアプリケーションへの適用の面では非常に有用だと思います。

そして、最後が本日のメインであるDID/VC関係の近況です。
* DID : Decentralized Identifier
* VC : Verifiable Credentials

こちらも以前ブログに書きましたが、その後ブラッシュアップされてきているもです。
※この辺のキーワード(含む自己主権型アイデンティティ/SSI)の使い方は間違って使われているケースが散見される(Decentralized Identityとか)たり、=ブロックチェーンみたいな誤解もあるみたいなのでどこかでちゃんとまとめないとな、、、と。この辺りのスライドを書いてから、自分の理解も進んだのと標準化の方向性も進捗してるのでどこかでUpdateします。。。

話がそれましたが、早速Igniteでのトピックスを追いかけてみましょう。

VC関係の話が取り上げられたのはキーノートを含む以下の4つのセッションです。

全体を簡単に要約すると、
  • VCを使うとVerifier(学校とか企業とか)が各種証明(学歴、職歴など)を簡単・確実に検証できるよ
  • VerifierがSubject(個人)の情報を一生懸命集める事によるプライバシー上の懸念もなくなるよ
  • すでに米国の退役軍人向けの教育プログラム(MILGears)で実証実験が走ってるよ
  • 今はプライベートプレビューだけど、もうすぐみんな使える様になるぞ!
  • VCをLinkedInのプロファイルに追加できるなるぞ!
みたいな話でした。

ざっくりみていきましょう。

まずはSatyaのキーノートです。後半54分あたりからDecentralized Identity Systemの話が出てきます。

私たちはオープンな分散型アイデンティティシステムを作り上げようとしています。そしてそれは、どんな中央集権的なオーソリティやテック企業からも独立しています。すでに退役軍人向けの教育プログラムでパイロットをしています。


彼らは自身の検証済みの記録をスマートフォン上のWalletに保管することができ、大学や企業に直接提示することができます。大学はそれ(VC)を数秒で検証することができ、センシティブなデータを保管する必要はありません。また退役軍人たちは、VCをLinkedInのプロファイルに追加することができ、新たな職業を得る機会に役立つでしょう。


次はVasuのキーノートです。途中16分すぎから出てくるIrinaのパートでIdentityの話があり、17分過ぎから分散型アイデンティティの話です。

オンライン化に伴いデジタル信頼やプライバシーはとっても重要なものになっています。しかし現在私たちはアイデンティティをデジタルに検証する仕組みを持っておらず、またデジタル・プライバシーは私たちのコントロール外となっています。私たちがパーソナルデータをオンラインで共有する際、企業・組織は記載されている目的外には利用せず、許可なく共有することはないことを約束し、それらのパーソナルデータが盗まれない様に、誤用されない様に保護する努力をします。マイクロソフトはすべての人々が自身のアイデンティティをコントロールできる様にする必要があると考えています。アイデンティティはどんな組織やテック企業からも独立しているべきなのです。これが私たちが分散型アイデンティティ分野に投資する理由であり、すべての人が自身のデジタルアイデンティティを所有し、誰が何の目的でいつアクセスできるか決定できるべきだと考えています。
年齢、学歴、職歴、クレジットスコア、生体情報は利用者自身のコントロール配下におかれ、政府や大学や企業の様なサードパーティはそれらの情報を検証できる様になります。それらすべてのクレデンシャルはデジタル・カードの様な形でMicrosoft Authenticatorの様なデジタル・ウォレットに保存されます。



私たちはVerifiable CredentialsとDecentralized Identifiersに関するオープンな標準に基づく自己主権型アイデンティティのヴィジョンを現実のものとするため、Decentralized Identity Foundationと共に活動しています。

私たちはこの分散型アイデンティティのシステムを多くの顧客と共にパイロットしており、MILGearsの教育プログラムもその一つです。 


ここでMilGearの人のインタビュー動画が流れた後、VasuがIrinaに今のステータスと今後どうなるの?って聞いてくれます(Good Job!)。「We're currently in private preview, but soon anyone will be able to try it.」素晴らしい!


次はおなじみJoyです。19分くらいから分散型アイデンティティ関係の話が始まります。


我々が物理的な世界で行ってきたパスポートや学位やその他証明書のやりとりをデジタル化するにはどうすれば良いのでしょうか?私たちはデジタルにそれらのクレデンシャルを検証するメカニズムが必要です。しかし今日私たちが持っているシステムはデータ漏洩や誤用で溢れています。私たちは分散型アイデンティティシステムとVerifiable Credentialsが解決策になると信じています。コミュニティの努力とオープンな標準をベースに構成され、既存のアイデンティティシステムと簡単に接続することが可能です。それはオープンな標準技術を用いており、マイクロソフトを含むどんな組織も支配することはできません。そして、それはすでに現実のものとなっているのです。


ここでやはりMILGearsの事例の話。どこにVerifiable Credentialsを提示したのか確認することができます。


退役後、大学や企業に就職する際に、軍がIssuerとなってそれまでの学歴や経歴を証明する、という形態の様ですね。

退役後、高等教育や企業への就職する際、大学や企業は学歴や軍でのトレーニング履歴にアクセスする方法がありませんでした。そのため、彼らは証明書などのドキュメントを収集し確認する長いプロセスを必要としていました。そして、多くの場合、それらのプロセスは紙をベースとしており、数ヶ月を要することもありました。

このプロセスをデジタル化することにより、彼らの待ち時間を減らすだけでなく、自身のデータに関するコントロールを行うことができる様になりました。大学がデータを収集し、保管し、保護する必要がなくなったのです。


ここでMILGearsのデモです。ここでMILGearsが保持している記録をVerifiable Credentialsとして発行します。

QRコードが表示されるのでMicrosoft Authenticatorで読み込むとカードの形でVerifiable CredentialsがAuthenticator上に追加されます。

次は大学にVerifiable Credentialsを提示します。こちらもQRコードを読み込むとVerifiable Credentialsが提示され、検証済みのデータとして大学側へ連携されます。


デモに続いてテクニカルな話をMelanieさんから。必要なのはAzure Active Directoryサブスクリプション(正確にはPremium P1以上)とKeyVaultだけ(こちらも正確にはStorageは必要)。やるべきことはたった3つ。KeyVaultでキーペアの作成をする、Rulesファイルを作る、Displayファイルを作る、とってもシンプルでしょ、的なデモです。
こちら、Rulesファイルですね。まぁ、確かに簡単な構造のjsonです。

こちらはDisplayファイル。こちらも非常にシンプルなjsonファイル。Authenticatorに表示されるカードのロゴとか色を決める感じですね。


というところでJoyのキーノートは終了です。

最後はMicrosoft Mechanicsですが、こちらも結局Joyががっつり話をします。
中身的には、W3Cの標準をちゃんとみてるよ、という話とこれまであったMILGearsの事例、KeyVault、RulesとDisplayなど実装にかかる話のおさらい的な感じのセッションです。

MILGearsの事例をベースにIssuer=MILGears/Subject(Holder)=退役軍人/Verifier=大学など、と関係性を解説してくれています。わかりやすい。

ブロックチェーンとの関係も最後に少しだけ触れられます。基本的にDID Documentと公開鍵の置き場所として使ってるだけです。



全体的にまだ詳しいところは触れられない感じでしたが、こうして動いている姿を見ることができると非常に面白いですね。MILGearsのケースも非常に面白いと思います。退役軍人っていうともっと年寄りでそのまま隠居する?ってイメージでしたが結構若い間に退役して、その後大学に行ったり企業に就職したりするケースもあり、その場合に身元保証を軍がやる、というのは日本にいるとあまりイメージが湧きにくいとは思いますが、話を聞いてみると納得、という非常に良いユースケースだと思います。

DID/VCはとても面白いテクノロジだとは思いますし、可能性も感じますが、別にDID/VCじゃなくても良いじゃん、というケースばかりなので今後DID/VCならではのユースケースがもっと研究されると良いな、というのが全体的な感想でした。




2020年6月9日火曜日

分散型ID「ION」のプレビューがアップデート

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

本ブログでも何度か触れたことのある分散型ID(この日本語訳は微妙だな、、、とは思いますが。Decentralized Identity)ですが、マイクロソフトも「ION(アイオン)」というコードネームで取り組んでいる、という話は過去のde:codeなどでも紹介してきました。

de:code 2019での発表資料


本ブログの過去ポスト
https://idmlab.eidentity.jp/2019/04/blog-post.html


先日のBuildでも当然セッションがあり、6月にUpdateあるよ!的な話がささやかれていたのですが、予定通り出てきました。

URLは相変わらずプレビュー間満載ですが・・・・
https://didproject.azurewebsites.net/docs/overview.html

新プレビューの概要

今回のプレビューで出来るようになったことは大きくは以下の通りです。

  • Azure ADとの統合(Credentialsのソースとして利用)
  • Microsoft AuthenticatorをWalletとして利用
  • Azure Key VaultでVerifiable Credentialsへの署名する鍵を管理
想像するにこんな感じの構造になっていると思われます。

構造としてはこんな感じです。
【Verifiable Credentialsの発行時】
  • Portable Identity Cards(実体のアプリ名はVerifiable Credentials Issuer Service)がAzure ADにEnterprise Applicationとして登録されている
  • Portable Identity CardsがAzure AD上に登録されたユーザの情報を元にVerifiable Credentials(VC)を発行する
  • ユーザはMicrosoft Authenticator(現状はAndroid/Beta版のみ対応)に発行されたVCをカードのメタファとして保存(ちなみに使われていると思われるAndroid用のSDKもここに公開されているので自作するのも可能なはず)
  • VCへの署名をするための秘密鍵はAzure KeyVaultで管理される
  • 分散台帳(ION)とのやり取りはPortable Identity Cardsサービスが使っているverifiablecredentials-verification-sdk-typescriptがやっている
【Verifiable Credentialsの利用時】
  • Portable Identity Cardsサービスと同じく、verifiablecredentials-verification-sdk-typescriptを使ったサービスへアクセス
  • サービスはQRコードを使ってVCの開示要求、ユーザはMicrosoft AuthenticatorでQEコードを読み込み、VCを送付
  • Portable Identity CardsサービスはVCをDLT上の公開鍵を使って検証(この辺もverifiablecredentials-verification-sdk-typescriptがやっている)


上記よりわかる通り、実体は「verifiablecredentials-verification-sdk-typescript」です。これをVC発行者がわかりやすいようにAzure AD/Azure KeyVaultと統合したものがPortable Identity Cardsであり、ユーザが使いやすいようにしたのがMicrosoft Authenticatorということです。



動きを見てみる

では、早速試してみましょう。

と言いたいところなのですが、Limited PreviewなのでMicrosoftに承認されないと動きません。(申請してみたけど返事がない・・・)
ただ、手順を見ているとAzure ADのEnterprise ApplicationsにVerifiable Credentials Issuer Serviceが出てきてObjectIDが取れればPreview機能が有効になっているよ、とあるのですが、一向にPortable Identity Cardsの管理コンソールがAzure Portalに現れません・・・・

上の図の通り、Previewが有効化されたテナントでAzure AD P1もしくはP2を有効にするとエンタープライズアプリケーションの一覧にVerifiable Credentials Issuer Serviceは出てきましたが、Portable Identity Cardsのコンソールが出てこない・・・(以下の図は手順書より)




ということで、自前のAzure ADを使うのはあきらめて素のverifiablecredentials-verification-sdk-typescriptを使ったサンプルコードを使って試してみます。
ちなみに、昨日までVCの発行まではうまく動いたのですが、検証はうまく動きませんでした。しかし、今朝サンプルコードが更新され現在はちゃんと検証まで動くようになりました。

サンプルコートはココにありますので、ローカルにcloneして使いました。

ちなみにMicrosoft Authenticatorからサービスにアクセスできる必要があるので、ngrokを使って外部からアクセスできるようにしました。

改造したコードはこちらです。
Issuer
Verifier

それぞれnpm installしてnode app.jsで実行できます。


まずはIssuerから動かします。
(前もってMicrosoft Authenticatorのベータ版を入れておいてください。現状Android版のみです)

起動すると画面上にボタンがあるのでクリックするとQRコードが表示されますので、これをAuthenticatorで読み込むと、Azure AD B2Cでのログインを要求されますので、アカウントの作成~ログインを行うとカード(Verified Credential Ninja)が追加されます。

Authenticatorでその他のアカウントを追加してQRコードを読み取る

Sign in to your accountでAzure AD B2Cへログインする。(初回は新規作成)

ログインが終わったらAcceptをタップします。

上手くいくとカードがAuthenticatorの中に保存されます。この中にVerifiable Credentialsとして氏名の情報が入っています。

次はVerifyです。
ngrokを使っていると2つ同時にサービスを挙げられないのでIssuerを停止しておきます。
Verifierを起動するとIssuerと同じようにボタンがあるのでクリックするとQRコードが表示されます。
これをAuthenticatorのカードの画面にあるQRコードリーダーを使って読み取ります。


上手くいくと画面上に「Congratulations, XX XX is a Verified Credential Ninja!」と出てきます。


ここまでは外から観測できたことなので、今後は引き続き中身を掘ってみようと思います。
IdentityCardRules.jsonファイルをいじくると他のOpenID Providerからでもクレデンシャル発行が出来るようですし。



参考)Buildのセッションの動画


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年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月26日水曜日

Identiverse 2019参加メモ(Day1)

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

 今週ワシントンDCで開催されているIdentiverse 2019にきています。私はまだIdentiverseがCloud Identity Summitと呼ばれていた2016年から合わせて通算で3回目の参加となります。(昨年度はスピーカーとしての参加でしたが、今回は純粋にオーディエンスとしての参加なので、大いに楽しみたいと思います)

尚、今年は10周年ということで会場のあちらこちらに10周年を祝うモニュメントがあったり、毎年恒例のTシャツも10周年記念モデル?となっていたりしてお祭りムード全開です。(残念ながら例年おもしろTシャツのデザインをしていたPing Identityの方が退職されたとのことで、今年は1種類だけでした)

10周年記念オブジェ

10周年記念Tシャツ

しかし、何と言っても今回の目玉は最終日に予定されているスペシャルゲスト、Steve Wozniakのスペシャル・キーノートです。
こちらは最終日に改めてレポートします(体力が持てば・・・)


と、言うことで初日の参加メモ(と言うか旅行日記)です。

◆Identiverseとは

まず、Identiverse(旧Cloud Identity Summit)をご存知ない方のために簡単にイベント自体の説明をしておきます。詳細はこちらに書かれている通りですが、ざっくり言うと「デジタルアイデンティティやセキュリティ分野のリーダーやユーザーが集まって来るべきデジタル世界のVisionやテクノロジーについて語らう場」で、元々はPing Identityが主催するCloud Identity Summitとしてスタートして今年で10年、200以上のセッションがあり、2000名以上の方が参加するEuropean Identity & Cloud Conferenceに並ぶグローバルで最大規模のアイデンティティ・イベントです。

日本人も10名程度ではありますが、毎年参加されています。(ここでしかお会いしない方々もいたりして・・・)

また、グローバルなアイデンティティ界隈のリーダーの方々にも直接あって近況の交換をすることのできるIDマニアにとって非常に重要なイベントでもあります。
今年も初日のレジストレーションに並んでいる時にSalesforceのVPのIan Glazerに声をかけてもらったり、廊下でUnikenのNishantと話をしたり、MicrosoftからAuth0に移籍して早1年、我らがVittorio Bertocciと写真を撮ったり、と日本ではなかなかできない体験ができます。

◆Day1で参加したセッション

今回は奇跡的に時差ボケ解消に成功したので、初日から力つきることなく朝から晩まで通してセッション参加しました。

簡単な感想などを添えてそれぞれのセッションを紹介します。
ちなみにアジェンダはこちらから見ることができます。

  • Introduction to Identity Part 1 / 2 by Ian Glazer, Pamela Dingle, Steve Hutchinson
    • 言わずと知れた大御所によるデジタルアイデンティティとはなんぞや、と言う解説セッション。
    • 標準技術から利用シーンまで網羅的かつわかりやすく解説してくれたので初学者に取っては非常に貴重な機会だったと思います。
    • それなりに広めの部屋でしたが立ち見が出るほどの大盛況でした。
    • かい摘んで解説すると、こんな感じでした。
      • B2Eの世界における従業員IDの管理のようなトラディショナルなID管理から、B2Cの世界における顧客IDの管理のようなモダンなID管理への潮流があり、これからは「個人にフォーカスしたID管理」が主流になってくる
      • B2E、B2B、B2Cのそれぞれの世界におけるID管理を「Admin-Time(管理時の目線)」と「Run-Time(実行時の目線)」で深掘り、関連するID管理の実施事項を解説してくと言うスタイル
      • 管理と言う目線では以下のキーワードについて概要及び技術標準(SCIMなど)を解説(Ian Glazerが担当)
        • Source of Truth(アイデンティティ情報の源泉)からディレクトリやアプリケーションなどの各種レポジトリへのプロビジョニングの流れ
        • その前段にあるIdentity ProofingについてB2E、B2B、B2Cでの違い
        • 権限管理、ロール管理、アイデンティティ・アナリティクス、特権ID管理
      • 利用時の目線では同じく概要から標準を解説(Pamela Dingleが担当)
        • 認証・認証要素(Active Factor/Passive Factor)とAdaptive Authenticationについて
        • シングルサインオンとは
        • APIセキュリティと委任(WS-Trust vs OAuth2.0)
        • UXについて(Discovery時のNASCAR問題、同意取得、プロファイル管理、登録やリカバリのセルフサービス化など)
      • 最後にSteve HutchinsonがAdmin-TimeとRun-Timeを合わせて全体像を語る、と言う締め

  • Modern Identity for Developers 101 by Vittorio Bertocci
    • 言わずと知れたVittorioのセッション
    • 旧来のIdentityシステムからモダンなアーキテクチャへの移り変わってきた理由をわかりやすく解説
      • 旧来はネットワーク境界の中にシステムがあり、各システムがアイデンティティ関連の機能(ユーザーストア、認証機能など)を持っていた
      • その後、複数のシステムを横断的に使いたい、と言う要望に答えてディレクトリシステムやKerberosなどネットワークレイヤに近い層でシングルサインオンを実現
      • しかしクラウドやB2Bなどネットワークの境界を超える必要が出てきたので、Federationテクノロジーが必要になってきた(モダン・アイデンティティの世界)
    • Developer向けのセッションなので、モダン・アイデンティティの世界を支える各種要素(Identity ProviderやRelying Party、id_token、access_tokenとセッション管理など)の基本的な考え方を実際のデモ(Auth0とASP.NET Coreアプリ)をFiddlerでトレースしながら解説

  • Google master class: Enabling BeyondCorp in your organization today by Google
    • ベンダーセッションなので製品・サービスに特化した解説
    • Vittorioのセッションでもあった通り、もはやネットワーク境界がセキュリティの境界となり得ない世界(Identity is the new perimeter)となってきているので、VPNやFirewallではなくアイデンティティ・アクセス管理とデバイス管理を統合的に行うことでセキュアな世界を作りましょう、と言うのがBeyondCorpの基本的な考え方
    • Identity、Context、Rules Engine、Enforcement pointを経てアプリケーションやデータへ到達できる、と言う流れ(以下、概要)
      • Identity : 利用者のアイデンティティ。Cloud Identityが該当
      • Context : 利用者がどのような状態なのか(デバイス状態やネットワーク)。Device Trustの設定など
      • Rules Engine : IdentityとContextに応じて必要な認証や認可ポリシーを判断するためのエンジン。Access Control Managerで設定
      • Enforcement point : 判断結果の応じたポリシーを実行する。Cloud IAP、Cloud IAM、VPC Service Controlなどで対象システムやAPIに応じて制御を行う
    • 最後にデモとして特定のバージョン以上のMacOSからでないとGmailが開けなくなる、と言うようなシナリオを紹介

  • US Army: The secrets of a Successful ABAC Deployment by Accenture Federal Service, NextLabs
    • 事例セッション
    • US ArmyのSAPシステムの権限管理をNextLabsのソリューションを使ってABACで最適化したよ、と言う話
    • ABACの基本的な考え方はNIST SP800-162の通り。XACMLベースです。
    • やりたいことはRealtime SoD、Realtime continues authentication/Risk-aware authorization
    • ベストプラクティスは以下の通り
      • 属性のクオリティは大事
      • ポリシーは100個以下におさめて再利用可能な設計をすること
      • RBACとABACは共存できる
    • US ArmyではNextLabsのソリューションを使い、SAPの標準の権限管理のさらに上位のレイヤーで権限管理を行った
    • 最終的にはこんな感じ
      • 権限管理に使った属性は5つ未満
      • ポリシーは10〜20個の間
      • 属性はGRCで管理

  • Decentralized Identity: Intersection of Identity and Distributed Ledger by Microsoft
    • マイクロソフトによるDIDのオーバービュー
    • 今日のアイデンティティに関する3つの課題
      • Too many passwords
      • Data ownership, privacy
      • Data oversharing
    • DLTはこれらの課題を解決できるのか?と言う問いに答えるのが、Identityと分散台帳をとり持つDecentralized Identity
    • DID AuthやVerifiable Credentialsを使うことである程度上記の課題が解決できそう。MSも最近IONを出したよ
    • しかし残課題として、UXやRP側から見たExperienceの改善や、アカウントリカバリーや鍵のローテーションの問題があるので、頑張って対応していく
    • そして、DIDはPIIなのか?という話も今後議論されていく問題。。。

  • Delivering a Trusted Digital Identity System by Mastercard
    • この辺りになると疲労度マックスなのであまり頭に入ってこなかったです。。。
    • 金融機関と言うよりテック企業になってきていて、デジタル空間での信頼を従来の社会と同様に作っていく、と言う話。
    • マスターカードのロゴのオレンジの丸は信頼を表している?と言うような話をしていた気がします
  • Throwing away the Clipboard : Digital Identity & Blockchain for Healthcare by Aetna, TrustedKey
    • 医療に関連する情報のポータビリティをTrustedKeyを使って実現しよう、と言う話(ただし、電子カルテの代わりになったり、ブロックチェーン上に医療履歴を載せようと言う話ではない)
    • 解決したい課題はユーザの利便性。
      • 保険証や本人確認書類を何度も提示しないといけない状態を解消したい。実際の医療行為を受けている時間より手続きを待っている時間の方が長いのは勘弁してほしい。
        • 医者に行く前のオンライン予約
        • 病院の受付
        • 薬局の受付
        • 医療履歴を管理するWebサイトへの登録
    • 医療機関、薬局などがIdentity Issuerとなり、TrustedKeyの提供するウォレットに情報をストア(ブロックチェーンベース)
    • 各種機関やオンラインサービスへQRコードを使って情報を提示することでUXを改善できる

  • Fastfed - A new standard to make SSO easy by AWS
    • OpenID FoundationのFastFed WGの発表
    • 現状、SSOを有効化しようとすると、IdP側に設定をした値をコピーしてRP側に設定、RP側の設定結果をIdP側にまたコピーして、、と言う流れになり非常に煩雑
    • FastFed WGでは設定や属性マッピングの自動化を行うための標準を検討している
    • AWSへのSSOをGoogle IdPで実施するデモを披露
      • AWSコンソールからGoogleアカウントを入れるだけで自動ディスカバリ〜自動設定が行われる
    • 個人的に非常に期待しているWGだったりするので、本格的に実装されてくるのが楽しみです
  • Self Sovereign OpenID Connect - a ToDo List by Nat Sakimura
    • 米国OpenID Foundationの理事長である崎村さんのセッション。
    • Self Sovereignってみんな騒いでるけど、ブロックチェーン=Self Sovereignじゃないよ、OpenID Connectでもいいよ、と言う話
    • モデルとしては、こんな感じ
      • SIOPを中心とした世界観
      • CP(Claims Provider)とIdP(SIOP)を明確に分離して、間をAggregated ClaimとかDistributed Claimで繋ぐ
    • ただ、まだまだやることもあって、以下がToDo List
      • SIOPを簡単にCPへレジストレーションできる仕組み(Dynamic Client Registration)
      • SIOPが発行するSelf IssuedなIdentifier(公開鍵のハッシュ)とCPの属性のバインディングの方法
      • 過去に遡った署名の管理(ブロックチェーンの出番かも)
      • 鍵のリカバリの仕組み
      • SIOPがオフラインでもRPが属性を取得できる仕組み
        • 基本的な考え方はDistributed Claimの利用。RPが直接CPへ問い合わせできる
      • SIOPのアドレスの解決
        • ブラウザ設定とリクエストヘッダーで解決できるような仕組みが良いのではないか?



とりあえず初日はこんなところです。


ちなみにワシントンDCの街中は結構坂もあるので、電動スクーターや電動自転車のシェアリングサービスがそこら中にあります。以前はカーシェアだけしかやっていなかったLyftがスクーターに手を出したりしていてまさにMaaS元年って感じなのかも知れません。(写真はBird)