# KERI (Key Event Receipt Infrastructure)
安全で分散型の鍵管理のための手段
Delegation / Rotation のイベントログ(Key Event Log)をハッシュチェーン型データ構造で管理することで、鍵が有効か、署名は有効かが確認できるようにするプロトコル。

## Key Event
鍵の状態を変更するアトミックなトランザクションのこと

## Key Event Log (KEL)
Key Event をハッシュチェーン型のデータ構造として保存したもの
Ceramicsで言うStream。

## Key Event Receipt Log
「署名した」というイベントのログ。
ハッシュチェーンでは管理していない。

## Key State
生成から始まり、さまざまなKeyEventを経て変化してきたKeyの状態
JSONで沢山Propertyがある。

v：バージョン文字列
i: 識別子のプレフィックス
s: シーケンス番号
...

## Revocation (失効) / Rotation (更新)

### Rotation
未来に適用されるルール（どの鍵が正しいか等）を一方的に変更すること。
なにか契約時に鍵Xを使って署名した後、Rotationをしたとしてもその時点では有効でなくてはならない。そうでないと署名者が歴史を改竄できてしまうため。

RotateとはRevoke（失効）とReplace(置換)の操作を一つにまとめたものである。
（Nullに置換する操作は別)

### Revocation
過去に適用した物事の意味を合意を持って変更すること。
署名をした事実はそのままに、意味自体を無効にする。
例として、なにか契約時に鍵Xを使って署名したが、そもそも契約する権利がなく契約自体が無効になった時など。

## 認証ルール/モデル

### ルール1 ） 永続的な認証モデル
署名の時点で有効な鍵を使用して署名されたステートメントは、別の有効な鍵で署名されたステートメントで上書きするか、または有効な鍵で執行されるまで有効。
鍵を(Rotation)交換したとしても、それ以前の署名付きステートメントの有効性は変わらない。
なので、新しい有効な鍵で過去全てのステートメントを署名し直さなくても良い。

### ルール2） 短命の認証モデル

署名の時点で有効な鍵を使用して署名されたステートメントは、鍵をローテートしたときに自動的に失効する。この強制失効方式は、トークンベースのセキュリティアプローチ（AccessTokenとか）でよく見られるルールで、与えられた鍵のセットで発行されたすべてのトークンは、鍵をローテーションするときに自動的に失効する。

ルール1）を運用するためには、与えられた鍵で署名されたステートメントの台帳やログを維持するか、少なくともステートメントのログのハッシュに対する暗号的コミットメント（マークルツリーやハッシュ連鎖データ構造）を維持して、ステートメントがその時点で有効な鍵で署名されたことを検証できるようにする必要がある。
したがって、署名されたステートメントのログ（台帳など）を使用していない場合、ルール1）は実行不可能であり、ルール2）が合理的なものである。

### ルール3） ある認可は永続的であり、ある認可は短命なモデル。

このモデルでは、ログに記録された署名付きステートメントのみがルール1）を使用し、その他のすべての署名付きステートメントはルール2）を使用する。ハイブリッドモデル。
署名付きステートメントを提示する場合、ログ内の時刻において有効な鍵が使われたかを確認できるようにしないといけない。
ログの中に鍵のデータがない場合、現在の鍵を確認し、それらが異なる場合、その署名付きステートメントは無効とみなす。

VCの発行者ー保有者ー検証者モデルは、ルール2）の場合規模が大きくなると問題が起こる。
VCの有効期限と鍵の有効期限(Rotation)が混ざり合って管理が大変。

### ルール4) 識別子を交換し、鍵自体は交換しないモデル。
署名されたステートメントは、有効な鍵に関連する短命な識別子が交換されるまで執行されない。
識別子の交換は、有効な鍵を効果的に交換する。
EthereumやBitcoinのアドレスなどはこの方式に該当する。
ある識別子に紐つく秘密鍵を交換することで新しい鍵の持ち主が認可される。

DID Methodは、そのDIDの鍵に関連する署名付きステートメントを検証するために、ルール1）2）3）のどの規則を使用するかを指定しなければならない。
DID:Documentは、単にVCだけでなく、署名文の種類の1つである。

しかし、2)や3)をサポートするためには、検証可能なログストアが必要。

各DID方式は、署名付きステートメントを検証する際に、1）2）3）のどのルールを使用するかを明示的に定義する必要がある。私の知る限り、これを明示的に行っているDID方式はない。暗黙の了解。