Skip to content

STF-2255: Clarify minFraud verification input descriptions - #19

Merged
oschwald merged 4 commits into
mainfrom
wstorey/stf-2255-clarify-minfraud-email-and-phone-verification-input
Nov 3, 2026
Merged

oschwald merged 4 commits into
mainfrom
wstorey/stf-2255-clarify-minfraud-email-and-phone-verification-input

Conversation

@horgh

@horgh horgh commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

Makes the same changes to the minFraud verification field descriptions as maxmind/dev-site#1808. The text matches the developer site. Each commit covers one item:

  1. Pending verifications are not failures. The result, method, and time fields describe the most recent completed verification. A pending, abandoned, or expired verification is not complete and is not a failure. If no verification is complete, leave out the field.
  2. verification_time and phone_verification_time are the time the verification succeeded or failed, not the time the link or code was sent.
  3. The email and phone verification fields must reflect the state as of the time of the event.
  4. Leave out the time if no verification was attempted or no verification is complete.

Only descriptions change. Each commit regenerates bundled/minfraud.yaml.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation
    • Clarified that email and phone verification details refer to the most recent completed verification.
    • Specified that timestamps reflect when verification succeeded or failed, and that incomplete or unattempted verifications should not be reported.
    • Clarified how success indicators distinguish failed verifications from pending, abandoned, or expired attempts.
    • Retained the accepted email timestamp range and warning behavior.

horgh and others added 4 commits November 3, 2026 21:47
The verification result fields did not say what to send while a
verification is pending. A merchant could send false for a link that
the user has not clicked yet, and minFraud would see a failed check.

Define the result as that of the most recent completed verification.
A pending, abandoned, or expired verification is not complete and is
not a failure. If no verification is complete, leave out the field.

The phone method field described the most recent verification attempt,
which can be pending. Make it describe the same completed verification
as the result field, so that a merchant does not send a method from a
pending attempt next to a result from an earlier one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"The most recent date and time a verification was attempted" could
mean the time the merchant sent the link or code, or the time the user
used it. For email, these times can be days apart.

Define the time as the time the most recent completed verification
succeeded or failed. A pending verification is neutral, so the time a
link or code was sent is not a result time.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
You can score a stored event later with /event/time. The verification
fields did not say whether to send the state at the time of the event
or at the time of the request. If a merchant sends the current state,
the model sees information from after the event.

Say that the email and phone verification fields must reflect the
state as of the time of the event.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The time fields did not say to leave out the field when no
verification was attempted. An integration that always sends a value
could send a placeholder such as 1970-01-01T00:00:00Z. The web service
accepts it and records a verification that did not occur.

Say to leave out the time if no verification was attempted or no
verification is complete.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copilot AI balanced review requested due to automatic review settings November 3, 2026 21:48
@coderabbitai

coderabbitai Bot commented Nov 3, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

No actionable comments were generated in the recent review.

Walkthrough

The email and phone verification descriptions now define fields in terms of the most recent completed verification. They clarify timestamp rules and distinguish failed verification from attempts that remain pending, abandoned, or expired.

Changes: Verification reporting

Layer / File(s) Summary
Completed verification reporting rules
components/minfraud-request.yaml, bundled/minfraud.yaml
The descriptions define when to report verification methods, timestamps, and outcomes. Timestamps refer to when verification succeeded or failed and must reflect the state at the event time. Existing timestamp bounds and warnings remain. Incomplete attempts are not failures.

Estimated code review effort: 2 (Simple) | ~5 minutes

Change: Other

Possibly related PRs

  • maxmind/openapi#7: Adds email verification fields whose reporting descriptions are updated in this PR.

Suggested reviewers: oschwald

Merge Risk: Minimal · up to 9d98e

The documentation clarifies completed verification outcomes and event-time reporting. No actionable merge-blocking risk is identified.

Pre-merge checks: Passed 5
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title clearly and concisely identifies the clarification of minFraud verification input descriptions, which is the main change.
Docstring Coverage Passed No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage

Explanation

No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)

Finishing Touches
Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Tip

🎯 Customize your risk assessments

Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.

✅ Automatic approvals, with your rules

Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.

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.

Share

A rabbit checks the email trail,
Then hops to phones without a fail.
Completed checks mark when they passed,
Or failed at last—not attempts past.
Pending waits; the rabbit rests.

CodeRabbit Verify

  • Run CodeRabbit Verify to test the changes in this pull request.
Recent review info
Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: 44c9b439-348c-41c2-99d1-afbebe8be5d3
Commits

Reviewing files that changed from the base of the PR and between 05080b0 and 9d98ec2.

Files selected for processing: 2
  • bundled/minfraud.yaml
  • components/minfraud-request.yaml

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

No unresolved review concerns are identified for the verification-field description updates.

No open issues 🎉

What changed in this PR

Clarifies minFraud’s email and phone verification input descriptions without changing schema structure or runtime behavior.

Changes:

  • Specifies that verification fields describe the most recent completed verification as of the event time.
  • Clarifies that timestamps record success or failure, not when a link or code was sent.
  • Explains that pending, abandoned, and expired verifications are not failures, and fields should be omitted when no verification is complete.
File Description
components/​minfraud-request.yaml Updates the source descriptions for email and phone verification fields.
bundled/​minfraud.yaml Mirrors the clarified descriptions in the generated bundle.

Review effort: Balanced

@oschwald
oschwald merged commit 79afbcc into main Nov 3, 2026
7 checks passed
@oschwald
oschwald deleted the wstorey/stf-2255-clarify-minfraud-email-and-phone-verification-input branch November 3, 2026 23:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants