Czym różni się Verify v2 od dzisiejszego /verify?

Verify v2 to specyfikacja rozszerzenia dzisiejszego weryfikatora o upload pliku (PDF/JSON/manifest) zamiast wklejania tekstu JSON oraz o osobny wskaźnik statusu podpisu elektronicznego. Mechanizm liczenia hasha SHA-256 pozostaje identyczny i działa dziś (LIVE) — nowością jest wyłącznie sposób dostarczenia pliku i dodatkowy wskaźnik podpisu, oba dziś w statusie ROADMAP (spec bez kodu).

Czy upload pliku PDF/JSON/manifest już działa w Verify v2?

Nie. Upload pliku to dziś specyfikacja (ROADMAP), nie działająca funkcja. Operator, który chce zweryfikować pakiet, korzysta z /verify — wkleja treść JSON ręcznie, a przeglądarka liczy SHA-256 lokalnie. Nie udajemy istnienia formularza uploadu, którego nie ma w kodzie.

Czy ipIII wystawia podpisy PAdES lub znaczniki czasu TSA?

Nie jeszcze. Podpis PAdES i znacznik czasu TSA (RFC 3161) są oznaczone jako ROADMAP w rejestrze known-limitations (priorytet P1). Dziś dostępny jest wyłącznie hash SHA-256 integralności treści oraz, w trybie shadow na środowisku staging, mechanizm HMAC integrity z fali F2 — żaden z nich nie zastępuje formalnego podpisu elektronicznego wystawcy.

Co to jest HMAC integrity F2 w trybie shadow?

To wewnętrzny mechanizm kontroli integralności ładunku transportowego z fali rozwoju F2, uruchomiony w trybie obserwacyjnym (shadow) na środowisku staging: wynik jest liczony i logowany, ale niezgodność nie blokuje dziś ruchu. To nie jest podpis PAdES ani mechanizm produkcyjny na środowisku bankowym — to krok pośredni w kierunku twardszej weryfikacji.

k0nsult.cloud / ai-truth / ipIII / orchestrator / verify-v2

Verify v2 — weryfikacja hash + status podpisu (spec)

Verify v2 to rozszerzenie dzisiejszego weryfikatora integralności o dwie rzeczy: upload pliku (PDF/JSON/manifest) zamiast wklejania JSON-a oraz czytelny status podpisu obok statusu hasha. Ta strona jest jednocześnie dokumentem specyfikacji i uczciwym rejestrem tego, co z tego działa dziś, a co jest planowane. Nic tu nie udaje działającego uploadu, którego nie ma.

Orchestrator Verify (v1) Verify v2 Pentest→Board Pack Chain-of-custody Znane ograniczenia ← ipIII hub

Uczciwie, zanim czytasz dalej. LIVE jest dziś tylko weryfikacja integralności skrótu SHA-256 — dokładnie to, co robi /verify (wklej JSON, licz hash w przeglądarce). Upload pliku (PDF/JSON/manifest przez formularz) to ROADMAP — spec poniżej, kod nie istnieje. Podpis PAdES/TSA to również ROADMAP. Jedyny mechanizm integralności działający dziś ponad zwykły hash to HMAC integrity F2, i to w trybie shadow (liczony i logowany, nie egzekwowany blokująco) na środowisku staging — nie na produkcji bankowej.

Dwa warstwy weryfikacji: hash (dziś) i podpis (jutro).

Doktryna claim ≤ proof: pokazujemy dokładnie tyle funkcji, ile mamy kodem i testem. Hash SHA-256 dowodzi, że treść pakietu się nie zmieniła. To nie jest tożsame z dowodem, kto pakiet wystawił, ani z formalnym podpisem elektronicznym uznawanym prawnie. Verify v2 ma pokazywać oba te statusy obok siebie, żeby nikt nie mylił integralności z autentycznością.

DZIŚ: hash SHA-256→LIVE (jak /verify) · PLAN: upload pliku→parsowanie PDF/JSON/manifest→status podpisu PAdES/TSA→ROADMAP

Co Verify v2 weryfikuje — dziś i docelowo

Integralność hash LIVE

SHA-256 kanonicznego payloadu JSON liczony w przeglądarce (Web Crypto), porównany z zadeklarowanym package_sha256. Identyczny mechanizm jak w /verify. Zero zmian w tej części — to, co już działa, zostaje.

Upload pliku ROADMAP

Dziś operator musi ręcznie wkleić treść JSON-a. Plan: pole uploadu przyjmujące .pdf, .json lub manifest evidence-package, z ekstrakcją hasha po stronie klienta (bez wysyłki pliku na serwer). To spec, nie działający formularz.

Status podpisu PAdES/TSA ROADMAP

Docelowo strona ma pokazywać osobny wskaźnik: „podpisany (PAdES) / ze znacznikiem czasu (TSA) / brak podpisu". Dziś ten wskaźnik zawsze pokazywałby „brak podpisu wystawcy" — bo podpisu jeszcze nie generujemy. Zobacz rejestr w /known-limitations (pozycja „PDF", priorytet P1).

HMAC integrity F2 shadow

Osobny mechanizm z fali F2: HMAC podpisujący ładunek na potrzeby integralności transportowej, uruchomiony dziś w trybie shadow — liczony i logowany równolegle, bez blokowania ruchu przy niezgodności. To nie jest podpis PAdES ani zamiennik podpisu prawnego dokumentu; to wewnętrzna kontrola integralności warstwy transportowej na środowisku niebankowym.

Upload flow (spec, jeszcze nie kod)

Poniższy przebieg opisuje, jak ma wyglądać upload w Verify v2, gdy zostanie zbudowany. To specyfikacja MVP, nie dokumentacja działającej funkcji — żaden z poniższych kroków nie ma dziś odpowiadającego endpointu ani kodu klienckiego.

1. Wybór pliku — operator wskazuje plik .pdf, .json lub manifest evidence-package z dysku lokalnego. Plik nie opuszcza przeglądarki (ten sam model co dziś w /verify).

2. Rozpoznanie typu — po rozszerzeniu i sygnaturze pliku: JSON parsowany wprost; PDF wymaga wyodrębnienia osadzonego manifestu/metadanych (jeśli evidence-package eksportowany jako PDF zawiera JSON w załączniku); manifest traktowany jak dziś w /verify.

3. Liczenie hasha — identyczny mechanizm jak LIVE dziś: SHA-256 kanonicznego payloadu w crypto.subtle, bez wysyłki treści na serwer.

4. Odczyt statusu podpisu — jeśli plik zawiera pole podpisu (PAdES/TSA), strona pokazuje jego obecność i (docelowo) poprawność formalną. Dziś: pole nie istnieje w żadnym eksportowanym pakiecie, więc status będzie zawsze „brak podpisu".

5. Werdykt łączony — dwa niezależne pola wyniku: „integralność: ZGODNY/NIEZGODNY" (jak dziś) oraz „podpis: BRAK / OBECNY-niezweryfikowany / OBECNY-zweryfikowany" (nowe, dziś zawsze pierwsza wartość).

Podpis PAdES / TSA — dlaczego to osobna oś, nie „mały dodatek"

Hash SHA-256 odpowiada na pytanie „czy treść jest dokładnie taka, jak zadeklarowano". Podpis elektroniczny typu PAdES (PDF Advanced Electronic Signatures) i znacznik czasu TSA (RFC 3161) odpowiadają na inne pytanie: „kto to podpisał i kiedy, w sposób trudny do sfałszowania i uznawany formalnie". To dwie różne warstwy dowodu. Dzisiejszy stan ipIII:

Warstwa	Co dowodzi	Status	Gdzie
SHA-256 integralności	Treść pakietu nie została zmieniona względem policzonego skrótu	LIVE	/verify, ten sam mechanizm w Verify v2
HMAC integrity F2	Wewnętrzna kontrola spójności ładunku transportowego, tryb obserwacyjny	shadow	środowisko staging, nie produkcja bankowa
PAdES (podpis PDF)	Tożsamość wystawcy dokumentu, formalna wartość dowodowa	ROADMAP	brak kodu — pozycja P1 w /known-limitations
TSA (znacznik czasu RFC 3161)	Moment istnienia dokumentu potwierdzony przez zaufaną trzecią stronę	ROADMAP	brak kodu — razem z PAdES

Chain-of-custody — powiązanie z manifestem evidence

Każdy evidence-package zawiera pole chain_of_custody — listę zapisów porządkujących, które elementy dowodowe (evidence_id) trafiły do pakietu i w jakim statusie (MEDIA_SIGNAL vs CONFIRMED). To dziś jest zapis w bazie, nie kryptograficzny łańcuch podpisów — nazwa „chain-of-custody" opisuje porządek dowodowy (kto/co/kiedy dodał), a nie kryptograficzne powiązanie bloków. Szczegóły mechanizmu i jego granic: /chain-of-custody.

Co się zmienia, a co zostaje bez zmian

Bez zmian: mechanizm hasha z /verify (wklej JSON, licz SHA-256, porównaj) pozostaje dokładnie taki sam i dalej działa LIVE. Verify v2 go nie zastępuje — go rozszerza specyfikacją.

Nowe (ROADMAP): pole uploadu pliku zamiast wklejania tekstu, rozpoznanie PDF/JSON/manifest, oraz osobny wskaźnik statusu podpisu PAdES/TSA. Żadnego z tych trzech elementów nie ma dziś w kodzie — ta strona jest dokumentem specyfikacji (MVP) i rejestrem uczciwości, nie ogłoszeniem nowej funkcji.

Reguła statusów

Status	Znaczenie tutaj
LIVE	Weryfikacja hasha SHA-256 w przeglądarce — identyczna z /verify.
shadow	HMAC integrity F2 — liczony/logowany na staging, nie egzekwowany blokująco, nie na produkcji bankowej.
ROADMAP	Upload pliku, parsowanie PDF/manifest, status podpisu PAdES/TSA — spec bez kodu.

Granica etyczna i prawna. Ta strona nie jest poradą prawną co do wartości dowodowej podpisów elektronicznych ani deklaracją zgodności z konkretną normą. Legal Trigger Engine i wszelkie mapowania obowiązków to wsparcie decyzji (decision-support), nie porada prawna. Kwalifikację prawną dokumentu przed przekazaniem do organu wykonuje radca/kancelaria.

Powiązane: weryfikator produkcyjny hasha → /verify · generowanie pakietu z raportu pentestu → /pentest-report-board-pack · porządek dowodowy pakietu → /chain-of-custody · pełny rejestr ograniczeń → /known-limitations.