Registry entry

Denmark Application for Danish Passport

Apply for a first Danish passport, a renewal, a provisional (emergency) passport, an extension, or an extra (simultaneously valid second) passport, under the authority of the Ministry of Foreign Affairs of Denmark (Udenrigsministeriet, UM). The form collects the applicant's core identity data (including the 10-digit Civil Registration/CPR number), nationality history, current residential address and contact details, current-passport status (including a lost-passport/police-report path), and — where the applicant is under 18 — a parallel two-column Section D in which up to two parents/legal guardians each independently declare custody status, nationality-acquisition history, kinship to the child, and their own consent, each under penalty of Section 163 of the Danish Criminal Code. Submission is in person together with supporting documentation (the form itself states: 'You are required to submit your application form in person, regardless of age, together with supporting documentation'); this document models the form's own data fields, not an online submission channel. It does not model fee amounts (not published on this form), photo specifications (referred to the relevant Embassy's own homepage), or document legalisation/translation requirements for non-Danish/non-English supporting documents — see VERIFICATION.md.

You are viewing v1.0.0

The latest published version of this schema is v1.1.0. See the current reference page. Published versions are immutable; this page stays for agents pinned to dk/um/application-for-danish-passport@1.0.0.

Registry entry

dk/um/application-for-danish-passport

Jurisdiction
Denmark · national
Version
1.0.0
Verification
draft

Authoritative source Application for Danish passport (edition 03/2026, no separate form number printed on the document itself)

Machine access

Registry catalog
registry/index.jsonone record per schema id

Field reference

58 fields, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Fields

  • firstPassportRequested boolean optional

    One of five independent, non-grouped PDF checkboxes (confirmed via getFieldObjects(): 5 distinct field names, no shared group, radioButton:false) describing the reason the application is being filed; see exclusivityGroups and VERIFICATION.md.

  • renewalRequested boolean optional

    Renewal

  • provisionalRequested boolean optional

    A provisional (emergency/temporary) passport.

  • extensionRequested boolean optional

    Extension

  • extraPassportRequested boolean optional

    A second, simultaneously valid passport, distinct from a first/replacement passport.

  • applicantSurname string required

    Surname

    length: 1–100classification: pii
  • applicantGivenAndMiddleNames string required

    Given and middle names

    length: 1–100classification: pii
  • applicantCivilRegistrationNumber string required

    The applicant's 10-digit Danish CPR (personnummer). On the source PDF this is split across ten separate single-digit AcroForm text widgets ('pasansoeger personnr 1_2' through '1_11'), merged here into one field per this registry's established split-digit-box convention; see VERIFICATION.md.

    patternclassification: sensitive-pii
  • applicantBirthPlaceTownParishMunicipality string required

    Place of registration of birth — town, parish or municipality

    length: 1–100
  • applicantBirthCountry string required

    Place of registration of birth — country

    length: 1–100
  • applicantIsMale boolean optional

    One of two independent, non-grouped PDF checkboxes for sex (radioButton:false); see exclusivityGroups.

  • applicantIsFemale boolean optional

    Sex: Female (F)

  • applicantHoldsDanishNationality boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false) answering the same yes/no question; see exclusivityGroups.

  • applicantDoesNotHoldDanishNationality boolean optional

    Does the applicant hold Danish nationality? — No

  • applicantIsOrWasNationalOfAnotherCountry boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false) answering the same yes/no question; see exclusivityGroups.

  • applicantIsNotAndWasNeverNationalOfAnotherCountry boolean optional

    Has the applicant been, or is now, a national of another country? — No

  • applicantOtherNationalityCountry string optional

    Country of the other nationality

    length: 1–100
  • applicantOtherNationalityDate date optional

    YYYY-MM-DD.

  • applicantPreviouslyHeldDanishPassport boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false) answering the same yes/no question; see exclusivityGroups.

  • applicantNeverHeldDanishPassport boolean optional

    Has the applicant previously held a Danish passport? — No

  • applicantAddressStreetAndHouseNumber string required

    Current residential address — street and house number

    length: 1–200classification: pii
  • applicantAddressPostalCodeAndCity string required

    Postal code and town/city

    length: 1–100classification: pii
  • applicantAddressCountry string required

    Country of residence

    length: 1–100
  • applicantEmail string required

    E-mail

    length: 3–254classification: pii
  • applicantPhoneNumber string required

    Telephone number

    length: 1–30classification: pii
  • currentPassportNumber string optional

    Current passport number

    length: 1–50
  • currentPassportExpiringOrExpired boolean optional

    One of three independent, non-grouped PDF checkboxes (radioButton:false) for why a new passport is being requested; see exclusivityGroups.

  • currentPassportLost boolean optional

    If true, a declaration of lost passport together with a police report must be enclosed (see documents[]).

  • currentPassportOtherReason boolean optional

    Reason for new passport: other

  • currentPassportOtherReasonDetails string optional

    Other reason — details

    length: 1–300
  • applicantDateAndSignature string required

    A physical, ink date-and-signature block completed in person; see the form's own consent/attestation text (Section C) referencing Section 163 of the Danish Criminal Code and the Ministry's authorisation to verify the applicant's information with other Danish or foreign authorities. Not a hand-drawn/image signature field per this registry's file-type convention — modelled as the printed date-plus-signature line the applicant completes on paper, consistent with this registry's treatment of other in-person/print-and-sign passport forms.

    length: 1–100
  • applicantIsMinor boolean required

    Semantic field with no backing AcroForm widget on the source PDF, added purely to gate the requiredWhen visibility of Section D ('Declaration of consent'), whose own printed header reads 'This section shall be completed if the applicant is under 18 years of age.' The source form has no explicit age/minority checkbox of its own (a Danish CPR number encodes date of birth, so the form does not separately collect one) — disclosed here rather than silently invented as PDF-backed; see VERIFICATION.md.

  • firstParentHasSoleCustody boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false); relevant only when 'applicantIsMinor' is true (see exclusivityGroups); not itself requiredWhen-gated, consistent with this registry's convention of not forcing an answer onto an independent, non-grouped checkbox pair.

  • firstParentHasJointCustody boolean optional

    First parent/guardian holds joint legal custody of the child

  • firstParentSectionChildName string optional

    The first parent/guardian's own copy of the applying child's name, written in their own column of Section D. The applicant's name is a single fact entered independently in each consent-holder's own signature block on the source form (not a split encoding of one value like the Civil Registration number digit groups) — kept as a separate field from the mirrored field in the other consent-holder's column, per this registry's convention of not merging genuinely duplicate write-in boxes; see VERIFICATION.md.

    length: 1–200classification: pii
  • firstParentAcquiredOtherNationalityBefore2015 boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false) answering the same yes/no question; see exclusivityGroups.

  • firstParentDidNotAcquireOtherNationalityBefore2015 boolean optional

    Has this consent holder acquired nationality of another country before 1 September 2015? — No

  • firstParentOtherNationalityCountry string optional

    Country of the consent holder's other nationality

    length: 1–100
  • firstParentName string optional

    Name of parent/guardian (consent holder)

    length: 1–200classification: pii
  • firstParentCivilRegistrationNumber string optional

    The 10-digit Danish CPR (personnummer) of this consent holder. On the source PDF this is split across ten separate single-digit AcroForm text widgets ('foraelder personnummer 2_2..2_11' / '3_2..3_11'), merged here into one field per this registry's established split-digit-box convention; see VERIFICATION.md.

    patternclassification: sensitive-pii
  • firstParentKinshipBiological boolean optional

    One of three independent, non-grouped PDF checkboxes (radioButton:false); see exclusivityGroups.

  • firstParentKinshipAdoptive boolean optional

    How was kinship established? — Adoptive parent

  • firstParentKinshipOther boolean optional

    How was kinship established? — Other

  • firstParentKinshipOtherDetails string optional

    Kinship — other, please specify

    length: 1–200
  • firstParentDateAndSignature string optional

    A physical, ink date-and-signature block completed in person by this consent holder, given under penalty of Section 163 of the Danish Criminal Code.

    length: 1–100
  • secondParentHasSoleCustody boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false); relevant only when 'applicantIsMinor' is true (see exclusivityGroups); not itself requiredWhen-gated, consistent with this registry's convention of not forcing an answer onto an independent, non-grouped checkbox pair.

  • secondParentHasJointCustody boolean optional

    Second parent/guardian holds joint legal custody of the child

  • secondParentSectionChildName string optional

    The second parent/guardian's own copy of the applying child's name, written in their own column of Section D. The applicant's name is a single fact entered independently in each consent-holder's own signature block on the source form (not a split encoding of one value like the Civil Registration number digit groups) — kept as a separate field from the mirrored field in the other consent-holder's column, per this registry's convention of not merging genuinely duplicate write-in boxes; see VERIFICATION.md.

    length: 1–200classification: pii
  • secondParentAcquiredOtherNationalityBefore2015 boolean optional

    One of two independent, non-grouped PDF checkboxes (radioButton:false) answering the same yes/no question; see exclusivityGroups.

  • secondParentDidNotAcquireOtherNationalityBefore2015 boolean optional

    Has this consent holder acquired nationality of another country before 1 September 2015? — No

  • secondParentOtherNationalityCountry string optional

    Country of the consent holder's other nationality

    length: 1–100
  • secondParentName string optional

    Name of parent/guardian (consent holder)

    length: 1–200classification: pii
  • secondParentCivilRegistrationNumber string optional

    The 10-digit Danish CPR (personnummer) of this consent holder. On the source PDF this is split across ten separate single-digit AcroForm text widgets ('foraelder personnummer 2_2..2_11' / '3_2..3_11'), merged here into one field per this registry's established split-digit-box convention; see VERIFICATION.md.

    patternclassification: sensitive-pii
  • secondParentKinshipBiological boolean optional

    One of three independent, non-grouped PDF checkboxes (radioButton:false); see exclusivityGroups.

  • secondParentKinshipAdoptive boolean optional

    How was kinship established? — Adoptive parent

  • secondParentKinshipOther boolean optional

    How was kinship established? — Other

  • secondParentKinshipOtherDetails string optional

    Kinship — other, please specify

    length: 1–200
  • secondParentDateAndSignature string optional

    A physical, ink date-and-signature block completed in person by this consent holder, given under penalty of Section 163 of the Danish Criminal Code.

    length: 1–100

Verification record

Candidate selection

This session's brief (GOV-2244), delegated from the GOV-2242 "GovSchema Standard Research" cycle, was to author Denmark as GovSchema's 33rd jurisdiction, opening with its Passport vertical (1/6). GOV-2242 had scouted three new-jurisdiction candidates in parallel (Norway, Denmark, Belgium) and found Denmark the strongest: genuine, fresh, unauthenticated AcroForm PDFs across three verticals, with Passport judged the strongest single source to open with. This session re-verified that scouting from scratch — a fresh fetch, a fresh pdfjs-dist extraction independent of the scouting agent's own numbers, and a fresh field-by-field design pass — rather than assuming the prior cycle's figures still held.

Source

  • Primary: https://um.dk/media/vd0fpauc/application_for-danish_passport_2026_03_web.pdf — the Ministry of Foreign Affairs of Denmark's (Udenrigsministeriet, UM) "Application for Danish passport" form, edition dated 03/2026 (printed at the foot of both pages: (03/2026)). Fetched with a plain HTTP GET using a realistic browser User-Agent: HTTP 200, content-type: application/pdf, exactly 122,515 bytes (SHA-256 87b7049de89a69cda5e512c91c8e74e038d6e217f5b93b81b8c0dffae48c8ac5), a genuine fillable AcroForm PDF, 2 pages. No login, CAPTCHA, or WAF gate of any kind — a direct, unauthenticated download from the Ministry's own um.dk media library.
  • No separate form-number is printed anywhere on the document; it is referred to here by its own printed title, "Application for Danish passport."

The PDF was re-fetched a second time at the end of this session (see "Pre-PR re-verification" below); the byte length and SHA-256 were identical both times.

Extraction technique

The PDF's AcroForm layer was extracted with pdfjs-dist v3.11.174 (legacy/build/pdf.js, loaded via createRequire, per this registry's documented Node-environment requirement), calling page.getAnnotations({ intent: "display" }) on each page to enumerate every Widget annotation, doc.getFieldObjects() to group widgets by their true, distinct PDF field name, and page.getTextContent() (with each item's transform[4]/transform[5] x/y coordinates preserved) to reconstruct the surrounding printed prose and labels by position, in the same style used by this registry's at/bmeia/is/* cycles.

  • 86 total AcroForm widgets — 42 on page 1, 44 on page 2.
  • getFieldObjects() returns 86 distinct field-name keys — i.e. no two widgets in this document share a field name anywhere. Every Btn (checkbox) widget's own radioButton flag is false (checked across all 30 Btn widgets programmatically, not eyeballed). This document contains zero genuine PDF radio-button groups.
  • Zero widgets carry a shared field name across the split Civil-Registration-number (CPR/personnummer) digit boxes — each of the 30 digit-box widgets (3 groups of 10, see "Split-digit merges" below) is its own distinct field name (pasansoeger personnr 1_2 .. 1_11, foraelder personnummer 2_2 .. 2_11, foraelder personnummer 3_2 .. 3_11), consistent with the split-box pattern already documented for other jurisdictions in this registry (e.g. Iceland's kennitala/kerfiskennitala forms).

Widget-to-field accounting (86 → 58, fully disclosed)

| Category | Widgets | Fields | Net | |---|---:|---:|---:| | Excluded (official-use-only) | 2 | 0 | −2 | | Split-digit CPR merges (3 groups × 10) | 30 | 3 | −27 | | All other widgets (1:1) | 54 | 54 | 0 | | Synthesized (no backing widget) | 0 | 1 | +1 | | Total | 86 | 58 | |

54 + 3 + 1 = 58, matching schema.json's own fields.length (checked mechanically: python3 -c "import json; print(len(json.load(open('schema.json'))['fields']))"58).

Excluded widgets (2)

Both are printed under the form's own header "For official use only" (top-right of page 1) and are explicitly the issuing authority's own fields, not applicant data:

  • modtaget dato 2 ("Date received")
  • hoejde 2 ("Height in cm")

Consistent with this registry's convention (see e.g. at/bmeia, de/bmi) of not modelling fields the source document itself marks as staff-only/office-computed.

Split-digit merges (3 groups, 30 widgets → 3 fields)

Each of the applicant and up to two parents/guardians has their 10-digit Danish CPR number (personnummer) split across ten separate single-digit text widgets on the source PDF, confirmed via each widget's own /TU alternate text (e.g. "Insert first digit of applicant's Civil registration number" through "...tenth digit..."). Per this registry's established split-digit/split-component box convention, each group of 10 merges into one field with a ^[0-9]{10}$ pattern:

  • pasansoeger personnr 1_2 .. 1_11applicantCivilRegistrationNumber
  • foraelder personnummer 2_2 .. 2_11firstParentCivilRegistrationNumber
  • foraelder personnummer 3_2 .. 3_11secondParentCivilRegistrationNumber
Duplicate-value fields kept unmerged (disclosed, not a merge)

Section D's two parallel parent/guardian columns each carry their own Tx widget asking for the applying child's name (barn foraelder 2 / barn foraelder 3, both with the identical /TU alternate text "Insert name of child who is applying for a passport"). Unlike the CPR digit groups — which jointly encode ten fragments of one number — these two widgets are literal, independent duplicate write-in boxes, each on a different consent-holder's own signature block on the physical form, not a split encoding of a single value. They are modelled as two distinct fields, firstParentSectionChildName and secondParentSectionChildName, per this registry's convention of not merging genuinely duplicate write-in boxes purely because they happen to ask for the same underlying fact; see the corresponding field descriptions in schema.json.

Synthesized field (1, no backing widget)

Section D's own printed header reads: "D: Declaration of consent (This section shall be completed if the applicant is under 18 years of age)." The source form has no explicit age/minority checkbox anywhere (a Danish CPR number itself encodes date of birth, which likely explains why the form does not separately collect a date-of-birth field at all — there is none on this document). Without a real field to gate Section D's own requiredWhen visibility, a semantic-only field applicantIsMinor (type: boolean, required: true, no sourceRef widget) was added, disclosed here as not backed by any AcroForm widget — the same class of judgment call already used by this registry's is/thjodskra/passport-issuance-consent-minor (GOV-2226) cycle.

Non-grouped checkbox modelling (12 exclusivityGroups)

Every multi-option selector in this document is a set of independent, non-grouped PDF checkboxes (confirmed via getFieldObjects()/radioButton as above), modelled as independent optional boolean fields with a disclosed exclusivityGroups entry where real-world mutual exclusivity is evident — the same convention already established by us/uscis/employment-authorization-i765 and generalized across this registry's at/bmeia cycle:

| Group | Fields | |---|---| | application_type | firstPassportRequested, renewalRequested, provisionalRequested, extensionRequested, extraPassportRequested | | applicant_sex | applicantIsMale, applicantIsFemale | | danish_nationality_status | applicantHoldsDanishNationality, applicantDoesNotHoldDanishNationality | | other_nationality_status | applicantIsOrWasNationalOfAnotherCountry, applicantIsNotAndWasNeverNationalOfAnotherCountry | | previous_danish_passport_status | applicantPreviouslyHeldDanishPassport, applicantNeverHeldDanishPassport | | current_passport_reason | currentPassportExpiringOrExpired, currentPassportLost, currentPassportOtherReason | | first_parent_custody_type | firstParentHasSoleCustody, firstParentHasJointCustody | | first_parent_other_nationality_status | firstParentAcquiredOtherNationalityBefore2015, firstParentDidNotAcquireOtherNationalityBefore2015 | | first_parent_kinship_basis | firstParentKinshipBiological, firstParentKinshipAdoptive, firstParentKinshipOther | | second_parent_custody_type | secondParentHasSoleCustody, secondParentHasJointCustody | | second_parent_other_nationality_status | secondParentAcquiredOtherNationalityBefore2015, secondParentDidNotAcquireOtherNationalityBefore2015 | | second_parent_kinship_basis | secondParentKinshipBiological, secondParentKinshipAdoptive, secondParentKinshipOther |

Per this registry's established practice (see at/bmeia VERIFICATION.md), none of the individual boolean options within these groups carry their own requiredWhen — only the genuine conditional detail fields do (e.g. applicantOtherNationalityCountry gated on applicantIsOrWasNationalOfAnotherCountry, currentPassportOtherReasonDetails gated on currentPassportOtherReason, firstParentOtherNationalityCountry gated on firstParentAcquiredOtherNationalityBefore2015, firstParentKinshipOtherDetails gated on firstParentKinshipOther, and their secondParent mirrors). An earlier draft of this schema mistakenly applied requiredWhen: { field: "applicantIsMinor", equals: true } to every Section D boolean option (custody, nationality-acquisition, kinship-basis) — this was caught by this session's own mock conformance test run (see below), which showed the minor scenario failing with 8 spurious missing-required errors on fields that are optional non-grouped checkboxes, not mandatory answers. The requiredWhen gate on applicantIsMinor was corrected to apply only to the genuine always-collected string fields per consent holder (child's name, name, Civil Registration number, date-and-signature) — not to the checkbox options themselves — after which both scenarios passed with 0 errors.

documents[] (1 entry)

  • lostPassportPoliceReportrequiredWhen: currentPassportLost == true, sourced from the form's own parenthetical: "Lost (a declaration of lost passport together with a police report must be enclosed)".

Verbatim-quote cross-check

Every phrase this record or schema.json places in single quotation marks was checked against this session's own pdfjs-dist getTextContent() dump of both pages (item strings preserved with x/y position, via a disposable script at /tmp/gov2244/text.js, not committed) — every quoted label, section heading, and instruction (including the Section C attestation text referencing "Section 163 of the Danish Criminal Code" and the Section D consent/custody sentences) matched the extracted text layer exactly, with no line-wrap or font-artifact discrepancies found.

Mock conformance test run

Two scenarios were built under conformance/dk/um/application-for-danish-passport/1.0.0/ and checked against this schema's own required/requiredWhen/validation/ documents[]/exclusivityGroups grammar with a disposable checker script (/tmp/gov2244/check_conformance.mjs, not committed — same technique used across this registry's other v1.0.0 cycles, extended here with explicit exclusivityGroups enforcement):

  • application-packet-adult-renewal.json: an adult applicant renewing an existing Danish passport, a Danish national with no other nationality and no lost/stolen history. 20 fields collected, 38 correctly not-applicable, 0 errors; currentPassportNumber correctly required (previously held a passport); all Section D fields correctly not required (applicantIsMinor: false).
  • application-packet-minor-both-parents-consent.json: a first passport for a minor applicant, filed with both parents completing Section D — the first parent has sole custody, is the biological parent, and did not acquire another nationality before 1 September 2015; the second parent has joint custody, did acquire another nationality before that date (triggering the conditional country field), and establishes kinship on an "other" basis (triggering the conditional details field). 34 fields collected, 24 correctly not-applicable, 0 errors.
  • Eight mutation/negative controls, each derived from a base scenario with exactly one defect introduced, run through the same checker script and each correctly raised at least one error:
    1. Removing the required applicantSurnamemissing-required.
    2. Setting both applicantIsMale and applicantIsFemale to trueexclusivity-violation on the applicant_sex group.
    3. Setting applicantCivilRegistrationNumber to "12345" (violates pattern: ^[0-9]{10}$) → pattern-violation.
    4. Removing currentPassportNumber from the renewal scenario (where applicantPreviouslyHeldDanishPassport: true) → missing-required, confirming that requiredWhen gate fires.
    5. Setting currentPassportLost: true on the renewal scenario (which already has currentPassportExpiringOrExpired: true) → 2 errors: an exclusivity-violation on current_passport_reason and a missing-required-document on lostPassportPoliceReport, confirming both mechanisms fire independently and correctly on the same packet.
    6. Removing secondParentKinshipOtherDetails from the minor scenario (while secondParentKinshipOther: true remains) → missing-required, confirming that nested conditional gate fires.
    7. Setting applicantIsMinor: true on the adult-renewal scenario without filling any Section D fields → 8 missing-required errors (the four always-collected string fields per consent-holder column: child's name, name, Civil Registration number, date-and-signature), confirming the corrected applicantIsMinor gate (see "Non-grouped checkbox modelling" above) fires for exactly the intended fields — no more, no fewer.
    8. Removing applicantDateAndSignature from the minor scenario → missing-required.

The schema was also validated against the GovSchema v0.3 meta-schema with node tools/validate.mjs and node tools/validate-ajv.mjs (both pass, run from the repository root against this document specifically and against the full registry — 343/343 documents pass after this addition).

Pre-PR re-verification

Immediately before finalizing this record, the primary PDF was re-fetched live a second time in this same session: HTTP 200, application/pdf, 122,515 bytes, SHA-256-identical to the first fetch (87b7049de89a69cda5e512c91c8e74e038d6e217f5b93b81b8c0dffae48c8ac5).

Path to a verified claim (next step)

To advance from status: draft to status: verified, a future reviewer would: confirm with a Danish mission or um.dk's own citizen-facing guidance which supporting documents (photo, prior passport, birth certificate, etc.) this form's own instructions require per applicant scenario, since this form itself is silent on that beyond the lost passport / police report note modelled here; and check whether a Danish-language-only companion guidance page changes any of the conditional-document requirements disclosed above.

Scope and jurisdiction notes

Opens Denmark as GovSchema's 33rd jurisdiction, with its Passport vertical (1/6). DMV and Taxes were flagged by the GOV-2242 scouting cycle as genuine, fresh, unauthenticated AcroForm-PDF candidates for future cycles; Business Formation, Visa, and National ID remain unscreened backlog candidates for a future cycle.

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 Udenrigsministeriet (Ministry of Foreign Affairs of Denmark) or any government. The authoritative source is always the live government form and its official instructions.