Track Email and Mobile Attribute Verification

Problem

ThunderID needs a trusted way to retain whether a user's email address or mobile number has been successfully verified.

Having an email address or mobile number on a user profile does not mean that the user has proven control of it. Existing registration, onboarding, recovery, and authentication flows may already perform this proof, but the result is not currently retained as trusted verification metadata.

This creates several problems:

• Applications cannot reliably determine whether a contact attribute has been verified.
• Successful verification performed in one flow cannot be reused as trusted metadata elsewhere.
• Verification information cannot be exposed consistently through user management APIs.
• Contact changes can leave previously established verification evidence ambiguous unless verification is explicitly tied to the current value.

Verification represents proof of control over the user's current contact value at a specific point in time.

The verification state is independent of account lifecycle states such as ACTIVE, LOCKED, and SUSPENDED.

Scope

This feature includes:

• Record successful verification of supported user contact attributes.
• Initially support email and mobile number verification.
• Reuse successful contact-proof mechanisms already performed by registration, onboarding, recovery, authentication, or similar flows.
• Record when the current attribute value was successfully verified.
• Expose verified attribute information through user management APIs.
• Treat verification metadata as server-managed and read-only through normal profile APIs.
• Remove verification metadata when the corresponding contact value changes or is removed.
• Prevent a previously verified value from automatically regaining verification when restored later.
• Provide a reusable mechanism for flows to record a successful attribute verification.
• Ensure verification is associated with the correct user, attribute, and current attribute value.
• Preserve verification metadata across unrelated profile updates.
• Support auditing of verification operations where applicable.
• Declarative users are excluded from attribute verification by design

Use Cases

Acceptance Criteria

Verification Recording

• A supported flow can record that a user's email or mobile number has been successfully verified.
• Verification is recorded only after a successful trusted contact-bound proof.
• Verification is associated with the target user, attribute, and current attribute value.
• Verification metadata includes the time at which the successful verification was recorded.
• Email and mobile number verification use the same extensible verification model.
• Recording verification does not introduce or modify an account lifecycle state.
• A reusable verification-recording mechanism is available so individual flows do not need to implement persistence independently.

Verification Integrity

• Verification cannot be established using client-provided flags or ordinary profile attributes.
• Changing a verified contact value removes its existing verification metadata.
• Removing a verified contact value removes its verification metadata.
• Changing a contact value from A → B → A does not restore the previous verification for A.
• Unrelated profile updates preserve existing verification metadata.
• Verification cannot be associated with a contact value different from the one that was successfully proven.
• Concurrent contact and verification updates must not result in stale verification metadata being associated with a newer contact value.

User Management API

• User responses expose verified attribute information for supported attributes.
• Verification metadata is exposed in a structure that can support additional metadata in the future.
• Normal user create and update operations cannot directly set or modify verification metadata.
• Verification metadata is treated as server-managed information.
• The API does not expose unrelated internal system attributes when returning verification information.

Flow Integration

• Existing registration, onboarding, recovery or other supported flows can opt in to recording verification after a successful contact-bound proof.
• Existing OTP generation, delivery, and validation mechanisms remain responsible for establishing the proof.
• The verification-recording capability only records the result of an already successful proof.
• A successful OTP or token validation does not automatically mark an attribute as verified unless the surrounding flow provides sufficient trusted context.

Release Note

Track Verified Email and Mobile Attributes

ThunderID can now retain trusted verification information for user email addresses and mobile numbers after successful contact verification.

Key capabilities include:

• Record verified contact attributes after successful email or mobile verification.
• Track verification time for the user's current contact value.
• Reuse existing verification flows instead of implementing attribute-verification state separately for each flow.
• Expose verification metadata through user APIs for applications that need to determine whether contact information has been verified.
• Protect verification integrity by preventing normal profile updates from setting verification metadata.
• Automatically invalidate verification when the corresponding email address or mobile number changes.

Evangelism Materials

Positioning

Contact information and verified contact information are not the same thing.

ThunderID attribute verification allows applications to distinguish between an email address or mobile number that merely exists on a user profile and one for which the user has successfully demonstrated control.

Verification is retained as trusted metadata and remains tied to the current contact value.

Core Messages

1. Know which contact information has been verified.
   Distinguish user-provided email addresses and mobile numbers from contact values whose ownership has been successfully proven.

2. Reuse proof across identity flows.
   Let registration, onboarding, recovery, and other flows record verification using a common mechanism.

3. Keep verification tied to the current value.
   Automatically invalidate verification when the corresponding email address or mobile number changes.

4. Protect trusted verification metadata.
   Prevent ordinary profile updates or client-provided flags from marking contact information as verified.

5. Expose verification consistently.
   Make verified contact information available through user management APIs using an extensible metadata model.