Page History

...

• registreringspolicy-URI användes vid registrering,

• komponentens organisationskoppling och domänkoppling var kontrollerbar,

• och att metadata-attributen som publicerats följer denna policys semantik.
  (Detaljerade stickprovsmekanismer och sanktionstrappor ligger i kompletterande regelverk/krav) .

Korta, obekväma men viktiga observationer (så ni slipper upptäcka dem i remissrunda)

...

Er nuvarande “registreringspolicy v15” är till stor del process/disposition och lämnar precis det ni efterfrågar här (semantik/“description”) som ett hål . Den här texten fyller det hålet, men ni behöver fortfarande skilja policy från kravprofil så att ni inte råkar stoppa valideringsregler i fel dokument.

...

. Vad från Anslutningspolicy för federationsmedlemmar som används av Registreringspolicy för tekniska komponenter

Utifrån anslutningspolicyn framgår att den inte reglerar registrering av tekniska komponenter, utan att detta hanteras i Registreringspolicy för teknisk komponent (avgränsning/scope).

Anslutningspolicy för federatio…

Samtidigt beskriver anslutningspolicyn vilka förutsättningar som andra parter kan lita på – och dessa är det som registreringspolicyn för tekniska komponenter typiskt bygger vidare på.

Anslutningspolicy för federatio…

Följande delar från anslutningspolicyn är direkt “input”/förutsättningar som registreringspolicyn behöver återanvända:

A. Verifierad organisationsidentitet (juridisk person)

• Organisationens existens och organisationsnummer verifieras mot relevant nationell registerkälla (ex. Bolagsverket).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy (teknisk komponent):

• Låser komponentregistrering till en verifierad juridisk part.

• Blir grund för att sätta/validera fält som motsvarar “organisationsidentitet” i komponentens/federationsentitetens metadata (t.ex. organization_name, ev. organization_identifier/orgnr), och för att säkerställa spårbar koppling mellan metadata och juridisk part.

B. Behörig företrädare och avtalstecknande (mandat)

• Avtalstecknare identifieras med stark identifiering och mandat/behörighetsgrund verifieras och dokumenteras (firmateckning, delegation, fullmakt, etc.).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Skapar den juridiska tillitspunkten: att organisationen faktiskt är federationsmedlem, vilket krävs för att organisationen ska få registrera komponenter/entiteter.

• Ger grund för regler om vem som får initiera/attestera “ny komponent”, “nyckelbyte”, “ändring av endpoints”, etc.

C. Kvalificerade kontaktpersoner med delegation för teknisk registrering

• Policyn kräver att federationsmedlemmen utser relevanta kontaktpersoner och att delegation/fullmakt finns om kontaktpersonen ska få utföra åtgärder i federationens system (t.ex. registrera tekniska komponenter).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Styr åtkomsträtt i registreringsflödet: vem får registrera och uppdatera tekniska komponenter/metadata.

• Underlag för krav på contacts i metadata (och att dessa ska vara spårbart utsedda/behöriga).

D. Spårbarhet, dokumentationskrav och arkivering

• Operatören ska dokumentera och arkivera bevis/underlag, logga utförda kontroller (vem, vad, när, källor, resultat), samt lagra dokumentation under medlemskap + viss tid.

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Registrering/ändringar av tekniska komponenter måste vara revisionsbara: koppla varje registreringshändelse till verifierad kontaktperson/roll, beslut, underlag.

• Underlag för policykrav kring “change management” (nyckelrullning, endpointändringar, avregistrering).

E. Löpande re-verifiering och händelsestyrd uppföljning

• Årlig re-verifiering och triggers (t.ex. ändrad firmatecknare, fusion, konkurs, etc.).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Om organisationen inte kan re-verifieras: påverkar förtroende/aktivering av organisationens tekniska komponenter (t.ex. karantän/avstängning av metadata, spärr av nycklar, etc.).

• Underlag för regler om när komponentmetadata måste uppdateras (t.ex. vid domänbyte/omorganisation).

Sammanfattande: Anslutningspolicyn etablerar “vem är organisationen och vem får företräda den”, medan registreringspolicyn kan fokusera på “vilka tekniska entiteter får organisationen publicera och hur säkras korrekthet över tid”. Det uttrycks också i anslutningspolicyn att organisationsverifieringen “ligger till grund” för verifiering kopplat till komponenter via registreringspolicyn.

Anslutningspolicy för federatio…

...

2. Ersätt “Sweden Connect metadata” med metadata relevant för OpenID Federation (inkl. Trust Marks)

I Sweden Connect metadata portal-underlaget beskrivs idag ett formulär-/metadataupplägg som i praktiken motsvarar OIDC-klientmetadata + vissa federationsrelaterade fält och med stark betoning på att fältnamn ska följa OIDC/OIDF-specifikationernas attributnamn.

Sweden Connect metadata portal_…

För att “ersätta Sweden Connect metadata” med OpenID Federation-relevant metadata (med fokus på OIDF och trust marks) bör man utgå från att det som registreras/publiceras är en Entity Configuration (en self-signed Entity Statement JWT) med dessa centrala delar:

A. Federation-lagret: Entity Statement / Entity Configuration (top-level claims)

OpenID Federation definierar claim-set för Entity Statements (t.ex. iss, sub, iat, exp, jwks, metadata) och att authority_hints är REQUIRED för leaf/intermediate (dvs alla som har en superior) och får inte vara tom.
metadata måste finnas för de Entity Types entiteten deltar i (t.ex. openid_relying_party).

B. Trust Marks: trust_marks + (för Trust Anchors) trust_mark_issuers/trust_mark_owners

OpenID Federation definierar trust_marks som en array av objekt med trust_mark_type och trust_mark (JWT).
Trust Anchor kan publicera trust_mark_issuers och trust_mark_owners för att styra/tydliggöra vilka utfärdare/ägare som är betrodda per trust mark-typ.

Den svenska profilen (utkast) anger dessutom att resolver-funktionen kan behöva hantera trust marks, inklusive att en resolver kan inkludera trust marks som inte ligger i entitetens egen konfiguration genom kommunikation med Trust Mark Issuer.
Notera: Själva avsnittet “Trust Marks” i profilen är i detta utkast i praktiken ett TODO-block, men det pekar på områden som måste beslutas (kortlivade vs långlivade trust marks, validering, namngivning, m.m.).

C. Svensk profil: rollseparation och att leaf/protokollentiteter inte ska bära federation_entity metadata

Profilen ställer krav att man inte kombinerar Federation Service-roller (Trust Anchor/Intermediate/Resolver/TMI) med protokollroller (OP/RP/Client/etc) under samma Entity Identifier, och att Federation Protocol Entity därmed är leaf och dess Entity Configuration inte ska innehålla federation_entity-metadata.

D. Registration Entity och “vad som intygas”

Profilen beskriver att en Federation Registration Entity (Immediate Superior) registrerar genom att skapa/signera Subordinate Statement, och att detta “vouching” bl.a. omfattar:

• bindningen mellan federationsnyckel och Entity Identifier,

• att innehavaren är legitim representant för Entity Identifier,

• att entiteten är legitim medlem i federationen.

Det är här kopplingen till anslutningspolicyn blir praktisk: anslutningspolicyns organisationsverifiering och delegationskontroller är det som gör att registreringsentiteten kan “vouch:a” på ett meningsfullt sätt.

...

3. Tabellutkast i samma format som Sweden Connect metadata (för OpenID Federation + Trust Marks)

Nedan är ett första utkast där jag använder samma kolumner som i portal-underlaget (Attribute, Type, Required, Description, Validation, Specification).
Jag har valt dot-notation för att tydliggöra var ett fält hör hemma (top-level i Entity Statement vs under metadata.openid_relying_party).

3.1 Entity Configuration 

Attribute	Type	Required	Description	Validation (svensk profil)
iss	String (URI)	Yes	Utfärdare av entity statement. För en entity configuration är detta entitetens entity identifier och den som signerar statementet.	HTTPS-URI. För self-signed entity configuration ska iss vara identisk med sub.
sub	String (URI)	Yes	Subjektet för entity statement; entitetens entity identifier i federationen.	HTTPS-URI. Ska motsvara entitetens identifierare.
iat	Number	Yes	Tidpunkt då entity statement utfärdades.	Unix-tid (sekunder).
exp	Number	Yes	Sista giltighetstid för entity statement.	Unix-tid (sekunder). Måste vara senare än iat. Bör sättas så att caching fungerar men att ändringar ändå kan slå igenom inom rimlig tid (profilen betonar operativa konsekvenser av för kort/lång giltighet).
jwks	Object (JWKS)	Yes	Publika federationsnycklar som används för att verifiera signaturer på entity statements (federation entity keys).	Endast publika nycklar. keys-array krävs. Varje nyckel ska ha unikt kid. Nyckeluppsättningen ska vara stabil nog för federationens cache-/resolverbeteende.
authority_hints	String[] (URI)	Yes (för Federation Protocol Entities)	Pekar ut entitetens immediate superior(s) som entiteten registrerats under. Används för att bygga tillitskedja.	I svensk profil är en Federation Protocol Entity alltid en leaf entity (p.g.a. rollseparation), och ska därför normalt alltid ha authority_hints (ej tom). Varje värde ska vara HTTPS-URI.
trust_anchor_hints	String[] (URI)	No	Extra hint om vilka trust anchors som är relevanta för entiteten.	Om angiven: får inte vara tom. HTTPS-URI. Bör endast användas om federationen kräver explicit förankring utöver normal kedjebyggnad via authority_hints.
metadata	Object	Yes (för Protocol Entities)	Metadata per entity type (t.ex. RP/OP/AS/Client/Resource). Anger protokollrollens kapabiliteter och preferenser.	Rollseparation: En Federation Protocol Entity ska inte inkludera metadata av typen federation_entity. Endast protokollrollernas metadata ska förekomma (t.ex. openid_relying_party, openid_provider, etc.).
trust_marks	Object[]	No	Trust marks som entiteten presenterar. Kan användas som kontrollmekanism i federationen.	Varje objekt ska innehålla trust_mark_type och trust_mark (JWT). Validering och eventuellt komplettering via resolver kan vara en del av federationens driftmodell; konsumtionsparter bör inte anta att avsaknad i entity configuration alltid betyder “saknas i federationens resolve”.

3.2 Trust Marks (struktur)

3.3 Metadata för openid_relying_party (exempel på RP/client-metadata inom federation)

Not: Ovan RP-tabell är avsiktligt kort (utkast). Portal-underlaget innehåller en mer komplett uppsättning OIDC client metadata-fält (redirect_uris, request_uris, token_endpoint_auth_method, response_types, grant_types, alg-val etc.).
För “ersättning till OpenID Federation” är den centrala skillnaden att dessa fält uttrycks som metadata.<entity_type>.<param> och att federation-lagret (Entity Statement claims + trust marks) tillkommer.

...

Om du vill att jag ska göra nästa iteration utan att vara “kort” i RP-metadata-delen kan jag ta hela fältlistan från portal-underlaget och:

• flytta den till metadata.openid_relying_party.*,

• lägga till federation-claims (authority_hints, fed

  Sweden Connect metadata portal_…

  st_marks`),

• samt rensa bort Sweden Connect-/Swedish OIDC Profile-specifika valideringar och ersätta med OpenID Federation-referenser och policy-hookar (Trust Anchor/Registration Policy).

Sweden Connect metadata portal_…

Sweden Connect metadata portal_…

Sweden Connect metadata portal_…

Sweden Connect metadata portal_…