Registry entry

North Macedonia — Passport Application (Type A)

The Министерство за внатрешни работи's (МВР, Ministry of Internal Affairs) "Барање за издавање пасош" (Application for issuance of a passport), Тип-А (Type A) — Прилог бр. 7 (Annex No. 7) of the ministry's civil-procedures (гражданско постапки) forms page, a print-and-lodge specimen with no fillable AcroForm widgets. Models the applicant's selected reason for the application (first issuance, regular replacement, personal-data change, other-reason replacement, duplicate lost/missing/stolen, premature replacement for damage, or limited-validity issuance), three independent minority-language processing-preference requests (Turkish, Vlach, Serbian, Roma, or Bosnian, for the resulting document, the personal-name data, or the form's data generally), the applicant's identity and family data, an optional two-row parent/guardian consent block for a minor applicant, the applicant's prior passport data, the requested processing tier (regular or urgent), submission and contact data, and the form's own attachment checklist and personal-data-use consent as `documents[]` entries. A near-identical Type B (Прилог бр. 8) variant of this same form also exists, printed bilingually in Macedonian and Albanian for applicants requesting the Albanian-language processing pathway (adding a national/ethnic-affiliation field and dropping the Type A minority-language checkbox section in favor of direct bilingual labels) — a genuinely distinct edition, not modelled in this document; see VERIFICATION.md. Advances North Macedonia's Passport vertical (2 of 6, after Taxes/GOV-2919); Visa was confirmed a dead end during the same GOV-2937 research cycle. GovSchema is an independent, non-profit standards body and is not affiliated with, endorsed by, or operated by the Government of the Republic of North Macedonia or the Министерство за внатрешни работи.

Registry entry

mk/mvr/baranje-za-izdavanje-pasosh

Jurisdiction
North Macedonia · national
Version
1.0.0
Verification
draft
Authority
Министерство за внатрешни работи

Authoritative source Прилог бр. 7 (Annex No. 7), "Барање за издавање пасош, Тип-А", published on mvr.gov.mk's Граѓански постапки (Civil Procedures) forms page

Machine access

Schema document
registry/mk/mvr/baranje-za-izdavanje-pasosh/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/mk/mvr/baranje-za-izdavanje-pasosh/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

31 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

  • reasonForApplication enum required

    The applicant's reason for the application, selected from the form's own seven mutually-exclusive checkboxes (the form's own instruction: "се одбира еден од основите", select one of the grounds): прв пат (first issuance), редовна замена (regular/periodic replacement), промена на лични податоци (change of personal data), замена поради други причини - исполнетост или друго (replacement for another reason - pages exhausted/full, or other), дупликат пасош - изгубен, исчезнат или украден (duplicate passport - lost, missing, or stolen), предвремена замена поради оштетеност на пасошот (premature replacement due to damage to the passport), or издавање на пасош со ограничен рок на важење (issuance of a passport with a limited validity period).

    enum: 7 valuesclassification: pii
  • formLanguageRequest enum optional

    Optional request that the resulting passport document itself be prepared in one of five languages/scripts the form recognizes: турски (Turkish), влашки (Vlach/Aromanian), српски (Serbian), ромски (Roma/Romani), or босански (Bosnian). The form's own instruction: 'се одбира еден од наведените јазици' (one of the stated languages is selected).

    enum: turkish | vlach | serbian | roma | bosnian
  • personalNameLanguageRequest enum optional

    Optional request that the personal-name data specifically be written in one of the same five languages/scripts as formLanguageRequest.

    enum: turkish | vlach | serbian | roma | bosnian
  • dataLanguageRequest enum optional

    Optional request that the form's data generally be written in one of the same five languages/scripts as formLanguageRequest.

    enum: turkish | vlach | serbian | roma | bosnian
  • givenName string required

    The applicant's given name, entered on the form's own 'ИМЕ' column ('1. македонски јазик', Macedonian-language line).

    classification: pii
  • surname string required

    The applicant's surname, entered on the form's own 'ПРЕЗИМЕ' column ('1. македонски јазик', Macedonian-language line).

    classification: pii
  • marriedSurnameBeforeMarriage string optional

    For a married applicant: their surname before marriage.

    classification: pii
  • dateOfBirth date required

    The applicant's date of birth (day, month, and year).

    classification: pii
  • placeOfBirth string required

    The applicant's place of birth. Per the field's own printed instruction, an applicant born abroad also writes the country ('лице родено во странство ја запишува и државата').

    classification: pii
  • personalIdNumber string required

    The applicant's матичен број (EMBG, unique master citizen number).

    classification: sensitive-pii
  • sex enum required

    The applicant's sex: машки (male) or женски (female), per the form's own two checkboxes.

    enum: male | femaleclassification: pii
  • residenceAddress string required

    The applicant's residence and address.

    classification: pii
  • citizenship string required

    The applicant's citizenship.

    classification: pii
  • fatherName string optional

    The applicant's father's name, per the form's own 'ПОДАТОЦИ ЗА РОДИТЕЛИТЕ' (parent data) block.

    classification: pii
  • motherName string optional

    The applicant's mother's name, per the form's own 'ПОДАТОЦИ ЗА РОДИТЕЛИТЕ' (parent data) block.

    classification: pii
  • guardian1Name string optional

    Section 3 applies only when the applicant is a minor: the first parent's/guardian's surname and given name, consenting to the passport application on the minor's behalf. The form prints no explicit boolean gate tying this block to minor status, so it is modelled unconditionally optional per this registry's established convention (see VERIFICATION.md).

    classification: pii
  • guardian1PersonalIdNumber string optional

    The first consenting parent's/guardian's матичен број (EMBG).

    classification: sensitive-pii
  • guardian1Relationship string optional

    The first consenting party's relationship to the minor applicant (e.g. parent, guardian).

  • guardian1Signature string optional

    The first consenting party's signature.

  • guardian2Name string optional

    The second parent's/guardian's surname and given name, when a second consenting party also signs (the form's table provides exactly two rows).

    classification: pii
  • guardian2PersonalIdNumber string optional

    The second consenting parent's/guardian's матичен број (EMBG).

    classification: sensitive-pii
  • guardian2Relationship string optional

    The second consenting party's relationship to the minor applicant.

  • guardian2Signature string optional

    The second consenting party's signature.

  • previousPassportNumber string optional

    The number of the applicant's previous passport, when one exists (Section 4, data about the applicant's previous document).

    classification: sensitive-pii
  • previousPassportIssuingAuthority string optional

    The authority that issued the applicant's previous passport.

  • processingTier enum required

    The requested processing tier: редовна постапка (regular procedure) or итна постапка (urgent procedure).

    enum: regular | urgent
  • submissionDate date optional

    The date the application is submitted, part of the form's own 'Датум и место на поднесување' line.

  • submissionPlace string optional

    The place the application is submitted, part of the form's own 'Датум и место на поднесување' line.

  • applicantSignature string optional

    The applicant's own signature.

  • contactDetails string optional

    The applicant's chosen contact details (the form's own instruction sheet clarifies these may be a phone number or email address, at the applicant's own choice).

    classification: pii
  • receivingOfficialSignature string optional

    Signature of the official who received the application. Completed by MVR staff, not the applicant.

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 states the current verification claim honestly.

Current claim

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

This is a GovSchema Standard Research cycle (GOV-2939, following the GOV-2937 research cycle that pre-verified this candidate). North Macedonia already exists in the registry (opened as the 54th jurisdiction via Taxes, GOV-2919); this document advances North Macedonia's Passport vertical (2 of 6). Visa was confirmed a dead end during the same GOV-2937 cycle (sibling scouting note, not re-screened here).

Source re-verification (Phase 1)

  • Authority: МВР (Министерство за внатрешни работи, Ministry of Internal Affairs), a national ministry.
  • Source page: https://mvr.gov.mk/mk-MK/uslugi/gragjanski-postapki (Граѓански постапки / Civil Procedures forms page). Independently re-fetched this cycle (curl -sL, HTTP 200, 659,532-byte HTML); confirmed both candidate PDF links are genuinely present on this live page, each anchored by its own visible link label: ...-xE03.pdf is labelled "Барање за издавање пасош тип А" and ...-Ni0J.pdf is labelled "Барање за издавање пасош тип Б" — resolving the Type A/Type B question directly from the source page's own markup, not by inference.
  • Modelled candidate (Type A): https://portal.mdt.gov.mk/post-documents/gragjanski-postapki-document-xE03.pdf — independently re-fetched this cycle with curl -sL. HTTP status: 200. Content-Type: application/pdf. Size: 1,440,598 bytes — matches the issue's own citation exactly. sha256: 09e4cf57ee51fc452c60d7317964c2c180d10788a2c0fe0f8590c59608a2d75c — independently computed this cycle with sha256sum, matching the issue's own citation exactly.
  • Type B mirror (not modelled): https://portal.mdt.gov.mk/post-documents/gragjanski-postapki-document-Ni0J.pdf — independently re-fetched this cycle. HTTP status: 200. Content-Type: application/pdf. Size: 2,064,363 bytes — matches the issue's own citation exactly. sha256: e74d30803a0171979e84bfb62b40a434ebcb8f6fa01e43ddcd60cc8525d12351.
  • File type: both are genuine PDFs with real embedded fonts and Tj/TJ text-drawing operators (not scanned images) but zero AcroForm/Widget annotations — confirmed via pdfjs-dist@3 (legacy/build/pdf.js) page.getAnnotations() returning 0 widgets on every page of both files. Both are print-and-lodge specimens, not fillable AcroForms.
  • Text-extraction caveat confirmed: the source's font subsetting lacks a proper ToUnicode CMap. page.getTextContent() on both files returns glyph-garbled strings (e.g. Cyrillic б/а/р/а/њ/е comes back as Ilpluor/6p.7 fragments) — unusable directly. Per the issue brief's own guidance, this cycle instead independently rendered every page of both candidates to a PNG image (pdfjs-dist@3 + node-canvas, scale 2.5, using a NodeCanvasFactory — pdfjs-dist v4's legacy/build/pdf.mjs crashed on this file's inline JPEG XObjects with TypeError: Image or Canvas expected; downgrading to pdfjs-dist@3.11.174's CommonJS legacy/build/pdf.js build resolved it) and read every field directly off the rendered image. This is a full visual read, not a coordinate-correlation exercise (there are no AcroForm widget rects to correlate against), since neither candidate has any fillable widgets.

Type A vs. Type B disambiguation

Both candidates share the same seven-section structure (reason for application, applicant/parent data, minor-guardian consent, previous-document data, processing tier, submission, and an attachment checklist plus data-use consent), but they are a genuinely distinct pair of editions, not a redundant duplicate:

  • Type A (Прилог бр. 7, xE03.pdf, 2 pages, 790 raw text items) is printed in Macedonian only, and its Section 2.2 offers three independent checkbox groups requesting Turkish/Vlach/Serbian/Roma/Bosnian-language processing of the resulting document, the applicant's own name data, or the form's data generally.
  • Type B (Прилог бр. 8, Ni0J.pdf, 2 pages, 1,423 raw text items) is printed bilingually in Macedonian and Albanian throughout (every field label, heading, and instruction line is duplicated: ИМЕ/EMRI, ПОЛ/GJINIA, etc.), drops Type A's Section 2.2 minority-language checkboxes entirely, and adds a field with no Type A counterpart: НАЦИОНАЛНА ПРИПАДНОСТ / PËRKATËSIA NACIONALE (national/ethnic affiliation).

Type A is modelled in this document as the general-purpose specimen: its own Section 2.2 checkbox list (Turkish/Vlach/Serbian/Roma/Bosnian) notably does not offer Albanian, which is presumably why the bilingual Type B exists as its own dedicated pathway specifically for applicants requesting Albanian-language processing. Type B is disclosed here as a real, sourced, out-of-scope candidate for a possible future companion schema; it is not modelled in this cycle, per this registry's one-deliverable-per-issue convention.

Field inventory (Phase 2)

All 31 fields[] entries and 9 documents[] entries are listed inline in schema.json with a sourceRef/sourceRef-equivalent citation to the exact section and label on the rendered page image. Section-by-section:

| Section (Type A) | Modelled as | |---|---| | 1. Причина за барање (7 checkboxes) | reasonForApplication (enum) | | 2.1 ИМЕ / ПРЕЗИМЕ | givenName, surname | | 2.2 three language-preference checkbox rows | formLanguageRequest, personalNameLanguageRequest, dataLanguageRequest (each enum) | | Personal-data block | marriedSurnameBeforeMarriage, dateOfBirth, placeOfBirth, personalIdNumber, sex, residenceAddress, citizenship | | Parent-data block | fatherName, motherName | | 3. Guardian consent table (2 rows × 4 columns) | guardian1Name/guardian1PersonalIdNumber/guardian1Relationship/guardian1Signature, and the guardian2* equivalents | | 4. Previous-document data | previousPassportNumber, previousPassportIssuingAuthority | | 5. Processing tier (2 checkboxes) | processingTier (enum) | | Footer (submission/signature/contact/receiving-official) | submissionDate, submissionPlace, applicantSignature, contactDetails, receivingOfficialSignature | | 6. Attachment checklist (8 checkbox rows, spanning pages 1-2) | 8 documents[] entries, identity-document/supporting-evidence | | 7. Personal-data-use consent checkbox | 1 documents[] entry, category: attestation, with the exact printed statement text |

Judgment calls

  1. Reason-for-application modelled as a single enum, not seven independent booleans. The form's own instruction ("се одбира еден од основите", one of the grounds is selected) states the seven checkboxes are mutually exclusive, matching this registry's established single-enum convention for this shape (e.g. bg/mvr/zayavlenie-za-izdavane-na-pasport's requestedDocumentType/ serviceType).
  2. Three Section 2.2 language-preference rows modelled as three separate optional enum fields, not one. Each row carries its own distinct printed request sentence (form itself / personal-name data / form's data generally) and each is independently selectable — a single applicant could plausibly tick different languages on different rows — so collapsing them into one field would lose real information.
  3. Guardian consent block (Section 3) modelled unconditionally required: false, with no invented gating field. The form prints no explicit boolean checkbox tying this table to minor/ward status (unlike the reason-for-application or processing-tier checkboxes, which are genuine widgetless-but-explicit checkbox groups); consistent with this registry's established convention for this exact pattern (see si/mzez/vloga-za-pridobitev-potnega-lista's legal-representative block and its own judgment call 2).
  4. Section 6's attachment checklist modelled as documents[], not fields[]. Per GSP-0014, these are document/evidence requirements, not applicant-entered data. Two entries (birthOrMarriageRegistryExtract, for reasons 1.1/1.3; lostMissingStolenPassportReport and passportInvalidationProof, for reason 1.5) carry a requiredWhen condition directly against reasonForApplication, mirroring the form's own printed (*) annotations ("за 1.1 и 1.3", "за 1.5"). The remaining attachment items (parentalConsentOrPowerOfAttorney, guardianshipProof, guardianshipAuthorityConsentForMinorNameChange) are left required: false with no requiredWhen, for the same reason as judgment call 3 above — no explicit form-printed gate exists to attach a condition to.
  5. Section 7's consent checkbox modelled as a documents[] entry with category: attestation, not a boolean fields[] entry. This follows this registry's established convention for a single sworn/consent checkbox with fixed printed text (see mx/sre/passport-application's swornTruthfulnessAndNationalityDeclaration); the statement field carries the exact Macedonian text verbatim.
  6. All signature fields modelled as type: string. Consistent with this registry's established convention for paper-form signature blocks on non-AcroForm specimens.
  7. Office-only fields modelled with required: false, not omitted. receivingOfficialSignature is completed by MVR staff, not the applicant, but is modelled per the instruction to model every printed field faithfully.

Conformance verification

A one-off checker script (check_conformance.mjs, not committed — ad hoc per this registry's convention, mirroring prior cycles, e.g. dk/fstyr/samtykkeerklaering-koerekort-under-18) was written to evaluate every fixture in conformance/mk/mvr/baranje-za-izdavanje-pasosh/1.0.0/ against this schema's fields[] (required/requiredWhen/validation.enum) and documents[] (required/requiredWhen) rules. Results:

| Fixture | Errors | Expected | |---|---|---| | valid-first-issuance-adult.json | 0 | 0 | | valid-duplicate-lost-passport-minor-guardian.json | 0 | 0 | | mutation-control-missing-static-required-reason.json | 1 (reasonForApplication missing) | 1 | | mutation-control-invalid-enum-reason.json | 1 (reasonForApplication value not in enum) | 1 | | mutation-control-missing-conditional-document-first-issuance.json | 1 (birthOrMarriageRegistryExtract requiredWhen violated) | 1 | | mutation-control-missing-conditional-document-duplicate.json | 1 (lostMissingStolenPassportReport requiredWhen violated) | 1 | | mutation-control-missing-attestation.json | 1 (dataProcessingConsentDeclaration missing) | 1 |

All 7 fixtures produced exactly the expected error count. The two valid scenarios cover both a reason requiring the birth/marriage extract (first-issuance) and a reason requiring the two duplicate-passport documents (lost/missing/stolen) plus the guardian block; the five mutation controls each isolate exactly one rule type (plain required on a field, validation.enum, two independent requiredWhen conditions on documents[], and plain required on a documents[] attestation entry) by construction.

Shared-checkout note

Two sibling in-progress schemas from concurrent GOV-2937 child issues (mk/mvr/baranje-za-izdavanje-na-lichna-karta, mk/mvr/baranje-za-izdavanje-na-vozacka-dozvola) were present as untracked files under registry/mk/mvr/ in this shared checkout while this document was authored. They were temporarily moved aside before running npm run build-index so this document's own registry-index.json regeneration would not prematurely include their still-in-progress entries, then restored unmodified immediately after. This document's own git history touches only baranje-za-izdavanje-pasosh.

Registry validation

  • node tools/validate.mjs registry/mk/mvr/baranje-za-izdavanje-pasosh/1.0.0/schema.json → ok, 1/1 passed
  • node tools/validate-ajv.mjs registry/mk/mvr/baranje-za-izdavanje-pasosh/1.0.0/schema.json → ok against the v0.3 meta-schema, 1/1 validated
  • tools/govschema-client/registry-index.json regenerated via npm run build-index (440 entries, +1) and diffed — only this document's entry added.

View the raw record (VERIFICATION.md)

Version history

  • 1.0.0 draft latest this page has verification record schema.json

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Министерство за внатрешни работи or any government. The authoritative source is always the live government form and its official instructions.