# Authorization Rules/ Models

`Univsersal Identifier Theory` というIDに関する論文を発見。そこから Authorization RuleやKey Revocation/Rotationに派生した。

# Univsersal Identifier Theory

## ID
IDの基本は
- Secure(悪用や侵害から保護されている)
- Trustable
- Universal

である。
`Secure` じゃないと信頼されない( `Trustable` )しTrustableでないと広く一般に使われない( `Universal` )

IDを設計する上での制約として `Zooko’s triangle of Identifier Properties` というものがある。
- Decentralized（global): 分散型である,中央集権的なサービスがなくIDが解決される。
- Secure(unique): 安全である。危険と害にさらされないもの。
- Human Meaningful(memorable): 意味のある、人間が覚えられる。

これら三つを満たすものは存在しない。

### Autonomic Identifier Model (AID)
上で言う `Security` 第一に考えたID。
例、公開鍵暗号署名における公開鍵。
- 暗号技術をRootにした信用であり自己完結している
- 秘密鍵管理による分散制御(管理者に勝手に制御されない)
- 普遍的な一意の識別子(コンフリクトが起こりにくい)
- 鍵ローテーションが存在しない

キーローテーションを兼ね備えたIDを自律型識別子(Autonomic identifiers (AIDs))と呼ぶ。

### Legitimized Human Meaningful Identifiers (LIDs)
上で `Human Meaningful` を第一に考えたID。
人間に認識される、人間が覚えられるID。例、ユーザーネーム。
- Adminとなる発行者が存在し管理されているケースが多い
- セキュリティはAIDに劣る
- 名前が全体に対してユニークなので不法に取得されてしまう

なお、上のPaperでは `AID|LID` と2種類のIDを繋げて一つのペアにすることで最強のIDにできないかと書かれている。

## ID Management System
IDを管理するシステム。鍵の有効性検証（失効、更新、存在確認）などを行う。

### 認証ルール/モデル
鍵の有効性を検証する上で３種類のアプローチがある。
#### ルール1） 永続的な認証モデル
- 有効な鍵での署名は上書きされるまで有効である
- 鍵を交換したとしても署名時点で有効ならば有効である
- 鍵の変更履歴や状態管理ができる台帳等が必要

`did:plc:`

#### ルール2） 短命の認証モデル
- 現在有効な鍵で署名されている場合有効である
- 鍵を交換しばあい過去の署名は無効になる
- 現在有効な鍵情報だけ管理すれば良い
よくあるAccessTokenなどのモデル。

#### ルール3） ある認可は永続的であり、ある認可は短命なモデル。
ハイブリッドモデル。
- 鍵の変更履歴や状態管理を台帳で管理
- 台帳に存在しない場合現在有効かどうかで確認する
- 台帳に存在している場合署名で有効か確認する

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

# 鍵の失効（Key Revocation/Rotation)とは？
鍵の有効性検証と言う中で重要な機能として失効がある。
前提としてRevocation/Rotationは同一視されてしまうケースが多いが
別物として考えた方が良いという提案が上がった。　[need to clarify revocation vs rotation](https://github.com/w3c/did-core/issues/386)

実際、現在のDID Specの`assertionMethod` だとただのRotationなのに過去のVCも無効になってしまうような仕様になっている。これは問題ないかが議論されている（結論は出ていない）

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

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

今有効な鍵を差しめすこと
- 有効な鍵を有効な鍵グループに追加して、Headをそれに付け替える

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

Revocationには２つの意味が存在していることに留意
- 鍵の失効（鍵管理) Key Revocation
- 認可ステートメント、クレデンシャルの失効（クレデンシャル管理）　Statement revocation

### Revocation Methods

上のPR内において結論は出ていないが、W3Cのまとめ役曰く

基本的にはルール２で対応するしかないが、
とはいえDIDドキュメントは、「鍵の全履歴を永久に保存する」ことはないし、どこかで過去の鍵の扱いは考えていかないといけない。

と言っている。

### Revocation Semantics / Revocation in Trustless Systems
現状VC/DIDではルール３を採用している。

過去の状態が取れないDIDの場合、Rule2の短命な認証にするしかない。
https://www.w3.org/TR/did-core/#revocation-semantics

トラストレスなIDシステムの場合、VersionIdやversionTimeを含んだClaimを署名＆ブロックチェーンでその時刻に鍵がValidかどうかを確認する。
https://www.w3.org/TR/did-core/#revocation-in-trustless-systems

### Revocation / Rotation の出てくる手法, 大筋

1) 失効した事実をステート管理し皆が参照できるようにする
  1) ステートが肥大しない事 
  2) 検索が容易な事 (Accumulators)
  3) 失効リストを秘匿し、プライバシーが守られる事 (ZKP)
2) 有効期限を柔軟に決めることができる
  1) Claimは秘匿化されたまま有効期限だけ更新できる (LVVC)
  2) 有効期限内にHolderが期限更新できる（Credential Update）

- List Based: 認証局など権威ある組織が証明書や鍵を失効しそのリストを共有する方法
Note: ZKMP(Zero-Knowledge Proofs for Set Membership
- Cryptographic Accumulators: セット内の要素を効率的に表現し、その要素のメンバーシップ（所属）を証明することができるデータ構造
- Credential Update: VCや鍵の有効期限を常に設定しておき期間内にVC・鍵更新するするもの(MediatedRefresh2021)

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

## Key Event Log (KEL)
Key Event をハッシュチェーン型のデータ構造として保存したもの.
- Rotation
- Revocation
- Delegation

などがある。
Ceramicsで言うStream。

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

### Trustとはなにか
信頼(Trust)には２つの意味が存在する。

- メッセージが改竄されていないことを保証する暗号的安全に対する信頼。電子署名などで検証できる。（Attributional Trust)
- メッセージの内容が妥当かどうか、発行者に対する信頼（Reputational Trust)

認証システムにはこの２つが必要。
`誰がXを言った` 事実は真、 `X` は真 両方が信頼にあたる時価値がある。順序としては
- 真実性(veracity)があり、
- その次に真正性(authenticity)がある。