Community på Sveriges dataportal

Jag tror att med en exclude-include-lösning som @josefinlassi pratar om för de existerande parametrarna kan vi säkerligen komma riktigt långt med. Det är svårt för mig att resonera fram om det räcker eftersom mängden jag vill filtrera bland för att hitta en okänd guldnål i en höstack är så stor och jag inte vet om guldnålen finns där. Det är mer en explorativ sökning.

Angående @salgo60's lösning så känns den ganska överingenjörad och det är svårt att fylla caset "Jag vill hitta en datamängd jag kan vinna ett hackathon eller bygga en unik affärsidé på" är särdeles enkel att lösa med hjälp av ML just eftersom jag vill åt de datamängderna som inte är populärast eller nödvändigtvis har högst uppdateringsfrekvens. Det är ju inte ens så att vi optimerar för en återkommande besökare nödvändigtvis i detta fall utan bara göra datamängden mer utforskningsbar.

@salgo60 det skulle lämpa sig om du bröt ut ditt inlägg om DCAT-AP-SE till en egen tråd tror jag, det har inte riktigt med detta ämne att göra.

Jag skulle vilja få tillgång inte bara till öppna data, utan också skyddad data men som handlar om mig själv, så jag kan bygga tjänster där medborgarna kan utgå från sin egen data.

Exempelvis skulle jag vilja:

• kunna begära ut vilka personnummer och organisationsnummer jag har rätt att agera ombud åt.
• kunna hämta ut min vab-kalender från FK så att den kan integreras med min kalender
• kunna hämta ut min skattedata

Ett förslag till hur detta skulle kunna fungera är att DIGG hjälper till att samordna ett sätt att där jag som medborgare med hjälp av e-legitimation kan genomgå en oauth-liknande flöde och ge en tjänsteanvändare möjlighet att ge en tjänst tillgång till min och de entiteter jag är ombud för's persondata eller organisationsdata inom det offentliga. Det bör kunna finnas ett enhetligt sätt att göra detta snarare än att varje myndighet ska ta fram detta själva.

Det finns flera sorters data i öppna APIer men varje API tenderar att hålla sig inom samma sort. Exempel på datasorter:

• Statistik
• Definitionsdata
• Mätdata (realtid eller inte)
• Relationsdata mellan olika grunddata
• "Min data". Det vill säga data jag kan enligt GDPR begära ut om mig själv.

Det finns säkert någon slags datasort jag missat, men jag är ofta helt ointresserad av statistik som jag uppfattar upptar majoriteten av dataseten. Jag skulle önska en möjlighet att filtrera ut vissa av dessa kategorier när jag bläddrar igenom den oöverskådliga mängden av 7000+ API:er. Jag har exempelvis varit deltagare och organisatör på flertalet hackathons och problemet är att det är ofta helt oöverstigligt att sortera igenom denna enorma mängd av API:er för att hitta något intressant att basera en affärsidé eller verktygsidé på.

@jonass

Behovet av API-nycklar
Jag har lite svårt att förstå syftet med varför API-nyckeln ska behövas. Min magkänsla är snarare att detta är någon slags säkerhetsteater. Dessa är de potentiella syften jag kan utläsa:

1. Möjlighet att ur ett driftsäkerhetsmässigt sätt begränsa trafiken mot användare
Om vi inte kan kräva en registrering med identifiering före uthämtning av API-nyckel så finns inte heller en realistisk teknisk möjlighet att med hjälp av API-nyckeln effektivt strypa påverkan på driftsäkerheten. Med min erfarenhet av bl.a. DDOS-attacker på några av sveriges största nyhetssajter så kan jag säga att det bästa sättet är utan tvivel att samarbeta med stora DDOS-skydd eller helt enkelt göra tjänsten så snabb och uppskalad att driften ändå inte blir problemet man behöver lösa med API-nyckeln.

Exempelvis med den föreslagna lösningen så ska nycklar inte krävas för tillgång. Då kan man tänka sig att en försvarsmekanism är att när man utsätts för problematisk trafik tillfälligt blockera all trafik som inte har API-nyckel och bara servera till de med API-nycklar. Problemet är att en attackerare kan göra så att det ser ut komma från nästan vilket IP-nummer som helst och dessutom slumpa vilket IP-nummer som används för varje förfrågan. För varje förfrågan så kan även en attackerare generera upp en ny slumpad nyckel eftersom nyckelrymden är stor.

I övrigt anser jag att rate-limiting i kombination med en uppskalad tjänst är hygiennivån för ett öppet konsumerat API precis som @salgo60 föreslår.

2. Möjlighet att debitera för högre servicenivå
I din lösning har du angett alla parametrar som en användare behöver för att med relativt hög grad kunna tillförlitligt gissa sig till en användares API-nyckel(hashas url till användarkonto), det räcker med att jag skapar ett eget konto med en API-nyckel och testa mig fram till vilket krypto som används eftersom jag har all kunskap som behövs eller kan tillämpa statistiska metoder för att gissa salt med mera motmetoder.

En alternativ lösning (eftersom centraliserad öppen-data-api-nyckel är en bra idé om API-nyckel krävs för tillgång) skulle kunna vara genererade 2stycken uuid (client_id och client_token) som är helt slumpade men lagrad på ditt community-konto.
Isåfall måste en lista med priviligerade tjänster och deras token etableras som får verifiera client_id och client_token mot en api-nyckels-verifierande tjänst etableras som övriga myndigheter(de priviligerade tjänsterna) kan använda.

En vidareutveckling på en sådan lösning skulle kunna vara att den centrala tjänsten tillhandahåller samtliga API-nycklar som en data-källa och en webhook-baserad lösning(förmodligen med en AMQP eller liknande lösning i botten som data-garant) för att kontinuerligt informera de priviligerade tjänsterna om nya och borttagna API-nycklar. Detta skulle lösa ett problem med driftsäkerheten för att vi inte har en single point of failure(SPOF) i API-nyckel-verifierings-tjänsten utan varje myndighet kan ha sin egen instans av den gemensamt ägda öppen-källkods-tjänsten.

Om vi inte skulle se denna API-nyckelslösning som en autentiseringslösning öppnas nämligen en potentiell attackyta där en elak 3:e part kan överanvända api-användarens nyckel vilket beroende på debiteringsmodell kostar den godartade användaren pengar utan att så menades.

3. Möjlighet att för registrerade betalande kunder hålla en separat instans
Detta är en solid anledning att använda någon form av teknisk autentisering eller identifiering. Så att inte en attackerande part påverkar de betalande 3:e parternas prestanda likt det klassiska noisy-neighbour-problemet som är vanligt inom moln-infrastruktur.

Angående val av headers

FROM-headern
Jag tycker detta verkar vara ett missbruk av en existerande header. Att använda en header på ett sätt som det inte är avsett är generellt inte att rekommendera. Om ni väljer att skapa upp e-post-adresser som client-id så kan det vara en god idé. T.ex:
<user-uuid>@api-users.dataportal.se. Jag skulle rekommendera att använda from-fältet i kombination med Authorizationfältet som kan innehålla en token, exempelvis en JWT-token om ni vill på något vis scope:a token till vissa öppna API:er då ni kan skicka med scopes i JWT-tokenen och dela den nyckeln till den kryptokrafiska hashen av JWTn's innehåll med priviligerade tjänster.

Det står utryckligen i MDN:

You shouldn't use the From header for access control or authentication.

I HTTP-standarden är det ganska tydligt att det borde vara en e-post-adress.

The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322].