På sidan:

1. Syfte

Syftet med denna anslutningspolicy är att beskriva ett normativt golv (minimikrav) för hur anslutningsoperatörer ska verifiera och dokumentera:

• verifierbar systemidentitet, samt
• verifierad koppling mellan system och anslutande organisation,

så att andra parter i federationen kan förlita sig på en tydligt definierad och repeterbar nivå av tillit vid MVP‑drift.

Policyn avser endast identifiering och organisationskoppling på federationsnivå — ej beslut om åtkomst eller verksamhetsbedömningar i enskilda tjänster.

2. Vad policyn garanterar (“vad andra parter kan förutsätta”)

När en aktör eller komponent ansluts enligt denna policy ska andra parter i federationen kunna förutsätta att:

1. Systemet har en unik, kryptografiskt skyddad identitet som kan autentiseras av tredje part (t.ex. X.509‑certifikat, målade JWK med signatur eller motsvarande).
   
   
2. Systemidentiteten är knuten till en ansvarig juridisk organisation som vid tidpunkten för anslutning har godkänt anslutningen via en verifierad behörig företrädare.
   
   
3. Det finns dokumenterad, maskin‑ och mänskligt granskbar spårbarhet från systemidentitet → beställning → behörig företrädare → verifieringskällor.
   
   
4. Minimikontrollerna i detta dokument genomförts och att anslutningsoperatören kan uppvisa verifieringsunderlag vid revision.

Observera: policyn GARANTERAR inte åtkomsträtt till någon tjänst. Tjänsteleverantörer måste fortfarande fatta egna åtkomstbeslut baserade på den tillit de behöver.

3. Roller och ansvar — vad som är federationskrav vs operatörsprocess

3.1 Normativt golv (federationskrav — obligatoriskt)

Följande krav är bindande för alla anslutningsoperatörer och kan åberopas av tjänsteleverantörer som förutsättning för grundläggande tillit:

• Verifiering av juridisk organisationsidentitet vid onboarding (se avsnitt 4 och 5).
• Verifiering av behörig företrädare enligt miniminivåer för privata respektive offentliga aktörer (se avsnitt 6).
• Utfärdande eller godkännande av systemidentitet med kryptografiska nyckelpar som uppfyller angivna kryptografiska krav (se avsnitt 7).
• Out‑of‑band‑verifiering minst enligt ett av alternativen i avsnitt 6.4.
• Dokumentation och retention av verifieringsunderlag enligt avsnitt 9.
• Möjlighet till revision av federationen enligt avsnitt 10.

3.2 Operatörens processer (implementeringsutrymme)

Anslutningsoperatören ansvarar för hur de obligatoriska kontrollerna genomförs inom ramen för följande krav: säkerhetsnivå, spårbarhet, beviskedja och rimlig kostnad/effektivitet. Operatören får själv välja tekniska lösningar, mallar och arbetsflöden så länge de uppfyller det normativa golvet.

Operatören ska dessutom bedriva en lokal riskbedömning och ange vilka kompletterande kontroller som tillämpas för högre riskfall (exempelvis för system med högre påverkan).

4. Definitioner

• Systemidentitet: unik, teknisk identitet som används för autentisering i maskin‑till‑maskin‑kommunikation (t.ex. certifikat eller signerade tokens).
• Behörig företrädare: person som enligt organisations interna regler och/eller extern registrering har rätt att binda organisationen (firmatecknare, motsv.) eller en person med dokumenterat och signerbart mandat.
• Offentlig aktör: statlig, regional eller kommunal juridisk enhet.

5. Organisationsverifiering (juridisk person)

5.1 Privata aktörer (miniminivå)

För privata aktörer ska operatören som minimun verifiera:

• organisationsnummer mot Bolagsverket eller annan nationell källa,
• att den som beställt anslutningen är firmatecknare eller har ett verifierbart, skriftligt mandat från firmatecknare (underskrift eller elektronisk signatur enligt lag).

Verifieringsbevis (t.ex. utdrag, fullmakt, signerat dokument) ska sparas enligt avsnitt 9.

5.2 Offentliga aktörer (miniminivå)

För offentliga aktörer — där motsvarande centrala register ofta saknas — krävs minst ett av följande, i prioritetsordning:

1. Verifiering mot officiellt myndighetsregister eller offentlig förteckning om sådan finns (t.ex. myndighetslista på regeringskansliets nivå eller kommunens officiella register). Om sådant register finns används det som primär källa.
2. Formellt beslutsdokument (utdrag ur protokoll, delegationsbeslut eller motsvarande) som tydligt visar att den namngivna personen har mandat att godkänna anslutningar för myndigheten. Dokumentet ska vara underskrivet av rätt beslutsfattare enligt myndighetens delegationsordning.
3. Bekräftelse via officiell e‑postadress kopplad till myndighetens officiella domän, i kombination med publicerat referenspåstående på myndighetens officiella webbplats eller register.
4. Om ovan ej är möjliga: notariserad fullmakt eller motsvarande signerad bekräftelse från högre förvaltningsnivå.

Operatören ska alltid dokumentera vilken källa som använts och motivera avvikelse från primära källor.

6. Behörig företrädare och delegation

• Beställning måste ske av firmatecknare eller av person med dokumenterat mandat.
• Vid delegation ska delegationen vara:
  • skriftlig eller elektroniskt signerad, samt
  • tidsbegränsad eller innehålla angiven omfattning (vad som får utföras).
• Delegationskedjan ska kunna granskas och länkas till systemidentiteten.

7. Systemidentitet och kryptografiska krav

7.1 Krav

• Systemidentitet ska baseras på asymmetrisk kryptografi.
• Utfärdat material ska inkludera:
  • unik identifierare (URI/subject),
  • offentlig nyckel,
  • referens till ansvarig organisations identifierare,
  • metadata om giltighetstid och avsedd användning.
• Stöd för automatiserad verifiering (t.ex. CRL/OCSP eller JWT‑nyckelpublicering) ska erbjudas.

7.2 Nyckelhantering (minimikrav)

• Privat nyckel ska lagras i skyddad miljö (HSM, KSP eller motsv.) där det är tekniskt möjligt.
• Nyckelgenerering bör ske i enlighet med bästa praxis; om kund genererar nyckel ska processen verifieras.
• Återkallelseprocess ska vara dokumenterad och kunna initieras av ansvarig organisation eller anslutningsoperatör.

8. Out‑of‑band‑verifiering (miniminivå)

Minst ett out‑of‑band‑steg krävs. Acceptabla metoder är:

• fysisk post (aktiveringskod) till organisationens offentligt registrerade adress (privata aktörer), eller
• bekräftelse via officiell e‑post hos offentlig aktör (se avsnitt 5.2) i kombination med publicerat stöd på officiell webbplats, eller
• undertecknat beslut eller fullmakt från behörig beslutsfattare.

Operatören ska välja lämplig metod beroende på om aktören är privat eller offentlig och dokumentera varför metoden är tillräcklig.

9. Dokumentation, retention och spårbarhet

Operatören ska spara följande för varje anslutning och minst under hela systemidentitetens giltighetstid + 3 år:

• identifieringar och utdrag från register,
• delegationshandlingar och signaturer,
• protokoll över utförda kontroller (vem, vad, när),
• utfärdat certifikat / publicerad JWK‑metadata,
• beslut om återkallelse och datum för sådan.

Dokumentationen ska vara möjlig att överlämna vid revision och att maskinellt indexera för sökbarhet.

10. Revision, uppföljning och sanktioner

Federationen äger rätt att:

• begära verifieringsunderlag, utföra stickprov och revisioner hos anslutningsoperatörer,
• ålägga korrigerande åtgärder eller temporär avstängning av nyanslutningar om krav inte uppfylls,
• i allvarliga fall avbryta driftssamarbete med operatörer som upprepade gånger brister i efterlevnad.

11. Avgränsning mot verksamhetsansvar och åtkomstbeslut

Det är tydligt: denna policy reglerar enbart tillitsbyggande åtgärder för identitet och organisationskoppling på federationsnivå. Den reglerar inte:

• autentiseringsnivåer som krävs för att få åtkomst till särskilda tjänster,
• beslut om vilka API‑operationer eller datamängder en ansluten komponent får utföra/åtkomst till,
• verksamhetsbedömningar eller efterlevnadsfrågor i tjänsteleverantörens egna domäner.

Tjänsteleverantörer måste fortsätta att fatta egna åtkomst‑ och säkerhetsbeslut med stöd i federationens tillitserbjudande.

12. Livscykelhantering

Operatören ska ha rutiner för:

• ändringar i organisationsuppgifter (ny firmatecknare, namnändring),
• rotation och återkallelse av nyckelmaterial,
• avveckling av systemidentiteter och borttagning av metadata från publiceringspunkter.

13. Vidareutveckling

Policyn gäller som MVP‑golv. För framtida faser rekommenderas:

• införa tillitsnivåer (t.ex. MVP‑BAS, MVP‑HÖG) med tydligare tekniska profiler,
• harmonisering med nationella referensramar och eIDAS/ehälsa‑standarder.