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.
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.
| 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. Kompatibel med standard OpenID Federation.
Cons: All onboarding och tillitsmärkeshantering måste gå via den nationella Tillitsankartjänsten → ökad administration. Begränsad flexibilitet för federationer att göra egna anpassningar. Risk för flaskhalsar och tung styrning
| Beskrivning: Varje federation har en egen Tillitsankartjänst, men dessa pekar uppåt mot en nationell Tillitsankartjänst.
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: Validerare måste kunna hantera flera nivåer i tillitskedjan. 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 mellan nivåer
| Beskrivning: Varje federation har en helt fristående Tillitsankartjänst. 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 Tillitsankartjänster länkas ihop genom gemensamma Anslutningstjänster (shared Intermediates).
Pros: Möjliggör interoperabilitet utan att Tillitsankartjänster 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 Anslutningstjänst.
Cons: Komplexitet ökar när fler Tillitsankartjänster ansluts. Intermediates måste hantera flera överordnade. Tillitsmärkeshantering blir splittrad – olika utfall beroende på vilken Tillitsankartjänst man validerar mot. Risk för policyfragmentering mellan kedjor - Entiteter och Uppslags-/verifieringstjänster måste kunna hantera flera parallella tillitskedjor, vilket ökar krav på implementation och kan ge olika valideringsresultat beroende på vald kedja
|
OIDF Policyhantering |
|
|
|
|
Ena Governance |
|
|
|
|
Konsekvenser för Ledningaktör |
|
|
|
|
Konsekvenser för Federationsoperatör |
|
|
|
|
Konsekvenser för Anslutningsoperatör |
|
|
|
|
Konsekvenser för federationsmedlemmar |
|
|
|
|
OIDF Trust Anchor Policy
Ena
Ena NTA
Påbörjat utkast på hur NTA-strukturen skulle kunna se ut i Ena |
Ena IIMAR
Påbörjat utkast på hur IIMAR-strukturen skulle kunna se ut i Ena |
