Denna SAD beskriver arkitekturen för Underskriftstjänsten - Webb och API. För motsvarande beskrivning av artikeln Underskriftstjänsten - Bas, se Underskriftstjänsten - Bas

Innehållsförteckning

Revisionshistorik

1. Inledning

1.1. Nomenklatur

Nomenklaturen är hämtad från Referensarkitektur för identitet och åtkomst eller Referensarkitektur för elektronisk underskrift och stämpel om termen inte återfinns i listan nedan. För övriga begrepp, se SAD Underskriftstjänsten.

1.2.   Syfte

Detta dokument syftar till att beskriva de funktioner som Underskriftstjänsten – Webb och API tillhandahåller, och hur denna funktionalitet tillgängliggörs via Underskriftstjänsten – Webb och API och dess gränssnitt mot anslutande system.

Underskriftstjänsten – Webb och API använder Underskriftstjänsten - elektronisk underskrift (P4) för att signera samt validera dokument enligt PAdES standarden, se vidare Profilhantering (Ref. P3) vilken signaturtyp som gäller per underskriftsprofil. Använd PAdES variant återfinns i den valideringsrapport under "Basic Policy" som skapas då signeringsuppdraget har blivit undertecknat av alla signatärer.

1.3. Avgränsningar

Detta dokument har inte som syfte att beskriva Underskriftstjänsten – Webb och API underliggande arkitektur eller logiska uppbyggnad.

1.4.  Målgrupp

De huvudsakliga målgrupperna för detta dokument är: systemförvaltare och systemarkitekter.

1.5. Referenser

2. Arkitekturell översikt

Följande förenklade arkitekturell översikt visar de viktigaste gränssnitten som berör Underskriftstjänsten - Webb och API. För en mer detaljerad bild se SAD - Underskriftstjänsten - Inera - Identitet och åtkomst (Ref. P7), där Underskriftstjänsten - Webb och API motsvarar en e-tjänst med inbyggd stödtjänst.

Tekniska gränssnitt mellan delsystem/komponenter

Följande bild visar gränssnitten mellan komponenterna som tillsammans realiserar funktionen Underskriftstjänsten – Webb och API.

SAML 2.0 Web SSO används vid legitimering av signatär. Endast privata e-legitimationer, utländska e-legitimationer (eIDAS) och SITHS eID stöds. För mer information om eIDAS se eIDAS - Underskriftstjänsten Webb och API (Ref. P11)

Sweden Connect Federated Signing DSS används vid underskrift.

SMTP protokollet används för att skicka aviseringar med e-post via en SMTP server.

HTTPS/JSON används i kommunikationen med API'et.

Utbyte av SAML metadata

2.1.  Arkitekturella mål

• Följsamhet mot Digitaliseringsmyndighetens specifikationer kring fristående underskriftstjänst
• Följsamhet mot Ineras Referensarkitekturer (Ref. P5)

2.2. Prioriterade områden

• Användning av underskriftsprofil vid skapande av signeringsuppdrag
• Tillämpning av vald underskriftsprofil vid underskrift
• Underskrift med SITHS eID och privata e-legitimationer

2.3.  Följsamhet till T-boken

N/A

3. Användargränssnitt

Underskriftstjänsten – Webb och API är en applikation som presenterar ett användargränssnitt där både Administratör och signatärer kan logga in. Administratör loggar in och skapar signeringsuppdrag genom att ladda upp de dokument som ska undertecknas, anger vilka som ska underteckna dokument samt initierar underskriftsflödet.

Signatärer får en avisering om att ett undertecknande krävs och de kan då logga in i Underskriftstjänsten – Webb och API, läsa dokumentet och sen antingen underteckna alternativt neka en underteckning av dokumentet.

För handhavade information samt övriga bilder på användargränssnittet, se Användarhandboken (Ref. P6).

Via användargränssnittet kan administratören ladda ner en valideringsrapport samt en händelselogg för ett avslutat signeringsuppdrag. För mer information gällande dessa dokument, se Händelselogg och Valideringsrapport (Ref. P10).

4. Användningsfall - Webb och API

4.1. Användningsfall - Översikt

Översikt över de mest signifikanta användningsfallen.

4.2. Aktörsinformation

4.3. Logisk realisering av användningsfall - Webb

4.3.1.  AF1 - Administratör skapar signeringsuppdrag

4.3.1.1. Textuell beskrivning

Flödet startar när en administratör ska skapa ett signeringsuppdrag.

1. Administratören loggar in i Underskriftstjänsten - Webb med sin e-legitimation. Endast personer med SITHS e-legitimation kan agera administrator.
2. Underskriftstjänsten - Webb visar tillgängliga signeringsuppdrag.
3. Administratören skapar ett signeringsuppdrag genom att:
   1. ange en rubrik
   2. ange en optionell beskrivning
   3. ange giltighetstid för signeringsuppdraget, om ingen giltighetstid anges används ett konfigurerat standard värde.
   4. ange gallringstid för signeringsuppdraget, om ingen gallringstid anges används ett konfigurerat standard värde.
   5. ange de dokument som skall undertecknas genom att ladda upp ett eller flera dokument
   6. eventuellt ladda upp en eller flera bilagor som inte ska undertecknas men som bifogas för ytterligande information
   7. ange den eller de signatärer som ska underteckna dokumenten, för varje signatär anges:
      1. Namn
      2. E-postadress
      3. Underskriftsprofil samt eventuellt ett eller flera av de attribut som vald underskriftsprofil kräver
   8. ange om undertecknandet skall ske sekventiellt eller parallellt
      1. i ett sekventiell underskriftsflöde kan endast en signatär i taget underteckna. Det är först när aktuell signatär har undertecknat signeringsuppdraget som nästa signatär i kedjan får en avisering om att ett signeringsuppdrag finns tillgängligt. 
      2. i ett parallellt underskriftsflöde  får alla signatärer en avisering samtidigt om att ett signeringsuppdrag är tillgängligt. Viss logik finns för att förhindra att fler än en signatär kan underteckna åt gången.
      3. Alla signatärer får även en avisering då signeringsuppdraget är undertecknat av alla signatärer.
4. Underskriftstjänsten - Webb sparar det skapade signeringsuppdraget tillsammans med alla uppladdade dokumentet som administratören lagt till i signeringsuppdraget.
5. Underskriftstjänsten - Webb skickar aviseringar till administratören samt berörda signatärer.

4.3.1.2. Realisering

4.3.2. AF2 - Signatär undertecknar signeringsuppdrag

4.3.2.1. Textuell beskrivning

Flödet startar när en signatär har fått en avisering (e-post) angående att det finns ett tillgängligt signeringsuppdrag som ska undertecknas.

1. Signatären klickar på den länk som finns angivet i det aviseringsmejl som signatären har fått angående det nya signeringsuppdraget.
   1. Mejlet innehåller även information om vilken typ av legitimering som behövs för att kunna underteckna signeringsuppdraget.
2. Signatären skickas vidare till Underskriftstjänsten - Webb där denna får legitimera sig med sin e-legitimation.
   1. Om signeringsuppdraget kräver ett medarbetaruppdrag och signatären loggar in utan ett medarbetaruppdrag visas ett felmeddelande. Signatären måste då logga ut och logga in igen med ett medarbetaruppdrag. 
   2. Om signeringsuppdraget kräver ett specifikt medarbetaruppdrag och signatären loggar in med fel medarbetaruppdrag visas ett felmeddelande. Signatären måste då logga ut och logga in igen med rätt medarbetaruppdrag.
   3. Om signeringsuppdraget kräver ett specifikt HSAid och signatären loggar in med fel HSAid visas ett felmeddelande. Signatären måste då logga ut och logga in igen med rätt HSAid.
   4. Om signatären legitimerar sig med en e-legitimation som inte kan användas för att underteckna signeringsuppdraget visas ett felmeddelande. Signatären måste då logga ut och försöka igen.
3. Underskriftstjänsten - Webb visar signeringsuppdraget, de dokument som skall undertecknas samt eventuellt bilagor för den inloggade signatären.
4. Signatären  granskar dokumenten och går vidare för att underteckna.
5. Underskriftstjänsten - Webb förbereder dokumenten för underskrift.
   1. Underskriftstjänsten - Webb väljer vilken logisk IdP som skall anropas utifrån signeringsuppdragets underskriftsprofil.
   2. Underskriftstjänsten - Webb extraherar användarattribut från den initiala autentiseringen för att i SignRequest till Underskriftstjänsten kunna peka ut vem som skall utföra underskriften.
6. Underskriftstjänsten - Webb skickar underskriftsbegäran (DSS SignRequest) till Underskriftstjänsten. SignRequest innehåller bland annat vilket data som skall signeras(<csig:SignTasks>), vem som skall utföra underskriften (<csig:Signer>), det underskriftsmeddelande som skall visas för Signatären (SignMessage), krav på tillitsnivå för legitimeringen, samt vilket underskriftsprofil som önskas (<csig:AuthnProfile>).
7. Underskriftstjänsten utför undertecknandet, se Underskriftstjänstens användningsfall.
8. Underskriftstjänsten - Webb får tillbaka undertecknat dokument data.
9. Om fler signatärer ska underteckna:
   1. vid ett sekventiellt underskriftsflöde aviseras nästa signatär i kedjan och exekveringen avbryts
   2. vid ett parallellt underskriftsflöde sker ingen avisering då alla signatärer redan har fått en avisering och exekveringen avbryts
10. När alla signatärer har undertecknat signeringsuppdraget validerar Underskriftstjänsten - Webb signaturen på dokumenten och skapar en valideringsrapport.
11. Underskriftstjänsten - Webb loggar alla händelser som rör signeringsuppdraget under hela underskriftsflödet. Denna händelselogg kan laddas ner av administratören när signeringsuppdraget är avslutat.
12. Underskriftstjänsten - Webb aviserar administratören att signeringsuppdraget är underskrivet.
13. Underskriftstjänsten - Webb aviserar eventuella intressenter att signeringsuppdraget är underskrivet.
14. Underskriftstjänsten - Webb aviserar de signatärer som ännu ej fått avisering att signeringsuppdraget är underskrivet.
15. Signatärer kan nu ladda ner/hämta de underskrivna dokumenten.
16. Underskriftstjänsten - Webb gallrar/raderar signeringsuppdraget inklusive alla dokument efter vald gallringstid.

4.3.2.2. Realisering

4.3.3. AF3 - Administratör hämtar underskrivna dokument

4.3.3.1. Textuell beskrivning

Flödet startar när ett signeringsuppdrag är avslutat och administratören vill hämta de underskrivna dokumenten.

1. Administratören loggar in i Underskriftstjänsten - Webb med sin e-legitimation. Endast personer med SITHS e-legitimation kan agera administratör.
2. Underskriftstjänsten - Webb visar en lista med signeringsuppdrag sorterade på status.
3. Administratören väljer det avslutade uppdraget
4. Administratören väljer det eller de dokument som ska laddas ner.
5. Administratören kan i detta skede även ta bort/radera signeringsuppdraget, vilket leder till att även alla dokument raderas.

4.3.3.2. Realisering

4.3.4. AF4 - Alternativflöde - Signatär avbryter underskriftsflödet

4.3.4.1. Textuell beskrivning

Flödet startar när en signatär har fått en avisering (e-post) angående att det finns ett tillgängligt signeringsuppdrag som ska undertecknas.

1. Signatären klickar på den länk som finns angivet i det aviseringsmejlet som signatären har fått angående det nya signeringsuppdraget.
   1. Mejlet innehåller även information om vilken typ av legitimering som behövs för att kunna underteckna signeringsuppdraget.
2. Signatären skickas vidare till Underskriftstjänsten - Webb där denna får legitimera sig med sin e-legitimation.
   1. Om signatären legitimerar sig med en e-legitimation som inte kan användas för att underteckna signeringsuppdraget visas ett felmeddelande. Signatären måste då logga ut och försöka igen.
3. Underskriftstjänsten - Webb visar signeringsuppdraget och de dokument som skall undertecknas för den inloggade signatären.
4. Signatären  granskar dokumenten och väljer att avbryta. Signatären måste ange en kommenter och där ange skälet till varför signatären väljer att avbryta underskriftsflödet.
5. Om fler signatärer förväntas underteckna signeringsuppdraget:
   1. vid ett sekventiellt underskriftsflöde aviseras all signatärer som redan har undertecknat om att signeringsuppdraget är avbrutet/återkallat.
   2. vid ett parallellt underskriftsflöde aviseras alla övriga signatärer om att signeringsuppdraget är avbrutet/återkallat.
6. Underskriftstjänsten - Webb loggar alla händelser som rör signeringsuppdraget under hela underskriftsflödet. Denna händelselogg kan laddas ner när signeringsuppdraget är avslutat/avbrutet.
7. Underskriftstjänsten - Webb aviserar administratören att signeringsuppdraget är avbrutet.
8. Underskriftstjänsten - Webb aviserar eventuella intressenter att signeringsuppdraget är avbrutet.
9. Underskriftstjänsten - Webb gallrar/raderar signeringsuppdraget inklusive alla dokument efter vald gallringstid.

4.3.4.2. Realisering

4.3.5. AF5 Alternativflöde : Visa signeringsuppdrag som intressent

4.3.5.1. Textuell beskrivning

Flödet startar när en intressent får en avisering om att ett signeringsuppdrag är signerat alternativt avbrutet.

1. Intressenten får en avisering om att det finns information om ett signeringsuppdrag tillgängligt.
2. Intressenten  loggar in i Underskriftstjänsten - Webb via den direkt länk som anges i aviseringsmeddelandet.
3. Underskriftstjänsten - Webb hämtar signeringsuppdraget och visar det för intressenten.
4. Om signeringsuppdraget är signerat, kan intressenten hämta ner de signerade dokumenten.
   1. Om signeringsuppdraget är avbrutet kan intressenten enbart läsa uppdragsinformationen.
5. Intressenten  loggar ut från Underskriftstjänsten - Webb.

4.3.5.2. Realisering

4.3.6. AF6 - Exportering av faktureringsunderlag

4.3.6.1. Textuell beskrivning

Flödet startar när en systemadministratör vill exportera faktureingsunderlag.

1. Systemadministratören loggar in i Underskriftstjänsten - Webb med sin e-legitimation. Endast personer med SITHS e-legitimation kan agera systemadministratör.
2. Underskriftstjänsten - Webb visar första sidan med en menyrad för val av inställningssidan.
3. Systemadministratören väljer menyvalet Inställningar för att visa inställningssidan.
4. Systemadministratören väljer menyvalet att exportera faktureringsunderlag.
5. Systemadministratören väljer ett från- och tilldatum för vilken datumintervall exporteringen skall ske.
6. Systemadministratören väljer att exportera faktureringsunderlaget. En CSV-fil laddas ner.
7. Systemadministratören loggar ut.

4.3.6.2. Realisering

4.4. Logisk realisering av användningsfall - API

4.4.1. AF API-1 Skapa signeringsuppdrag

4.4.1.1. Textuell beskrivning

Flödet startar när en användare via ett verksamhetssystem vill skapa ett signeringsuppdrag.

1. Användaren loggar in i verksamhetssystemet. 
2. Verksamhetssystemet inhämtar nödvändig information från användaren om uppdraget och dess signatärer.
3. Verksamhetssystemet  anropar API'et för att skapa ett signeringsuppdrag. Anropet innehåller följande information om uppdraget:
   1. Rubrik på uppdraget
   2. Optionell beskrivning av uppdraget
   3. LOA 3 nivå
   4. Typ av signeringsflöde: sekventiellt eller parallellt flöde. Vid ett sekventiellt flöde sker varje avisering och underskrift separat och i följd, medans vid ett parallellt flöde får alla signatärer aviseringar samtidigt och alla kan därefter skriva under i princip samtidigt.
   5. Lista med signatärer. Minst en signatär måste anges med följande information:
      1. Underskriftsprofil, för möjliga värden se Profilhantering (Ref P3).
      2. Användarid. Användarid'et beror på vilken underskriftsprofil som används.
      3. Typ av aviseringsmetod
   6. Optionell giltighetstid. Om ingen gilttighetstid anges, används en förkonfigurerat giltighetstid.
4. Underskriftstjänsten - API skapar signeringsuppdarget och returnerar ett unikt id för det nya signeringsuppdraget.
5. Verksamhetssystemet sparar undan id'et på signeringsuppdragets för att vid ett senare tillfälle hämta status på uppdraget.
6. För varje dokument som ska adderas till signeringsuppdraget sker följande flöde:
   1. Verksamhetssystemet  anropar API'et för att skapa en dokument entitet. För varje dokument entitet kan följande anges:
      1. Om dokumentet ska signeras eller om det ska hanteras som en bilaga som inte blir signerat.
      2. Optionell rubrik
      3. Optionell beskrivning
      4. Filnamn
      5. MIME typ. Normalt "application/pdf".
      6. Optionellt korrelations id. Korrelations id kan användas för att tagga varje dokument då dokumentet får ett nytt id vid varje underskrift. Korrelations id'et förändras ej.
   2. Verksamhetssystemet  anropar API'et för att ladda upp dokumentinnehållet. 
7. Verksamhetssystemet  anropar API'et för att starta signeringsflödet.
8. Underskriftstjänsten - API aviserar signatärer
   1. Vid ett sekventiellt flöde sker enbart aviseringen till nästkommande signatär
   2. Vid ett parallellt flöde sker aviseringen till alla signatärer samtidigt
9. Signatären alternativ signatärerna signering, se AF2 - Signatär undertecknar signeringsuppdrag.
10. När signeringsuppdraget är signerat alternativt avbrutet ändrar Underskriftstjänsten - API statusen på uppdraget till relevant status. Ingen mer handling utförs från Underskriftstjänsten - API.
11. Verksamhetssystemet hämtar status på uppdraget utifrån det sparande id'et på signeringsuppdraget och hämtar signerade dokument om uppdraget är signerat.
12. Verksamhetssystemet kan avsluta med att ta bort uppdraget, alternativt gallras uppdraget av Underskriftstjänsten - API efter en förutbestämd tid.

4.4.1.2. Realisering

4.4.2. AF API-1.1 Alternativflöde: Skapa signeringsuppdrag med intressenter

När ett signeringsuppdrag skapas via API anrop finns ingen direkt ägare av uppdraget förutom verksamhetssystemet, vilket gör att enbart signatärerna får behörighet att komma åt uppdraget.

Om andra användare ska ges behörighet till uppdraget måste dessa anges både som intressenter och aviseringsmottagare när uppdraget skapas. Användarens HSAid anges som intressent och användarens e-postadress anger för avisering.

4.4.2.1. Textuell beskrivning

Flödet startar när en användare via ett verksamhetssystem vill skapa ett signeringsuppdrag.

1. Användaren loggar in i verksamhetssystemet. 
2. Verksamhetssystemet inhämtar nödvändig information om uppdraget, dess signatärer och de intressenter som är intresserade av uppdraget. En intressent får aviseringar då ett uppdrag är signerat alternativt avbrutet och ges även tillgång till att läsa innehåller i signeringsuppdraget.
3. Verksamhetssystemet  anropar API'et för att skapa ett signeringsuppdrag. Anropet innehåller följande information om uppdraget:
   1. Rubrik på uppdraget
   2. Optionell beskrivning av uppdraget
   3. LOA 3 nivå
   4. Typ av signeringsflöde: sekventiellt eller parallellt flöde. Vid ett sekventiellt flöde sker varje avisering och underskrift separat och i följd, medans vid ett parallellt flöde får alla signatärer aviseringar samtidigt och alla kan därefter skriva under i princip samtidigt.
   5. Lista med signatärer. Minst en signatär måste anges med följande information:
      1. Underskriftsprofil, för möjliga värden se Profilhantering (Ref P3).
      2. Användarid. Användarid'et beror på vilken underskriftsprofil som används.
      3. Typ av aviseringsmetod
   6. Optionell giltighetstid. Om ingen gilttighetstid anges, används en förkonfigurerat giltighetstid.
   7. Lista med intressenter. Varje intressent ska anges som:
      1. mottagare av aviseringar (notifier med e-postadress) och
      2. som en intressent (stakeholder) med HSAid för att få rättigheter till att läsa uppdraget.
4. Underskriftstjänsten - API skapar signeringsuppdarget och returnerar ett unikt id för det nya signeringsuppdraget.
5. Verksamhetssystemet sparar undan id'et på signeringsuppdragets för att vid ett senare tillfälle hämta status på uppdraget.
6. För varje dokument som ska adderas till signeringsuppdraget sker följande flöde:
   1. Verksamhetssystemet  anropar API'et för att skapa en dokument entitet. För varje dokument entitet kan följande anges:
      1. Om dokumentet ska signeras eller om det ska hanteras som en bilaga som inte blir signerat.
      2. Optionell rubrik
      3. Optionell beskrivning
      4. Optionellt filnamn
      5. MIME typ. Normalt "application/pdf".
      6. Optionellt korrelations id. Korrelations id kan användas för att tagga varje dokument då dokumentet får ett nytt id vid varje underskrift. Korrelations id'et förändras ej.
   2. Verksamhetssystemet  anropar API'et för att ladda upp dokumentinnehållet. 
7. Verksamhetssystemet  anropar API'et för att starta signeringsflödet.
8. Underskriftstjänsten - API aviserar signatärer
   1. Vid ett sekventiellt flöde sker enbart aviseringen till nästkommande signatär
   2. Vid ett parallellt flöde sker aviseringen till alla signatärer samtidigt
9. Signatären alternativ signatärerna signering, se AF2 - Signatär undertecknar signeringsuppdrag.
10. När signeringsuppdraget är signerat alternativt avbrutet ändrar Underskriftstjänsten - API statusen på uppdraget till relevant status. Ingen mer handling utförs från Underskriftstjänsten - API.
    1. Förutom den aviseringen som sker i AF2 - Signatär undertecknar signeringsuppdrag får även alla intressenter an avisering huruvida updraget är signerat eller avbrutet. Aviseringsmeddelandet innehåller även en direkt länk till signeringsuppdraget.
11. Verksamhetssystemet hämtar status på uppdraget utifrån det sparande id'et på signeringsuppdraget och hämtar signerade dokument om uppdraget är signerat.
12. Verksamhetssystemet kan avsluta med att ta bort uppdraget, alternativt gallras uppdraget av Underskriftstjänsten - API efter en förutbestämd tid.

4.4.2.2. Realisering

4.4.3. AF API-1.2 Alternativflöde: Skapa signeringsuppdrag med automatisk statusuppdatering (callback)

4.4.3.1. Textuell beskrivning

Flödet startar när en användare via ett verksamhetssystem vill skapa ett signeringsuppdrag.

1. Användaren loggar in i verksamhetssystemet. 
2. Verksamhetssystemet inhämtar nödvändig information om uppdraget och dess signatärer.
3. Verksamhetssystemet  anropar API'et för att skapa ett signeringsuppdrag. Anropet innehåller följande information om uppdraget:
   1. Rubrik på uppdraget
   2. Optionell beskrivning av uppdraget
   3. LOA 3 nivå
   4. Typ av signeringsflöde: sekventiellt eller parallellt flöde. Vid ett sekventiellt flöde sker varje avisering och underskrift separat och i följd, medans vid ett parallellt flöde får alla signatärer aviseringar samtidigt och alla kan därefter skriva under i princip samtidigt.
   5. Lista med signatärer. Minst en signatär måste anges med följande information:
      1. Underskriftsprofil, för möjliga värden se Profilhantering (Ref P3).
      2. Användarid. Användarid'et beror på vilken underskriftsprofil som används.
      3. Typ av aviseringsmetod
   6. Optionell giltighetstid. Om ingen gilttighetstid anges, används en förkonfigurerat giltighetstid.
   7. En URL till verksamhetssystemet som ska anropas av Underskriftstjänsten - API vid statusuppdateringar för att informera verksamhetssystemet när statusändringar görs på uppdraget. Följande statusuppdateringar skickas:
      1. Signeringsflödet är initierat
      2. En signatär har skrivit under uppdraget
      3. Uppdraget är signerat
      4. Uppdraget är avbrutet
4. Underskriftstjänsten - API skapar signeringsuppdarget och returnerar ett unikt id för det nya signeringsuppdraget.
5. Verksamhetssystemet sparar undan id'et på signeringsuppdragets för att vid ett senare tillfälle hämta status på uppdraget.
6. För varje dokument som ska adderas till signeringsuppdraget sker följande flöde:
   1. Verksamhetssystemet  anropar API'et för att skapa en dokument entitet. För varje dokument entitet kan följande anges:
      1. Om dokumentet ska signeras eller om det ska hanteras som en bilaga som inte blir signerat.
      2. Optionell rubrik
      3. Optionell beskrivning
      4. Optionellt filnamn
      5. MIME typ. Normalt "application/pdf".
      6. Optionellt korrelations id. Korrelations id kan användas för att tagga varje dokument då dokumentet får ett nytt id vid varje underskrift. Korrelations id'et förändras ej.
   2. Verksamhetssystemet  anropar API'et för att ladda upp dokumentinnehållet. 
7. Verksamhetssystemet  anropar API'et för att starta signeringsflödet.
8. Underskriftstjänsten - API anropar den callback som verksamhetssystemet har angivit för att informera att signeringsflödet är startat.
9. Underskriftstjänsten - API aviserar signatärer
   1. Vid ett sekventiellt flöde sker enbart aviseringen till nästkommande signatär
   2. Vid ett parallellt flöde sker aviseringen till alla signatärer samtidigt
10. Signatären alternativ signatärerna signering, se AF2 - Signatär undertecknar signeringsuppdrag.
    1. Vid varje underskrift anropar Underskriftstjänsten - API den callback som verksamhetssystemet har angivit för att informera att en signatär har skrivit under uppdraget.
11. När signeringsuppdraget är signerat alternativt avbrutet ändrar Underskriftstjänsten - API statusen på uppdraget till relevant status.
    1. Underskriftstjänsten - API anropar den callback som verksamhetssystemet har angivit för att informera om att signeringsuppdraget är signerat alternativt avbrutet.
12. Verksamhetssystemet hämtar status på uppdraget utifrån det sparande id'et på signeringsuppdraget och hämtar signerade dokument om uppdraget är signerat.
13. Verksamhetssystemet kan avsluta med att ta bort uppdraget, alternativt gallras uppdarget av Underskriftstjänsten - API efter en förutbestämd tid.

4.4.3.2. Realisering

4.4.4. AF API-2 Visa signeringsuppdrag

4.4.4.1. Textuell beskrivning

Flödet startar när en användare vill visa ett signeringsuppdrag genom verksamhetssystemet. Hur denna åtgärd initieras beror på verksamhetssystemet. En signatär får alltid en avisering om att ett signeringsuppdrag finns tillgängligt för signering och visningen av signeringsuppdraget i detta fall sker utanför verksamhetssystemet direkt via Underskriftstjänsten - API. Detta användningsfall beskriver snarare fallet när verksamhetssystemet ska hämta information om signeringsuppdraget för att kunna visa informationen i dess egen regi för den användare som efterfrågar informationen.

1. Användaren loggar in i verksamhetssystemet och väljer att visa signeringsuppdrag.
   1. Verksamhetssystemet kan här välja att visa alla signeringsuppdrag alternativt inhämta information från administartören om ett specifikt signeringsuppdrag.
2. Verksamhetssystemet anropar API'et för att:
   1. hämta en fullständig lista med pågående och avslutande signeringsuppdrag, alternativt
   2. hämtar ett specifikt signeringsuppdrag
3. Underskriftstjänsten - API får anropet och returnerar en lista med pågående och avbrutna signeringsuppdrag som verksamhetssystemet har behörighet till.
4. Verksamhetssystemet visas upp informationen för användaren.
5. Användare loggar ut ur verksamhetssystemet.

4.4.4.2. Realisering

4.4.5. AF API-2.1 Alternativflöde : Visa signeringsuppdrag som intressent

4.4.5.1. Textuell beskrivning

Flödet startar när en intressent får en avisering om att ett signeringsuppdrag är signerat alternativt avbrutet.

1. Intressenten får en avisering om att det finns information om ett signeringsuppdrag tillgängligt.
2. Intressenten  loggar in i Underskriftstjänsten - API via den direkt länk som anges i aviseringsmeddelandet.
3. Underskriftstjänsten - API hämtar signeringsuppdraget och visar det för intressenten.
4. Om signeringsuppdraget är signerat, kan intressenten hämta ner de signerade dokumenten.
   1. Om signeringsuppdraget är avbrutet kan intressenten enbart läsa uppdragsinformationen.
5. Intressenten  loggar ut från Underskriftstjänsten - API.

4.4.5.2. Realisering

4.4.6. AF API-3 Avbryta signeringsuppdrag

4.4.6.1. Textuell beskrivning

Flödet startar när en användare vill avbryta ett signeringsuppdrag genom verksamhetssystemet. Hur denna åtgärd initieras beror på verksamhetssystemet.

1. Flödet startar med AF API-2 Visa signeringsuppdrag.
2. Användare väljer ett uppdrag och ger verksamhetssystemet order om att avbryta/återkalla uppdraget.
3. Verksamhetssystemet anropar API'et med ett specifikt id på det signeringsuppdfrag som ska avbrytas/återkallas.
4. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan uppdraget avbryts/återkallas.
5. Verksamhetssystemet hämtar händelseloggen för signeringsuppdraget och hanterar den.
6. Verksamhetssystemet visas att signeringsuppdraget är avbrutet/återkallat för användaren.
7. Användare loggar ut ur verksamhetssystemet.

4.4.6.2. Realisering

4.4.7. AF API-3.1 Alternativflöde : Avbryta och radera signeringsuppdrag

4.4.7.1. Textuell beskrivning

Flödet startar när en användare vill avbryta och radera ett signeringsuppdrag genom verksamhetssystemet. Hur denna åtgärd initieras beror på verksamhetssystemet.

1. Flödet startar med AF API-2 Visa signeringsuppdrag.
2. Användare väljer ett uppdrag och ger verksamhetssystemet order om att avbryta/återkalla uppdraget.
3. Verksamhetssystemet anropar API'et med ett specifikt id på det signeringsuppdfrag som ska avbrytas/återkallas.
4. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan uppdraget avbryts/återkallas.
5. Verksamhetssystemet anropar API'et med samma specifika id på signeringsuppdraget som ovan för att radera uppdraget.
6. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan uppdraget raderas.
7. Verksamhetssystemet visas att signeringsuppdraget är raderat för användaren.
8. Användare loggar ut ur verksamhetssystemet.

4.4.7.2. Realisering

4.4.8. AF API-4 Hämtning av signerade dokument

4.4.8.1. Textuell beskrivning

Flödet startar när en användare vill hämta de dokument som är signerade på ett signeringsuppdrag som är underskrivet av alla signatärer genom verksamhetssystemet. Hur denna åtgärd initieras beror på verksamhetssystemet.

1. Användaren loggar in i verksamhetssystemet och väljer att visa signeringsuppdrag.
   1. Verksamhetssystemet kan här välja att visa alla signeringsuppdrag alternativt inhämta information från administartören om ett specifikt signeringsuppdrag.
2. Verksamhetssystemet anropar API'et för att:
   1. hämta en fullständig lista med pågående och avslutande signeringsuppdrag, alternativt
   2. hämtar ett specifikt signeringsuppdrag
3. Underskriftstjänsten - API får anropet och returnerar en lista med pågående och avbrutna signeringsuppdrag som verksamhetssystemet har behörighet till.
4. Verksamhetssystemet visas upp informationen för användaren
5. Användaren väljer exempelvis att visa enbart signerade uppdrag i verksamhetssystemet.
6. Verksamhetssystemet anropar API'et med ett specifikt id på signeringsuppdraget för att hämta uppdragsinformation.
7. Underskriftstjänsten - API får anropet och kontrollerar behörigheten på verksamhetssystemet innan uppdragsinformation returneras.
8. Verksamhetssystemet visar uppdragsinformationen inklusive ingående dokument för användaren.
9. För varje signerat dokument som användaren vill ladda ner:
   1. användaren väljer ett signerat dokument att ladda ner
   2. Verksamhetssystemet anropar API'et för att ladda ner dokumentinnehållet.
   3. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan dokumentinnehållet returneras.
   4. Verksamhetssystemet hanterar dokumentinnehållet.
10. Om Användaren vill ladda ner valideringsrapporten sker detta genom:
    1. Användaren väljer att ladda ner/hämta valideringsrapporten
    2. Verksamhetssystemet anropar API'et för att ladda ner valideringsrapporten.
    3. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan valideringsrapporten returneras.
11. Om Användaren vill ladda ner händelserapporten sker detta genom:
    1. Användaren väljer att ladda ner/hämta händelserapporten 
    2. Verksamhetssystemet anropar API'et för att ladda ner listan med händelser.
    3. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan händelserapporten  skapas och returneras.
12. Användare loggar ut ur verksamhetssystemet.

4.4.8.2. Realisering

4.4.9. AF API-5 Hantera mottagen automatisk statusuppdatering (callback)

4.4.9.1. Textuell beskrivning

Flödet startar när en händelse som ska leda till en statusuppdatering ska skickas ut till verksamhetssystemet av Underskriftstjänsten - API.

En av följande händelser leder till en statusuppdatering:

• Signeringsflödet startas
• En signatär skriver under
• En signatär avbryter
• Signeringsuppdraget är signerat av alla signatärer

En automatiskt statusuppdatering kräver att verksamhetssystemet har registrerat en URL till verksamhetssystemet som kan anropas av Underskriftstjänsten - API enligt AF API-1.2.

1. Flödet startar när ett signeringsuppdrag ändrar status till en status som leder till en automatiskt statusuppdatering, se ovan för möjliga händelsetyper.
2. Underskriftstjänsten - API kontrollerar om det finns en statusuppdaterings URL registrerad på signeringsuppdraget.
3. Underskriftstjänsten - API inhämtar information om statusuppdraget och skapar ett statusmeddelande som innehåller:
   1. Signeringsuppdragetsidentitet
   2. Typ av statusändring
   3. Tidsstämpel
4. Underskriftstjänsten - API anropar den statusuppdaterings URL som angivits
5. Verksamhetssystemet får anropet och inhämtar uppgifter om signeringsuppdraget. Inga detaljer om uppdraget ges i meddelandet.
6. Verksamhetssystemet anropar API'et med det givna signeringsuppdrags id't för att hämta information om signeringsuppdraget.
7. Underskriftstjänsten - API får anropet och kontrollerar behörigheten till uppdraget innan information om uppdraget returneras.
8. Verksamhetssystemet hanterar returnerad information, exempelvis:
   1. Om signeringsuppdraget är signerat kan de signerade dokumenten hämtas
   2. Om signeringsuppdraget är signerat kan valideringsrapporten hämtas
   3. Om signeringsuppdraget är signerat kan händelserapporten hämtas

4.4.9.2. Realisering

5. Icke-funktionella krav

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig.

6. Teknisk lösning

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig.

7. Säkerhet

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig.

8. Informationshantering

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig.

9. Driftaspekter

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig.