DIDとVCでなぜ分けているのか
Umiチームと話していて論点として出てきたYudai.icon
「DID document内になぜAttributeを入れたらいけないのか？」
これは面白い命題だと思う
同じ場合の課題を探ってみる
課題
DID documentにAttributeを載せた場合は公開される
これハッシュ値やzkを使用することで保護できる
分散台帳のスケーリングの問題に繋がるかも？
次々に追加していくから問題になる
選択的開示が行えないかも？
そもそもの話Attribute自体を全て分ければいい
検証をどのように行うのか？
これは一つ課題かも？
元のAttributeが載っているデータをどこに保存するのか
これはかなり問題だとはおもう
暗号化し保存するとしてどこに保存するのかって問題は生じる
暗号化を行う場合鍵が一つ増える
ただVCでも課題ではある
JSONファイルをローカルに保存するってのは言われてたりする
Umiチームではファイルを無くした際にどうするのかってところは言ってた
発行者によって再発行可能だけど、発行者機関が無くなった時に再発行できない問題
これはサードパーティーに依存しているに繋がる話Yudai.icon
DID documentに追加するとして、毎回トランザクションを実行する必要がある
つまりガス代がかかる
これは将来的に解決する可能性はある？
DID documentに追加するとして、EOA(ブロックチェーンのアドレス)が必要になる
つまりDID documentとアドレスが紐づくことになる
アカウントが紐づかないようにアカウントを分けることも可能ではある
その場合管理する鍵が増える
DIDをDNSとしても捉えることは可能だがその場合鍵が増えることは、解決したい問題を増やしていることと同じになる
100個管理しないといけなくて、実質2つになるのは確かにいいかもしれないが
このケースって組織でDID controllerが1人で、複数の鍵を管理するって時にはいいかもね
ユースケースによって鍵を使い分けないといけない時とか？
1つの鍵で複数の鍵を管理することは、1つの鍵に依存することになる
果たしてこれはセキュリティ的にいいのか？
この挙げた課題をVCは解決しているのか？
それでいくとプライバシーの側面は分けることでかなり高い
そりゃEOAとDIDが繋がっているけど公開されないのはかなり大きいとは思う
上記で挙げた発行者に対して依存は解決できていない
tkgshn.iconも言っている通り
/tkgshn-private/INTERSECTIONAL SOCIAL DATA
書いてて思ったのが分ける理由ってレイヤーがそもそも違うって感じっぽいYudai.icon
分けない場合問題が出てくる？
検証レイヤーと証明レイヤーって分け方が言葉として適してるかも？
そしてオンチェーンではなくオフチェーンで成立するってのが何より重要ってのは凄い思うね
この部分の疑問を言語化少しできたYudai.icon
核であればあるほどシンプルである
それぞれが核である = やることは分割である