docs: RFC 0002 for explicit consent at signup - #1905
Conversation
# Conflicts: # web/sdk/client/views/pat/pat-details-view.tsx
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis RFC proposes explicit signup consent with configurable documents, flow intent propagation, consent validation, immutable consent records, audit events, and SDK checkbox support. It also defines errors, limitations, alternatives, references, and implementation order. ChangesExplicit Signup Consent
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🟡 Moderate · up to This draft changes signup/login behavior and consent records but still leaves a post-commit audit-loss path, potentially unsafe configured links, and conflicting or incomplete authentication and error-handling rules. These could cause missing compliance records or broken and misleading signup flows, so the PR needs fixes or explicit owner acceptance before merge. Suggested reviewers: 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
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 |
Coverage Report for CI Build 33112327895Coverage remained the same at 49.168%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
There was a problem hiding this comment.
Actionable comments posted: 6
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1dc2fe21-4385-44c5-ac55-af0f437bbbc7
📒 Files selected for processing (1)
docs/rfcs/0002-explicit-consent-at-signup.md
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.
Shorter sentences and plainer wording throughout, and cut the paragraphs that restated a decision already made earlier in the document. No design changes: every decision, file reference and verified claim is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 4f80a22e-3585-4be4-9eb5-ef22fb91b974
📒 Files selected for processing (1)
docs/rfcs/0002-explicit-consent-at-signup.md
Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review.
|
Few points as we discussed -
|
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 3f4716e0-66c8-40e4-a967-5a41169a19d1
📒 Files selected for processing (1)
docs/rfcs/0002-explicit-consent-at-signup.md
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.
Summary
app.consentconfig, the client sends the accepted document ids, and frontier writes an immutableuser_consentsrecord together with the new user in one transaction. Withapp.consentunset or disabled, nothing changes.flow_intentfield onAuthenticateRequestto separate login from signup. Consent is a signup-only requirement, and today both are the same request, so a login silently creates the account it should have refused and the consent check has nothing to key off before the OIDC redirect.usersso records outlive account deletion, andBEFORE UPDATE/BEFORE DELETEtriggers plus a create-only repository making them unmodifiable.user.consent_grantedaudit record fields, including why its actor has to be set explicitly rather than left to context enrichment on the skip-listed auth endpoints, and why it cannot be atomic with the consent write.