Oczekiwania wobec dokumentu elektronicznego

2007-05-23 00:00:00 +0100


Głównym problemem z jakim musimy się uporać w 2006 roku jest określenie formatu bezpiecznego dokumentu elektronicznego obowiązującego w administracji oraz zgodnej z ustawą o podpisie elekronicznym wymianie dokumentów w biznesie (e-faktury).

Z prywatnego rekonesansu w maju 2006 wynika, że mamy obecnie co najmniej dwa działające produkcyjnie systemy faktur elektronicznych (EBF i prywatny Winkhaus). Analogiczne prace prowadzi najmniej kilka kolejnych zespołów (m.in. EPL, Grupa: PWPW, Unizeto, KIR, ILiM, Stowarzyszenie PEMI). Wszystkie są prawie identyczne funkcjonalnie, ale niekompatybilne. Niepokojąco przypomina to sytuację z 2002 roku, kiedy cztery polskie centra certyfikacji z zapałem zabrały się do wdrażania czterech różnych standardów, co skończyło się chaosem na rynku. Tego błędu nie trzeba powtarzać.

W związku z tym Internet Society Polska postanowiło wystąpić z inicjatywą ujednolicenia formatu bezpiecznego dokumentu elektronicznego, co obejmie zbieranie informacji o potrzebach poszczególnych aplikacji, przekazywanie tych informacji do ciał standardyzacyjnych, koordynację wymiany infomracji oraz doradztwo techniczne w zakresie stosowanych standardów. Propozycja ta nie stoi w sprzeczności z już stworzonymi formatami, co wyniknie z dalszej lektury.

Administracja rządowa powinna określić obowiązujący i jednolity format kontenera bezpiecznego dokumentu elektronicznego. Kontenter jest jednym archiwum ZIP, zawierającym:

Formatki to tak na prawdę XMLScheme zawierające definicje konkretnych dokumentów:

Faktura elektroniczna zawierałaby więc content.xml sformatowany według XML Scheme określonego dla faktur elektronicznych, deklaracja VAT-7 - według XML Scheme dla deklaracji itd. W dokumencie zmieniałaby się tylko formatka i prezentacja, natomiast zewnętrzny format kontenera i elementów stąłych (podpis elektroniczny) pozostawałby ten sam.

Zalety

Zalety takiego ujednoliconego rozwiązania:

Warunki konieczne

Warunki konieczne aby wyżej wymienione zalety zadziałały:

Bezpieczeństwo

Rozdzielenie prezentacji (XSL) od treści (XML) nasuwa pytanie, czy to jest bezpieczne. Tak, jest, ponieważ rozdzielenie jest tylko w sensie podziału na odrębne pliki a dane pozostają w ścisłym związku logicznym:

Dodatkowe zalety:

Aspekt międzynarodowy

Te działania muszą być prowadzone w porozumieniu z odpowiednimi ciałami w Unii, żebyśmy nie stworzyli sobie lokalnego standardu. Równocześnie, jeśli uznamy że nasze rozwiązanie jest lepsze od istniejących w Unii to administracja musi aktywnie promować go na arenie europejskiej. Nie należy mieć tutaj żadnych kompleksów, bo istniejące rozwiązania unijne są równie funkcjonalne i interoperacyjne jak nasze obecne - czyli prawie wcale.

Aspekt biznesowy

W latach 90-tych Microsoft i Netscape toczyły słynne "wojny przeglądarek", które polegały na wzajemnym prześciganiu się w tworzeniu niekompatybilnych ale "fajnych" rozszerzeń do niby jednolitego standardu HTML. Rezultatem było istotnie wykluczenie Netscape z rynku przeglądarek, ale dla Microsoftu było to zwycięstwo okupione ogromnymi kosztami, a zwłaszcza frustracją użytkowników i absurdalnymi wymogami "do tego sklepu możesz wejść tylko MSIE 5.00.1.5 w rozdzielczości 800x600". Rezultat jest taki, że obecnie Microsoft jest jednym z najbardziej zdyscyplinowanych uczestników prac World Wide Web Consortium, pracujących nad jednolitymi standardami HTML, CSS itd.

Na tej kompatybilności zarabiają teraz wszyscy, a zasada neutralności technologicznej (braku uzależnienia od konkretnej implementacji) jest już normalnie osadzona w prawodawstwie unijnym i polskim.

Sytuacja podobna do "wojny przeglądarek" powtórzyła się u nas w latach 2002-2005 jeśli chodzi o Formaty podpisu elektronicznego, kiedy cztery polskie centra certyfikacji wprowadziły na rynek cztery niekompatybilne formaty podpisu. O ile w przypadku dwóch firm (MS i Netscape) wygrana jednej z nich była możliwa, w polskim przypadku była ona z góry skazana na porażkę. W sytuacji kiedy na rynku działają cztery podobnej wielkości firmy, żadna z nich nie ma żadnych szans na przeforsowanie swojego formatu bo pozostałe dysponują szerokim spektrum środków (protesty) by zablokować każdą próbę opanowania rynku (ustawianie SIWZ) i utrzymywać status quo na zasadzie "psa ogrodnika".

Rezultaty dla uczestników tej gry są widoczne od czterech lat i chyba nie trzeba ich komentować. Rezultatów dla rynku tym bardziej.

Rolę regulatora musi tutaj odegrać administracja publiczna, która wskaże jednolity standard wymiany dokumentów, spełniający następujące warunki:

Opisana przeze mnie propozycja spełnia wszystkie te warunki.

Istniejące rozwiązania

Opisany przeze mnie format prawie istnieje - jest to format kontenera dokumentów Open Document Format, wykorzystywany obecnie np. przez pakiet OpenOffice. ODF jest otwartym standardem opublikowanym przez grupę OASIS jako OpenDocument Format for Office Applications (OpenDocument) v1.0. Jeśli chodzi o podpis elektroniczny, to ODF korzysta z XML-DSIG. Oba formaty (OASIS ODF i XML-DSIG) są osadzone w polskim prawie, a konkretnie w Rozporządzeniu o minimalnych warunkach dla systemów teleinformatycznych i oba jako pełnoprawne (nie tylko read-only).

Wszystko świadczy więc na korzyść ODF. Co trzeba zrobić z ODF, żeby spełniał wyżej wymienione warunki:

Dodajmy, że z podobnego kontenera korzysta obecnie MS Office 2007 beta (DOCX), jest to również ZIP tylko XML w środku jest sformatowany wg MS OpenXML a nie OASIS OpenDocument. Gdyby ktoś chciał zobaczyć jak to wygląda w praktyce, to można pobrać dwa poniższe pliki podpisane przeze mnie - wystarczy rozpakować je programem WinRAR i zobaczyć jak wygląda w środku ich struktura:

PR za OpenDocument:

Analiza potrzeb formatu dokumentu elektronicznego przeprowadzona przez Stowarzyszenie PEMI: