Switzerland — Online Application for a Swiss Passport and/or Identity Card (fedpol Internetantrag)

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-09
• maturity.level: structural-reference

Why this cycle picked fedpol's online passport/ID-card application

This is the recurring "GovSchema Standard Research" cycle (GOV-1931). Switzerland previously had only 2 of 6 verticals modelled — DMV (ch/sg/stva/gesuch-lernfahr-fuehrerausweis, cantonal) and Taxes (ch/zh/sta/*, 11 companion schedules for Canton Zürich, a seam now fully mined per GOV-1924). Business Formation, Passport, Visa, and National ID were open. CH Visa was already a confirmed dead end (GOV-1774: SEM's own national D-visa and Schengen C-visa PDFs are field-for-field duplicates of the EU-harmonized de/auswaertiges-amt/national-visa-application template). CH Passport and National ID had only ever been screened at the level of "no downloadable citizen-facing PDF exists in the flow" (GOV-1840, re-confirmed GOV-1804/GOV-1774) — that finding is true (there genuinely is no PDF) but incomplete: it never rendered the live JavaScript single-page application (SPA) the process actually runs on, at ch-edoc-passantrag.admin.ch, linked from fedpol.admin.ch's own /en/application page. This cycle did.

fedpol (the Federal Office of Police, part of the Federal Department of Justice and Police) is Switzerland's federal authority for both the passport and the identity card (Identitätskarte) — both documents are issued through the same online application tool, asked through one shared field set (a document-type choice: passport / identity card / combi), not two separate flows. Per this registry's established pattern for a single source that forks into related paths rather than being split artificially (see e.g. ch/zh/sta/hilfsblatt-b), this cycle authors one schema modelling both verticals via a documentType discriminator field, rather than two schemas.

The tool turned out to be a real, non-trivial data-entry SPA — not a login-only shell — but one that structurally gates its own substantive personal-data screens behind a one-time link e-mailed to the applicant, which this cycle could not obtain (no real inbox). Rather than treating that gate as a hard dead end (which this cycle judged would have discarded a great deal of genuine, mechanically-sourced structure), the running application's own canonical i18n resource bundle was fetched directly and used — clearly and separately disclosed below from the directly-rendered portion — to model the full flow. See "Sources examined" and "Judgment calls" below for the complete, honest breakdown of what was directly observed vs. what was sourced from that resource.

This opens 2 of Switzerland's remaining 4 open verticals (Passport, National ID) via one schema. Business Formation (easygov.swiss) remains Switzerland's last fully open vertical, previously confirmed a pure CH-Login-gated dead end (GOV-1840) not re-attempted this cycle.

Sources examined

• Document (id, version): ch/fedpol/antrag-pass-identitaetskarte / 0.1.0
• Spec version: GovSchema 0.3.0
• Authority: Federal Office of Police (fedpol), Federal Department of Justice and Police (FDJP) — a federal, not cantonal, authority (contrast every prior CH schema in the registry, all cantonal).
• Entry point: https://www.fedpol.admin.ch/en/application, fetched directly this cycle, which links to the live application tool.
• Primary source (live application): https://www.ch-edoc-passantrag.admin.ch/antrag/antrag_start.action?request_locale=en — an Angular single-page application. Its own /rest/appinfo/infos endpoint (fetched directly this cycle, HTTP 200) reports {"appVersion":"3.19.11", ..., "appName":"antrag-service"}. First direct static fetch attempts (curl, WebFetch) returned a WAF block page ("Web Page Blocked! ... Attack ID: 20000051") on some requests but a normal 200 with full HTML on others from the same IP within the same session — intermittent, not a hard block; a headless-Chromium session with a realistic desktop User-Agent string rendered the application cleanly and consistently every subsequent attempt this cycle.
• Live rendering method: Playwright driving headless Chromium (via playwright-core + the /paperclip/chrome-sysroot shared libraries, per this registry's own documented technique for this environment), navigating and interacting with real DOM elements (radio buttons, an autocomplete combobox, a mat-select dropdown, text inputs), never a fixed sleep — each step waited on networkidle plus a settle delay, and every step was screenshotted (saved under /tmp/shotter/, not in this repo, per this registry's screenshot-storage convention).
  • Step 1 (Domicile) — directly rendered, DOM-verified. The page (#/antraggesuch) opened in German by default despite the request_locale=en query parameter (a source quirk, disclosed, not a modelling concern); clicking the on-page EN language link (careful to match link text that starts with "EN", since a naive substring match on "en" false-positived on the French link's own text, "Cette page en français") switched the whole UI to English. Clicking "Order documents" (#bestellenBtn) opened a mat-radio-group titled "Select your place of residence.", with two mat-radio-buttons labelled "Switzerland" and "Abroad" (native radio inputs mat-radio-0-input/ mat-radio-1-input, clicked via their visible <label>, since MDC's native radio input itself is visually hidden by CSS). Selecting "Switzerland" immediately revealed a required #cantonInput autocomplete (aria-required="true", title="Select your canton of domicile."); opening it listed exactly 26 mat-options (Aargau AG, Appenzell Inner-/Outer-Rhodes AI/AR, Basle-City/-Country BS/BL, Bern BE, Fribourg FR, Geneva GE, Glarus GL, Grisons GR, Jura JU, Lucerne LU, Neuchâtel NE, Nidwalden NW, Obwalden OW, Schaffhausen SH, Schwyz SZ, Solothurn SO, St Gall SG, Thurgovia TG, Ticino TI, Uri UR, Valais VS, Vaud VD, Zug ZG, Zurich ZH), independently cross-checked against the application's own live reference-data endpoint, https://www.ch-edoc-passantrag.admin.ch/rest/stammdaten/kanton?lang=en (fetched directly this cycle, HTTP 200), which returns exactly 26 records with kuerzel abbreviations AG,AI,AR,BE,BL,BS,FR,GE,GL,GR,JU,LU,NE,NW, OW,SG,SH,SO,SZ,TG,TI,UR,VD,VS,ZG,ZH — an exact match, confirming the canton field's enum. Selecting "Abroad" instead advanced straight to the Applicant-contact card below with no separate country/ registration-centre selector on this immediate screen (checked directly by re-running the flow with "Abroad" selected) — the "Registration centre" concept the i18n resource separately names (internet.auslandch.passnureau) is not shown at this point in the live flow; this cycle could not confirm exactly which later screen renders it (modelled here as responsibleRepresentation, per the i18n resource's own step-6 naming — see "Judgment calls" below).
  • Step 2 (Applicant-contact card) — directly rendered, DOM-verified. Clicking "Next" revealed a form headed "Applicant:" with a required mat-select[formcontrolname=anrede] (aria-required="true", title="Select title."; opening it listed exactly two options, "Mr" and "Ms"), a required surname text input (#mat-input-0 [formcontrolname=name], aria-required="true", maxlength="50"), a required firstNames text input (#vorname[formcontrolname=vorname], same attributes), and a required email input entered twice (#email/#emailrepeat, both aria-required="true" maxlength="50"). Two additional hidden form-control names were found in the DOM at this step but are not modelled as schema fields: formcontrolname="HName" — confirmed to be an anti-bot honeypot field, not a real applicant attribute, by the i18n resource's own dedicated message, validate.hname.maxLength: "Input too long. Are you possibly a bot?" — and formcontrolname="TS" — confirmed to be an anti-bot elapsed-time field by validate.ts.min: "Cannot be sent. Please restart the application."; filling and submitting the form via scripted page.fill() calls (near-instant) reproducibly crashed the SPA's own client-side error renderer (TypeError: Cannot read properties of undefined (reading 'text') inside its getErrorMessage/validateFormular code, confirmed via the browser console), consistent with the timing field failing its minimum-elapsed-time check; resubmitting with human-paced page.type() keystrokes and multi-second waits between steps (no bug, no crash) advanced cleanly straight to the Confirmation screen, which read: "A message has been sent to your e-mail address placeholder.test@example.com . Open the message by clicking the subject heading "Ordering identity documents". To proceed with your order, click the link in this message." — mechanically confirming that everything past this point in the flow is gated behind a real e-mailed link, which this cycle, having used a fabricated placeholder address (placeholder.test@example.com, deliberately not a real deliverable inbox, per this registry's no-real-data rule), could not obtain. No CAPTCHA was actually rendered for this particular attempt, despite the i18n resource carrying CAPTCHA-related strings (internet.captcha, validate.captcha) — this cycle cannot rule out a CAPTCHA appearing under different conditions (e.g. rate-limiting) since it was not observed to trigger for a single clean attempt.
  • All of the above is reproducible from this cycle's own saved screenshots (not committed to this repository; a fresh independent re-run of the same live URL, described above, reproduces the same DOM structure and behaviour).
• Secondary source (the application's own i18n resource) — used for every field beyond the e-mail gate, clearly disclosed per-field in schema.json via each field's sourceRef. https://www.ch-edoc-passantrag.admin.ch/rest/i18n/translations/en, fetched directly this cycle (HTTP 200, 443 top-level keys, Content-Type: application/json). This is not a static document the reviewer merely read about — it is the exact REST resource the running Angular application itself downloads on page load (confirmed via the browser's own network log during the Step 1/2 rendering above, which shows the SPA fetching /rest/i18n/translations/de on first (German) load) to render every label, tooltip, and field-specific validation-error message in every step of the wizard, keyed by strings such as internet.schritt2.geburtsdatum ("Date of birth:") and validate.nogeburtsdatum ("Enter a valid date (dd.mm.yyyy or 00.mm.yyyy or 00.00.yyyy).") — i.e. the resource discloses not just field labels but the exact client-side validation-error text tied to each field, which is how this cycle inferred requiredness for fields it could not directly render (see "Requiredness inference" below). Every translation key cited in schema.json's field descriptions and below was independently re-grepped against a fresh re-fetch of this same endpoint immediately before this cycle's sourcing re-verification pass (see the PR checklist / verify-sources.mjs run); none were paraphrased from memory. The resource's own step-grouping key namespace (internet.schritt1.* through internet.schritt8.*/schritt10.*) is what this schema's steps[] array's ordering and titles are derived from — schritt1 = "Identity document type & language type" through schritt7 = "Contact details", with schritt8's own sub-keys (schritt8.schritt1 through schritt8.schritt6) re-using the same headings to label a review/summary screen rather than describing an additional distinct data-entry step, and schritt10.title = "Summary of the application" naming the final screen this schema calls summary.

Requiredness inference for i18n-resource-sourced fields (disclosed limitation)

For every field in the documentTypeAndLanguage step onward, required/ requiredWhen was set to true only where the i18n resource carries a dedicated "this field is empty" validation-message key for it (e.g. validate.nogeburtsdatum, validate.nogeschlecht, validate.noantragsgrund, validate.nolieferoption, validate.noimmatrikulation, validate.noland.lieferadresse) — a strong, but indirect, signal: the existence of a dedicated blank-field error message means the live validateFormular code path checks for that field's presence, which is only meaningful if the field can be left blank and rejected, i.e. it is enforced as required in at least some reachable form state. This is not the same evidentiary strength as a directly observed required/aria-required DOM attribute (which this cycle has, and cites, for every field in domicile and applicantContact) or a submitted-and-rejected empty-field screenshot. Fields with no such dedicated message (e.g. hyphenatedSurname, currentPassportNumber, currentIdCardNumber, the address-line-2 fields, remarks, the phone-number fields) are modelled as optional. This distinction is called out again, field-by-field, in each affected field's sourceRef in schema.json ("sourced from the application's own i18n resource; not independently DOM-rendered this cycle").

Judgment calls

1. Single schema with a documentType discriminator, not two schemas. fedpol's own tool asks "Do you need a passport, an ID card, or both (combi)?" through one shared field set and one continuous flow, not two separate application processes — the same modelling choice this registry made for ch/zh/sta/hilfsblatt-b. See the top-level description for the full reasoning.
2. The domestic ID-card-only online-ordering restriction is disclosed in prose, not enforced as a hard validation rule. The i18n resource states: "You are presently only able to apply for a passport or combination offer (passport and identity card) via internet in your canton of residence. Kindly contact your municipality of residence if you only wish to apply for an identity card." (internet.schritt1.intro.pass). Because the source itself frames this as a current operational state ("presently"), not a permanent structural rule, and because this cycle could not directly observe whether it is enforced as a hard client-side validation or is merely descriptive guidance, documentType's enum is not narrowed conditionally on domicile; the restriction is disclosed in the field's own description instead.
3. The ID-card "with/without data chip" wording variant (internet.schritt1.intro.chip.true/.false) is not modelled as a separate field. This cycle could not confirm whether it is a user-selectable option or a system-determined attribute (e.g. tied to a chip-rollout date or the applicant's canton); disclosed in documentType's description rather than guessed at.
4. reasonForApplication's enum is simplified to the plain citizen-facing reason set, excluding the i18n resource's own additional document-specific (identity-card A/B/C codes), consular/EDA-specific, and internal data-entry-correction reason codes — a disclosed scope decision (see the field's own description), since fully replicating every internal code combination without ever rendering that screen risks overclaiming precision this cycle does not have.
5. custodyType/parents/guardian fields are all optional, not gated to minor applicants structurally, since this cycle could not confirm the live trigger condition (most likely an age threshold, but unconfirmed) — disclosed in custodyType's own description.
6. emailRepeat (the live form's duplicate-entry e-mail confirmation field) is not modelled as a separate schema field — it carries no distinct data value beyond email itself; this mirrors how this registry generally treats UI-only double-entry confirmation controls.
7. responsibleRepresentation/responsibleRepresentationCountry are placed at the step the i18n resource's own step numbering (internet.schritt6.title) implies, even though this cycle's direct rendering of the Domicile step's "Abroad" branch did not surface a registration-centre selector at that point — disclosed directly in the field's own description, not silently reconciled.
8. dateOfBirth and height use string/pattern rather than date/number, to preserve the source's own documented non-standard allowances (partial dates with 00 placeholders for an unknown day/month; the literal *** sentinel for children under 14 or wheelchair-dependent applicants) rather than forcing a strict calendar date or a bare numeric height that would reject those source-documented valid inputs.

Field-by-field source mapping

• Domicile step → domicile, canton — DOM-verified (see "Sources examined").
• Applicant-contact card → title, surname, firstNames, email — DOM-verified.
• Identity document type & language (i18n schritt1) → documentType, printedLanguage.
• Personal data (i18n schritt2) → hyphenatedSurname, dateOfBirth, placeOfBirthAbroad, placeOfBirth, sex, height, placeOfOrigin, currentPassportNumber, currentIdCardNumber, reasonForApplication. (surname/firstNames are collected once, on the Applicant-contact card, and reused here per the i18n resource's identical internet.schritt2.name/ .vorname labels — not duplicated as separate fields.)
• Further personal data / parents & legal guardian (i18n schritt3) → custodyType, motherSurname, motherFirstNames, fatherSurname, fatherFirstNames, guardianSurname, guardianFirstNames.
• Residential address (i18n schritt4) → residentialStreetAndNumber, residentialAddressLine1, residentialAddressLine2, residentialPostalCode, residentialCity.
• Delivery address (i18n schritt5) → deliveryOption, deliveryAddressLine1, deliveryAddressLine2, deliveryPostalCode, deliveryCity, deliveryCountry.
• Responsible representation, abroad only (i18n schritt6) → responsibleRepresentationCountry, responsibleRepresentation.
• Contact details & remarks (i18n schritt7) → privatePhone, mobilePhone, workPhone, remarks.
• Summary/Confirmation (i18n schritt8/schritt10) → not a distinct data-collection step; modelled as the terminal summary step with no fields of its own, per its own live-observed behaviour (Step 3 of the top-level tracker, "Confirmation").

What is NOT modelled

• The biometric-capture in-person appointment (photograph, signature, fingerprints for a passport) that follows a verified online application — explicitly out of scope, per fedpol's own process description and this registry's established treatment of "the online step is what this registry models" for similar processes elsewhere.
• Payment/fee handling — the i18n resource references fee amounts (antrag.antragtyp.template) but this cycle found no payment step reachable online (fees are described elsewhere as collected at the in-person biometric appointment).
• Any document upload — none exists in this flow (contrast, e.g., a photo-upload step); the one imageupload.* key cluster in the i18n resource describes a different, separately-login-gated photo-upload tool (its own strings are literally untranslated placeholders, "EN: Bild hochladen" etc., and require a password e-mailed separately per imageupload.tooltip.login), which this cycle did not attempt to reach and does not model.
• The exact conditional trigger for the parents/legal-guardian section (age-based, most likely, but unconfirmed) — see "Judgment calls" #5.

Mock-data test run

One complete, realistic application-packet fixture was constructed at conformance/ch/fedpol/antrag-pass-identitaetskarte/0.1.0/application-packet.json per this registry's established conformance-fixture convention (GSP-0016): an adult woman domiciled in Winterthur, Canton Zürich, ordering a Combi (passport + identity card) to replace her expiring documents, delivered to her own residential address. Fabricated details, not a real person.

An ad hoc Node script (not committed to tools/, consistent with this registry's established practice for a one-off conformance check) re-derived every field's effective requiredness from schema.json's own required/requiredWhen conditions and re-checked the packet, plus five additional hand-written variants, against every validation.enum/pattern/ maxLength rule:

1. The committed packet itself (domicile: "switzerland", adult, combi) — no violations.
2. A positive control with domicile: "abroad", deliveryOption: "otherAddressAbroad", and every field requiredWhen-gated on those two choices supplied (responsibleRepresentation, responsibleRepresentationCountry, deliveryAddressLine1, deliveryPostalCode, deliveryCity, deliveryCountry) — no violations.
3. A positive control with custodyType: "both" and both parents' names supplied — no violations.
4. A negative control: domicile: "switzerland" with canton omitted — correctly rejected (MISSING required field: canton).
5. A negative control: domicile: "abroad" with responsibleRepresentation/responsibleRepresentationCountry omitted — correctly rejected (both flagged missing).
6. A negative control: deliveryOption: "otherAddressAbroad" with deliveryCountry omitted — correctly rejected.
7. A negative control: documentType: "diplomaticPassport" (not a member of the schema's enum) — correctly rejected.

All seven checks behaved as expected. Both registry validators were also run directly against schema.json:

``` $ node tools/validate.mjs registry/ch/fedpol/antrag-pass-identitaetskarte/0.1.0/schema.json ok registry/ch/fedpol/antrag-pass-identitaetskarte/0.1.0/schema.json 1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/ch/fedpol/antrag-pass-identitaetskarte/0.1.0/schema.json ok registry/ch/fedpol/antrag-pass-identitaetskarte/0.1.0/schema.json [v0.3] 1/1 document(s) validated against the meta-schema (ajv 2020-12). ```