Wersja: 1.1
Data: Styczeń 2026
Autor: Jarosław Kaczmarski
Kontakt: jaroslaw.kaczmarski@outlook.com
Rozprzestrzenienie się generatywnej sztucznej inteligencji sprawiło, że tradycyjne systemy CAPTCHA stały się nieskuteczne jako środek rozróżniania ludzi od zautomatyzowanych agentów. Obecne alternatywy albo naruszają prywatność użytkowników (Proof of Humanity), wymagają specjalistycznego sprzętu (Worldcoin), albo opierają się na słabych źródłach weryfikacji (Privacy Pass).
Ten dokument proponuje Anonimową Weryfikację Człowieczeństwa (AHV) — system wykorzystujący istniejącą infrastrukturę rządu i instytucji finansowych do wydawania poświadczeń „ludzkości" zachowujących prywatność. System wykorzystuje dowody zerowej wiedzy, aby potwierdzać jedynie, że użytkownik jest zweryfikowanym człowiekiem, nie ujawniając jego tożsamości. Nowatorski model weryfikacji progowo-losowej zapewnia, że konta o dużym wpływie podlegają obowiązkowej weryfikacji, podczas gdy zwykli użytkownicy spotykają się z okazjonalnymi losowymi kontrolami, co czyni farmy botów ekonomicznie nierentownymi bez narzucania nadzoru ogółowi społeczeństwa.
Proponowany system naturalnie integruje się z ramami Europejskiej Tożsamości Cyfrowej (EUDI Wallet) wymaganymi przez eIDAS 2.0, pozycjonując go do szybkiego przyjęcia w całej Unii Europejskiej.
Przez dwie dekady CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) służył jako podstawowy mechanizm rozróżniania użytkowników będących ludźmi od automatycznych botów. Jednak postępy w uczeniu maszynowym fundamentalnie podważyły to podejście:
Pojawienie się dużych modeli językowych (LLM) zdolnych do przejścia testu Turinga wyeliminowało ostatnią niezawodną cyfrową metodę weryfikacji człowieczeństwa. Bot może teraz prowadzić długie rozmowy, pisać przekonujące posty i wykazywać zachowania podobne do ludzkich, nieodróżnialne od prawdziwych użytkowników.
Niemożność weryfikacji człowieczeństwa online ma poważne konsekwencje:
Dezinformacja na skalę: Farmy botów wzmacniają fałszywe narracje, manipulują opinią publiczną i ingerują w procesy demokratyczne.
Degradacja platform: Platformy mediów społecznościowych zostają zanieczyszczone syntetycznymi treściami, erodując zaufanie i zaangażowanie użytkowników.
Oszustwa ekonomiczne: Fałszywe konta umożliwiają manipulację recenzjami, oszustwa kliknięciowe i ataki credential stuffing.
Erozja dyskursu online: Gdy ludzie nie mogą ufać, że komunikują się z innymi ludźmi, znaczący dialog staje się niemożliwy.
Skuteczny system weryfikacji ludzi musi spełniać kilka warunków:
Mechanizm: Użytkownicy rozwiązują CAPTCHA raz i otrzymują kryptograficznie zaślepione tokeny. Te tokeny mogą być wykorzystywane do przyszłego dostępu bez rozwiązywania dodatkowych CAPTCHA.
Zalety:
- Zachowuje prywatność poprzez ślepe podpisy
- Niemożliwe do powiązania wykorzystanie tokenów
- Wdrożony na skalę (sieć Cloudflare)
Wady:
- Źródłem weryfikacji jest CAPTCHA — teraz pokonywalna przez AI
- Nie weryfikuje człowieczeństwa, tylko umiejętność rozwiązywania CAPTCHA
- Tokeny mogą być „farmowane" przez boty używając usług rozwiązywania CAPTCHA
Mechanizm: Użytkownicy rejestrują się poprzez przesłanie nagrania wideo siebie i poręczenie przez istniejących zarejestrowanych użytkowników. Rejestracje są przechowywane w blockchainie Ethereum.
Zalety:
- Silna weryfikacja poprzez dowód wideo
- Zdecentralizowane zarządzanie
- Odporne na ataki Sybil poprzez sieć poręczeń
Wady:
- Nie zachowuje prywatności — wideo i adres Ethereum są publiczne
- Tworzy trwały rekord łączący tożsamość z aktywnością blockchain
- Technologia deepfake zagraża integralności weryfikacji wideo
- Wymaga wiedzy o kryptowalutach
Mechanizm: Użytkownicy skanują swoją tęczówkę za pomocą specjalistycznego urządzenia („Orb"), które generuje unikalny hash biometryczny. Ten hash jest używany do wydania poświadczenia „World ID".
Zalety:
- Silna weryfikacja biometryczna
- Dowody zerowej wiedzy chronią prywatność po rejestracji
- Globalne ambicje
Wady:
- Wymaga specjalistycznego sprzętu — Orby są rzadkie i geograficznie ograniczone
- Zbieranie danych biometrycznych budzi głębokie obawy o prywatność
- Scentralizowana kontrola nad wdrażaniem Orb
- Kontrowersyjne praktyki dotyczące danych doprowadziły do kontroli regulacyjnej
- Użytkownicy muszą zaufać, że surowe dane biometryczne nie są zachowywane
Mechanizm: Rozporządzenie UE nakazujące państwom członkowskim dostarczanie cyfrowych portfeli tożsamości zdolnych do przechowywania weryfikowalnych poświadczeń. Portfele wspierają selektywne ujawnianie atrybutów.
Zalety:
- Mandat prawny zapewnia przyjęcie (termin: koniec 2026)
- Wykorzystuje istniejącą rządową infrastrukturę tożsamości
- Zaprojektowany dla prywatności (selektywne ujawnianie)
- Standaryzowany w całej UE
Wady:
- Framework ogólnego przeznaczenia — nie adresuje specjalnie weryfikacji człowieczeństwa
- Implementacja różni się między państwami członkowskimi
- Nie jest jeszcze w pełni wdrożony
Privacy Pass: Anonimowy ale słaba weryfikacja
Proof of Humanity: Silna weryfikacja ale nie anonimowy
Worldcoin: Silny i częściowo anonimowy ale wymaga specjalnego sprzętu
eIDAS 2.0: Silna infrastruktura ale brak przypadku użycia weryfikacji człowieczeństwa
Zidentyfikowana luka: Żadne istniejące rozwiązanie nie łączy silnej weryfikacji, pełnej anonimowości i opierania się na istniejącej infrastrukturze.
Anonimowa Weryfikacja Człowieczeństwa wykorzystuje weryfikację tożsamości już przeprowadzoną przez zaufane instytucje — w szczególności rządowe systemy tożsamości (np. mObywatel w Polsce) i regulowane instytucje finansowe (banki) — do wydawania poświadczeń, które zaświadczają tylko o człowieczeństwie posiadacza.
Kluczową obserwacją jest to, że te instytucje już zweryfikowały, że ich użytkownicy to prawdziwi ludzie poprzez procesy Know Your Customer (KYC) wymagane przez prawo. Ta weryfikacja może być ponownie wykorzystana bez ponownego ujawniania podstawowych danych tożsamości.
Co system potwierdza:
- Użytkownik posiada ważne poświadczenie od zaufanego wydawcy
- Wydawca zweryfikował, że posiadacz poświadczenia to człowiek
Czego system NIE ujawnia:
- Który człowiek
- Imię, numer ID, adres lub jakiekolwiek dane osobowe
- Czy to ten sam człowiek co w poprzedniej weryfikacji
- Jakikolwiek identyfikator możliwy do powiązania
┌─────────────────────────────────────────────────────────────┐
│ HIERARCHIA ZAUFANIA │
├─────────────────────────────────────────────────────────────┤
│ │
│ Poziom 1: WYDAWCY (zaufani) │
│ ├── Rządowe systemy tożsamości (mObywatel, itp.) │
│ ├── Regulowane instytucje finansowe (banki) │
│ └── Wymagania: KYC-zweryfikowane, audytowane, rozliczalne │
│ │
│ Poziom 2: BRAMA WERYFIKACYJNA (zaufany pośrednik) │
│ └── Waliduje kody, wydaje tokeny krótkotrwałe │
│ │
│ Poziom 3: POSIADACZE (niezaufani do weryfikacji) │
│ └── Każdy użytkownik z poświadczeniem od wydawcy Poziomu 1│
│ │
│ Poziom 4: WERYFIKATORZY (ufają Poziomom 1 i 2) │
│ └── Strony, platformy, usługi żądające dowodu │
│ │
└─────────────────────────────────────────────────────────────┘Weryfikatorzy nie muszą ufać poszczególnym użytkownikom. Ufają wydawcom i bramie weryfikacyjnej.
System AHV składa się z czterech głównych komponentów:
┌─────────────────────────────────────────────────────────────────────┐
│ ARCHITEKTURA AHV │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────────────┐ │
│ │ mObywatel │ │ Brama │ │
│ │ / App Banku│ ────── kod ───────→ │ Weryfikacyjna │ │
│ │ │ │ (brama.gov.pl) │ │
│ └──────────────┘ └──────────┬───────────┘ │
│ │ │ │
│ │ generuje │ waliduje │
│ │ kod typu │ z wydawcą │
│ │ BLIK │ │
│ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Użytkownik │ ◄────── JWT ─────────│ Zwraca token JWT │ │
│ │ (przeglądarka│ token │ { human: true, │ │
│ │ │ │ age_over_18: true │ │
│ └──────┬───────┘ │ exp: 24h } │ │
│ │ └──────────────────────┘ │
│ │ X-VP-Token: <jwt> │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Strona │ ───── weryfikuj ───→ │ Endpoint JWKS │ │
│ │ Docelowa │ ◄──── klucz publ.────│ /.well-known/jwks │ │
│ │ (reddit.com) │ └──────────────────────┘ │
│ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Strona docelowa weryfikuje podpis JWT lokalnie │ │
│ │ → Brak potrzeby wywołania bramy │ │
│ │ → Wie tylko: human=true, age_over_18=true │ │
│ │ → NIE wie: kto, imię, ID, itp. │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘Użytkownicy generują jednorazowy kod weryfikacyjny w swojej zaufanej aplikacji:
Doświadczenie użytkownika:
1. Otwórz aplikację mObywatel lub bankową
2. Uwierzytelnij się (biometria/PIN)
3. Wybierz „Generuj Kod Weryfikacji Człowieczeństwa"
4. Otrzymaj 6-cyfrowy kod ważny przez 2 minuty
Właściwości kodu:
- 6 cyfr (jak BLIK)
- Ważny przez 120 sekund
- Jednorazowe użycie
- Powiązany z zweryfikowaną tożsamością użytkownika (ale tożsamość nie jest transmitowana)
Brama Weryfikacyjna działa jako zaufany pośrednik:
Odpowiedzialności:
- Otrzymuje kody weryfikacyjne od użytkowników
- Waliduje kody z instytucją wydającą (bank/mObywatel)
- Wydaje tokeny JWT po pomyślnej walidacji
- Nie prowadzi logów łączących tokeny z tożsamościami
Endpointy API:
POST /verify
Content-Type: application/json
{
"code": "123456",
"issuer": "mbank.pl",
"requested_claims": ["human", "age_over_18"]
}
Odpowiedź (sukces):
{
"token": "eyJhbGciOiJFUzI1NiIs...",
"expires_in": 86400
}
Odpowiedź (błąd):
{
"error": "invalid_code",
"message": "Kod wygasł lub jest nieprawidłowy"
}Brama wydaje standardowe tokeny JWT:
Header:
{
"alg": "ES256",
"typ": "JWT",
"kid": "gateway-key-2026-01"
}Payload:
{
"iss": "https://brama.gov.pl",
"iat": 1706435000,
"exp": 1706521400,
"jti": "unique-token-id-xyz",
"human": true,
"age_over_13": true,
"age_over_18": true,
"age_over_21": false,
"verification_level": "government_kyc",
"issuer_country": "PL",
"session_hash": "a8f3b2c1d4e5f6..."
}Kluczowe decyzje projektowe:
Rekomendowane czasy życia tokenów:
| Przypadek użycia | Czas życia tokenu | Uzasadnienie |
|---|---|---|
| Ogólne przeglądanie | 24 godziny | Balans bezpieczeństwo/wygoda |
| Posty w mediach społecznościowych | 24 godziny | Rozsądna długość sesji |
| Transakcje finansowe | 15 minut | Wyższe wymagania bezpieczeństwa |
| Treści z ograniczeniami wiekowymi | 7 dni | Mniej wrażliwe |
Mechanizm odświeżania:
Tokeny mogą być odświeżane bez ponownego wprowadzania kodu jeśli:
- Oryginalny token jest nadal ważny (nie wygasł)
- Hash sesji pasuje (to samo urządzenie)
- W oknie odświeżania (np. ostatnie 10% okresu ważności)
POST /refresh
Authorization: Bearer <current-token>
Odpowiedź:
{
"token": "eyJhbGciOiJFUzI1NiIs...",
"expires_in": 86400
}Zamiast wymagania weryfikacji od każdego użytkownika lub przy każdej akcji, AHV wprowadza hybrydowy model weryfikacji, który równoważy bezpieczeństwo z trudnościami użytkownika:
Weryfikacja progowa: Konta przekraczające określone progi wpływu muszą ukończyć weryfikację.
Weryfikacja losowa: Wszystkie inne konta mają niewielkie prawdopodobieństwo weryfikacji przy każdej akcji.
Weryfikacja staje się obowiązkowa gdy:
Dla kont poniżej progów:
- Każda kwalifikowana akcja (post, komentarz, udostępnienie) ma prawdopodobieństwo p wywołania weryfikacji
- Rekomendowane p = 0,02 (2%)
- Platforma może dostosować w oparciu o sygnały ryzyka
Przeciw farmom botów:
Farma obsługująca 10 000 kont botów będzie miała do czynienia z:
- ~200 wyzwaniami weryfikacyjnymi (przy p=0,02)
- Każde wyzwanie wymaga unikalnego poświadczenia ludzkiego
- Zdobycie 200 ludzkich poświadczeń jest kosztowne/trudne
- Model ekonomiczny farmy botów upada
Dla zwykłych użytkowników:
Niech:
- n = liczba kont botów
- p = prawdopodobieństwo losowej weryfikacji
- c = koszt zdobycia jednego ludzkiego poświadczenia
- v = wartość generowana na konto bota
Farma botów jest opłacalna gdy: n × v > (n × p) × c
Z p = 0,02, c = 100 PLN (konserwatywne szacunki dla poświadczeń z czarnego rynku):
- 10 000 botów generujących po 10 PLN wartości = 100 000 PLN przychodu
- Oczekiwany koszt weryfikacji = 10 000 × 0,02 × 100 PLN = 20 000 PLN
Rentowność zmniejszona o 20%. Ale co ważniejsze:
- Poświadczenia są trudne do zdobycia na skalę
- Każda oflagowana weryfikacja trwale spala poświadczenie
- Ograniczenia podaży czynią skalowanie niemożliwym
Rozporządzenie eIDAS 2.0 (Rozporządzenie UE 2024/1183) nakazuje:
AHV jest naturalnym rozszerzeniem tej struktury:
- Poświadczenie Weryfikacji Człowieczeństwa to jeden typ poświadczenia wśród wielu
- Wydawanie wykorzystuje istniejącą rządową weryfikację tożsamości
- Używa standardowego formatu W3C Verifiable Credentials
- Kompatybilny z architekturą portfela EUDI
Proponujemy dodanie „HumanVerificationCredential" do typów poświadczeń wspieranych przez portfel EUDI:
Typ poświadczenia: HumanVerificationCredential
Wymagania wydawcy: Rządowy organ tożsamości lub
regulowana instytucja finansowa
Atrybuty:
- type: "VerifiedHuman" (wymagane)
- verificationLevel: "government_kyc" | "bank_kyc" (wymagane)
- age_over_13: boolean (opcjonalne)
- age_over_18: boolean (opcjonalne)
- age_over_21: boolean (opcjonalne)
- issuer_country: ISO 3166-1 kod kraju (wymagane)
Faza 1: Pilot krajowy (2026)
- Implementacja w Polsce z mObywatel
- Demonstracja wykonalności
- Zbieranie danych o akceptacji użytkowników
Faza 2: Standardyzacja EU (2027)
- Propozycja do European Digital Identity Wallet Architecture Reference Framework
- Konsultacje z państwami członkowskimi
- Piloty w 3-5 krajach
Faza 3: Wdrożenie w całej UE (2028)
- Pełna integracja z portfelami EUDI
- Wzajemne uznawanie między krajami
- Adopcja przez główne platformy
Upadek CAPTCHA jako mechanizmu weryfikacji człowieczeństwa wymaga nowych podejść. Anonimowa Weryfikacja Człowieczeństwa oferuje drogę naprzód, która:
Okno na działanie to teraz. Gdy możliwości AI nadal się rozwijają, koszt bezczynności rośnie. Zapraszamy do współpracy polityków, technologów i platformy, aby przenieść Anonimową Weryfikację Człowieczeństwa z koncepcji do rzeczywistości.
Parlament Europejski i Rada. Rozporządzenie (UE) 2024/1183 ustanawiające Europejską Strukturę Tożsamości Cyfrowej. 2024.
W3C. Verifiable Credentials Data Model v1.1. 2022.
IETF. RFC 7519 - JSON Web Token (JWT). 2015.
IETF. RFC 7517 - JSON Web Key (JWK). 2015.
Tessaro, S., & Zhu, C. "Privacy Pass: Bypassing Internet Challenges Anonymously." Proceedings on Privacy Enhancing Technologies. 2018.
Proof of Humanity. https://proofofhumanity.id/
Worldcoin Foundation. "Humanness in the Age of AI." 2023.
Komisja Europejska. Digital Services Act (Rozporządzenie UE 2022/2065). 2022.
BBS+ Signatures. https://w3c-ccg.github.io/ldp-bbs2020/
System płatności BLIK. https://blik.com/
AHV: Anonimowa Weryfikacja Człowieczeństwa
BBS+: Schemat podpisów Boneh-Boyen-Shacham wspierający selektywne ujawnianie
BLIK: Polski standard płatności mobilnych używający 6-cyfrowych kodów
CAPTCHA: Całkowicie Zautomatyzowany Publiczny Test Turinga do rozróżniania komputerów i ludzi
DSA: Digital Services Act (Akt o Usługach Cyfrowych)
eIDAS: Elektroniczna Identyfikacja, Uwierzytelnianie i Usługi Zaufania
EUDI: Europejska Tożsamość Cyfrowa
JWT: JSON Web Token
JWKS: JSON Web Key Set
KYC: Know Your Customer (Poznaj Swojego Klienta)
VP: Verifiable Presentation (Weryfikowalna Prezentacja)
ZK: Zero-Knowledge (Zerowa Wiedza)
| Endpoint | Metoda | Opis |
|---|---|---|
/verify |
POST | Wymiana kodu na token |
/refresh |
POST | Odświeżenie istniejącego tokenu |
/introspect |
POST | Weryfikacja ważności tokenu |
/.well-known/jwks.json |
GET | Klucze publiczne do weryfikacji |
| Header | Użycie |
|---|---|
X-VP-Token |
Przenosi token weryfikacyjny na stronę docelową |
X-VP-Required-Claims |
Strona określa wymagane claims |
Dokument ukończony: Styczeń 2026
Autor: Jarosław Kaczmarski
Kontakt: jaroslaw.kaczmarski@outlook.com
Wersja: 1.1 (tłumaczenie polskie)