こんにちは~! 僕は、C-VoxelというDID/VC系のプロダクトを開発しております、みなもとこうきと申します！
こんにちは~! 僕は、C-VoxelというDID/VC系のプロダクトを開発しております、みなもとこうきと申します！
Subscribe to Kouki Minamoto
Subscribe to Kouki Minamoto
Share Dialog
Share Dialog
皆さんこんにちは〜C-Voxelというプロダクトを開発しております、みなもとです。 C-VoxelはDIDと紐づけてオンチェーン上に職務経歴書をつくれる画期的な技術なのでぜひチェックお願いします！！！↓
前回に引き続き、DIDの勉強をしていきます！今回は、DIDにもURLみたいなものがあって、それでいろんな情報のやりとりをしているよ〜ってことを説明します！
実際のDIDはこんな形になっています。
こんな形になっているんですね。「なんだかWebページのURLみたいだなあ。」と思った方。その通りです。URLの http: みたいなところが、did: にあたります。
DIDは見ての通り3つのパートに分かれています。
did: URIスキームのID (http:みたいなやつの仲間)
DID Method これはDIDを運用する仕組みの種類
DID Method-Specific Identifier これはDID Methodの中の特定のID
です。なんだか難しいですが、要するに上の例で言えば、
example という種類のDIDの仕組み中の 123456789abcd… さんの DID にアクセスしてねっていう意味です。
DID mehodはちょっと難しいと思いますが、追々詳しく説明するの一旦ふわっといきましょう！！
ほんとに申し訳ないんですけど、これから DID document みたいな DID ~ っていう形の用語が死ぬほど出てきます。W3Cが悪いです。
DID document とは DIDに関連づけられた諸情報です。とりあえずまず見ていただきましょう。
何かしらの要求を投げるとこんな感じのJSON形式のデータが得られます。ユーザーの個人情報が欲しい時はこういう形でそのユーザーが許可すれば返ってくるということですね。これについても、回が進んでいくごとに詳しく解説しますので、今はへぇ〜ってくらいで大丈夫です。
DIDやDID documentといった用語が出てき始めたところで、まずは全体像を把握しながらDIDを語っていく上での登場人物とその意味について解説します。
全体像はこんな感じです。
この図を参考に、この図にある登場人物について一つづつ解説していきます。
🟥 は重要なやつ、🟡 はそんなに重要じゃないやつです。
DIDは先述の通り、3つのパートに分かれたURIです。このDIDには DID document には関連づけられています。このDIDを元にDID documentを参照することを 「DID documentへ解決する」と表現します。そしてDIDは、WebページのURLと同じく、 / や ? を用いて、DIDが保管されている場所やクエリを送信することができます。
これは定義によると「DIDによって識別された実体」です。実体とは人や組織、モノなど実際にそのDIDを持っている存在のことです。つまりこの世に存在する全てのものがDID subjectとなり得ます。
これは、DID documentの変更や消去などの編集を行う権限を持った実体 (人や組織、モノなど)を指します。この権限は通常、暗号鍵の仕組みによって付与されます。つまり、DIDは一つ以上の DID controller か、DID controllerになりうる DID subjectを持っていることになります。
DID documentはDIDに関連づけられた情報を持っている。第三者に最終的に見せる情報 DID documentの形式になる。
DID methodsは、あるDIDに対して、それに紐づいたDID documentが生成、解決、更新、ディアクティベートされる仕組み全体のこと。
DID から DID document を生成するために、DIDごとの情報を保管しておくストレージみたいなもの。特定の技術を使わなくても、DID documentを生成するためのデータの参照/記録ができる仕組みを Verifiable Data Registry という。例) 分散型台帳、分散型ストレージ、P2Pネットワークなど
DID resolverはDIDを入力として受け取り、適合するDID documentを出力するシステムコンポーネント。そしてこの解決の過程を DID resolution と言う。この特定のDIDの種類を解決するためのステップはDID methodの仕様によって変わる。
DID URL dereferencerはDID URLを入力として受け取り、リソースを出力するシステムコンポーネント。この過程をDID URL dereferencingと言います。DID resolverとの違いは、DID を入力として受け取るか、DID URLを入力として受け取るかの違い。
と、結構事務的なことをたくさん書きましたが、大事なのは、**DID subject が持つDIDをから DID document が得られ、DID document を編集したりできるのは DID controllerだけ！**ってことです。
DIDは did:[DID method]:[DID method-specific identifier] の形で成り立っている
DID から得たい情報は DID document というJSON形式のデータで得られる。(ユーザーが承認すれば)
DID controller のみが DID document の編集が可能
皆さんこんにちは〜C-Voxelというプロダクトを開発しております、みなもとです。 C-VoxelはDIDと紐づけてオンチェーン上に職務経歴書をつくれる画期的な技術なのでぜひチェックお願いします！！！↓
前回に引き続き、DIDの勉強をしていきます！今回は、DIDにもURLみたいなものがあって、それでいろんな情報のやりとりをしているよ〜ってことを説明します！
実際のDIDはこんな形になっています。
こんな形になっているんですね。「なんだかWebページのURLみたいだなあ。」と思った方。その通りです。URLの http: みたいなところが、did: にあたります。
DIDは見ての通り3つのパートに分かれています。
did: URIスキームのID (http:みたいなやつの仲間)
DID Method これはDIDを運用する仕組みの種類
DID Method-Specific Identifier これはDID Methodの中の特定のID
です。なんだか難しいですが、要するに上の例で言えば、
example という種類のDIDの仕組み中の 123456789abcd… さんの DID にアクセスしてねっていう意味です。
DID mehodはちょっと難しいと思いますが、追々詳しく説明するの一旦ふわっといきましょう！！
ほんとに申し訳ないんですけど、これから DID document みたいな DID ~ っていう形の用語が死ぬほど出てきます。W3Cが悪いです。
DID document とは DIDに関連づけられた諸情報です。とりあえずまず見ていただきましょう。
何かしらの要求を投げるとこんな感じのJSON形式のデータが得られます。ユーザーの個人情報が欲しい時はこういう形でそのユーザーが許可すれば返ってくるということですね。これについても、回が進んでいくごとに詳しく解説しますので、今はへぇ〜ってくらいで大丈夫です。
DIDやDID documentといった用語が出てき始めたところで、まずは全体像を把握しながらDIDを語っていく上での登場人物とその意味について解説します。
全体像はこんな感じです。
この図を参考に、この図にある登場人物について一つづつ解説していきます。
🟥 は重要なやつ、🟡 はそんなに重要じゃないやつです。
DIDは先述の通り、3つのパートに分かれたURIです。このDIDには DID document には関連づけられています。このDIDを元にDID documentを参照することを 「DID documentへ解決する」と表現します。そしてDIDは、WebページのURLと同じく、 / や ? を用いて、DIDが保管されている場所やクエリを送信することができます。
これは定義によると「DIDによって識別された実体」です。実体とは人や組織、モノなど実際にそのDIDを持っている存在のことです。つまりこの世に存在する全てのものがDID subjectとなり得ます。
これは、DID documentの変更や消去などの編集を行う権限を持った実体 (人や組織、モノなど)を指します。この権限は通常、暗号鍵の仕組みによって付与されます。つまり、DIDは一つ以上の DID controller か、DID controllerになりうる DID subjectを持っていることになります。
DID documentはDIDに関連づけられた情報を持っている。第三者に最終的に見せる情報 DID documentの形式になる。
DID methodsは、あるDIDに対して、それに紐づいたDID documentが生成、解決、更新、ディアクティベートされる仕組み全体のこと。
DID から DID document を生成するために、DIDごとの情報を保管しておくストレージみたいなもの。特定の技術を使わなくても、DID documentを生成するためのデータの参照/記録ができる仕組みを Verifiable Data Registry という。例) 分散型台帳、分散型ストレージ、P2Pネットワークなど
DID resolverはDIDを入力として受け取り、適合するDID documentを出力するシステムコンポーネント。そしてこの解決の過程を DID resolution と言う。この特定のDIDの種類を解決するためのステップはDID methodの仕様によって変わる。
DID URL dereferencerはDID URLを入力として受け取り、リソースを出力するシステムコンポーネント。この過程をDID URL dereferencingと言います。DID resolverとの違いは、DID を入力として受け取るか、DID URLを入力として受け取るかの違い。
と、結構事務的なことをたくさん書きましたが、大事なのは、**DID subject が持つDIDをから DID document が得られ、DID document を編集したりできるのは DID controllerだけ！**ってことです。
DIDは did:[DID method]:[DID method-specific identifier] の形で成り立っている
DID から得たい情報は DID document というJSON形式のデータで得られる。(ユーザーが承認すれば)
DID controller のみが DID document の編集が可能
<100 subscribers
<100 subscribers
No activity yet