5 Konceptuell lösning – hur det är tänkt att fungera

5.1 Tekniska krav

Som tidigare nämnt är det övergripande målet att bygga en infrastruktur för datautbyte mellan offentliga och privata aktörer, som kontrolleras av datasubjektet.

Arbetsförmedlingen definierar datasubjektet som den individ eller organisation som har rättigheterna att hantera personliga eller privata data. Datasubjektet är oftast den person vars data som avses, men kan skilja sig från dataägaren eller datainnehavaren.

Mot bakgrund av hur Arbetsförmedlingen tolkar mandatet för uppdraget att utveckla en datainfrastruktur för kompetensförsörjning och livslångt lärande (Regeringsuppdrag N2021/01915) och Min Profil har vi även angett de huvudsakliga krav som vi vill uppfylla när vi bygger denna typ av infrastruktur:

  1. Individcentrerat:
    Se till att datasubjektet med befogenhet över data möjliggör utbyte (dvs. inte automatisk delning mellan system). Arbetsförmedlingen lägger tonvikten på kontrollsidan av delningen, snarare än på typen av data som delas (t ex personuppgifter). Denna tolkning gör att vi kan bredda vad som delas och i viss mån vem som godkänner överföringen. Under den första implementeringen tittar Arbetsförmedlingen specifikt på fallet där den person vars data som avses godkänner överföringen. I framtiden skulle vi kunna tillåta en delegering av befogenheter där en individ kan få behörighet att ha tillgång till och hantera data (t ex en företagsadministratör, en handläggare etc).
  2. Utnyttja befintligt regelverk:
    Lansering med stöd av befintligt regelverk samt att föreslå framtida förbättringar i lagen. Arbetsförmedlingens mål är att bygga en infrastruktur som kan verka utifrån gällande lagstiftning och inte utifrån hur vi förväntar oss att framtida regelverk kommer se ut. Till exempel använder Arbetsförmedlingen ramverket för Eget Utrymme för att ge individer tillgång till data och för att möjliggöra delning mellan offentliga organisationer.
  3. Skalbarhet:
    Stödja en utökning av datatyper, organisationer (offentliga och privata) samt användare och scenarier. För att säkerställa infriandet av den sista punkten, utökning av scenarier, har Arbetsförmedlingen beslutat att infrastrukturen ska kunna stödja minst två olika fall med olika komplexitet samtidigt; 1) ett utbyte av certifikat, 2) en insamling av datapunkter från olika källor och utbyten. Detta kommer till viss del att säkerställa att vi inte levererar ad-hoc-lösningar för ett enskilt specifikt fall.
  4. Användarvänlig och enkel integration:
    Ambitionen är att infrastrukturen ska bli en de-facto standard för att dela digital information i Sverige. Anslutning till infrastrukturen bör dock vara frivillig och inte påtvingad. Eftersom Arbetsförmedlingen vill att så många individer och organisationer (både offentliga och privata) som möjligt ska se ett värde i att ansluta sig till infrastrukturen, strävar vi efter att minska tröskeln för anslutning genom att skapa grundläggande funktioner för en enkel tillgång och integration med infrastrukturen. Genom att skapa alla nödvändiga delar kommer vi dessutom möjliggöra att piloterna fungerar tillräckligt bra från dag ett.
  5. Öppen källkod:
    All källkod som produceras publiceras öppet så att andra kan både granska och bidra till utvecklingen. Arbetsförmedlingen kommer till exempel att skapa referensimplementationer för en digital plånbok, identitetsleverantör, dataleverantör samt ett utrymme för personens egen data, men de är byggda i moduler som enkelt kan bytas ut till andra från olika leverantörer. Genom att lägga all kod tillgänglig för andra som vill Arbetsförmedlingen också uppmuntra andra aktörer att utveckla nya tjänster kopplade till infrastrukturen. Detta tillvägagångssätt tvingar oss dessutom att använda öppen källkod snarare än att skapa inlåsningseffekt av enskilda leverantörer genom att använda eller påtvinga våra användare licensierade verktyg.
  6. Klar för produktion:
    Arbetsförmedlingen utvecklar datainfrastruktur som stödjer minst två livepiloter med olika komplexitet innan slutet av 2022(33).

5.2 Hur det fungerar

Som tidigare nämnt utgår Arbetsförmedlingen från att individer med största sannolikhet kommer påbörja sina ärenden på datakonsumentens hemsida, och bli ombedd att samtycka till datadelningen. Detta är nyckeln till en snabbare utveckling och att användare i stor skala drar nytta av den lösning som är under utveckling. Vår strategi är att integrationen sker mellan organisationer (offentliga och privata) snarare än att ha en direkt kontakt med individen.

Individer kommer fortfarande att ha sin digitala plånbok där de kan begära, samla och dela data, men vi arbetar utifrån antagandet att organisationer (datakonsument/tjänsteleverantör), offentliga och privata, kommer att presentera Min Profil för sina kunder.

Som ett exempel på situation antar vi att Rebecca vill ansöka till Handelshögskolan i Stockholm. Rebecca kommer att gå till universitetets webbplats, fylla i ansökningsformuläret och hon kommer att ombedjas att inkludera sitt examensbevis med betyg från gymnasiet. Hon kommer att klicka på knappen "Hämta e-dokument" som kommer att leda till hennes digitala plånbok. Här kommer hon att kunna begära informationen direkt från sin gymnasieskola, granska informationen och skicka intyget till Handelshögskolan i Stockholm, för att slutföra sin ansökan(34).

Nedanstående bild visar hur processen fungerar:

Beskrivning av det generella flödet

Baserat på bilden ovan beskrivs här det generella flödet:

  1. Individen går till datakonsumentens/tjänsteleverantörens webbplats för att få den önskade tjänsten.
  2. Datakonsumenten/tjänsteleverantören förbereder en dataförfrågan och omdirigerar individen till sin digitala plånbok för att godkänna begäran.
  3. Efter identifiering begär individen att datan hos datainnehavaren skickas till den digitala plånboken.
  4. Väl i plånboken granskas datan och individen kan samtycka till vidare delning med datakonsumenten/tjänsteleverantören.
  5. Datakonsumenten/ tjänsteleverantören får tillgång till data och ett äkthetscertifikat.

Alla fall i datainfrastrukturen att följa samma mönster.

Det måste dock noteras att datainnehavare också kan vara datakonsumenter och vice versa (till exempel när datainnehavare ombeds att skapa ett dokument och de behöver ytterligare data innan de utfärdar det).

Dessutom är datasubjektet både datainnehavare (när de delar data) och datakonsumenter (när de begär data). Det innebär att en databegäran kan initieras av datasubjektet, när en individ exempelvis begär arbetstillstånd från Migrationsverket för framtida användning.

5.3 Teknologi och arkitektur

5.3.1 Detaljerad beskrivning av flödet

Varje datahanterare/datainnehavare består av flera komponenter(35) som visas i bilden nedan.

Detaljerad beskrivning av flödet

Datainfrastrukturen består av identitetstillhandahållaren, den digitala plånboken, pod-servrar, valideringsregistret och komponenter för mottagare/exportör.

Alla delar av infrastrukturen tillhandahålls som ”open source” och är öppen för andra att bidra till. Alla bidrag behöver kontrolleras och godkännas av organisationen ansvarig3(6) för underhållet av infrastrukturen, innan det blir en integrerad del av infrastrukturen.

Alla delar kan bytas ut mot andra tredje-parts-mjukvaror eller lösningar så länge de möter infrastrukturens krav kring integration och kommunikation med ”podservrarna”. T ex kan ingen ytterligare data levereras utöver det som efterfrågas från datakonsumenten vid varje enskild begäran.

Baserat på bilden ovan beskrivs här det generella flödet:

  1. Datasubjektet (individen) besöker datakonsumentens hemsida för att använda en tjänst (t ex ett försäkringsärende, jobbansökan eller annat)
  2. Datakonsumenten begär av individen att den hämtar och delar viss data som behövs för att hantera efterfrågad tjänst
  3. Datasubjektet förflyttas till den digitala plånboken där identifiering sker via identitetstillhandahållaren.
  4. I den digitala plånboken kan datasubjektet begära data från datainnehavaren. Systemet skulle kunna tillåta förhandsgodkännanden, men nuvarande regelverk kräver att individen granskar datan innan den delas vidare.
  5. Begäran hanteras av inbox-modulen i ”pod-serven” och skickas till den dataleverantör där data är lagrad.
  6. Dataleverantören, om det är en offentlig aktör, håller den begärda datan i ett eget utrymme(37). Vid begäran säkerställer dataleverantören att datan tillgängliggörs till “pod-servern”, samt dokumenterar transaktionen i sitt eget digitala arkiv.
    1. När data tillgängliggörs “pod-servern” genererar dataleverantören en privat nyckel, en publik nyckel och ett intyg, som verifierar äktheten hos källan av data, och att datan inte har modifierats. Den publika nyckeln och intyget, skickas till valideringsregistret för senare nyttjande (se 8a).
  7. När data når “pod-servern” så lagras den först, för att sedan tillgängliggöras datasubjektet i den digitala plånboken. Individen (datasubjektet) kan först då kontrollera datan, för att sedan tillåta att datan delas med datakonsumenten.
  8. När ett godkännande är medgett så tillgängliggörs datan i “pod-servern” till datakonsumenten som kan fortsätta tillhandahålla efterfrågad tjänst enligt 1.
    1. Den offentliga nyckeln (Intyget) som dataleverantören genererar (6a ovan) tillgängliggörs även datakonsumenten som därmed kan verifiera äktheten av källan och datan.

5.3.2 Val av teknologi

När Arbetsförmedlingen skulle bestämma sig för hur infrastrukturen skulle byggas, var vi tvungna att välja mellan att bygga ett nytt system eller använda ett befintligt system. Med tanke på tidsbegränsningen beslutade vi att det gick snabbare att använda ett befintligt system.

Under uppdraget att möjliggöra lösningar för individen till kontroll och insyn av data om individen(38) undersökte Arbetsförmedlingen två teknologier, MyData(39) och Solid(40). Båda testerna visade hur en digital infrastruktur kan utformas för att ge människor mer insyn och kontroll över sin personliga data och hur information kan delas mellan myndigheter och privata aktörer.

För uppdraget att utveckla en datainfrastruktur för kompetensförsörjning och livslångt lärande (Regeringsuppdrag N2021/01915) bestämde Arbetsförmedlingen sig för att gå vidare med Solid då det fungerar på ett sätt som ligger i linje med både svenska och europeiska krav för att öka transparensen och kontrollen som individen har över sin data.

Solid (Social linked data) är en vidareutveckling/utökning på befintliga webbstandarder för att ge individer möjlighet till ägarskap och kontroll över sin personliga data på webben. Solid grundas i länkade data och är en möjliggörare för att utforma en datadriven infrastruktur.

Solid låter individer lagra sin personliga data säkert i ett decentraliserat datalager (även s.k. Solid Pods). När data lagras i någons Pod styr individen genom den digitala plånboken vilka personer och applikationer som kan komma åt den.

De främsta skälen till att välja Solid är:

  • Solid bygger på väletablerade webbstandarder(41) som styr samspelet mellan datalagring och åtkomst, i ett distribuerat ekosystem av tjänsteleverantörer och dataproducenter.
  • Solid Pods är en lämplig metod för att hantera datalagring som är i linje med regelverket för Eget Utrymme.
  • Solid pod-data kan lagras på en central plats eller som en distribuerad konfiguration, vilket möjliggör stor flexibilitet i implementeringen.
  • Andra befintliga (om än begränsade) institutionella projekt som för närvarande byggs med Solid(42) och ett aktivt community(43) som kan stötta oss i vår implementering.

Även om Solid är designat/utformat för att vara decentraliserat, så kan vi inte nyttja Solid till dess fulla potential på grund av begränsningar i svensk lagstiftning och i Arbetsförmedlingens mandat. Detta medför att vissa delar av infrastrukturen behöver driftsättas och hanteras centralt och att viss funktionalitet ej kan nyttjas fullt ut, t ex länkad data som förändras över tid.

5.3.3 Solid och datainfrastrukturen

För att förklara med en metafor löser Solid transportlogistiken mellan lagerlokaler. Låt oss anta att personinformation lagras i paket och att dessa paket är placerade hos flera lagerlokaler. Varje organisation som har informationen kan ha ett eller flera datalager. Vad Solid gör är att låta individer hitta det paket som behövs (t ex organisation, lagerlokal, gång, ställning och hylla) och levererar det dit individen vill.

Dock, som tidigare nämnts, bygger vi inte datainfrastrukturen med Solid och dess fulla möjligheter eller intentioner. På grund av våra krav har Arbetsförmedlingen behövt göra följande justeringar:

  1. Vi måste säkerställa att individer samtycker till hämtning och leverans av data innan informationen kan nå den mottagande organisationen. Vi har därför justerat det naturliga informationsflödet genom att lägga till ett kontrollsteg innan den slutliga leveransen görs. Med det nya flödet kommer individen att göra en begäran om att hämta data, inspektera dess innehåll (kontrollpunkt) och godkänna leveransen till den avsedda destinationen.
  2. På samma sätt vill den mottagande parten försäkra sig om att data som kommer från den tilltänkta parten, inte manipulerats under transporten, och att data innehåller det de letar efter. Solid tillåter till viss del en lösning på detta genom att inkludera något som ett "leveransdokument", som anger hur informationen läses och vad som är innehållet. Vi behövde dock inkludera en mekanism i processen för att intyga leveransens ursprung och för att försäkra den mottagande parten om att informationen i data inte har ändrats under transporten. Vi utvärderade möjligheten att göra detta med blockchain-teknologier, men identifierade bl a svårigheter med att bevara individers personliga integritet, då data t ex inte kan tas bort helt. Vi beslutade därför att integrera "leveransdokumentet" med Verifiable Credentials(44), en öppen standardlösning för digitala referenser.
  3. Även om Solid är tänkt att erbjuda decentraliserade lagringslösningar, är dess struktur ganska flexibel gällande sättet att konfigurera den. När Arbetsförmedlingen nu skapar en referensimplementering, både för att sätta standarder för framtida implementeringar, och för att tillhandahålla verktygen för de som inte kan implementera sin egen lösning, har vi valt en centraliserad arkitektur. Denna lösning kommer vara lättare att upprätthålla tills parterna som ansluter till infrastrukturen har bekantat sig med tekniken.
  4. En annan förändring, som ännu inte har implementerats fullt ut, är att Solid använder ett enda WebID per datasubjekt vilket möjliggör spårbarhet för användaren under vissa omständigheter. För att undvika problemet har vi maskerat WebID under MVP-fasen. En mer permanent lösning kommer dock att vara att utfärda flera WebID:n per användare och per datakonsument(45).

Solid är en relativt ny teknik att arbeta med vilket skapar en del utmaningar. Det tar till exempel förhållandevis lång tid att förstå hur det fungerar. Det finns ett relativt litet community som stödjer med detta, och som kan hjälpa till att lösa utvecklingsfrågor. Arbetsförmedlingens bedömning är att fördelarna överväger utmaningarna.

Ovanstående lista över skillnader är inte helt fullständig. För mer information om hur datainfrastrukturen fungerar och har byggts, se projekt ’repository’ på https://gitlab.com/arbetsformedlingen/individdata/oak Länk till annan webbplats..

5.3.4 Integration av dataleverantören och datakonsumenten

En särskild notering behöver göras gällande hur datakonsumenter och datainnehavare integrerar med infrastrukturen och förstår varandra. Hur vet infrastrukturen var informationen, som datakonsumenten kräver och som efterfrågas av datasubjektet, finns att få tag på?

Till dags dato (juni 2022) har vi ännu inte börjat arbeta i den exporterade/importerande komponenten som används av datainnehavaren och datakonsumenten för att interagera med resten av infrastrukturen. Likväl är det på följande sätt Arbetsförmedlingen planerar att lösa problemet.

För att individer ska kunna uppfylla dataförfrågningar, måste datakonsumenter och dataleverantörer i förväg deklarera dess behov och kapacitet vid koppling till infrastrukturen. Datakonsumenter måste deklarera vilken typ av data som kan hanteras (och i vilket syfte) från individen. Dataproducenter måste deklarera vilken typ av data som kan utfärdas på individens begäran. Detta gör det möjligt att hitta vilken dataleverantör som har den data som behövs.

Kommunikation mellan de olika parterna (datakonsumenter, dataproducenter och infrastruktur) sker via HTTP REST gränssnitt i enlighet med protokoll som definieras av Solid standarden, och hur informationen är organiserad och representerad enligt RDF-schemat(46).

Det är viktigt att poängtera att infrastrukturen är dataagnostisk och ej dikterar hur domänspecifika nyttodata organiseras och tolkas. Gemensam förståelse och standardisering av domänspecifika data måste växa fram utifrån behov och initiativ inom branscher/domäner.

5.4 Definierade förmågor

I tidigare stycken nämner vi de främsta nackdelarna och fördelarna för varje aktör i datainfrastrukturen. Nedan kommer vi att titta på de viktigaste förmågorna systemet har som gör det möjligt för datainfrastrukturen att uppfylla alla aktörers behov:

5.4.1 Huvudsakliga förmågor

  1. Flytta data (begära och dela):
    Denna förmåga gör det möjligt för individer att få information från en aktör som innehar personliga data (datainnehavaren, till exempel en skola, Skatteverket etc.) och skicka den till andra aktörer som behöver informationen (datakonsumenten, till exempel ett försäkringsbolag, en arbetsgivare etc.). Dataöverföring möjliggörs via en digital plånbok och inkluderar möjligheten att begära data från en datainnehavare och dela den med en datakonsument. Dataflyttning sker via kopiering av originalinformationen så att data vid källan förblir intakt.
  2. Identifiering av individer:
    Individer kommer att behöva identifiera sig både för att få tillgång till sina uppgifter och för att hantera sina data. Det säger sig självt att identifiering är viktigt av säkerhets- och integritetsskäl. Det är dock också särskilt viktigt för datainnehavaren och datakonsumenten, som måste se till att de hämtar eller använder data för rätt individ. Identifiering utförs av en applikation som hålls åtskild från den digitala plånboken så att andra aktörer kan tillhandahålla sin lösning(47).

    Infrastrukturen använder för närvarande BankID och integration med FrejaID har också påbörjats, men den kommer inte att slutföras under MVP-fasen på grund av tidsbegränsning. Integration med byggblocket Identitet skulle vara nästa naturliga steg om den föreslagna infrastrukturen antas rikstäckande.
  3. Granska data:
    Individer som vill flytta data kommer att ha möjlighet att kontrollera; 1) vilken data de ska begära, 2) vem de får data från, 3) vilken data som hämtas, 4) i vilket syfte de delar data och 5) vilken aktör de ska dela data med. Detta tillåter total kontroll över förflyttningen av informationen och transaktionen kan stoppas vid vilken tidpunkt som helst. Till exempel, om en individ behöver skicka intyg om arbetslöshet från Arbetsförmedlingen till sitt försäkringsbolag för att få pengar utbetalda. Då kan individen begära underlag och kunna granska intyget/datan innan den skickas till försäkringsbolaget.
  4. Samtycke till dataöverföring:
    En individ som vill flytta data måste förse organisationen där data hanteras med ett godkännande (samtycke(48)) som gör det möjligt för organisationen att skicka data dit den behövs och att undanta datainnehavaren och datahanteraren från eventuella framtida ansvar för data när det väl överförts från deras miljö. Samtycket lagras oftast av organisationen för att bevisa att begäran har hanterats i enlighet med lagen. Denna möjlighet kan bli överflödig om lagen tillåter en "överenskommelse" mellan parterna som en grund för databehandlingen.
  5. Lagra och återanvänd data:
    Individen kan lagra sin information för senare användning. Denna förmåga är möjlig eftersom det går att lagra information inom det personliga lagringsutrymmet (Pod). Detta möjliggör en smidigare upplevelse, särskilt i de scenarier när data inte är lättillgänglig hos datainnehavaren på begäran. Återanvändning av data är begränsad till dess giltighet: om informationen har löpt ut (t ex ett visumdokument) kan den inte återanvändas.

    Den initiala implementeringen av infrastrukturen kommer att inkludera en centraliserad molnlagringslösning. Pods skulle också kunna placeras på den enskilda datorn eller mobila enheten, vilket gör det möjligt att hämta vissa typer av dokument (som transportdokument, vaccinationsbevis etc.) trots att det inte finns internetanslutning eller om dokument behöver visas direkt på begäran(49). Lagringen är frivillig och individer har alltid rätt att radera informationen i sina personliga lagringssystem. Radering påverkar inte data hos datainnehavaren. Lagringslösningar och funktioner hålls åtskilda från datahanteraren så att tredje part kan tillhandahålla alternativa tjänster (som enhetslagring).

    OBS: möjligheten att lagra information på personliga enheter är inte en del specificerat i något av uppdragen, och omfattas inte i implementeringen av MVP.
  6. Certifiering av datagiltighet:
    Både individer och datakonsumenter kommer att vilja säkerställa att de får; 1) information som inte har löpt ut, 2) data från den önskade källan och 3) att informationen inte har manipulerats under transporten. Detta uppnås med att datat omfattas av, och signeras som, en "verifiable credential” (50).
  7. Systemmeddelanden och kommunikation mellan aktörer:
    Den personliga digitala plånboken har en inkorg där individer kan få systemaviseringar som läskvitto eller datatillgänglighet. Till exempel skulle individen vilja veta när en information har lästs av den mottagande parten efter att den har delats med den parten. Eller när information är redo att hämtas när den inte var direkt tillgänglig på begäran. Detta meddelandesystem skulle kunna användas för att möjliggöra kommunikation mellan individer och andra aktörer. Vi rekommenderar dock att den här funktionen begränsas på något sätt för att undvika att spamma individer. Vi föreslår därför att individer alltid kan initiera kommunikationen med en datainnehavare och en datakonsument. Offentliga organisationer, oavsett om det är datainnehavare eller datakonsumenter, kan också kommunicera med individen när som helst. Om organisationen däremot är en privat organisation, oavsett om den är datainnehavare eller datakonsument, kan den bara svara på kommunikation som initierats av individen.

    Det måste noteras att även om systemaviseringsfunktionen kommer att finnas tillgänglig i MVP-versionen av infrastrukturen, kommer den mer utarbetade kommunikationen mellan parterna att behöva utvecklas under senare versioner.
  8. Adressering av data:
    Under introduktionsprocessen måste både datainnehavaren och datakonsumenten specificera den data de gör tillgänglig och den data de behöver. Datainnehavaren kommer att behöva kortfattat beskriva den data de kan förse individer med, och varje datapunkt som den innehåller. Denna uppgift, som vi förväntar oss kommer att vara tidskrävande, kommer dock att bli mindre besvärlig övertid då vi förväntar oss att en del av uppgifterna återkommer i många dokument och då inte behöver beskrivas på nytt. Datakonsument, å andra sidan, kommer under sin introduktionsprocess att kunna välja vilket dokument och vilken datapunkt som helst som görs tillgänglig av datakonsumenten och binda den till en specifik intern process. På så sätt kommer de att kunna informera individer om vilken data de behöver, vem de kan hämta den från och för vilket ändamål de behöver den.

5.4.2 Kompletterande förmågor

  1. Multipla databegäranden och aggregerad delning:
    I många fall behöver individer samla in flera uppgifter från olika myndigheter och dela den insamlade informationen samtidigt. Om en immigrant till exempel vill ansöka om praktik via Arbetsförmedlingen måste personen inhämta bevis i form av uppehållstillstånd, arbetstillstånd, arbetslöshetsintyg, kvalifikationer etc för att få godkänt. Tack vare datainfrastrukturen kommer individer att kunna begära alla dokument samtidigt och även dela dem alla på en gång.
  2. Dela med flera parter samtidigt:
    När data väl har hämtats kan individer tillåtas att dela samma information med flera parter samtidigt, vilket i praktiken uppfyller ”once-only-principle”. Implementeringen av dessa förmågor ingår inte i produktens första MVP eftersom vi behöver klargöra om regelverket tillåter att ett enda samtycke(51) kan tillämpas på flera parter förutsatt att syftet med transaktionen förblir detsamma och att parterna är kända av individen.
  3. Begränsning av dataanvändning:
    Datainnehavaren skulle kunna begränsa användningen av data, antingen genom att begränsa syftet eller genom att begränsa vilken aktör som kan ta emot uppgifterna. Begränsad delning kan också tillämpas på branscher. Denna funktion, som för närvarande inte är implementerad i MVP, bör hanteras varsamt, och endast med tydlig juridisk ledsagning. Detta beror på att datainnehavaren redan har befogenhet att begränsa informationsutbytet och ofta tenderar att tolka lagen på ett restriktivt sätt.
  4. Spåra data, ärenden och beroenden av ärenden:
    Infrastrukturen kommer att lagra loggar över dataförflyttningar inklusive samtycke eller återkallande av samtycke, data som delats och med vem, syftet, varifrån datan kommer, när den har begärts etc. Detta innebär att individer kommer att ha en fullständig bild av all dataförflyttning som initierats av dem. Dessutom, och som även beskrivs i inledningen, kommer datainnehavare och datakonsumenter att skicka individers ärendenummer så att personer kan hänvisa till ett specifikt ärende när de handlar med tredje part.

    I vissa fall är begäran av data beroende av andra data från andra myndigheter. Som beskrivits tidigare, till exempel när en individ begär en kvalificering för praktik via Arbetsförmedlingen, kommer myndigheten att kräva att ytterligare underlag från Migrationsverket tas fram. I detta scenario, eftersom varje myndighet måste utfärda ett ärendenummer, kommer systemet att kunna koppla varje ärendenummer till det överordnade ärendet.

    Länkning av ärendenummer för att följa aggregerad databegäran är inte implementerad, men möjligheterna finns för tredjepartsapplikationsutveckling.

 

 

33) Uppdraget att utveckla en datainfrastruktur för livslångt lärande ska slutrapporteras sista januari 2023.

 

34) Överföringen av skolbetyg är redan digital. Användarfallet visar hur överföringen skulle kunna hanteras av individen.

 

35) Bilden ämnar inte vara en fullständig bild av datainfrastrukturen och saknar några viktiga tekniska element (t.ex. datainnehavarens och datakonsumentens Pods) för enkelhetens skull.

 

36) Se kapitel 13 Rekommendationer och förslag till fortsatt arbete

 

37) Detta är inget krav. Som beskrivet i det juridiska kapitlet, kan vissa myndigheter föredra att lämna ut data till en individ genom en Eget Utrymme-miljö.

 

38) Se bland annat https://www.digg.se/analys-och -uppföljning/publikationer/publikationer/2021-06-01-uppdrag-attmojliggora-losningar-for-individen-till-kontroll-och-insyn-av-data-om-individen

 

39) Se bland annat https://www.mydata.org/

 

40) Se bland annat https://solid.mit.edu/

 

41) https://en.wikipedia.org/wiki/Web_standardshttps://en.wikipedia.org/wiki/Web_standards

 

42) Se bilaga 1 för några av projekten

 

43) https://forum.solidproject.org/. Also, Accenture, has announced the support of Solid - https://newsroom.accenture.com/news/accenture-invests-in-data-technology-company-inrupt.htm

 

44) https://www.w3.org/TR/vc-data-model/

 

45) Lösningen har också föreslagits av Sunet: https://kushaldas.in/posts/targeted-webid-for-privacy-in-solid.html

 

46) https://en.wikipedia.org/wiki/RDF_Schema

 

47) Alla tredjepartslösningar kräver integration med den ursprungliga infrastrukturen. Se kapitel 11 om Beroenden och avgränsningar nedan

 

48) Se kapitel 9 Rättslig analys

 

49 Denna förmåga kan leda till att vara användbar för Uppdrag I2022/01265 - Uppdrag att ta fram en eller flera digitala plånböcker inom ramen för EU:s storskaliga pilotprojekt

 

50) Se (https://www.w3.org/TR/vc-data-model/).


51) Som nämnts tidigare, om "Avtal" används som rättslig grund, istället för "samtycke", kan funktionerna implementeras.

Hjälpte denna information dig?

Ditt svar hjälper oss att förbättra sidan

Senast uppdaterad: