Military Identity Verification

Overview

Military Verification confirms a user's military service affiliation for benefit, discount, and eligibility programs. Unlike the identity-proofing workflows, this establishes an attribute about a user rather than establishing who they are — it answers "is this person affiliated with the military?", not "is this person who they claim to be."

The workflow leads with an instant check against authoritative service records and automatically steps up to document review for users who cannot be confirmed instantly. Most users are confirmed in seconds. The document path ensures coverage for everyone else rather than turning away genuine service members who don't match on the first pass.

Level of Assurance

Not applicable — this workflow verifies an attribute, not an identity. Assurance derives from the source: instant verification matches against authoritative service records; the document path authenticates a service document under review.

Pair this workflow with an identity-proofing workflow when both the person and the affiliation must be established.

User Friction Level

Low for the instant path — one form, no redirect, no document. Medium for the document path, which adds an upload and a short review wait.

End User Requirements

Instant path: name, date of birth, contact details, and branch of service.

Document path: the above, plus a service document (DD-214, military ID, or equivalent) and a device able to upload a file.

Speed

Seconds for the instant path. Roughly 10–15 seconds for the document path — the document review is asynchronous and the decision is not available immediately after upload. See Timing and the review window.

Use Cases & Fraud Prevention

• Retail and e-commerce military discount programs where self-attestation is currently the only control.
• Benefit and eligibility gating for services restricted to service members, veterans, or their families.
• Any program where affiliation determines pricing or access and manual document review does not scale.
• Fraud prevention: false affiliation claims, discount abuse, credential sharing, forged or reused service documents.

How It Works

flowchart LR
    Start([User begins]) --> PII[Instant Verification<br/>Name, DOB, branch vs. service records]
    PII -->|Confirmed| Approve([Verified])
    PII -->|Not confirmed| Deny([Not verified])
    PII -->|Inconclusive| Doc[Document Review<br/>Service document upload]
    Doc -->|Review passes| Approve
    Doc -->|Review fails| Deny
    Doc -->|Review unresolved| Review([Under review])

Instant Verification: The user submits their name, date of birth, phone, and branch of service. These are matched against authoritative service records. A confirmed match returns approve immediately. A definitive non-match returns deny. An inconclusive result returns obligation, routing to document review.

Document Review: The user uploads a service document, which is attached to the existing transaction and reviewed. Up to three upload attempts are permitted per transaction. Review is asynchronous — see the timing note below.

Attribute Summary

What Gets Established on Approval

• Service affiliation — confirmation that the user is affiliated with the military, along with the community segment returned by the provider.
• Verification transaction ID — a provider-side identifier for the verification, stable across both calls of the document path and useful for support and audit.

This workflow does not bind devices or establish a credential. Pair it with an identity-proofing workflow where those are required.

Integration: ID Dataweb API

This workflow is commonly integrated API-only: your application owns the entire user experience, collects the user's details in your own UI, and calls the API server-side. There is no redirect and no hosted capture screen.

Steps chain via forwardApiKey. The /slverify response signals whether document review applies. See API Authentication for token acquisition.

sequenceDiagram
    participant App as Your Application
    participant IDW as ID Dataweb API
    participant User as End User

    App->>IDW: POST /token (apiKey:secret)
    IDW-->>App: access_token

    App->>IDW: POST /slverify (name, DOB, phone, organization)
    IDW-->>App: policyDecision + transaction_id

    alt Confirmed instantly
        Note over App,IDW: policyDecision = approve — done
    else Not confirmed
        Note over App,IDW: policyDecision = deny — done
    else Inconclusive
        IDW-->>App: policyDecision = obligation + forwardApiKey
        User->>App: Provides service document
        App->>IDW: POST /document/upload (file, asi, apikey)
        IDW-->>App: file_uploaded + attempt
        Note over App,IDW: Wait for the review to complete
        App->>IDW: POST /slverify (apikey, asi, original attributes)
        IDW-->>App: policyDecision (approve / deny)
    end

Request attributes

The /slverify request carries credential (a subject identifier of your choosing — typically the user's email) and a userAttributes array:

dateCreated is MM/DD/YYYY HH:mm:ss.

Reading the response

Service data is returned in acquiredAttributes and userAssertionList:

serviceOffering indicates which path produced the result — instant verification or document verification.

Step-by-step Setup

• Obtain an access_token — see API Authentication.
• Call /slverify with the collected attributes and read policyDecision.
• On obligation, upload the document with asi set to transaction_id and apikey set to the forwardApiKey from that response.
• Pass transaction_id from the first response as asi in all subsequent calls, and keep credential identical across every call in the transaction.
• Replay the original userAttributes unchanged on the post-upload /slverify. The asi carries the transaction state; altering attributes between calls causes the response to echo the changed values.

Timing and the review window

Document review is asynchronous. Calling /slverify immediately after /document/upload may return an unresolved result. Measured latency in preproduction is approximately 10–15 seconds from the initial obligation response.

Wait before the post-upload /slverify rather than calling immediately. A first check at around 5 seconds is a reasonable starting point.

Test documents

Document review outcomes in test mode are driven by the leading token of the uploaded filename:

Test document images are available from the provider's documentation. They have no effect on live programs.

Step-by-step How to Test

• Instant approve: Submit with first name Approve and any other values.
• Document path: Submit with last name UPLOAD, then upload a file whose name begins with approve_. Allow roughly 10–15 seconds before reading the decision.
• Reject: Submit with last name REJECT.
• Document rejection: Trigger the document path, then upload a file beginning with reject_.

Related Resources

→ Trust Progression Model | → API Authentication | → Gateway (OIDC) Integration