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 mojego wstępnego rekonesansu w maju 2006 wynika, że mamy obecnie co najmniej dwa działające produkcyjnie systemy faktur elektronicznych (EBF, 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 całkowicie 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.
Bezpieczny dokument elektroniczny (szkic projektu)
Administracja rządowa powinna określić obowiązujący i jednolity format kontenera bezpiecznego dokumentu elektronicznego. Kontenter jest jednym archiwum ZIP, zawierającym:
- treść dokumentu w XML w jednym pliku (powiedzmy content.xml) wg określonej formatki,
- warstwa prezentacyjna dokumentu w postaci CSS, XSL (xsl.xml),
- cokolwiek innego co jest wymagane przez treść/prezentację (grafiki, CSS), wg referencji w w/w plikach
- podpis elektroniczny wszystkich elementów, które tego wymagają (signatures.xml) w formacie XAdES,.
- samą definicję (XML Scheme) występujących w dokumencie treści. Uwaga: w jednym z komentarzy proponuje się rozdzielenie plików z podpisem na oddzielne fizycznie pliki, co ułatwi automatyczne przetwarzanie archiwum (podpis użytkownika w jednym pliku, podpis producenta formatki w drugim). Do dyskusji przez osoby piszące soft.
Formatki to tak na prawdę XMLScheme zawierające definicje konkretnych dokumentów:
- faktur elektronicznych (takie jak EDI-XML GS1 czy EBF),
- e-deklaracji,
- poświadczenia odbioru,
- rządowych publikacji elektronicznych (ustawy, interpretacje itd),
- czegokolwiek innego, co komu będzie potrzebne.
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.
<h3>Zalety</h3> <p>Zalety takiego ujednoliconego rozwiązania: </p> <ul><li> Oddzielenie prezentacji od treści - co jest ważne dla producentów systemów przetwarzających dane, dla których różnica między małym XML z treścią a dużym XML z treścią i prezentacją jest kluczowa. Przykład - aplikacja księgowa trzyma u siebie cały kontener, ale do systemu wysyła tylko XML z treścią i podpis - np. przez SOAP. </li><li> Wynikowy dokument jest self-embedded - krytyczne jeśli mówimy o formacie do publikacji lub przesyłania na odległość. Wynikowy kontenter jest self-embedded, więc jest niezależny od zewnętrznych XSLi czy grafik. Umieszczenie w dokumencie XML Scheme jest korzystne w przypadku archiwizacji dokumentu. </li><li> Całościowy dokument jest mały (kompresja ZIP) - zaleta dla wszystkich. </li><li> Uniwersalność i rozszerzalność - każdy kto potrzebuje może stworzyć własną formatkę np. nowego formularza lub nowej formy dokumentu. </li><li> Elastyczność biznesowa - do istniejącej formatki faktury firmy mogą tworzyć własne XSL z prezentacją, także aktywną, co umożliwia konkurencję, pełną integrację z systemami F-K i rozwija rynek. </li><li> Możliwość bezproblemowego dołączania dużych załączników binarnych - ważne np. dla instytucji takich jak ZUS. </li><li> Jednolity format dokumentów i interoperacyjność - wszystkie elektroniczne dokumenty są weryfikowane tak samo, cieszą się Urzędy Skarbowe, administracja publiczna i firmy. </li></ul> <div class="editsection" style="float: right; margin-left: 5px">
</div><h3>Warunki konieczne</h3> <p>Warunki konieczne aby wyżej wymienione zalety zadziałały: </p> <ul><li> Formatki muszą być rejestrowane centralnie, tryb do ustalenia przez osoby kompetentne. Na przykład jako PN lub w jakikolwiek inny sposób. Kluczowe jest to, by np. Urzędy Skarbowe miały obowiązek weryfikować tylko faktury zapisane wg zarejestrowanego formatu dla faktur elektronicznych, a formularze VAT-7 wg formatu zarejestrowanego dla VAT-7. W jednym z komentarzy proponowano by rejestracja ograniczała się do nadania formatce publicznego OID oraz dołączenia podpisu elektronicznego twórcy (co też wynika z wyżej wymienionych wymogów). </li></ul> <ul><li> Formatki zgłaszane do rejestracji muszą być wolne od ograniczeń licencyjnych, patentowych i innych, na zasadzie deklaracji składanej przez firmę lub instytucję składającą formatkę do rejestracji. Uwaga - dotyczy to tylko formatek (DTD/XML Scheme). </li></ul> <ul><li> Warstwa prezentacyjna (XSL) nie podlega tym ograniczeniom, ale równocześnie nie może być integralną częścią formatki. Chodzi o to żeby twórczą inwencję firm przełożyć właśnie do XSL, a nie zostawiać w treści dokumentu. Prezentacja może posiadać ograniczenia licencyjne, co umożliwia firmom, które stworzyły atrakcyjne dla rynku formy prezentacji zarabianie na tym. </li></ul> <div class="editsection" style="float: right; margin-left: 5px">
</div><h3>Bezpieczeństwo</h3> <p>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: </p> <ul><li> Formatka zawiera faktyczną treść dokumentu czy formularza. Na etapie podpisywania i weryfikacji istnieje więc możliwość pełnej prezentacji tego, co użytkownik faktycznie podpisuje. Prezentacji i podpisywaniu powinna wręcz podlegać sama wynikowa formatka z wypełnionymi danymi, po to by wyeliminować problemy wynikające ze stosowania np. aktywnych XSL. </li><li> Moc prawną ma kod XML a nie jego wizualizacja, która może być zrobiona przy pomocy różnych XSL. Musi to być wyraźnie zaznaczone, ponieważ firmy mogą tworzyć różne wizualizacje dla tego samego XML - np. nadawca faktury wizualizuje w XSL swojego programu F-K, a odbiorca - swojego. Niezaleźnie od tego patrz punkt kolejny. </li><li> Formatka zawiera referencję do konkretnego XSL, użytego do jej wypełnienia. Ponieważ formatka jest podpisana, więc istnieje logiczne powiązanie pomiędzy treścią a XSL użytym do jej stworzenia. Jest to warunek konieczny przy rozstrzyganiu sporów jako zabezpieczenia materiału dowodowego. </li><li> XML Scheme formatki jest podpisane przez producenta - np. w przypadku deklaracji przez odpowiednie ministerstwo. </li><li> Prezentacyjny XSL jest również podpisany, ale niekoniecznie przez użytkownika - chodzi o zapewnienie autentyczności XSL, więc XSL powinien być podpisany przez producenta. Użytkownik podpisuje tylko referencję do XSL w formatce. W rezultacie system teleinformatyczny otrzymujący małą formatkę może szybko sprawdzić, czy została ona wypełniona przez znane mu XSL. </li><li> Podpisane i powiązane przez referencje z formatką mogą być wszystkie dodatkowe elementy, na przykład binarne załączniki do dokumentu (skany dokumentów itd). </li></ul> <p>Dodatkowe zalety: </p> <ul><li> Format XAdES umożliwia realizację tej funkcjonalności od ręki. </li><li> Zaproponowany format kontenera ZIP umożliwia realizację tej funkcjonalności od ręki. </li><li> Format XAdES umożliwia precyzyjne określenie funkcji podpisu elektronicznego pod poszczególnymi elementami za pomocą polityk podpisu (Signature Policies). Rozwiązuje to w dużym stopniu palący obecnie problem niezaprzeczalności w certyfikatach kwalifikowanych. </li></ul> <div class="editsection" style="float: right; margin-left: 5px">
</div><h3>Aspekt międzynarodowy</h3> <p>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. </p> <div class="editsection" style="float: right; margin-left: 5px">
</div><h3>Aspekt biznesowy</h3> <p>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: </p> <ul><li> Standard jako rzecz publiczna musi być dostępny w sposób otwarty i za darmo. </li><li> Równocześnie musi się na nim dać zarabiać. </li><li> Musi być promowany lub opracowany we współpracy z Europą. </li></ul> <p>Opisana przeze mnie propozycja spełnia wszystkie te warunki. </p> <div class="editsection" style="float: right; margin-left: 5px">
</div><h3>Istniejące rozwiązania</h3> <p>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: </p> <ul><li> trzeba rozszerzyc ODF o formatki konkretnych dokumentów elektronicznych, </li><li> należy go dostosować do podpisu kwalifikowanego (wprowadzić profil XAdES). </li></ul> <p>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: </p> <ul><li> OpenOffice 2 "ODT" - OASIS OpenDocument, XML-DSIG, ZIP </li><li> MS Office 2007 beta "DOCX" - OpenXML, XML-DSIG, ZIP </li></ul> <p>PR za OpenDocument: </p> <ul><li> "Belgia sięga po otwarty format dokumentów" </li><li> OpenDocument Format w Microsoft Office plugin ODT dla MS Office </li><li> OpenXML Converter projekt konwertera ODF-OpenXML na licencji BSD uruchomiony przez… Microsoft </li><li> E-dokumenty rynek na fali "Rozwiązania do obsługi dokumentu elektronicznego są przede wszystkim stosowane przez europejską administrację publiczną i samorządową. Dodatkowo, rozszerzająca się Unia Europejska potrzebuje ogólnie akceptowanych standardów dokumentu elektronicznego, które mogłyby stosować administracje wszystkich krajów członkowskich" (Interia) </li></ul> <p>Analiza potrzeb formatu dokumentu elektronicznego przeprowadzona przez Stowarzyszenie PEMI: </p> <ul><li> E-paczka, czyli wysyłam dokumenty do e-urzędu </li></ul> <div class="editsection" style="float: right; margin-left: 5px">
</div><h2>Komentarze</h2> <p>Ten dokument jest prywatną opinią autora (Paweł Krawczyk) i nie jest na razie stanowiskiem żadnej organizacji lub firmy, z którą jestem związany. Celem jego publikacji jest zebranie komentarzy ze strony zainteresowanych podmiotów, uwzględnienie ich w kolejnych wersjach i na koniec wypracowanie propozycji, która będzie formalnie wyartykułowana przez środowisko IT jako propozycja dla administracji publicznej. Proszę o przekazywanie tego dokumentu wszystkim, którzy mogą być nim zainteresowani oraz przede wszystkim przesyłanie komentarzy. </p>