---

BILAGA

INNEHÅLLSFÖRTECKNING
KAPITEL 1:	Utbyte av DNA-uppgifter
1.	DNA-relaterade kriminaltekniska frågor, matchningsregler och algoritmer
1.1	DNA-profilernas egenskaper
1.2	Matchningsregler
1.3	Rapporteringsregler
2.	Tabell över medlemsstatskoder
3.	Funktionsanalys
3.1	Systemets tillgänglighet
3.2	Steg 2
4.	Dokument för gränssnittskontroll – DNA
4.1	Inledning
4.2	Definition av XML-strukturen
5.	Tillämpnings-, säkerhets, och kommunikationsarkitektur
5.1	Översikt
5.2	Högnivåarkitektur
5.3	Säkerhetsstandarder och dataskydd
5.4	Protokoll och standarder för krypteringsmekanismen: S/MIME och därmed sammanhörande paket
5.5	Tillämpningsarkitektur
5.6	Protokoll och standarder för tillämpningsarkitekturen
5.7	Kommunikationsmiljö
KAPITEL 2:	Utbyte av fingeravtrycksuppgifter (gränssnittskontrolldokument)
1.	Översikt av filinnehållet
2.	Postformat
3.	Logisk post typ 1: Filhuvud
4.	Logisk post typ 2: Beskrivande text
5.	Logisk post typ 4: Högupplösningsbild i gråskala
6.	Logisk post typ 9: Minutiaepost
7.	Post typ 13: Bilder av latenta avtryck med varierande upplösning
8.	Post typ 15: Bilder av handavtryck med varierande upplösning
9.	Bilagor till kapitel 2
9.1	ASCII-koder för avgränsare
9.2	Beräkning av alfanumeriskt kontrolltecken
9.3	Teckenkoder
9.4	Sammanfattning av transaktioner
9.5	Post typ 1 definitioner
9.6	Post typ 2 definitioner
9.7	Koder för gråskalekomprimering
9.8	E-postspecifikation
KAPITEL 3:	Utbyte av uppgifter i fordonsregister
1.	Gemensam uppsättning uppgifter för automatiserad sökning i fordonsregister
1.1	Definitioner
1.2	Sökning på fordon/ägare/innehavare
2.	Datasäkerhet
2.1	Översikt
2.2	Säkerhetsfunktioner i samband med meddelandeutbytet
2.3	Säkerhetsfunktioner utan samband med meddelandeutbytet
3.	Tekniska villkor för informationsutbytet
3.1	Allmän beskrivning av Eucaris-applikationen
3.2	Funktionella och icke funktionella krav
KAPITEL 4:	Utvärdering
1.	Utvärderingsförfarande i enlighet med artikel 20 (förberedelse av beslut enligt artikel 25.2 i beslut 2008/615/RIF)
1.1	Frågeformulär
1.2	Testkörning
1.3	Utvärderingsbesök
1.4	Rapport till rådet
2.	Utvärderingsförfarande enligt artikel 21
2.1	Statistik och rapport
2.2	Revidering
3.	Expertmöten

KAPITEL 1: Utbyte av DNA-uppgifter

1.   DNA-relaterade kriminaltekniska frågor, matchningsregler och algoritmer

1.1   DNA-profilernas egenskaper

DNA-profilen kan innehålla 24 talpar som representerar allelerna i 24 lokus som också används vid Interpols DNA-förfaranden. Benämningarna för dessa lokus framgår av följande tabell:

De sju gråmarkerade lokusen i den översta raden utgör både den nuvarande europeiska standarduppsättningen av lokus (ESS) och Interpols standarduppsättning av lokus (Issol).

Inklusionsregler:

De DNA-profiler som medlemsstaterna gör tillgängliga för sökning och jämförelse samt de DNA-profiler som sänds för sökning och jämförelse måste innehålla minst 6 fullständigt angivna ( 1 ) lokus och får innehålla ytterligare lokus eller tomma positioner beroende på tillgång. DNA-personprofiler måste innehålla minst 6 av de 7 ESS-lokusen. För att öka noggrannheten vid matchningen ska alla tillgängliga alleler lagras i den indexerade databasen med DNA-profiler och användas för sökning och jämförelse. Varje medlemsstat ska så snart det är praktiskt möjligt tillämpa varje ny ESS-lokus som antas av EU.

Blandade profiler är inte tillåtna, vilket gör att allel-värdena för varje lokus består av endast två tal. Vid homozygositet kan dessa tal vara lika för ett givet lokus.

Jokertecken och mikrovarianter ska behandlas enligt följande regler:

1.2   Matchningsregler

Jämförelsen av två DNA-profiler ska göras på grundval av de lokus för vilka ett par allelvärden är tillgängliga i båda DNA-profilerna. Minst 6 fullständigt angivna lokus (exklusive amelogenin) måste överensstämma mellan de två DNA-profilerna innan ett träffsvar ges.

Full överensstämmelse (Quality 1) definieras som en överensstämmelse där samtliga allelvärden är identiska för de jämförda lokus som finns både i den DNA-profil som används för sökningen och i den sökta DNA-profilen. Nära överensstämmelse definieras som en överensstämmelse där värdet för endast en av samtliga jämförda alleler skiljer sig mellan de två DNA-profilerna (Quality 2, 3 och 4). En nära överensstämmelse godtas endast om det finns minst 6 fullständigt angivna lokus med full överensstämmelse i de två jämförda DNA-profilerna.

Anledningen till en nära överensstämmelse kan vara

1.3   Rapporteringsregler

Både fulla överensstämmelser, nära överensstämmelser och ”inga träffar” ska rapporteras.

Överensstämmelserapporten ska sändas till den begärande nationella kontaktpunkten samt göras tillgänglig för den tillfrågade nationella kontaktpunkten (så att den kan uppskatta arten av och antal eventuella uppföljande begäranden om ytterligare personuppgifter och annan information med anknytning till den DNA-profil som svarar mot träffen i enlighet med artiklarna 5 och 10 i beslut 2008/615/RIF).

2.   Tabell över medlemsstatskoder

I enlighet med beslut 2008/615/RIF, används ISO 3166-1 tvåställiga bokstavskoder för att upprätta domännamn och andra konfigurationsparametrar som krävs för Prümtillämpningarna för utbyte av DNA-uppgifter via ett slutet nät.

De tvåställiga medlemsstatskoderna enligt ISO 3166-1 alpha-2 är följande:

3.   Funktionsanalys

3.1   Systemets tillgänglighet

En begäran om sökning enligt artikel 3 i beslut 2008/615/RIF bör nå den anropade databasen i kronologisk ankomstordning enligt vilken begäran sändes, medan svaren bör nå den anmodande medlemsstaten inom 15 minuter efter det att begäran inkom.

3.2   Steg 2

När en medlemsstat mottar en rapport om överensstämmelse ansvarar den nationella kontaktpunkten för en jämförelse mellan värdena i den profil som sänds som fråga och värdena i den profil/de profiler som har mottagits som svar i syfte att validera och kontrollera profilens bevisvärde. De nationella kontaktpunkterna kan ta direktkontakter i valideringssyfte.

Förfaranden för rättslig hjälp inleds efter det att en överensstämmelse mellan två profiler validerats, på grundval av ”fullständig överensstämmelse” eller ”nära överensstämmelse” under det automatiska sökningsförfarandet.

4.   Dokument för gränssnittskontroll – DNA

4.1   Inledning

4.1.1    Syfte

Detta kapitel anger kraven för informationsutbytet om DNA-profiler mellan samtliga medlemsstaters DNA-databassystem. Fälten i huvudet är specificerade speciellt för Prüm-utbytet av DNA-uppgifter och datadelen grundar sig på datadelen för DNA-uppgifter enligt XML-schemat för Interpols nätport för utbyte av DNA-uppgifter.

Uppgifterna utbyts genom SMTP (Simple Mail Transfer Protocol) med användning av en central e-postserver som ställs till förfogande av nätoperatören. XML-filen överförs som meddelandetext.

4.1.2    Omfattning

Detta dokument för gränssnittskontroll, ICD, rör endast e-postmeddelandets innehåll. Alla nätspecifika och e-postspecifika områden definieras på ett likartat sätt för att ge en gemensam teknisk grund för utbytet av DNA-uppgifter.

Detta inbegriper

4.1.3    XML-struktur och XML-principer

XML-meddelandet är indelat i

Samma XML-schema ska kunna användas för både begäran och svar.

För fullständiga kontroller av oidentifierade DNA-profiler (artikel 4 i beslut 2008/615/RIF) ska det vara möjligt att sända en uppsättning profiler i ett enda meddelande. Det maximala antalet profiler i ett meddelande måste fastställas. Detta antal är beroende av den maximala meddelandestorleken och ska fastställas efter val av e-postserver.

XML-exempel:

<?version="1.0" standalone="yes"?>

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> datastrukturen upprepas om fler än en profil sänds i (....) ett enda SMTP-meddelande, något som endast tillåts i fall enligt artikel 4

</datas>

</PRUEMDNA>

4.2   Definition av XML-strukturen

Följande definitioner medtas endast i dokumentationssyfte och för bättre läsbarhet, den faktiskt bindande informationen återfinns i en fil med XML-schemat (PRUEM DNA.xsd).

4.2.1    Specifikation PRUEMDNAx

Den innehåller följande fält:

4.2.2    Innehåll i huvudfältets struktur

Denna struktur beskriver XML-filhuvudet. Den innehåller följande fält:

Typ av data i meddelandet, värden

Struktur som beskriver medlemsstaten samt anger datum och tid för meddelandet. Den innehåller följande fält:

4.2.3    PRUEM-profiluppgifter, innehåll

Denna struktur beskriver XML-profilens datadel: Den innehåller följande fält:

Typ av data i meddelandet, värden:

Typ av data i meddelandet, värden:

Typ av data i meddelandet, värden:

Struktur som beskriver en DNA-profil. Den innehåller följande fält:

Struktur som innehåller Issol-lokus (Interpols standarduppsättning lokus). Den innehåller följande fält:

Struktur som innehåller övriga lokus. Den innehåller följande fält:

Struktur som beskriver ett lokus. Den innehåller följande fält:

5.   Tillämpnings-, säkerhets- och kommunikationsarkitektur

5.1   Översikt

Vid införandet av tillämpningar för utbyte av DNA-uppgifter inom ramen för beslut 2008/615/RIF ska ett gemensamt, på logisk nivå slutet, nät mellan medlemsstaterna användas. För att mer effektivt utnyttja detta gemensamma kommunikationsnät för att sända begäranden och ta emot svar ska begäranden om DNA- och fingeravtrycksuppgifter överföras asynkront i inkapslade SMTP-meddelanden. Av hänsyn till säkerhetskraven kommer S/MIME-mekanismen att användas som tillägg till SMTP-funktionerna för att upprätta en obruten säker tunnel i nätet.

Det redan fungerande systemet Testa (Trans European Services for Telematics between Administrations) har valts som kommunikationsnät för datautbytet mellan medlemsstaterna. Europeiska kommissionen ansvarar för närvarande för Testa. Eftersom de nationella DNA-databaserna och de nuvarande nationella anslutningspunkterna för Testa kan vara belägna på olika ställen i medlemsstaterna kan tillgång till Testa anordnas antingen

De protokoll och standarder som används vid införandet av tillämpningar enligt beslut 2008/615/RIF står i överensstämmelse med öppna standarder och uppfyller de kraven från dem som ansvarar för medlemsstaternas nationella säkerhet.

5.2   Högnivåarkitektur

Enligt beslut 2008/615/RIF ska varje medlemsstat göra sin DNA-databas tillgänglig för utbyte med och/eller sökning från andra medlemsstater i enlighet med ett standardiserat gemensamt dataformat. Arkitekturen bygger på kommunikationsmodellen alla-till-alla (any-to-any). Det finns ingen central server och inte heller någon centraliserad databas med DNA-profiler.

Figur 1: Topologi över utbyte av DNA-uppgifter

Medlemsstaterna ska iaktta de nationella rättsliga restriktionerna för medlemsstaternas webbplatser och kan också bestämma vilken typ av hårdvara och vilka program som bör användas för att konfigurera medlemsstatens webbplats för att iaktta kraven i beslut 2008/615/RIF.

5.3   Säkerhetsstandarder och dataskydd

Tre nivåer av säkerhetsklassning har övervägts och införts.

5.3.1    Datanivån

De DNA-profiluppgifter som tillhandahålls av varje medlemsstat måste utformas i enlighet med en gemensam standard för dataskydd så att den begärande medlemsstaten får ett svar som huvudsakligen anger TRÄFF eller ICKE-TRÄFF samt vid TRÄFF ett identifikationsnummer som inte innehåller några som helst personuppgifter. Den fortsatta undersökningen efter meddelande om TRÄFF kommer att genomföras på bilateral nivå i enlighet med de nationella rättsliga och organisatoriska föreskrifter som gäller vid respektive medlemsstats anläggning.

5.3.2    Kommunikationsnivån

Meddelanden som innehåller information om DNA-profiler (begäranden och svar) kommer att krypteras med senaste teknik, anpassad till öppna standarder, t.ex. S/MIME, innan de översänds till andra medlemsstaters anläggningar.

5.3.3    Transmissionsnivån

Alla krypterade meddelanden med DNA-profilinformation kommer att vidarebefordras till andra medlemsstaters anläggningar genom ett virtuellt privat tunnelsystem som på internationell nivå förvaltas av en tillförlitlig nätleverantör och med nationellt ansvar för de säkra länkarna till detta tunnelsystem. Det virtuella privata tunnelsystemet har ingen anslutning till det öppna Internet.

5.4   Protokoll och standarder för krypteringsmekanismen S/MIME och därmed sammanhörande paket

Den öppna standarden S/MIME, en vidareutveckling av den faktiska e-poststandarden SMTP, kommer att användas för att kryptera meddelanden med DNA-profilinformation. Protokollet S/MIME (version 3) ger möjlighet till signerade kvittenser, säkerhetsuppmärkning och säkra sändlistor på grundval av en kryptografisk meddelandestandard (Cryptographic Message Syntax, CMS), en specifikation från Internet Engineering Task Force (IETF) för meddelanden skyddade genom kryptering. Det kan användas för att digitalt signera, autentisera eller kryptera alla former av uppgifter i digital form.

Det certifikat som S/MIME-mekanismen använder måste överensstämma med X.509-standarden. För att se till att de gemensamma standarderna och förfarandena överensstämmer med andra Prüm-tillämpningar gäller följande regler för S/MIME-kryptering eller i samband med olika Cots-miljöer (Cots, färdigköpt allmänt tillgänglig produkt).

S/MIME-funktioner finns i de allra flesta moderna programpaket för e-post, bland annat Outlook, Mozilla Mail och Netscape Communicator 4.x och är interoperabla mellan alla viktigare programpaket för e-post.

S/MIME har valts som lämplig mekanism för dataskyddet på kommunikationsnivån eftersom den är lätt att införliva i den nationella infrastrukturen vid alla medlemsstaters anläggningar. För att på ett effektivare sätt och till lägre kostnader visa hur tekniken fungerar har dock den öppna standarden JavaMail API valts för prototypen till utbytet av DNA-uppgifter. JavaMail API erbjuder enkel kryptering och dekryptering av e-postmeddelanden med användning av S/MIME och/eller OpenPGP. Avsikten är att erbjuda ett enkelt och lättanvänt API för e-postkunder som vill sända och ta emot e-post i något av de två mest populära formaten för krypterade e-postmeddelanden. Därför är det tillräckligt med någon av de senaste tillämpningarna av JavaMail API för de krav som ställs i beslut 2008/615/RIF, t.ex. en produkt från Bouncy Castle JCE (Java Cryptographic Extension), som kommer att användas för tillämpningen av S/MIME för prototypen av utbytet av DNA-uppgifter mellan alla medlemsstater.

5.5   Tillämpningsarkitektur

Varje medlemsstat kommer att ge övriga medlemsstater en uppsättning standardiserade DNA-profiluppgifter som är anpassade till gällande dokument för gränssnittskontroll (Interface Control Document, ICD). Detta kan antingen göras genom en logisk visning av den enskilda nationella databasen eller genom att upprätta en fysiskt exporterad databas (indexerad databas).

De fyra huvuddelarna: E-postservern/S/MIME, tillämpningsservern, datastrukturområdet för hämtning/inmatning av uppgifter och registrering av inkommande/utgående meddelanden samt matchningsmotorn genomför tillämpningslogiken på ett produktoberoende sätt.

För att alla medlemsstater lätt ska kunna införliva dessa komponenter i sina respektive anläggningar har de specificerade gemensamma funktionerna införts genom öppna standarder och protokoll som varje medlemsstat själv kan välja med hänsyn till nationell IT-policy och nationella IT-föreskrifter. På grund av de oberoende funktioner som ska införas för att få tillgång till de indexerade DNA-profildatabaser som omfattas av beslut 2008/615/RIF kan varje medlemsstat fritt välja plattform för hårdvara och program, inklusive databas- och operativsystem.

En prototyp för utbytet av DNA-uppgifter har utarbetats och prövats med framgång på det befintliga gemensamma nätet. Version 1.0 har utnyttjats i produktionsmiljö och används för det löpande arbetet. Medlemsstaterna får använda den produkt som har utvecklats gemensamt men får också utveckla egna produkter. De gemensamma produktkomponenterna kommer att bevaras, anpassas och vidareutvecklas i enlighet med de förändrade kraven inom IT, kriminaltekniken och/eller polisfunktionerna.

Figur 2: Översikt av tillämpningstopologin

5.6   Protokoll och standarder för tillämpningsarkitekturen

5.6.1    XML

Vid utbytet av DNA-uppgifter kommer XML-schemat, som bifogas e-postmeddelanden enligt SMTP, att användas fullt ut. XML (Xtensible Markup Language) är ett av W3C rekommenderat allmänt markeringsspråk för att för särskilda ändamål skapa markeringsspråk som kan beskriva många olika former av uppgifter. En beskrivning av en DNA-profil som lämpar sig för utbyte mellan alla medlemsstater har utarbetats med hjälp av XML och XML-schemat i dokumentet för gränssnittskontroll.

5.6.2    ODBC

Open DataBase Connectivity tillhandahåller ett standardiserat programmeringsgränssnitt (Application Program Interface, API) som ger åtkomst till databashanterare, oberoende av programmeringsspråk, databassystem och operativsystem. ODBC har dock vissa nackdelar. Att hantera ett stort antal klienter kan innebära en mångfald drivrutiner och dynamiska länkbibliotek (DLL). Dessa komplikationer kan öka omkostnaderna för administration av systemet.

5.6.3    JDBC

Java DataBase Connectivity (JDBC) är ett programgränssnitt (API) for programmeringsspråket Java som definierar på vilket sätt en klient kan ha åtkomst till en databas. I motsats till ODBC kräver inte JDBC några särskilda DLL i den lokala persondatorn.

Affärslogiken för att bearbeta begäran om DNA-profiler och svar på dessa vid medlemsstaternas anläggningar beskrivs i följande diagram. Både flödet för begäran och flödet för svar växelverkar med ett neutralt dataområde bestående av olika datapooler med gemensam datastruktur.

Figur 3: Tillämpningens arbetsflöde vid medlemsstaternas anläggningar, översikt

5.7   Kommunikationsmiljö

5.7.1    Gemensamt kommunikationsnät: Testa och efterföljande infrastruktur

Tillämpningen för utbyte av DNA-uppgifter kommer att använda e-post, en asynkron mekanism, för att begära sökningar och ta emot svar mellan medlemsstaterna. Eftersom alla medlemsstater har minst en nationell anslutningspunkt till Testa-nätet kommer det nätet att användas för utbytet av DNA-uppgifter. Testa tillhandahåller ett antal mervärdestjänster via sitt e-postrelä. Infrastrukturen fungerar som värd för Testa-specifika e-postlådor och kan dessutom omfatta sändlistor och policy för dirigering. Detta gör att Testa kan användas som en clearingcentral för meddelanden som är adresserade till förvaltningar som är anslutna till EU-omfattande domäner. Mekanismer för viruskontroll kan också inrättas.

Relästationen för e-post i Testa är byggd på en maskinvaruplattform med hög tillgänglighet vid den centrala Testa-anläggningen och skyddas av en brandvägg. DNS-servern i Testa konverterar URL-strängar till IP-adresser så att adresseringsfrågorna inte berör användare och tillämpningar.

5.7.2    Säkerhetsfrågan

VPN-konceptet (Virtuellt Privat Nät) är genomfört inom ramen för Testa. Den teknik för Tag Switching som används för att bygga upp detta VPN kommer att utvecklas så att den är anpassad för den standard för MPLS (Multi-Protocol Label Switching) som har utarbetats av IETF (Internet Engineering Task Force).

MPLS kombinerar fördelarna med lager 3-routning och lager 2-switchning. Eftersom IP-adresserna inte analyseras vid överföringen i stamnätet, medför MPLS inte några begränsningar vad gäller IP-adresseringen.

Dessutom kommer e-postmeddelanden i Testa att skyddas av en krypteringsmekanism driven av S/MIME. Utan kännedom om nyckeln och utan rätt certifikat är det omöjligt att dekryptera meddelanden som sänds via nätet.

5.7.3    Protokoll och standarder för kommunikationsnätet

SMTP (Simple Mail Transfer Protocol) är en de facto-standard för överföring av e-post via Internet. SMTP är ett relativt enkelt textbaserat protokoll där man anger en eller flera mottagare och därefter överför meddelandetexten. SMTP använder TCP-port 25 enligt IETF:s specifikation. För att hitta SMTP-servern för en visst domännamn används DNS-informationen vid MX (Mail eXchange).

Eftersom detta protokoll till att börja med uteslutande grundade sig på ASCII-text, kunde det inte hantera binära filer särskilt bra. Standarder som MIME utarbetades för att koda binära filer för överföring med SMTP. Numera är de flesta SMTP-servrarna anpassade till vidareutvecklingarna 8BITMIME och S/MIME, vilket gör att binära filer kan överföras nästan lika enkelt som klartext. Bearbetningsreglerna för S/MIME beskrivs i S/MIME-avsnittet.

SMTP är ett push-protokoll som gör att meddelanden inte kan hämtas från en fjärrserver på begäran. För att göra detta måste postkunden använda POP3 eller IMAP. Man har beslutat att använda POP3-protokollet för utbytet av DNA-uppgifter.

De lokala e-postkunderna använder protokollet POP3 (Post Office Protocol, version 3), ett Internet-standardprotokoll för tillämpningslagret, för att hämta e-post från en fjärrserver via en TCP/IP-förbindelse. Genom att använda SMTP-protokollets profil för ”skicka” sänder e-postkunder meddelanden över Internet eller över ett företagsinternt nät. MIME används som standard för bilagor och icke-ASCII-text. Även om varken POP3 eller SMTP kräver MIME-formaterad e-post, kommer så gott som all e-post via Internet i MIME-format, vilket innebär att även POP-klienterna måste förstå och använda MIME. Hela kommunikationsmiljön enligt beslut 2008/615/RIF kommer därför att inkludera POP-komponenterna.

5.7.4    Tilldelning av nätadresser

Driftsmiljö

Testa har av den europeiska IP-registreringsmyndigheten (RIPE) redan tilldelats ett särskilt block av subnet-adresser av klass C. Ytterligare block av adresser kan senare komma att tilldelas Testa vid behov. Tilldelningen av IP-adresser till medlemsstaterna grundar sig på ett geografiskt mönster i Europa. Uppgiftsutbytet mellan medlemsstaterna inom ramen för beslut 2008/615/RIF genomförs i ett logiskt slutet IP-nät som omfattar hela Europa.

Testmiljö

För att tillhandahålla en väl fungerande miljö för den dagliga verksamheten i alla anslutna medlemsstater måste en testmiljö upprättas i det slutna nätet för nya medlemsstater som förbereder sitt deltagande. Ett blad med parametrar, bland annat IP-adresser, nätinställningar, e-postdomäner och användarkonton för tillämpningen har utarbetats och bör anslås vid dessa medlemsstaters anläggningar. En uppsättning pseudo-DNA-profiler för teständamål har också utformats.

5.7.5    Konfigurationsparametrar

Ett säkert e-postsystem har upprättats med användning av domänen eu-admin.net. Denna domän kommer inte att kunna nås från en plats som inte ingår i den EU-omfattande Testa-domänen, eftersom namnen endast är kända på Testas centrala DNS-server, som är skyddad från Internet.

Mappningen av dessa webbplatsadresser (värdnamn) till motsvarande IP-adresser sköts genom DNS-tjänsten i Testa. För varje lokal domän kommer ett postobjekt att läggas till på Testas centrala DNS-server, varifrån alla e-postmeddelanden från Testas lokala domäner skickas vidare till Testas centrala postrelä. Det centrala postrelät kommer därefter att vidarebefordra dem till den specifika lokala domänens e-postserver och använda de lokala domänernas e-postadresser. Genom att skicka vidare e-posten på detta sätt kommer kritisk information i e-postmeddelandena endast att passera den EU-omfattande slutna nätinfrastrukturen, inte det osäkra Internet.

Subdomäner ( fet kursiv stil ) enligt följande syntax måste upprättas för alla medlemsstaters anläggningar:

” typ_av_tillämpning.pruem. medlemsstatskod.eu-admin.net ”, där

värdet för ” medlemsstatskod ” är en av de tvåställiga bokstavskoderna för medlemsstaterna (dvs. ”AT”, ”BE” etc.), och

värdet för ” typ_av_tillämpning ” är antingen DNA eller FP.

Med denna syntax blir medlemsstaternas subdomäner följande:

KAPITEL 2: Utbyte av fingeravtrycksuppgifter (gränssnittskontrolldokument)

Syftet med följande gränssnittskontrolldokument är att fastställa kraven för utbytet av fingeravtrycksuppgifter mellan AFIS-systemen i medlemsstaterna (Automated Fingerprint Identification Systems). Det grundar sig på Interpols implementation av ANSI/NIST-ITL 1-2000 (INT-I, version 4.22b).

Denna version ska omfatta alla grundläggande definitioner för de logiska posterna av typ 1, typ 2, typ 4, typ 9, typ 13 och typ 15 som krävs för bearbetning av fingeravtrycken utgående från bilder och minutiae.

1.   Översikt av filinnehållet

En fingeravtrycksfil består av flera logiska poster. I den ursprungliga standarden ANSI/NIST-ITL 1-2000 specificeras 16 posttyper. Lämpliga ASCII-avgränsare sätts in mellan posterna och mellan fält och delfält i posterna.

Endast sex posttyper används för att utbyta uppgifter mellan det sändande och det mottagande organet.

1.1   Typ 1 – Filhuvud

Denna post innehåller routningsinformation och information som beskriver strukturen i resten av filen. Denna posttyp definierar också transaktionstypen, som ingår i någon av följande övergripande kategorier:

1.2   Typ 2 – Beskrivande text

Denna post innehåller informerande text av intresse för det sändande och det mottagande organet.

1.3   Typ 4 – Högupplöst bild i gråskala

Denna post används för att utbyta högupplösta fingeravtrycksbilder i gråskala (8 bitar) som skannats med upplösningen 500 pixel/tum. Fingeravtrycksbilderna ska komprimeras med WSQ-algoritmen i ett förhållande som inte överstiger 15:1. Andra komprimeringsalgoritmer eller okomprimerade bilder får inte användas.

1.4   Typ 9 – Minutiaepost

Posttyp 9 används för att utbyta karakteristiska papillarmönster eller uppgifter om minutiae. De tjänar dels till undvika onödig dubblering av AFIS-kodningsprocesserna, dels till att göra det möjligt att överföra AFIS-koder som innehåller färre uppgifter än motsvarande bilder.

1.5   Typ 13 – Latenta bilder med varierande upplösning

Denna post ska användas för att utbyta bilder av latenta fingeravtryck och handavtryck tillsammans med alfanumerisk textinformation. Bilder ska vara skannade med upplösningen 500 pixel/tum i 256 nivåer av grått. Om den latenta bildens kvalitet tillåter det, ska den komprimeras med WSQ-algoritmen. Om så behövs får, efter ömsesidig överenskommelse, bildernas upplösning ökas så att den överskrider 500 pixel/tum och gråskalan utvidgas till fler än 256 nivåer. I detta fall bör man absolut använda JPEG 2000 (se bilaga 7).

1.6   Post för handavtrycksbild med varierande upplösning

Poster av typ 15 med taggade fält ska användas för att utbyta handavtrycksbilder med varierande upplösning tillsammans med alfanumerisk textinformation. Bilder ska vara skannade med upplösningen 500 pixel/tum i 256 nivåer av grått. För att minimera datamängderna ska alla handavtrycksbilder komprimeras med WSQ-mekanismen. Om så behövs får, efter ömsesidig överenskommelse, bildernas upplösning ökas så att den överskrider 500 pixel/tum och gråskalan utvidgas till fler än 256 nivåer. I detta fall bör man absolut använda JPEG 2000 (se bilaga 7).

2.   Postformat

En transaktionsfil ska bestå av en eller flera logiska poster. I varje logisk post i filen ska det finnas flera fält med information associerad med posttypen i fråga. Varje informationsfält kan innehålla en eller flera grundläggande uppgifter som var och en representeras av endast ett värde. Sammantagna används dessa uppgifter för att förmedla olika aspekter av informationen i fältet. Ett informationsfält kan också bestå av en eller flera grupperade uppgifter som upprepas flera gånger inom fältet. En sådan grupp av uppgifter kallas delfält. Ett informationsfält kan därför bestå av ett eller delfält med uppgifter.

2.1   Informationsavgränsare

I de logiska posterna med taggade fält skiljs de olika informationskomponenterna från varandra med hjälp av fyra informationsavgränsare i ASCII-kod. De på så sätt avgränsade informationskomponenterna kan vara uppgifter inom ett fält eller ett delfält, fält i en logisk post eller de olika förekomsterna av delfält. Dessa informationsavgränsare definieras i ANSI X3.4-standarden. Dessa tecken används för att avgränsa och kvalificera information i logisk mening. Sedda i hierarkisk ordning uppifrån och ner är filavgränsningstecknet ”FS” den mest inklusiva avgränsaren, följd av gruppavgränsaren ”GS”, postavgränsaren ”RS” och sist enhetsavgränsningstecknet ”US”. Dessa ASCII-avgränsare, och hur de används inom ramen för denna standard, beskrivs i tabell 1.

Informationsavgränsarna bör ur funktionell synpunkt ses som en anvisning om vilken typ av information som följer efter avgränsaren. US-tecknet ska avgränsa olika enskilda uppgifter inom ett fält eller ett delfält. Det är en signal om att nästa uppgift är en informationskomponent inom det fältet eller delfältet. Flera olika delfält inom ett fält avgränsade med RS-tecknet signalerar början av nästa grupp av upprepade uppgifter. Avgränsningstecknet GS mellan informationsfält signalerar början av ett nytt fält och ska föregå det fältidentifikationsnummer som ska finnas. På liknande sätt ska början av en ny logisk post signaleras av FS-tecknet.

De fyra tecknen är endast meningsfulla när de används som avgränsare av informationskomponenter i fält i poster med ASCII-text. Dessa tecken har ingen särskild betydelse när de förekommer i binära bildposter och binära fält – de ingår då endast i de utbytta uppgifterna.

Det ska normalt inte finnas tomma fält eller uppgifter, och därför bör det endast förekomma ett avgränsningstecken mellan två uppgifter. Undantaget från denna regel inträffar till exempel när data i ett fält eller uppgifter i en transaktion inte är tillgängliga, saknas eller är frivilliga, och bearbetningen av transaktionen inte är beroende av att dessa specifika data finns att tillgå. I dessa fall ska flera och angränsande avgränsningstecken förekomma tillsammans, snarare än att uppgifter utan betydelse infogas mellan avgränsningstecknen.

Följande gäller för definitionen av ett fält som består av tre uppgifter. Om information för den andra uppgiften saknas, kommer två angränsande US-avgränsare att förekomma mellan den första och den tredje uppgiften. Om både den andra och den tredje uppgiften saknades, skulle tre avgränsningstecken användas – två US-tecken förutom den avslutande fält- eller delfältsavgränsaren. Allmänt sett gäller att om en eller flera obligatoriska eller frivilliga uppgifter inte finns att tillgå för ett fält eller ett delfält, ska det relevanta antalet avgränsningstecken infogas.

Det är möjligt att ha kombinationer med två eller flera av de fyra tillgängliga avgränsningstecknen gränsande till varandra. Om data saknas eller inte finns att tillgå för uppgifter, delfält eller fält, måste det förekomma ett avgränsningstecken mindre än antalet erforderliga uppgifter, delfält eller fält.

2.2   Postformat

I logiska poster med taggade fält ska varje informationsfält som används numreras i enlighet med följande standard. Varje fält ska formateras så att det består av typnummer för den logiska posten följt av punkt ”.”, ett fältnummer följt av kolon ”:”, följt av den för detta fält relevanta informationen. Fältnumret för det taggade fältet kan vara ett godtyckligt en- till niosiffrigt nummer som förekommer mellan punkt ”.” och kolon ”:”. Det ska tolkas som ett fältnummer i positivt heltal. Detta innebär att ett fältnummer ”2 123:” är lika med och ska tolkas på samma sätt som ett fältnummer ”2.000000123:”.

I exemplifierande syfte används i hela detta dokument ett treställigt tal för numrering av de fält som ingår de logiska poster med taggade fält som beskrivs i dokumentet. Fältnummer får formatet ”TT.xxx:” där ”TT” representerar posttypen med ett eller två tecken följt av en punkt. De följande tre tecknen innehåller det relevanta fältnumret som följs av ett kolon. Efter kolon följer ASCII-information eller bilddata.

Logiska poster av typ 1 eller typ 2 innehåller endast datafält med ASCII-text. Den totala postlängden (inklusive fältnummer, kolon och avgränsningstecken) ska anges i det första ASCII-fältet i båda dessa posttyper. ASCII-filavgränsaren ”FS” (anger slutet av den logiska posten eller transaktionen) ska följa efter den sista positionen ASCII-information och inkluderas i postlängden.

I motsats till konceptet med taggade fält innehåller poster av typ 4 endast binära data som registrerats i form av ordnade binära fält med fast längd. Den totala postlängden ska anges i det första fältet om fyra positioner i varje post. I denna binära post ska varken postnumret med sin efterföljande punkt eller fältnumret med efterföljande kolon anges. Eftersom alla fältlängder i denna posttyp antingen är fasta eller specificerade, ska inget av de fyra avgränsningstecknen (”US”, ”RS”, ”GS”, eller ”FS”) tolkas som någonting annat än binära data. FS-tecknet ska inte användas som post- eller transaktionsavgränsare i den binära posten.

3.   Logisk post typ 1: Filhuvud

Denna post beskriver filens struktur och typ samt innehåller annan viktig information. De tecken som används för fält i logiska poster av typ 1 ska endast utgöras av den 7-bitars ANSI-koden för informationsutbyte.

3.1   Fält i logisk post typ 1

3.1.1    Fält 1.001: Logisk postlängd (Logical Record Length – LEN)

I detta fält anges det totala antalet byte i hela den logiska posten av typ 1. Fältet inleds med ”1 001:” följt av den totala postlängden, inklusive alla tecken i alla fält och informationsavgränsarna.

3.1.2    Fält 1.002: Versionsnummer (Version number – VER)

För att säkerställa att användarna känner till vilken version av ANSI/NIST-standarden som används, anges i detta fält versionsnumret för den standard som används av det program eller system som har skapat filen. I de första två positionerna anges versionsnumret, i de två följande revisionsnumret. Den ursprungliga standarden från 1986 skulle till exempel anses som den första versionen och anges som ”0100”, medan den nuvarande standarden ANSI/NIST-ITL 1-2000 anges som ”0300”.

3.1.3    Fält 1.002: Fältinnehåll (File Content – CNT)

I detta fält förtecknas varje post i filen efter posttyp och i den ordning i vilken de förekommer i den logiska filen. Det består av ett eller flera delfält, som vart och ett i sin tur innehåller två uppgifter som beskriver en logisk post som förekommer i den aktuella filen. Delfälten registreras i samma ordning som den i vilken posterna registreras och överförs.

Den första uppgiften i det första delfältet är ”1”, vilket hänvisar till denna post av typ 1. Den följs av en andra uppgift om antalet andra poster som förekommer i filen. Detta antal är också lika med antal återstående delfält i fält 1.003.

Vart och ett av de återstående delfälten är förknippat med en post i filen och sekvensen av delfält svarar mot sekvensen av poster. Varje delfält innehåller två uppgifter. Den första uppgiften identifierar posttypen. Den andra uppgiften är postens IDC. US-tecknet ska användas för att avgränsa de två uppgifterna.

3.1.4    Fält 1.003: Transaktionstyp (Type of Transaction – TOT)

Detta fält innehåller en treställig minneskod som anger transaktionstypen. Dessa koder kan skilja sig från dem som används i andra implementationer av ANSI/NIST-standarden.

CPS: Criminal Print-to-Print Search. Transaktionen är en begäran om sökning med en post i anslutning till ett brott mot en avtrycksdatabas. Personens avtryck måste inkluderas i filen som WSQ-komprimerade bilder.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

Vid TRÄFF kommer följande logiska poster att returneras:

Transaktionstypen CPS sammanfattas i tabell A.6.1 (bilaga 6).

PMS: Print-to-Latent Search. Denna transaktion används när en uppsättning avtryck ska användas för sökning mot en databas med oidentifierade latenta avtryck. Svaret kommer att innehålla Träff/Icke-träff-avgörandet vid den avsedda AFIS-sökningen. Om det finns flera oidentifierade latenta avtryck, kommer flera SRE-transaktioner att returneras med ett latent avtryck per transaktion. Personens avtryck måste inkluderas i filen som WSQ-komprimerade bilder.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

Vid TRÄFF kommer följande logiska poster att returneras:

Transaktionstypen PMS sammanfattas i tabell A.6.1 (bilaga 6).

MPS: Latent-to-Print Search. Denna transaktion används när ett latent avtryck ska användas för sökning mot en avtrycksdatabas. Den latenta minutiaeinformationen och bilden (WSQ-komprimerad) måste ingå i filen.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

Vid TRÄFF kommer följande logiska poster att returneras:

Transaktionstypen MPS sammanfattas i tabell A.6.4 (bilaga 6).

MMS: Latent-to-Latent Search. För denna transaktion innehåller filen ett latent avtryck som ska användas för sökning mot en databas med oidentifierade latenta avtryck i syfte att ta konstatera kopplingar mellan olika brottsplatser. Den latenta minutiaeinformationen och bilden (WSQ-komprimerad) måste ingå i filen.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

Vid TRÄFF kommer följande logiska poster att returneras:

Transaktionstypen MMS sammanfattas i tabell A.6.4 (bilaga 6).

SRE: Denna transaktion returneras av bestämmelseorganet som svar på begäran om fingeravtrycksundersökningar. Svaret kommer att innehålla Träff/Icke-träff-avgörandet vid den avsedda AFIS-sökningen. Om det finns flera kandidater, kommer flera SRE-transaktioner att returneras med en kandidat per transaktion.

Transaktionstypen SRE sammanfattas i tabell A.6.2 (bilaga 6).

ERR: Denna transaktion returneras av det avsedda AFIS-systemet för att ange ett fel vid bearbetningen av transaktionen. Den innehåller ett meddelandefält (ERM) som anger vilket fel som har upptäckts. Följande logiska poster kommer att returneras:

Transaktionstypen ERR sammanfattas i tabell A.6.3 (bilaga 6).

Nyckel:

M

=

Obligatorisk

M*

=

Endast en av båda posttyperna får ingå

O

=

Frivillig

C

=

Beroende av tillgängliga uppgifter

–

=

Ej tillåten

1*

=

Beroende av legacy systems

3.1.5    Fält 1.005: Transaktionsdatum (Date of Transaction – DAT)

Detta fält anger vilken dag transaktionen initierades och måste följa ISO-standarden YYYYMMDD

där YYYY är året, MM är månaden och DD är dagen i månaden. Ledande nollor ska användas för ensiffriga tal. ”19931004” står till exempel för den 4 oktober 1993.

3.1.6    Fält 1.006: PRIORITET (Priority – PRY)

Detta frivilliga fält anger prioritet, på en nivå 1–9, för begäran. ”1” anger högsta prioritet, ”9” lägsta prioritet. Prioritet ”1” ska behandlas omedelbart.

3.1.7    Fält 1.007: Bestämmelseorgansidentifierare (Destination Agency Identifier – DAI)

Detta fält anger transaktionens bestämmelseorgan.

Det består av två uppgifter i följande format: CC/organ.

Den första uppgiften består av en landskod om två alfanumeriska tecken enligt ISO 3166. Den andra uppgiften, organ, identifierar organet genom en sträng fri text om maximalt 32 alfanumeriska tecken.

3.1.8    Fält 1.008: Ursprungsorgansidentifierare (Originating Agency Identifier – ORI)

Detta fält anger vilket organ som har skapat filen och har samma format som DAI (fält 1.007).

3.1.9    Fält 1.009: Transaktionskontrollnummer (Transaction Control Number – TCN)

Detta är ett kontrollnummer för hänvisningsändamål. Det bör skapas av datorn och ha följande format: YYSSSSSSSSA

där YY är år för transaktionen, SSSSSSSS är ett åttaställligt serienummer och A är ett kontrolltecken som har genererats med den procedur som anges i bilaga 2.

Om TCN inte är tillgängligt, ska fältet YYSSSSSSSS fyllas med nollor och det kontrolltecken som genererats enligt ovan.

3.1.10    Fält 1.010: Transaktionskontrollsvar (Transaction Control Response – TCR)

När en begäran har sänts med denna post som svar, innehåller detta frivilliga fält Transaction Control Number (TCN) för meddelandet med begäran. Det har därför samma format som TCN (fält 1.009).

3.1.11    Fält 1.011: (Native Scanning Resolution – NSR)

Detta fält anger den normala upplösningen vid skanning för det system som avsändaren av transaktionen använder. Upplösningen ska anges med två siffror följd av decimalpunkt och därefter ytterligare två siffror.

För alla transaktioner i enlighet med beslut 2008/615/RIF ska samplingsfrekvensen vara 500 pixel/tum eller 19,68  pixel/mm.

3.1.12    Fält 1.012: Nominell överföringsresolution (Nominal Transmitting Resolution – NTR)

Detta fält om fem positioner anger nominell överföringsupplösning för de bilder som överförs. Upplösningen ska uttryckas i pixel/mm i samma format som NSR (fält 1.011).

3.1.13    Fält 1.013: Domännamn (Domaine Name – DOM)

I detta obligatoriska fält anges domännamnet för den användardefinierade implementationen av logisk post typ 2. Det innehåller två uppgifter och ska uttryckas som ”INT-I{US}4.22{GS}”.

3.1.14    Fält 1.014: Greenwich Mean Time (GMT)

Detta obligatoriska fält ger möjlighet att uttrycka datum och tidpunkt i GMT-enheter (Greenwich Mean Time). Om det används innehåller GMT-fältet universellt datum i tillägg till det lokala datum som anges i fält 1.005 (DAT). Om GMT-fältet används elimineras inkonsekvenser med lokal tid när en transaktion och dess svar överförs mellan två platser skilda åt av flera tidszoner. GMT ger ett universellt datum och en 24-timmarstid som är oberoende av tidszoner. Fältet anges som ”CCYYMMDDHHMMSSZ”, en 15-positioners teckensträng som utgörs av datum konkatenerat med GMT och avslutas med ”Z”. Tecknen ”CCYY” ska representera år för transaktionen, tecknen ”MM” ska ange tiotals- och entalssiffran för månad, tecknen ”DD” ska ange tiotals- och entalssiffran för dag i månaden, tecknen ”HH” ska ange timme, ”MM” ska ange minut och ”SS” ska ange sekund. Den fullständiga tidsangivelsen får inte ange en tidpunkt i framtiden.

4.   Logisk post typ 2: Beskrivande text

Större delen av denna posts struktur definieras inte genom den ursprungliga ANSI/NIST-standarden. Posten innehåller information av särskilt intresse för de organ som sänder eller tar emot filen. För att säkerställa att de kommunicerande fingeravtryckssystemen är kompatibla kräver detta ICD att posten innehåller endast de fält som förtecknas nedan. I dokumentet anges vilka fält som är obligatoriska frivilliga, samtidigt som de enskilda fältens struktur fastställs.

4.1   Fält i logisk post typ 2

4.1.1    Fält 2.001: Logisk postlängd (Logical Record Length – LEN)

Detta obligatoriska fält anger längden av typ 2-posten i totalt antal byte, inklusive varje tecken i varje fält och informationsavgränsarna.

4.1.2    Fält 2.002: Bilddesigneringstecken (IDC)

Den IDC som anges i detta obligatoriska fält är en ASCII-representation av den IDC som definieras i fältet File Content i typ 1-posten.

4.1.3    Fält 2.003: Systeminformation (System Information – SYS)

Detta fält om fyra positioner är obligatoriskt och anger vilken version av INT-I som just denna typ 2-post följer.

I de första två positionerna anges versionsnumret, i de två följande revisionsnumret. Denna implementation grundar sig till exempel på INT-I version 2 revision 22, vilket ska uttryckas som ”0422”.

4.1.4    Fält 2.007: Ärendenummer (Case Number – CNO)

Detta är ett nummer som av det lokala fingeravtrycksorganet tilldelas en samling latenta avtryck som hittas på brottsplatsen. Följande format ska användas: CC/nummer

där ”CC” är Interpols landskod med två alfanumeriska tecken och nummer följer de relevanta lokala riktlinjerna och kan bestå av upp till 32 alfanumeriska tecken.

Genom detta fält kan systemet identifiera latenta avtryck förknippade med ett visst brott.

4.1.5    Fält 2.008: Sekvensnummer (Sequence Number – SQN)

Detta specificerar varje sekvens av latenta avtryck inom ett fall. Det kan innehålla upp till fyra numeriska tecken. En sekvens är ett latent avtryck eller serier av latenta avtryck som förs samman i grupper för registrering och/eller sökning. Denna definition medför att även enskilda latenta avtryck måste tilldelas ett sekvensnummer.

Detta fält kan tillsammans med MID (fält 2.009) användas för att identifiera ett särskilt latent avtryck i sekvensen.

4.1.6    Fält 2.009: Latentavtrycksidentifierare (Latent Identifier – MID)

Detta fält specificerar det enskilda latenta avtrycket inom en sekvens. Värdet är en eller två bokstäver där ”A” tilldelas det första latenta avtrycket, ”B” tilldelas det andra och så vidare upp till gränsen ”ZZ”. Fältet används på samma sätt som sekvensnumret för det latenta avtrycket enligt beskrivningen av SQN (fält 2.008).

4.1.7    Fält 2.010: Brottsreferensnummer (Criminal Reference Number – CRN)

Detta är ett unikt referensnummer som ett nationellt organ tilldelar en person när denna för första gången döms för att ha begått ett brott. I ett visst land har en person aldrig mer än ett CRN, eller delar det med en annan person. Samma person kan emellertid ha Criminal Reference Numbers i flera länder, dessa kan då skiljas åt med hjälp av landskoden.

CRN-fältet ska ha följande format: CC/nummer

där ”CC” är landskod med två alfanumeriska tecken enligt ISO 3166 och nummer följer relevanta nationella riktlinjer från det utfärdande organet och kan bestå av upp till 32 alfanumeriska tecken.

I transaktioner i enlighet med beslut 2008/615/RIF kommer detta fält att användas för nationellt Criminal Reference Number från det organ som är kopplat till bilderna i poster av typ 4 eller typ 15.

4.1.8    Fält 2.012: (Miscellaneous Identification Number – MN1)

Detta fält innehåller det CRN (fält 2.010) som sänts med en CPS- eller PMS-transaktion, utan inledande landskod.

4.1.9    Fält 2.013: (Miscellaneous Identification Number – MN2)

Detta fält innehåller det CRO (fält 2.007) som sänts med en MPS- eller MMS-transaktion, utan inledande landskod.

4.1.10    Fält 2.014: (Miscellaneous Identification Number – MN3)

Detta fält innehåller det SQN (fält 2.008) som sänts med en MPS- eller MMS-transaktion.

4.1.11    Fält 2.015: (Miscellaneous Identification Number – MN4)

Detta fält innehåller det SQN (fält 2.009) som sänts med en MPS- eller MMS-transaktion.

4.1.12    Fält 2.063: Tilläggsinformation (Additional Information – INF)

Vid en SRE-transaktion efter en PMS-begäran informerar detta fält om vilket finger som gav anledning till den eventuella träffen. Fältet ska ha följande format:

NN där NN är den tvåställiga fingerpositionskod som definieras i tabell 5.

I alla övriga fall är detta fält frivilligt. Det består av upp till 32 alfanumeriska tecken och kan användas för att lämna ytterligare upplysningar om begäran.

4.1.13    Fält 2.064: (Respondents List – RLS)

Detta fält innehåller minst två delfält. Det första delfältet beskriver den typ av sökning som har gjorts med användning av den treställiga minneskod som specificerar transaktionstypen i TOT-fältet (fält 1.004). Det andra delfältet består av endast ett tecken. ”I” ska användas för att ange en TRÄFF, och ”N” ska användas för att ange att inga överensstämmelser har hittats (ICKE-TRÄFF). Det tredje delfältet innehåller sekvensidentifieraren för kandidatresultatet och totalt antal kandidater, avgränsat med snedstreck. Flera meddelanden kommer att returneras om det finns fler än en kandidat.

Vid en eventuell TRÄFF ska fjärde delfältet innehålla träffvärdet med upp till tio siffror. Om TRÄFFen har verifierats ska värdet för detta delfält definieras som ”999999”.

Exempel: ”CPS{RS}I{RS}001/001{RS}999999{GS}”

Om det AFIS till vilket transaktionen sänds inte tilldelar träffvärden, ska träffvärdet noll föras in på rätt plats.

4.1.14    Fält 2.074: Fält för status- och felmeddelanden (Status/Error Message Field – ERM)

Detta fält innehåller felmeddelanden vid transaktionsbearbetningen, vilka sänds tillbaka till den begärande parten som del av en feltransaktion.

Felmeddelanden i intervallet 100–199:

Dessa felmeddelanden gäller kontrollen av ANSI/NIST-posterna och ska uttryckas som

<error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF

<error_code 2>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF

där

Exempel:

201: IDC - 1 FIELD 1 009 FEL KONTROLLTECKEN {LF} 115: IDC 0 FIELD 2 003 OGILTIG SYSTEMINFORMATION

Detta fält är obligatoriskt för feltransaktioner.

4.1.15    Fält 2.320: Förväntat antal kandidater (Expected Number of Candidates – ENC)

Detta fält anger det maximala antal kandidater för kontroll som det begärande organet förväntar sig. Värdet ENC får inte överskrida de värden som definieras i tabell 11.

5.   Logisk post typ 4: Högupplösningsbild i gråskala

Det bör noteras att poster av typ 4 är binära poster snarare än ASCII-poster. Varje fält har där tilldelats en specifik position i posten, vilket medför att alla fält är obligatoriska.

Standarden medger att både bildstorlek och upplösning anges i posten. Logisk posttyp 4 måste innehålla fingeravtrycksuppgifter som överförs med en nominell pixeltäthet av 500–520 pixel/tum. Den täthet som föredras för nyutformningar är 500 pixel per tum, dvs. 19,68 pixel per mm. 500 pixel per tum är den täthet som specificeras i INT-I, med undantag för att liknande system får kommunicera med användning av en annan täthet inom intervallet 500–520 pixel per tum.

5.1   Fält i logisk post typ 4

5.1.1    Fält 4.001: Logisk postlängd (Logical Record Length – LEN)

Detta fält om fyra byte anger längden av typ 4-posten i totalt antal byte, inklusive varje byte i varje fält.

5.1.2    Fält 4.002: Bilddesigneringstecken (Image Designation Character – IDC)

Detta fält innehåller i binär form IDC-numret i filhuvudet.

5.1.3    Fält 4.003: Avtryckstyp (Impression Type – IMP)

Avtryckstyp är ett fält om en byte i sjätte positionen i posten.

5.1.4    Fält 4.004: Fingerposition (Finger Position – FGP)

Detta fasta fält med 6 byte upptar positionerna 7–12 i en post av typ 4. Det innehåller möjliga fingerställningar med början i den byte som befinner sig längst till vänster (byte 7 i posten). Känd eller mest trolig fingerposition har tagits från tabell 5. Upp till fem ytterligare fingrar kan registreras genom att man lägger in alternerande fingerpositioner i återstående fem byte i samma format. Om färre än fem fingerpositionsreferenser används fylls oanvända byte med binära 255. För att registrera alla fingerpositioner används 0 för okänd.

För latenta fingeravtryck på brottsplatsen bör endast koderna 0-10 användas.

5.1.5    Fält 4.005: Bildskanningsupplösning (Image Scanning Resolution – ISR)

Detta fält om en byte upptar position 13 i typ 4-posten. Om det innehåller ”0” har bilden skannats med en föredragen upplösning på 19,68 pixel/mm (500 pixel per tum). Om det innehåller ”1” har bilden skannats med en alternativ upplösning enligt typ 1-posten.

5.1.6    Fält 4.006: Horisontell linjelängd (Horizontal Line Length – HLL)

I detta fält som upptar positionerna 14-15 i typ 4-posten anges antalet pixel i varje skanningslinje. Den första positionen är mest signifikant.

5.1.7    Fält 4.007: Vertikal linjelängd (Vertical Line Length – VLL)

I detta fält i positionerna 16–17 anges antalet skanningslinjer i bilden. Den första positionen är mest signifikant.

5.1.8    Fält 4.008: Algoritm för komprimering av gråskalan (Gray-scale Compression Algorithm – GCA)

I detta fält om en byte anges vilken algoritm för komprimering av gråskalan som har använts för att koda bilddata. En binär kod 1 anger att WSQ-komprimering (bilaga 7 har använts för denna implementation.

5.1.9    Fält 4.009: Bilden (The Image)

Detta fält innehåller en teckensträng som representerar bilden. Fältets struktur kommer uppenbarligen att vara beroende av vilken komprimeringsalgoritm som används.

6.   Logisk post typ 9: Minutiaepost

Typ 9-poster ska innehålla ASCII-text som beskriver minutiae och dithörande uppgifter som har registrerats från ett latent avtryck. För en sökning efter latenta avtryck finns ingen övre gräns för antalet typ 9-poster i filen, som var och en ska svara mot en annan vy eller latent avtryck.

6.1   Extraktion av minutiae

6.1.1    Identifiering av minutiaetypen

I denna standard definieras tre identifikationsnummer som används för att beskriva minutiaetypen. Dessa specifikationer förtecknas i tabell 6. Åsavslutningar ska betecknas typ 1. Förgreningar ska betecknas typ 2. Om en minutiae inte klart kan kategoriseras en av de ovan nämnda typerna ska den betecknas som ”annan”, typ 0.

6.1.2    Typ och placering av minutiae

För att mallarna ska uppfylla kraven i avsnitt 5 i standarden ANSI INCITS 378-2004, ska följande metod, som förstärker den nu gällande standarden INCITS 378-20204, användas för att bestämma placering (läge och vinkelriktning) för enskilda minutiae.

Positionen eller läget för en minutia som representerar avslutningen på en ås ska vara gaffelpunkten i dalområdets mittskelett omedelbart framför åsavslutningen. Om de tre benen i dalområdet tunnas ner till en skelettbild som är en enda pixel bred, är det skärningspunkten som är minutians läge. På samma sätt blir minutialäget för en förgrening förgreningspunkten för linjens mittskelett. Om de tre benen i åsen tunnas ner till en skelettbild som är en enda pixel bred är det skärningspunkten för de tre benen som är minutians läge.

När alla linjeslut har omvandlats till förgreningar, framställs alla minutiae i fingeravtrycksbilden som förgreningar. X- och Y-pixelkoordinaterna för skärningen av de tre benen i varje minutia kan direktformateras. Bestämning av minutiariktningen kan extraheras from varje skelettförgrening. De tre benen i varje skelettförgrening måste undersökas, och avslutningspunkten för varje ben bestämmas. Figur 6.1.2 illustrerar de tre metoder som används för att bestämma avslutningen på ett ben som grundar sig på en skanningsupplösning på 500 ppi.

Avslutningen fastställs i enlighet med det som först inträffar. Pixelantalet grundar sig på en skanningsupplösning på 500 ppi. Olika skanningsupplösningar innebär olika pixelantal.

Figur 6.1.2

Minutiavinkeln bestäms genom att man drar tre virtuella strålar som utgår från gaffelpunkten och fortsätter till avslutningen av varje ben. Den minsta av de tre vinklar som bildas av strålarna skärs av på mitten för att ange minutians riktning.

6.1.3    Koordinatsystem

Det koordinatsystem som används för att beskriva minutiae i ett fingeravtryck ska vara ett rätvinkligt koordinatsystem med två axlar. Läge för minutiae ska anges med deras x- och y-koordinater. Koordinatsystemet ska ha origo i det övre vänstra hörnet av den ursprungliga bilden, med x-axeln pekande åt höger och y-axeln pekande nedåt. Både x-koordinaten och y-koordinaten för en minutia ska anges i pixlar från origo. Det bör noteras att läget för origo och måttenheten inte stämmer med definitionen av typ 9-poster i ANSI/NIST-ITL 1-2000.

6.1.4    Minutiaeriktning

Vinklar ska uttryckas i vanlig matematisk form, med nollgrader åt höger och vinkelvärden som ökar moturs. Registrerade vinklar pekar i riktningen tillbaka längs åsen på en avslutning av åsen och mot dalens centrum på en förgrening. Enligt denna konvention avviker vinklarna 180 grader från vad som anges i definitionen poster av typ 9 i ANSI/NIST-ITL 1-2000.

6.2   Fält i poster av typ 9, INCITS-378-format

Samtliga fält i typ 9-poster ska registreras som ASCII-text. I denna posttyp med taggade fält tillåts inga binära fält.

6.2.1    Fält 9.001: Logisk postlängd (Logical record length – LEN)

I detta obligatoriska fält anges längden av den logiska posten som det sammanlagda antalet byte i varje fält i posten.

6.2.2    Fält 9.002: (Image Designation Character – IDC)

Detta obligatoriska fält om två positioner ska användas för att identifiera och ange läge för minutiaeuppgifterna. IDC i detta fält ska stämma överens med IDC i filinnehållsfältet i typ 1-posten.

6.2.3    Fält 9.003: (Impression Type – IMP)

Detta obligatoriska fält om en byte ska beskriva på vilket sätt informationen i fingeravtrycksbilden har erhållits. ASCII-värdet för rätt kod för avtryckstypen ur tabell 4 ska registreras i detta fält.

6.2.4    Fält 9.004: Minutiaeformat (Minutiæ format – FMT)

Detta fält ska innehålla ”U” för att ange att minutiae är formaterade enligt M1-378. Även om informationen kan ha kodats enligt M1-378-standarden, måste samtliga fält i typ 9-posten förbli fält med ASCII-text.

6.2.5    Fält 9.126: CBEFF-information (CBEFF-information)

Detta fält ska innehålla tre uppgifter. Den första uppgiften ska ha värdet ”27” (0x1B). Detta är en identifikation av ägaren av CBEFF-formatet som har tilldelats INCITS:s tekniska kommitté M1 av International Biometric Industry Association (IBIA). <US>-avgränsaren ska avgränsa denna uppgift från CBEFF-formattypen som har tilldelats värdet ”513” (0x0201), vilket anger att denna post endast innehåller uppgifter om läge och vinkelriktning utan att ange någon information ur Extended Data Block. <US>-avgränsaren ska avgränsa denna uppgift från CBEFF-produktidentifieraren (PID) som identifierar ”ägaren” av kodningsutrustningen. Det är säljaren som fastställer detta värde. Det kan erhållas från IBIA:s webbplats (www.ibia.org) om det har publicerats på webben.

6.2.6    Fält 9.127: Identifikation av upptagningsutrustning (Capture equipment identification)

Detta fält ska innehålla två uppgifter skilda åt med <US>-avgränsaren. Den första uppgiften ska innehålla ”APPF”, om den utrustning som användes för att ursprungligen ta upp bilden var certifierad att överensstämma med bilaga F (Bildkvalitetsspecifikation för IAFIS, 29 januari 1999) till FBI:s specifikation för överföring av fingeravtryck i elektronisk form CJIS-RS-0010. Om utrustningen inte överensstämmer med denna specifikation, ska fältet innehålla teckensträngen ”NONE”. Den andra uppgiften ska innehålla upptagningsutrustningens identifikationsbegrepp (Capture Equipment ID), ett produktnummer för upptagningsutrustningen som tilldelats av säljaren. Värdet ”0” anger att upptagningsutrustningens identifikationsbegrepp inte har rapporterats.

6.2.7    Fält 9.128: Horisontell linjelängd (Horizontal Line Length – HLL)

Detta obligatoriska ASCII-fält ska innehålla antalet pixel i en enstaka horisontell linje i den överförda bilden. Storleken i horisontell led är begränsad till 65 534 pixel.

6.2.8    Fält 9.129: Vertikal linjelängd (Vertical Line Length – VLL)

Detta obligatoriska ASCII-fält ska innehålla antalet horisontella linjer i den överförda bilden. Storleken i vertikal led är begränsad till 65 534 pixel.

6.2.9    Fält 9.130: Skalenheter (Scale units – SLC)

Detta obligatoriska ASCII-fält ska ange enhet för samplingsfrekvensen (pixeltätheten). ”1” i detta fält anger pixel per tum, ”2” anger pixel per centimeter. ”0” i detta fält betyder att ingen enhet har angivits. I detta fall ger kvoten HPS/VPS pixelsidförhållandet (pixel aspect ratio).

6.2.10    Fält 9.131: Horisontell pixelskala (Horizontal pixel scale – HPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i horisontell led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den horisontella komponenten av pixelsidförhållandet (pixel aspect ratio).

6.2.11    Fält 9.132: Vertikal pixelskala (Vertical pixel scale – VPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i vertikal led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den vertikala komponenten av pixelsidförhållandet (pixel aspect ratio).

6.2.12    Fält 9.133: Fingervy (Finger view)

Detta obligatoriska fält innehåller vynumret för det finger postens uppgifter avser. Vynumren börjar på ”0” och ökar till ”15” med steglängden ett.

6.2.13    Fält 9.134: Fingerposition (Finger Position – FGP)

Detta fält ska innehålla koden för den fingerposition som lämnade informationen i denna typ 9-post. En kod mellan 1 och 10 från tabell 5, eller rätt handflatekod från tabell 10, ska användas för att ange finger- eller handflateposition.

6.2.14    Fält 9.135: Fingerkvalitet (Finger quality)

Detta fält ska ange den sammanlagda kvaliteten för uppgifterna om fingerminutiae med ett värde mellan 0 och 100. Detta tal sammanfattar fingerpostens kvalitet och avspeglar originalbildens kvalitet, kvaliteten vid extrahering av minutiae och andra operationer som kan påverka minutiaeposten.

6.2.15    Fält 1.136: Minutiaeantal (Number of minutiae)

I detta obligatoriska fält ska antalet minutiae som registrerats i denna logiska post anges.

6.2.16    Fält 9.137: Uppgifter om fingerminutiae (Finger minutiæ data)

Detta fält ska innehålla sex uppgifter åtskilda med <US>-avgränsaren. Det består av flera delfält där vart och ett innehåller detaljerna för enskilda minutiae. Det totala antalet minutiaedelfält måste stämma överens med antalet i fält 136. Den första uppgiften är minutiaeindexnummer, som ska initialiseras till ”1” och ökas med ”1” för varje tillkommande minutia i fingeravtrycket. Den andra och den tredje uppgiften är x-koordinaten och y-koordinaterna för minutiae i pixelenheter. Den fjärde uppgiften är minutiaevinkeln angiven i enheter om två grader. Detta värde ska vara icke-negativt mellan 0 och 179. Den femte uppgiften är minitiaetypen. Ett värde av ”0” används för att representera minutiae av typen ”ANNAN”, ett värde av ”1” för en åsavslutning och ett värde av ”2” för en åsförgrening. Den sjätte uppgiften anger kvaliteten för varje minutiae. Värdet ska ligga mellan minst 1 och mest 100. Ett ”0”-värde anger att kvalitetsvärde saknas. Varje delfält ska skiljas från nästa delfält med <RS>-avgränsaren.

6.2.17    Fält 9.138: Uppgifter om åsantal (Ridge count information)

Fältet består av en serie delfält där vart och ett innehåller tre uppgifter. Den första uppgiften i det första delfältet ska ange metoden för extrahering av antal åsar. ”0” anger att metoden för att extrahera antalet åsar är okänd, liksom ordningen i posten. ”1” anger att för varje centrumminutia har uppgifter om åsantal tagits fram till närmaste angränsande minutia i fyra kvadranter, och åsantal för varje centrumminutia har förtecknats tillsammans. ”2” anger att för varje centrumminutia har uppgifter om åsantal tagits fram till närmaste grannminutia i fyra kvadranter, och åsantal för varje centrumminutia har förtecknats tillsammans. De återstående två uppgifterna i det första delfältet ska båda innehålla ”0”. Uppgifterna ska åtskiljas av <US>-avgränsaren. Följande delfält får centrumminutians indexnummer som första uppgift, indexnummer för angränsande minutiae som andra uppgift och antalet åsövergångar som tredje uppgift. Uppgifterna ska åtskiljas av <US>-avgränsaren.

6.2.18    Fält 9.139: Uppgifter om centrumpunkter (Core information)

Detta fält består av ett delfält för varje centrumpunkt i originalbilden. Varje delfält innehåller tre uppgifter. De första två uppgifterna innehåller x- och y-koordinatpositionerna i pixelenheter. Den tredje uppgiften innehåller centrumpunktens vinkel angiven i enheter om 2 grader. Detta värde ska vara icke-negativt mellan 0 och 179. Multipla centrumpunkter ska åtskiljas av <RS>-avgränsaren.

6.2.19    Fält 9.140: Deltauppgifter (Delta information)

Detta fält består av ett delfält för varje deltapunkt i originalbilden. Varje delfält innehåller tre uppgifter. De första två uppgifterna innehåller x- och y-koordinatpositionerna i pixelenheter. Den tredje uppgiften innehåller deltapunktens vinkel angiven i enheter av 2 grader. Detta värde ska vara icke-negativt mellan 0 och 179. Multipla centrumpunkter ska åtskiljas av <RS>-avgränsaren.

7.   Post typ 13: Bilder av latenta avtryck med varierande upplösning

Logisk post av typ 13 med taggade fält ska innehålla data från bilder av latenta avtryck. Dessa bilder är avsedda att överföras till organ som automatiskt extraherar eller använder mänsklig intervention och behandling för att extrahera den önskade detaljinformationen från bilderna.

Uppgifter om skanningsupplösning, bildstorlek och andra parametrar som krävs för att behandla bilden registreras som taggade fält inom posten.

Nyckel för teckentyp: N = numerisk, A = alfabetisk, AN = alfanumerisk, B = binär

7.1   Fält i logisk post typ 4

Följande stycken beskriver uppgifterna i vart och ett av fälten för logisk post typ 13.

Inom en logisk post typ 13 ska registreringar läggas in i numrerade fält. De första två fälten i posten måste vara i rätt ordning, och fältet med bilduppgifterna ska vara det sista fysiska fältet i posten. För varje fält i typ 13-posten förtecknas i tabell 7 koden ”Beroende på tillgång på uppgifter” (”condition code”) som obligatorisk ”M” eller frivillig/valfri ”O”, fältnummer, fältbenämning, teckentyp, fältstorlek och förekomstgränser. Maximal storlek för fältet, uttryckt i antal byte och grundad på ett treställigt fältnummer, anges i sista kolumnen. När fler siffror används för fältnumret ökar också maximalt antal byte. De två registreringarna i fältstorlek per förekomst (”field size per occurrence”) inkluderar alla teckenavgränsare i fältet. Maximalt antal byte (”Maximum byte count”) inkluderar fältnummer, uppgifter och alla teckenavgränsare inklusive <GS>-avgränsaren.

7.1.1    Fält 13.001: Logisk postlängd (Logical record length – LEN)

I detta obligatoriska fält anges det totala antalet byte i hela logisk post typ 1. I fält 13.001 anges postens längd inklusive alla tecken i alla fält i posten samt uppgiftsavgränsare.

7.1.2    Fält 13.002: Bilddesigneringstecken (Image Designation Character – IDC)

Detta obligatoriska ASCII-fält ska användas för att identifiera bilduppgifterna om latent avtryck i posten. Detta IDC ska matcha IDC i fältet för filinnehåll (CNT) i typ 1-posten.

7.1.3    Fält 13.003: Avtryckstyp (Impression Type – IMP)

Detta obligatoriska fält om en eller två byte ska beskriva på vilket sätt bildinformationen om det latenta avtrycket har erhållits. Korrekt latentkod från tabell 4 (finger) eller tabell 9 (handflata) ska föras in i detta fält.

7.1.4    Fält 13.004: Källorgan (Source agency/ORI – SRC)

Detta obligatoriska ASCII-fält ska innehålla identifikation av den myndighet eller organisation som ursprungligen tog upp ansiktsbilden i posten. Normalt sett är det ursprungsorgansidentifieraren för det organ som tog upp bilden som ska stå i detta fält. Det består av två uppgifter i följande format: CC/organ.

Den första uppgiften består av Interpols landskod om två alfanumeriska tecken. Den andra uppgiften, organ, identifierar organet genom en sträng fri text om maximalt 32 alfanumeriska tecken.

7.1.5    Fält 13.005: Upptagningsdatum för latent avtryck (Latent capture date – LCD)

Detta obligatoriska ASCII-fält ska innehålla datum för upptagningen av den latenta bilden i posten. Datum skrivs som åtta siffror i formatet CCYYMMDD. CCYY-tecknen står för året för upptagningen av bilden. MM-tecknen är månadens tiotals- och enhetsvärden och DD-tecknen tiotals- och enhetsvärden för dagen i månaden. Till exempel står 20000229 för den 29 februari 2000. Fullständigt datum måste vara ett riktigt datum.

7.1.6    Fält 13.065: Horisontell linjelängd (Horizontal Line Length – HLL)

Detta obligatoriska ASCII-fält ska innehålla antalet pixel i en enstaka horisontell linje i den överförda bilden.

7.1.7    Fält 13.007: Vertikal linjelängd (Vertical Line Length – VLL)

Detta obligatoriska ASCII-fält ska innehålla antalet horisontella linjer i den överförda bilden.

7.1.8    Fält 13.008: Skalenheter (Scale units – SLC)

Detta obligatoriska ASCII-fält ska ange enhet för samplingsfrekvensen (pixeltätheten). ”1” i detta fält anger pixel per tum, ”2” anger pixel per centimeter. ”0” i detta fält betyder att ingen enhet har angivits. I detta fall ger kvoten HPS/VPS pixelsidförhållandet (pixel aspect ratio).

7.1.9    Fält 13.009: Horisontell pixelskala (Horizontal pixel scale – HPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i horisontell led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den horisontella komponenten av pixelsidförhållandet (pixel aspect ratio).

7.1.10    Fält 13.010: Vertikal pixelskala (Vertical pixel scale – VPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i vertikal led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den vertikala komponenten av pixelsidförhållandet (pixel aspect ratio).

7.1.11    Fält 13.011: Komprimeringsalgoritm (Compression algoritm – CGA)

Detta obligatoriska ASCII-fält ska ange den algoritm som används för att komprimera gråskalebilder. Komprimeringskoderna anges i bilaga 7.

7.1.12    Fält 13.012: Bitar per pixel (Bits per pixel – BPX)

Detta obligatoriska ASCII-fält ska innehålla antalet bitar som används för en pixel. I detta fält står ”8” för normala gråskalevärden från ”0” till ”255”. Alla värden i detta fält som är större än ”8” står för gråskalepixel med högre precision.

7.1.13    Fält 13.013: Fingerposition/handflateposition (Finger/Palm Position – FGP)

Detta obligatoriska taggade fält ska innehålla en eller flera av de möjliga finger-/handflatepositioner som kan matcha den latenta bilden. Det decimalkodsnummer som motsvarar den kända eller mest troliga fingerpositionen ska tas från tabell 5 eller den mest troliga handflatepositionen från tabell 10 och föras in som ett ASCII-delfält med ett eller två tecken. Ytterligare finger- och/eller handflatepositioner kan registreras genom att man lägger in alternerande positionskoder som delfält åtskilda av RS-avgränsaren. Koden ”0” för ”Okänt finger” ska användas för att registrera varje fingerposition från ett till tio. Koden ”20” för ”Okänd handflata” ska användas för att registrera varje handflateposition i förteckningen.

7.1.14    Fält 13.014-019: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

7.1.15    Fält 13.020: Kommentar (Comment COM)

Detta frivilliga fält kan användas för kommentarer eller annan information i ASCII-text med uppgifter om latent bild.

7.1.16    Fält 13.021-199: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

7.1.17    Fält 13.200-998: Användardefinierade fält (User-defined fields – UDF)

Dessa fält är användardefinierade fält och kommer att användas för framtida behov. Deras storlek och innehåll ska definieras av användaren i enlighet med det mottagande organet. Om de förekommer ska de innehålla information i ASCII-text.

7.1.18    Fält 13.999: Bilduppgifter (Image data – DAT)

Detta fält ska innehålla alla uppgifter från en upptagen latent bild. Det ska alltid få fältnummer 999 och måste vara det sista fysiska fältet i posten. Till exempel följs ”13.999” av bilduppgifter i binärt format.

Varje pixel av okomprimerade gråskaleuppgifter ska normalt kvantifieras till åtta bitar (256 grå nivåer) i en enda byte. Om värdet i BPX-fältet 13.102 är större än eller mindre än ”8” får man ett annat antal byte som krävs för att innehålla en pixel. Om komprimering används ska pixeluppgifterna komprimeras i enlighet med den komprimeringsteknik som anges i GCA-fältet.

7.2   Avslutning post typ 13: Latenta bilder med varierande upplösning

Omedelbart efter sista byte uppgifter från fält 13.199 ska för konsekvensens skull en <FS>-avgränsare användas för att avgränsa den från nästa logiska post. Denna avgränsare måste inkluderas i typ 13-postens längdfält.

8.   Post typ 15: Bilder av handavtryck med varierande upplösning

Det taggade fältet i logisk post typ 15 ska innehålla och användas för att utbyta uppgifter om handflateavtryck tillsammans med fasta och användardefinierade textinformationsfält avseende den digitaliserade bilden. Uppgifter om skanningsupplösning, bildstorlek och andra parametrar eller kommentarer som krävs för att behandla bilden registreras som taggade fält inom posten. Handflateavtrycksbilder som översänds till andra organ kommer att behandlas av de mottagande organen för att extrahera den önskade detaljinformation som krävs för matchning.

Bilduppgifterna fås direkt från en person med hjälp av en livescan-utrustning eller från en handflateavtrycksblankett eller annat medium som innehåller personens handflateavtryck.

Alla metoder som används för att få fram bilder av handflateavtrycket ska också medge upptagning av en uppsättning bilder för varje hand. Denna uppsättning ska inkludera handflatans yttre kant som en enda skannad bild och hela området för hela handen från handleden till fingertopparna som en eller två skannade bilder. Om två bilder används för att visa hela handflatan, ska den nedre bilden visa området från handleden till övre delen av området mellan fingrarna (tredje fingerleden) inklusive områdena kring handflatans tumvalk och lillfingervalk. Den övre bilden ska visa området från nedre delen av det interdigitala området till de översta fingertopparna. Detta ger tillräcklig överlappning mellan de två bilderna som båda visar handflateområdet mellan fingrarna. Genom att matcha åsstrukturen och detaljerna i detta gemensamma område kan en undersökare med tillförlitlighet konstatera att båda bilderna kom från samma handflata.

Eftersom en handavtryckstransaktion kan användas för olika ändamål, kan det innehålla ett eller flera unika bildområden registrerade från handflatan eller handen. En fullständig registrering av ett handflateavtryck från en individ inkluderar normalt handflatans yttre kant och fullständig/a bild/er av varje handflata. Eftersom en logisk bildpost med taggade fält kan innehålla endast ett binärt fält, kommer det att krävas en enda typ 15-post för varje handflatekant och en eller två typ 15-poster för varje fullständig handflata. Därför behövs det fyra till sex typ 15-poster för att visa personens handflateavtryck i en normal transaktion med handflateavtryck.

8.1   Fält i logisk post typ 15

Följande stycken beskriver uppgifterna i vart och ett av fälten för logisk post typ 15.

Inom en logisk post typ 15 ska registreringar läggas in i numrerade fält. De första två fälten i posten måste vara i rätt ordning, och fältet med bilduppgifterna ska vara det sista fysiska fältet i posten. För varje fält i typ 15-posten förtecknas i tabell 8 korskoden ”Beroende av tillgång på uppgifter” (”condition code”) som obligatorisk ”M” eller frivillig/valfri ”O”, fältnummer, fältbenämning, teckentyp, fältstorlek och förekomstgränser. Maximal storlek för fältet, uttryckt i antal byte och grundad på ett treställigt fältnummer, anges i sista kolumnen. När fler siffror används för fältnumret ökar också maximalt antal byte. De två registreringarna i fältstorlek per förekomst (”field size per occurrence”) inkluderar alla teckenavgränsare i fältet. Maximalt antal byte (”Maximum byte count”) inkluderar fältnummer, uppgifter och alla teckenavgränsare inklusive GS-avgränsaren.

8.1.1    Fält 15.001: Logisk postlängd (Logical record length – LEN)

I detta obligatoriska ASCII-fält anges det totala antalet byte i hela den logiska posten av typ 15. I fält 15.001 ska anges postens längd inklusive alla tecken i alla fält i posten samt uppgiftsavgränsare.

8.1.2    Fält 15.002: Bildbenämningstecken (Image Designation Character – IDC)

Detta obligatoriska ASCII-fält ska användas för att identifiera uppgifterna om handflateavtrycksbilden i posten. Detta IDC ska matcha IDC i fältet för filinnehåll (CNT) i typ 1-posten.

8.1.3    Fält 15.003: Avtryckstyp (Impression Type – IMP)

Detta obligatoriska ASCII-fält om en byte ska ange på vilket sätt informationen i handavtrycksbilden har erhållits. Korrekt kod från tabell 9 ska föras in i detta fält.

8.1.4    Fält 15.004: Källorgan (Source agency/ORI – SRC)

Detta obligatoriska ASCII-fält ska innehålla identifikation av den myndighet eller organisation som ursprungligen tog upp ansiktsbilden i posten. Normalt sett är det ursprungsorgansidentifieraren för det organ som tog upp bilden som ska stå i detta fält. Det består av två uppgifter i följande format: CC/organ.

Den första uppgiften består av Interpols landskod om två alfanumeriska tecken. Den andra uppgiften, organ, identifierar organet genom en sträng fri text om maximalt 32 alfanumeriska tecken.

8.1.5    Fält 15.005: Upptagningsdatum för handflateavtrycket (Palmprint capture date – PCD)

Detta obligatoriska ASCII-fält ska ange datum för upptagningen av handflateavtrycket. Datum skrivs som åtta siffror i formatet CCYYMMDD. CCYY-tecknen står för året för upptagningen av bilden. MM-tecknen ska ange tiotals- och entalssiffran för månaden och DD-tecknen tiotals- och entalssiffran för dagen i månaden. Till exempel står 20000229 för den 29 februari 2000. Fullständigt datum måste vara ett verkligt datum.

8.1.6    Fält 15.006: Horisontell linjelängd (Horizontal Line Length – HLL)

Detta obligatoriska ASCII-fält ska innehålla antalet pixlar i en enstaka horisontell linje i den överförda bilden.

8.1.7    Fält 15.007: Vertikal linjelängd (Vertical Line Length – VLL)

Detta obligatoriska ASCII-fält ska ange antalet horisontella linjer i den överförda bilden.

8.1.8    Fält 15.008: Skalenheter (Scale units – SLC)

Detta obligatoriska ASCII-fält ska ange enhet för samplingsfrekvensen (pixeltätheten). ”1” i detta fält anger pixel per tum, ”2” anger pixel per centimeter. ”0” i detta fält betyder att ingen enhet har angivits. I detta fall ger kvoten HPS/VPS pixelsidförhållandet (pixel aspect ratio).

8.1.9    Fält 15.009: Horisontell pixelskala (Horizontal pixel scale – HPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i horisontell led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den horisontella komponenten av pixelsidförhållandet (pixel aspect ratio).

8.1.10    Fält 15.010: Vertikal pixelskala (Vertical pixel scale – VPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i vertikal led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den vertikala komponenten av pixelsidförhållandet (pixel aspect ratio).

8.1.11    Fält 15.011: Komprimeringsalgoritm (Compression algoritm – CGA)

Detta obligatoriska ASCII-fält ska ange den algoritm som används för att komprimera gråskalebilder. ”NONE” i detta fält anger att uppgifterna i denna post inte har komprimerats. För de uppgifter som ska komprimeras ska detta fält innehålla den metod som valts för komprimering av fingeravtrycksbilder av 10 fingrar. Giltiga komprimeringskoder definieras i bilaga 7.

8.1.12    Fält 15.012: Bitar per pixel (Bits per pixel – BPX)

Detta obligatoriska ASCII-fält ska innehålla antalet bitar som används för en pixel. I detta fält ska ”8” stå för normala gråskalevärden från ”0” till ”255”. Alla värden i detta fält som är större än eller mindre än ”8” står för en gråskalepixel med högre respektive lägre precision.

8.1.13    Fält 15.013: Handavtrycksposition (Palmprint position – PLP)

Detta obligatoriska taggade fält ska innehålla den handavtrycksposition som matchar bilden av handflateavtrycket. Det decimalkodsnummer som motsvarar den kända eller mest troliga handavtryckspositionen ska tas från tabell 10 och föras in som ett ASCII-delfält med ett eller två tecken. Tabell 10 listar också maximala bildområden och dimensioner för var och en av de möjliga positionerna för handavtrycken.

8.1.14    Fält 15.014-019: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

8.1.15    Fält 15.020: Kommentar (Comment – COM)

Detta frivilliga fält kan användas för kommentarer eller annan information i ASCII-text med uppgifter om handavtrycksbild.

8.1.16    Fält 15.021-199: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

8.1.17    Fält 15.200-998: Användardefinierade fält (User-defined fields – UDF)

Dessa fält är användardefinierade fält och kommer att användas för framtida behov. Deras storlek och innehåll ska definieras av användaren i enlighet med det mottagande organet. Om de förekommer ska de innehålla information i ASCII-text.

8.1.18    Fält 15.999: Bilduppgifter (Image data – DAT)

Detta fält ska innehålla alla uppgifter om en upptagen handavtrycksbild. Det ska alltid tilldelas fältnummer 999 och måste vara det sista fysiska fältet i posten. Till exempel ”15.999” följs av bilduppgifter i binärt format. Varje pixel av okomprimerade gråskaleuppgifter ska normalt kvantifieras till åtta bitar (256 grå nivåer) i en enda byte. Om värdet i BPX-fältet 15.012 är större än eller mindre än ”8” får man ett annat antal byte som krävs för att innehålla en pixel. Om komprimering används ska pixeluppgifterna komprimeras i enlighet med den komprimeringsteknik som anges i CGA-fältet.

8.2   Avslutning post typ 15: Handavtrycksbilder med varierande upplösning

Omedelbart efter sista byte av uppgifter från fält 15.999 ska för konsekvensens skull en <FS>-avgränsare användas för att avgränsa den från nästa logiska post. Denna avgränsare måste inkluderas i typ 15-postens längdfält.

8.3   Ytterligare handavtrycksbilder av post typ 15 med varierande upplösning

Ytterligare typ 15-poster kan inkluderas i filen. För varje ytterligare handavtrycksbild krävs en fullständig logisk post typ 15 tillsammans med <FS>-avgränsaren.

Sökningstyper:

9.   Bilagor till kapitel 2 (utbyte av finger- och handavtrycksuppgifter)

9.1   Bilaga 1 ASCII-koder för avgränsare

9.2   Bilaga 2 Beräkning av alfanumeriskt kontrolltecken

För TCN och TCR (Fält 1.09 och 1.10)

Det tal som motsvarar kontrolltecknet genereras enligt följande formel:

(YY * 108 + SSSSSSSS) Modulo 23

där YY and SSSSSSSS är de numeriska värdena av de sista två siffrorna för år respektive serienummer.

Kontrolltecknet genereras sedan ur tabellen nedan.

För CRO (Fält 2.010)

Det tal som motsvarar kontrolltecknet genereras enligt följande formel:

(YY * 106 + NNNNNN) Modulo 23

där YY and SSSSSSSS är de numeriska värdena av de sista två siffrorna för år respektive serienummer.

Kontrolltecknet genereras sedan ur tabellen nedan.

9.3   Bilaga 3 Teckenkoder

9.4   Bilaga 4 Sammanfattning av transaktioner

Under villkorskolumnen:

O = frivilligt, M = obligatoriskt, C = beroende på om transaktionen är ett svar till ursprungsorganet

Under kolumnen ”Condition”:

O = frivilligt, M = obligatoriskt, C = beroende av tillgängliga uppgifter

*

=

om översändningen av uppgifterna är i enlighet med nationell lag (omfattas ej av beslut 2008/615/RIF)

9.5   Bilaga 5 Post typ 1 definitioner

Under kolumnen ”Condition”: O = frivillig, M = obligatorisk, C = beroende av tillgängliga uppgifter

Under teckentypkolumn: A = Alfa, N = Numerisk, B = Binär

1* tillåtna tecken för organets namn är [”0...9”, ”A...Z”, ”a...z”, ”_”,”.”, ” ”, ”-”]

9.6   Bilaga 6 Post typ 2 definitioner

Under kolumnen ”Condition”: O = frivillig, M = obligatorisk, C = beroende av tillgängliga uppgifter

Under teckentypkolumn: A = Alfa, N = Numerisk, B = Binär

1* tillåtna tecken är [”0...9”, ”A...Z”, ”a...z”, ”_”,”.”, ” ”, ”-”]

9.7   Bilaga 7 Koder för gråskalekomprimering

Komprimeringskoder

9.8   Bilaga 8 E-postspecifikation

För att förbättra det interna arbetsflödet måste ärenderubriken för en Prümtransaktion fyllas i med landskod (CC) för den medlemsstat som sänt meddelandet och även typ av transaktion (TOT-fältet 1.004).

Format: CC/transaktionstyp

Exempel: ”DE/CPS”

Fältet för meddelandetext kan vara tomt.

KAPITEL 3: Utbyte av uppgifter i fordonsregister

1.   Gemensam uppsättning uppgifter för automatiserad sökning i fordonsregister

1.1   Definitioner

Definitionerna av obligatoriska och frivilliga uppgifter enligt artikel 16.4 är följande:

Obligatoriska uppgifter (M)

Uppgiften måste vidarebefordras när informationen är tillgänglig i en medlemsstats nationella register. Det finns därför en skyldighet att utbyta uppgifterna när de finns tillgängliga.

Frivilliga uppgifter (O)

Uppgiften får vidarebefordras när informationen är tillgänglig i en medlemsstats nationella register. Det finns därför ingen skyldighet att utbyta uppgifterna även om de finns tillgängliga.

Beteckningen (Y) används för varje uppgift i uppsättningen uppgifter som anses vara särskilt viktig med avseende på beslut 2008/615/RIF.

1.2   Sökning på fordon/ägare/innehavare

1.2.1    Sökkriterier

Det finns två olika sätt att söka efter uppgifterna, nämligen

Med hjälp av dessa sökkriterier får man uppgifter om ett eller flera fordon. Om uppgifterna endast gäller ett fordon lämnas samtliga uppgifter i ett svar. Om fler än ett fordon har hittats kan den tillfrågade medlemsstaten själv besluta vilka uppgifter som ska lämnas ut: alla uppgifter eller endast de uppgifter som behövs för att begränsa sökningen (t.ex. av integritetsskäl eller prestandaskäl).

De uppgifter som behövs för att begränsa sökningen anges i punkt 1.2.2.1. I punkt 1.2.2.2 beskrivs den fullständiga uppsättningen uppgifter.

När man söker på identifieringsnummer, referensdatum och referenstid kan sökningen göras i en eller alla deltagande medlemsstater.

När man söker på registreringsnummer, referensdatum och referenstid måste sökningen göras i en viss medlemsstat.

Vanligen används nuvarande datum och tid för sökningen, men det är möjligt att göra en sökning med ett referensdatum och en referenstid i det förflutna. Om man gör en sökning med ett referensdatum och en referenstid i det förflutna, och historiska uppgifter inte finns tillgängliga i en viss medlemsstats register eftersom sådana uppgifter inte registreras över huvud taget, kan de aktuella uppgifterna komma upp som sökresultat med en angivelse om att det rör sig om aktuella uppgifter.

1.2.2    Uppsättning uppgifter

2.   Datasäkerhet

2.1   Översikt

Eucaris programapplikation används för säker kommunikation med övriga medlemsstater och kommunicerar med medlemsstaternas äldre back-end-system med hjälp av XML. Medlemsstaterna utbyter meddelanden genom att sända dem direkt till mottagaren. Varje medlemsstats datacentral är ansluten till EU:s Testa-nät.

De XML-meddelanden som sänds via nätet krypteras med krypteringstekniken SSL. De meddelanden som sänds till back-end-systemen är XML-meddelanden i klartext eftersom anslutningen mellan applikationen och back-end-systemen ska vara i en skyddad miljö.

Det tillhandahålls en klientapplikation som kan användas inom en medlemsstat för att söka i dess eget register eller i en annan medlemsstats register. Klienterna identifieras med hjälp av användar-ID/lösenord eller ett klientcertifikat. Anslutningen till en användare kan krypteras, men detta är varje enskild medlemsstats ansvar.

2.2   Säkerhetsfunktioner i samband med meddelandeutbytet

Säkerhetssystemet är baserat på en kombination av HTTPS och XML-signatur. Med detta alternativ används XML-signatur för att signera alla meddelanden som sänds till servern, och den som sänder meddelandet kan autentiseras genom att signaturen kontrolleras. Enkelsidig SSL (enbart ett servercertifikat) används för att skydda meddelandets konfidentialitet och integritet under överföringen och skyddar mot raderings-/replay- och insättningsattacker. Istället för skräddarsydd programvaruutveckling för att tillämpa dubbelsidig SSL, tillämpas XML-signatur. Användningen av XML-signatur ligger närmare färdplanen för webbtjänstgränssnitt än dubbelsidig SSL och är därför mer strategisk.

XML-signatur kan tillämpas på flera sätt men man har valt att använda tekniken som en del av Web Services Security (WSS). WSS anger hur XML-signatur ska användas. Eftersom WSS bygger på Soap-standarden är det logiskt att följa denna standard så långt det är möjligt.

2.3   Säkerhetsfunktioner utan samband med meddelandeutbytet

2.3.1    Autentisering av användare

Användare av Eucaris webbapplikation kan autentisera sig med hjälp av användarnamn och lösenord. Eftersom man använder Windows standardautentisering kan medlemsstaterna vid behov höja autentiseringsnivån för användarna genom att använda klientcertifikat.

2.3.2    Användarroller

Eucaris är anpassad till olika användarroller. Varje grupp av tjänster har en egen behörighetstilldelning. Användare som enbart har behörighet att använda ”Eucarisavtalsfunktionen” får exempelvis inte använda ”Prümfunktionen”. Administratörstjänsterna är avskilda från de vanliga slutanvändarrollerna.

2.3.3    Loggning och spårning av meddelandeutbytet

Eucaris möjliggör loggning av alla typer av meddelanden. Genom en administratörsfunktion kan den nationella administratören bestämma vilka meddelanden som ska loggas: begäranden från slutanvändare, inkommande begäranden från andra medlemsstater, uppgifter som hämtats från de nationella registren osv.

Applikationen kan konfigureras så att den använder en intern databas eller en extern (Oracle) databas för denna loggning. Vilka meddelanden som måste loggas beror naturligtvis på loggningsmöjligheterna i andra delar av de äldre systemen och de anslutna klientapplikationerna.

Rubriken till varje meddelande innehåller information om den begärande medlemsstaten, den begärande organisationen inom den medlemsstaten och den berörda användaren. Skälet till begäran anges också.

Det är möjligt att spåra ett fullständigt meddelandeutbyte (t.ex. på begäran av den berörda medborgaren) med hjälp av den kombinerade loggningen i den begärande och tillfrågade medlemsstaten.

Loggningen konfigureras genom Eucaris webbklient (menu Administration, Logging configuration). Loggningsfunktionen utförs av grundsystemet. När loggningen är aktiverad lagras hela meddelandet (rubriken och meddelandetexten) i en loggningspost. Loggningsnivån kan ställas in enligt angiven tjänst eller enligt den meddelandetyp som passerar genom grundsystemet.

Loggningsnivåer

Följande loggningsnivåer är möjliga:

Privat – meddelandet loggas: Loggen är inte tillgänglig för sökning av loggningar, utan är endast tillgänglig på nationell nivå för revision och problemlösning.

Ingen – meddelandet loggas inte alls.

Typer av meddelanden

Informationsutbytet mellan medlemsstaterna består av flera meddelanden, som illustreras schematiskt i figuren nedan.

De möjliga meddelandetyperna (som i figuren visas för Eucaris grundsystem i medlemsstat X) är följande:

Figur: Meddelandetyper för loggning

2.3.4    Säkerhetsmodul i maskinvara

Ingen säkerhetsmodul används i maskinvaran.

En säkerhetsmodul i maskinvaran (HSM, Hardware Security Model) ger ett gott skydd av den nyckel som används för att signera meddelanden och identifiera servrar. Detta bidrar till den allmänna säkerhetsnivån, men kostnaden är hög för inköp/underhåll av en HSM, och det finns inga krav på att använda en HSM som uppfyller nivå 2 eller 3 enligt FIPS-standarden 140-2. Eftersom man använder ett slutet nät som effektivt skyddar mot hot har man beslutat att inledningsvis inte använda någon HSM. Om en HSM blir nödvändig, t.ex. för att ackreditering, kan arkitekturen kompletteras med detta.

3.   Tekniska villkor för informationsutbytet

3.1   Allmän beskrivning av Eucaris-applikationen

3.1.1    Översikt

Eucaris-applikationen kopplar samman alla medlemsstater i ett meshnät där varje medlemsstat kommunicerar direkt med en annan medlemsstat. Ingen central komponent behövs för att etablera kommunikationen. Eucaris-applikationen hanterar säker kommunikation till de andra medlemsstaterna och kommunicerar med back-end-delen i äldre system hos medlemsstater som använder XML. Följande bild visualiserar denna arkitektur.

Medlemsstaterna utbyter meddelanden genom att sända dem direkt till mottagaren. En medlemsstats datacentral är kopplad till det nät som används för utbyte av meddelanden (Testa). För åtkomst av Testa-nätet ansluter sig medlemsstaterna till Testa via sin nationella nätport. En brandvägg ska användas för anslutning till nätet och en router ansluter Eucaris-applikationen till brandväggen. Beroende på vilket alternativ som väljs för att skydda meddelandena, används ett certifikat antingen av routern eller av Eucaris-applikationen.

En klientapplikation tillhandahålls som kan användas inom en medlemsstat för att söka i dess eget register eller andra medlemsstaters register. Klientapplikationen är ansluten till Eucaris. Klienterna identifieras med hjälp av användarID/lösenord eller ett klientcertifikat. Anslutningen till en användare i en extern organisation (t.ex. polisen) kan krypteras men detta är varje enskild medlemsstats ansvar.

3.1.2    Systemets tillämpningsområde

Eucaris-systemets tillämpningsområde är begränsat till processer som används i informationsutbytet mellan registreringsmyndigheterna i medlemsstaterna och en grundläggande presentation av denna information. Förfaranden och automatiserade processer i vilka informationen ska användas faller utanför systemets tillämpningsområde.

Medlemsstater kan välja att antingen använda Eucaris klientfunktion eller skapa sin egen skräddarsydda klientapplikation. I tabellen nedan anges vilka aspekter av Eucaris-systemet som obligatoriskt måste användas och/eller föreskrivs och vilka aspekter som är frivilliga och/eller som medlemsstaterna fritt kan fastställa.

3.2   Funktionella och icke funktionella krav

3.2.1    Generisk funktionalitet

I detta avsnitt har de huvudsakliga generiska funktionerna beskrivits i allmänna termer

3.2.2    Användbarhet

3.2.3    Tillförlitlighet

3.2.4    Prestanda

3.2.5    Säkerhet

3.2.6    Anpassbarhet

3.2.7    Stöd och underhåll

3.2.8    Krav på utformningen

3.2.9    Tillämpliga standarder

KAPITEL 4: Utvärdering

1.   Utvärderingsförfarande i enlighet med artikel 20 (förberedelse av beslut enligt artikel 25.2 i beslut 2008/615/RIF)

1.1   Frågeformulär

Den berörda rådsarbetsgruppen ska utarbeta ett frågeformulär beträffande vart och ett av de automatiserade utbytena av information i kapitel 2 i beslut 2008/615/RIF.

Så snart som en medlemsstat anser sig uppfylla de nödvändiga förutsättningarna för att dela information i de relevanta informationskategorierna ska den besvara det relevanta frågeformuläret.

1.2   Testkörning

I syfte att utvärdera resultatet av frågeformuläret ska de medlemsstater som vill börja dela information genomföra en testkörning tillsammans med en eller flera andra medlemsstater som redan delar information enligt rådsbeslutet. Testkörningen ska äga rum före eller kort tid efter utvärderingsbesöket.

Villkoren och arrangemangen kring denna testkörning ska fastställas av den berörda rådsarbetsgruppen och grunda sig på en i förväg träffad separat överenskommelse med den berörda medlemsstaten. De medlemsstater som deltar i testkörningen beslutar själva om de praktiska detaljerna.

1.3   Utvärderingsbesök

I syfte att utvärdera resultatet av frågeformuläret ska ett utvärderingsbesök äga rum i den medlemsstat som vill börja dela information.

Villkoren och arrangemangen kring denna testkörning kommer att fastställas av den berörda rådsarbetsgruppen och grunda sig på en i förväg träffad separat överenskommelse mellan den berörda medlemsstaten och utvärderingsteamet. Den berörda medlemsstaten ska ge utvärderingsteamet möjlighet att kontrollera det automatiserade informationsutbytet i den eller de informationskategorier som ska utvärderas, bland annat genom att organisera ett program för besöket som beaktar de önskemål som utvärderingsteamet framfört.

Inom en månad ska utvärderingsteamet sammanställa en rapport om utvärderingsbesöket och överlämna den till berörda medlemsstater för kommentarer. I förekommande fall ska utvärderingsgruppen revidera denna rapport på grundval av medlemsstaternas kommentarer.

Utvärderingsteamet ska bestå av högst tre experter, utsedda av de medlemsstater som deltar i det automatiserade informationsutbytet i de informationskategorier som ska utvärderas, som har erfarenhet beträffande den berörda informationskategorin, som har genomgått lämplig nationell säkerhetskontroll för att få handha dessa frågor och som är villiga att delta i åtminstone ett utvärderingsbesök i en annan medlemsstat.

Medlemmarna i utvärderingsteamet ska respektera den inhämtade informationens konfidentiella natur i samband med att de utför sin uppgift.

1.4   Rapport till rådet

En övergripande utvärderingsrapport som sammanfattar resultatet av frågeformulären, utvärderingsbesöket och testkörningen kommer att läggas fram för rådet för beslut i enlighet med artikel 25.2 i beslut 2008/615/RIF.

2.   Utvärderingsförfarande enligt artikel 21

2.1   Statistik och rapport

Varje medlemsstat ska samla in statistik över resultatet av det automatiserade informationsutbytet. I syfte att säkerställa jämförbarhet kommer statistikmodellen att fastställas av den berörda rådsarbetsgruppen.

Dessa statistikuppgifter kommer årligen att läggas fram för rådet, som ska göra en övergripande sammanfattning av det gångna året, och för kommissionen.

Dessutom kommer medlemsstaterna regelbundet att anmodas att inte underlåta att en gång per år tillhandahålla sådana ytterligare uppgifter om det administrativa, tekniska och finansiella genomförandet av automatiserat utbyte av information som behövs för analys och förbättringar av processen. På grundval av denna information kommer en rapport att sammanställas för rådet.

2.2   Revidering

Inom rimlig tid kommer rådet att granska den utvärderingsmekanism som beskrivs här och vid behov revidera den.

3.    Expertmöten

Inom den berörda rådsarbetsgruppen kommer experter regelbundet att träffas för att organisera och genomföra de ovannämnda utvärderingsförfarandena samt dela med sig av sina erfarenheter och diskutera möjliga förbättringar. I tillämpliga fall kommer resultatet av dessa expertdiskussioner att införlivas med den rapport som det hänvisas till i punkt 2.1 ovan.