1. Inledning:

Inera har av CGI upphandlat en central fristående underskriftstjänst i enlighet med Digitaliseringsmyndighetens (DIGG) standard Tekniskt ramverk för Sweden connect.

Detta dokument har som mål att vägleda er som kund till Inera i de steg ni som organisation måste ta för att dels förbereda er på en policy- och organisatorisk nivå, men även de tekniska förberedelserna och beställningsprocessen som krävs för att kunna ansluta sig.

Det totala ekosystemet för underskrift och identifiering baserar sig i grunden på Ineras referensarkitektur som är utgiven under 2020. Observera att vi valt att inte ta med stämplar just nu i Ineras erbjudande eftersom det finns juridiska utmaningar för signaturer till juridisk person i och med brist på dessa e-legitimationer.
Det är lätt att stämplar blandas ihop med en automation så som t ex signering av ankomna handlingar i ett ärendehantering system eller signering av loggar vilket tekniskt är en stämpelsignering, men som då inte passar in i en fristående underskriftstjänst baserat på dess mål att lösa signeringar av dokument som ligger under eIDAS artikel 26 eller artikel 36.

2. Definitioner:

3. Förbereda er organisation på ett icke tekniskt plan.

e-underskrifter kan vara ett mycket komplext område och vid implementering av e-underskrift i en e-tjänst så måste den egna organisationen också förstå sitt egna juridiska ansvar för slutprodukten (den underskrivna dokumentet). En fristående underskriftstjänst definierad av Digitaliseringsmyndigheten innebär ett delat ansvar för den slutgiltiga e-underskriften, vilket eget ansvar ni som organisation har beror på er egen miljö och uppsättning av den.

En bra start för organisationen är att börja läsa för att förstå är:

• Digitaliseringsmyndighetens Normativ Specifikation
  • Policy
  • Tjänstespecifikation

• e-SAM’s vägledning ”e-legitimation och e-underskrift 1.1”
• eIDAS förordningen

Men även de svenska lagar dessa underskrifter kommer tillämpas (lagrummet). Notera att i det svenska lagrummet så tillämpas två nivåer, Elektronisk Underskrift eller Avancerad Elektronisk Underskrift. Dessa två nivåer har definition i eIDAS förordningen Artikel 3. Den fristående e-underskriftstjänsten som Inera levererar är en tjänst som når upp till nivån Avancerad Elektronisk Underskrift om alla ingående komponenter lever upp till kravet i eIDAS Artikel 26. Det är punkt C som e-tjänsten kommer ha ett delansvar samt även då IdP:n och Signerings meddelandet ”Sign message” som e-tjänsten skapar som är viktiga komponenter som ni som organisation själva måste se till att tillsammans med verksamhet och Jurister komma fram till hur detta ska implementeras i era egna e-tjänster. Här finns det stöd hur man bör utforma sin e-tjänst från Kammarkollegiet (Vägledning avrop eID tjänster 2.0) där de ritat upp ett rekommenderat arbetsflöde i en tjänst som kan följas.

Viktigaste texten som definierar relationen och ansvar mellan e-tjänst och underskriftstjänst finns i Digg’s Tjänstespecifikation Kapitel 2.3
” Underskriftstjänsten tillämpar en rollfördelning där e-tjänsten tillhandahåller funktioner gentemot användaren för att visa och hantera dokument samt sända och ta emot signeringsmeddelanden till underskriftstjänsten. Underskriftstjänsten agerar i detta avseende som underleverantör till e-tjänsten. Underskriftstjänsten ställer ut underskriftscertifikat och tillhandahålla bland annat funktioner för spärrinformation gentemot förlitande part.”

Verifikations punkter:

• Vi har utfört analys av vårat eget juridiska ansvar och den tänkta implementeringen?
• Vi har utfört analys hur vi ska lösa arkivering av e-underskrifter?

4. Vad är en fristående e-underskriftstjänst i enlighet med Tekniskt ramverk från Digitaliseringsmyndigheten?

Den korta versionen är att det är en e-underskriftsfunktion som är frikopplad e-tjänsten och även e-legitimationsbäraren.

Det innebär att underskriftstjänsten i sig inte är en helhets leverans för e-underskrifter utan det behövs då dels en e-tjänst som ansvarar för vissa delar i ett underskriftsflöde, samt då integration med en identitets intygsutgivare som oftast benämns IdP. Det innebär att det ligger fortfararande ett stort ansvar på er som organisation och e-tjänst att ha koll och förstå. Det är också en bakomliggande del att Inera nu i början enbart erbjuder e-underskrift från Ineras idP eftersom lokala idP:er på och är en stor del att totala tilliten på en e-underskrift.

4.1. Vilka steg behöver vi som organisation ta rent tekniskt för att ansluta till Ineras underskriftstjänst?

• Alla användare måste ha den nya Autentiserings klienten antingen installerad på sin PC eller i form av Mobilt SITHS.
• Ha en e-tjänst som antingen redan har en egen inbyggd stödtjänst eller gör en integration mot CGI’s Stödtjänst mjukvara som kan tillhandahållas som just mjukvara till en organisation för egen drift. Läs mer om Stödtjänsten:
• Beslut vad för ”Display name” som ska visas i Autentiserings klienten för en integration.
• Beställ av Inera uppsättning av en e-underskriftstjänst i enlighet med beställnings formuläret.

4.2. Stödtjänst Vad är det? Behöver vi den? Hur levereras den?

En stödtjänst är en mjukvara som e-tjänsten kan dra nytta av om de inte vill själva utveckla en e-tjänst som har stöd för att skapa en Sign request i enlighet med Digitaliseringsmyndighetens Teknisk ramverk för DSS. Mjukvaran ska installeras på kundens infrastruktur så nära e-tjänsten som möjligt.

CGI levererar till Inera en stödtjänst som mjukvara som är en Java applikation. Det går att kontakta CGI direkt för att teckna avtal för hjälp gällande paketering och konfiguration och design av denna mjukvara. Det går även att paketera stödtjänsten som en Dockerleverans om så önskas.
 

4.3. Display name:

I Ineras Autentiserings klient så kommer det nu visas på samma sätt som då man använder BankID vem som begär en Autentisering och en Signering.

Det finns i Metadatan två skilda fält, en vem som är Juridiska organisationen bakom namnet detta representeras i Metadatan för en e-underskriftstjänst på fältet

<md:OrganizationName xml:lang="sv">Region Stockholm</md:OrganizationName>

En organisation kan ha en eller flera Displayname

<md:OrganizationDisplayName xml:lang="sv">Region Stockhoms underskriftstjänst</md:OrganizationDisplayName>

Men ju fler Display name ni väljer att ha ju mer konfiguration att hålla koll på i Stödtjänsten och Inera förvaltningen/CGI på både underskriftstjänsten och IdPn så håll Display name till ett minimum om det är möjligt.

5. Logisk separation av kunder.

Både Stödtjänsten och underskriftstjänsten är så kallade multitenanta tjänster där en miljö klarar av att logiskt separera många kunder. Samma sätt som dagens Inera IdP:n hanterar från en infrastruktur flera Service Providers (Sp).

5.1. Stödtjänsten:

Den är tänkt att finnas en eller flera per organisation. Om ni tänker er hur det ser ut på andra myndigheter så står det t ex jag gör underskrift för Skatteverket om jag är inne och gör moms deklaration och även om jag gör inkomstskattedeklaration. Dvs av Skatteverkets alla e-tjänster så använder de samma Display name. 

Men det går utmärkt att använda då samma stödtjänst för att även från samma städtjänst infrastruktur stödja andra organisationer så som Min myndighetspost och Kronofogdemyndigheten. I stödtjänsten så baserar det sig på Profilhanteringen att respektive e-tjänst i sitt API anrop till stödtjänsten anropar sin profil.

Vill man här separera mer än på denna nivå så sätter man upp egna stödtjänster eller använder sig av en Signaturproxy som också är vanlig väg från ett arkitekturperspektiv på stora organisationer att använda sig av för att dels enklare kunna migrera mellan olika stödtjänster framöver, men även bygge kanske en koncerngemensam ”mina underskrifter” portal som då kanske enkelt kan visas på ”mina sidor” om man har flöden mellan ett antal e-tjänster och har användare som kan få signerings uppdrag sända till sig, och då kanske får en notifiering via t ex min myndighetspost.

5.2. underskriftstjänsten.

Denna infrastruktur sköter CGI, så det är inget ni som e-tjänst kommer behöva tänka så mycket på.

underskriftstjänsten agerar då Service provider för underskrift för er som organisation, men i och med att Display name står i metadatan så blir separationen per Display name som sätts upp.

Det innebär att underskriftstjänsten kommer behöva sätta upp lika många kunder som deras begrepp är, Men är i SAML språk lika med separata entityID.

5.3. IdP:n

IdP:n för signering är logiskt skild jämfört med IdP:n för Identifiering och det eftersom Metadatan skiljer sig så mycket mellan SAMBI och Sweden connect samt att man i och med de nya Autentiserings metoderna ändå måste separera dessa som skilda IdP:er.

Det nya begreppet IdP för signering som kommer framöver användas för att beskriva relationen per EntityID på underskriftstjänsten och de tre olika endpoint Idp:er för signering Ineras IdP tillhandahåller.

Förklarande bild:

Det ser kanske komplext ut med massa pilar från lagret underskriftstjänst och det är mycket konfiguration där, samt då på IdP delen. Men för en integrerande e-tjänst så blir bilden lite enklare.
Men i och med att man ska dels stödja flera olika inloggningsmetoder, samt då kanske även från samma stödtjänst fler e-tjänster, och även underskrifts attributs profiler (som ovan bild inte visar) så blir det många användarfall som man måste kunna hålla isär framförallt vid test.

6. Underskriftsprofiler:

Det menar vi vilka attribut som kommer in i underskriftscertifikatet och som då baserar sig på de profiler som digitaliseringsmyndigheten definierat för inloggning.

• Natural Personal Identity with Civic Registration Number (Personnummer)
• Organizational Identity for Natural Persons
• Natural Person Identity with HSA-ID

Detta dokument förklarar inte hur en e-tjänst gör i sitt API anrop för att kunna anropa för att få respektive profil, och inte heller hur själva underskriftscertifikatet ser ut. Men det är viktigt att organisationen förstå i ett tidigt skede de möjligheter man har som e-tjänst och organisation samt vilken information en får från ett underskrivet dokument.

7. Information som behövs i beställningen från er som kund.

• Organisationsnamn (Legal identity):___________________________
• Displaynamn 1:_____________________
• Displaynamn 2:_____________________
• Displaynamn x:_____________________
• Vill kunna ha underskriftsprofil:
  • Natural Personal Identity with Civic Registration Number (Personnummer)
  • Organizational Identity for Natural Persons
  • Natural Person Identity with HSA-ID
• Metadata för e-tjänst/Stödtjänst: Ange en URL varifrån metadata kan hämtas.  Alternativt bifoga metadata som XML i ärendet eller ange en annan väg att föra över metadata*

* Om ni som kund köper hjälp av CGI som kommer de hjälpa er att ta fram denna ur CGI’s stödtjänst.

8. Efter beställning får ni följande information

1. URL för metadata
2. URL:er för anrop