...
Motsvarar alltså den "inre styrningen" – den operativa policyn som omsätter de nationella reglerna i praktiken.
| Perspektiv | Styrning av federationsinfrastrukturen | OIDF-policy (Federationsområdesansvarig) |
|---|
| Nivå | Nationell, övergripande | Federationskontext, operativ |
| Ansvarig | Ledningsaktör | Federationsoperatör |
| Syfte | Gemensam styrning och samordning | Säkerställa efterlevnad av gemensamma regler inom ett Federationskontext |
| Fokus | Ramar, standarder, roller, tillsyn | Implementering, validering, metadata och tillitsmärken |
| Typ av krav | Strategiska och juridiska | Tekniska och operativa |
Anslutning till federationsinfrastrukturen och till federationskontext
...
Genom denna roll kan operatören även stödja interoperabilitet mellan olika tillitsankartjänster och kontexter, genom att samordna hur metadata publiceras och hur valideringstjänster används.
| Aspekt | Anslutning till federationsinfrastrukturen | Anslutning till federationskontext |
|---|
| Syfte | Tekniskt tillträde till infrastrukturen | Tillit och policy för en viss samverkan |
| Hanteras av | Anslutningsoperatör | Tillitsankartjänst (och tillitsmärkestjänster) via Anslutningsoperatör |
| Resultat | Komponentens metadata blir verifierbar och sökbar | Komponentens tillhörighet till ett visst federationskontext fastställs |
| Typ av tillit | Teknisk tillit (signerad metadata) | Organisatorisk och policybaserad tillit |
För att helheten ska fungera krävs att interoperabilitet bevaras både inom den tekniska federationsinfrastrukturen och mellan olika federationskontexter.
...
| Modell | HTA | NTA | DTA med TBE | IIMAR |
|---|
| Länk | HTA | NTA | DTA | IIMAR |
| Skiss | 1: Hierarchical Trust Anchors (HTA)
| 2: Nested Trust Anchors (NTA)
| 3: Disconnected Trust Anchors with External Key Distribution (DTA)
| 4: Interlinked Intermediates with Multi-Anchor Resolution (IIMAR)
|
| 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 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: |
OIDF stöd | Fullt stöd enligt OIDF specifikation | Stöds ej Ej fullt stöds enligt OIDF specifikationen | Stöds ej enligt specifikationen | Fullt stöd enligt OIDF specifikation |
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 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.
|
...