2022年12月14日水曜日

SBT/DID/VCを紐解いてみる

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


"Digital Identity技術勉強会 #iddance Advent Calendar 2022" 14日目の記事です。


最近DID(Decentralized Identifiers)やVC(Verifiable Credentials)をコネコネしてインターネット上でのデータや取引の信頼性をどうやって担保するか?みたいなことにトライをしているわけですが、どうしてもDIDを「分散型ID」という日本語に翻訳してしまうことにより「web3イェーイ!!」な人たちの変な関心・期待を集めてしまっている気がしています。今日のトピックではないので割愛しますが、インターネットの信頼性を高めたいというモチベーションにはDIDではなく「VC」こそが最重要のコンポーネントであり、DIDをVCと組み合わせることでよりスケーラブルなシステムを構築できるようになる、というのが本質的な位置付けだと思っています。どうしても「分散型ID」という訳語が強すぎるので「VC:検証可能な資格情報」のインパクトが出しきれず言葉が一人歩きしているんだろうなぁ、、、という課題感です。


さておき、本日はそんなweb3な文脈でしばしば出てくる、譲渡不可能なNFTであるSBT(Soul Bound Token)とDID/VCとの関係性について考えてみようと思います。

※NFTとは?については割愛します。


■SBTとは?

イーサリアムの提唱者のヴィタリック氏がSBT(Soul Bound Token)に関して以下の論文を発表しています。

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763


ものすごくざっくりいうと、アカウントやウォレットのアドレスを「ソウル」と呼ぶことで、従来のNFTに対して発行者のアイデンティティを紐づけることができるようにしよう、という考え方で、このソウルに紐づけられたトークンをSBT、つまりソウルに紐づけられたトークンと呼ぶことにしよう、という話です。

このことによりNFTについて群衆ベースで信頼性を向上することができたり、ウォレットのリカバリをコミュニティベースで行うことができるようになる、という利点があるとされています。

例えば、特定のソウル(アーティスト)に紐づいたアート作品をトークンとして発行する場合、多くのソウル(購入者)がトークンを受け取ることで、アーティストの信頼性が上がっていくという群衆ベース、レピュテーション(評判)ベースの信頼性を向上することができ、結果としてアーティストの実在可能性が高くなって無担保融資ができるようになったりする、ということも考えられたりします。また、ウォレットのリカバリをニーモニックで行ったりカストディアンに依存してしまっている現状から、繋がっているソウルからの証言によりリカバリができるようになる、といったコミュニティによるリカバリシナリオについても利点として挙げられています。


■特徴は?

先にも書きましたが、アカウントやウォレットを「ソウル」と呼び、ソウルに紐づけられたトークンを「SBT」と呼ぶという考え方ですが、その一番の特徴は信頼の形成方法だと思います。

論文内で言及されるWeb2.0における世界観における信頼は既存のアカウント管理システム(例えばNFTマーケットだったらOpenSeaやTwitterなど)によって裏打ちされたアイデンティティがベースでしたが、本論文内においてSBTはレピュテーションをベースに信頼を構築することが考えられています。いわゆるブロックチェーンにおけるコンセンサスアルゴリズムのProof of Workのモデルそのものだな、と感じているのですが多くのアクティビティがあり、他のソウルとの関連があり良い評判が得られているソウルの信頼性は高く、必ずしも現実社会におけるエンティティとの紐付きをベースとしてお墨付きを必要としないという考え方です。

もちろん、このいわば直接民主主義的なのかコルホーズ的な考え方にも、すべての群衆が誰にも扇動されることなく正しい判断を行えるのか?という疑念は付きまとうわけです。これは歴史的に見ても社会システムとしての継続性には大いに疑問な訳で、特に群衆心理が強く働く日本社会においては各個人が本当に個人の意思を持って判断ができる状態になるのではないか、社会的・商業的なお墨付きがないものに対する正しい判断を各個人ができるだけにデジタル社会は成熟しているのだろうか?ネットリンチのようなことを生むことによりソウルに死がもたらされるのではないか?LinkedInが日本に浸透仕切っていない点からもソーシャルベースのReputationシステムに対する猜疑心を拭い去ることはできないのではないか?なんという疑問は尽きません。

同じく、マイクロファイナンスなど社会的弱者に対する寛容な仕組みは必要だとは思われますが、そもそも論として弱者に対する寛容性の欠如している世界観において社会的包摂は成立するのだろうか?なんていう疑問も出てきます。

ヴィタリックはこの点について論文の中でDAOを構成する上でSBTの相関を調べて投票ウェイトを下げるなどバイアスの排除のメカニズム(相関スコア)も提案しているので解決に向かう可能性もあるのでここは個人的にも要注目かと思っています。(要するに相関割引を導入して交節点の少ないノードに対する投票ウェイトを上げることで多数決における少数意見を拾い上げるシステム)

また、ヴィタリックが書いている段階で当然ですが、イーサリアムの利用を前提としたエコシステムの範囲内で実現される世界観を描いているものである点も大きな特徴なのかもしれません。つまり、パブリックかつパーミッションレスなブロックチェーンの世界の中で表現できるものが中心となるためPII(個人情報)に関する公開制御などプライバシーに関する考慮は現時点ではまだ解がなく、現時点では衆人環視を前提とした信頼の醸成となっているという点にも留意が必要です。(論文内でも今後の考慮点として記載されています)

いずれにしても現時点でSBTは実装系も多く存在しているわけではなくERCになっているわけでもないので、あくまで理念として捉えておくのが良いかと思います。


■DID/VCとの共通点・相違点

もちろんVCはデータモデルでしかないので、SBTの理念と相反しない使い方をすることも可能です。事実、論文内にもVCを利用することに関しての言及もあります。(こちらは後ほど)



少し脇道に逸れますが、そもそも論としてDIDに関してもIssuer DIDとHolder DIDは分けて考えるべきではないか?と思います。VCの文脈における典型的なIssuer/Holder/Verifierのモデルは原則事業者と消費者のモデルがベースとなっており、Issuerは事業者、Holderは消費者となることが想定されていますが、このモデルではいかにしてIssuerの信頼性を高めることができるのか?が焦点となります。この点はDIFのWell Known DID ConfigurationによるDNSのガバナンスへの依拠などにより解決をしてきた問題です。



しかしながら、SBTに関してはIssuer/Holder/Verifierがフラットに考えられているように感じます。つまり、VCのモデルではHolderの信頼性をDIDの信頼性によって担保が難しかった点(個人となることが多く、DNSとのバインディングでは解決しにくかった)についても群衆ベース・レピュテーションベースにより解決できる可能性がある点は大きな相違点なのかもしれません。なお、論文内にも記載がありますがSBTにおけるソウルを社会的なエンティティと紐づけて信頼性を向上すること自体はヴィタリックも否定はしていませんので、この点においてはDID/VCにおける信頼性向上のアプローチと補完関係にあると言えると思います。

つまり、結果としてどちらが良いというものはないが、全公開の前提において衆人環視の元で信頼性を向上するSBTのアプローチか、現実世界のガバナンスモデルを元に信頼を構築するVCのエコシステムは信頼に関するアプローチの違いということができるのではないかと思います。そしてもちろんVC/DIDの世界観においてもSBTの衆人環視のアプローチによるレピュテーションベースの信頼性向上の仕組みを構築することは当然可能だといえます。


■DID/VCとの共存?

ヴィタリックも論文の中でVCについても触れており、SBTがプライバシーの課題に対する解決策を見つけるまでは補完関係になると言っています。

特徴として、

  • SBT:全公開されるので機微なクレデンシャルには向かない
  • VC:コミュニティリカバリの仕組みがない(要は一部の事業者に依拠する)

など挙げられています。

また、各ソウル(DID)の信頼性を向上するという意味合いにおいても、

  • SBT:Issuer/Holder/Verifierの区分けがなく、VCモデルの弱点であるHolderの信頼性向上ができる可能性がある
  • VC:特にIssuerの信頼性はDNSなど他のガバナンスとのバインディングにより向上できる仕組みがすでに実装されてきている

ということも言えますので、うまくSBTの理念をDID/VCの世界の中に持ち込んでいくと面白い世界観が実現できる可能性は十分にありそうです。

論文内ではVCはコミュニティベース、レピュテーションベースの信頼性向上の仕組みを持っていないので、ソーシャルレンディングや無担保のアパート賃貸契約などのユースケースには対応できない、という話もありましたが、うまく補完しつつシナリオ毎に使い所を分類していけると良いのではないかと感じています。

ただ、先にも書きましたが現時点においてSBTはあくまで理念・概念にしかすぎないのが現実だと思うので、もう少し実装に踏み込んめるとより議論を深められるな、と思っています。


最後におまけです。

2023年3月1日〜3日にIIWのスピンオフイベントがタイであるようです。アジアでもこの手の議論が盛り上がってきていると思うので、可能な方は参加されてはいかがでしょうか?

https://identitywoman.net/save-the-date-apac-digital-identity-unconference-march-1-3-2023/









2022年11月6日日曜日

発行済みVerifiable Credentialsの状態確認を行うStatus List 2021の仕様と動作

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

今日はちょっとマニアックなところを。(完全に自分向けのメモです)


Microsoft Entra Verified IDは発行済みのVerifiable Credentialsの状態(有効・取り消し済み)を管理するためにDecentralized Identity Foundation(DIF)のStatus List 2021とIdentity Hubという仕様を使っています。

ちなみにその後Identity Hubはdecentralized web nodeという仕様になっているので、もうIdentity Hubの仕様はすでに古いものとなっています。

Decentralized Web Nodeの仕様


基本的にやりたいことはとしては、

  • 発行されたVerifiable Credentialの状態をHolderやVerifierは確認したい
  • ただ、Issuerに状態を問い合わせるのでは従来の集中モデルと変わらずプライバシー保護の観点などからも好ましくない
ということなので、Issuerに問い合わせしなくてもVerifiable Credentialの有効状態を確認できる必要があります。

ということでStatusList2021CredentialというタイプのVerifiable Credentialを発行し、IssuerのIdentity Hubに発行、他のノード等からIssuerが把握することなく閲覧が可能な状態を実現します。
なお、スケーラビリティへの考慮から発行済みVerifiable Credentialsのリストをなるべくコンパクトに保持する必要があり、ビット配列で状態を保持する形の仕様となっています。


今回はHolderやVerifier(主にはこちらが確認することが多いとは思いますが)などVerifiable Credentialを受け取ったエンティティがどのように有効性確認を行うのか?について触れたいと思います。(あくまで現時点でのMicrosoft Entra Verified IDでの実装をベースにしています)

■大まかな流れ

大まかにはこんな流れです。
  1. Verifiable Credentialを受け取る
  2. 受け取ったVC内のCredentialStatusを取得(主に以下2つの値が重要)
    • statusListIndex
    • statusListCredential
  3. Issuer DIDのDID DocumentからIdentity HubのserviceEndpointを取得
  4. 2で取得したstatusListCredentilalからIdentity HubへPOSTすべきBodyを生成、Identity Hubへ投げ込む
  5. Identity HubからstatusList2021CredentialというTypeのVCが返ってくるのでencodedListを取得
  6. 2でとっておいたstatusListIndexでencodedListのオフセットを確認し、ビットが立っていたら取り消し済み、倒れていたら有効として判断

■実際に取得してみる

まずは、VCからCredentialStatusの取得です。これは単純にJWTをパースすればOKです。
{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1"
    ],
    "type": [
      "VerifiableCredential",
      "hogehogeVC"
    ],
    "credentialSubject": {
      "name": "hoge taro",
      "mail": "hoge@exampple.jp"
    },
    "credentialStatus": {
      "id": "urn:uuid:6fa4e682-f427-41cf-b0e5-59179d66fea3?bit-index=5",
      "type": "RevocationList2021Status",
      "statusListIndex": 5,
      "statusListCredential": "did:web:example.jp?service=IdentityHub&queries=W3sibWV0aG9kIjoiQ29...(省略)...jZmZWEzIn1d"
    },
    (以下省略)


大事なのはstatusListIndex、statusListCredentialなかでもqueriesの値です。
queriesはbase64urlエンコードされたjsonなのでデコードすると後からIdentity Hubへ投げ込む値が出てきます。
[
	{
		"method": "CollectionsQuery",
		"schema": "https://w3id.org/vc-status-list-2021/v1",
		"objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3"
	}
]


では、このデータをIdentity Hubに投げ込んでいきます。
まずはIdentity Hubのエンドポイントを取得する必要があります。statusListCredentialを見ると当該のDIDのserviceの種類がIdentityHubとなっているところにqueriesの値を投げ込むべし、ということが書いてあり、MSの仕様ではIdentityHubへ聞きに行く必要があるということが指し示されているからです。
ということでIssuer DIDをResolveします。これまでもこのBlogで触れてきたuniversal resolverを使ってもいいですし、Microsoftが用意しているdiscoveryエンドポイントを使ってもいいでしょう。今回はMicrosoftのものを使いました。
https://discover.did.msidentity.com/1.0/identifiers/{IssuerのDID}
でGETするとDID Documentが返ってきます。
{
  "id": "did:web:example.jp",
  "@context": [
    "https://www.w3.org/ns/did/v1",
    {
      "@base": "did:web:example.jp"
    }
  ],
  "service": [
    {
      "id": "#linkeddomains",
      "type": "LinkedDomains",
      "serviceEndpoint": {
        "origins": [
          "https://example.jp/"
        ]
      }
    },
    {
      "id": "#hub",
      "type": "IdentityHub",
      "serviceEndpoint": {
        "instances": [
          "https://hub.did.msidentity.com/v1.0/{tenant id}"
        ]
      }
    }
  ],
  (以下省略)

この中のIdentityHubのserviceEndpointの値を取得します。Entra Verified IDの場合、https://hub.did.msidentity.com/v1.0/{Azure ADのテナントID}という構造になっていますので、あらかじめわかっている場合はわざわざresolveしなくてもいいかもしれません。

このエンドポイントに先ほど取得したqueriesの値を含むjsonをPOSTすることでstatusList2021Credentialが取得できます。

まずはPOSTデータの作成です。
構造としてはこんな感じになっています。
{
  "requestId": "c5784162-84af-4aab-aff5-f1f8438dfc33",
  "target": "did:web:example.jp",
  "messages": [
    {
      "descriptor": {
        "method": "CollectionsQuery",
        "schema": "https://w3id.org/vc-status-list-2021/v1",
        "objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3"
      }
    }
  ]
}

requestIdはuuid-v4形式の値を指定します。単なるリクエストとレスポンスを紐づけるための識別子なので値はなんでもOKです。
targetはissuerのDIDを指定します。
messagesの中のdescriptorに先ほど取得したqueriesの値をセットします。

ということでPOSTすると以下のレスポンスが返ってきます。
{
    "requestId": "c5784162-84af-4aab-aff5-f1f8438dfc33",
    "replies": [
        {
            "messageId": "bafkreicksslcxa7xraqg6luqqfsezkpfalpqdqk6jzealwqxrkv7svu5vy",
            "status": {
                "code": 200
            },
            "entries": [
                {
                    "descriptor": {
                        "method": "CollectionsWrite",
                        "schema": "https://w3id.org/vc-status-list-2021/v1",
                        "dataFormat": "application/vc+jwt",
                        "objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3",
                        "clock": 0,
                        "cid": "bafkreib5cnsi7kw5ya6otq2lybvwnqlh2ga2gmud7x7t46f4zkkcca6s5y"
                    },
                    "data": "ZXlKaGJHY2lPaUpG...(省略)...IydDNXaWhR"
                }
            ]
        }
    ]
}

大事なのはdataの部分です。
この値はbase64エンコードされたVerifiable CredentialsなのでデコードするといつものeyJ...が出てきます。もちろんこのjwtの署名検証はするとして、中身を確認していきます。
{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://w3id.org/vc-status-list-2021/v1"
    ],
    "type": [
      "VerifiableCredential",
      "StatusList2021Credential"
    ],
    "credentialSubject": {
      "id": "urn:uuid:6fa4e682-f427-41cf-b0e5-59179d66fea3",
      "type": "RevocationList2021",
      "encodedList": "H4sIAAAAAAAAA-3BAQEAAAgCoPw_qmsOEfgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAhAJmaUnkqGEAAA"
    }
  },
  "jti": "did:web:example.jp?service=IdentityHub&queries=W3sibWV0aG9kIjo3...(省略)...zlkNjZmZWEzIn1d",
  "iss": "did:web:example.jp",
  "sub": "urn:uuid:6fa4e682-f427-41cf-b0e5-59179d66fea3",
  "iat": 1667651604
}

大事なのはencodedListです。
この値はbase64でエンコードされgzipされたビット配列なのでデコードし、確認したいVCのstatusListIndexの値のオフセットの部分のビットの状態を確認します。

例えば、以下のような状態になっている場合は上から下に向けて1-2-4-8-...という形で桁が上がっていくのでこの例だと7番目だけがActive、あとは取り消し済みなのでencodedListは2進数でいうと「...110111111」という形で対応するIndexにあたるビットが立ちます。

ここまでわかればあとは簡単ですね。
statusListIndexに指定された値(上の例だと5)に該当するオフセットの部分をmaskしてANDをとれば当該ビットが立っているのかどうかがわかり、当該のVCの状態が把握できます。


ということで今回はStatus List 2021の仕様とMSの実装について触れました。
(実際はMSのAPIの中でよろしくやってくれるので自前でコードを書く必要はないんですけどね)






2022年11月3日木曜日

Auth0 labのVerifiable Credentialsを試してみる

こんにちは、富士榮です


これまで当BlogでもVerifiable Credentials周りは色々と触ってきましたが、今回はAuth0ラボで公開しているサービスを触ってみます。

こんな感じでCredentialを作れるサービスです。



参考)これまで触れてきたDID/Verifiable Credentials関係のポストの一部

※まぁ、古くはConsensysのuPortなんてのをガリガリ触っていた時期もあるんですが。。。


ということで一通り触ってみましょう。

注)その名の通りラボなのでプロダクションで使うのはやめましょう。

■Auth0ラボのセットアップ

まずはAuth0のラボ環境を作ります。通常のAuth0環境とはことなり、別のテナントを作る必要があります。


にアクセスするとログインが求められるのでアカウントを作るか、自前のAuth0のアカウントでログインしましょう。

■Verifiable Credentialsのテンプレートを作成

左側のナビゲーションメニューから[Credentials]をクリックするとTemplateを定義する画面が開きます。
適当にクレデンシャルの名前などを決めていきます。

一旦はここまでで、残りの見た目(Branding)などは後で設定します。

■Issuance Flowを定義

次はCredentialを発行する際の属性のマッピングなどを定義します。Microsoft Entraの場合はRulesで定義しましたが、Auth0の場合は[Actions]で定義します。
[Actions]から[Flows]を開くとテンプレートとしてVerifiable Credential Issuanceがあるので選択します。

カスタムで適当に属性のマッピングなどを定義します。この辺は当たり前ですがいつものAuth0です。
もちろん、ここで定義したapp_metadataはユーザの属性と一致させる必要がありますので、後でユーザを作成するときに属性を追加するのを忘れないようにします。

最終的にこんな感じにFlowが定義されていればOKです。

■DCRの有効化

Walletをクライアントとして登録する必要があるのですが初めからclient_idが払い出せるような世界じゃないのでDCR(Dynamic Client Registration)を有効にしておきます。
※テナント全体の設定に関わる話なので、慎重に

ナビゲーションから[Settings]、[Advanced]を開くと[OIDC Dynamic Application Registration]があるので有効にします。

■認証定義で3rd Party Clientsを有効化

3rd Party Clientsからの認証要求を有効化することでWalletの様に1st Partyではないアプリケーションからの認証要求に対応できる様にします。
これもいつもの[Authentication]から任意のConnection(今回は面倒なのでDatabase Connectionを使いました)を開き、設定内の[Enable for third party clients]を有効にします。

■ユーザの作成と属性の定義

先ほどFlowを定義した際にも述べましたが属性のマッピングを行うにはユーザに当該の属性がないといけません。
なので、ユーザを作成し、app_metadataに必要となる属性値を定義しておきます。
今回はこんな感じで定義しています。

■Credentialの定義を完成させる
最初にやってもよかったんですが、[Credentials]メニューから先ほど作成したTemplateの見た目の部分にあたる[Branding]を設定します。
と言ってもロゴや背景画像を指定するだけですが。

■いざ、発行

ここまでで設定はおしまいなので、発行してみましょう。
テスト用にブラウザで動くWalletが組み込まれているので、[Credentials]からTemplateを開いたところにある[Try Credential]をクリックするとすぐに使えます。

起動するとRequest Credentialボタンが出てくるのでクリックして発行を要求します。
ログインが求められますので、先ほど作成したユーザを使ってログインします。
属性提供に関する認可が走ります。

Credentialが表示されるので、Add CredentialでWalletにCredentialが格納されます。

■次は検証

CredentialがWalletに入ったら次は提示(Presentation)から検証ですね。
こちらもラボが用意されているので非常に簡単です。
Wallet内のCredentialをクリックすると[Try Presentation Flow]というボタンが出てくるのでクリックするだけです。
クリックするとテスト用のVerifierが起動してくるのでQRコードの下にある[Click here to continue]をクリックするとブラウザ版のWalletへPresentation Requestが行われます。
提示するCredentialを選択して[Present credential]をクリックします。

Verifiable Presentation/Credentialがテストサイトに渡されるので中身が見えます。



と、ここまでです。
非常に簡単です。


VPやVCを軽くみましたが、ld-proofなんですね。
Microsoft Authenticatorとの互換性は今のところなさそうです。もうちょいカスタマイズすれば色々とやれそうなので、引き続き触ってみようかと思います。
なんにせよ、こういう形で選択肢が増えてくるのは良いことですね!










2022年10月15日土曜日

ようやくAzure ADのデータが日本のデータセンターに

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

最近アクティビティが減っていますが分散型IDを含む諸々の活動は継続していますので時間をとって何かアウトプットしていかないとなぁ、と考えている今日この頃です。

ちょうどIgniteがあったのでAzure AD周りも色々と発表がありましたが、その中でもやっとか・・・というのがAzure ADのデータの置き場所問題です。

これまでAzure ADのデータは日本リージョンにテナントを作っても他の地域へレプリケーションされていましたが、今回のUpdateで日本データセンターに配置されることになりました。(今回の発表はAzure ADのみが対象でB2B/B2Cを含む各種サブセットについては対象外です。各コンポーネントごとのデータ配置は後述のサイトで確認できます)


公式Blog:「Announcing a New Azure AD, part of Microsoft Entra, region in Japan」

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/announcing-a-new-azure-ad-part-of-microsoft-entra-region-in/ba-p/2967453


ざっくりいうと、

  • 新規に日本リージョンに作ったテナントは日本データセンターに(対象コンポーネントはauthentication, core directory storage, and premium features storage)
  • 以前に日本リージョンに作ったテナントのマイグレーションは今後の発表を待て

ということです。

なお、コンポーネント単位のデータ配置場所は「https://aka.ms/aaddatamap」で確認することができます。

「AAD Directory Data & Management」や「Authentication」など対象となっているサービスを選択すると「大阪、東京、埼玉(笑)」と出ます。



では、自分のテナントのデータの配置場所がどこになっているのか?はどうやって確認するのかですが、2つ方法があります。

一つ目は単純にポータルからディレクトリのプロパティを見る方法です。

■10月に新しく作ったテナント

 リージョン(国または地域):Japan

 データの場所:Japan datacenters


■昔作ったテナント

 国または地域(リージョン):Japan

 データの場所:Asia, United States, Europe datacenters


※余談ですが何年か前に古巣バハレーンに作ったテナントのデータの場所はEUになってました。



もう一つの方法はアクセストークンの中のClaimを見る方法です。

アプリケーションでリージョンを絞りたい場合などはこちらを使うことができそうです。

こちらが日本データセンターにデータがあるテナントのアクセストークンをjwt.ioでデコードしたものです。

tenant_region_scopeというClaimに"JPR"という値が入っています。


それに対してこちらが古いテナント(まだ海外にデータがレプリケーションされている)のものです。



自治体とか金融機関とか医療関係などデータの置き場所に縛りのあるシナリオではこの辺りをうまく活用していくと良いでしょう。





2022年7月2日土曜日

分散型ID関係のコミュニティ立ち上げ

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


5月末にMicrosoftからAzure Active Directory、CloudKnox Permissions Management、Azure AD Verifiable CredentialsをまとめたMicrosoft Entraが発表されたこともあり、先日のOffice365勉強会で分散型ID(DID/Decentralized Identifiers)、検証可能な資格情報(VC/Verifiable Credentials)に関するプレゼンをさせていただきました。

事前申し込みも400オーバー、当日も230名くらいの方にご参加いただき、slidoの質問やコメントも止まらない感じで時間を大幅に超えて23時くらいまでやらせていただくくらいには盛況だった様です。(みんなそんなにDIDとVCに興味あるのかな?)

また、そんな中、W3Cでは長らくFormal Objectionによるこう着状態が続いていたDID Core Specificationに決着がつきW3C勧告へ進むことが承認された、との発表がありました。

これでますます開発者の人たちは安心してこの技術領域へ突き進んでいけますね!


ということで、先の勉強会でも発表させていただいたのですが、DID/VCに興味のあるエンジニアの皆さんが集まる場が欲しいよね、ということでCollabogateの三井さんやBlockBaseの山村さんたちと「DID Developer Community(仮)」を立ち上げることにしました。


と言っても現時点ではDiscordの板が存在しているくらいなので、あまりコンテンツもありませんし、アクティブな活動も予定されているわけではありませんが、まずはここにエンジニアの皆さんには集まっていただき、なんでも情報交換ができる様な場所を作れればな、、と思います。

ということでぜひご参加ください。

https://discord.gg/nn53BRRz(招待リンクが切れていたので張り替えました)

https://discord.gg/UFE9m22TeT


あ、参考までに先の勉強会で使った資料も貼っておきます。





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の間の結合度を下げることによる管理面やインフラ的なコスト削減が一番のメリットになるのでは?


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