Teknisk arkitektur och standarder

Arkitekturprinciper

e-Legitimation bygger på en modell där organisationen kan utfärda en arbetsrelaterad digital identitet som användaren bär i IDOmbud-appen. Identiteten ska kunna användas för stark autentisering utan att organisationen behöver luta sig mot privata e-legitimationer eller bygga separata inloggningslösningar för varje applikation.

Den tekniska utgångspunkten är att identiteten ska vara:

• stark nog för arbetsrelaterad inloggning
• portabel mellan olika digitala flöden
• möjlig att verifiera kryptografiskt
• möjlig att spärra eller återkalla när den inte längre ska gälla
• selektiv, så att endast relevant information delas i ett specifikt användningsfall

EUDI Wallet och Verifiable Credentials

Arkitekturen ligger nära EU:s EUDI Wallet-modell och öppna standarder för Verifiable Credentials. I praktiken innebär det att identitetsuppgifter kan utfärdas som verifierbara digitala intyg och presenteras kontrollerat när användaren behöver legitimera sig digitalt.

För organisationen ger det en mer flexibel identitetsmodell än lösningar där all information måste hämtas direkt från en central katalog eller från en nationell privat e-legitimation. För användaren innebär det en mobil, wallet-nära upplevelse där e-legitimationen kan presenteras när den behövs.

Passkey som bärare

e-Legitimation behöver inte vara låst till ett enda sätt att bäras eller presenteras. I många flöden kan passkey användas som bärare av den arbetsrelaterade identiteten. Det gör att användaren kan autentisera sig med en etablerad, lösenordsfri metod samtidigt som organisationen behåller kontroll över vilken identitet som har utfärdats, vilken tillit som krävs och när åtkomsten ska upphöra.

I ett sådant upplägg blir passkey inte en separat inloggningslösning vid sidan av e-Legitimation, utan en praktisk bärare i samma modell. Organisationen kan använda passkey för stark autentisering och samtidigt knyta inloggningen till den identitet, livscykel och styrning som IDOmbud hanterar.

En utgiven e-legitimation på passkey kan användas i de scenarier där passkeys stöds. Det kan till exempel vara inloggning från en Windows-dator med Windows Hello, från macOS eller iOS med Touch ID eller Face ID, från Android med plattformens inbyggda passkey-stöd eller från en webbläsare som stödjer passkeys. På så sätt kan samma organisationsstyrda identitet användas i etablerade lösenordsfria flöden utan att organisationen behöver skapa en separat identitetsmodell för varje klienttyp.

Det är särskilt relevant när användarupplevelsen behöver vara enkel, snabb och lösenordsfri, men där organisationen ändå behöver kunna styra utfärdande, återkallelse och koppling till egna behörighetsmodeller.

Autentiseringsflöde

I ett förenklat flöde fungerar modellen så här:

1. Organisationen utfärdar en e-legitimation till användaren.
2. e-Legitimationen placeras i IDOmbud-appen eller knyts till en passkey-baserad bärare.
3. När användaren loggar in presenteras e-legitimationen via den valda bäraren.
4. IdP:n verifierar intyget och kontrollerar att det är giltigt.
5. Resultatet används i inloggningsflödet och kan skickas vidare till rätt applikation.

Det gör att e-legitimationen kan bära organisationens identitet medan åtkomstlagret hanterar federation, policyer och anslutning till applikationer.

Privacy by Design och selektiv informationsdelning

e-Legitimation är utformad enligt principen Privacy by Design. Det innebär att lösningen ska kunna stödja selektiv informationsdelning, där användaren bara delar den information som faktiskt behövs i den aktuella situationen.

Det skiljer sig från mer traditionella identitetsmodeller där hela identitetspaket ofta exponeras som en följd av inloggningen. När presentationen kan styras mer selektivt blir det lättare att anpassa informationsdelningen till det faktiska behovet och samtidigt minska onödig exponering av data.

Samverkan med Fortified ID Access

När e-Legitimation används tillsammans med Fortified ID Access blir Access det lager som kopplar den starka identiteten till applikationer, federation och policyer.

I ett sådant flöde kan Access till exempel:

• initiera en identifiering från webbläsaren
• visa deeplink eller QR-kod beroende på användarens enhet
• ta emot en signerad presentation från den mobila appen
• verifiera typ av intyg, nödvändiga attribut, giltighet och revokeringsstatus
• släppa vidare rätt identitetskontext till målplattformen

Det gör att e-legitimationen kan användas som identitetsbärare samtidigt som Access står för integrationslogik och kontroll över hur identiteten används vidare.

Tekniska byggblock

De viktigaste tekniska byggblocken är:

• wallet-, app- eller passkey-baserad användarupplevelse för identifiering
• verifierbara intyg som kan presenteras och kontrolleras kryptografiskt
• verifieringslogik i åtkomstlagret för att kontrollera presentation, attribut och tillitskrav
• kontroll av spärr och återkallelse för att säkerställa att en identitet fortfarande är giltig
• koppling mellan den verifierade identiteten och organisationens lokala konto- eller behörighetsmodell

Relaterat innehåll

• e-Legitimation
• Utfärdande, administration och återkallelse
• Autentisering