デモ開発の全体像
実装
DID認証
DIDの生成
DID docの生成
DID docの保存
DIDの検証
DID Doc呼び出し
署名
検証
https://scrapbox.io/files/64d1f8500413b8001bf4902c.png
鍵生成
DKf,BKf,SKf, FKf, CKfの生成
ノード
ルートノードの生成
追加
鍵のリンク
Add: URI, Key:DKf,BKf,SKf, FKf, CKf, Name: FIleName, EncLink: PeaNode
これくらいかな？
https://scrapbox.io/files/64d1f868f83484001c5f92e2.png
削除
移動
再暗号
https://scrapbox.io/files/64d1f89a685a30001cb04dd8.png
どうやって再暗号化を行うのか？Yudai.icon
アクセス制御
RBAC
特定の役割を持つという事前に定義された条件に基づいてアクセス制御
条件の定義
DIDの所有者がアクセスコントロールする
ABAC
この部分は今回設計する必要ないかも？
ってかアクセス制御ってさ、鍵がシェアされるのかな？
それとも条件を満たしていたら自動で扉が開くに近いの？
鍵のSharing
どのように鍵を共有するか
誰にアクセス許可をしているか
UI
Pipeleを元に作れる
言語: Python, Rust(mameta.iconの趣味)
2023/8/10
Cryptreeのdemo実装とりあえずデータ構造とかは作れたYudai.icon*2
メモ
アクセス制御の設計についての疑問でも書いたように鍵をどうやって共有するか
デモならば一旦は簡易的で良い & 僕たちで設計する必要がないのかもしれないYudai.icon
抽象化
鍵をどうやって共有するかって所を考える
今回はベタ張り出来るようにするイメージで、どうやってLocatinを出すかって所やね
どうやって再暗号化を行うのか？
鍵の生成自体は親ノードの鍵によって生成する必要がある
本番でデータ構造をどこに保存するのか？
まあこれはずっと考えていること
今のところはIPFS
DIDの署名鍵とルートノードの秘密鍵の2つになると思うYudai.icon
この問題をどうやって解決するか
DID認証をいつ行うのか
ファイルシステムが必要かどうか
必要になってくると思うんだけどDemoでは必要ないのでは？とも思っている
認証の部分でCryptreeとIDの紐づけが出来ていない場合SBK(ルートの鍵)の管理が必要となる
この場合ユーザーはある意味では2つの鍵管理になる
これは逆に紐づけた場合これを解決することは出来るのだろうか？
今日改めて何を作る必要があるのか、役割分担について話す！Yudai.icon
9/7,8くらいまでにmameta.iconがフロントの開発
まささんにはこれまでに論文と全体を理解してもらう
UIは既に進んでいる