Define identity-verification requirements around risk and access
Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Obtain the business action being protected, consequence of misuse, user populations, supplied fraud observations, policy requirements, accessibility constraints, support capacity, and any candidate methods described by the user. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Define the protected action and the identity assertion needed. Distinguish proving control of a communication channel, authenticating an existing account, and establishing a person's real-world identity; these solve different problems. 2. Map supplied misuse scenarios to impact and plausible failure paths. Separate observed incidents from hypothetical threats and avoid inventing regional fraud patterns or numerical risk levels. 3. Identify legitimate-user constraints such as shared devices, unreliable connectivity, inaccessible channels, name changes, or lost access when supplied. Consider both false acceptance and false rejection rather than maximizing friction alone. 4. Compare candidate approaches on assurance needed, accessibility, user effort, recovery, operational burden, and evidence available. Channel possession does not automatically establish legal identity or eliminate account takeover. 5. Specify fallback, exception, recovery, and escalation requirements, including who makes consequential decisions. Prevent a weaker recovery path from silently undermining the main requirement; keep unresolved policy constraints explicit. 6. Propose a decision matrix and evaluation protocol based on supplied criteria: task completion, abandonment, erroneous rejection, support burden, and relevant abuse outcomes. No integration, provider recommendation based on unseen facts, or security certification is performed.
Output: Return the protected-action brief, risk and friction scenarios, requirement matrix, candidate tradeoffs, fallback and recovery questions, and proposed evaluation measures.
Quality checks: Avoid current legal or KYC conclusions, provider/country performance claims, fixed scale thresholds, and security guarantees. State what the method proves, what it does not, and which policy owner must resolve uncertainties.
Worked example: A membership service wants to protect address changes. Supplied policy requires existing-account authentication, but many members cannot receive SMS. Frame alternate accessible verification and recovery requirements instead of declaring SMS mandatory or universally secure. Measure successful legitimate changes and support burden alongside unauthorized-change reports; do not claim a deployed solution or legal compliance.