| Krav-ID | Kravgrupp | Krav | Anslutningsoperatör | Federationsoperatör | Vägledning |
|---|---|---|---|---|---|
| O.1 | Organisation och rättskapacitet | Aktör som tillhandahåller federationsinfrastrukturtjänst och som inte är ett offentligt organ ska drivas som registrerad juridisk person samt teckna och vidmakthålla för verksamheten erforderliga försäkringar. Aktören ska ha förmåga att bära risken för skadeståndsskyldighet och förfoga över tillräckliga ekonomiska medel för att kunna bedriva verksamheten under minst ett år. | Ja | Ja | Kravet innebär att en aktör som vill tillhandahålla en federationsinfrastrukturtjänst behöver kunna visa att organisationen är en tydlig och ansvarsbärande juridisk part. För privata aktörer innebär detta normalt registrerad juridisk person, ordnad ekonomi och relevanta försäkringar eller annan dokumenterad förmåga att bära ekonomiska risker. Syftet är att federationen, anslutna aktörer och förlitande parter ska kunna lita på att tjänsten kan drivas stabilt över tid och att ansvar kan utkrävas vid brister. |
| O.2 | Etablerad och operationell verksamhet | Aktör som tillhandahåller federationsinfrastrukturtjänst ska ha en etablerad verksamhet, vara fullt operationell i alla delar som omfattas av åtagandet inom federationen, samt vara väl insatt i de juridiska krav som ställs på aktören. | Ja | Ja | Kravet innebär att aktören inte bara ska ha en plan för tjänsten, utan kunna visa att verksamheten är införd, bemannad och operativ i de delar som omfattas av federationsåtagandet. För en aktör som befinner sig i pilotfas kan detta visas genom testdrift, dokumenterade pilotfall, revisionsspår och fungerande processer. Det viktiga är att kravuppfyllnad inte bara finns i presentationer, eftersom sådant mest värmer PowerPoint, inte federationer. |
| O.3 | Ledningssystem för informationssäkerhet | Aktör som tillhandahåller federationsinfrastrukturtjänst ska, för de delar av verksamheten som omfattas av åtagandet inom federationen, ha inrättat ett ledningssystem för informationssäkerhet som i tillämpliga delar baseras på ISO/IEC 27001 eller motsvarande likvärdiga principer för ledning och styrning av informationssäkerhetsarbetet. Ledningssystemet ska minst omfatta att:
| Ja | Ja | Kravet innebär att aktören behöver ha ett sammanhållet arbetssätt för informationssäkerhet. Det behöver finnas dokumenterade processer för ansvar, riskhantering, incidenthantering, kontinuitet, resurser och förbättringsarbete. Aktören behöver inte nödvändigtvis vara ISO 27001-certifierad, men ska kunna visa att motsvarande principer tillämpas på den del av verksamheten som berör federationsinfrastrukturtjänsten. |
| O.4 | Underleverantörer | Aktör som lagt ut utförandet av en eller flera säkerhetskritiska processer på en underleverantör ska genom avtal definiera vilka kritiska processer underleverantören ansvarar för, vilka krav som är tillämpliga på dessa, samt säkerställa att underleverantören uppfyller kraven. | Ja | Ja | Kravet innebär att en aktör som använder underleverantörer fortfarande ansvarar för att federationskraven uppfylls. Det ska därför framgå vilka säkerhetskritiska delar som har lagts ut, vilka krav underleverantören ska följa och hur aktören följer upp detta. Externa aktörer bör redan tidigt analysera om drift-, moln-, säkerhets- eller supportleverantörer omfattas av kravet. |
| O.5 | Bevarande och spårbar dokumentation | Aktör som tillhandahåller federationsinfrastrukturtjänst ska, i tillämpliga delar, bevara:
| Ja | Ja | Kravet innebär att aktören behöver kunna visa i efterhand vad som har gjorts, av vem, när och på vilken grund. Dokumentation om avtal, anslutningar, metadata, nycklar, policyer, ändringar och säkerhetskontroller ska bevaras så att efterlevnad kan granskas och incidenter kan utredas. Informationen ska skyddas mot obehörig åtkomst och förvanskning. |
| O.6 | Bevarandetid | Tiden för bevarande enligt O.5 ska inte understiga fem år och material ska kunna tas fram i läsbar form under hela denna tid, såvida inte krav på gallring påkallas från integritetssynpunkt och har stöd i lag eller annan författning. | Ja | Ja | Kravet innebär att relevant dokumentation normalt ska kunna tas fram i läsbar form under minst fem år. Om dokumentationen innehåller personuppgifter behöver aktören också analysera gallring, rättslig grund och dataminimering. För offentliga aktörer kan arkivrättsliga krav påverka hur bevarande och gallring ska hanteras. |
| O.7 | Åtkomst till bevarad dokumentation och säkerhetsloggar | Aktör som tillhandahåller federationsinfrastrukturtjänst ska ha rutiner som säkerställer att endast särskilt bemyndigad personal har åtkomst till uppgifter som samlas in och bevaras enligt O.5. | Ja | Ja | Kravet innebär att aktören ska begränsa åtkomst till dokumentation, behandlingshistorik och säkerhetsloggar till särskilt utsedda personer. Åtkomst ska bygga på behov och roll. För säkerhetsloggar bör aktören särskilt beakta separation mellan den personal som administrerar systemen och den personal som kan läsa eller följa upp loggar. |
| O.8 | Internrevision och uppföljning | Aktör som tillhandahåller federationsinfrastrukturtjänst ska inrätta en oberoende funktion för internrevision som periodiskt granskar verksamheten. Internrevisorn ska vara oberoende i utförandet, ha den kompetens och erfarenhet som krävs och självständigt planera granskningen i en revisionsplan som sträcker sig över en treårsperiod. Revisionsmoment ska väljas utifrån risk- och väsentlighetsanalys och grundas i de krav som gäller för aktören inom federationen. Resultatet ska dokumenteras, avvikelser ska riskklassas och följas upp, och revisionsresultatet ska på begäran göras tillgängligt för ledningsaktör och federationsoperatör. | Ja | Ja | Kravet innebär att aktören ska ha en oberoende funktion som regelbundet granskar att verksamheten uppfyller kraven. Funktionen kan vara intern eller externt anlitad, men ska vara tillräckligt oberoende från den verksamhet som granskas. Externa aktörer bör planera för att revisionen blir återkommande, riskbaserad och dokumenterad i en flerårig revisionsplan. |
| O.9 | Fysisk säkerhet | För verksamheten centrala delar ska skyddas fysiskt mot skada till följd av miljörelaterade händelser, otillåten åtkomst eller andra yttre störningar. Tillträdeskontroll ska tillämpas så att åtkomst till känsliga utrymmen är begränsad till behörig personal, informationsbärande media förvaras, hanteras och avvecklas på ett säkert sätt, samt tillträde till skyddade utrymmen övervakas och kan följas upp. | Ja | Ja | Kravet innebär att utrustning, systemmiljöer och informationsbärande media som är centrala för federationsinfrastrukturtjänsten ska skyddas mot fysisk skada och obehörig åtkomst. För egen drift handlar det om lokaler, tillträdeskontroll och övervakning. Vid moln- eller outsourcad drift behöver aktören kunna visa hur motsvarande skydd uppnås genom avtal, kontrollrapporter eller certifieringar. |
| O.10 | Betrodda roller | Innan en person antar en roll som är av särskild betydelse för säkerheten ska aktören ha genomfört en lämplighetsprövning i syfte att förvissa sig om att personen kan anses vara pålitlig från säkerhetssynpunkt samt har de kvalifikationer, färdigheter och den utbildning som krävs för att utföra arbetsuppgifterna på ett säkert och betryggande sätt. | Ja | Ja | Kravet innebär att personer i säkerhetskritiska roller ska vara lämpliga, pålitliga och ha rätt kompetens. Exempel kan vara personer som hanterar kryptografiskt nyckelmaterial, ändrar metadata, administrerar tekniska komponenter eller har åtkomst till säkerhetsloggar. Prövningen ska vara proportionerlig och förenlig med arbetsrätt och dataskyddsregler. |
| O.11 | Behörig företrädare och kontaktpersoner | Aktör som tillhandahåller federationsinfrastrukturtjänst ska till federationsoperatören anmäla:
Aktören ska hålla uppgifterna aktuella. | Ja | Ja | Kravet innebär att aktören ska tala om för federationsoperatören vilka personer som får företräda aktören i federationsrelaterade frågor. En behörig företrädare är en person som har faktisk rätt att företräda aktören i anslutnings-, ändrings- eller avregistreringsärenden, exempelvis genom firmateckningsrätt, delegation eller fullmakt. Kontaktuppgifter ska hållas aktuella så att rätt person kan nås vid behov. |
| O.12 | Incidentkontakt och eskalering | Kontaktväg för säkerhetsincidenter ska vara bemannad under kontorstid med möjlighet att eskalera brådskande ärenden enligt fastställd incidentprocess. | Ja | Ja | Kravet innebär att aktören måste kunna ta emot och eskalera säkerhetsincidenter under kontorstid, och ha rutiner för hur brådskande ärenden hanteras. För mer kritiska roller eller produktionsmiljöer kan högre krav på beredskap behöva anges i särskilda tjänstenivåer eller federationskontextspecifika villkor. |
| O.13 | Personuppgifter och skyddade uppgifter | Aktör som inom ramen för federationssamverkan behandlar personuppgifter, inklusive skyddade uppgifter, ska ha dokumenterade rutiner för hur uppgifterna behandlas, skyddas, lämnas ut, bevaras och gallras. | Ja | Ja | Kravet innebär att aktören ska ha ordning på om, hur och varför personuppgifter behandlas i federationsinfrastrukturtjänsten. Rutinerna bör omfatta rättslig grund, åtkomst, skyddade personuppgifter, loggning, utlämnande, incidenthantering, bevarande och gallring. Detta är särskilt viktigt om metadata eller loggar kan innehålla personuppgifter. |
| O.14 | Avtal med underanslutna federationsmedlemmar | Anslutningsoperatören ska genom skriftligt avtal med underanslutna federationsmedlemmar reglera tillämpliga anslutningsvillkor, informationsägarskap, informationssäkerhetsansvar, ansvar för lämnade uppgifter och rätt till insyn eller uppföljning i den omfattning som krävs enligt regelverket. På begäran ska anslutningsoperatören tillhandahålla ledningsaktören de uppgifter som krävs för att verifiera att anslutningsoperatören uppfyller detta krav. | Ja | — | Kravet innebär att anslutningsoperatören behöver reglera relationen till de federationsmedlemmar som ansluts via operatörens tjänst. Avtalen ska tydliggöra ansvar för uppgifter, metadata, informationssäkerhet, uppföljning och efterlevnad. Kravet gäller underanslutna federationsmedlemmar, inte vanliga driftleverantörer. Den distinktionen är tråkig men nödvändig. |
| O.15 | Kontroll av anslutningsförutsättningar | Anslutningsoperatören ska säkerställa att anslutning av federationsmedlemmar endast sker när organisationen uppfyller de förutsättningar som anges i tillämplig krav på anslutning och regler för aktuell federationskontext. Genomförda kontroller ska dokumenteras. | Ja | — | Kravet innebär att anslutningsoperatören bara får ansluta organisationer som uppfyller de krav som gäller enligt aktuell anslutningspolicy och federationskontext. Operatören ska inte göra en obegränsad juridisk prövning, men ska genomföra de kontroller som regelverket kräver och dokumentera resultatet. |
| O.16 | Revision av underanslutningsprocessen | Anslutningsoperatörens internrevision ska omfatta de processer, kontroller och rutiner som används för att ansluta och förvalta underanslutna federationsmedlemmar. Urval och omfattning ska vara riskbaserade. | Ja | — | Kravet innebär att anslutningsoperatörens revision även ska omfatta hur operatören ansluter och följer upp underanslutna federationsmedlemmar. Det betyder inte att varje underansluten aktör alltid måste granskas varje år. Urval, djup och frekvens bör styras av risk, omfattning och tidigare avvikelser. |
| O.17 | Support och samverkan med federationsoperatören | Anslutningsoperatören ska ha en organiserad supportfunktion för underanslutna federationsmedlemmars anslutningsärenden samt delta i felsökning och incidentsamordning i ärenden som involverar flera anslutningsoperatörer eller federationsoperatören. | Ja | — | Kravet innebär att anslutningsoperatören ska ha en fungerande support- och samverkansförmåga för anslutningsrelaterade ärenden. Operatören behöver kunna stödja underanslutna medlemmar och delta i felsökning när problem berör flera aktörer i federationen. Exakt servicenivå bör framgå av särskild överenskommelse eller metodkrav. |
| O.18 | Icke-diskriminering | Anslutningsoperatören ska tillämpa fastställda anslutningskrav på ett sakligt, transparent och icke-diskriminerande sätt inom tillämplig federationskontext. | Ja | — | Kravet innebär att anslutningsoperatören ska tillämpa anslutningskraven sakligt och transparent. Organisationer som uppfyller kraven ska behandlas lika. Samtidigt hindrar kravet inte operatören från att neka eller pausa anslutning om krav inte är uppfyllda eller risknivån är oacceptabel enligt regelverket. |
| O.19 | Portabilitet av registrerad metadata | Anslutningsoperatören ska på federationsmedlemmens begäran lämna ut sådan metadata som registrerats för federationsmedlemmen enligt regelverkets krav i ett strukturerat och maskinläsbart format. Anslutningsoperatören får inte oskäligt försvåra federationsmedlemmens tillgång till sin egen registrerade metadata. | Ja | — | Kravet innebär att en federationsmedlem ska kunna få ut sin egen registrerade metadata i ett strukturerat och maskinläsbart format. Syftet är att minska inlåsning och underlätta byte av anslutningsoperatör. Utlämnande innebär däremot inte att metadata automatiskt blir godkänd i en annan federationskontext. |
| O.20 | Återanvändning i annan federationskontext | Återanvändning av anslutning, registrering eller metadata i annan federationskontext får endast ske om detta följer av uttrycklig bindande artefakt eller särskilt beslutad kontextregel och om tillämpliga krav är uppfyllda. | Ja | — | Kravet innebär att återanvändning av anslutning, registrering eller metadata i en annan federationskontext bara får ske när det uttryckligen är tillåtet. En aktör kan alltså inte utgå från att en godkänd anslutning i en kontext automatiskt gäller i en annan. Varje kontext kan ha egna risker, regler och policykrav. |
| O.21 | Kombinerade funktioner | Om en aktör eller teknisk tjänst realiserar flera federationsinfrastrukturfunktioner ska samtliga krav för respektive funktion vara tillämpliga, om inte annat uttryckligen anges i bindande artefakt. | Ja | Ja | Kravet innebär att en aktör som kombinerar flera roller, exempelvis anslutningstjänst och resolver eller trust anchor och resolver, behöver uppfylla kraven för samtliga funktioner. Det ska inte uppstå lägre krav bara för att flera funktioner paketeras i samma organisation eller tekniska miljö. |
| Krav-ID | Kravgrupp | Krav | Anslutningstjänst (Intermediate Entity) | Tillitsankartjänst (Trust Anchor) | Uppslags- och verifieringstjänst (Resolver) | Vägledning |
|---|---|---|---|---|---|---|
| T.1 | Teknisk säkerhet | Aktör som tillhandahåller federationsinfrastrukturtjänst ska säkerställa att de tekniska kontroller som finns införda är tillräckliga för att uppnå den skyddsnivå som bedöms nödvändig med hänsyn till verksamhetens art, omfattning och övriga omständigheter, och att dessa kontroller fungerar och är effektiva. | Ja | Ja | Ja | Kravet innebär att aktören ska kunna visa att de tekniska skyddsåtgärderna är anpassade till tjänstens risker. Det handlar om skydd för riktighet, konfidentialitet, tillgänglighet och spårbarhet i de system och uppgifter som tjänsten hanterar. Kontrollerna ska inte bara finnas, utan också följas upp så att de fungerar över tid. |
| T.2 | Kommunikationsskydd | Elektroniska kommunikationsvägar som nyttjas i verksamheten för överföring av känsliga uppgifter ska skyddas mot insyn, manipulation och återuppspelning. | Ja | Ja | Ja | Kravet innebär att känslig kommunikation till, från och inom federationsinfrastrukturtjänsten ska skyddas mot avlyssning, manipulation och återuppspelning. I praktiken innebär det normalt starka kryptografiska protokoll, säker identifiering av kommunicerande parter och korrekt hantering av certifikat och nycklar. |
| T.3 | Livscykel för IT-miljö | Aktör som tillhandahåller federationsinfrastrukturtjänst ska ha dokumenterade rutiner som säkerställer att erforderlig skyddsnivå i den berörda IT-miljön kan upprätthållas över tid och i samband med förändringar, innefattande regelbundna sårbarhetsundersökningar samt ändamålsenlig beredskap för att möta förändrade risknivåer och inträffade incidenter. | Ja | Ja | Ja | Kravet innebär att aktören behöver ha kontroll över IT-miljöns hela livscykel: anskaffning, utveckling, konfiguration, drift, ändring, sårbarhetshantering och avveckling. Det ska finnas dokumenterade rutiner för hur ändringar införs, hur sårbarheter upptäcks och hanteras, och hur incidenter eller förändrade hotbilder möts. |
| T.4 | Standarder och tekniska profiler | Federationsinfrastrukturtjänst ska följa gällande standarder, tekniska profiler och specifikationer för samverkan enligt Bilaga D och andra bindande tekniska artefakter. | Ja | Ja | Ja | Kravet innebär att aktören ska följa de tekniska standarder och profiler som gäller för federationsinfrastrukturen. Det kan omfatta OpenID Federation, metadataformat, signeringskrav, endpoint-beteenden, policyhantering och andra bindande tekniska artefakter. Aktörer bör därför tidigt bedöma om befintliga produkter och plattformar kan uppfylla profilen utan omfattande specialutveckling. |
| T.5 | Generellt skydd av kryptografiskt nyckelmaterial | Känsligt kryptografiskt nyckelmaterial som används för signering, publicering eller verifiering av federationsmetadata eller annan tillitsbärande information ska skyddas så att: (a) åtkomst begränsas, logiskt och fysiskt, till de roller och tillämpningar som oundgängligen kräver det, (b) nyckelmaterialet aldrig lagras i klartext på beständig lagringsmedia, och (c) säkerhetsmekanismerna för skydd av nyckelmaterial är genomlysta och baserade på erkända och väletablerade standarder. | Ja | Ja | Ja | Kravet innebär att kryptografiskt nyckelmaterial som är centralt för federationsfunktionen ska skyddas särskilt. Endast roller och system som behöver nycklarna ska ha åtkomst. Nycklar får inte lagras i klartext på beständig lagring och skyddet ska bygga på erkända och granskade säkerhetsprinciper. |
| T.6 | Nyckelskydd för anslutningstjänst | Känsligt kryptografiskt nyckelmaterial som används av anslutningstjänsten för signering av subordinate statements eller motsvarande federationsmetadata ska skyddas genom kryptografisk hårdvarumodul eller annat likvärdigt skydd med aktiva säkerhetsmekanismer som motverkar såväl fysiska som logiska försök att röja nyckelmaterialet. | Ja | — | — | Kravet innebär att en anslutningstjänst behöver skydda signeringsnycklar för subordinate statements eller motsvarande metadata med en hög skyddsnivå. En HSM är ett tydligt sätt att uppfylla kravet, men annat skydd kan godtas om det ger likvärdig effekt. Aktören ska då kunna visa varför skyddet är likvärdigt genom teknisk dokumentation, riskanalys och lämplig granskning. |
| T.7 | Nyckelskydd för tillitsankartjänst | Känsligt kryptografiskt nyckelmaterial som används av tillitsankartjänsten ska skyddas genom kryptografisk hårdvarumodul med aktiva säkerhetsmekanismer som motverkar såväl fysiska som logiska försök att röja nyckelmaterialet. | — | Ja | — | Kravet innebär att en tillitsankartjänst ska ha starkare skydd för sitt mest kritiska nyckelmaterial. Eftersom tillitsankaret är den kryptografiska roten i tillitskedjan bör nycklarna skyddas med kryptografisk hårdvarumodul. En aktör som överväger rollen som trust anchor behöver därför räkna med att detta är en kostnadsdrivande men säkerhetsmässigt central förmåga. |
| T.8 | Flerpersonkontroll för aktiveringsdata | Aktiveringsdata för skydd av känsligt kryptografiskt nyckelmaterial ska för tillitsankartjänst hanteras genom flerpersonkontroll. För anslutningstjänst bör aktiveringsdata hanteras genom flerpersonkontroll, och ska hanteras genom flerpersonkontroll om anslutningstjänstens riskklass eller omfattning kräver det enligt fastställd riskbedömning. | Ja | Ja | — | Kravet innebär att ingen enskild person bör kunna aktivera eller använda det mest skyddsvärda nyckelmaterialet ensam. För trust anchor ska flerpersonkontroll tillämpas. För anslutningstjänst bör flerpersonkontroll tillämpas och kan behöva bli obligatorisk beroende på risk, omfattning och vilka federationsmedlemmar som ansluts. |
| T.9 | Publicering av metadata genom anslutningstjänst | Anslutningstjänsten ska publicera metadata för anslutna federationsmedlemmars tekniska komponenter i enlighet med tillämpliga specifikationer, tekniska profiler och registreringspolicyer. | Ja | — | — | Kravet innebär att anslutningstjänsten ska kunna publicera metadata för de tekniska komponenter som anslutits via tjänsten. Publiceringen ska ske enligt teknisk profil och registreringspolicy så att metadata kan hämtas och verifieras av andra aktörer i federationen. |
| T.10 | Signering genom anslutningstjänst | Anslutningstjänsten ska signera subordinate statements eller motsvarande federationsmetadata i enlighet med tillämplig teknisk profil. | Ja | — | — | Kravet innebär att anslutningstjänsten ska signera metadata eller subordinate statements så att andra aktörer kan verifiera att informationen kommer från rätt anslutningstjänst och inte har ändrats. Signeringen är en central del av tillitskedjan och ska därför hänga ihop med kraven på nyckelskydd. |
| T.11 | Tillgänglighet för uppslag | Anslutningstjänsten ska vara tillgänglig och nåbar för federationsoperatörens uppslags- och verifieringstjänst enligt tillämplig teknisk profil och fastställda tjänstenivåer. | Ja | — | — | Kravet innebär att anslutningstjänsten måste vara tekniskt nåbar för uppslag och verifiering enligt federationsinfrastrukturens tekniska profil. En aktör som överväger att bli anslutningsoperatör behöver därför planera för drift, övervakning och tillgänglighet. Exakta servicenivåer bör anges i särskild tjänstenivå eller metodkrav. |
| T.12 | Registreringskontroller för tekniska komponenter | Vid registrering av tekniska komponenter ska anslutningsoperatören kontrollera metadata mot tillämpliga krav, verifiera organisationskoppling och domänkontroll samt tilldela tillämplig registreringspolicy-URI. | Ja | — | — | Kravet innebär att anslutningsoperatören ska kontrollera att tekniska komponenter registreras med korrekt metadata, rätt organisationskoppling, styrkt domänkontroll och rätt registreringspolicy. Syftet är att felaktiga eller obehöriga komponenter inte ska kunna få en tillitsposition i federationen. |
| T.13 | Dokumentation av anslutning och registrering | Varje anslutning och registrering ska dokumenteras med minst tidpunkt, identifierade kontrollmoment, utfall, begärande part, behörig företrädare, tillämplig policyversion och relevant ärende- eller referens-ID. | Ja | — | — | Kravet innebär att anslutningar och registreringar ska vara spårbara. Aktören ska kunna visa vilka kontroller som gjorts, när de gjordes, vem som begärde åtgärden, vilken företrädare som låg bakom och vilken policyversion som tillämpades. Detta är nödvändigt vid revision, felsökning och incidentutredning. |
| T.14 | Ändringshantering för metadata och policy | Ändringar av metadata, registreringsuppgifter, tillitsvägar eller policyuppgifter som kan påverka tilliten i federationen ska journalföras och riskbedömas innan de genomförs, om inte omedelbar åtgärd krävs för att hantera en incident. Journalen ska minst omfatta ärende-ID, begärande part, tidpunkt, ändringsbeskrivning, motivering och beslutsfattare. | Ja | Ja | — | Kravet innebär att ändringar som kan påverka tilliten i federationen ska hanteras kontrollerat. Metadata, tillitsvägar, policyuppgifter och andra centrala uppgifter ska inte ändras utan dokumentation och riskbedömning. Vid incident kan akut åtgärd behövas först, men då ska dokumentation och riskbedömning kompletteras i efterhand. |
| T.15 | Avregistrering och teknisk effekt | Avregistrering, återkallelse eller spärr av registrerad komponent, metadata, tillitsväg eller nyckel ska ge entydig teknisk effekt så att förlitande parter inte kan etablera tillit på grundval av information som inte längre ska vara giltig. Åtgärden ska journalföras med minst ärende-ID, beslutsdatum, beslutsfattare och grund. | Ja | Ja | Ja | Kravet innebär att avregistrering, spärr eller återkallelse ska få faktisk teknisk effekt. En komponent eller tillitsväg som inte längre ska vara giltig ska inte kunna användas för att etablera tillit. Aktörer behöver därför förstå hur cache, giltighetstider, statuskontroller och uppdateringsintervall påverkar detta. |
| T.16 | Nyckelrotation | Rotation av kryptografiskt nyckelmaterial som används i federationsinfrastrukturtjänst ska genomföras på ett kontrollerat, dokumenterat och spårbart sätt. | Ja | Ja | Ja | Kravet innebär att nyckelrotation ska ske planerat, dokumenterat och spårbart. Aktören behöver rutiner både för normal rotation och för akut rotation vid misstänkt kompromettering. Nyckelrotation ska inte göras ad hoc av någon stackars tekniker klockan 23:47 utan process, även om historien säkert innehåller sådana små tragedier. |
| T.17 | Nödåterkallelse och incidentåtgärder | Aktör som tillhandahåller federationsinfrastrukturtjänst ska kunna genomföra nödåterkallelse eller motsvarande teknisk riskbegränsande åtgärd utan onödigt dröjsmål vid komprometterat nyckelmaterial, felaktig metadata, felaktig tillitsväg eller annan incident som påverkar tilliten i federationen. | Ja | Ja | Ja | Kravet innebär att aktören ska kunna vidta snabba tekniska åtgärder när tilliten påverkas, exempelvis vid komprometterat nyckelmaterial, felaktig metadata eller felaktig tillitsväg. Det ska finnas praktisk förmåga att återkalla, spärra, ändra, kommunicera och återställa. |
| T.18 | Publicering genom tillitsankartjänst | Tillitsankartjänsten ska publicera federationsmetadata och trust anchor entity configuration i enlighet med tillämpliga specifikationer och tekniska profiler. | — | Ja | — | Kravet innebär att tillitsankartjänsten ska publicera den metadata och entity configuration som krävs för att andra aktörer ska kunna etablera tillit till federationskontexten. Publiceringen ska följa teknisk profil och vara utformad så att metadata kan verifieras korrekt. |
| T.19 | Tillitskedja och federationspolicy | Tillitsankartjänsten ska möjliggöra verifierbar tillitskedja genom signering av relevanta entity statements och subordinate statements samt uttrycka och tekniskt genomdriva federationspolicy i publicerad metadata, metadata policy och andra bindande tekniska artefakter som tillämpas i tillitskedjan. | — | Ja | — | Kravet innebär att tillitsankartjänsten ska signera och uttrycka den policy som styr tillitskedjan. Trust anchor ska inte förstås som en resolver som själv verifierar åt andra, utan som den funktion som publicerar och signerar den rotade tillit och policy som andra verifierar mot. |
| T.20 | Tillitsvägar och överordnade relationer | Tillitsankartjänsten ska endast exponera sådana tillitsvägar och överordnade relationer som uttryckligen beslutats och konfigurerats enligt bindande artefakter. | — | Ja | — | Kravet innebär att tillitsankartjänsten bara får exponera tillitsvägar och relationer som faktiskt har beslutats och konfigurerats enligt bindande artefakter. Syftet är att undvika oavsiktlig tillit mellan aktörer, miljöer eller federationskontexter. |
| T.21 | Resolverfunktion | Uppslags- och verifieringstjänsten ska möjliggöra automatiserat uppslag och verifiering av metadata, tillitskedjor, status och relevanta policyuppgifter via federationsinfrastrukturen enligt tillämplig teknisk profil. | — | — | Ja | Kravet innebär att resolverfunktionen ska kunna hämta och verifiera metadata, tillitskedjor, status och policyuppgifter enligt den tekniska profilen. Resolvern producerar inte ny tillitsinformation, utan hjälper andra aktörer att använda redan publicerad information korrekt. |
| T.22 | Kryptografisk verifiering och statuskontroll | Uppslags- och verifieringstjänsten ska verifiera kryptografisk giltighet, tillitskedja, giltighetstid, status och tillämplig metadata policy innan metadata eller annan tillitsinformation lämnas som verifierad. | — | — | Ja | Kravet innebär att resolverfunktionen ska göra faktisk verifiering, inte bara lämna vidare metadata. Den ska kontrollera signaturer, tillitskedja, giltighetstid, status och tillämplig policy innan information lämnas som verifierad. Annars är den mest en cache med självförtroende, och sådana finns det redan nog av. |
| T.23 | Kontextbunden verifiering | Uppslags- och verifieringstjänsten ska genomföra verifiering utifrån den tillitsankare och federationskontext som följer av tjänstens konfiguration. Cross-context-validering får inte förutsättas utan uttryckligt stöd i bindande artefakt. | — | — | Ja | Kravet innebär att verifiering alltid ska ske mot rätt trust anchor och rätt federationskontext. En aktör ska inte anta att en komponent som är betrodd i en kontext automatiskt är betrodd i en annan. Det är särskilt viktigt när flera kontexter, testmiljöer eller övergångslösningar används parallellt. |
| T.24 | Rätt att göra påståenden i metadata | Aktör som tillhandahåller federationsinfrastrukturtjänst får inte publicera, signera eller förmedla påståenden om organisationer, system, tillitsvägar, policyer eller användare som aktören inte har rätt att företräda eller intyga enligt tillämpligt avtal, registreringspolicy eller bindande artefakt. | Ja | Ja | Ja | Kravet innebär att aktören bara får publicera, signera eller förmedla påståenden som aktören har rätt att göra enligt roll, avtal, policy eller annan bindande grund. Detta gäller exempelvis uppgifter om organisationer, tekniska komponenter, tillitsvägar och policyer. |
| T.25 | Informationskvalitet i metadata | Aktör som tillhandahåller federationsinfrastrukturtjänst ska säkerställa att information i metadata, beskrivningar och fritextfält är korrekt, relevant och ändamålsenlig samt inte innehåller stötande, kränkande, värderande eller jämförande innehåll. | Ja | Ja | Ja | Kravet innebär att metadata och fritextfält ska vara korrekta, relevanta och sakliga. Information som visas för andra aktörer eller används i administrativa gränssnitt ska inte innehålla ovidkommande, värderande eller kränkande uppgifter. Syftet är både informationskvalitet och förtroende. |
| T.26 | Skydd mot spridning av produktionsrelaterade verifieringsuppgifter | Aktör som tillhandahåller federationsinfrastrukturtjänst ska säkerställa att produktionsrelaterade uppgifter som inte är avsedda för publicering, exempelvis testdata, interna verifieringsuppgifter, konfigurationsuppgifter eller skyddsvärda nyckelrelaterade uppgifter, inte sprids utanför de aktörer, system eller processer som har rätt att ta del av dem. | Ja | Ja | Ja | Kravet innebär att produktionsrelaterade uppgifter som inte ska publiceras inte får spridas utanför behöriga aktörer, system eller processer. Kravet ska inte hindra sådan metadata som enligt teknisk profil ska vara publik eller åtkomlig. Det riktar sig mot interna verifieringsuppgifter, testdata, konfiguration och skyddsvärda nyckelrelaterade uppgifter. |