Standaarden en conformiteit

Een dataspace werkt alleen als deelnemers niet vastzitten aan één leverancier. Daarom spreekt de connector van buildinglinks dezelfde protocollen als connectors in andere Europese dataspaces. Een connector van een andere leverancier kan het lidmaatschap van een deelnemer controleren, en ziet een rechthebbende in buildinglinks als een gewone aanbieder van data. Waar de protocollen niets regelen, zoals een rechtsgeldige handtekening onder een mandaat, volgt de dataspace de Europese eIDAS-verordening.

Of de protocollen kloppen, toetsen we met de officiële testsuites van Eclipse. De resultaten staan onderaan deze pagina.

De standaarden op een rij

Standaard	Waarvoor	Waar
Dataspace Protocol 2025-1 (DSP)	De catalogus opvragen, een overeenkomst sluiten, een levering starten, pauzeren en beëindigen	Tussen connectors
Decentralized Claims Protocol 1.0 (DCP)	Aantonen wie je bent en dat je lid bent, en het lidmaatschap uitgeven	Tussen connectors, en tussen Trust Authority en connector
Data Plane Signaling 1.0 (DPS)	Het deel dat afspraken maakt, stuurt het deel dat data levert aan; de dataontvanger haalt data op met een token dat hij vernieuwt	Binnen een connector, en bij leveren namens een ander
W3C Verifiable Credentials 1.1 en Bitstring Status List	Het lidmaatschapsbewijs, en intrekken via een statuslijst	De Trust Authority geeft uit, elke connector controleert
did:web en did:webvh	De identiteit van elke deelnemer en de historie van zijn sleutels	Connector en Trust Authority
ODRL	De voorwaarden van een product en de inhoud van een overeenkomst	Catalogus en overeenkomst
eIDAS, met de CSC API en PAdES	De gekwalificeerde handtekening van een tekenbevoegde bij de aanmelding	Trust Authority, QTSP en EU DSS
RFC 3161	Gekwalificeerde tijdstempels op het bewijs	Trust Authority en een tijdstempeldienst
Brick, in het Buildinglinks-protocol	De vorm van gebouwdata: meetpunten, setpoints, installaties	Tussen de connector en het systeem of de app

Tussen de connectors lopen DSP en DCP, binnen elke connector DPS. De Trust Authority geeft het lidmaatschap uit met DCP en gebruikt eIDAS-diensten voor handtekeningen en tijdstempels. Met het systeem en de app spreekt de connector het Buildinglinks-protocol.

Data uitwisselen

Dataspace Protocol

Het Dataspace Protocol (DSP) regelt het gesprek tussen twee connectors. De dataontvanger vraagt de catalogus van een rechthebbende op en ziet welke producten er zijn, met bij elk aanbod de voorwaarden. Daarna onderhandelen de connectors over een overeenkomst. Met die overeenkomst start de dataontvanger een levering, die beide partijen kunnen pauzeren, hervatten en beëindigen.

Het Dataspace Protocol ondertekent de berichten zelf niet. De connector zet daarom een eigen handtekening in een extra header op elk bericht. Een connector van een andere leverancier negeert die header, dus aan de conformiteit verandert niets. Hoe die handtekeningen het bewijs vormen, staat bij Vertrouwen en bewijs.

Op een paar plekken gaat buildinglinks verder dan het protocol, steeds met een uitbreiding die een connector van een andere leverancier kan negeren: de melding dat een aanvraag op een besluit van de rechthebbende wacht, een bericht waarmee de dataontvanger een overeenkomst opzegt, en het gebruik van een levering in het statusbericht van DPS. Een andere connector merkt daar alleen van dat sommige dingen langer duren of niet zichtbaar zijn.

Data Plane Signaling

Een connector bestaat uit twee delen. De control plane maakt de afspraken en beslist, de data plane laat de data door en controleert elk verzoek. Met Data Plane Signaling (DPS) geeft de control plane de data plane opdrachten, zoals starten, pauzeren en beëindigen. Omdat die koppeling de standaard volgt, kan de control plane van de rechthebbende ook de data plane van een datahouder aansturen, zoals bij leveren namens een ander.

De data plane biedt alleen het pull-profiel van DPS aan. De dataontvanger haalt de data op, met een toegangstoken dat een uur geldig is en dat zijn gateway zelf vernieuwt. Push, waarbij de data naar de dataontvanger wordt gestuurd, biedt de dataspace niet aan.

TechnischProfielen en identifiers

• DSP-berichten gebruiken de JSON-LD-context https://w3id.org/dspace/2025/1/context.jsonld. De connector meldt zijn versie op /.well-known/dspace-version.
• Een onderhandeling begint altijd bij de dataontvanger, vanuit de catalogus. Een onderhandeling die bij de rechthebbende begint, weigert de connector met een 400.
• DCP gebruikt het credentialprofiel vc11-sl2021/jwt. De Trust Authority maakt statuslijsten als BitstringStatusList; een connector accepteert ook het oudere StatusList2021.
• Eigen handtekeningen op tokens en credentials zijn ES256 (P-256). De updatesleutels van did:webvh zijn Ed25519.
• Het adres van een levering volgt het DPS-profiel http-pull, met tokenvernieuwing. Berichten tussen control plane en data plane dragen een JWT die de afzender zelf tekent met de sleutel uit zijn DID-document. Een apart token-endpoint is daarvoor niet nodig.
• De registratie-endpoints van DPS zijn optioneel in de specificatie en niet gebouwd. Een data plane wordt aangemeld via de configuratie, of via de erkenning en aanwijzing.

Identiteit en lidmaatschap

Elke deelnemer heeft een DID van het type did:web: een webadres met een document waarin zijn publieke sleutels staan. Naast did:web houdt elke connector een did:webvh-log bij, een ondertekende historie van dat document. Daarmee is achteraf na te gaan welke sleutel op welk moment gold. In de protocollen blijft did:web de identifier.

Het lidmaatschap is een verifiable credential volgens het W3C-model, versie 1.1. De Trust Authority geeft het uit via het Decentralized Claims Protocol, met de rollen van de deelnemer erin. Vraagt een connector een catalogus op of start hij een aanvraag, dan haalt de andere connector via DCP het lidmaatschapsbewijs op en controleert hij handtekening, geldigheid, uitgever en status. Schorst de Trust Authority een deelnemer, dan zet hij diens bewijs op een statuslijst, en ziet elke connector dat bij de volgende controle.

Voorwaarden in ODRL

De voorwaarden van een product staan in ODRL, de W3C-taal voor gebruiksrechten die het Dataspace Protocol voorschrijft. De connector kent een vaste set condities: actief lidmaatschap, een rol uit het lidmaatschap, een bepaalde deelnemer, een datum, een doel, en de eis dat verzoeken om data ondertekend zijn. Een conditie die de connector niet kent, geldt als niet vervuld. Zo wordt een product nooit per ongeluk ruimer aangeboden dan bedoeld. Welk deel van een gebouw een overeenkomst dekt, staat ook in ODRL: in het target, met de gebouwen en de meetpunten.

Rechtsgeldige handtekeningen en tijdstempels

Een organisatie meldt zich aan met een mandaat voor haar connector. Een tekenbevoegde ondertekent dat mandaat en de aanvaarding van het rulebook met een gekwalificeerde elektronische handtekening. Onder eIDAS heeft zo’n handtekening dezelfde rechtskracht als een handgeschreven handtekening.

De handtekening komt van een gekwalificeerde verlener van vertrouwensdiensten (QTSP), via de CSC API van het Cloud Signature Consortium. De QTSP krijgt alleen een vingerafdruk van de documenten te zien, niet de documenten zelf. De Digital Signature Service (DSS) van de Europese Commissie zet de handtekening als PAdES in de PDF en valideert het resultaat. De Trust Authority accepteert alleen een handtekening die DSS als gekwalificeerd beoordeelt. Of de ondertekenaar echt tekenbevoegd is, controleert een medewerker van de Trust Authority in het Handelsregister.

Voor het tijdstip van het bewijs gebruikt de dataspace tijdstempels volgens RFC 3161. Connectors verankeren hun bewijslog elke minuut bij de Trust Authority, die als notaris alleen hashes ziet. De Trust Authority laat de ankers elk uur stempelen door een gekwalificeerde tijdstempeldienst. Voordat het certificaat van die dienst verloopt, zet hij er een archieftijdstempel overheen. Welke tijdstempeldienst de productie gebruikt, is nog niet gekozen.

Gebouwdata: Brick en het Buildinglinks-protocol

De protocollen hierboven zeggen niets over de inhoud van de data. Daarvoor is er het Buildinglinks-protocol, versie 1. Het beschrijft wat een systeem met gebouwdata aanbiedt, per gebouw: meetpunten opvragen, meetwaarden lezen, setpoints schrijven, het terugvalbeleid aanpassen, groepscommando’s geven en de indeling opvragen. Gebouwen heten naar hun pand in de BAG. Elk meetpunt en elke installatie heeft een klasse uit de Brick-ontologie, zoals een luchttemperatuursensor in een zone. Eenheden komen uit QUDT.

Het Buildinglinks-protocol is van buildinglinks zelf, geen Eclipse-standaard, en er bestaat geen TCK voor. De dataspace zelf hangt er niet van af: een systeem met een ander protocol kan ook, maar dan kan de connector een levering alleen per pad afbakenen, niet per meetpunt.

Hoe we conformiteit toetsen

Wat een TCK is

Een Technology Compatibility Kit (TCK) is een testsuite die bij een specificatie hoort. Het Eclipse Dataspace TCK-project publiceert er een voor DSP, DCP en DPS. De TCK speelt de andere partij, stuurt berichten, ook foute, en controleert elk antwoord, elke statusovergang en elke terugmelding. Slaagt een implementatie voor alle tests, dan gebruikt ze de berichten en toestanden die de specificatie voorschrijft, voor zover de TCK die afdekt.

Wij draaien de TCK’s ongewijzigd, in de uitgebrachte versie, tegen de echte programma’s: de connector, de data plane en de Trust Authority. De DCP-suites draaien daarnaast ook tegen een lichte testopstelling met alleen de DCP-onderdelen.

Wat de TCK-modus verandert

Een TCK gedraagt zich niet als een echte deelnemer. De DSP-TCK spreekt bijvoorbeeld geen DCP en meldt zich met een vast token, en welk scenario hij test, geeft hij alleen door via vaste id’s. Daarom hebben de programma’s een TCK-modus. Die accepteert het vaste token van de TCK, koppelt de vaste id’s aan de handelingen die het scenario verwacht, en zet klaar wat de TCK nodig heeft.

De protocolcode verandert niet. Berichten, toestanden, foutmeldingen en opslag zijn dezelfde als in productie. De TCK-modus mag alleen aan in een aparte testomgeving. In elke andere omgeving weigert het programma te starten als de modus aan staat.

Wat de TCK’s niet testen

• Push in DPS. De dataspace biedt push niet aan, dus die tests draaien niet.
• Twee DSP-tests van de levering, die in de TCK zelf zijn uitgeschakeld.
• Leveren namens een ander. DPS schrijft het aansturen van de data plane van een andere organisatie niet voor. Het gebruikt dezelfde berichten, met de controle van de aanwijzing erbovenop.
• De eigen uitbreidingen, zoals het gebruik van een levering in het statusbericht van DPS.
• Het samenspel van de connectors, de controles op gebouw en meetpunten, het bewijs, eIDAS en het Buildinglinks-protocol. Die testen we met de simulatie, een test die de hele simulatie doorloopt, en unit tests.

Resultaten

Deze tabellen komen bij het bouwen van de documentatie rechtstreeks uit de rapporten van de laatste TCK-runs. Elk rapport hoort bij de commit die erbij staat.

Protocol	TCK	Datum	Commit	Geslaagd	Resultaat
Dataspace Protocol 2025-1	dsp-tck-runtime:1.0.2	10 okt 2026	f7ec492	65 van 65	geslaagd
Decentralized Claims Protocol 1.0	dcp-tck-runtime:1.2.1	10 okt 2026	f7ec492	256 van 256 in 9 suites	geslaagd
Data Plane Signaling 1.0	dps-tck-runtime:1.3.0	10 okt 2026	f7ec492	26 van 26	geslaagd

Dataspace Protocol 2025-1

De connector, als rechthebbende en als dataontvanger.

Suite	Wat de TCK test	Geslaagd	Resultaat
MET	Versie-informatie	1 van 1	geslaagd
CAT	Catalogus opvragen	3 van 3	geslaagd
CN	Onderhandeling, connector als rechthebbende	15 van 15	geslaagd
CN_C	Onderhandeling, connector als dataontvanger	16 van 16	geslaagd
TP	Levering, connector als rechthebbende	15 van 15	geslaagd
TP_C	Levering, connector als dataontvanger	15 van 15	geslaagd

Decentralized Claims Protocol 1.0

De suites met testopstelling draaien tegen de lichte opstelling met alleen de DCP-onderdelen, de andere tegen de connector en de Trust Authority zelf.

Suite	Wat de TCK test	Geslaagd	Resultaat
cs-presentation	Credential service: presentaties en tokens (testopstelling)	19 van 19	geslaagd
cs-issuance	Credential service: opslag en uitgifte (testopstelling)	35 van 35	geslaagd
issuer	Uitgever van credentials (testopstelling)	41 van 41	geslaagd
verifier	Verifier, Bitstring Status List (testopstelling)	22 van 22	geslaagd
verifier-sl2021	Verifier, StatusList2021 (testopstelling)	22 van 22	geslaagd
issuer-authority	Uitgever van credentials: de Trust Authority	41 van 41	geslaagd
connector-cs-presentation	Credential service van de connector: presentaties en tokens	19 van 19	geslaagd
connector-cs-issuance	Credential service van de connector: opslag en uitgifte	35 van 35	geslaagd
connector-verifier	Verifier in de connector	22 van 22	geslaagd

Data Plane Signaling 1.0

De control plane in de connector en de data plane, elk aan beide kanten van een levering.

Suite	Wat de TCK test	Geslaagd	Resultaat
CP_P	Control plane, kant van de rechthebbende	5 van 5	geslaagd
CP_C	Control plane, kant van de dataontvanger	5 van 5	geslaagd
DP_P_PULL	Data plane, levert (pull)	5 van 5	geslaagd
DP_C_PULL	Data plane, ontvangt (pull)	6 van 6	geslaagd
DP_P_HTTP_PULL	HTTP-pull en tokenvernieuwing, levert	3 van 3	geslaagd
DP_C_HTTP_PULL	HTTP-pull en tokenvernieuwing, ontvangt	2 van 2	geslaagd

TechnischZelf de TCK's draaien

Met toegang tot de broncode draai je alle drie de TCK’s met het script compliance/run-all.sh, of één ervan met compliance/dsp/run.sh, compliance/dps/run.sh of compliance/dcp/run.sh. Je hebt Docker en Rust nodig. De scripts bouwen de programma’s, starten ze in de testomgeving en draaien dan het TCK-image. De images eindigen altijd met exitcode 0, ook als er tests falen. De scripts lezen daarom zelf de log, controleren dat de run compleet is, en schrijven een summary.md in hun map reports. Dat is de samenvatting waar de tabellen hierboven uit komen.