OIDF Arkitektur

En Tillitsankartjänst utgör den yttersta källan till tillit och skapar därmed ett federationskontext – en gemensam teknisk ram där anslutna tjänster kan verifieras och ingå i samma tillitssammanhang. Inom ett sådant federationskontext kan aktörer dessutom använda tillitsmärken för att definiera vilka tillitsskapande krav som är uppfyllda. På så sätt kan man etablera olika samverkanskontexter där informationsutbyte sker på villkor som är anpassade efter behov och kravbild, utan att frångå den gemensamma tekniska grunden.

Detta väcker frågan om hur många Tillitsankartjänster som behövs och varför en modell med flera Tillitsankartjänster skulle kunna vara en fördel i en nationell federationsinfrastruktur.

Arkitekturella drivkrafter bakom val av modell

Här ska vi beskriva drivkrafterna bakom valet av modell

Nedan hämtat från Kap 1.1.1 Ena IAM - sammanhållen identitet- och behörighetshantering

Ökad kostnadseffektivitet
Kostnadseffektivitet genom användning av etablerade standarder samt återanvändning av tidigare gjorda investeringar. Infrastrukturen och dess komponenter bygger i stor utsträckning på väl etablerade standarder, som OAuth2, vilket möjliggör användande av standardprodukter. Infrastrukturen är även anpassad för att kunna knytas till befintliga lösningar för exempelvis autentisering av användare, för att minimera behov av förändring då befintliga it-lösningar ansluta till infrastrukturen. Att kunna minska dagens manuella administration av medarbetare i digitala tjänster hos andra huvudmän och istället på ett tillitsfullt och standardiserat sätt kunna dela behörighetsgrundande information som underlag för åtkomst har stor potential ökad säkerhet och minskade administrativa kostnader.
Behov av gränsöverskridande samverkan
Digital samverkan sker alltmer mellan olika sektorer, domäner och aktörer. En gemensam teknisk grund minskar behovet av kostsamma specialanpassningar för dessa situationer samt möjliggör att tillit och interoperabilitet kan skalas över gränser.
Minskad integrationsbörda
Genom att etablera en gemensam federationsinfrastruktur kan nya tillämpningar återanvända befintliga mekanismer för autentisering, åtkomsthantering och etablering av tillit – istället för att varje organisation eller samverkansinitiativ behöver utveckla egna lösningar.
Främjande av innovation och decentralisering
Genom att tillhandahålla en stabil och bred teknisk plattform kan olika verksamheter – offentliga såväl som privata – bygga egna tjänster och lösningar som samtidigt är fullt kompatibla med federationens ramverk.
Stöd för behovsdriven förändring över tid
Arkitekturen möjliggör att olika delar (tillitshantering, teknisk federation, tillämpningar) kan vidareutvecklas i olika takt utan att skapa ömsesidiga beroenden som hämmar förändring.
Stöd för utveckling i ett heterogent landskap
Arkitekturen är utformad för att fungera i en miljö där olika organisationer befinner sig på olika nivåer av mognad, har olika tekniska förutsättningar och arbetar med varierande processer och system. Tjänster och digitala förmågor utvecklas i den takt och omfattning som organisationers resurser och prioriteringar tillåter. Detta främjar både flexibilitet och långsiktig samverkan, utan att de mest avancerade aktörerna behöver bromsa sin utveckling eller de mindre erfarna riskerar att hamna utanför.

Varför flera Tillitsankartjänster aka olika federationskontext?

Att organisera en nationell federationsinfrastruktur kring flera Tillitsankartjänster (Trust Anchor enligt OIDF specifikationen) skapar flexibilitet och möjlighet till anpassning för de olika behov som finns i samverkan.

Olika tillitsmodeller och säkerhetsstyrning
All samverkan behöver inte bygga på samma tillitsramverk. Vissa sammanhang kräver styrning enligt ISO 27000 med ledningssystem för informationssäkerhet, medan andra skulle kunna bygga på helt andra regelverk eller kravbilder. Genom att tillåta flera Tillitsankartjänster kan man tillämpa olika tillitsmodeller parallellt, men ändå hålla ihop tekniskt via en gemensam federationsinfrastruktur.
Olika tekniska protokoll och standarder
All samverkan behöver inte ske med OIDC eller OAuth. Det finns etablerade miljöer som bygger på SAML, eller andra standarder. Om all metadata blandas i en och samma federationskontext riskerar infrastrukturen att bli svårhanterlig. Med flera Tillitsankartjänster kan man istället skapa tydliga avgränsningar där varje Tillitsankartjänst ansvarar för sitt tekniska område och sina policyer.
Avgränsade samverkanskontexter
All samverkan sker inte mellan alla tjänster. I praktiken är det vanligt att grupper av tjänster främst utbyter information med varandra utifrån gemensamma behov och krav. För vissa typer av tjänster, som exempelvis intygstjänster, är det däremot vanligt att de används i flera olika samverkanskontexter eftersom de tillför generella förmågor som många behöver. Andra komponenter, som API:er eller klienter, är oftare knutna till ett mer specifikt behov av samverkan. Genom att införa flera Tillitsankartjänster kan man hantera denna variation: intygstjänster kan återanvändas brett, medan mer specialiserade komponenter kan styras inom en snävare kontext.

Offentlig sektors rådighet i Federationsinfrastrukturen

För att offentlig sektor ska kunna ha rådighet över den federativa infrastrukturen behöver vi gemensamt ta ställning till vilken nivå av ansvar som bör ligga hos myndigheter. Är det rimligt att just tillitsankartjänsterna förvaltas av myndigheter, eftersom de utgör själva fundamentet för ett federationskontext och kräver stabilitet och legitimitet i offentlig förvaltning?

En möjlig modell är att myndigheter även ansvarar för den första nivån av underordnade anslutningstjänster. Det skulle skapa en gemensam bas där aktörer kan ansluta sig under tydliga ramar, medan andra anslutningstjänster längre ut i hierarkin kan utvecklas av olika aktörer. På så sätt kan offentlig rådighet kombineras med flexibilitet och innovationskraft.

Samtidigt är det viktigt att komma ihåg att den ledningsaktör som ansvarar för infrastrukturen ändå kan styra genom att avgöra vilka tillitsankartjänster som accepteras och får ”anslutas” in i helheten. Även om flera aktörer driver olika tillitsankartjänster kan rådighet därför upprätthållas genom de överordnade regler och policies som styr helheten.

Frågan vi behöver diskutera är alltså: var bör gränsdragningen gå mellan offentlig styrning och mångfalden av andra aktörer, för att både tillit, robusthet och utvecklingsmöjligheter ska kunna säkerställas över tid?

OIDF Trust models

Dokumentet beskriver fyra arkitektoniska modeller för hur en nationell OpenID Federation kan byggas upp och hur tillit fördelas mellan Trust Anchors, Intermediates och deltagande aktörer. Varje modell har olika styrkor och svagheter när det gäller centralisering, autonomi, interoperabilitet och enkelhet i validering.

Mer information

Mer information, inklusive detaljerade exempel och jämförelser, finns i projektets GitHub-repo: https://github.com/s-hal/oidf-architecture/blob/main/oidf-trust-models.md

Modell	HTA	NTA	DTA med TBE	IIMAR
Länk	HTA	NTA	DTA	IIMAR
Skiss
Kort beskrivning	Centraliserad modell med en nationell Trust Anchor som rot. All policy styrs uppifrån och ned via Intermediates. Enkel och enhetlig validering men begränsad flexibilitet.	Varje federation har en egen Trust Anchor som pekar på den nationella Trust Anchorn. Balans mellan lokal autonomi och nationell styrning, med möjlighet till både lokal och central validering.	Decentraliserad modell där varje federation driver en oberoende Trust Anchor. En Trusted Bridging Entity (TBE) distribuerar nycklar utanför OIDF-specen. Ger hög autonomi men kräver separat governance och samordning.	Flera oberoende Trust Anchors kan dela Intermediates, vilket möjliggör interoperabilitet utan nyckeldistribution mellan Trust Anchors. Mycket flexibel men med ökad komplexitet och risk för fragmenterad policy.
Inom Ena	Beskrivning: En nationell Tillitsankartjänst som är rot. Befintliga federationer är Anslutningstjänster. Pros: Centraliserad styrning → enhetlig policy och tydlig ansvarsfördelning. Tillitskedjor blir enkla, deterministiska och alltid förankrade i samma Tillitsankartjänst → enkel validering. Cons: All onboarding och tillitsmärkeshantering måste gå via den nationella Tillitsankartjänsten → ökad administration. Begränsad flexibilitet för federationer (Fed A, Fed B) att göra egna anpassningar. Risk för flaskhalsar och tung styrning	Beskrivning: Varje federation har en egen Trust Anchor, men dessa pekar uppåt mot en nationell Trust Anchor. Pros: Varje federation har egen kontroll över sin Tillitsankartjänst och sina nycklar. Möjliggör anpassning till lokala/regionala krav samtidigt som nationella regler följs. Stödjer integration av självständiga federationer. Cross-federation validering blir enklare (alla slutar i samma nationella TA). Cons: Vid validering måste entiteter kunna hantera flera Tillitsankartjänster Lokal Nationell Risk för olika valideringsresultat beroende på om man startar i lokal eller nationell Tillitsankartjänst. Kräver tydlig samordning så att policys inte krockar	Beskrivning: Varje federation har en helt fristående Trust Anchor. Nycklar publiceras via en extern Trusted Bridging Entity (TBE). Ingen hierarki. Pros: Full autonomi för varje federation. Möjlighet till selektiv interoperabilitet utan gemensam rot. Flexibel, olika federationer kan utvecklas självständigt. Cons: TBE ligger utanför OpenID Federation-specifikationen → kräver separat styrning och standardisering. Risk för fragmentering om inte stark governance upprättas. Ingen automatisk tillitskedja → validerare måste hantera flera nyckeluppsättningar parallellt. Större administrativ börda vid onboarding och nyckelhantering	Beskrivning: Flera oberoende Trust Anchor länkas ihop genom gemensamma shared Intermediates). Pros: Möjliggör interoperabilitet för underordnade utan att Trust Anchors behöver underordna sig varandra. Flexibel anslutning – samma Anslutningstjänst kan knytas till flera Tillitsankartjänster. Stödjer gradvis integration mellan federationer. Entiteter kan delta i flera federationer via samma Intermediate. Cons: Komplexitet ökar när fler Trust Anchors ansluts. Intermediates måste hantera flera överordnade. Risk för policyfragmentering mellan Trust Anchors Entiteter och Uppslags-/verifieringstjänster måste kunna hantera flera Trust Anchors, vilket ökar krav på implementation,
OIDF Policyhantering	All policy definieras i den nationella Trust Anchor och slår igenom top-down. Policys blir enhetliga och entydiga, vilket gör validering enkelt och konsekvent. Begränsad möjlighet för underordnade federationer att lägga till egna krav – det riskerar att krocka med den centrala styrningen	Policy kan definieras både i den nationella Trust Anchor och i lokala federationers Tillitsankartjänster. Om validering görs mot en lokal TA → lokala regler gäller. Om validering görs via den nationella TA → både nationella och lokala regler slår igenom. Risk för inkonsekvent policy tillämpning beroende på vilken väg en verifiering går.	Ingen gemensam policykedja i federationens metadata. Varje Tillitsankartjänst definierar sin egen policy helt självständigt. För att möjliggöra interoperabilitet måste TBE (Trusted Bridging Entity) eller motsvarande governance-funktion definiera gemensamma minimikrav för att få vara med. All faktisk policytillämpning blir lokalt scope:ad till respektive TA.	Varje Trust Anchor behåller sin egen policy och publicerar den separat. Indermediates som är delade måste hantera och förena policyer från flera olika Trust Anchors. Vid validering måste en Trust Anchor väljas → policyn som tillämpas beror på vilken Trust Anchor som är slutpunkt. Risk för divergens: samma Intermediate kan ge olika valideringsresultat beroende på vilken kedja som följs.

Ena

Modell	HTA	NTA	DTA med TBE	IIMAR
Ena Governance	Behövs främst för att underlätta tillämpning och förståelse av den centrala policyn – t.ex. stödmaterial, vägledningar och gemensamma processer för anslutning. Ena:s roll blir alltså att stötta införande och praktisk användning, snarare än att kompensera för tekniska brister i styrningen	Ena behöver ge vägledning, profileringar och exempel på hur lokala federationer ska komplettera den nationella policyn. Även processer för konflikthantering behövs, eftersom OIDF-policy mekanismer inte räcker för att undvika interoperabilitet mellan NTA och LTA	Ena måste etablera governance, gemensamma minimikrav, och koordinering av nyckelpublicering och policy. Här blir mjuk styrning den enda möjligheten att skapa interoperabilitet.	Ena måste stötta genom att samordna hur Intermediates ska publicera metadata och tillitsmärken på ett enhetligt sätt över flera TA:er. Även vägledning för hur validering ska göras när flera Tillitsankartjänster är möjliga för validering av tillit.
Konsekvenser för Ledningaktör	Säkerställa att aktörer förstår och kan tillämpa policyn i praktiken, genom vägledningar, stöd i onboarding och gemensamma processer.	Ge ramar för hur lokala federationers policy ska komplettera den nationella. Ta fram profileringar, processer och konflikthantering som jämkar nivåerna.		Samordna hur Intermediates ska hantera och publicera policy från flera Tillitsankartjänster. Säkerställa gemensam hantering av tillitsmärken och ge riktlinjer för multipla valideringskedjor.
Konsekvenser för nationell federationsoperatör	Säkerställa att anslutna Anslutningoperatörer förstår och följer nationell policy, hantera onboarding och incidentprocesser, samt vara stödjande i praktisk drift.			N/A
Konsekvenser för Federationsoperatör		Översätta nationell policy till lokal policy, Stödja medlemmar i att följa nationell och lokal policy, och rapportera konflikter uppåt till Ledningsaktören.		Delta och Koordinera mellan olika Federationsoperatörer för att säkerställa konsekvent publicering av nationella Tillitsoperatörer Ge vägledning om valideringsskillnader och stödja Anslutningoperatörer i att hantera motstridiga krav.
Konsekvenser för Anslutningsoperatör
Konsekvenser för federationsmedlemmar

Sammanställning plus och minus (Inera)

Följande lista ÄR ETT FÖRSTA UTKAST PÅ EN SAMMANSTÄLLNING av plus och minus för de olika modellerna. Den är baserad på tolkningar OCH BRISTANDE FÖRSTÅELSE av de olika modellerna. Dessutom finns det stor risk att slutsatserna i listan påverkas av vägval inom respektive modell. Dock tror vi att informationen om modellerna behöver kokas ner till slutsatser på denna nivå och att det är enklare med denna typ av plus/minus lista än pros/cons i tabellen ovan.

ATT-GÖRA 1: ensa de olika slutsatserna om respektive modell så att överlappande slutsatser rensas bort.

ATT-GÖRA 2: balansera upp plus och minus. Just nu är det nästan bara plus på NTA…

ATT-GÖRA 3: kvalitetsgranska slutsatserna!!!

HTA

NTA

DTA m. TBE

IIMAR

Plus

Plus: Enkelt, fint och tydligt.

Enklast att genomföra tekniskt, både att bygga upp och att nyttja då valideringen är enklare än alternativen.
Att spåra eventuella incidenter blir också enklare i denna modell.
Enklare att förklara.
Att lista alla tillitsmärkesutdelare på ett ställe gör det enklare att hitta dem.
Det kommer att bli lättare att hålla ihop policies.

Lokala tillitsmärken stöds, dvs federad hantering, medan samverkan mellan federativa kontext endast kan basera sig på nationellt godkända märken.

Digg kan lägga ut federationstillitsankare på sektorsmyndigheter utan att det försvårar interoperabilitet över sektorsgränser.

Lyckas vi skapa bra gemensamma tillitsmärken bör inte behovet av specifika tillitsmärken i respektive sub-tillitsankare bli lika stort.

Fortfarande förhållandevis enkel modell men med ökad flexibilitet jämfört med HTA.
- Den stora fördelen med denna modell är en högre graden av flexibilitet.
- Kan snabbare och enklare möta områdets eventuella specifika behov.
I vissa användningsfall kan tilliten lösas i den lokala federationen utan inblandning på central nivå:
- Underlättar incidenthanteringen
- Ökar robustheten
Ökad robusthet då enskilt federativt kontext kan fungera autonomt.
Löser problemet med samverkan mellan aktörer i olika verksamhetsområde. [Exempel: Migrationsverket, AF, FK, SKV, CSN, Transportstyrelsen, A-kassorna och Pensionsmyndigheten kan använda de gemensamma nationella tillitsmärkena för GIF och ha interoperabilitet över flera verksamhetsområden].
Jämnare fördelning av arbetsbördan för att underhålla federationen, fler organisationer kan bidra.
- Digg torde få minst administration i denna modell.
Om vi väljer att kapsla in befintliga federationer som sub-tillitsankare i NTA får vi en tydligare modell för hur vi kan ta tillvara på tidigare investeringar i federationer.
- [Skolfederation, Sambi och andra befintliga federationer kan vid behov bli en federation i nya infrastrukturen utan större förändringar. Internt behöver man inte förändra så mycket och EFI gör att anslutna parter får identitets och behörighetshantering med andra verksamhetsområden. Inera skulle (om vi kommer fram till att det är en bra ide) kunna skapa ett tillitsankare för Inera och tillitsmärke för HSA-bas samt HSA-extra (andra gruppen är de som uppfyller fem bör-kraven i HSA Tillitsramverk 5.0 som krävs av EHM). Får enklare övergång till framtida gemensamma tillitsmärken. EHM skulle initialt kunna acceptera både tillitsmärke Sambi och HSA-extra men kan på sikt gå över till ett (eller flera) gemensamma tillitsmärken.]

Stor flexibilitet
Ökad robusthet då enskilt federativt kontext kan fungera autonomt.

Förmodligen mest flexibel(?) - men eftersom vi inte fullt ut klarar bedöma vad modellen innebär så vet vi inte.

Minus

Brist på flexibilitet kan leda till att infrastrukturen inte svarar upp mot behoven efter en tid.
Centralstyrningen ger mindre utrymme för egna varianter, vilket kommer att uppfattas som negativt.
Mer arbete för ledningsaktören.
Problematiskt att centralisera hantering av samverkanskontext. Risk för att mindre samverkanskontexter får hanteras utan tillitsmärken. Kan bli ohållbart.
Om man vill representera avtal eller medlemskap i ett specifikt samverkanskontext behöver ansvarig samordnare för varje samverkanskontext använda en trust mark issuer som är registrerad/godkänd av tillitsankare

Mer komplex validering än HTA.
Risk för fragmentering om nationella och lokala policies inte koordineras.
Valideringsutfall kan skilja sig mellan lokal och nationell TA
Högre krav på samordning för att undvika konflikter.

Minimal harmonisering mellan federativa kontext – interfederation.
Riskerar cementera fast fragmentering och motverka harmonisering. Skulle i så fall inte öka samhällets framtida digitaliseringstakt.
- Så stor risk att alternativet kan utgå.

Upplevs som krånglig. Torde bli svår att förklara.
Kanske mindre risk för fragmentering än DTA men tror fortfarande att skillnader mellan olika kontext riskerar cementeras fast, och att målet om harmonisering missas.

Ena modeller

Hur mappar vald modell(er) mot våra principer

Ena NTA

OIDF Trust Anchor Policy

Nationell Policy

Lokal Policy

Ena Governance

Utkast!

Påbörjat utkast på hur NTA-strukturen skulle kunna se ut i Ena

Ena IIMAR