Låt oss göra en communityinsats!

Vi listar öppna programvaruprojekt som används inom offentlig sektor i Sverige. Vår ambition är att möjliggöra för myndigheter som står inför en upphandling eller anskaffning av ett nytt system att utvärdera befintliga öppna programvaruprojekt i relation till deras kravlista.

En utvärdering av motsvarande öppna programvaruprojekt kan även ses som ett sätt utveckla den egna kravhanteringen och som en del i informationsinsamlingsarbetet. Detta kan sedan ligga till grund för uppföljande RFI:er och upphandlingen i sig.

Gå in på https://gitlab.com/open-data-knowledge-sharing/wiki/-/wikis/Katalog-över-öppen-programvara-inom-offentlig-sektor

För mer information gå in på http://nosad.se

@dennis_priskorn I nätverket NOSAD hostar och ansvarar olika myndigheter och organisationer för olika delar av infrastrukturen. Arbetsförmedlingen ansvarar för https://nosad.se och det vi lägger upp på wikin. Vi ansvarar också för tidigare diskussionsforum som vi på Jobtech (Arbetsförmedlingen) använder. DIGG ansvarar för innehållet för detta forum och Internetstiftelsen bidrar genom att bl.a. arrangera själva videomötena.

Internetstiftelsen använder sig av Zoom. Det vi får via Internetstiftelsen är stöd vid bokning, utskick, kalendarium. Dessutom redigering av videeoinspelningar samt coachning och teknisk moderering under alla våra workshops. Detta är mycket värt och mer än bara en annan lösning som vi sätter upp själva. Jobtechdev kör internt Jitsi, men vi får prestandaproblem redan vid 30-40 användare, samt att flera organisationer inte kan använda jitsi. Just ur ett tillgänglighetsperspektiv har Zoom fungerat mycket bra. Men frågan om videoverktyg bör gå till Internetstiftelsen. Vi har redan uppmärksammat osäkerhet kring Zoom och har en dialog kring verktyg men i närtid kommer vi att fortsätta med befintlig lösning.

Nu har videoinspelningen kommit! Gå in på https://youtu.be/UvtX4e_qRWY Inspelningen ligger också på nosad.se

@dennis_priskorn bra kommentarer. Funkar det bra för Wikimedia borde det vara gångbart även för oss.

Nu finns inspelningen också upplagd: https://youtu.be/sfWWPpTysjk

@jonass Precis, när vi började lansera våra API:er och även lanserade betaAPI:er var den vanligaste frågan. "Kan man lite på beständigheten". Ingen vill riska tid och därmed pengar på att utveckla mot något som kan tas bort eller ändras markant på kort tid eller är för instabilt.

Superbra exempel! På Jobtech Development blev vi så inspirerade av dina exempel så vi tittar på om vi kan skapa en "paketerad"-miljö för icke-programmerare.

Missa inte denna workshop 2 mars kl 10-12.

Fördelarna och utmaningarna kring öppen programvara är många, och något vi berört tidigare. Men hur kan vi bli praktiska och hjälpa varandra ta de första stegen till att börja använda, utveckla och upphandla öppen programvara?

I denna workshop gör vi en utblick i omvärlden och får höra lärdomar och tips från andra länder i hur de har hanterat motsvarande frågor. Bl.a. hur Italien och Frankrike arbetar centraliserat på myndighetsnivå med att hjälpa, utbilda och guida myndigheter kring frågor som upphandling, kultur och utveckling av öppen programvara. Vi får även höra från den danska kommunföreningen OS2 och hur de samverkar sinsemellan och med leverantörer kring utveckling av öppen programvara.

Presentatörer:

Leonardo Favario, Open Source Project Leader, Department for Digital Transformation (motsv. DIGG) i Italien
Bastien Guerry, Free Software Officer, Etalab (motsv. DIGG) i Frankrike,
Rasmus Frey, Executive Director, OS2 - Public Digitalization Network i Danmark

För anmälan: https://www.goto10.se/event/samverkan-kring-oppen-programvara-inom-inom-offentlig-sektor-hur-gor-man-i-andra-lander/

Arbetsförmedlingen (Jobtech Development) använder Jupyter för historiska annonser. https://github.com/simonbe/afhistorik/blob/master/notebooks/API_description.ipynb

Vidare används Jupyter i följande projekt: Create a daily labor demand index based on job ads to calculate total available jobs in Sweden for a given day between 2006-2020¶
https://github.com/kevindeeboman/masters_project/blob/main/masters_project.ipynb

Nedan delar jag ett inlägg från min kollega Jonas Södergren på Jobtech Development/AF kring nyckelhantering av öppna API:er. (I detta inlägg föreslås inga nycklar, men frivillig registrering via exempelvis detta forum!)

Tillåt anonym användning av öppna apier
Förslaget bygger på principen att det ska vara frivilligt att ange vem man är vid interaktion med det offentligas öppna data, förslaget i sin korthet innebär att:

• det ska vara frivilligt att ange vem man är

• ett spårbarhets-id kan anges vid interaktion med offentliga öppna API:er ^1

• offentliga aktörer kan använda DIGG:s forum som utfärdare av id:n för spårbarhet

Definitionen av öppna data säger:

Öppna data är sådana data som vem som helst fritt får använda, återanvända och distribuera med som största motprestation att ange källa eller krav på att dela data på samma sätt.
– Open Knowledge Foundation, en ideell organisation som verkar för utveckling av öppna data [^2]

En tvingande identifiering av användare bör ses som icke förenlig med intentionen i PSI-lagstiftningen [^3] och kommande öppna data direktiv 2019/1024. En rimlig tolkning är att det offentliga ska undvika att ställa motkrav på konsumenterna av offentlig information vilket inkluderar identifiering av användaren.

Organisationer som tillhandahåller öppna data vill kunna stävja missanvändning och följa hur öppna data skapar nytta, det blir rimligen svårare när det finns en osäkerhet angående vem som använder ett API. Från användarens synvinkel föreligger oftast behov av att få regelbunden information om kommande uppdateringar och inträffade incidenter etc. Med en genomtänkt arkitektur föreligger ingen motsättning i att tillhandahålla en anonym tillgång och samtidigt ha en dialog med användarna i en separat kanal. Möjlighet att följa användningen och att garantera driftsäkerhet går alltså att kombinera med anonym tillgång till API:et där alternativet att spåra användning erbjuds som ett tillägg.

Förslag till lösning
I korthet innebär lösningen att användaren:

kan prova eller använda API:er i produktion utan att ange sin identitet.
frivilligt kan förmedla en identitet som används för att följa användningen och kan vara krav för att erbjuda en högre servicenivå.
kan kvittera ut ett id baserat på sitt användarkonto i Sveriges utvecklarportal [^6].

Hur förmedlar användaren sin identitet?
I HTTP-protokollet finns attributet referer [^4]. Detta attribut kan med fördel användas för att förmedla från vilken del av en webbtjänst som anropet görs. Informationen från referer är lämplig att använda för analys, logging med mera.

Attribut from kan användas för att frivilligt förmedla en identitet. Ursprungligen användes attributet för att förmedla en e-mailadress. Men i denna rekommendation föreslås en kryptologisk hashad URL (till ett användarkonto) som inte kan återskapas av tredje part. Processen för att hasha URL:en föreslås ske från ett redan öppet forum såsom DIGG:s utvecklarportal där användaren frivilligt har skapat ett användarkonto.

Referer
HTTP headers är ett sätt för en klient att skicka ytterligare information till en server. Mozilla beskriver syftet enligt följande.

When making resource requests to another domain, this would be the address of the page using the resource

Exempel på information som kan förmedlas till API:et via en http header:

Referer: https://jobbsajt.se/jobbsök
Vilken del av URL som förmedlas till servern bestäms av den referrer-policy [^5] som klienten väljer.

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

From
Myndigheter har användarforum för att diskutera med sina användare, antingen i form av den nationella Community på Sveriges dataportal eller domänspecifika som exempelvis Jobtechdev.se/forum. För dessa forum finns redan existerande användarprofiler och det är utifrån dessa användarprofiler som ett spårbarhets-id kan skapas. Attributet from i HTTP specificerar från början en email för den användaren som kontrollerar anropet. Föreslagen lösning är är att användaren av offentliga API:er frivilligt kan ange sin hashade URI som värde i detta attribut.

Exempel på http header för en användare

From: 4cdf99d62d21f5f81dd6880e01a5390e
Exempel på hur användaren hämtar sitt id genom att logga in på portalen
Profil på generisk utvecklarportal
Profil på generisk utvecklarportal
1932×442 79.4 KB

Hur kan DIGG eller annan myndighet skapa ett id för användaren Profil - jonas - JobTech Development forum
echo -n https://forum.jobtechdev.se/u/jonas/ | md5
4cdf99d62d21f5f81dd6880e01a5390e
Notera! Istället för md5 bör kanske sha256 användas och eventuellt med en HMAC (innehåller en privat nyckel) så att inte tredjepart kan återskapa hashsumman från de publika profilerna.

echo -n "URI-till-publik-profil" | openssl dgst -sha256 -hmac "hemlig-nyckel" -binary | openssl enc -base64 -A
Lösningen är alltså inte en autentiseringslösning och ska inte heller användas för att bestämma åtkomst till en resurs.

En lösning som skalar
Fördelen med att identiteten skapas baserat på att användaren finns i DIGG:s Community på Sveriges dataportal underlättar både för användaren och de myndigheter som tillhandahåller öppna data. Användaren kan skapa ett konto med tillhörande “nyckel” för alla myndigheters API:er samtidigt som myndigheter inte behöver ha en egen kontohantering.

Införande
Arbetsförmedlingens plattform jobtechdev.se planerar att prova ovan koncept i Q2 och vi är väldigt intresserade av återkoppling.

Referenslista
[^2]: Open Definition 2.1 - Open Definition - Defining Open in Open Data, Open Content and Open Knowledge, 2019-10-16.
[^3]: Lag (2010:566) om vidareutnyttjande av handlingar från den offentliga förvaltningen Svensk författningssamling 2010:2010:566 t.o.m. SFS 2019:943 - Riksdagen
[^4]: Referer - HTTP | MDN
[^5]: Referrer-Policy - HTTP | MDN
[^6]: https://community.dataportal.se/

@stefan-wallin tolkar tråden och ditt inlägg som om flera i forumet är inne på rate-limiting i kombination med en uppskalad tjänst där någon nivå av identifiering förekommer. Tanken med att koppla till Diggs Community är att låta myndigheter lita på varandra och på sina invånare. Säger någon att de är från Jordbruksverket eller IDG så kan vi välja att lita på detta, även om vi inte har krav på eID-lösning. Det är ju fortfarande API:er för öppna data lösningen bygger på. Inte data där vi förväntar oss eller har rätt att ens förvänta oss motprestationer. Däremot har olika API:er i alla fall hos oss olika kapacitet. Lösningen borde då bli att:

1. Vill man inte identifiera sig finns det en rate-limiting
2. Identifierar man sig genom forumet (som teoretiskt inte behöver vara sanningsenligt, men som vi tror kommer vara det i högre utsträckning än bara en email eftersom det finns incitament till att medverka i communityn) så kan man via forumet kontakta ansvarig för API:et och på så sätt få den kapacitet man behöver, eller att vi blir varse att det finns ett reellt behov av mer kapacitet.

@jonass Precis, när vi började lansera våra API:er och även lanserade betaAPI:er var den vanligaste frågan. "Kan man lite på beständigheten". Ingen vill riska tid och därmed pengar på att utveckla mot något som kan tas bort eller ändras markant på kort tid eller är för instabilt.

@dennis_priskorn bra kommentarer. Funkar det bra för Wikimedia borde det vara gångbart även för oss.

Nedan delar jag ett inlägg från min kollega Jonas Södergren på Jobtech Development/AF kring nyckelhantering av öppna API:er. (I detta inlägg föreslås inga nycklar, men frivillig registrering via exempelvis detta forum!)

Tillåt anonym användning av öppna apier
Förslaget bygger på principen att det ska vara frivilligt att ange vem man är vid interaktion med det offentligas öppna data, förslaget i sin korthet innebär att:

• det ska vara frivilligt att ange vem man är

• ett spårbarhets-id kan anges vid interaktion med offentliga öppna API:er ^1

• offentliga aktörer kan använda DIGG:s forum som utfärdare av id:n för spårbarhet

Definitionen av öppna data säger:

Öppna data är sådana data som vem som helst fritt får använda, återanvända och distribuera med som största motprestation att ange källa eller krav på att dela data på samma sätt.
– Open Knowledge Foundation, en ideell organisation som verkar för utveckling av öppna data [^2]

En tvingande identifiering av användare bör ses som icke förenlig med intentionen i PSI-lagstiftningen [^3] och kommande öppna data direktiv 2019/1024. En rimlig tolkning är att det offentliga ska undvika att ställa motkrav på konsumenterna av offentlig information vilket inkluderar identifiering av användaren.

Organisationer som tillhandahåller öppna data vill kunna stävja missanvändning och följa hur öppna data skapar nytta, det blir rimligen svårare när det finns en osäkerhet angående vem som använder ett API. Från användarens synvinkel föreligger oftast behov av att få regelbunden information om kommande uppdateringar och inträffade incidenter etc. Med en genomtänkt arkitektur föreligger ingen motsättning i att tillhandahålla en anonym tillgång och samtidigt ha en dialog med användarna i en separat kanal. Möjlighet att följa användningen och att garantera driftsäkerhet går alltså att kombinera med anonym tillgång till API:et där alternativet att spåra användning erbjuds som ett tillägg.

Förslag till lösning
I korthet innebär lösningen att användaren:

kan prova eller använda API:er i produktion utan att ange sin identitet.
frivilligt kan förmedla en identitet som används för att följa användningen och kan vara krav för att erbjuda en högre servicenivå.
kan kvittera ut ett id baserat på sitt användarkonto i Sveriges utvecklarportal [^6].

Hur förmedlar användaren sin identitet?
I HTTP-protokollet finns attributet referer [^4]. Detta attribut kan med fördel användas för att förmedla från vilken del av en webbtjänst som anropet görs. Informationen från referer är lämplig att använda för analys, logging med mera.

Attribut from kan användas för att frivilligt förmedla en identitet. Ursprungligen användes attributet för att förmedla en e-mailadress. Men i denna rekommendation föreslås en kryptologisk hashad URL (till ett användarkonto) som inte kan återskapas av tredje part. Processen för att hasha URL:en föreslås ske från ett redan öppet forum såsom DIGG:s utvecklarportal där användaren frivilligt har skapat ett användarkonto.

Referer
HTTP headers är ett sätt för en klient att skicka ytterligare information till en server. Mozilla beskriver syftet enligt följande.

When making resource requests to another domain, this would be the address of the page using the resource

Exempel på information som kan förmedlas till API:et via en http header:

Referer: https://jobbsajt.se/jobbsök
Vilken del av URL som förmedlas till servern bestäms av den referrer-policy [^5] som klienten väljer.

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

From
Myndigheter har användarforum för att diskutera med sina användare, antingen i form av den nationella Community på Sveriges dataportal eller domänspecifika som exempelvis Jobtechdev.se/forum. För dessa forum finns redan existerande användarprofiler och det är utifrån dessa användarprofiler som ett spårbarhets-id kan skapas. Attributet from i HTTP specificerar från början en email för den användaren som kontrollerar anropet. Föreslagen lösning är är att användaren av offentliga API:er frivilligt kan ange sin hashade URI som värde i detta attribut.

Exempel på http header för en användare

From: 4cdf99d62d21f5f81dd6880e01a5390e
Exempel på hur användaren hämtar sitt id genom att logga in på portalen
Profil på generisk utvecklarportal
Profil på generisk utvecklarportal
1932×442 79.4 KB

Hur kan DIGG eller annan myndighet skapa ett id för användaren Profil - jonas - JobTech Development forum
echo -n https://forum.jobtechdev.se/u/jonas/ | md5
4cdf99d62d21f5f81dd6880e01a5390e
Notera! Istället för md5 bör kanske sha256 användas och eventuellt med en HMAC (innehåller en privat nyckel) så att inte tredjepart kan återskapa hashsumman från de publika profilerna.

echo -n "URI-till-publik-profil" | openssl dgst -sha256 -hmac "hemlig-nyckel" -binary | openssl enc -base64 -A
Lösningen är alltså inte en autentiseringslösning och ska inte heller användas för att bestämma åtkomst till en resurs.

En lösning som skalar
Fördelen med att identiteten skapas baserat på att användaren finns i DIGG:s Community på Sveriges dataportal underlättar både för användaren och de myndigheter som tillhandahåller öppna data. Användaren kan skapa ett konto med tillhörande “nyckel” för alla myndigheters API:er samtidigt som myndigheter inte behöver ha en egen kontohantering.

Införande
Arbetsförmedlingens plattform jobtechdev.se planerar att prova ovan koncept i Q2 och vi är väldigt intresserade av återkoppling.

Referenslista
[^2]: Open Definition 2.1 - Open Definition - Defining Open in Open Data, Open Content and Open Knowledge, 2019-10-16.
[^3]: Lag (2010:566) om vidareutnyttjande av handlingar från den offentliga förvaltningen Svensk författningssamling 2010:2010:566 t.o.m. SFS 2019:943 - Riksdagen
[^4]: Referer - HTTP | MDN
[^5]: Referrer-Policy - HTTP | MDN
[^6]: https://community.dataportal.se/

@björn-hagström @salgo60
Härlig tråd! Hetta är bra! Vi kan väl bara konstatera att det tar tid för oss myndigheter att tillgängliggöra våra öppna data. Och trots att vi sedan 10 år tillbaka haft en PSI-lagstiftning så går det långsamt. Ur mitt perspektiv, och kopplat till länkad data så uteblir effekterna eftersom mycket av den data vi vill länka till inte är öppen idag, och kommer sannolikt inte bli öppen på två år. (Den tid myndigheterna har på sig att anpassa sina särskilt värdefulla datamängder till ny lag.) En uppenbar anledning till att vi inte kan släppa data som öppen är att den är "inlåst" i olika system. Vi behöver titta på hur vi kravställer IT-system. Vi behöver ta höjd för att data går att dela mellan olika system och att data går att få ut även när vi ersätter ett system. Krav på öppna standarder som går att implementera i öppna källkodssystem är en förutsättning för att kunna få ut mer öppna data.

Superbra exempel! På Jobtech Development blev vi så inspirerade av dina exempel så vi tittar på om vi kan skapa en "paketerad"-miljö för icke-programmerare.

Innovation förutsätter interoperabilitet, d.v.s. förmågan hos olika system, att fungera tillsammans och kunna kommunicera med varandra. Interoperabilitet i sig förutsätter öppna standarder för att undvika inlåsningseffekter. En öppen standard är en standard som kan implementeras i en öppen programvara. Hur ser ni till att bidra till innovation redan i projektinitieringsfasen? Kravställer ni öppna standarder? Om inte varför?

Nu har videoinspelningen kommit! Gå in på https://youtu.be/UvtX4e_qRWY Inspelningen ligger också på nosad.se

@dennis_priskorn I nätverket NOSAD hostar och ansvarar olika myndigheter och organisationer för olika delar av infrastrukturen. Arbetsförmedlingen ansvarar för https://nosad.se och det vi lägger upp på wikin. Vi ansvarar också för tidigare diskussionsforum som vi på Jobtech (Arbetsförmedlingen) använder. DIGG ansvarar för innehållet för detta forum och Internetstiftelsen bidrar genom att bl.a. arrangera själva videomötena.

Internetstiftelsen använder sig av Zoom. Det vi får via Internetstiftelsen är stöd vid bokning, utskick, kalendarium. Dessutom redigering av videeoinspelningar samt coachning och teknisk moderering under alla våra workshops. Detta är mycket värt och mer än bara en annan lösning som vi sätter upp själva. Jobtechdev kör internt Jitsi, men vi får prestandaproblem redan vid 30-40 användare, samt att flera organisationer inte kan använda jitsi. Just ur ett tillgänglighetsperspektiv har Zoom fungerat mycket bra. Men frågan om videoverktyg bör gå till Internetstiftelsen. Vi har redan uppmärksammat osäkerhet kring Zoom och har en dialog kring verktyg men i närtid kommer vi att fortsätta med befintlig lösning.

Nu finns inspelningen också upplagd: https://youtu.be/sfWWPpTysjk