Identity
Microsoft
Technology

デジタル・アイデンティティの最新動向 (07-10-2020)

2020-07-09 13:00

MS内で社内転職をし、Identity Standardsチームにジョインしてから、早3週間が経ちました。 Identity業界で起きている社内外の最新動向にキャッチアップをするために、ひたすら猛勉強をしていました。 インプットがどれくらい身についてきたかの確認も兼ねて、ラーニングをまとめてみました。

Identity最新動向のシラバス

以下のようなラーニングプランで3週間勉強していました。

  1. 分散型アイデンティティ(Decentralized identity)

A. 規格(Specification)の読み込み

B. MSがローンチしたサービスの仕組み・概要を理解(プライベートプレビュー中)

C. 現在起きている規格を策定するワーキンググループ(WG)への参加

D. GDPRコンプライアンスに関するリーガル・リサーチ

  1. 従来型アイデンティティ(Centralized Identity)

A. 規格(Specification)の読み込み

B. MSが提供しているサービスをより深く理解・実際にやってみる

C. 現在起きている規格を策定するワーキンググループ(WG)への参加

  1. 横断的ラーニング

A. Identiverse 2020

B. Pluralsight (REST API, node.jsなど)

【序章】分散型アイデンティティの基盤となるVCをDID

前提知識として、すこし分散型アイデンティティの世界およびその実装の基盤となるVerifiable Credentials Data Model 1.0Decentralized Identifiers (DIDs) v1.0について解説します。

VCとDIDによって達成される世界観

Verifiable Credentials(VC)は、すごく簡単に言うと、Subjectに関するClaimが含まれており、Issuerによって電子署名がなされたJSONドキュメントであり、Subjectは自身に関する何らかの情報を証明する際に、VCをVerifier/Relying Partyに提示することができます。

そして、こちらのVCを作成する際に、issure, Subject, Verifierを特定するためのIdentifierがDecentralized Identifier(DID)なのです。 そして、DNSのようにIdentifierを管理する中央型のPKIがないため、DPKI(Decentralized PKI)としてのブロックチェーンの親和性が高い、ということなのです。(IPFSなどでもOK

現在、デジタル世界における認証においては、Issuerが直接Verifierにクレデンシャルを提示していますが、VCの実現によって、個人が自分に関するクレデンシャルをVerifierに直接渡すことのできるようになり、身体的なF2Fの世界の認証に近くなることが期待されています。

VCとDIDがもたらす価値

では、これで誰が、何が嬉しいのでしょうか。一言でいうと、Stronger AuthenticationとBetter privacy/security protectionであり、情報漏洩が減り、デジタル世界における活動がよりシームレスになることなのですが、もう少し具体的に見ていきましょう。

Enterprise Identity(B2B認証)で考えると、企業間でコラボレーションをする際に、A社に所属する個人が、B社のリソースにログインする必要がある場合、

  • 有効なパスワードかどうか
  • リソースへのアクセス権があるかどうか
  • 二段階認証など条件付きアクセスポリシーが適用されているかどうか
  • マネージドされているデバイスからのログインかどうか などをチェックしているわけです。

しかし、Stronger AuthenticationとBetter privacy/security protectionを実現するためには、

  • 今回のタスクの遂行に必要なスキルトレーニングを完了しているかどうか
  • 2社間の契約が切れていないかどうか
  • 働けるステータスであるかどうか(VISAなど。USに多いケースですね) など追加の情報チェックもしたいところですが、現在は、こちらの情報は、A社でもB社でもない企業のデータベースに保存されているわけです。

現在の企業がパーソナルデータに関するDBがサイロ化されており、個人の分のデータを企業が提示する現在のデジタル世界では、とても実現できません・ しかし、VCやDIDの仕組みを用いて、個人が自分にまつわる情報を多企業から集め、自身で提示するようになれば、互いには信頼していないかもしれないが、複数の情報源からの情報を組み合わせることでセキュリティを強化し、プライバシーを守り、新しい価値を個人に提供できるようになると期待されているのです。

※ 図があったほうがわかりやすいですね。あとで追加します。

※ パーソナルデータにまつわる例ですが、もちろんモノや企業のIDにも対応した仕組みになっています

1-A. 規格読み込み (分散型ID)【W3C編】

基盤となるW3Cの2つの規格

前述の、分散型アイデンティティ実装の基盤となるVerifiable Credentials Data Model 1.0Decentralized Identifiers (DIDs) v1.0は、W3Cで規格が標準化されているので、まずは、その2つを今までの斜め読みではなく、じっくり時間をかけて読み込むことからはじめました。

W3Cとは

W3Cとは「World Wide Web Consortium」の略称で、Web技術の標準化を行う非営利団体の名称です。W3Cはティム・バーナーズ=リーによって1994年に創設され、Webで使用される技術を標準化し、よりスムーズな開発や品質向上を目標に活動が続けられています。 現在はHTMLやXHTML、CSS、DOM(Document Object Model)やXML(Extensible Markup Language)など多くの仕様が公開されており、IT関連企業を中心として400近くの団体が会員として加入するほど大規模な団体へと成長しています。

引用元: https://www.internetacademy.jp/it/design/homepage/web-standardization-and-w3c-recommendation-process.html

VC-data-model 規格

Verifiable Credentials Data Model 1.0のSpecificationは、データモデルのみを定義しており、暗号化や通信プロトコルなどはout of scopeです。 ストレージやVCの提示方法など、現在規格化が進んでいる、DIDエコシステムのあらゆる局面において基礎となるデータの表現方法が定義されています。

日本で特に必要になってきそうなのは、こちらの、VCが必要になってくるユースケースのまとめではないでしょうか。上記の私の簡単な解説では物足りない方は、ぜひ目を通してみてください。 __Verifiable Credentials Use-Cases __

DID-CORE 規格

Issuer, Subject (Holder), Verifierに関するPublic Keyなどの情報が書かれているDID Documentの場所を指しているIdentifierを定めている規格はこちら:Decentralized Identifiers (DIDs) v1.0

Decentralized Identifierと呼ばれる理由は、前述の通り、DIDを管理する(更新や失効など)中央型の組織がなく、DLTなどの分散型のストレージに頼っているからです。

W3C CCG

https://w3c-ccg.github.io/

DID Method Registry did-methodを記述するスペックが必要

1-A. 規格読み込み (分散型ID)【DIF編】

DIFとは

W3Cにおける規格化は、権威がある分、従うべきプロセスが定まっており、対象となる技術が決まっています。 そこで、高スピードで進行する、(既存技術の組み合わせではあるが)新しい分野である分散型アイデンティティにまつわる規格を策定するために設立されたのが、Decentralized Identy Foundationです。

VC/DID周りの規格のインキュベーションスペースでもありながら、近年、急成長をとげ、DIDエコシステムのキープレイヤーが集まっているため、VC/DID周りの規格が策定される場所としても認められつつあります。

DIF規格

私が、まず手を付けたのは、以下3つです。こちらは、成立には近いものの、まだ規格として成立しておらず、ドラフト段階です。

  • Presentation Exchange: VerifierとSubject/Holder間でやり取りをする際に、必要な情報を指定するための規格
  • Credential Manifest: IssuerとSubject/Holder間でやり取りをする際に、必要な情報を指定するための規格
  • Well Known DID Configuration: ドメイン名の保持者とDIDの保持者が同一であることを証明するための規格。Issuerへの信ぴょう性を高めるために必要

Caveat

他にもISOの規格なども読み込んでいたのですが、ISOの規格は購入が必要であることもあり、割愛します。

【コラム①】規格の重要性

本当は、このトピックだけで記事を書くべきなのですが、異なる製造メーカー横断でUSBを使うことができるのは、USB規格のおかげであり、全国でSuicaもPasmoもKitakaもIcocaも使えるのもICカード通信の規格のおかげである、という例のように、複数企業によるInteroperableで横断的なサービス・製品提供を可能にするのが規格なのです。

デジタル・アイデンティティは、デジタル世界で機能する全企業が頼るものであるため、規格化がかなり重要視されているのです。

※ 規格の標準化は、Patent/著作権保護以上の経済価値をもたらす、とヨーロッパでは研究結果が出ています。

【コラム②】その他DID周りのリソース

SSI Meet-upの動画シリーズが最強でして、全部見たいところなのですが、まずは、以下2つから手を付けてみました。

1-B. MSが提供するVerifiable Credentials as a Service by Azure AD (分散型ID)

私が異動した1か月くらい前という素晴らしいタイミングでMSが以前から取り組んでいた分散型IdentityのサービスであるVerifiable Credentials as a Service by Azure ADのプライベートプレビューが公開されました。

プライベートプレビューは、限られた数のお客さんのみに提供しているのですが、日本でも2件PoCが走っており、そちらに関われてとてもわくわくしています。

Subject/Holderがクレデンシャルを管理するウォレット(Microsoft Authenticator)がAndroid版しかなく、iPhoneしか利用したことのなかった私が初めてGoogle pixelを買ったのは、ここだけの秘密です。

自分独自のIssuerを作り、クレデンシャルを発行するためには、プライベートプレビューへのアクセス権が必要なのですが、それ以外のコンポーネントである、Verifier、ウォレットなどは、以下のGitHubのレポジトリ通りにデプロイできるので、ぜひお試しを!イシューやコメントなどぜひお願いいたします!

VCaaSのアーキテクチャ

ふじえさんのブログにアーキテクチャの図があったので引用。ほぼこちら通り、と考えていただいて大丈夫です。

DID architecture

もちろん、AADにベンダーロックインする気はなく、他のIssuerとの相互運用性のPoCも始まっております。

1-C. 規格策定WGへの参加 (分散型ID)

W3CおよびW3C CCGはメンバー加入が今週完了したので、来週から本格的に参加していきます。

DIFに関しては、ビジネスよりのAPACコール以外は日本の朝2-4時に行われることが多く、なかなかきついので、録画でキャッチアップしていました。

DIFのWG一覧

  • DID Commuunication
  • Identifiers & Discovery
  • Storage & Compute
  • DID Authentication
  • Claims and Credentials
  • Sidetree
  • Secure Data Storage

+ Governance + Interop (策定中。提案されているCharterはこちら)

※ DIFの各WGの方向性は先日行われたDIF F2F Virtual community meetingのまとめを読むとよく理解できるはずです。

※ WGに参加するためには、こちらのContribution Agreementに同意する必要があります。

DIF(Decentralized Identity Foundation)に無料で参加できるように!

DIF is opening up: Join for free: DIFが参加条件を変え、1000人以下の企業は、無料で参加できるようになりました。

参加はこちらから!

1-D. リーガル・リサーチ (分散型ID)

論点

以下2点、前から気になっていたので、調べてみました。

  • DIDにGDPRは適用されるのか
  • 適用される場合、ブロックチェーンを用いているDIDの仕組みにおいて忘れられる権利の扱いはどうなるのか

私がPolicy/Legalバックグラウンドであり、新しい視点をもたらしてくれるのではないか、とかなり期待されている部分もあり。

現時点での結論

日本語で簡単に要約すると、以下の通りになります。「DIDもパーソナルデータであると考えるべきであり、パーソナルデータを対象とするGDPRが適用される。ブロックチェーンを利用するシステムにおいては、忘れられる権利の施行が論点になるが、特定の条件を満たせば、忘れられる権利が適用されない場合も考えられる。」

In summary, "DIDs are usually considered personal data, but if certain conditions are met, the right to erasure does not apply" (still looking at different material)

  1. whether GDPR applies to DID systems ・ GDPR applies only to personal data. Case-by-case analysis is required, but in general, DIDs, credentials, revocations of credentials (as in Sovrin's revocation registry architecture) and hashes of data are all considered personal data. so yes, GDPR applies.

  2. can you argue that DIDs are not personal data ・ DIDs are the trickiest: to argue that DIDs are not personal data, you need to show that DIDs do not disclose "identity of the data subject" A. Show that DID does NOT work as an identifier and does NOT allow to linking different credentials/attributes (hard) ・ option1. use DIDs only once; ・ option2. use pairwise pseudonymous identifiers (in GDPR, you have to take into account "All means reasonably likely to be used" to relate information to an identified/identifiable natural person and even pairwise identifiers are seen as leaving a possibility for linking to an identifiable natural person. B. Show that DID metadata (ex. time of the creation of DID) can NOT be used to correlate other data

  3. when the right to erasure does not apply (addressing that it is very hard to delete one DIDs since they are stored in bulks) ・ option1: Establish that the data subject is the controller herself (determines the purposes and means of processing) ・ option2: Show that the household exemption applies (processing of personal data by a natural person in the course of a purely personal or household activity) - looking at court cases. does not usually work ・ option3: Show that the controller has a justification to continue to store the personal data

リソース

2-A. 規格読み込み (従来型ID)

OAuth & OpenID Connect

分散型アイデンティティの世界を実現しようとする際に、現在幅広く利用されている規格との親和性が鍵になってきます。 Modern Authenticationの場合、現在、圧倒的な人気を誇っているのが、OAuthとOpenID Connectなので、こちらの規格や実装の理解もかなり重要になってきます。(部分的にSAMLも)

分散型アイデンティティの場合は、初期から関わっており、NGOの方の活動で、実際に実装した経験もあることから、すぐに規格を読み始めても違和感はなかったのですが、OAuthとOpenID Connectに関しては、OAuth徹底入門で簡易実装をしたことはあるものの、まずは、実装や実装している人による解説を読んでから規格に手を付けようという作戦に出た私。

Authlete社が提供しているOAuthとOpenID Connectの資料のすばらしさ

個人的には、Authlete社と川崎社長ほどOAuthとOpenID Connectの規格を読み込んでおり、深く理解している人はいないのではないか、と思っているのですが、いずれにしろ、Authlete社のOAuthとOpenID Connectの資料はかなり質が高いのでかなりおすすめです。

以下の3つ、全部拝聴しましたが、とても理解が深まりました。

  • OAuth & OIDC 勉強会
    • 【入門編】 https://www.authlete.com/ja/resources/videos/20200317/
    • 【アクセストークン編】 https://www.authlete.com/ja/resources/videos/20200422/
    • 【認可リクエスト編】 https://www.authlete.com/ja/resources/videos/20200527/

Embedded content: https://twitter.com/kristinayasuda/status/1277462576587173889

今は、IETFのJSONやOIDFのJWTなどの規格も観ながら、OIDF(OpenID Foundation)の規格ひたすら読み進める私。。

SIOPが熱い

ここは、また別の機会に解説しますが、分散型アイデンティティとModern Authenticationのブリッジの一つとして期待されているのが、OIDCにおいて個人がOpeniD ProviderとしてふるまうSIOPという考え方です。

初期のディスカッションおよび伝上の実装状況は、こちらのSIOP Virtual Meet-upをご覧ください。

まだまだ詰めはこれからですが、今年後半、最も熱くなる議論だと個人的には予想しています。

2B MSが提供しているIdentityサービス (従来型ID)

Azure AD 製品開発チームのプログラムマネージャーが実施する日本語のWebinarが素晴らしすぎる

MSのIdentity周りのサービスはかなりたくさんあり、社内でも追うのが難しいのですが、まずは、Azure AD(B2C含めて)から始めようと思い、Azure AD 製品開発チームのプログラムマネージャーが実施する Azure AD Webinar (日本語)を活用していました。 クオリティが高くて、とてもよくまとまっていて、感動レベルです。

2C 規格作成WGへの参加 (従来型ID)

できるところから始めよう、ということで、OIDFのekyc-ida WG(Identity Assurance)に参加することから始めることに。

Identity Assuranceとは、どの機関が、どのトラストフレームワークを用いて、どのような方法で、どのような書類を確認することで個人を認証したのかを表現し、やり取りできるようにするための規格です。 例えば、XX銀行が、日本のAML法に基づいて、対面で、運転免許証とパスポートを用いて個人認証をした、ということが証明できるようになるのです。特にヨーロッパのユースケースについて議論が盛り上がっています。

私は主に、Selective Disclosureの観点から貢献しようと頑張っています。(ここもまた後日解説します。

3A Identiverse (横断的)

業界一大イベントの一つである、Identiverseが今年はすべてオンラインになったので、業界全体の動向を追うためにぼちぼち見ていました。

全セッションリストはこちら

私がみたのは、以下です。

  • Distributed Open Identity: Self-Sovereign OpenID: a Status Report Speakers: Nat Sakimura, Preeti Rastogi
    • SIOP Virtual Meet-upのサマリ
  • Identity Assurance with OpenID Connect Speaker: Daniel Fett
    • 規格を読んで理解はしていたけれども、素晴らしいサマリ。裏にある考え方も良く理解できる。
  • Identity Standards: What's Up, What's New, What's Next Speaker: Alex Simons
    • MSのIdentity Standardsの注力ポイントは、FIDO2・DPoP、Decentralized Identityです。
  • A Balancing Act: Identity, Privacy, and Security in a Data Sharing Economy Speakers: Alice Wang, Heidi Wachs, Pamela Dingle, Christina Morillo
    • Identity業界って女性が少ないなと思う今日この頃…
  • Enabling Scalable Multi-Lateral Federations with OpenID Connect Speaker: Michael Jones
    • 特にEducation & Reseach業界向けに、SAMLのKerberosベースのFederationの代替としてOIDCベースのTrust ChainモデルのFederationモデルを提案。
  • The Power of SCIM Speakers: David Lee
    • 複数の組織間で情報をやり取りする際に、互いのAPIの変更を気にしなくても良いように作られた”Universal Controller”的な規格。ResourceとSchemaが重要コンポーネント。面白かった。
  • Diagramming your Identity Integration: A Picture is Worth a Thousand Words Speaker: David Gersh
    • Diagramの種類などはよくわかったのですが、それぞれの違い・使い分け方や作成方法はよくわかりませんでした…
  • Is Homomorphic Encryption a Reality? Speakers: Rajan Behal, Sriram Ravikumar
    • Homomorphic EncryptionはまだまだこれからでMSがここにも投資をしており、投票への実用化を目指していることがわかりました。

正直、全部見たいけれど、それも難しいので、他の人のおすすめや、スピーカーで選ぶようにしています。

3-B. Pluralsight

技術を短期間でキャッチアップするために私が工夫しているのは、Pluralsightで気になる技術テーマを検索して1-2時間の初心者向けのコースを受講してしまうことです。 もちろん、その分野のエキスパートにはなれないけれど、その分野の人と会話ができるようにはなります。

Designing RESTful Web APIs

アイデンティティやセキュリティを勉強していると、この規格や仕様は「情報をやり取りする際に利用するAPIを守るため」に必要、という文脈がよく出てきます。 APIとは何か、なんとなくわかったつもりではいたけれども、もっとちゃんと理解する必要があるのではないかと思い、Pluralsightで検索し、こちらのDesigning RESTful Web APIsという2時間くらいのコースを受講することに。

コースの過程でPostmanという「API開発のためのコラボレーションプラットフォーム」の使い方を学んだのですが、掘ってみたら、AADともばっちり親和性があるようでびっくり: Getting started with Windows Azure AD Authentication using Postman

Node.js: Getting Started

2-Bで実際にMSのVerifiable Credentials as a ServiceのGitHubレポジトリを触って実装する必要があったのですが、自分のIssuerを作り、独自のVCを発行しようとすると、サーバーサイドの準備が必要であり。。こちらのNode.js: Getting StartedコースでNode.jsを少しキャッチアップすることに。(まだキャッチアップ中w

MSのGitHub触る機会増えそうなので、TypescriptとC言語系もお勉強しなきゃ…

その他

DIFの新しいInterop WGでの議論で私が理事を務めるMyData Globalとのコラボレーションについて打診があったため、最近発行され、MyData Globalの活動のコアになりつつある、Understanding MyData Operatorsというホワイトペーパーに目を通すことに。どちらかというとポリシーよりで、 もっとActionableな内容にこれからなっていくことに期待したい。

※ MyData Japanによる日本語版はこちら

Next Steps

たくさんありすぎるのですが、上記のシラバス通りに知識を身に着けつつ、イシューやPRやコールで少しずつ貢献できるようにしていかないと。

ちなみに、今のロールに向けて準備をしていた際のStudy Planをレビューしてもらったの際に、TCP/IP、HTTP、DNSを勉強するのがよい、と崎村さんから頂いたアドバイスには感謝しきれません!この3つの基礎を事前にカバーしておいて本当によかった。 今、この3つに今付け加えるとしたら、APIの知識ですかね(笑)

終わりに

退屈する暇はなかった本当に朝から晩までID付けの幸せな3週間だったことがお分かりいただけたのではないでしょうか(笑)

これからにご期待ください~