# Verification record — ge/mfa/evisa-application@1.0.0 ## Candidate selection GOV-3313 ("GovSchema Standard Research", 2026-07-16) scouted Georgia's e-Visa portal alongside four other candidates while looking for a new jurisdiction, found it a strong, ~74-field, unauthenticated candidate, but authored Ethiopia instead that cycle and left Georgia as disclosed backlog (see this registry's own CATALOG.md "Known Gaps & Opportunities" section, entry "GOV-3313 — Georgia"). This cycle (GOV-3321) picked up that candidate and authored it. Georgia had no prior schema of any kind in this registry; this opens it as the registry's 65th jurisdiction with one vertical (Visa). ## Reaching the live source Fetched `https://evisa.gov.ge/GeoVisa/en/VisaApp` twice this session with a plain `curl`, using a standard desktop Chrome User-Agent string (the root domain and some mirrors WAF-block a default headless/no-UA fingerprint, but succeed immediately once a normal UA is set — this was independently reconfirmed, matching the prior cycle's own note): - HTTP 200, `Content-Type: text/html; charset=utf-8`, `Content-Length: 95545` both times. - **Correction (GOV-3324 review gate):** the page embeds a fresh, per-request `__RequestVerificationToken` anti-forgery value as a hidden input on every single response — confirmed by re-fetching four times (including twice with a persisted cookie jar, ruling out session affinity) and observing four distinct token values and four distinct raw sha256 hashes, all at the same 95,545-byte length. A raw whole-page sha256 is therefore not a reproducible fidelity check for this source (the originally recorded `98ed9f59219a74850b6aee3b2ec0a145ae73a1349bb92f78085f760e0c80b652` could not be reproduced by this review). Applying this registry's own established redacted-token technique (see `ng/frsc/vehicle-registration` v1.0.0's VERIFICATION.md, GOV-3231) — replacing the `__RequestVerificationToken` hidden input's `value` attribute with a fixed placeholder before hashing — produces a byte-identical structural sha256 of `0050f9db95c380decf0ff251db9f97f3a7f037fe4c052578dc3235465c415297` across all four independent fetches, confirming the rest of the page (all field markup, `data-val-*` attributes, and dropdown option lists this schema is sourced from) is in fact stable and reproducible. - Response headers confirm `Server: Microsoft-IIS/10.0`, `X-AspNetMvc-Version: 4.0`, `X-AspNet-Version: 4.0.30319`, and a custom `Server: MFA of Georgia` header — a genuine, government-operated ASP.NET MVC application, not a CDN/WAF stub. No login, account creation, or payment gate blocks reaching or reading this page. ## Structure of the source: one ViewModel, one step visibly rendered This is a single server-rendered page whose one `
` element spans the *entire* wizard's underlying C# ViewModel — not five separate partial views. Only the first step, "Citizenship/Country" (marked `class="active"` in the page's own `wizard-steps` navigation table, and delimited by an explicit ` ... ` HTML comment pair), renders its inputs as normal, visible, interactive controls (``, ``). Every other step's fields — Travel Information, Terms & Conditions, Personal Information, and Verification — are already present in the same HTTP response, but as `type="hidden"` inputs with empty/default values. This is the standard ASP.NET MVC pattern of serializing the full model as hidden fields to preserve state across postbacks; it is not evidence that those steps are independently reachable without a server round-trip (they are not — see below). Critically, ASP.NET's unobtrusive client validation auto-generates `data-val-required`/`data-val-date`/`data-val-number`/`data-val-range` attributes directly from the underlying model's own C# `[Required(ErrorMessage="...")]`/`[Range(...)]` attributes. These attributes are present on the hidden inputs for every later step exactly as they would be on the visible inputs once that step actually renders — they are accurate, government-authored field descriptions tied to the model property, not something that changes based on which step is currently displayed. This is the basis for modelling the Travel Information, Terms & Conditions, and Personal Information steps' fields below without needing to interactively reach them. ## The Citizenship/Country step, confirmed live via Playwright Walked with Playwright + Chromium (`executablePath` pointed at the locally cached Chromium build at `/paperclip/.cache/ms-playwright/chromium-1228/chrome-linux64/chrome`, `LD_LIBRARY_PATH` set to the sysroot's `libglib-2.0.so.0` path, `waitUntil: 'domcontentloaded'`). Read all four `` do carry a `data-val-required` attribute (`"The Check the box if applicant has insurance field is required."` and `"The Country of supporting document field is required."` respectively), independently reconfirmed live. The `required: false` modelling itself still holds — for the same reason already established for `visaType`'s stale `data-val-range` above: the page's own `checkfirstpage()` function, the mechanism that actually gates whether the wizard advances, explicitly comments out the check for both fields, so the static attribute is present but functionally unenforced. The two fields' descriptions in `schema.json` have been corrected to state this accurately rather than claim the attribute is absent. ## The CAPTCHA gate, and why Representative/Companion and documents are out of scope The step's "NEXT" button runs `checkfirstpage()`, which (once its checks pass) fires an AJAX GET to `/GeoVisa/en/VisaApp/CheckAllDocuments` with the selected country/document-type/visa-type and the CAPTCHA value, then conditionally clicks a second, hidden "NEXT" button (`#formsubmit`) that performs the actual form POST advancing the wizard server-side. This session used Playwright to select real values for `Citizenship`, `DocumentType`, and `VisaType`, checked `HasReadBorderCrossInfo` (via `window.checkBorderCrossCheckBox(true)`, its own exposed JS function, since the checkbox's native click target is covered by custom CSS styling), and then directly invoked `document.getElementById('formsubmit').click()` to attempt the real server POST, bypassing the client-side `checkfirstpage()` gate entirely (to test whether server-side validation would still allow progress even with an arbitrary CAPTCHA value). The server rejected this with an "Error — Security verifivation code is incorrect" [sic, the site's own typo] modal and re-rendered step 1 rather than advancing — confirming the CAPTCHA (`SecurityCode`, backed by an image at `/GeoVisa/CaptchaImageHandler.ashx`) is a genuine, server-side- enforced gate, not merely client-side theater. Separately, a plain unauthenticated GET to `/GeoVisa/en/VisaApp/CheckAllDocuments` (with a placeholder captcha value) returned HTTP 500, consistent with that endpoint expecting a CAPTCHA token tied to the current session rather than an arbitrary string. Solving or otherwise bypassing this CAPTCHA was out of scope for this research task (reading the form's own public structure), so two parts of the live wizard could not be confirmed and are excluded from this schema as a disclosed scope boundary: 1. **The Representative and Travelling-With-Companion sub-flows.** Both are gated by their own opt-in checkbox (`ByRepresentative`, `WithCompanion`) and each requires selecting a "relationship to the applicant"/"relationship to the accompanying person" from a numeric-ID `