Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SSIの全体像とHyperledger Ariesを使ったシステム構築

SSIの全体像とHyperledger Ariesを使ったシステム構築

SSI/DID/VC領域においては、W3C、DIF、Hyperledger Indy/Aries、
OpenID Foundationが互いに関連しながら標準仕様を持っており、
新規参入者にとって全体像が掴みにくいと思われます。
そこでToIP Technology Stackのレイヤーごとに、
これらの団体と仕様の関連からWeb5などのOSSとサービス提供者までを整理し、
その全体像と直近の業界の流れをご説明します。
また、OSSとしては最も成熟していると思われるHyperledger Ariesの
処理方式とその使い方から、我々が構築したデモシステムについて ご説明します。
(イベント: https://oracle-code-tokyo-dev.connpass.com/event/285743/)

Takahiro Kanuma

July 18, 2023
Tweet

Other Decks in Technology

Transcript

  1. SSIの全体像と
    HL Ariesによるシステム構築
    Blockchain GIG #15
    神沼 貴⼤(@t_kanuma)
    2023/7/12

    View Slide

  2. 会社概要
    2
    GMOグローバルサイン・ホールディングス株式会社
    本社所在地
    事業内容
    代表者名
    設⽴
    資本⾦
    上場市場
    連結従業員数
    加盟団体(抜粋)
    東京都渋⾕区桜丘町26-1 セルリアンタワー
    クラウドホスティング及びセキュリティサービスを中核とした
    各種インターネットソリューションの開発・運⽤
    代表取締役社⻑執⾏役員 ⻘⼭ 満
    平成5年12⽉
    9億1,690万円
    東京証券取引所プライム市場(証券コード︓3788)
    社員972名
    ⽇本ネットワークセキュリティ協会
    トラストサービス推進フォーラム
    デジタルトラスト協議会
    ⼀般社団法⼈⽇本クラウド産業協会(ASPIC)
    電⼦認証事業および創業以来提供しているホスティング事業から、AI・IoTを活⽤したサ
    ービスにいたるまで、ITのチカラでお客さまのビジネスを⽀えています。
    ● 電⼦認証・印鑑事業
    ● クラウド・インフラ事業
    ● DX事業
    ※2022年12⽉31⽇現在
    •「GMOおみせアプリ」導⼊店舗数 2万店以上 (2022年3⽉末時点)
    •「SSLサーバ証明書」発⾏実績 1,600万枚以上 (国内シェアNo.1※)
    •「電⼦印鑑GMOサイン」 導⼊企業数 190万社以上 (2022年3⽉末時点)
    ※ 2023年3⽉末時点 「SSL Survey by Hosting Country」より
    • 提供実績26年
    • クラウドインフラサービス契約件数 約8万件 (2022年12⽉末時点)

    View Slide

  3. ざっくりした流れ
    3

    View Slide

  4. 前提: SSI/DID/VCの範囲
    ● ⼈によって⼤分認識が異なるのではないか︖
    ● 私の取り組み
    ● 既存のIdentity分野の延⻑線上にある⾊合いが強い。
    ● SSI空間全体の⼀⾯、部分
    ● (何事にも多様性は⼤事だと思う。否定的、攻撃的な意図はありません。)
    ● 私の取り組み︓Web3/Crypto領域のモノとは思っていません。No Tokens.
    ● Web3/Cryptoについては無知です。
    4

    View Slide

  5. 前提: SSI/DID/VCの範囲
    ● W3C
    ● Decentralized Identity Foundation (DIF)
    ● Hyperledger Indy/Aries
    ● OpenID Foundation
    ● Web5
    5

    View Slide

  6. SSI/DID/VCを理解するための良い⼿段は︖
    オープンスタンダード(とそれに付随するドキュメント)をフルスキャンすること
    ● W3C
    ● VCs Data Model
    ● VCs Data Integrity
    ● VCs Impl Guidelines
    ● DID Core
    ● DID Specification Registries
    ● DID Resolution
    ● Revocation List 2020
    ● Status List 2021
    6
    ● did:web
    ● did:sov
    ● did:key
    ● Securing VC using JWT
    ● JWT VC Presentation Profile
    ● Universal Wallet 2020
    ● VCs JSON Schema 2022
    ● Encrypted Data Vaults

    View Slide

  7. SSI/DID/VCを理解する⼀番の⼿段は︖
    ● DIF
    ● DID Registrar
    ● well-known DID configuration
    ● Sidetree
    ● did:peer
    ● DIDComm
    ● Decentralized Web Node
    ● Wallet Rendering
    ● Credential Manifest
    ● Presentation Exchange
    ● WACI-DIDComm Interop Profile
    ● The BBS Signature Scheme
    7

    View Slide

  8. SSI/DID/VCを理解する⼀番の⼿段は︖
    ● Hyperledger Indy/Aries
    ● Indy SDK/Node/Plenum
    ● AnonCreds
    ● did:indy
    ● Aries Interop Profile
    8

    View Slide

  9. SSI/DID/VCを理解する⼀番の⼿段は︖
    ● OpenID Foundation
    ● OpenID for Verifiable Credential Issuance
    ● OpenID for Verifiable Presentations
    ● Self-Issued OpenID Provider
    ● IETF
    ● SD-JWT
    9

    View Slide

  10. SSI/DID/VCを理解する⼀番の⼿段は︖
    前半: 細かいことは気にせず、ざっくりと(私が考える) 全体感をご説明
    10

    View Slide

  11. 1. ToIP Tech StackのLayerごとに仕様/実態の特徴⽐較
    11
    SSI
    仮説:アプローチ⼿法として、ToIP Tech Stackを
    使ってみると、全体感を理解しやすくなるかもしれない。
    (OAuth/OIDCが厳密に当てはまらないのは承知の上で)
    VC
    • 思想
    • イデオロギー
    Entity/
    Agent
    DID
    Layer 1: DID Methods
    Layer 2: Agents and Communication
    Layer 3: VC, Trust Triangle
    Layer 4: Apps, Ecosystem
    Open Standards
    did:web did:indy did:ion
    ToIP Tech Stack
    コア要素
    仮説:宗教の中の宗派のように、それぞれ⼤事にしているポイントが異なる。
    それを前提に、ポイントを⽐較することで理解が進むかもしれない。

    View Slide

  12. 2. 仕様セットごとの特徴⽐較
    12
    SSI
    VC
    Entity/
    Agent
    DID
    Layer 1: DID Methods
    Layer 2: Agents and Communication
    Layer 3: VC, Trust Triangle
    Layer 4: Apps, Ecosystem
    Open Standards
    did:web did:indy did:ion
    ToIP Tech Stack
    コア要素

    View Slide

  13. 2. 仕様群ごとの特徴⽐較 / 3. エンジニアとして開発の選択肢
    13
    仕様群 per
    管理団体
    OSS
    サービス
    (プラットフォーマー)
    サービス
    (プラットフォーマー)
    実装
    ラップ
    実装

    View Slide

  14. 後半
    Hyperledger Indy/Ariesを使ったシステム構築の流れ
    14

    View Slide

  15. ToIP Technology Stack
    15

    View Slide

  16. Trust over IP Foundation
    ● IP = Internet Protocol
    ● デジタル空間でトラストを形成するために、
    DID/VCを⽤いた相互運⽤性のあるアーキテクチャ/モデルを策定
    ● コンセプトは国が推進するTrusted Webに近いかも︖
    16

    View Slide

  17. ToIP Technology Stack
    17
    [出展] The Trust Over IP Model

    View Slide

  18. Layer 1
    ~DID Methods~
    18

    View Slide

  19. DID
    DIDとは結局何なの︖:
    公開鍵とエンドポイントで構成されるJSONを指すポインター/ロケーター
    19
    DID
    DID Document
    公開鍵
    エンドポイント
    resolve

    View Slide

  20. DIDの⽤途分解
    20
    公開鍵 /
    エンドポイント
    署名
    VC
    (by Issuer)
    通信
    VP
    (by Holder)
    Public DID
    (e.g. web, indy, ion...)
    Public DID
    (e.g. key, web, ion...)
    Private Holder Binding
    (e.g. Link Secret)
    VCのPossession証明
    HolderのCorrelation(名寄せ)リスクあり
    IDをexposeしない
    Correlation対策
    Public DID
    (e.g. web, indy, ion...)
    Pairwise DID
    (e.g. peer)
    Correlation対策
    HolderのCorrelation(名寄せ)リスクあり
    Layer 3(VC種別)
    Layer 2
    Layer 1

    View Slide

  21. DID Method
    ● メソッドによって何が異なるか︖
    1. DID Documentの保管⼿法(どこにどう保管するか)
    2. Method Specific Identifierの作り⽅(e.g. did:key:foobarbaz)
    3. DID Operation/Resolutionの⼿法
    ● Operation = Create, Update, Deactivate
    ● Resolution = Read
    21
    Layer 1: DID Methods
    did:web did:indy did:ion

    View Slide

  22. did:web
    ● WebサーバにDID Documentを保管
    ● GET https://{domain}/.well-known/did.json
    ● ドメインを持つエンティティが管理
    ● 現実的にはIssuerがサーバ⽴てる︖
    ● DID Doc取得者は以下を信⽤する。
    ● 既存のインターネットの中央集権的なインフラ
    ● DNS
    ● 電⼦認証局
    ● 中央集権的に管理されるWebサーバ / 管理主体
    22

    View Slide

  23. did:web
    23

    View Slide

  24. did:web
    24
    Holder
    Issuer Verifier
    Issuer Webサーバ
    DID Document
    ①VC発⾏
    ③VP提⽰
    SSIポイント: 「提⽰の際にIssuerに問い合わせない /
    フィジカルな紙のモデルと同等にする」
    はクリア。
    - Issuerの負荷軽減
    - IssuerにVC利⽤をトレースされない。
    - + パスワードレス
    GET https://{domain}/.well-known/did.json
    ④公開鍵取得
    ⑤VP検証失敗
    ②公開鍵改ざん
    例: (Issuer)あのHolderムカつくから公開
    鍵、改ざんしてやんべ︕
    -> 社会的信⽤を失うだけであり得ないの
    では。
    例: サーバを攻撃されていつの間にか
    改ざんされている︕
    -> ただの当たり前で普遍的なリスクでは。
    中央集権的な仕組みを危惧するなら、
    ブロックチェーンが選択肢になる。
    中央集権的
    中央集権的
    中央集権的

    View Slide

  25. did:indy
    ● Hyperledger Indy(OSS)を使ったDLT/分散台帳。コンソーシアム型。
    ● Redundant Byzantine Fault Toleranceベースのコンセンサスプロトコル
    ● ブロックはチェーンしていない。
    ● Validator Nodeとしてネットワーク参加は許可制
    ● TX書き込みクライアント(=Issuer)は許可制
    ● TX読み取りクライアント(=Holder/Verifier)は誰でもなれる。
    ● 稼働ネットワーク例
    ● Sovrin: ⾮営利団体運営の最⼤規模のネットワーク
    ● IDUnion: ヨーロッパのエンタープライズ企業で構成
    ● Indicio: ⺠間企業運営のネットワーク
    25
    [1]

    View Slide

  26. did:indy
    26
    Agent
    Indy Node
    Indy Node
    Indy Node
    Agent
    [1]
    HTTPでいけるのでは︖(DNS、認証局に依存しない)
    [TX書き込み]
    • 改ざん検知: DIDで署名して送信する。
    • 暗号化: 内容はPublicな情報
    [TX読み込み]
    • 改ざん検知:
    • TX群をRocksDB(KVS) + Merkle Patricia Treeで管理
    • 全ノードがRoot HashにBLS Multi署名
    • ClientはMerkle proof-of-inclusionとノード署名を検証
    • 暗号化: 内容はPublicな情報

    View Slide

  27. did:indy
    27
    Sovrin IDUnion
    Agent
    did:indy:sovrin:abcde123
    did:indy:idunion:xyz456
    Indy Node
    Indy Node
    Indy Node
    DID Doc

    View Slide

  28. did:ion (Sidetree実装 / Identity Overlay Network
    28
    クライアント
    IONノード
    Bitcoin IPFS
    IONノード IONノード
    DID ResolutionのRequest
    クライアント
    DID OperationのREST API Request
    Batch Write
    定期Readとローカルキャッシュ
    DID Operation(DID Documentに対するCUDのTX)が発⽣した順序を保証するために、
    中央集権無しでその機能を持つBitcoinを使う。
    Storing DIDs on ION (a Layer 2 DID network that runs on top of Bitcoin)
    is a preferred design decision for the implementation of Web 5.
    ION is a decentralized replacement for DNS for identity identifiers, so there
    are no authorities, coordinators, tokens, or other centralized bottleneck.
    [出展]: What is Web5?(TBD)

    View Slide

  29. did:ion
    29
    [出展] DIF Sidetree Protocol [出展] The Sidetree Protocol: Scalable DPKI for
    Decentralized Identity

    View Slide

  30. 各DID Methodのイデオロギー⽐較(私的妄想 – こう考えると区別、理解しやすいかも
    )
    30
    did:web
    ⾮中央集権?/⾮集中?/分権?/分散?の度合い
    低 ⾼
    did:indy did:ion
    • パスワードレスとIssuer(IdP)の集中度合いの
    分権は実現できているわけだし、
    SSIとして、それで⼗分でしょ︖
    • 今のインターネットの中央集権インフラ
    (DNS、認証局)でいいじゃない。
    • ⾃分で改竄なんてしたら社会的信⽤失うだけ。
    攻撃にはしっかりサーバー管理すれば良い。
    問題視する必要ある︖
    • 分散台帳、ブロックチェーンなんて⼤それた
    仕組み使う必要ある︖
    ⾮改ざん性⾼いし、
    私が⼀番、分権のバランスが良い。
    • 改ざんリスク︕ -> did:web
    • 中途半端やねん︕ -> did:indy
    -> did:ion
    本当に持続可能なの︖
    • 変動性⾼い。
    • 分散と⾔いながら、BTCの保有具合はパレートの法則やん。
    • 発⾏上限に達してモノよりBTCの価値が上がってデフレ状態になっても誰もリフレ、
    通貨発⾏できないやん。
    • アメリカだとアルトコインが証券扱いされて国にボコボコにされてるやん。

    View Slide

  31. 各DID Methodのイデオロギー⽐較(私的妄想 – こう考えると区別、理解しやすいかも
    )
    ● 正解は無いのでは。
    ● 結局、我々ホモサピエンスの営みなので、
    どのくらいの⼈が、どのフィクションを信じるか。=> 勢⼒、常識
    ● あなたはどれが好みですか︖
    31

    View Slide

  32. Layer 2
    ~Agents and Communication~
    32

    View Slide

  33. DIDの⽤途分解
    33
    公開鍵 /
    エンドポイント
    署名
    VC
    (by Issuer)
    通信
    VP
    (by Holder)
    Public DID
    (e.g. web, indy, ion...)
    Public DID
    (e.g. key, web, ion...)
    Private Holder Binding
    (e.g. Link Secret)
    VCのPossession証明
    HolderのCorrelation(名寄せ)リスクあり
    IDをexposeしない
    Correlation対策
    Public DID
    (e.g. web, indy, ion...)
    Pairwise DID
    (e.g. peer)
    Correlation対策
    HolderのCorrelation(名寄せ)リスクあり
    Layer 3(VC種別)
    Layer 2
    Layer 1

    View Slide

  34. ⽐較
    34
    特徴 OAuth/OIDC DIDComm DWN
    アーキテクチャ クラサバ P2P P2P
    トランスポート HTTPS Agnostic HTTP?
    通信にDIDを 使わない 使う 使う
    通信のDIDは - Pairwise Public?
    OpenID4VCI/VPのベースになっているという
    意味合いでわかりやすさ優先で載せています

    View Slide

  35. DIDComm
    35
    Agent Agent
    公開鍵 公開鍵
    共有鍵⽣成
    共有鍵⽣成
    鍵交換 鍵交換
    HTTP(S), Bluetooth, MQTT...
    Endpoint Endpoint
    Connection⽣成
    DIDCommメッセージ送受信

    View Slide

  36. DIDComm: Connectionの張り⽅ 2種類
    36
    Agent X Agent Y
    did:peer
    公開鍵/Endpoint
    XのEndpointにYのdid:peer(公開鍵+ Endpoint)を送る
    Out-Of-Band(QRコード、メール)で送る
    Agent X Agent Y
    (Registry)
    Yʼs Public DID
    Endpoint取得
    YのEndpointにXのdid:peerを送る

    View Slide

  37. Correlationとは︖
    37
    Holder像

    View Slide

  38. Correlationとは︖
    38
    Holder
    Verifier A
    Verifier B
    通信のためのDID、複数のIssuer/Verifierに対し使い回す。
    did:ion:abc123
    Aさん、Holder(did:key:abc123)から、
    こういう
    - 時
    - 内容のVC
    - ⽬的
    で来ている。そちらはどう︖
    結託
    Holder
    Verifier A
    Verifier B
    did:peer:abc123
    did:peer:xyz123

    View Slide

  39. Decentralized Web Node
    39
    [出展] DIF: Decentralized Web Node

    View Slide

  40. Layer2イデオロギー⽐較(私的妄想 – こう考えると理解しやすいかも
    )
    40
    OIDC
    ⾮中央集権?/⾮集中?/分権?/分散?の度合い
    低 ⾼
    DIDComm
    • 今のインフラでいいっしょ。
    • これだけスケールして、⼈々の⽣活インフラ
    になったインターネットに新しいレイヤーを
    加えるのは⼤変だよ︖ -> DIDComm
    • クラサバは歪な⼒関係。P2Pが良い︕
    • DNS/認証局、必要なし︕HTTPでワークする︕
    • Transport Agnostic︕(WS、Bluetooth、MQTT...)

    View Slide

  41. Layer 3
    ~VC and Trust Triangle~
    41

    View Slide

  42. 2つのトピック
    42
    Layer 3: VCの種別
    JWT-VC
    JSON-LD Credential(LDP-VC)
    (Ed25519 Sig/
    BBS+ Sig)
    Indy AnonCreds
    Layer 3: VC発⾏/VP検証のプロトコル
    OpenID4VCI/VP
    Aries
    Issue Credential Protocol/
    Present Proof Protocol
    DWN︖

    View Slide

  43. VC種別
    43
    特徴 JWT VC
    JSON-LD
    Ed25519 Sig
    JSON-LD
    BBS+ Sig
    AnonCreds
    W3C Data Model
    準拠
    Yes Yes Yes No
    アドバンテージ
    JWTが⼀般に普及済み
    シンプルさ
    Contextsの再利⽤性︖
    シンプルさ
    ⇦⇨
    いいとこ取り
    (プライバシー + シンプル)
    VCとして現在、最も普及[3]
    プライバシー機能
    ディスアドバンテージ ︖ ︖ ︖ パフォーマンス⾯
    Holderプライバシー
    保護機能 5つ
    無し 無し ⼀部(全部︖) 全部
    [2]
    Proponents of correlating credentials often make an argument that
    sounds like this:
    Going to great lengths to avoid correlation is wasted effort,
    because weʼll be correlated anyway. Just accept that and quit
    trying to fight a losing battle. Our energy is better used elsewhere.
    出展: Evernym: The Dangerous Half-Truth of “We’ll Be Correlated Anyway”
    ←どの道最終的にはCorrelationされるのだから技術で
    それを防ごうとするのは無駄な努⼒と考える⼀派もいる︖

    View Slide

  44. 暗号技術を使ったプライバシー保護機能5つ
    44
    タイプ 機能 概要
    Correlation(名寄せ)対策
    Private Holder Binding
    VCにオーナーであることを⽰すDIDを記載せずに、
    それをVerifierに証明する。
    Privacy Preserved Revocation
    VCに失効状態を特定するIDを持たせずに、
    Verifierに失効状態を証明する。
    Signature Blinding
    • IssuerのVC署名の使い回しが、Holderの特定に繋がる︖
    • わからない(知っている⼈いたら教えてください)
    開⽰する情報の最⼩化
    Predicate
    ZKPでClaim値を明かさずに、基準値以上以下だけを
    Verifierに証明する。
    Selective Disclosure
    All or Nothingではなく、Verifierから要求のあった
    (もしくはHolderが提案した)Claim群のみを提⽰する。
    [4]

    View Slide

  45. DIDの⽤途分解
    45
    公開鍵 /
    エンドポイント
    署名
    VC
    (by Issuer)
    通信
    VP
    (by Holder)
    Public DID
    (e.g. web, indy, ion...)
    Public DID
    (e.g. key, web, ion...)
    Private Holder Binding
    (e.g. Link Secret)
    VCのPossession証明
    HolderのCorrelation(名寄せ)リスクあり
    IDをexposeしない
    Correlation対策
    Public DID
    (e.g. web, indy, ion...)
    Pairwise DID
    (e.g. peer)
    Correlation対策
    HolderのCorrelation(名寄せ)リスクあり
    Layer 3(VC種別)
    Layer 2
    Layer 1

    View Slide

  46. Correlationとは︖
    46
    Holder
    Verifier A
    VC
    Credential
    Metadata
    [4]
    Verifier B
    Claims
    Proof
    (Issuer署名)
    Holder DID
    VP
    Presentaiton
    Metadata
    VC
    Proof
    (Holder署名)
    VP提⽰
    Aさん、Holder(did:ion:abc123)から、
    こういう
    - 時
    - 内容のVC
    - ⽬的
    で来ている。そちらはどう︖
    埋め込む
    署名
    結託

    View Slide

  47. Correlationとは︖
    47
    Holder像

    View Slide

  48. Correlationとは︖
    48
    Holder
    Verifier A
    [5]
    Verifier B
    VP提⽰
    W3C VCs Data Model
    • 気にするなら、HolderはDIDの使い回しはしないでね。
    • シングルユースにとどめてね。Verifierごとに変えてね。
    did:ion:abc123
    did:ion:xyz456

    View Slide

  49. AnonCreds = Anonymous Credentials
    ⾝元を明かさずに、Possessionを証明する。
    Private Holder Binding (e.g. Link Secret)
    49
    Holder
    Issuer Verifier
    [4]
    Indy Ledger
    Link Secret
    Link Secretを元に⽣成された値X
    (発⾏単位で異なる)
    XをClaimの⼀部としてVC発⾏ Link Secretを明かさずに、
    それがXに寄与することを証明

    View Slide

  50. Privacy Preserved Revocation
    ● Indy Revocation
    ● 拙著:【Hyperledger Indy/Aries】ACA-PyでVerifiable Credentialを失効させる
    ● Evernym:
    ● OSS実装?仕組み⾃体?はスケーラビリティに⽋ける。
    ● 我々のサービスでは失効機能を実装していない。
    ● コミュニティで、効率的な⽅式について対応中
    ● Non-Preserved
    ● DIF Revocation List 2020
    ● DIF Status List 2021
    50

    View Slide

  51. 備考: Privacyに関して標準における記述場所
    ● W3C VCs Data Model
    ● 7. Privacy Considerations
    ● W3C VCs Implementation Guidelines
    ● 12. Zero-Knowledge Proofs
    ● 13. Progressive Trust
    ● W3C VC Data Integrity
    ● 6. Privacy Considerations
    51

    View Slide

  52. それぞれ進化の途中
    52
    JWT-VC
    JSON-LD Credential
    (BBS+ Signature)
    Indy AnonCreds
    SD-JWT
    (Selective Disclosure機能)
    Indy配下からHyperledger直下へ
    Indyなしでも使えるよう仕様化
    Data ModelをW3C準拠へ
    各種プライバシー保護機能の仕組み策定
    Predicate
    Selective Disclosure
    その他︖
    [2]

    View Slide

  53. VC発⾏/VP提⽰のプロトコル
    53
    [出展] OpenID for Verifiable Credential Issuance
    ● Aries系は、後半で説明。
    ● OpenID4VCI

    View Slide

  54. OpenID4VCI (Pre-Authorized Code Flow)
    54
    JSON-LD Credential(LDP-VC)
    (Ed25519 Sig/
    BBS+ Sig)
    Aries
    Issue Credential Protocol/
    Present Proof Protocol
    [出展] OpenID for Verifiable Credential Issuance
    SSIの外側で、事前にHolderの認証が済んで
    いる状態から始まるフロー
    QRコードにOAuth2の認可コードが埋め込ん
    であり、これをHolderにメールなどで送る or
    ⾒せる。(この認可コードにClaim情報が紐
    づいている︖)
    (OAuth2と同様に)Holderは認可コードを
    Token Endpointに送ることでアクセストー
    クンを得る。
    Holderは⾃⾝のDIDで署名したnonceとアク
    セストークンを含むリクエストを
    IssuerのIssue Endpoint(OAuth2でのリソー
    スサーバー)に送る。
    Issuerはそのレスポンスとして、HolderにVC
    を発⾏する。
    VC発⾏オファー
    VC発⾏要求
    VC発⾏
    ここの
    ⼤まかな流れは
    Ariesと同じ

    View Slide

  55. バーティカルカットで特徴⽐較
    55

    View Slide

  56. 2. 仕様セットごとの特徴⽐較
    56
    SSI
    VC
    • 思想
    • イデオロギー
    Entity/
    Agent
    DID
    Layer 1: DID Methods
    Layer 2: Agents and Communication
    Layer 3: VC, Trust Triangle
    Layer 4: Apps, Ecosystem
    Open Standards
    ToIP Tech Stack
    コア要素

    View Slide

  57. 2. 仕様セットごとの特徴⽐較
    57
    仕様スタック /
    管理団体
    OSS
    サービス
    (プラットフォーマー)
    サービス
    (プラットフォーマー)
    実装
    ラップ
    実装

    View Slide

  58. 団体の種別
    58
    コミュニティ、団体 種別
    Hyperledger Indy/Aries 標準化、OSS
    OpenID Foundation 標準化
    Web5 OSS
    Microroft Entra, Evernym, Indicio... サービス

    View Slide

  59. スタック
    59
    (W3C) did:sov
    (DIF) DIDComm
    (Aries) Issue Credential Protocol/
    Present Proof Protocol
    (DIF) Credential Manifest
    (DIF) Presentation Exchange
    Layer 4: Apps, Ecosystem
    Hyperledger Indy/Aries
    ToIP Tech Stack
    AnonCreds
    JSON-LD Credential
    Web5
    (DIF) did:ion
    (W3C) did:web
    (DIF) DWN
    OIDF
    JWT-VC
    JSON-LD Credential
    (DIF) Credential
    Manifest
    (DIF) Presentation
    Exchange
    OAuth/OIDC
    OpenID4VCI/VP
    JWT-VC
    JSON-LD Credential
    AnonCreds
    (DIF) Credential Manifest
    (DIF) Presentation Exchange
    [6]

    View Slide

  60. プラットフォーム環境
    サービス / プラットフォームとは︖
    60
    Holder Agent
    (Mobile App)
    Issuer Agent Verifier Agent
    expose REST API
    Issuer環境
    (顧客)
    Verifier環境
    (顧客)
    expose REST API
    • SSIシステム構築を楽にします。
    • SSI的にありなのか︖わからない。
    Issue/Store VC Present/Verify VP

    View Slide

  61. スタック
    61
    (OIDF) Self-Issued OpenID
    Provider
    (OIDF)OpenID4VP
    (DIF) Presentation Exchange
    Layer 4: Apps, Ecosystem
    Microsoft Entra
    ToIP Tech Stack
    JWT-VC
    Evenym, Indicio, Northern Block : 海外スタートアップ
    Hyperledger Indy/Aries
    (DIF) did:ion
    (W3C) did:web
    [6]

    View Slide

  62. 団体間の関係性
    62
    OIDF
    W3C
    Web5
    DIF
    取り⼊れる
    Hyperlerdger Indy/Aries
    競合

    View Slide

  63. OSS、サービス出てきて3~4年くらい︖ / 普及していない
    ● なぜ︖(個⼈的⾒解)
    ● ビジネス化が難しいという話を周りからも聞く。
    ● 普及
    ● 多くの⼈がそのフィクションを信じること。
    ● ⾃由主義の世界では多くの⼈に良いと思ってもらう必要がある。
    ● ⽂明化、ビジネス = 便利、楽になる。(e.g. ChatGPT)
    ● SSIは、そういう⽅向の明確な成分が少ないのでは。
    ● 意味のあるもの︖ = 市場規模が⼩さくなりがち︖
    ● 経済合理性が低い社会課題に近しい︖
    ● ⼤きな組織単位で権⼒によるトップダウンが必要︖
    ● トリガーになりそうなプロジェクト
    63

    View Slide

  64. European Digital Identity Wallet
    64
    ● eIDAS 2.0
    (electronic IDentification, Authentication and trust Service)
    ● 希望するEU市⺠に対しWalletの提供を義務化
    ● SSIでいうとHolder Agent(Wallet)
    ● EU市⺠は使う使わないは⾃由
    ● 数々のSSI企業が参加しパイロットプロジェクトが進⾏中
    ● ARF(Architecture and Reference Framework)発表
    ● ⼀般に知られている標準とプラクティスに則り、
    相互運⽤性のあるEUDI Walletを開発するための仕様群
    ● OpenID4VCI採択
    ● 5億⼈!
    [7]

    View Slide

  65. エンジニアとして開発の選択肢
    65

    View Slide

  66. あり得そうな選択肢
    1. オープンスタンダードを⾃前で実装
    ● OpenID系だと、元々IdP、RPを持っていたらやりやすいのかも︖
    ● Trusted Webのパイロットで、OpenID系の実装をされていた会社さん
    複数いた気がする。
    2. OSSの利⽤
    ● Hypeledger Aries: Production Ready
    ● OpenID系: ありがたいことに、出てきているが実装中の段階
    ● Sphereon社
    ● Aries Framework JavaScript (⾯⽩いのはAriesのOSSで取り⼊れている所)
    ● Web5: まだTechnical Previewの段階
    3. サービスの利⽤
    66

    View Slide

  67. 巨⼈の肩の上に⽴ち、Layer4実現を⽬指す、あるエンジニア
    67
    Layer 1: DID Methods
    Layer 2: Agents and Communication
    Layer 3: VC, Trust Triangle
    Layer 4: Apps, Ecosystem
    Open Standards
    ToIP Tech Stack
    SSIやれ、⾔われたけど、
    仕様を全部実装する体⼒、スキルないしな・・・
    HL Ariesさん、OSSいい感じやん︕
    ありがたや、⼤感謝〜〜
    仕様、OSSコード、開発Doc
    ⼀通り読んで、試してみよ︕
    ⼈的資本 -> 社会資本のために
    試した結果を公開しちゃお︕
    アプリ、システム作ってPoCして、
    ビジネス、サービスに繋げて会社の
    ミッション/ビジョン達成しちゃお︕
    社会資本 -> ⾦融資本

    View Slide

  68. (前半部分) ソース
    ● [1] Hyperledger Indy Public Blockchain
    ● [2]
    ● Covid-19 Credentials Initiative: Verifiable Credentials Flavors Explained
    ● Covid-19 Credentials Initiative: Verifiable Credentials Flavors Explained (Infographic)
    ● Indicio: Five Things You Need to Know About JSON-LD Credentials in Hyperledger Aries Cloudagent Python
    ● Evernym: Categorizing Verifiable Credentials
    ● Evernym: Why the Verifiable Credentials Community Should Converge on BBS+
    ● [3] Hyperledger: Announcing Hyperledger AnonCreds: Open Source, Open Specification Privacy Preserving Verifiable Credentials
    ● [4]
    ● Evernym: The Dangerous Half-Truth of “Weʼll Be Correlated Anyway”
    ● Evernym: How Does a Verifier Know the Credential is Yours?
    ● Aries RFC 0646: W3C Credential Exchange using BBS+ Signatures
    ● [5] W3C Verifiable Credentials Data Model: 7. Privacy Considerations
    ● [6]
    ● https://pkg.go.dev/github.com/TBD54566975/ssi-sdk#section-readme
    ● https://developer.tbd.website/docs/web5/learn/decentralized-identifiers/
    ● Microsoft Entra Verified ID-supported standards
    ● [7]
    ● Biometric Update.com: EU Digital Identity Wallet Consortium selected for large-scale pilot
    ● European Commission: The European Digital Identity Wallet Architecture and Reference Framework
    68

    View Slide

  69. 前半終わり
    69

    View Slide

  70. Hyperledger Ariesとシステム構築
    70

    View Slide

  71. 71

    View Slide

  72. ACA-Py / AFJ / von-network
    72

    View Slide

  73. ACA-Py (Issuer/Verifier)
    73
    Indy SDK
    Wallet(PostgreSQL or SQLite)

    View Slide

  74. ACA-Py (Issuer/Verifier)
    74

    View Slide

  75. AFJ (Holder)
    75

    View Slide

  76. 1. 開発⽤Indy Ledger⽤意 / Issuer Public DID⽣成
    76

    View Slide

  77. 2. Issuer Agent(ACA-Py)の起動
    77

    View Slide

  78. 2. Verifier Agent(ACA-Py)の起動
    78

    View Slide

  79. 3. IssuerがVC発⾏、検証に必要になるTXを作成
    79

    View Slide

  80. 3. IssuerがVC発⾏、検証に必要になるTXを作成
    80

    View Slide

  81. Mediator
    81

    View Slide

  82. 4. ⼤まかな流れ
    82
    ● Issuer-Holder間でConnection⽣成
    ● Holder-Verifier間でConnection⽣成
    ● Issuer-Holder間でVC(AnonCreds)発⾏
    ● Holder-Verifier間でProof提⽰検証
    ● https://tech.gmogshd.com/medical-chekup-prototype/
    ● 細かい部分は拙著群をご参照ください。
    ● https://tech.gmogshd.com/?s=kanuma

    View Slide

  83. 後半終わり
    83

    View Slide

  84. 最後に
    ● PoCを協業していただける企業様を探しています。
    下記の窓⼝までご連絡ください。
    [email protected] (マネージャ)
    ● 社会資本を引き続き増やしたいので、今回 or テックブログの内容に関する
    質問、議論等、お気軽に連絡ください。
    ● Twitter: @t_kanuma
    ● 何のコダワリもプライドもないIdentity素⼈のサラリーマンエンジニアです。
    誤った理解をしている箇所があれば、学びたいと思うのでご教⽰ください。
    84

    View Slide

  85. 終わり
    ● ご清聴ありがとうございました。
    85

    View Slide