feat(approach|use-case): add resilient identity continuity approach and use case#145
feat(approach|use-case): add resilient identity continuity approach and use case#145
Conversation
WalkthroughAdded a new "Resilient Identity Continuity" use case documenting an issuer-hostile threat model and requirements for on-chain identity continuity. Expanded the "Private Identity" approach to add issuer-independent enrollment via distributed OPRF (new Section F) and updated planning phases. Updated CHANGELOG with an unreleased entry referencing these additions. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@approaches/approach-resilient-identity-continuity.md`:
- Around line 1-241: The document "Approach: Resilient Identity Continuity"
exceeds the 2000-word guideline; shorten it to under 2000 words by trimming
non-essential bulk (move vendor recommendation tables, long vendor lists,
detailed PoC links, extensive example scenarios, and large prior-art lists into
a separate appendix or external resources), condense architecture sections into
concise summaries (keep core problem, constraints, approach A/B/C, and TLDRs),
and add a short "Read more" link to the moved content; update any front-matter
or header note to reflect the new word count and where the extended material now
lives so the file (Approach: Resilient Identity Continuity) complies with the
"Word limits" rule.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: c04574b6-fdd5-44c7-aa5c-cb63fa7117ed
📒 Files selected for processing (2)
approaches/approach-resilient-identity-continuity.mduse-cases/resilient-identity-continuity.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (2)
use-cases/**/*.md
⚙️ CodeRabbit configuration file
use-cases/**/*.md: This is a use case card.Structure & frontmatter: Validate against the template at
use-cases/_template.md.
Rules and scope are inuse-cases/README.md.Check that
primary_domainmatches one of the domains listed indomains/README.md.
Use cases should stay on a single page — flag if the content is excessively long or duplicates linked docs.Warn if section
## 2) Additional Business Contextcontains anything that looks like confidential
information (specific organization names, pilot scopes, committed volumes) — these belong incontext/files.
Files:
use-cases/resilient-identity-continuity.md
approaches/**/*.md
⚙️ CodeRabbit configuration file
approaches/**/*.md: This is an approach card.Structure: Validate against the template at
approaches/_template.md.
File naming and conventions are inapproaches/README.md. Filename must start withapproach-in kebab-case.Approach cards MUST link to both the use case they address and the patterns they combine.
Flag if no pattern or use case cross-references are present.Word limits: warn > 2000, error > 3000.
Files:
approaches/approach-resilient-identity-continuity.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
🪛 GitHub Check: vale
use-cases/resilient-identity-continuity.md
[warning] 70-70: [vale] use-cases/resilient-identity-continuity.md#L70
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
approaches/approach-resilient-identity-continuity.md
[warning] 70-70: [vale] approaches/approach-resilient-identity-continuity.md#L70
[IPTF.Marketing] Avoid marketing language: 'unique'. Use neutral, factual terms.
[warning] 167-167: [vale] approaches/approach-resilient-identity-continuity.md#L167
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 168-168: [vale] approaches/approach-resilient-identity-continuity.md#L168
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 183-183: [vale] approaches/approach-resilient-identity-continuity.md#L183
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 195-195: [vale] approaches/approach-resilient-identity-continuity.md#L195
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 214-214: [vale] approaches/approach-resilient-identity-continuity.md#L214
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 229-229: [vale] approaches/approach-resilient-identity-continuity.md#L229
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
| **Primary Pattern:** [Private MTP Authentication](../patterns/pattern-private-mtp-auth.md) | ||
| **Supporting Patterns:** [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md), [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md) | ||
|
|
||
| Holders prove real-world identity ownership (passport NFC, national ID, email DKIM, TLS transcript, biometric, community attestation) and obtain a deterministic evaluation from a distributed OPRF network. The OPRF output produces an enrollment nullifier (one per real-world identity) and a leaf commitment inserted into an on-chain incremental Merkle tree. After enrollment, the on-chain root is the sole trust anchor. |
There was a problem hiding this comment.
TLS proving is already mapped. It'd be cool to add zk-wrappers as a pattern (signature verification in a ZKP).
There was a problem hiding this comment.
zk wrappers in follow up pr
There was a problem hiding this comment.
In general best to add it now, as it's in scope. i.e., defining a building block that is part of the approach.
I think it should at least lead to an open issue, otherwise we will lose track of it.
| **Recovery:** | ||
|
|
||
| - **Threshold (Shamir):** Secret split across devices or custodians (t-of-n). Recovered secret produces the same proofs. No on-chain transaction required. | ||
| - **Social (guardian-based):** Quorum of guardians authorizes key rotation under same enrollment. Anti-coercion mechanism is an open design question. |
There was a problem hiding this comment.
Same here, social recovery is a strong primitive that we could map as a pattern.
|
|
||
| ## 2) Additional Business Context | ||
|
|
||
| **Confidential context:** Available in private IPTF repo |
There was a problem hiding this comment.
Not sure, we should keep this mention here.
There was a problem hiding this comment.
addressed in 44f2bce. its part of the template
There was a problem hiding this comment.
Same feedback as in group chat.
I think this approach could be consolidated with the existing approach-private-identity, that way the survive track will not be a side track but will harden current approach doc assumptions.
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
approaches/approach-private-identity.md (1)
1-383:⚠️ Potential issue | 🟠 MajorApproach card exceeds hard word limit and currently fails CI.
This file is 3461 words; split or trim content to get under 3000 words (e.g., move deep scenario details/trade-off expansions to a linked companion doc).
As per coding guidelines, approach cards have an error threshold above 3000 words.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@approaches/approach-private-identity.md` around lines 1 - 383, The approach card "Approach: Private Identity" exceeds the 3000-word limit and fails CI; reduce the document to under 3000 words by trimming or relocating verbose sections. Specifically, remove or move deep scenario descriptions (Scenario 1–7), extensive vendor/links lists, long "More Details" and "Trade-offs" tables, and large example blocks into a companion document, condense the "Overview", "Key Constraints", "TLDR for Different Personas" and "Architecture and Design Choices" to concise bullets, and ensure the resulting content (headers like "A. Registry-Based Membership Proofs", "F. Issuer-Independent Enrollment via Distributed OPRF", "Open Questions") remains a focused summary under 3000 words so CI will pass.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@approaches/approach-private-identity.md`:
- Line 158: The markdown contains marketing/superlative phrasing in the table
row and other flagged lines (e.g., the cells "One enrollment per source
credential" and "Source credentials are unique and unforgeable"); replace those
terms with neutral, factual alternatives (for example: "One enrollment per
source credential" -> "One enrollment per source credential (per-source
binding)" or "One enrollment per source credential" -> "Single enrollment
associated with each source credential" and "Source credentials are unique and
unforgeable" -> "Source credentials are tied to issuance and protected against
forgery" or similar neutral wording) and apply the same tone change to the other
flagged occurrences that match the same phrasing patterns so the prose lint and
repository tone requirements are satisfied.
In `@use-cases/resilient-identity-continuity.md`:
- Line 70: Replace the phrase "with only the on-chain trust anchor and a ZK
proof. No external calls." with neutral wording such as "with the on-chain trust
anchor and a ZK proof, without external service calls" in the sentence
describing verification in issuer-hostile settings; update the sentence in the
paragraph containing "Verification in existing private identity systems often
requires contacting a registry operator or issuer for revocation checks or
credential status" so it reads that verification must work "with the on-chain
trust anchor and a ZK proof, without external service calls."
- Around line 90-97: The "Open Questions" section currently uses a numbered
list; update the section headed "## 6) Open Questions" so each item is a
bullet-form question (use leading "-" or "*" per markdown) and append a
reference link for each question (e.g., "[link text](URL)") pointing to relevant
issue/PR or spec; ensure the header remains "Open Questions" and convert each of
the five numbered entries into separate bullet questions (preserve wording like
"minimum guardian set size for social recovery" and "production path for private
predicate parameters") with a short descriptive link for context attached to
each bullet.
- Line 26: Convert the dense inline actor sentence into an explicit bulleted
"Actors" list in the use-case card: replace the single-line string that
currently lists Holder, Identity Source, Enrollment Operator, Verifier, Auditor
/ Regulator, and Governance Operator with a markdown section titled "Actors"
followed by separate bullet entries for each actor (Holder, Identity Source,
Enrollment Operator, Verifier, Auditor / Regulator, Governance Operator),
ensuring each actor is its own list item and keeping the existing descriptions
(e.g., "Holder (identity owner: enrolls once, proves attributes at will)")
intact so the template structure and readability requirements are met.
- Line 3: Update the YAML frontmatter key primary_domain in
use-cases/resilient-identity-continuity.md from the incorrect value "identity"
to the canonical domain "Identity & Compliance" (matching domains/README.md and
other use-cases like private-identity.md and private-registry.md) so the file
references the correct domain.
---
Outside diff comments:
In `@approaches/approach-private-identity.md`:
- Around line 1-383: The approach card "Approach: Private Identity" exceeds the
3000-word limit and fails CI; reduce the document to under 3000 words by
trimming or relocating verbose sections. Specifically, remove or move deep
scenario descriptions (Scenario 1–7), extensive vendor/links lists, long "More
Details" and "Trade-offs" tables, and large example blocks into a companion
document, condense the "Overview", "Key Constraints", "TLDR for Different
Personas" and "Architecture and Design Choices" to concise bullets, and ensure
the resulting content (headers like "A. Registry-Based Membership Proofs", "F.
Issuer-Independent Enrollment via Distributed OPRF", "Open Questions") remains a
focused summary under 3000 words so CI will pass.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9e6a36b8-0700-41fc-a645-5e46228018bd
📒 Files selected for processing (3)
CHANGELOG.mdapproaches/approach-private-identity.mduse-cases/resilient-identity-continuity.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: Entries must go under[Unreleased], include a markdown link to the changed file,
reference the PR number(#NNN), and use a semantic prefix (feat(pattern):,feat(vendor):,fix:,docs:, etc.).
Files:
CHANGELOG.md
approaches/**/*.md
⚙️ CodeRabbit configuration file
approaches/**/*.md: This is an approach card.Structure: Validate against the template at
approaches/_template.md.
File naming and conventions are inapproaches/README.md. Filename must start withapproach-in kebab-case.Approach cards MUST link to both the use case they address and the patterns they combine.
Flag if no pattern or use case cross-references are present.Word limits: warn > 2000, error > 3000.
Files:
approaches/approach-private-identity.md
use-cases/**/*.md
⚙️ CodeRabbit configuration file
use-cases/**/*.md: This is a use case card.Structure & frontmatter: Validate against the template at
use-cases/_template.md.
Rules and scope are inuse-cases/README.md.Check that
primary_domainmatches one of the domains listed indomains/README.md.
Use cases should stay on a single page — flag if the content is excessively long or duplicates linked docs.Warn if section
## 2) Additional Business Contextcontains anything that looks like confidential
information (specific organization names, pilot scopes, committed volumes) — these belong incontext/files.
Files:
use-cases/resilient-identity-continuity.md
🧠 Learnings (3)
📚 Learning: 2026-03-18T09:22:00.023Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
CHANGELOG.mdapproaches/approach-private-identity.md
📚 Learning: 2026-03-19T10:42:51.310Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:51.310Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
Applied to files:
CHANGELOG.md
📚 Learning: 2026-03-20T05:29:10.507Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:19-23
Timestamp: 2026-03-20T05:29:10.507Z
Learning: In ethereum/iptf-map pattern reviews, distinguish between **censorship** (operator blocks user inputs from being processed — affects CR score) and **liveness** (operator withholds output after protocol participation — does not directly affect CR score). For garbled-circuit PSI patterns, the garbler withholding the output decoding table is a liveness concern, not censorship; do not flag it as a CR justification gap.
Applied to files:
CHANGELOG.md
🪛 GitHub Actions: CI Quality Gates
approaches/approach-private-identity.md
[error] 1-1: Content too long: 3461 words (max 3000). approach/private pattern validation failed.
🪛 GitHub Check: vale
approaches/approach-private-identity.md
[warning] 158-158: [vale] approaches/approach-private-identity.md#L158
[IPTF.Marketing] Avoid marketing language: 'unique'. Use neutral, factual terms.
[warning] 251-251: [vale] approaches/approach-private-identity.md#L251
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 252-252: [vale] approaches/approach-private-identity.md#L252
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 304-304: [vale] approaches/approach-private-identity.md#L304
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 316-316: [vale] approaches/approach-private-identity.md#L316
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 360-360: [vale] approaches/approach-private-identity.md#L360
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
use-cases/resilient-identity-continuity.md
[warning] 70-70: [vale] use-cases/resilient-identity-continuity.md#L70
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
🔇 Additional comments (2)
CHANGELOG.md (1)
9-9: Changelog entry format is compliant.This line meets the repository changelog requirements (section placement, semantic prefix, linked files, and PR reference).
As per coding guidelines,
CHANGELOG.mdentries must be under[Unreleased], include markdown links to changed files, reference(#NNN), and use a semantic prefix.approaches/approach-private-identity.md (1)
3-3: Required cross-references are present and clear.The approach links back to use cases and explicitly references combined patterns, matching approach-card conventions.
As per coding guidelines, approach cards must link to the addressed use case and the patterns they combine.
Also applies to: 135-137, 379-379
oskarth
left a comment
oskarth
left a comment
There was a problem hiding this comment.
LGTM; one nit and then asking ZKID team for review and good to go I think
whats the nit? |
oskarth
left a comment
oskarth
left a comment
There was a problem hiding this comment.
Is this updated with the latest write-up as context? re plural identity etc
no, should the map contents go hand in hand with narrative on writeups? if so can do |
oops I was multi-tasking, nit was for -web repo with name order
I think if you paste the latest version of writeup into this branch it'll suggest some edits (phrasing, some links etc) |
addressed in e07ff66 |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
approaches/approach-private-identity.md (1)
1-270:⚠️ Potential issue | 🟡 MinorReduce document to below 2000 words or justify section consolidation.
Document is 2512 words, exceeding the approach-card warning threshold of 2000 words. Consider consolidating vendor recommendations and alternative approaches sections, or splitting into multiple approach documents focused on specific credential sources.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@approaches/approach-private-identity.md` around lines 1 - 270, The document "Approach: Private Identity" exceeds the 2000-word limit; trim it to under 2000 words by consolidating or removing lower-value sections (e.g., merge the "Vendor Recommendations" and "Alternative Approaches Considered" into a single compact table or move detailed vendor listings into an appendix), shorten or combine long explanatory sections like "Implementation Strategy" and "More Details", and collapse verbose examples/scenario text (or split per-credential sources into separate approach cards such as one for "Issuer-Independent OPRF (F)" and another for "Registry-Based Membership (A)"); ensure headings to target for edits include "Vendor Recommendations", "Alternative Approaches Considered", "Implementation Strategy", and "More Details" so reviewers can locate the reductions or justify why the full length must be kept.
♻️ Duplicate comments (2)
use-cases/resilient-identity-continuity.md (2)
3-3:⚠️ Potential issue | 🟡 Minor
primary_domaindoes not match the canonical domain taxonomy.Line 3 uses
identity, but this repo’s domain list expects the canonical label (previously identified asIdentity & Compliance). Please align frontmatter withdomains/README.md.Proposed fix
-primary_domain: identity +primary_domain: Identity & ComplianceAs per coding guidelines,
primary_domainmust match one of the domains listed indomains/README.md.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@use-cases/resilient-identity-continuity.md` at line 3, Update the frontmatter key primary_domain in the document to use the canonical domain label from domains/README.md (replace the current value "identity" with the exact canonical string "Identity & Compliance") so it matches the repo's domain taxonomy; locate the frontmatter entry named primary_domain in use-cases/resilient-identity-continuity.md and update its value accordingly.
92-97:⚠️ Potential issue | 🟡 MinorOpen questions should include issue links for traceability.
Lines 92-97 are now bullets (good), but each question should carry an issue/PR/spec link so decisions can be tracked.
Suggested structure
-- What is the minimum guardian set size for social recovery that provides anti-coercion guarantees without excessive coordination overhead? +- What is the minimum guardian set size for social recovery that provides anti-coercion guarantees without excessive coordination overhead? ([issue](../issues/<id>))As per coding guidelines, use-case open questions are expected to be listed with issue links.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@use-cases/resilient-identity-continuity.md` around lines 92 - 97, Each open-question bullet in the "resilient-identity-continuity" section (the five bullets beginning "What is the minimum guardian set size..." through "What is the production path for private predicate parameters...") must include a corresponding issue/PR/spec link for traceability; update each bullet to append or replace with a link to the relevant issue (e.g., "[`#123`](url)" or spec PR) and if no issue exists, create one and reference it, ensuring links are specific to that question so decisions can be tracked; keep the original question text unchanged and use a consistent link format for all five bullets so reviewers can follow them.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@approaches/approach-private-identity.md`:
- Line 138: In the "Limitations" sentence that currently reads "Requires
distributed OPRF network (liveness depends on threshold availability)…", insert
the missing article so it reads "Requires a distributed OPRF network (liveness
depends on threshold availability)…" — update the text near the "Limitations"
bullet in approaches/approach-private-identity.md where the phrase "Requires
distributed OPRF network" appears.
---
Outside diff comments:
In `@approaches/approach-private-identity.md`:
- Around line 1-270: The document "Approach: Private Identity" exceeds the
2000-word limit; trim it to under 2000 words by consolidating or removing
lower-value sections (e.g., merge the "Vendor Recommendations" and "Alternative
Approaches Considered" into a single compact table or move detailed vendor
listings into an appendix), shorten or combine long explanatory sections like
"Implementation Strategy" and "More Details", and collapse verbose
examples/scenario text (or split per-credential sources into separate approach
cards such as one for "Issuer-Independent OPRF (F)" and another for
"Registry-Based Membership (A)"); ensure headings to target for edits include
"Vendor Recommendations", "Alternative Approaches Considered", "Implementation
Strategy", and "More Details" so reviewers can locate the reductions or justify
why the full length must be kept.
---
Duplicate comments:
In `@use-cases/resilient-identity-continuity.md`:
- Line 3: Update the frontmatter key primary_domain in the document to use the
canonical domain label from domains/README.md (replace the current value
"identity" with the exact canonical string "Identity & Compliance") so it
matches the repo's domain taxonomy; locate the frontmatter entry named
primary_domain in use-cases/resilient-identity-continuity.md and update its
value accordingly.
- Around line 92-97: Each open-question bullet in the
"resilient-identity-continuity" section (the five bullets beginning "What is the
minimum guardian set size..." through "What is the production path for private
predicate parameters...") must include a corresponding issue/PR/spec link for
traceability; update each bullet to append or replace with a link to the
relevant issue (e.g., "[`#123`](url)" or spec PR) and if no issue exists, create
one and reference it, ensuring links are specific to that question so decisions
can be tracked; keep the original question text unchanged and use a consistent
link format for all five bullets so reviewers can follow them.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b3d65d9c-2f3a-4f82-9500-cd4f89af66a1
📒 Files selected for processing (2)
approaches/approach-private-identity.mduse-cases/resilient-identity-continuity.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Validate Documentation Patterns
🧰 Additional context used
📓 Path-based instructions (2)
use-cases/**/*.md
⚙️ CodeRabbit configuration file
use-cases/**/*.md: This is a use case card.Structure & frontmatter: Validate against the template at
use-cases/_template.md.
Rules and scope are inuse-cases/README.md.Check that
primary_domainmatches one of the domains listed indomains/README.md.
Use cases should stay on a single page — flag if the content is excessively long or duplicates linked docs.Warn if section
## 2) Additional Business Contextcontains anything that looks like confidential
information (specific organization names, pilot scopes, committed volumes) — these belong incontext/files.
Files:
use-cases/resilient-identity-continuity.md
approaches/**/*.md
⚙️ CodeRabbit configuration file
approaches/**/*.md: This is an approach card.Structure: Validate against the template at
approaches/_template.md.
File naming and conventions are inapproaches/README.md. Filename must start withapproach-in kebab-case.Approach cards MUST link to both the use case they address and the patterns they combine.
Flag if no pattern or use case cross-references are present.Word limits: warn > 2000, error > 3000.
Files:
approaches/approach-private-identity.md
🧠 Learnings (2)
📚 Learning: 2026-04-14T08:10:15.334Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 145
File: use-cases/resilient-identity-continuity.md:26-26
Timestamp: 2026-04-14T08:10:15.334Z
Learning: In ethereum/iptf-map’s `use-cases/` markdown files, the `## 3) Actors` section may use a single-line inline `·`-separated actor list (e.g., `Actor A · Actor B · Actor C`) instead of a bulleted list. If the formatting matches `use-cases/_template.md`, do not flag it as non-compliant.
Applied to files:
use-cases/resilient-identity-continuity.md
📚 Learning: 2026-03-18T09:22:00.023Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
approaches/approach-private-identity.md
🪛 GitHub Check: vale
approaches/approach-private-identity.md
[warning] 25-25: [vale] approaches/approach-private-identity.md#L25
[IPTF.Marketing] Avoid marketing language: 'scalable'. Use neutral, factual terms.
[warning] 27-27: [vale] approaches/approach-private-identity.md#L27
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 126-126: [vale] approaches/approach-private-identity.md#L126
[IPTF.Marketing] Avoid marketing language: 'unique'. Use neutral, factual terms.
[warning] 203-203: [vale] approaches/approach-private-identity.md#L203
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 204-204: [vale] approaches/approach-private-identity.md#L204
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 226-226: [vale] approaches/approach-private-identity.md#L226
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
🪛 LanguageTool
use-cases/resilient-identity-continuity.md
[grammar] ~46-~46: Ensure spelling is correct
Context: ...l IDs or email for web services, social vouches or economic stake for communities. Each...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
approaches/approach-private-identity.md
[style] ~138-~138: The double modal “Requires distributed” is nonstandard (only accepted in certain dialects). Consider “to be distributed”.
Context: ...aHonk, BN254) Limitations: Requires distributed OPRF network (liveness depends on thres...
(NEEDS_FIXED)
🔇 Additional comments (2)
approaches/approach-private-identity.md (1)
25-27: Neutralize flagged marketing-style wording (scalable/only/unique) for repo tone consistency.This is the same prose-tone issue previously raised on this PR; keeping it as a duplicate note only.
Also applies to: 126-126, 203-204, 226-226
use-cases/resilient-identity-continuity.md (1)
13-13: This comment is incorrect. The organizations and deployment details referenced in section 2 are publicly documented systems, not confidential information:
- Human Passport and TACEO are publicly documented projects with their own technical documentation (publicly available URLs)
- The "13-node threshold vOPRF" is TACEO's publicly documented technical architecture, not a confidential volume or pilot scope
- "Ships for grant sybil resistance today" describes current public use, not an undisclosed pilot commitment
Per the coding guidelines, the restriction on organization names applies to confidential details (specific internal orgs, pilot scopes, committed volumes). This file appropriately documents public reference implementations as proof-points that the approach works in practice. The section transitions naturally into "Related work and deployments" (listing ZKPassport, Self, Anon Aadhaar, World ID, Semaphore, etc.), and section 7 explicitly lists "Deployed vOPRF: [TACEO]," consistent with the template's intent to reference existing approaches and deployments.
> Likely an incorrect or invalid review comment.
|
@coderabbitai approve |
✅ Actions performedComments resolved and changes approved. |
3 participants
What are you adding?
Description
closes part of #136
This pull request introduces comprehensive documentation for the "Resilient Identity Continuity" use case and its corresponding approach. It defines the requirements, challenges, and solutions for maintaining on-chain identity proofs when the original credential issuer is unavailable or adversarial. The update includes both a high-level use case description and a detailed technical approach, covering architecture, recovery mechanisms, sybil resistance, and trade-offs.
Key additions and changes:
Use Case Definition and Context:
use-cases/resilient-identity-continuity.md) outlining the need for identity proofs that survive issuer failure, detailing business context, actors, core problems, and requirements. It also summarizes related work, open questions, and links to standards and prior art.Technical Approach and Architecture:
approaches/approach-resilient-identity-continuity.md) that:Open Questions and Future Considerations:
Links to Related Work and Standards:
Checklist
Summary by CodeRabbit