...
En stor skillnad gentemot signering med NetID är att underskriften inte sker med det signerings-certifikat, PIN-kod för underskrift (PIN2), som användaren har på sitt SITHS-kort. Istället legitimerar sig användaren, PIN-kod för legitimering (PIN1), via en IdP, och det är sedan underskriftstjänsten Underskriftstjänsten som använder uppgifter från denna legitimering för att skapa upp ett engångs-signerings-certifikat som sedan ligger till grund för underskriften.
...
 |
| Genom att använda Chrome så erhålls det nya underskriftsflödet per automatik. Detta medför att journalsystemens nuvarande inbäddade webbläsare, Internet Explorer, behöver bytas ut. I dagsläget är flödet testad testat med Chrome men bör även fungera med andra Chromium-baserade webbläsare. |
 |
| Krävs för inloggning till tjänsten, samt för |
 |
| Ny autentiseringsklient som används vid legitimering vid underskrift i nya flödet. Används vid app-växlingen. Länk för nedladdning av autentiseringsklient |
...
I flödet för signering med Fristående Underskriftstjänst fristående underskriftstjänst kommer användarens dator att kommunicera med fyra (4) olika tjänster/servrar. För att flödet ska fungera krävs det således att dessa tjänster går att nå från användarens dator.
Tjänst/Server | Beskrivning | Adress |
|---|---|---|
Webcert | Användaren loggar in i Webcert med sin webbläsare. |
|
Fristående Underskriftstjänstunderskriftstjänst | Användarens webbläsare kommer ansluta till denna tjänst i flödet. |
|
IdP för legitimering vid underskrift | Användarens webbläsare kommer ansluta till denna tjänst i flödet. |
|
Server för autentiseringsklient |
|
|
...
Den nya underskriftfunktionen som kommer bli tillgänglig i Webcert kommer använda s.k. app-växling för att öppna det program där användaren anger sin PIN-kod för legitimering (PIN1). Detta är en ny autentiseringsklient som tagits fram inom SITHS. Vidare i texten kommer denna benämnas SITHS eID AutentieringsklientAutentiseringsklient
Om man ser till användarflödet så är de flesta redan vana vid denna typ av app-växling, då det vanligtvis sker på samma sätt när man använder BankID eller Mobilt BankID. Dvs användarens webbläsare är ansvarig för att öppna det program där PIN-koden skall anges.
...
1: Användaren har loggat in i Webcert med SITHS-kort och har skrivit ett intyg som är klart att signera. Användaren klickar på |
 |
2: Webcert dirigerar användarens webbläsare till Underskriftstjänsten med information om den data som ska signeras. Ingen dialog visas för användaren (webbläsaren visar vit bakgrund). |
|
3: Underskriftstjänsten dirigerar användarens webbläsare till Ineras IdP med begäran om att legitimera användaren för underskrift. IdP’n visar en dialog och försöker samtidigt starta Det är i detta steg som den s.k. app-växlingen sker och där användarens webbläsare behöver ha rättigheter för att öppna program via protokollet Om Autentiseringsklienten Notera att kravet gällande app-växling gäller oavsett om programmet öppnas per automatik eller genom att manuellt klicka på länken. |
 |
4:
En dialog visas för användaren med information om vad som ska signeras. Användaren anger sin PIN-kod för legitimering (PIN1) och klickar Autentiseringsklienten |
 |
5: Användarens webbläsare dirigeras tillbaka till Webcert via Underskriftstjänsten. Webcert visar dialog med signerat intyg, eller felmeddelande om signering misslyckades. |
|
...
Följande ger en proof-of-concept på hur man kan tillåta SITHS-protokollet att exekvera/app-växla vid användning av CefSharp. (CefSharp är baserat på Chromium Embedded Framwork och kan användas för att integrera en webbläsare i en C#-applikation).
Givetvis skiljer sig implementationen mellan alla olika journalsystem, så nedan exempel är enbart tänkt som en fingervisning på hur det kan göras i just denna implementationen av inbäddad webbläsare.
...