DeKYX: 分散型 Know Your X

DeKYX は、身元と参加資格を扱う共通の層である。相手の資格は確かめたいが、その行為に必要な範囲を超えて身元を知りたくないシステムのために作った。X は人でも、法人でも、機器でも、サービスでも、自律エージェントでもよい。業務システムが受け取るのは、検証済みで scope（用途の範囲）付きの結果である。保持者の秘密は受け取らない。

出典: dekyx/README.md · crate: dekyx-core。Aethel との結び付けは aethel リポジトリ側の aethel-dekyx · 研究実装であり、KYC/KYB システムとしての認証は受けていない

クレデンシャルと提示の流れ

sequenceDiagram
    participant G as 統治
    participant I as クレデンシャル発行者
    participant H as 保持者
    participant D as DeKYX 検証器
    participant A as 業務システム
    G->>D: 発行者、鍵 epoch、名前空間、ポリシーを登録
    H->>H: 主体秘密と commitment を生成
    H->>I: クレデンシャル要求 + 所持の証明
    I->>H: 署名済みの scope 付きクレデンシャル
    I->>D: 署名済みの失効状態一覧
    A->>H: 提示の文脈と要件を指定
    H->>D: 匿名提示 + 選んだ資格の証明
    D->>D: 発行者、署名、状態、scope、文脈、リプレイを検証
    D-->>A: VerifiedEligibility / scope 付きの subject line

主要オブジェクト

オブジェクト	役割
`IssuerDefinition`	発行者、その鍵 epoch、名前空間、主体の種別、有効期間
`IssuerDirectory`	検証済みの発行者 epoch と現在の失効一覧
`CredentialRequest`	保持者が作った commitment を発行証明に束縛する
`Credential`	発行者が署名した scope、ポリシー、commitment、資格のルート
`RevocationStatusList`	発行者が署名した、epoch 順の失効クレデンシャル・ダイジェストの集合
`PresentationContext`	証明を一つの audience、action、要求、nonce、期限に束縛する
`AnonymousPresentation`	その文脈について、所持と選んだ資格を証明する
`VerifiedEligibility`	検証を通った後にだけ作られる結果。シリアライズできない
`PresentationLedger`	nullifier と文脈の組を使用済みとして記録し、同じ提示の再利用（リプレイ）を拒否する

プライバシーの範囲

保持者は自分で主体秘密を作る。発行時には、commitment の中身（開封値）を知っていることを証明するだけで、秘密そのものは発行者に渡さない。個々の資格は Merkle 木の葉として一つのルートにまとめ、commitment にする。提示のときは、業務システムのポリシーが求める葉だけを開き、それが署名済みのルートに含まれることを証明する。チャレンジには audience（提示先）、action（行為）、要求内容、nonce、期限が入る。そのため、ある操作のために作った提示を別の操作に流用することはできない。

subject line は、scope の中で主体を指す仮名の識別子である。発行者、scope、ポリシー、scope ごとの nullifier から導出する。発行者が鍵を交代し、同じ保持者が差し替えのクレデンシャルを受け取っても、subject line は変わらない。そのため業務システムは、法的な身元を知らないまま、一主体に一つの枠や一つの限度を課すことができる。scope が違えば nullifier の基点も違い、commitment も再ランダム化される。OCLOB はこの仕組みで、一法人が同時に出せる注文数に上限を設ける。DeCCP は名前ではなく subject line で清算参加者を受け入れる。

この版はscope の中では仮名だが、発行者に対して連結不能ではない。Ed25519 で署名した commitment は、一つのクレデンシャルの中では固定である。そのため、発行者が持つ発行記録と突き合わせれば、提示と発行を結び付けられる可能性がある。発行と提示を結び付けられないことが必要な配置では、再ランダム化できるクレデンシャル方式が要る。たとえば、査読を受けた BBS+ や CL 署名のアダプタである。同じことは README にも書いてあるが、読者が最も当然にあると思い込みやすい性質なので、ここでも繰り返す。

失効、鍵交代、リプレイ

受け入れる発行者鍵の epoch（鍵の世代）ごとに、署名済みの失効状態一覧が必要である。一覧が無い、または古いときは拒否側に倒れる（fail closed）。古い一覧で新しい一覧を置き換えることはできない。
鍵の交代では、前より必ず大きい epoch を登録し、それまでの epoch には猶予の締め時刻を付ける。鍵がいま漏れたという場合は、猶予の締め時刻を旧鍵の開始時刻より前に置く。これが即時に鍵を無効にする経路である。業務システムがすでに検証を済ませた記録は、業務システムの状態としてそのまま残る。ただし、退役した鍵で新しい提示を承認することはできない。
PresentationLedger は、scope ごとの nullifier と提示文脈の組を使用済みとして記録する。証明を再ランダム化しても、同じ行為を二度使えるようにはならない。ホストはこの台帳を、改ざんを検出できる記憶域に永続化しなければならない。台帳を巻き戻すと、リプレイが再びできてしまうからである。

永続化の境界

IssuerRegistry は、検証を飛ばしてデシリアライズすることができない。IssuerDirectory は、検証済みのレコードから変換する経路でしか復元できない。クレデンシャル、状態一覧、提示、文脈は wire 上のデータであり、使う前に検証する。VerifiedEligibility はわざとシリアライズできないようにしている。これは検証の出力であって、信頼できる入力として扱うことは決してない。

統合

flowchart TB
    CORE["dekyx-core
クレデンシャルと提示の検証"]
    AA["aethel-dekyx（aethel リポジトリ）
任意の artifact 束縛"]
    A["Aethel
与信と保証の資格"]
    C["DeCCP
清算参加者の受入"]
    O["OCLOB、QOMM ほか
ポリシー別の資格"]
    AA --> CORE
    AA --> A
    CORE --> C
    CORE --> O
    Z["zkPI / DeFMI"] -. "クレデンシャルへの直接依存なし" .-> CORE

zkPI と DeFMI はクレデンシャルを定義しない。ホストは、指図を作る前や決済する前に、DeKYX の資格を要求してよい。指図 crate の issuer モジュールには、独自の KYB クレデンシャルの経路がある。同じ one-of-many と or-DLEQ のガジェットの上に作ったもので、DeKYX より前からある。これが DeFMI のページで述べる審査証明（vetting）済みの名簿である。

配置側がなお定めなければならないこと

発行者の統治、証拠の基準、企業グループの名寄せ、失効の運用、データの保持方針、法域ごとの KYC/KYB の義務。発行者をまたいだ Sybil 対策（一人が多数を装うことへの対策）の方針は、crate の外で、共通の統治か登録簿として決める必要がある。公開した rev は、依存関係を固定したうえで、Linux 上で test、clippy、fmt、release ビルドを通過した。これはビルドの gate（受入の関門）であって、監査ではない。

← DeFMI DeCCP: 清算 →