På sidan:

 Översikt relationer

Figur 1, piloten

R1, federationsoperatör mot anslutningsoperatör. Digg mot Inera respektive Internetstiftelsen. Heldragen, alltså en etablerad federationsrelation som regleras direkt. Detta är operatörsavtalet.

R2, anslutningsoperatör mot federationsmedlem. En av operatörerna mot EHM. Heldragen. Detta är anslutningsavtalet, och det är den enda vägen in i federationen för en federationsmedlem.

Figur 2, framtida läge

R1 upprepas när ytterligare anslutningsoperatörer tillkommer. Streckad, alltså framtida.

R2 upprepas per federationsmedlem, oberoende av vilken operatör som anslutit dem. Heldragen mot EHM, streckad mot tillkommande medlemmar.

R3, anslutningsoperatör mot anslutningsoperatör. Röd streckad, alltså indirekt. Operatörerna har ingen egen relation utan är förbundna genom att båda har R1 mot samma federationsoperatör. Det är den relationen som bär tilliten mellan medlemmar anslutna via olika operatörer.

R4, federationsmedlem mot federationsmedlem. Blå, alltså övrig avtalsrelation och inte en federationsrelation. Här ligger det verksamhetsmässiga utbytet mellan parterna, utanför det federationen reglerar.

Möjlig lösning

Att skriva samma materiella regler i varje avtal skapar tre problem. Reglerna glider isär över tid, en ändring kräver omförhandling med varje part, och det blir oklart vad som egentligen gäller lika för alla.

Lösningen är att samla det som gäller lika för alla på ett ställe. Federationsoperatören publicerar Federationsregelverk BAS, och varje avtal hänvisar till det. Genom hänvisningen blir regelverket avtalsinnehåll i just den relationen. Parterna binds alltså inte till varandra av regelverket i sig utan var och en till sin motpart, med samma innehåll.

Uppgift till 4 september

 Vad bedömer vi särskilt behöver regleras i de två relationerna inom ramen för piloten:

• Digg (federationsoperatör)
• Inera (Anslutningsoperatör)
• Internetstiftelsen (Anslutningsoperatör)
• EHM (Federationsmedlem)

Piloten finns beskriven på Idé till pilot - RU Identitet & Behörighet - Confluence

Utgå från utskickat ramverk.

Rollerna och ansvaret ska inte omdefinieras. Vi utgår från Bilaga D, Roller och ansvar, och bygger vidare på det som redan står där. Om ramverket beskriver en roll på ett sätt som inte fungerar, ska det hanteras som en synpunkt på delningen och leda till ändring i ramverket, inte till en avvikande beskrivning i pilotavtalen. Vi vill inte skapa en parallell verklighet inom piloten.

• Bilaga A — Definitioner - RU Identitet & Behörighet - Confluence
• Bilaga D — Roller och ansvar - RU Identitet & Behörighet - Confluence

Utgångspunkt

Vid mötet 2026-08-19 enades vi om att ingen part ensam tar fram ett första utkast. I stället tar varje part hem frågan och besvarar den utifrån sin egen roll. Svaren samlas in, slås ihop till en gemensam bruttolista och sorteras vid nästa tillfälle.

Vi enades också om att börja smalt. Vi utgår från de parter och de två relationer som finns i piloten och löser inte den skalbara avtalsmodellen nu. När vi vet vad som materiellt behöver regleras mellan få parter blir det enklare att avgöra hur samma innehåll kan göras skalbart.

Vad uppgiften går ut på

Varje part svarar på följande fråga, för de relationer där parten själv är part:

Utifrån vår roll och det ansvar som beskrivs i federationsplattformens ramverk:

• vad behöver regleras mellan oss och vår motpart för att vi ska kunna delta i piloten?

Frågan besvaras separat för R1 och R2.

 Bruttolista över vad vi anser behöver regleras

Tidplan och form
Svar lämnas senast 3 september till Johan Tjäder, eller skrivs direkt in i tabellen på Avtalsarbete
Digg sammanställer inkomna svar till en gemensam bruttolista före nästa möte