Registreringspolicy för tekniska komponenter Version 0.1

1. Syfte

Denna policy beskriver vad registrering av tekniska komponenter i federationen innebär och vilken betydelse (semantik) registrerade metadata-attribut har. Policyn ska skapa en gemensam förståelse för vilken tillit som kan läggas i registrerade uppgifter samt hur dessa används för automatiserad etablering av förtroenderelatione som baseras på registrerade uppgifter, interoperabilitet och säker drift.

Policyn tar vid efter att en organisation är ansluten som federationsmedlem enligt anslutningspolicy (verifierad organisation och behöriga kontaktpersoner).

2. Styrande ramverk

Policyn bygger på OpenID Federation och den svenska profilen för OpenID Federation. Dessa anger den tekniska modellen för entity statements, trust chains, metadata per entity type och (i förekommande fall) trust marks. Denna policy preciserar hur metadata ska förstås, vilka tillitsantaganden som ska gälla och vilka minimikrav som behöver vara uppfyllda för att en registrering ska vara meningsfull och maskinellt användbar.

Normhierki

1. OpenID Federation 1.0: definierar Entity Statements, trust chains, metadata-ramen och de informational metadata parametrar som bl.a. inkluderar description (alltså exakt den typ av semantik vi vill uttrycka) 

2. Svensk OpenID Federation-profil: preciserar hur (1) ska användas i svensk kontext (t.ex. val av identifierare, roller, constraints, ev. trust marks m.m.)

3. Registreringspolicy för tekniska komponenter anger vad attributen faktiskt signalerar och betyder i detta sammanhang.

3. Vad andra parter kan förutsätta

När en teknisk komponent är registrerad enligt denna policy kan andra parter förutsätta att:

• Komponenten är knuten till en federationsmedlem (juridisk person) genom stabila organisationsuppgifter i metadata.

• Identifierare och domänval ger en kontrollerbar koppling mellan komponent och organisationens domän(er), för att minska risk för felregistrering och vilseledande identiteter.

• Metadata-attributen har en definierad semantik som kan användas för maskinell uppslag och validering och i federationen.

• Registreringen hänvisar till en identifierbar registreringspolicy (policy-URI) som anger vilket regelverk som gällde vid registreringstillfället och vid uppdateringar.

4. Omfattning och avgränsning

4.1 Omfattar

• Semantik för metadata-attribut vid registrering av tekniska komponenter: identitet, organisation, kontakt, nycklar, endpoints och protokollrelaterad metadata.

• Grundprinciper för hur metadata används för interoperabilitet och tillit inom ramen för OpenID Federation och svensk profil.

• Registreringslivscykel på policynivå (nyregistrering, uppdatering, avregistrering) med fokus på spårbarhet.

4.2 Omfattar inte

• Exakta fältkrav per profil, algoritmlistor, testfall eller detaljerade tekniska valideringsregler (hanteras i krav/spec/profil).

• Organisationsverifiering och mandatkedjor för medlemskap (hanteras i anslutningspolicy).

• Driftinstruktioner för resolver, cache och federationstjänster (hanteras i operativa dokument).

5. Roller och ansvar

• Ledningsaktör: fastställer policyn och kan initiera uppföljning/revision av efterlevnad.

• Federationsoperatör: ansvarar för federationens tillitsinfrastruktur och publicering av federationens gemensamma resurser (om rollen är separerad).

• Anslutningsoperatör: ansvarar för registrering och ändringshantering av anslutningar enligt policyn, inklusive att policyidentifierare används, att nödvändiga kontroller genomförs samt att metadataunderlag (t.ex. certifikat, nyckelmaterial och andra uppgifter som används för validering.

• Federationsmedlem: ansvarar för att lämnad metadata är korrekt, aktuell och att förändringar hanteras enligt federationens processer.

6. Definitioner

• Teknisk komponent: federationsentitet som registreras och publiceras för upptäckt och tillit inom federationen, t.ex. OpenID Provider, Relying Party/Client, Authorization Server, Resource.

• Entity Identifier: entydig URI som identifierar en entitet i federationen.

• Entity Configuration: entitetens självdeklaration som utgör startpunkt för trust chain och uppslagning av metadata i federationen.

• Subordinate Statement: uttalande signerat av den Anslutningsoperatör som är överordnad entiteten och ansvarar för dess registrering, vilket intygar bindningar och genomförda kontroller.

• Registreringspolicy-URI: stabil identifierare som anger vilken version av registreringspolicy som tillämpats.

7. Grundläggande ställningstaganden

1. Registrering är tillitsskapande och ska möjliggöra maskinell bedömning av vem som står bakom en komponent, vilka nycklar som hör till entiteten och hur komponenten ska användas säkert och interoperabelt.

2. Metadata ska vara begriplig och verifierbar. Identitetspekande metadata (namn, org-id, domän, kontakt) ska vara spårbar till federationsmedlemmen.

3. Registreringspolicy-URI är en central del av tilliten: andra parter ska kunna förstå vilket regelverk som gällde vid intaget och vid senare ändringar.

4. Svensk profil tillämpas med rollseparation: federation service-roller och protokollroller ska inte blandas under samma entity identifier för protokollentiteter.

8. Registreringsobjekt och policyartefakter

Registrering av en teknisk komponent ska resultera i följande artefakter:

1. Entity Configuration som kan hämtas och valideras.

2. Subordinate Statement utfärdat av Anslutningsoperatören, som binder ihop entiteten, dess federationsnycklar och dess medlemskap samt kan fixera eller stärka utvalda metadata.

3. Registreringspolicy-URI som gör policyn spårbar vid resolution och vid revision.

9. Registreringsprocess (policy-nivå)

9.1 Nyregistrering

Nyregistrering innebär att en ny entitet skapas med initial baseline-metadata. Anslutningsoperatören ska säkerställa att:

• organisationskoppling är etablerad,

• domänkoppling är rimlig och kontrollerbar,

• entity configuration kan valideras,

• subordinate statement kan utfärdas,

• registreringspolicy-URI kopplas till registreringen.

9.2 Uppdatering

Uppdatering innebär ändring av metadata för en befintlig entitet. Principer:

• Uppdateringar ska vara spårbara (vem, vad, när, varför).

• Nyckelbyte och endpointändringar ska hanteras kontrollerat.

• Uppdateringar kan kräva ny attest eller ny kontroll beroende på ändringens säkerhetspåverkan.

• Tillämplig policyversion ska vara tydlig (antingen kvarvarande version om policyn ej ändras, eller ny version om policyn uppdaterats och tillämpas).

9.3 Avregistrering och återkallelse

Avregistrering innebär att entiteten inte längre ska vara tillitsbar/upptäckbar. Principer:

• Avregistrering ska kunna ske kontrollerat vid avslutat medlemskap eller vid säkerhetsincident.

• Federationens tillitskedjor ska brytas eller markera entiteten som icke giltig på ett sätt som är konsekvent för förlitande parter.

10. Spårbarhet, transparens och bevisbarhet

• Registreringsbeslut ska kunna knytas till ärende/beslutsdatum och tillämpad policyversion.

• Federationens parter ska kunna skilja på vad som intygats av Anslutningsoperatören genom sin registreringsfunktionen (subordinate statement) och vad som är självdeklarerat (entity configuration).

• Underlag för kritiska bindningar (organisation↔entitet, domän↔identifierare, nycklar↔entitet) ska kunna redovisas vid revision.

11. Revision och uppföljning

• Efterlevnad kan följas upp genom stickprov, incidentuppföljning och granskning av publicerade artefakter.

• Vid brister kan federationen kräva korrigering, begränsa tillit eller avregistrera komponenten enligt federationens styrmodell.

----------------------------------SLUT-----------------------------

Nedan bilagor ska ses som stödmaterial och inte som en del av 0.1 versionen ovan. 

Bilagor – Metadata-tabeller per entity type (portalformat)

Bilaga A – Entity Configuration (top-level claims) – svensk profil

Bilaga B – Trust Marks (generisk struktur)

Bilaga C – Gemensam organisations- och kontaktmetadata

Dessa fält bör finnas för samtliga protokollentiteter (OP, RP/Client, AS, Resource) för att stödja spårbarhet och mänsklig validering.

Bilaga D – Entity type: OpenID Relying Party / Client (metadata.openid_relying_party.*)

Bilaga E – Entity type: OpenID Provider (metadata.openid_provider.*)

Bilaga F – Entity type: OAuth Authorization Server (metadata.oauth_authorization_server.*)

Används för AS som inte nödvändigtvis är en OpenID Provider (ren OAuth AS), eller där man vill uttrycka OAuth AS-metadata separat.

Bilaga G – Entity type: OAuth Protected Resource (metadata.oauth_resource.*)

Avser resurs/API som skyddas av OAuth (Resource Server) och som kan beskrivas maskinellt för interoperabilitet.

Bilaga H – Minimiregler för semantik och kvalitet (gäller alla entity types)

Identifierare och domänkoppling

• Entity identifier och kritiska URI-fält ska vara valda så att koppling till federationsmedlemmens domän(er) är rimlig och kontrollerbar.

• URI:er ska vara långsiktigt förvaltningsbara och inte peka på innehåll/endpoints som kan bytas ut på ett sätt som skapar vilseledande beteende.

Nycklar och livscykel

• Federationsnycklar (i entity configuration) och protokollnycklar (i entity type metadata, t.ex. jwks_uri) ska kunna roteras på ett kontrollerat sätt.

• Nyckelbyte ska vara spårbart och hanteras som säkerhetskänslig ändring.

Kontakter och incidentförmåga

• Kontakter ska vara bemannade och kunna hantera incidenter, nyckelbyten och metadataändringar.

• Vid incident ska federationen kunna nå ansvarig part utan dröjsmål.

Rollseparation (svensk profil)

• Protokollentiteter ska vara leaf entities och får inte blandas med federation service-roller under samma entity identifier.

• Protokollentiteters entity configuration ska inte innehålla federation service-metadata (federation_entity).

Bilaga I – Mall för “registreringsbeslut” (spårbarhet)

---------------------Grejer som kanske kan vara bra---------------------------

2. Vad andra parter kan förutsätta

När en teknisk komponent är registrerad enligt denna policy kan andra parter i federationen förutsätta att:

• Komponenten är kopplad till rätt federationsmedlem (juridisk person) via stabil organisationsinformation i metadata .

• Komponentens identifierare och domän är valda så att det finns en rimlig och kontrollerbar koppling mellan komponenten och organisationens domän(er) (motverkar “spoofing” och felregistrering) .

• Metadata-attributens semantik är entydig: samma attribut betyder samma sak oavsett anslutningsoperatör, och används som underlag för maskinell validering/resolution .

• Det finns en identifierbar registreringspolicy som anger vilket regelverk som gällde när komponenten togs in (policy-URI i federationens intyg/uttalanden) .

3. Omfattning och avgränsning

Omfattar:

• Semantik (betydelse) för metadata-attribut som används vid registrering av tekniska komponenter, inklusive organisationsuppgifter, kontaktuppgifter, identifierare, nyckelreferenser och protokollrelaterade metadata.

• Övergripande ställningstaganden om hur metadata ska stödja interoperabilitet och tillit.

Omfattar inte:

• Exakta fältkrav per profil, protokollspecifika detaljkrav, algoritmlistor, endpoint-valideringar eller testfall (det hör hemma i krav/spec/profil) .

• Organisationsverifiering och mandatkedjor för att bli federationsmedlem (det hör hemma i anslutningspolicyn) .

4. Roller och ansvar (policy-nivå)

• Ledningsaktör fastställer policyn och kan kräva uppföljning/revision av efterlevnad.

• Federationsoperatör (om rollen finns separat) ansvarar för federationens övergripande tillitsram och publicering av tillitsinfrastruktur.

• Anslutningsoperatör / Registreringsfunktion (Federation Registration Entity) ansvarar för att registrering sker enligt policyn och att policyidentifierare används i federationens uttalanden om entiteter .

• Federationsmedlem ansvarar för att lämnad metadata är korrekt, aktuell och att förändringar hanteras enligt federationsprocesser .

5. Definitioner

• Teknisk komponent: federationsentitet som registreras och blir upptäckbar via federationens metadata/tillitsinformation (t.ex. OP, RP/klient, AS, resurs/API) .

• Entity Identifier (entity_id / entity_identifier): entydig identifierare (URI) för entiteten i OpenID Federation .

• Entity Configuration: entitetens självdeklaration enligt OpenID Federation (kan vara hostad) .

• Subordinate Statement: federationsuttalande som en överordnad entitet signerar vid registrering och därmed “vittnar” om vissa bindningar (nyckel↔identifierare, medlemskap, kontroller) .

• Registreringspolicy-URI: stabil identifierare som anger vilken registreringspolicy som tillämpats för registreringen .

6. Grundläggande ställningstaganden (vad och varför)

1. Registrering är tillitsskapande, inte bara administration.
   Registrering ska göra det möjligt för andra parter att på maskinell väg avgöra vem som står bakom en komponent och hur den kan användas säkert.

2. Metadata ska vara begriplig och verifierbar.
   Där metadata pekar ut identitet (namn, org-id, domän, kontakt) ska den vara spårbar till federationsmedlemmens verifierade organisationsuppgifter och validerade domän(er) .

3. Deskriptiv metadata fixeras vid registrering; säkerhets- och funktionspolicy koncentreras högre upp.
   Registreringsfunktionen ska främst styra/deskribera sådant som kontrolleras vid registrering (visningsnamn, organisationskoppling). Mer komplexa säkerhets-/funktionsrestriktioner bör ligga i trust anchor-policy för att minska konflikt- och mergeproblem .

4. Policyidentifierare är obligatorisk del av tillit.
   Andra parter ska kunna se vilket regelverk som gällde vid intag av komponenten (t.ex. via registreringspolicy-claim/policy-URI) .

--------------------------------Tankar och noteringar--------------------------------

-------------------------------------------------------------------------------------------------

Inledning

Förutsättning: Federationsmedlem är ansluten enligt Anslutningspolicy för federationsmedlemmar

Den här registreringspolicyn beskriver hur en teknisk komponent tas in i federationen för Samordnad identitet och behörighet (”federationen”) och hur komponentens metadata och tillitsinformation hanteras under hela livscykeln från registrering, validering, publicering, uppdatering till avregistrering.

Policyn är styrande för anslutningsoperatörens registreringsarbete och används som stöd för federationsmedlemmars administrativa och tekniska kontaktpersoner.

Policyn beskriver processen och den tekniska hanteringen på artefaktnivå, dvs. vilka federationsobjekt som skapas och uppdateras

Detaljerade protokoll och interoperabilitetskrav (t.ex. exakta fältkrav, säkerhetsparametrar, endpoints) återfinns i separata tekniska profiler och tekniska anslutningsregler. Denna policy hänvisar till dessa dokument när de finns fastställda.

Omfattning och tillämpning

Här beskrivet vi koppling till avtal, villkor och meta dataregistrering, Definierar när policyn gäller så som vid nyregistrering, uppdatering och avregistrering

Roller och ansvar

Här beskriver vi roller som träffas av policyn samt relationerna mellan roller ex Anslutningsoperatör, Federationsmedlem 

Koppling/referens bör finnas till anslutnignspolicy/avtal här?

Ledningsaktör

kanske ska beskrivas?

Federationsoperatör 

kanske ska beskrivas? 

Anslutningsoperatör

Anslutningsoperatör är den organisation/funktion som:

tar emot och handlägger ansökningar från federationsmedlemmar,

genomför registreringskontroller och beslutsunderlag,

godkänner och avregistrerar federationsmedlemmar och deras komponenter, och

driver den tekniska funktionen för anslutning/registrering (t.ex. “anslutningstjänst”) och tillhörande register.

I federationsmodellen kan anslutningsoperatören ha delegerat ansvar från överordnad federationsfunktion och förväntas kunna godkänna/avregistrera komponenter och deras metadata?

Federationsmedlem

Federationsmedlem är en organisation som ansluter en eller flera tekniska komponenter till federationen och nyttjar federationens tillitsinformation för samverkan. Federationsmedlemmar förutsätts ingå avtal med anslutningsoperatör för att kunna placera komponenter i federationen.

Teknisk komponent
Med teknisk komponent avses i denna policy en federationsentitet som federationsmedlem ansluter och som ska kunna upptäckas och valideras genom federationens metadata/tillitsinformation. Exempel på komponenttyper:

• legitimeringstjänst/OP,

• förlitande part/RP,

• auktorisationstjänst/AS,

• resurs/API (RS) och API-klient,

• attribut-/informationskälla??,

• övriga om jag missat nån federationsprotokollentiteter enligt tekniska profil(er).

Trust Mark Issuer kanske ska heta nåt annart så som egenskapsintygutföärdare 

Trust Mark Issuer är en federationsentitet som utfärdar Trust Marks, dvs signerade intyg om xyz

Federationsmiljöer

Beskriver krav kopplade till olika miljöer såsom test, QA och produktion. Reglerar hur komponenter får flyttas mellan miljöer och vilka krav som gäller per miljö.

Registreringsbara tekniska komponenter

Specificerar vilka typer av komponenter som får registreras, exempelvis IdP, SP, attributtjänster osv. 

Process för registrering och verifiering av metadata

Villkor för organisatorisk koppling, behörigföreträdare mm koppling/referat till anslutningspolicy

Här regleras organisatorisk koppling, behörig företrädare och publicerbarhet på någon nivå, samt att detaljerade tekniska krav/test  det senare kanske ligger under tekniska anslutnings regler?
Koppling finns troligen till  Anslutningspolicy (behörighet/anslutningsvillkor), Tekniska anslutningsregler (detaljer).

Förutsättningar för att registrering får initieras

Här anges att registrering endast får initieras av behörig företrädare (utsedd administrativ/teknisk kontakt) och att organisationen omfattas av anslutningsvillkoren.
Koppling: Anslutningspolicy (medlemskap, roller, behörig företrädare).

Villkor för organisatorisk koppling

Här beskrivs hur komponenten ska kopplas till rätt organisation (t.ex. orgnr/orgnamn) och hur operatören verifierar kopplingen beskriv hur och kolla koppling till Anslutningspolicy för federationsmedlemmar

Inlämning av metadata för registrering

Här beskrivs antingen vilka metadata som minst ska lämnas in kanske på typnivå (identifierare, orginfo, nycklar, endpoints, kontakt) eller så ska vi lista alla fält? 

Grundläggande verifiering inför publicering

Här beskrivs vilken verifiering som alltid görs innan publicering, 

Beslut, publicering och återkoppling

Här beskrivs beslutspunkten (godkänn/avvisa/kräv komplettering), hur publicering sker i federationen samt hur medlemmen får återkoppling. Här borde det finns en del klurigheter så som vad som händer vid avslag och vad som ses som myndighetsutövning osv? 

Hantering av avvikelser, spärrar och avregistrering

Här beskrivs vad som händer om organisatorisk koppling inte kan styrkas eller om metadata bedöms inte vara publicerbar.

Metadataregler

Beskriver övergripande regler för hur teknisk metadata för en federerad komponent ska vara utformad, vad den ska innehålla och hur den valideras. Syftet ät att metadata kan publiceras och användas för automatiserad tillitsetablering och interoperabilitet i federationen. Metadatareglerna gäller för federationsmedlemmars tekniska komponenter som registreras i federationen oavsett roll (t.ex. utfärdare/auktorisationsserver, förlitande part/klient, eller andra federationstjänster).

Teknisk metadata - organisationnr, orgnamn, entity_id, nycklar mm
Reglerar struktur, innehåll och validering av metadata. Anger obligatoriska element såsom organisationsinformation, endpoints, certifikat osv.

Metadata ska knytas till en teknisk komponent via en entydig identifierare dessutom ska metadata bära tillräcklig organisationsinformation för att koppla komponenten till ansvarig federationsmedlem det skulle kunna vara ex: 

• organisationsnummer,

• organisationsnamn,

• relevanta kontaktuppgifter (administrativ och teknisk kontakt),

• eventuell koppling till avtal/anslutningsrelation

• mm

• ELLER så är det en hänvisning till den svenska iodf profileneller nåt annat? 

Identifierare och organisationsuppgifter ska vara stabila över tid. Ändring av dessa uppgifter sker enligt nån process nånstans som inte beskrivits ännu. 

Egenskapsintyg

Ett egenskapsintyg är ett digitalt, signerat intyg som uttrycker vissa egenskaper hos en aktör eller dess tekniska komponenter på ett standardiserat och maskinläsbart sätt, så att det kan verifieras och användas automatiserat.

Det används för att styrka förutsättningar eller statusar som är relevanta för samverkan, till exempel att ett visst avtal är tecknat? eller andra organisatoriska/tekniska villkor är uppfyllda?

Det ska inte användas för att uttrycka juridisk behörighet eller beslutsmandat? (sånt hör hemma i särskilda behörighetsintyg/behörighetshandlingar).

Tekniska krav på komponenter

Anger krav på protokollstöd, säkerhetskonfiguration, signering och kryptering. Reglerar användning av specificerade profiler och tekniska standarder.

Attribut- och identitetsregler

Definierar vilka attributuppsättningar som får levereras och under vilka förutsättningar. Reglerar särskilda fall såsom organisationsidentiteter och samordningsnummer.

Test och verifiering

Beskriver processen för teknisk granskning och verifiering innan produktionssättning. Anger krav på testfall, interoperabilitet och säkerhetskontroller.

Förändringshantering - kanske ska slå ihop med Kap 13. 

Reglerar hur ändringar i metadata, certifikat, endpoints eller funktionalitet ska hanteras. Anger krav på notifiering och eventuell "omgranskning".

Löpande uppföljning och kontroller

Fastställer mekanismer för kontinuerlig validering av metadata och teknisk efterlevnad i syfte att möjliggör revision, stickprov(er) och incidentbaserad kontroll(er).

Avregistrering och återkallelse

Reglerar hur komponenter avregistreras frivilligt eller genom beslut. Anger hur metadata tas bort och hur tillit återkallas vid allvarliga avvikelser.

Versionshantering och uppdatering

Beskriver hur nya versioner av tekniska krav införs och tidsramar för anpassning. Fastställer hur policyn själv uppdateras och träder i kraft.