ARF
ARF, czyli Architecture and Reference Framework, to techniczna specyfikacja ekosystemu portfela EUDI: przekłada to, czego eIDAS 2.0 wymaga w warstwie prawnej, na konkretne role, formaty poświadczeń, protokoły i infrastrukturę zaufania, które muszą zbudować wdrożeniowcy.
Jest utrzymywany przez Komisję Europejską wraz z państwami członkowskimi za pośrednictwem eIDAS Expert Group i publikowany w kolejnych wersjach, z których każda towarzyszy zestawowi specyfikacji technicznych i załączników obejmujących poszczególne tematy, takie jak zasady dotyczące PID, zaufanie i unieważnianie czy wymagania kryptograficzne portfela. ARF rozstrzyga kwestie, które rozporządzenie celowo pozostawia otwarte na poziomie szczegółowości potrzebnym wdrożeniowcom: że portfel używa OpenID4VCI do otrzymywania poświadczeń i OpenID4VP do ich przedstawiania, że PID i atestacje występują w formacie SD-JWT VC i ISO mdoc, jak portfel udowadnia wydawcy lub weryfikatorowi, że jest autentyczny, oraz jak zarejestrowani wydawcy i strony ufające są publikowani w krajowych rejestrach, aby druga strona mogła ich sprawdzić, zanim zaufa poświadczeniu. Jest rozwijany otwarcie na GitHubie, gdzie państwa członkowskie, branża i duże pilotaże, takie jak Potential i DC4EU, zgłaszają problemy i proponują zmiany, zanim wersja zostanie sfinalizowana, dlatego dokument stale ewoluuje, gdy te pilotaże ujawniają luki, których tekst nie przewidział. Osoby budujące dla EUDI Wallet czytają ARF, a nie rozporządzenie czy jego akty wykonawcze, aby poznać te szczegóły, ponieważ akty ustanawiają obowiązek prawny, a ARF ustala interoperacyjny sposób jego spełnienia. Portfel, wydawca czy weryfikator, który spełnia jedynie rozporządzenie bez stosowania się do technicznych wyborów ARF, nie współdziałałby z resztą ekosystemu, nawet gdyby był zgodny z prawem.
Powiązane terminy
Jak często zmienia się ARF?
ARF jest wydawany w kolejnych aktualizacjach, w miarę jak Komisja Europejska, państwa członkowskie i duże pilotaże, takie jak Potential i DC4EU, ujawniają luki lub niejasności podczas budowania rzeczywistych wdrożeń. Każda wersja dostarcza też specyfikacje techniczne i załączniki dla własnych tematów. Rozwój odbywa się otwarcie na GitHubie, dzięki czemu wdrożeniowcy mogą śledzić proponowane zmiany i zgłaszać problemy, zanim wersja zostanie sfinalizowana, zamiast budować na dokumencie, który nigdy nie zostaje poprawiony.