Identity
Blockchain
Microsoft

分散型ID ラーニングパス

2020-12-09 15:00

Intro

分散型IDに関する情報がウェブ上に溢れており、片っ端から読んではいるけれど、なかなか理解が深まらないということもあるかと思います。私も苦労しました。（今もしています笑）

分散型IDに関する規格は、以下の図からわかるように、たくさん存在し、互いに依存したり、関係し合っています。

diagram-VC Spec Relationships

from Verifiable Credentials Specification Map

そこで、この順番で読めば理解が深まるのではないか、というラーニングパスを作ってみました。

※ まずはVer01(2020-12-10)。徐々にアップデートしていきます。

ラーニングパス

  • 前提知識

    • JSON：開発者フレンドリーなデータフォーマット
    • JSON-LD：データに関係性を持たせることができるデータフォーマット。データ間の関係性を可視化するセマンティックウェブなどを起点に始まった。規格が不安定かつ最新情報が反映されていないため、取り扱い注意。既に実装している人に聞く方は早い。
    • JWT, JWS, JWK, JWAあたり：署名・暗号化が多用されており、非対称暗号技術（秘密鍵・公開鍵）がコアにあるので、その表現方法は必須。
    • ユースケースによっては、CBORのような他のデータフォーマットの知識も必要になってくるかもしれません。

  • 基礎

    • DID Land - DID-CORE: https://www.w3.org/TR/did-core/

      • 個人がプロバイダに依存せずに情報を提供する際に、自分を識別するための分散型識別子
        • DID-Resolution: https://w3c-ccg.github.io/did-resolution/
          • 分散型識別子をユーザーからもらったRelying Partyが、その識別子の真正性を確認するための情報（鍵情報など）が含まれているDID Documentを取得するためのプロセス
        • Did-spec registries：https://w3c.github.io/did-spec-registries/
          • DIDの実装において、規格で定義されておらず、実装者に任されている部分が管理されているレジストリ。おりDID Documentの記録先（ブロックチェーンなど）や委員会DIDからDID Documentを取得する方法は、W3C CCGにDIDメソッド
        • Did-use-cases: https://www.w3.org/TR/did-use-cases/
        • ユースケースを見るのが一番イメージ沸くかと。もちろん、ここに記載されていないユーズケースに期待です。

    • VC Land (Verifiable Credentials)

      • VC-data model: https://www.w3.org/TR/vc-data-model/
        • DIDは識別子でしかないので、識別子に紐づいている属性情報を表現するためのデータフォーマットが必要です。DIDとVCは相性は良いですが、必ず一緒に使われる必要はありません。別の識別子と組み合わせたVCのみの利用も十分考えられます。
      • VC-use-cases: https://www.w3.org/TR/vc-use-cases/
        • ユースケースを見るのが一番イメージ沸くかと。もちろん、ここに記載されていないユーズケースに期待です。
      • VC-imp-guide: https://w3c.github.io/vc-imp-guide/
        • 実装するためのガイドライン。技術者の方は手を動かして実装してみることがおすすめですし、技術者ではなくても、規格の文章では表現しきれない詳細を理解するのにはうってつけです。

    • Transport：DIDやVCをどのようにやり取りするか、幅広く使われているHTMLを使う実装と、新しいP2P通信プロトコルであるDIDCommを使う、大きく2つの方向性があると、認識しています。DIDCommについてはHTMLをP2Pな感じに0から作り直そうとしているようなものなので、商用向けに利用するには、セキュリティなど、結構、懸念事項があるようです。。

      • HTML(OIDC) or DIDComm
        • OIDC: https://openid.net/specs/openid-connect-core-1_0.html
        • DIDComm:https://identity.foundation/didcomm-messaging/spec/

    • Credential presentation：どの属性・クレデンシャルが欲しいかを、やり取りするEntity間でコミュニケーションする必要があります。

      • Presentation Exchange: https://identity.foundation/presentation-exchange/ （Relying Partyと個人の間）
        • Credential Manifest: https://identity.foundation/credential-manifest/ （Issuerと個人の間）

    • Option（余力があれば。）

      • Well-known-did: https://identity.foundation/.well-known/resources/did-configuration/ DIDによって、どのIssuerがどのVCを発行したかはわかりますが、結局、そのIssuer自体が、本当に信頼できるエンティティによってコントロールされているかは、わかりません。DNSのドメインをコントロールしているエンティティがIssuerです、と証明することでその問題を解決しようとしているのが、この規格。

    • Other Data formats

      • Open Badges: https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html
        • 教育業界で広く使われているクレデンシャルフォーマット。署名を定義はしているが、一般的な実装では利用されていない模様。OpenBadgesへのリンクをVCに含めるのが妥当か。。
      • 一企業に依存しないDIDメソッド
        • DID-method-key: https://w3c-ccg.github.io/did-method-key/
        • DID-method-peer: https://identity.foundation/peer-did-method-spec/
        • DID-method-web: https://w3c-ccg.github.io/did-method-web/