ABCDEFGHIJKLMNOPQRSTUVWXYZAAABAC
1
項目ペアワイズ可VDR不要外部依存しない国際動向proscons選定選定理由/非選定理由備考
2
JWK Thumbprint〇-〇IETFで標準化・JWK Thumbprintはすでに規格化された
データ形式であり広く運用されている。

・特定のVDRへの依存を減らすことが
できる。		・公開鍵そのものが識別子となるため
鍵のローテーションに対応できない		◯[選定理由]
IETFで標準化されており既に広く使われている、かつSIOPv2で利用可能。

（VDR非依存であることがメリットであるが、鍵のローテーションにより
識別子が変化することとなる。そのためアカウントの復旧が難しい）		・SIOPv2でsubの形式の一つに指定されている
・鍵の更新（鍵の危殆化等への対処）を行った場合にsubの値が変化してしまう
こととなる。
・ID Token提供先のサービスはsubの値を元にユーザー管理を行うため、鍵更新により
同一ユーザーであることを保てなくなる。
3
DID Key〇〇〇w3c規格（v0.7）Unofficial Draft

DID文字列に情報が全て含まれるのでオフラインでも解決が可能更新と非アクティブ化ができない為、長期間の使用は非推奨

公開鍵＝識別子となるので鍵のローテーションに対応できない

規格はドラフト段階。		✕[非選定理由]
VDR依存を廃すことはできるが、
W3Cで未だドラフト段階である。		・DID文字列は単一の公開鍵と全く同じ情報量
・DID Documentも公開鍵と等価

did-key-format := did:key:MULTIBASE(base58-btc, MULTICODEC(public-key-type, raw-public-key-bytes))


https://w3c-ccg.github.io/did-method-key/
4
DID ION〇✕✕DIFが標準化
Microsoftが推奨		・スケーラブルなネットワーク
・高パフォーマンス(秒間数千〜数万件の処理)		Bitcoin依存✕[非選定理由]
Bitcoin、Microsoftに依存しているため。		アンカリング先のブロックチェーンにBitcoin、Content-Addressed Storage System（CAS）ノードにIPFSを用いたSidetreeプロトコル

https://github.com/decentralized-identity/ion

https://identity.foundation/ion/
5
DID Web〇✕✕w3c規格既存のWebインフラストラクチャと互換性があるDNSとHTTPに依存しているため、セキュリティとプライバシーの課題に直面する可能性がある

完全に分散型のDIDメソッドと比較して、中央集権的な要素がいくつか存在する		✕[非選定理由]
DNSとHTTPに依存しているため。		特定のURLでアクセスできる箇所にDID Document(/.well-known/did.json
)を配置することで利用


https://w3c-ccg.github.io/did-method-web/
6
DID plc〇✕✕BlueskyがATprotocolのために開発・強い一貫性
・高い可用性
・回復可能
・暗号学的に安全な方法		DIDのみでVCはない（今のところ）

汎用的なDIDにならない可能性がある
あくまで、atprotoのためのもの		✕[非選定理由]
ATProtocolのための実装であり、plcサーバに依存しているため。		did:keyを「簡易」公開鍵基盤として使用。
署名鍵と回復鍵の公開鍵を提供
・署名鍵 : DIDドキュメントの作成/更新
・回復鍵 : 鍵盗難/紛失などのときのアカウント回復を行うため

did:plc:${base32Encode(sha256(createOp)).slice(0,24)}

1. クライアントでdid:keyを作成
2. 上記を記載したcreateログを作成
3. 上記ログをハッシュ処理したものがdid:plcの識別子

[VDR不要のメモ]
PostgreSQLとIPFSでデータを持つ
PostgreSQL : 作成・更新などの操作履歴を管理
IPFS : DID Documentの保持

[外部依存しないのメモ]
plcサーバーへ依存

[consのメモ]
We welcome proposals for small additions to make did:plc more generic and reusable for applications other than atproto. But no promises: atproto will remain the focus for the near future.
7
ドメイン✕-✕-既存のインターネットインフラを活用できる。Holderがドメインを登録していない場合も多い。✕[非選定理由]
Holderの識別としては、各人がドメインを登録する必要が生じ現実的ではないため。
8
メールアドレス〇-✕-Bunsinのような転送サービスで匿名のメールアドレスを利用できる。転送サービスも事業者に依存する。メールアドレス転送の標準技術はない。✕[非選定理由]
特定のメールサービス提供事業者に依存することとなるため。
(自身のメールサーバーを運用することは、一般的には容易ではない。)
9
電話番号〇-✕-転送サービスで別の電話番号を提示できる。転送サービス事業者に依存する。✕[非選定理由]
特定の通信回線事業者に依存することとなるため。
10
事業者から与えられたID✕-✕-とくになし。自分で変更ができない。✕[非選定理由]
ペアワイズできず、事業者に依存しているため。		facebookがCookieで設定している c_user の値など。
11
マイナンバー✕-✕-1つの番号で複数の行政サービスを受けることができる。地方公共団体情報システム機構（J-LIS）に依存している。番号の利用が制限されている。認可を受けた団体はマイナンバーカードで本人確認処理が可能。✕[非選定理由]
日本国のマイナンバー制度に依存するため
12
ユーザーが自分で決めたID〇-〇-サービスで受理されれば、自由なIDを設定できる。サービスが受理するかどうかで自由度が変わる。✕[非選定理由]
シンタックス等、ID体系を独自に定める必要があり、汎用的性を欠くため。
これを体系的に行うのが、DIDである。		facebookのユーザー名など。
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100