# 鍵の失効（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
ある鍵を使ってメッセージに署名した場合、鍵をRotateさせるとメッセージが無効になるとは言えない。
例えば署名付きメッセージによって、支払いを行うことを約束した場合、Rotateで失効、支払わなくて良いなどになってしまったら、
署名者に歴史を解釈し直す一方的な権力を与えることになってしまう。
未来に適用されるルールを一方的に変更すること。過去は不変。

## Revocation
Revocationとは確定された歴史に、将来の展開に基づいた `新しい意味づけ` をする必要があるという、全当事者による共通の理解が前提となっている操作である。
`"フレッドは本当にこの契約書にサインした。それについて疑問の余地はない。しかし、フレッドはそうしたとき、法的な能力がなかった。したがって、この契約権は無効である--署名の存在を否定するのではなく、この出来事を異なる意味論で見ているからである"`
過去に適用した事象に対する意味を変更すること。全体の合意が必要。

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

# Revocation Methods

上のPR内において結論は出ていないが、W3Cのまとめ役曰く
> DLTに保存されるDIDドキュメントは、ある時点の鍵が有効かどうかを確認できるステートAPIのようなものを提供すると思われる。
このようなDLTベースのDID方式では、ある時点のキーの状態を確認することができるので、ある時点でクレデンシャルがすべて有効であったかどうかを知ることができる。
とはいえDIDドキュメントは、「鍵の全履歴を永久に保存する」ことはないし、どこかで過去の鍵の扱いは考えていかないといけない。

と言っている。

### Revocation Semantics / Revocation in Trustless Systems
過去の状態が取れない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

## (前回のおさらい) 認証モデル

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

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

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

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

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

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

# 下の Revocation / Rotation の手法, 大筋(まとめ)

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

# Revocation / Rotation の手法

## List Based
- Online Certificate Status Protocol(OCSP)
Online Certificate Status Protocol（OCSP）は、X.509公開鍵証明書の失効状態を取得するための通信プロトコル
https://github.com/Open-Attestation/adr/blob/master/did-certificate-revocation.md　

- Key Revocation Lists / Certificate Revocation Lists
https://www.rfc-editor.org/rfc/rfc5280
認証局など権威ある組織が証明書や鍵を失効しそのリストを共有する方法
Note: ZKMP(Zero-Knowledge Proofs for Set Membership
)とKey Revocation Listsを組み合わせれば、Listを公開せずとも中に含まれているか否か判定できたりする？
- Key Event Log (KERI)
発行者が鍵のイベント（生成、回転、失効）をイベントログに記録し、検証者がそのログを検証することで、
VCの公開鍵を確認できる仕組み。イベントログは、不変であり、順序付けられ、時刻同期される（Hashchainなどが使われる）。

## Cryptographic Accumulators
セット内の要素を効率的に表現し、その要素のメンバーシップ（所属）を証明することができるデータ構造。
データの追加と削除、存在していることを証明の３つができる。
- ハッシュベースのアキュムレータ
- RSA Accumulators
- Bilinear Pairing Accumulators

などがある。
証明書の失効リスト (CRL) やオンライン証明書ステータスプロトコル (OCSP) の代替手段として、証明書の失効状態を効率的に管理できる。
List Based形式にメンバーシップ署名の概念を追加して便利にしただけ？

[RSA Accumulatorを理解する](https://speakerdeck.com/azuchi/rsa-accumulatorwoli-jie-suru?slide=8)
[Cryptographic Accumulators: Definitions, Constructions and Applications](http://www.inf.ufsc.br/~martin.vigil/paper.pdf)

## Credential Update
VCや鍵の有効期限を常に設定しておき期間内にVC・鍵更新するするもの
`MediatedRefresh2021` など

### Verifiable Credential Refresh
> https://w3c-ccg.github.io/vc-refresh-2021/#refresh-protocol
Verifiable Credential Refresh 2021
A data model and protocol for refreshing Verifiable Credentials

VCの期限切れに対応するためのリフレッシュ方法について書かれている。リフレッシュはVC保持者の事前の同意か発行者の手動で行われる

VCの中の `refreshService`　を使って実現している

"refreshService": {
    "type": "MediatedRefresh2021",
    "url": "https://example.edu/refresh/3732",
    "validAfter": "2021-09-01T19:23:24Z"
}

このDocでは `MediatedRefresh2021` という期限内のVCをIssuerに送りつけて新しいVCにする方法が書かれている

## Linked Validity Verifiable Credential(LVVC)
*これはRevocable VCなのでStatement Revocation。
VCとLVVCの２種類をIssuerが発行し、Verifierは両方検証することでVCの有効性を確認するメソッド。
- LVVC: 発行日
- VC：発行日以外の情報とLVVCの紐付け情報

ポイントとしてIssuerがHolderから現時刻のLVVCを要求された場合、Revokeでなければ返す。Revokeならば返さない。
これによりClaimの署名を変えることがないので、暗号化したままVCを共有できる。
[A new Privacy Preserving and Scalable Revocation Method for Self
Sovereign Identity - The Perfect Revocation Method does not exist yet](https://eprint.iacr.org/2022/1658.pdf)

## P2P 上で、かつBloom Filterを使ったRevocation List共有

IssuerがRevocationしたと言う情報を他のノードに伝播させ、それぞれのノードで判定する。
判定データが増えるのでBloom Filterを使いデータ量を減らす。

### Bloom Filter
> 空間効率の良い確率的データ構造であり、あるデータが集合の要素である（集合に含まれている）かどうかの判定に使われる。ただし判定は正確ではなくて、含まれていないのに含まれていると誤って判定すること偽陽性（false positive）の可能性がある。
>

[Distributed Attestation Revocation in Self-Sovereign Identity](https://arxiv.org/pdf/2208.05339.pdf)

# Library/App

## OpenAttestation
https://www.openattestation.com/
DocumentのMerkleRootをContractに書き込み、
Documentの改ざんを防止＆状態管理をする。

[demo](https://github.com/Open-Attestation/document-store#interact-with-document-store)

ポイントとしてContractの発行者をDNSのTXTレコードを使うことで
Domain保有者と紐つける
`TXT example.com "openatts net=ethereum netId=3 addr=<DOCUMENT_STORE_ADDRESS>"`