Q3 | Verifiable Credentials en bewijzen over gegevens #13
Comments
|
Uit #10:
|
|
IRMA kan hier ook een voorbeeld in zijn danwel van afgekeken worden. Meer info over IRMA staat nu in #11 ivm authenticatie omdat IRMA daar nu specifieke oplossingen voor biedt. Onderwater zullen wel VC (like?) tech toegepast worden ?? Zie ook mijn vraag op edi.pleio.nl over online datakluis vs wallet |
|
Het voorbeeld van Sphereon is een 'fork' van Digital Bazaar. Deze partij zit ook achter het ontwikkelen van de specificatie(s). Verifiable Credentials als spec klinken mooi en bruikbaar ... maar een werkend voorbeeld maken is nog niet zo gemakkelijk gebleken. Het is wel gelukt om een VC te produceren ... maar het verifiëren vraagt meer infrastructuur ... of begrip van hoe dat dan werkt. We lopen vast op het aanleveren van context tbv verificatie en het is onduidelijk of dat externe services zouden moeten zijn of intern beschikbaar gemaakte resources (zoals public key). Sowieso zijn de specificaties van 2022 en komen we uiteindelijk terecht in 'Editors Drafts' ... die nog niet concreet bruikbaar zijn. Hier komen we ook op de DID spec terecht ... en daarmee op de meer blockchain georiënteerde oplossingen. Ook SolidLabs heeft hier nog challenges open staan: SolidLabResearch/Challenges#37 en SolidLabResearch/Challenges#72. In deze laatste wordt ook verwezen naar het vraagstuk hoe VCs en PODs zich tot elkaar verhouden.
|
|
DigitalBazaar/vc-js : the JWT serialization is not currently supported. OK. That's why it has to be a Verifiable Credential Data Integrity. |
|
OK. Digging a little further I stumbled upon an issue with an underlying lib: jsonld.js in combination with the ed25519-signature-2020 lib: digitalbazaar/jsonld.js#451 (comment) Another issue and help for our quest might be in this issue |
|
IRMA noemt VCs 'disclosure proofs' zie hoofdstuk Cryptographic Entities |
Vraag: Wordt de (IRMA vocab) Disclosure Proof van het eigenaar zijn bewaard in de POD (van de Verkoper) of is dat de enige manier om een perceel (KadastraalObjectID) toe te voegen en is de controle onderdeel van het proces om deze toe te voegen? Zie ook https://privacybydesign.foundation/irma-verifier/#issue |
|
Dit is wat ik zover heb kunnen vinden:
IRMA is een product (app) waarbinnen je zelf controle hebt over je attributen. Het doel van VC is om een open standaard te creeëren om credentials uit te kunnen wisselen. Op dit moment is IRMA niet compatible met VC en werkt dus alleen binnen het IRMA ecosysteem zelf. Er lijken meer demo's te zijn i.c.m. met IRMA, omdat die al verder lijkt te zijn. VC is echt nog meer in ontwikkeling.
In de code voorbeelden van VC wordt vaak een "document loader" genoemd. Dit is een stukje code die linked data kan de-references. De standaard loader die wordt meegeladen leest alleen vanaf lokale folders in. Je kunt hier bijv. ook een loader voor maken die URLs online ophaald en inlaad. Of een did-loader, die om kan gaan met decentralized documenten.
Middels DID kan er stukken data opgeslagen worden, maar dat is echter niet noodzakelijk voor VC. Het resolven ervan hangt van je DID-loader af, wat het portable maakt. Kan er verder niet veel over vinden, voor nu lijkt de WebID prima te volstaan voor onze demo.
De 'disclosure proofs' maken IRMA idd verifiable, maar is niet helemaal hetzelfde als een VC. Waar het hier bij beiden over gaat is de data integrity, het kunnen verifiëren dat je niet zelf aan de attributen loopt te sleutelen. Binnen VC signeert de issuer daar de credential die die uitgeeft. Iedereen kan die vervolgens verifiëren op basis van de meegeleverde proof, meestal een verwijzing naar de public key van de issuer. Binnen IRMA is het de IRMA server zelf die een signature toevoegd, de disclosure proof. Dat maakt het ook dat non-IRMA applicaties niet de IRMA attributen kan verifieren, maar alleen IRMA servers dat zelf kunnen, in tegenstelling tot VC.
Lijkt me wel? Binnen VCs kan er een hoop in een credential worden opgeslagen, en op basis van linked data. Dit is dan wat het Kadaster (als Issuer) uitgeeft. Deze credential kan je (als Holder) opslaan in je Pod. Binnen IRMA werkt dit vergelijkbaar, lijkt me.
Dat zou dan een Kadaster/makelaar app zijn die dat doet, right? Die leest het eigenaarschap uit je pod, stelt een overeenkomst op en schrijft dat (gesigneerd) in je pod weer weg. |
|
Voor de demonstrator kunnen we twee kanten op, gebruik van IRMA of van VC.
Gezien VC meer een open standaard is en er voorbeelden van beschikbaar zijn, is deze m.i. interessant om verder te onderzoeken. De opzet zou ongeveer als volgt kunnen zijn: Makelaar/Kadaster app voor het creeëren van de credential. Koper en verkoper met eigen Solid POD om overeenkomst in op te slaan. Wat ik echter nog niet helemaal helder heb is hoe / waar het signeren plaats vind. De Solid PODs hebben een private folder waarin de koper/verkoper hun private keys kunnen opslaan (tenminste, hoe private zijn deze écht?). Overheden bedrijven zullen geen eigen Pod hebben (toch?), maar leveren hun diensten via een (Solid) app. Het signeren van de credential zou dan in de back-end van de app kunnen(?), wellicht op basis van https://github.com/w3c-ccg/vc-api/ |
|
Op de host-data-registry-on-localhost branch onderzocht hoe credentials en presentations op te bouwen en te verifiëren. Op basis van die voortgang en inzichten zou de demo de volgende functionaliteit kunnen hebben:
|
|
Nice work, @kad-busses !! ❤️ it!! Het zou idd mooi zijn als we VCs kunnen testen, gebruiken, demonstreren. Ik denk dat daar meer mensen in geïnteresseerd zijn... (oa in Vlaanderen vermoed ik 😉 ) Ik denk dat we een proces (mag ook command line script zijn) die een 'Kadaster eigendomsbewijs VC' uitgeeft. Daarnaast hebben we een BRP (BasisRegistratie Personen) proces nodig (cli is OK) die VCs voor Koper Koos en Verkoper Vera uitgeeft (alias voor paspoort gegevens). De Koopovereenkomst App kan die info uit de PODs halen (eerst verwijzingen toevoegen of zo?) om de VCs te controleren en groene vinkjes weer te geven in de UI als VCs OK zijn. We zouden zelfs met een aantal foutscenario's kunnen spelen waarin de groene vinkjes een rood uitroepteken wordt ... ? Het ondertekenen van de koopovereenkomst, zou idd ook een VC kunnen zijn per gebruiker / ondertekenaar. Daarvoor is dan een private key nodig in elke POD? En de VC wordt gemaakt mbv de Koopovereenkomst App? 🤔 |
Nice, lijkt me een goed idee! 👌
Elke ondertekenaar zal een key nodig heb, de Een VC is iets wat door een Issuer uitgegeven wordt. De vraag wordt dan eigenlijk wat welke VCs (meerdere?) er precies nodig zijn, wat daar dan in staat, en door wie uitgegeven wordt. Is dat iets wat de koper en verkoper onderling doen, of wordt de uiteindelijke VC (bewijs van eigendom) uitgegeven door de notaris? Of is juist het idee dat de Koopovereenkomst App juist die rol van notaris inneemt? Wat ik tot dusver heb gezien is dat Solid apps front-end applicaties zijn. Als een notaris iets moet ondertekenen zou daar een back-end voor moeten zijn, of misschien heeft de notaris een eigen Solid pod?! |
|
Check. Voor SSH is de standaard (ik weet dat WebID ook auth mbv certs ondersteunt ... maar ik weet niet precies hoe en ik denk dat ondertekenen om een ander certificaat vraagt dan authenticatie ... 🤔 ) Welke VCs er nodig zijn voor ons voorbeeld, dan denk ik aan:
Zoiets? |
|
Yes, zat dat ook te denken! Met de WebID hebben we zelfs al gebruik gemaakt van auth 😁 Namelijk via de pod provider (solidcommunity, inrupts, etc..), die bevestigd dat wij daadwerkelijk eigenaar zijn van de WebID. Of dat stukje te hergebruiken valt om zelf dingen te ondertekenen ben ik niet tegengekomen en vermoed ik eigenlijk van niet. Eens met het lijstje VCs, ik mis eigenlijk alleen nog de terugkoppeling, de afronding zeg maar. Waar we volgens mij mee moeten eindigen is dat Koper Koos een VC heeft met bewijs van eigendom van het perceel, en dat de VC van Verkoper Vera revoked is (jaja, VCs kunnen statussen hebben). Volgens mij komen we dan op zoiets uit:
|
|
Nice! Love it (again) ❤️ ! Waarom we met de koopovereenkomst niet een nieuwe eigendomsbewijs kunnen uitgeven, is omdat deze niet verplicht ingeschreven hoeft te worden bij het Kadaster en niet tot verandering van de rechtssituatie leidt. Dat doet de leveringsakte die passeert op het moment van overdracht. De koopovereenkomst is het contract waarin staat dát die levering gaat komen, onder welke voorwaarden (voornaamste is koopprijs, maar natuurlijk ook staat van de onroerende goederen) en wanneer die levering dan gaat plaatsvinden. Dan zouden we dat ook allemaal mee moeten nemen in deze demonstrator ... wat uiteindelijk wellicht zou kunnen ... maar voor nu wil ik dat liever (nog) buiten scope houden. Wat we mondeling al bespraken, vind ik wel heel tof: alle events signen met eigen cert voor de events die een persoon produceert. Dus de events van de verkoper zijn gesigned door die verkoper en de events van de koper door de koper. De Koopovereenkomst App kan alle events verifiëren en aangeven dat dat idd klopt. Dat zou super cool zijn! |
|
Ah check, blijkt maar weer dat ik dat proces eigenlijk niet (zo goed) ken 🙈 Waar komt dan die leveringsakte vandaan, is dat vanuit de notaris? Moet ik me dan maar eens in verdiepen, wellicht dat we intern naar een kennissessie oid online hebben staan. Wellicht beter om dit nu buiten scope te houden inderdaad, niet moeilijker maken dan nodig 😇 |
|
Daar wordt het plaatje eenvoudiger van:
|
|
Het stukje (2) Onderhandeling wordt verder uitgewerkt in #25 |
|
In bovenstaand voorbeeld vullen de Rijksdienst voor Identiteitsgegevens en het Kadaster hun rol als bronhouder op een andere manier in: zij worden Issuer van VCs. Dit zie je in stukje (1). In algemene zin stellen wij dat elke bronhouder van een basisregistratie potentieel een Issuer van VCs is. Om een gevoel te krijgen bij wat dit betekent, wat er technisch (on)mogelijk is met VCs, welke veranderingen dit vraagt in de infrastructuur van die organisaties en hier onderbouwd iets over te beslissen, moet hiermee geoefend en geëxperimenteerd worden. In de demonstrator zijn er VCs nodig over zowel de betrokken personen als het betrokken perceel. Dit wordt ook wel het subject van een claim genoemd, niet te verwarren met een holder van de VC. Betrokken personen:
Betrokken perceel:
De VCs 'eigenaar van' en 'gevestigde publiekrechtelijke beperkingen' moeten ook weer ingetrokken kunnen worden. Als 'bonus' kan er nog meer informatie worden toegevoegd over het betrokken perceel en gebouw, inclusief de zekerheid dat deze informatie vertrouwd kan worden door de vorm van verifieerbare VCs. Dit ligt echter buiten scope van de demonstrator omdat bovenstaande informatie voldoende is om de technologie te beproeven. |
|
Zojuist besloten dat we de events NIET als VCs gaan produceren en opslaan. Daarom is #25 gesloten. We hebben ook besproken dat we het proces gaan uitbreiden naar het inschrijven van de koopovereenkomst door de koper. Dat betekent dat er een notaris signing service moet zijn, die de getekende concept koopovereenkomst van de koper (de data geminimaliseerde versie voor de koper) als VC gaat inschrijven bij het Kadaster. Alle VC onderdelen die we voor de demonstrator dan nodig hebben, zijn:
|
|
Het zou best tof zijn als we voor "demonstratiedoeleinden" de VC van het Kadaster ook zouden kunnen revoken (of een andere VC maar vindt het eigendomsrecht wat logischer) De overdracht zit niet in onze demonstrator maar puur om te laten zien dat dit wel mogelijk is. |
|
Pff ... leuk idee ... maar ook wel complex, hoor! 😳 |
|
én gerealiseerd in de demonstrator én beschreven in de documentatie 💪 |
Het revoken is overigens verder besproken in #44 |
OK. Er is data. Er is persoonlijke data die in mijn POD staat. Maar hoe kan een gebruiker met wie ik deze data deel er vanuit gaan dat die data waar, integer en oorspronkelijk van een authentieke bron afkomstig is? Hoe werken 'Verifiable Credentials' precies? Wat zijn 'Representations'?
Dit zijn vragen die in dit issue onderzocht en info over verzameld wordt.
The text was updated successfully, but these errors were encountered: