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

2024年7月2日火曜日

論文)Decentralized Identifiers (DID) とVerifiable Credentials (VC) の現況

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

慶應義塾の鈴木 茂哉先生がメインライターのDIDとVCに関する解説論文が出ています。


https://www.jstage.jst.go.jp/article/essfr/18/1/18_42/_article/-char/ja

Decentralized Identifiers (DID) とVerifiable Credentials (VC) は,ディジタルアイデンティティの新しい実装形態として注目されている.従来型のディジタルアイデンティティのモデルでは,アイデンティティサービスを提供する主体が,ユーザの同意の元,ユーザ情報を,その情報を必要としている主体に提供していたが,VCによるモデルでは,ユーザ自身が,自身に関する情報を提供できるようになり,ディジタルアイデンティティの繊細なコントロールを可能としている.このモデルの中心となるのは,データモデル,非対称鍵暗号,発行・検証プロトコルなどであり,技術開発と標準化が積極的に進められている状況にある.本論文では,VCによるモデルとそれをとりまく検討状況について,背景,標準化,関連プロトコル,応用事例,課題や論点について概説する.(JStageに記載の抄録より)


おそらく現時点では関連する技術仕様が一番コンパクトにまとまっている論文だと思いますので、ぜひ読みましょう。

(私も微力ながらお手伝いさせていただきました)


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 v2やOIDC4VPとか。
    • そもそも論、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年1月16日土曜日

MATTRの分散型IDプラットフォームを触ってみる - その 1

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

ここ数年、uPort〜Microsoft VC as a Serviceなど分散型ID(DIDs/VCs*)に絡んでいるわけですが、一昨年秋のIIWに参加したときにPoCの話を聞いたMATTRのプラットフォームがかなりいい感じに進化していたので触ってみました。

* DIDs: Decentralized Identifiers

* VCs: Verifiable Credentials


MATTRについて

会社自体についてはそこまで詳しく知りませんが、ニュージーランドの会社です。

この辺りやこの辺りでは有名ですね。

現在、MATTRが提供しているのはプラットフォームと関連する開発ツール群のようです。

(プロダクトページより)


MATTR Platformについて

プラットフォームはコア機能として、

  • DID
  • Messaging
  • Verifiable Credentials
  • Verifiable Presentations
に関する生成、取得、削除、検証に関する機能群を提供しています。

また、拡張機能として、
  • OIDC Bridge
  • White Label Mobile Wallet & SDKs(提供予定)
が、ロックイン回避のために以下の機能もあらかじめ提供しているようです。
  • 複数のDID Methodのサポート
  • Secure Storageのサポート
  • プラガブルなKey Managementのサポート
IIWではOIDC Bridgeの部分のデモを見せてもらいました。
当時、私はuPortとAzure AD B2CとLibJeIDを組み合わせて免許証をトラストアンカーにしたuPort Credentialを発行、B2BのWebサイトでの身元確認を行う、というようなデモを作ったりしていました。懐かしい。


開発ツールについて

プラットフォーム以外にも開発者向けに以下の機能が提供されています。
  • MATTR Mobile Wallet App
  • Sample Applications
  • MATTR Command Line Interface(提供予定)


今回、プラットフォームのコア部分に関するSandbox環境を払い出してもらったので少し触ってみます。

では、早速レビューを。

トライアル申し込みをする

まずは環境をもらうところからですが、先程のプロダクトページの一番下にSandbox環境のトライアル申し込みがあるので申し込んでみました。

しばらくするとメールとSlackへの招待がくるので、Slackで担当の方と会話をすることになります。基本的にはKeybase上でトライアルテナントの情報とかシークレットなどを渡すからまずはKeybaseのアカウントを教えるように言われるのでアカウント名を伝えます。
(Keybaseのアカウントを作るところから始めました)

アカウントを伝えると今度はKeybaseのチャットで担当の人から以下の情報をもらえます。
  • tenantSubdomain: xxxx.sandbox.platform.mattr.global
  • tenantId: xxx-xxx-xxx
  • url: https://mattr-prod.au.auth0.com/oauth/token(Auth0使ってるんですね)
  • audience: https://platform.mattr.global
  • client_id: xxxxxxxxxxx
  • client_secret: xxxxxxxxxxx

プラットフォームの設定を行う

先にもらった情報があるとプラットフォームにアクセスできるようになります。(といってもAPIだけしか存在しないので、APIを叩きまくるんですが)

詳細は
に手順がのっているのでこちらをみながら進めます。

API Auth Tokenを取得する

要するに、先程Keybaseで伝えられたclient_idやclient_secretはAuth0のプラットフォームでaccess_token(MATTRプラットフォームのAPI Auth Token)を取得するためのものだったわけです。
普通にclient_credentialsでaccess_tokenを取得します。

curl --request POST \
  --url https://mattr-prod.au.auth0.com/oauth/token \
  --header 'Content-Type: application/json' \
  --data '{"client_id": "xxxxxxxxxx",
           "client_secret": "xxxxxxxxxx",
           "audience": "https://platform.mattr.global",
           "grant_type": "client_credentials"
          }’

DIDを生成する

まずはDIDを生成してます。
methodとしてはkey、web、sovの3種類をサポートしているようです。
didのエンドポイントにAPI Auth Tokenをつけて生成リクエストをPOSTするだけなので非常にシンプルです。
curl --request POST \
  --url https://tenant.platform.mattr.global/v1/dids \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer REPLACE_ACCESS_TOKEN' \
  --data '{   "method":"key",
              "options": {
                  "keyType":"ed25519"
              }
          }'

うまくいくとDID Documentが返ってきます。
MATTRのResolver APIもありますが、Universal Resolverでもちゃんと解決できるようになります。

Issuerに関する情報を確認する

DIDを発行することでIssuerのDID構成情報を確認することができるようになります。DIFのWell Known DID Configurationのスペックに対応しているようです。

curl --request GET \
  --url https://tenant.platform.mattr.global/.well-known/did-configuration \
  --header 'Accept: application/json'

結果、IssuerのDID構成情報が確認できます。

VCを発行する

こちらもAPIが用意されていますので、IssuerのDID、SubjectのDID、VCに含めるClaimなどを決めてPOSTしてあげるだけです。
curl --request POST \
  --url https://tenant.platform.mattr.global/v1/credentials \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer REPLACE_ACCESS_TOKEN' \
  --data '{"@context":["https://www.w3.org/2018/credentials/examples/v1" , "https://www.w3.org/2018/credentials/v1"],
           "subjectId":"did:key:z6MkjBWPPa1njEKygyr3LR3pRKkqv714vyTkfnUdP6ToFSH5",
           "type":["AlumniCredential"],
           "claims":{"givenName":"Jamie",
                     "familyName":"Doe",
                     "alumniOf":"Example University"},
           "issuer":{"id":"did:key:z6Mkg7FkYxUpSKBEUJMeG91A9vz66GfWxB4m9Lq81AMZ7wNT",
                     "name":"Example University"},
           "persist":true,
           "revocable":true
          }'

ありがちな卒業生である証明を発行するサンプルですね。

発行したVCは同じAPIのエンドポイントにGETしてあげると一覧表示されます。

とりあえず最低限必要な機能はちゃんと動いていますし、他にもVCのRevokeなど管理系のAPIも充実している感じです。

Walletアプリも使えるようにしてもらったので、次回はOIDC Bridgeと合わせてWalletへのVP/VC発行とOIDC-DID Authのゲートウェイでのログインなどチュートリアルにそって試してみようかと思います。

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年7月23日木曜日

[DID]リゾルバあれこれ

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

完全に個人メモです。

ご存知の通りDID(Decentralized Identifier)の構造は
did:{method}:{method specific identifier}
となっています。

例えば、イーサリアムだったら
did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
という感じです。

現状Blockchainの系がバラバラと乱立している状態なので、系の間でユニバーサルに一意に識別できる仕組みがないとDIDがIdentifier(識別子)としての役割を果たせないことはわかるんですが、そもそも論としてメソッド名が識別子の中に入っているって言うのもなぁ、と個人的には思いますが他にいいアイデアが出せるわけではないので自粛しておきます。

話はそれましたがDIDが上記の様な形式になっている以上、系を跨いで識別子(DID)および関連する情報(DID Metadata)を解決する仕組みがないと、DIDを使ったアイデンティティ管理システムが成立しません。ということで今日の本題の「リゾルバ」が必要になるわけで、実質標準になっているのがMarcusがやっている「Universal Resolver」である、というわけです。

元々DID関係はW3CのWeb Payment WG、Verifiable Credentials TF、OASISのXDI TC Registry WGが別々にやっていて、2015年〜2016年あたりでDPKIとかのドラフトとして出てきた中でレゾルバの必要性に注目してUniversal Resolverを作った、みたいな話を2018年のEuropean Identity and Cloud ConferenceでMarkusから聞いたとき、リソルバ自身の信頼性ってどうやって担保するの??みたいな話を聞いた覚えがあります。その時にMarkusはリゾルバ自体はOSSだからプライベート実装しても良いし、アプリに組み込んでも良いよ、みたいな話をしていました。

そんな中でMarkusがサンプル実装として公開したのが先の https://uniresolver.io/ で、他にもベンダが実装してきている例としてMicrosoftが自前のDID Projectで実装したのが、 https://beta.discover.did.microsoft.com/ だったりする、ということなんですね。

と言うことで、それぞれどんな感じなのかみてみようと思います。

登録されているDID method

そもそも現在どんなDID methodが存在しているのか、という話になるのですが、DID methodはW3Cのコミュニティグループで「ゆるく」管理?されています。

https://w3c-ccg.github.io/did-method-registry/

今日(2020/07/23)の段階で59個も登録されてるんですね。残念ながらuPortはdeprecatedになってます(単にethrに引っ越しただけですが)。

Universal Resolverの状況

Universal ResolverではメソッドをサポートするためにDriverという単位でプラグインを追加していく形になります。

githubのレポジトリを見るとDriverの開発の方法や現在開発されているDriverの一覧を確認することが出来ます。

https://github.com/decentralized-identity/universal-resolver/

同じく今日時点で28種類ある様です。

使い方としては非常にシンプルでUniversal Resolverをデプロイし、エンドポイントに対して
curl -X GET http://localhost:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
という感じでGETしてあげればDID metadataが返ってくるという仕掛けです。

これをWebで簡単に触れる様にしたのが先に書いた

https://uniresolver.io/

ってことです。


Microsoftの実装は?

前回のポストでも紹介しましたがMicrosoftもDIDの世界に突き進んでいるわけですが、当然マネージドなリゾルバを提供しています。
公開されているサンプルソースを掘っていくと、

https://beta.discover.did.microsoft.com/

というURLが出てきます。

ご存知の通りMicrosoftのDID/IONのメソッドは ion で、現在Universal Resolverではサポートされていません。ionメソッドのDIDをUniversal Resolverで解決しようとしてもNFです。



と言うことでMicrosoftのDIDを解決するには上記のリゾルバを使うしかなさそうです。

使い方としては、Universal Resolverと同じで


curl -X GET https://beta.discover.did.microsoft.com/1.0/identifiers/did:ion:EiBo3GQwMgF...
と言う感じです。

DID metadataの視認性を上げるためにFirefoxで開いてみます。


ふとした疑問として、どこまでMicrosoftのリゾルバは他のメソッドをサポートしているんだろう?と思って実験してみました。サンプルとして使ったDIDはUniversal Resolverのレポジトリにあるテスト用のものを使いました。

以下が結果です。
method support
sov OK
btctr OK
v1:test OK
key OK
ipid NG? Universal ResolverでもTimeoutするのでipid側の不具合かも
web NG? サンプルになっているのがdid:web:uport.meなのでDIDの問題かと
ethr NG. Timeout
nacl OK
jolo NG. Timeout
stack OK
erc725 NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
hcr OK
neoid NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
elem NG
github NG
ccp OK
work OK
ont OK
kilt OK
evan OK
echo OK
factom OK
dock OK
abt OK
trustbloc NG
sirius NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
mpg NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
trust NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
io NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい



ということで完全に自分メモでした。





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年5月27日月曜日

de:code 2019でKYCとDecentralized Identityの話をします

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

先日のEuropean Identity & Cloud Conferenceでの登壇に引き続き、今年もde:code 2019でお話させていただきます。Webサイトには所属組織名として会社名も書いてありますが、今回は基本的にOpenIDファウンデーション・ジャパンの帽子でのお仕事です。

春のde:code、秋のTech Summitと日本マイクロソフトの大型イベントでここ数年連続でセッションを持たせていただいておりますが、大型のイベントでの登壇はオーディエンスの属性も様々なので内容とレベル設定に気を使いますね。

今回は「これからのKYCとIdentity on Blockchainの動向」というタイトルで、金融機関等におけるKYCの課題とIdentity on Blockchain、いわゆるDecentralized Identityが解決するための手段になりうるのか?という観点で最近の動向についてお話させていただこうと思います。そして、この内容を「レベル200=初級者向け」に解説しなければならない、というまた難題を・・・。(前回レベル詐欺と言われたので今回は反省して細かい部分は最低限に抑えるつもりではあります)

内容的にはOpenIDファウンデーション・ジャパンのKYCワーキング・グループで議論している内容や、先日ポストした自己主権型アイデンティティの話を中心に、KYCにおける属性情報の受け渡しと検証を誰がどうやって簡単かつ確実にするのか?みたいな話について私の考えをお話しようと思っています。

フェデレーションの様に一部のIdentity Providerに依存するモデルから、自己主権型アイデンティティでの主権・自由と引き換えに責任を自分で負うモデル、情報銀行の様に属性情報の管理を委託するようなモデルなど、色々な考え方への遷り変りの話なども少し紹介できればと思っています。


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

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自体の定義も議論の途中で非常にふわふわした状態ですが)


当日のまとめはこちら

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