実践DID:Symbol 1.DID:Symbolを名乗ろう

この記事はSymbolを使ってDIDをやってみようという記事です。
書き溜めて一気に公開することも検討してみましたが、思う様に筆が進まないため、少しずつ公開していきます。

# 本ドキュメントの位置付け

このドキュメントをDIDを知っている人が読むと、

#### これのどこがDIDなわけ？

と思われるかもしれません。
本ドキュメントはSymbol使ってサクッとDIDを始めるための提案書ととらえてください。
ベースとしてはVerifiable Credentials(VC)での活用をイメージしながら執筆しています。
本家DIDではVC以外にも様々なケースを想定したり様々なブロックチェーンで使われることを想定しているのか、全てを把握するには若干骨の折れる設計となっています。しかし、残念ながらそれはDIDを活用しようという気持ちを萎えさせて、逆に参入ハードルを上げてしまっています。
また、あらゆる環境に適合しようとするために、抽象化概念が存在しないブロックチェーンを採用した場合に実現が難しい議論が放置状態であったり、まだ議論の余地があるゼロ知識証明を取り入れてみたり設計の均一性が欠けていると思われる部分も多く見かけます。

そこでDID:SymbolはDIDとは一度切り離して考えていただき、実践的なVCを実現しながら理想的なDIDの在り方について議論していきたいと思います。

DID:Symbolでは扱う機能を下図のように定義します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/fffa890a-5acf-f621-e6ff-2f8bab1efdd1.png)

つまり、すべてのDIDの概念を踏襲するわけではないが、Symbolの機能をフル活用する、といったイメージで読み進めていただければ幸いです。

それでは、しばらくのお付き合いになるかもしれませんがよろしくお願いします。

# DID:Symbolとは

まずは、DIDとは？と書きたいところですが、膨大に存在するドキュメントを簡単に説明してしまうと何処かで語弊が出てしまいますので、割愛します。
今回参考にしたページについてURLのみご紹介させていただきます。

Decentralized Identifiers (DIDs) v1.0
https://www.w3.org/TR/did-core/

Verifiable Credentials Data Model v1.1
https://www.w3.org/TR/vc-data-model/

### DID:Symbol

というわけで、DID:Symbolについての説明だけ簡単にしておきます。
DID:SymbolはSymbol上で管理される分散型IDです。

みなさんはIDというとログインID、などを思い浮かべるかもしれません。システム開発をしている方であればユーザーID、商品ID、セッションIDなどさまざまなIDを見かけることでしょう。

IDは、サービス提供者が提供すべき相手を間違えない様に、ユーザーごとに(一意とかユニークになどと表現します)振り分けられたコードと考えることができます。つまり、サービスの内部で定義されて、そのサービス中だけで有効利用されるのが本来のIDです。国民IDなどはサービスの主体が国・政府と考えることができます。

DID:Symbolとは、このIDをサービスの外側に出してしまいます。
大きな違いは2点あります。

- IDは自分で作る
- サービスの外でも使える

DID:Symbolでは自分のIDは自分で作るところから始まります。このあたりがマイナンバーとは決定的に違う点だと認識してください。あなたはマイナンバーカードに埋め込まれた秘密鍵の具体的な値がどうやって導出されたかを知っていますか？「そんなことあなたが知る必要はない」というのがマイナンバーのサービス提供者側の立ち位置です。もちろんこれはガバナンスという意味では重要かもしれません。
またDID:Symbolは何個作るかは個人の自由ですので、マイナンバーのように1人につき1つと制限することはできません。セッションIDのようにWebサイトを1巡りするたびに作成するぐらいの気軽さを持っておきましょう。
自分が管理するのでそのIDをメインで使用するサービスの外でも使えます。競合会社で同じDIDを提示してもいいですし、サービスが終了したとしてもそのIDの記録は残ります。このあたりはブロックチェーンではないと実現が難しいところですね。



# DID:Symbolを名乗る！

ここはDIDのフォーマットを踏襲しましょう。
DID識別子は以下のように記述します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/2d83d2b9-db46-6b56-968f-764b06e0380e.png)

DID:SymbolではこのScheme:DID Methodの部分を

```
did:symbol:
```

と定義します。その後ろに自分が所有しているSymbolアドレスを付与してください。

```
did:symbol:{Symbolアドレス}
```

つまりxembookのDIDはこうなります。

```did
did:symbol:NCESRRSDSXQW7LTYWMHZOCXAESNNBNNVXHPB6WY
```

ネームスペースの場合はこうしましょうか。

```
did:symbol:ns:xembook
```

これがDID:Symbolの識別子になります。
DIDではこの識別子に紐付く場所に重要なドキュメントを配置します。

http:// という接頭子を見つけると、URLだと分かる様に
DIDもdid:symbolという接頭子によって、その後ろがSymbolアドレスだとわかりそのアドレスに紐づく情報を提供できるようにします。

ここで一つの疑問が湧いてきます。

```
did:symbol:{トランザクションHASH}
```

did:symbolの後ろがトランザクションHASHではダメなの？という点です。
確かにトランザクションHASHを記載しても改竄不可能な一意のデータに紐づけることが可能です。
しかしながら後述するように、DIDには所有という概念が存在している方が便利であるため、ここではSymbolアドレスを用いておいた方が便利です。
また、Symbolのアカウントはマルチシグ化という機能を使うことでアカウントを抽象化（秘密鍵の無効化）すること可能です。
これがDIDのリカバリ（回復）にも役に立ちますので、また後述しますのでお待ちください。

### では、名乗ってみましょう。

大したことではありません。
自分がコントロール可能なSNSや文書に作成したDID:Symbolを掲載するだけです。

私もQiitaにこの様に記載してみました。

![スクリーンショット 2023-04-11 3.29.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/cc2baffc-6848-469a-d3c9-308287190de5.png)


自分のアカウントやネームスペースを実世界を通じてどのドメインの所属しているかをリンクさせることで例え1XYMも入っていないアカウントだったとしてもブランド価値を持つようになります。
この考え方はSymbolの前身であるNEMにて議論が進められてきたアポスティーユの考え方が役に立ちます。興味のある方は一度ご参考ください。

https://nemproject.github.io/nem-docs/pages/Whitepapers/ApostilleWhitePaper.pdf

はい、これであなたもDID:Symbolを名乗ることができました。
サクッとアカウントを作って自分のSNSで公表する、DID事始めはこれぐらい簡単でないといけませんね。

それではまた次回の記事をお楽しみください。

https://qiita.com/nem_takanobu/items/9bfe292194b56fdd8d07