Registry entry

United States Statement Regarding a Valid Lost or Stolen Passport Book and/or Card (Form DS-64)

Report a valid U.S. passport book and/or card as lost or stolen, using the data model of Form DS-64 (Statement Regarding a Valid Lost or Stolen U.S. Passport Book and/or Card). Filing this form electronically cancels the reported passport in the Consular Lost and Stolen Passport System (CLASP), so it can no longer be used for travel; a bearer who later travels on a reported-lost passport may be detained on U.S. entry. If the applicant is also applying for a new passport (the common case), Form DS-64 is submitted together with Form DS-11 (see us/dos/passport-application-ds11); if not, it is mailed to CLASP with a photocopy of a valid government-issued photo ID, or reported online/by phone at travel.state.gov. If the lost/stolen passport is already expired, it is no longer valid and this form is not needed. It does not submit the report; the live U.S. Department of State source is always authoritative (see VERIFICATION.md).

You are viewing v1.0.0

The latest published version of this schema is v1.1.1 — see the current reference page. Published versions are immutable; this page stays for agents pinned to us/dos/lost-or-stolen-passport-ds64@1.0.0.

Registry entry

us/dos/lost-or-stolen-passport-ds64

Jurisdiction
United States · national
Version
1.0.0
Verification
draft
Authority
U.S. Department of State, Bureau of Consular Affairs

GovSchema spec v0.2

Authoritative source Form DS-64 (OMB Control No. 1405-0014)

Machine access

Schema document
registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

35 fields across 5 steps, read from the published schema.json — names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Which document(s) are being reported

  • passportBookStatus enum required

    not_applicable if the applicant is not reporting a passport book. At least one of passportBookStatus or passportCardStatus must be lost or stolen.

    enum: not_applicable | lost | stolen
  • passportCardStatus enum required

    not_applicable if the applicant is not reporting a passport card. The passport book and card have different numbers; at least one of passportBookStatus or passportCardStatus must be lost or stolen.

    enum: not_applicable | lost | stolen
  • isConnectedToNewApplication boolean required

    If true, submit this form together with Form DS-11 (Application for a U.S. Passport). If false, mail this form alone with a front-and-back photocopy of a valid government-issued photo ID to the Consular Lost and Stolen Passport Unit (CLASP), or report online or by phone instead.

Identifying information of passport holder

  • lastName string required

    Personal identifier; handle as sensitive data.

    length: 1–80
  • firstName string required

    Personal identifier; handle as sensitive data.

    length: 1–80
  • middleName string optional

    Personal identifier; handle as sensitive data.

    length: 0–80
  • nameChangedSincePassportIssued boolean required

    If true, also give nameAtPassportIssuance.

  • nameAtPassportIssuance string optional

    Personal identifier; handle as sensitive data. Required when nameChangedSincePassportIssued is true.

    length: 0–160
  • dateOfBirth date required

    Personal identifier; handle as sensitive data. YYYY-MM-DD.

  • placeOfBirth string required

    City & state if in the U.S., or city & country if born abroad.

    length: 1–120
  • socialSecurityNumber string optional

    Personal identifier; handle as sensitive data. 9 digits, no separators. Providing the SSN is voluntary per the form's Disclosure notice, but is used to verify the identity of the person reporting the lost/stolen passport and to identify the passport being reported; failure to provide it may result in processing delays.

    pattern

Contact information

  • currentAddressLine1 string required

    Street address.

    length: 1–120
  • currentAddressCity string required

    City of the applicant's current address.

    length: 1–80
  • currentAddressState string optional

    Two-letter USPS state abbreviation. Not applicable to a foreign address; see currentAddressCountry instead.

    pattern
  • currentAddressPostalCode string required

    5-digit or ZIP+4 U.S. format if in the U.S.; the form also permits a foreign postal code here for an address outside the U.S. (see currentAddressCountry).

    length: 0–15
  • currentAddressCountry string optional

    Required only when the current address is outside the United States.

    length: 0–100
  • telephoneNumber string required

    Personal identifier; handle as sensitive data. In international E.164 format, e.g. +12025551234.

    pattern
  • alternateTelephoneNumber string optional

    Personal identifier; handle as sensitive data. In international E.164 format.

    pattern
  • emailAddress string optional

    Personal identifier; handle as sensitive data.

    length: 0–160

Details of the loss or theft

  • lossOrTheftExplanation string required

    Answer completely; if the exact circumstances are unknown, be as exact as possible.

    length: 1–2000
  • lossOrTheftLocation string required

    Provide the address if known: city and state if in the U.S., or city and country if known to have occurred abroad.

    length: 1–500
  • lossOrTheftDate date required

    YYYY-MM-DD. If the exact date is unknown, give the last date the applicant remembers having it in their possession.

  • policeReportFiled boolean required

    If true and the report is available, submit a copy with the form.

  • lostPassportBookNumber string optional

    Personal identifier; handle as sensitive data. Applicable when passportBookStatus is lost or stolen. A reused number cannot be reissued.

    length: 0–20
  • lostPassportBookIssueDate date optional

    YYYY-MM-DD. Applicable when passportBookStatus is lost or stolen.

  • lostPassportCardNumber string optional

    Personal identifier; handle as sensitive data. Applicable when passportCardStatus is lost or stolen. The book and card have different numbers.

    length: 0–20
  • lostPassportCardIssueDate date optional

    YYYY-MM-DD. Applicable when passportCardStatus is lost or stolen.

  • hasOtherLostOrStolenPassports boolean required

    Refers to prior incidents, separate from the one being reported now. If true, also give otherLostPassportCount and otherLostPassportApproximateDates. If more than one valid U.S. passport previously issued to the applicant was lost or stolen, the replacement passport may be limited in validity.

  • otherLostPassportCount integer optional

    Required when hasOtherLostOrStolenPassports is true.

    range: 1–∞
  • otherLostPassportApproximateDates string optional

    Required when hasOtherLostOrStolenPassports is true. Free text; the form allows more than one approximate date.

    length: 0–200
  • otherLostPassportPoliceReportFiled boolean optional

    Required when hasOtherLostOrStolenPassports is true. If true and the report is available, submit a copy with the form. A distinct field from policeReportFiled: the form has two separate 'Did you file a police report?' questions — this one under the other-lost-passports history question, the other under the current loss/theft-date question.

Signature

  • isMinorUnder16 boolean required

    If true, both parents/legal guardians must sign (see guardianSignatureDate and secondGuardianSignatureDate) instead of the applicant, and a front-and-back photocopy of each signing guardian's ID must accompany the form. If only one parent/guardian has sole legal authority to obtain a passport for the child (22 C.F.R. 51.28), a supporting document (e.g. a court order proving sole legal custody, or Form DS-5525) must be included instead of the second guardian's signature. If false, the applicant signs (see applicantSignatureDate).

  • applicantSignatureDate date optional

    Required when isMinorUnder16 is false. YYYY-MM-DD. By signing, the applicant declares under penalty of perjury that they have read the warning on page one, the information provided is correct and complete, they have not given the passport to another person or disposed of it in an unauthorized manner, they understand the reported passport(s) will be invalidated, and they will return it to Passport Services if it is subsequently found.

  • guardianSignatureDate date optional

    Required when isMinorUnder16 is true, unless the sole-legal-authority exception applies (see isMinorUnder16). YYYY-MM-DD.

  • secondGuardianSignatureDate date optional

    Required when isMinorUnder16 is true and no parent/guardian has sole legal authority under 22 C.F.R. 51.28 (see isMinorUnder16). YYYY-MM-DD.

Verification record

This file is the source-review record for this document version, per the manual-source-review-v1 practice. It documents the provenance of the published fields and flow, records a mock-data test run of the field set, and states the current verification claim honestly.

Current claim

  • status: draft
  • verification.method: manual-source-review-v1
  • verification.lastVerifiedAt: 2026-07-01

The document was derived from and cross-checked against the official sources below, but the full field-by-field comparison the practice requires (confirming every published field, type, requiredness, and constraint against the live form — manual-source-review-v1 → Procedure step 2) has not yet been independently re-verified by a second reviewer. It therefore remains draft, not verified. Consumers SHOULD treat this as an accurate, source-grounded structural reference, not a load-bearing description of the live process.

Why this candidate was added (phase 2 of the GOV-282 brief)

GOV-282 names "Passport (First-Time, Renewal, Lost, etc.)" as one of five focus verticals. Before this document, the registry had eight published passport documents across seven jurisdictions (US, GB, IE, AU, CA, NZ, SG) covering first-time and renewal applications, but no "Lost" candidate at all — not even in the discovery backlog — despite "Lost" being named explicitly in the brief. This document closes that gap for the U.S.: it was added directly as a new catalog candidate and authored to published in the same cycle, mirroring how us/ca/sos/corporation-formation-arts-gs and us/ca/dmv/vehicle-title-transfer opened gaps in prior cycles.

Sources examined

  • Document (id, version): us/dos/lost-or-stolen-passport-ds64 / 1.0.0
  • Spec version: GovSchema 0.2.0
  • Authority: U.S. Department of State, Bureau of Consular Affairs (DOS)
  • Primary source URL: https://travel.state.gov/content/travel/en/passports/have-passport/lost-stolen.html
  • Official form id: Form DS-64 (OMB Control No. 1405-0014)
  • Form PDF: https://eforms.state.gov/Forms/ds64_pdf.pdf — fetched directly with a plain curl request; no access block encountered, consistent with the sibling us/dos/passport-application-ds11 and us/dos/passport-renewal-ds82 documents also sourced from state.gov. Parsed with the pdf-parse npm package (PDFParse.getText()). Page 2 of 2 (the actual data-collection form — document-status checkboxes, identity, contact, loss/theft details, and signature block) extracted as clean, legible text and was transcribed field-by-field from that output. Some of page 1's boilerplate/legal text (the filing-options list, warning, and Privacy Act statement) extracted with font-encoding artifacts — a custom-glyph substitution in this PDF's generation tool scrambled some letters (e.g. "book and/or card" rendering as "ERRNDQGRUFDUG" in places) — but this did not affect any of the page 2 field labels this schema is built from, which were unaffected and fully legible.
  • Retrieved / reviewed: 2026-07-01
  • Reviewer: GovSchema Engineering (initial authoring source-review)

Not a time-versioned (edition) form

A lost-or-stolen-passport report is a one-time filing tied to a specific incident, not filed "for" a recurring tax/award year — applying the GSP-0005 §2 coexistence test, there is no scenario where two editions of the DS-64 data model need to coexist for the same applicant. This document is therefore authored at the plain (non-edition) registry path, registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/. A future DS-64 revision that changes the field set ships as a new version, not an edition.

What was confirmed against the source

  • Form identity and purpose. Form DS-64 reports a valid U.S. passport book and/or card as lost or stolen, cancelling it in the Consular Lost and Stolen Passport System (CLASP) so it can no longer be used for travel. Confirmed against the form's own title and the travel.state.gov "Report Your Passport Lost or Stolen" page.
  • Full field set (page 2). Transcribed directly from the decoded PDF text: the book/card-and-status selection; the connected-new-application question; identity (name, name change, date/place of birth, SSN with its voluntary disclosure note); contact (address, phone, alternate phone, email); the loss/theft explanation, location, and date questions (including the "be as exact as possible if unknown" instruction); the police-report question; the lost book/card number-and-issue-date fields (with the "book and card have different numbers, a reused number cannot be reissued" note); the other-lost-passports history question with count and approximate-dates follow-ups; and the signature block, including the minor-under-16 dual-parent signature path and its sole-legal-authority exception (22 C.F.R. 51.28, Form DS-5525).
  • Filing-channel guidance. The four filing options (online, in-person with a new DS-11, by phone, by mail to CLASP with a photo-ID photocopy) and the already-expired-passport exception are recorded in the document description and isConnectedToNewApplication's description, transcribed from page 1's text (unaffected by the font-encoding artifacts noted above, since these particular sentences extracted cleanly).

Mock-data test run

Per the issue's phase-4 instruction to test-run the schema with valid mock data, a representative filled-out report was authored and checked field-by-field against every type/required/validation constraint in schema.json (string length, regex pattern, enum membership, integer minimum, date format, boolean type, and the conditional-field notes called out in field descriptions):

``json { "passportBookStatus": "stolen", "passportCardStatus": "not_applicable", "isConnectedToNewApplication": true, "lastName": "Torres", "firstName": "Maria", "middleName": "Alejandra", "nameChangedSincePassportIssued": false, "dateOfBirth": "1990-03-14", "placeOfBirth": "San Diego, California", "currentAddressLine1": "482 Harbor View Drive, Suite 210", "currentAddressCity": "San Diego", "currentAddressState": "CA", "currentAddressPostalCode": "92101", "telephoneNumber": "+16195550142", "lossOrTheftExplanation": "Backpack was stolen from a parked car; the passport was inside a zipped travel pouch.", "lossOrTheftLocation": "San Diego, California", "lossOrTheftDate": "2026-06-20", "policeReportFiled": true, "lostPassportBookNumber": "123456789", "lostPassportBookIssueDate": "2019-05-10", "hasOtherLostOrStolenPassports": false, "isMinorUnder16": false, "applicantSignatureDate": "2026-07-01" } ``

This models Maria Alejandra Torres — the same individual used in the sibling us/ca/sos/business-entity-llc-formation, us/ca/sos/corporation-formation-arts-gs, us/irs/employer-identification-number-ss4, and us/ca/dmv/vehicle-title-transfer mock scenarios — reporting her passport book stolen from her car and filing this form together with a new DS-11 application, the most common individual scenario. The scenario exercises the passportBookStatus: stolen → lostPassportBookNumber/ lostPassportBookIssueDate conditional group and the isMinorUnder16: false → applicantSignatureDate pair, while omitting the optional passport-card fields, alternate phone/email, and the minor-guardian signature path. A one-off Node script (node:fs + a hand-rolled per-field validator, not committed to the repo) confirmed every populated field satisfies its type and validation constraint and that no required field was left unset:

`` PASS — mock adult stolen-passport-book report (filed with a new DS-11 application) satisfies the schema field-level constraints. ``

Both registry validators were run against the schema document itself (not the mock data) and pass:

``` $ node tools/validate.mjs registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json ok registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json

$ cd tools && node validate-ajv.mjs ../registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json ok registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json [v0.2] ```

What is NOT yet independently verified

  • The "at least one of book/card must be lost or stolen" constraint. The form's checkbox layout implies at least one of passportBookStatus/ passportCardStatus must be lost or stolen, but v0.1/v0.2 has no cross-field "at least one of" constraint construct; this is stated as a description-level note on both fields rather than enforced. Likewise, otherLostPassportCount and otherLostPassportApproximateDates are gated on hasOtherLostOrStolenPassports only via field-description notes, a reasonable flattening of the form's own conditional layout, not independently re-verified field-by-field against a live-filled example.
  • The font-encoding artifacts on page 1. While the page 2 field labels this schema is built from extracted cleanly, a reviewer should re-fetch and re-extract the PDF (or try an alternative extraction tool) to confirm nothing on page 1 that could affect field semantics (rather than just prose/legal boilerplate) was garbled.
  • Constraint patterns (SSN, ZIP code, E.164 phone) are reasonable encodings, not citations of a published DOS validation rule.
  • The online and phone-reporting channels' exact data model were not directly observed (the online channel requires an active travel.state.gov session to reach past the login gate); this document is sourced from the paper/PDF Form DS-64, which the source page states is the same underlying report.

Correction — missing second "police report" field (GOV-321)

Independent review at GOV-309 (PR #40 review comment) found that the live Form DS-64 PDF has two distinct AcroForm checkbox fields, both labeled "Did you file a police report? (If yes, and the report is available, please submit a copy.)":

  1. "lable please submit a copy" (Yes_2/No_2) — under the loss/theft-date question. Captured in this schema as policeReportFiled.
  2. "Did you file a police report If yes and the report is available please submit a copy" (Yes_4/No_4) — positioned under the "Have you had any other valid U.S. passport book/card lost or stolen? ... Approximate date(s)?" question. Confirmed via pdfjs-dist getAnnotations() to be a separate field (distinct field name and rect, ~65pt below the first hasOtherLostOrStolenPassports/otherLostPassportCount/ otherLostPassportApproximateDates group, not a duplicate widget of field 1), and corroborated by a rendered Playwright screenshot of page 2 showing two separate "Did you file a police report?" rows each with its own Yes/No checkboxes.

This second field was missing from the original transcription. It has been added as otherLostPassportPoliceReportFiled (boolean, optional, required when hasOtherLostOrStolenPassports is true — the same conditional pattern as its sibling fields otherLostPassportCount/otherLostPassportApproximateDates), appended to the loss_details step's field list. No other fields were found missing in this pass. Both registry validators were re-run after the addition and pass (see below).

``` $ node tools/validate.mjs registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json ok registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json

$ cd tools && node validate-ajv.mjs ../registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json ok registry/us/dos/lost-or-stolen-passport-ds64/1.0.0/schema.json [v0.2] ```

Since this v1.0.0 document has not yet merged to main (still under review on open PR #40), it has not been "published" in the VERSIONING.md §3 sense — immutability protects a version directory once merged, not a document still being reviewed on its originating PR. This correction is therefore made in place, rather than shipped as a new version, the same as any other pre-merge review fix-up. status remains draft pending the remainder of the independent field-by-field review.

Path to a verified claim (next step)

To advance this document to status: verified, a reviewer applies manual-source-review-v1 (Procedure step 2 field-by-field comparison, step 3 flow comparison) against the live Form DS-64 PDF, ideally with an observed run of the online reporting flow, confirms the sources are still authoritative, resolves any discrepancy by shipping a new schema version (immutability — VERSIONING §3, practice Procedure step 5), and records the outcome here plus sets status: verified with a current verification.lastVerifiedAt / nextReviewBy. This v1.0.0 record stays as the authoring provenance.

Re-verification

Per the practice's Cadence, nextReviewBy is set to 2027-01-01 (6 months). Re-check the source on or before that date, on any source.url change, or when the U.S. Department of State publishes a new Form DS-64 revision.

View the raw record (VERIFICATION.md)

Version history

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by U.S. Department of State, Bureau of Consular Affairs or any government. The authoritative source is always the live government form and its official instructions.