Events als Verifiable Credentials opslaan

[marcvanandel]

• oorspronkelijke data integriteit 'verzekering'
• oorsprong van de data 'verzekering'

[kad-busses]

#13 omschrijft wat VCs zijn en waar die inzetbaar/nodig zijn. Het uitdelen van het eigendomsbewijs door het Kadaster en identiteitsbewijs door de overheid is geïndentificeerd in dat issue. Wat nog niet duidelijk is of de events in VCs gevat moeten worden en hoe dat er dan uit ziet.

Waarom events überhaupt opslaan als verifiable credential? Het uitgangspunt van (Solid) PODs is dat je zelf de regie hebt over de data. Dus wie daar bij kan, maar ook wat daar precies in staat. Hoewel het opslaan van het onderhandelen in events er historie en herleidbaarheid aan geven zijn ze nog steeds kwetsbaar voor wijzigingen. Er staat de eigenaar van de POD niets in de weg om biedingen (events) uit het verleden te herschijven. Dit ondermijnt (potentieel) de integriteit van de data en daarmee het vertrouwen in het proces. Door events te combineren met VCs geeft het als het ware een "echtheidscertificaat" aan zowel de uiteindelijke koopovereenkomst, als de tussengelegen events waaruit die koopovereenkomst is opgebouwd.

[kad-busses]

Het is niet toereikend om de (kale) events op te slaan in de eigen POD, om bovengenoemde reden. Er zijn verschillende ontwerpen denkbaar hoe we Verifiable Events (VE) kunnen maken.

Ontwerp (1)
Middels de Koopovereenkomst app (KOEK App) creëer je een event die in je eigen POD wordt opgeslagen. Ook geef je een VC uit aan de ander, welke in diens POD wordt opgeslagen. Dit leidt er effectief toe dat de events dubbel worden opgeslagen. In je POD beschik je aan het einde van het proces over je eigen events en de (gesigneerde) events van de ander.

Ontwerp (2)
Variatie op ontwerp (1), alleen wordt hierbij enkel de proof of een hash van je event opgeslagen in de aggregate van de ander.

Ontwerp (3)
Het dubbel opslaan van gegeven kan verkomen worden door de events enkel bij de ander op te slaan. Jij doet immers een bod aan de ander, het event kan daardoor (door jou ondertekend) opgeslagen worden bij de ander. Dit voelt echter tegenstrijdig met het principe dat je zelf over je eigen data beschikt.

Ontwerp (4)
Het is ook mogelijk om een (neutrale) derde partij te introduceren: "De Digitale Makelaar". Deze makelaar legitimeert de biedingen/events door ze te ondertekenen. Dit kan gerealiseerd worden als een backend waar de KOEK App mee praat. Het plaatsen van een bod wordt dan voorzien van een ondertekening van de digitale makelaar. De andere partij kan de events uit jou PODs op deze manier verifiëren bij de makelaar.

Ontwerp (5)
Koper en verkoper zouden zelf hun events kunnen ondertekenen, maar dan de events elders kunnen opslaan, in een gedeelde omgeving. Bijvoorbeeld een (huis)kluis of een omgeving die klaargezet is door de makelaar.

[kad-busses]

Ontwerp (4) lijkt voor nu het interessants om verder uit te werken, omdat deze het beste balans lijkt te bieden tussen "data bij de bron" / "regie op eigen data" en gevalideerde en verifieerbare data. Dat komt er dan grofweg als volgt uit te zien:

versie 0.1. Koos en Vera werken via de KOEK App, welke dan verbonden is met een digitale makelaar, welke hun acties kan bevestigen. De Verifieerbare Events worden in hun eigen POD opgeslagen.

Wat nog niet in het plaatje zichtbaar is en verder moet worden onderzocht is:

• De verkoper moet genotificeerd worden als de koper een bod plaatst. Wordt dat een toevoegen aan de Koopovereenkomst Aggregate, of zit daar misschien iets in de Solid standaard voor. Dit kan verder onderzocht worden in Notificaties bij updates (vooral van andere partij) #26
• VCs hebben de mogelijkheid te verlopen of te revoken. Wat willen/kunnen we daarmee? Bijvoorbeeld als bewijs van legitimatie van de digitale makelaar, uitgegeven door NVM/KvK?

[kad-busses]

In dit ontwerp zijn er een aantal verschillende VCs:

• credentials uitgegeven door Kadaster / Overheid
• ondertekende events tijdens onderhandelingsproces
• access control zodat koper en verkoper bij elkaar (private) events kunnen. Die willen we immers niet publiekelijk beschikbaar maken

[marcvanandel]

'The aggregate' is hier een mistig concept. Er is namelijk een aggregate die alle data bevat van de koopovereenkomst. Dit is de door events opgebouwde koopovereenkomst, de gedataficeerde koopovereenkomst dus. Deze bestaat voor het grootste gedeelte van het proces alleen in memory in de 'KOEK app' (wat een geniale naam!! 😆 )

Bij een Event Sourced systeem is er een dedicated EventStore die ondersteuning biedt voor het event sourcen ... welke in dit geval ontbreekt. Daarom is er extra administratie nodig om bij te houden welke events er bij een aggregate horen. Bijv. koopovereenkomst (aggregate) http://localhost:3001/verkoper-vera/koopovereenkomst/id/345 bestaat uit deze events:

koopovereenkomst:
    prov:wasGeneratedBy 
        event:1169a7f6-aebc-4c0e-b69b-ba5f6530a72c,
        event:1bc24631-de10-42b1-8ffe-6c0509336dfa,
        event:3c27a67c-ab1e-49cf-8e22-90f58e924e95,
        koperEvent:36cf9c26-c692-48ee-8802-c8979a66d2d4,
        event:674b0ed0-6501-42c1-aa99-1d045030288d,
        koperEvent:3dcf3747-185f-4862-a442-47de5e236fa9,
        event:817f3528-aa93-45bd-8462-ee43837f8df4,
        koperEvent:4f5e143b-e2df-4fe9-9770-99c6b5bd4054,
        event:9b39855b-5c40-4635-b0e8-906cbddcbc23,
        koperEvent:87ce3023-ed73-4054-91fb-943b47c98a1a,
        event:ad7ed2b1-8cda-4e5a-838b-c7790dcb9107,
        koperEvent:9b899c79-865b-4820-8583-0156fc4b1443,
        event:c572c5c8-2c84-4b5a-8eb2-630215eae840,
        koperEvent:a3dd7c4b-1572-4837-a9fc-46219b751495,
        event:c87c8a9b-0419-4b4f-89ed-3c97a5b3b51c,
        koperEvent:c2a70f99-1542-4dc7-a9eb-c055158041bc,
        event:f587c64e-d006-442c-9252-2d6ca21190af
     .

Deze wordt bijgehouden in de POD van Verkoper Vera aangezien de 'aggregate administratie' staat op de plek waar de (Web)ID van de aggregate naar verwijst.

Open staand punt: Hoe weet de koper dat deze lijst niet door de verkoper is aangepast en dus of die wel compleet is?

• Zou de lijst van events als VC door de digitale makelaar 'ge-issued' moeten worden?
• Zou er in de koper POD een schaduw administratie (= dezelfde administratie) moeten worden bijgehouden?
  In dat geval is het toevoegen van een event door de 'KOEK app' past geslaagd als:
  1. De Verifiable Event is opgeslagen in de POD van de betreffende actor
  2. De lijst van events is bijgewerkt in de 'aggregate administratie' van de verkoper (en bijgewerkt in de POD van de verkoper) én
  3. De lijst van events is bijgewerkt in de 'aggregate administratie' van de koper (en bijgewerkt in de POD van de koper)
• Nog anders ... ?

[kad-busses]

Ah check, de term 'aggregate' deed me aan event sourcing denken, 'aggregate administratie' zet (mij) daardoor op het verkeerde been 😇. Dit gaat over de event metadata, dus iets als: verkooplogboek (VLB)?

Open staand punt: Hoe weet de koper dat deze lijst niet door de verkoper is aangepast en dus of die wel compleet is?

Dit vind ik een interessante. Het uitgangspunt van Solid / pods is dat je zelf de beheer over je data hebt (toch?). Verschuiven we dit nu niet naar: data over jou wordt bij jou opgeslagen? Of eigenlijk: in hoeverre gaat dit over trust?

We kunnen natuurlijk alle interactie (events, VLB) laten signen door een makelaar, maar op welk punt hadden we die data niet beter in een makelaar pod kunnen opslaan? Gezien de events, logboek en koopovereenkomst over meerdere partijen gaat.

• Nog anders ... ?

Nou ja, events en logboek dus bij "een digitale makelaar" in de pod opslaan. Koper/verkoper hebben beiden dan alleen lees en append rechten. Weten ze beiden zeker dat de andere partij het niet gewijzigd heeft en heb je voor dit stukje geeneens VCs nodig. Het eindproduct (de koopovereenkomst) kan (als VC?) bij koper en verkoper in pod opgeslagen worden.

[marcvanandel]

OK. VCs zijn 😎 ... maar laten we deze niet nú overal toepassen 😁

Besloten in overleg:

• Events geproduceerd door de actors verkoper en koper zouden best VCs kunnen zijn op verschillende manieren ... maar voor de demonstrator laten we dit achterwege
• Als events gesigned worden (gepubliceerd als VCs) dan is een signing service van de makelaar wel een tof concept. Dat betekent namelijk dat een onafhankelijke 3e partij meekijkt bij het vaststellen / publiceren van events én deze als gezien 'stempelt' - als VCs uitgeeft - terwijl de events zelf in de POD worden opgeslagen van de actor die het event produceert / triggered. Dus géén 'makelaarsPOD' zoals het eerste idee waarin alle events worden bewaard als 'neutrale datakluis' tussen de partijen, maar iedere actor bewaart zelf hun eigen data. Maar wel door een 3e partij gewaarborgd dat deze officiëel zijn geproduceerd - en verifiëerbaar ongewijzigd!
• Ook het ondertekenen van de (concept) overeenkomst gaan we in de demonstrator NIET opnemen. Hier wordt hard aan gewerkt in het traject voor een Europese Digitale Identiteit (EDI) ... en zodra dat er is, zal daar ook 'iets met VCs' in mogelijk worden gemaakt. Voor ons buiten scope.

Daarmee sluit ik dit issue aangezien we de events (dus) NIET als VCs gaan toevoegen / produceren / bewaren / opslaan.