前回はこちら↓
こんにちは〜！C-Voxelという DID系のプロダクトを開発しております、みなもとと申します！！ C-Voxel はWeb上でおこなった仕事や個人の実績をDIDと紐付けて可視化・蓄積することができるプロトコルです！興味のある方はぜひ一度チェックして見てください！
今回はですね、とうとう実際に DIDドキュメント がどんな形になっているかを見ていくことにします！
DIDドキュメント がなんだったかというと、特定のDIDが持っているデータがまとまっているJSON形式のドキュメントでしたね！
DIDドキュメントは、エントリー のマップによって構成されています。「マップ」というのは辞書やキーバリューとも言われるような、ある特定の文字列に対して、何かしらのデータを持っているデータの形です。
そして DIDドキュメントには二種類の分類の エントリー が存在します。
一つ目が、Properties という分類です。二つ目が、Representation-specific entries という分類です。
とは言っても、なんのこっちゃわからないので、ざっくり説明します。
これは、id や controller 、authentication など DIDドキュメントが必ず持っておかなければならない情報や任意で追加できる情報など、DIDに紐づけられる色々なデータに参照するための、「キー」のことです。
これも結局は、上記のプロパティと同じ形にデコードされます。しかし、「DIDドキュメントをXMLで書きたい！！！」とか「YAMLじゃないとやだ！！！」という JSON以外のフォーマットでDIDドキュメントを書きたい人 に向けた仕組みです。
“@context”: [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
みたいな感じでDIDドキュメント内にURLを記述しておくことで、外部に置かれた任意のデータ表現でのDIDドキュメントにアクセスできるようになります。とは言っても、DIDドキュメントの大元はJSONなので、JSON形式にデコードしてあげる仕組みを DIDメソッドを提供する側は用意しておく必要があるということです。
DIDドキュメントには二つのエントリーがある。
一つがプロパティでも一つが任意形式で表現されたデータへのエントリー
結局は全部 JSON にデコードされる
本日は短かったですが以上です！！！
Web3でのUIデザインやDIDに関する最新情報をお届けしておりますので、よかったらツイッターもフォローしてください〜！