DIDs, CBOR, credentials, and product passports
Technical workbench for DIDs, CBOR, verifiable credentials, battery passports, and the built environment. The built-environment tab uses the Luotea Hackathon 2026 estate dataset.
Use sample data to inspect each request and result. A local development preview may use fixtures; record the serving origin and check the matching backend before treating a result as interoperability evidence.
DID resolver
Paste a DID and resolve it — the method is recognized from the DID. Resolution runs
server-side, so did:web documents are fetched without the browser's
cross-origin (CORS) restrictions do not apply to that server request. Supported methods and outbound-network restrictions still apply. did:key is computed
directly.
Supported methods (click to try an example):
CBOR inspector
Paste CBOR as hex and inspect it: the bytes and the Extended Diagnostic Notation are linked — hover either side to see which bytes encode which item. Parsing runs server-side.
VC playground
Author a W3C Verifiable Credential (VCDM 2.0), sign it, and verify it. Issuing runs
server-side: the playground signs with its own process-lifetime did:key
identity and an eddsa-jcs-2022 Data Integrity proof — JCS canonicalization
signs every property and resolves no JSON-LD context, so this canonicalisation step does not fetch an external JSON-LD context. Issuer resolution and status checking have separate network requirements. Edit the signed credential to watch tampering get caught.
What you are signing here is a W3C Verifiable Credentials Data Model 2.0 credential
secured with an eddsa-jcs-2022 Data Integrity proof over RFC 8785
canonicalization. Relevant European instruments include Regulation
(EU) 2024/1183 (eIDAS 2.0, amending Regulation (EU) No 910/2014) for wallets and their
credentials, Regulation (EU) 2024/1781 (Ecodesign for Sustainable Products) for Digital
Product Passports, and Regulation (EU) 2023/1542 (Batteries) for the first product group
with real requirements — the clusters the Battery passport tab validates against.
Wallet-facing SD-JWT VC and ISO/IEC 18013-5 mdoc issuance runs in
the sandbox; the UN Transparency Protocol passport, conformity, and
traceability credentials are issued there too.
Nothing here is a conformance claim. What is shipped, what is in development, and what is merely planned is listed with a verification pointer for each on the facts page.
Battery passport
An EU battery passport as a verifiable credential. Regulation (EU) 2023/1542 requires a digital passport for EV, LMT, and >2 kWh industrial batteries placed on the EU market from 18 February 2027, reachable through a QR carrier on the battery — and it is technology-neutral about the signed data construct. Here the regulated attribute clusters (identification, chemistry, carbon footprint, recycled content, performance) form the credential subject of a plain VCDM 2.0 credential, secured and checked exactly like any other credential in this playground. The document validates against the battery passport schema as you type — findings point into the credential with JSON Pointers.
Issue as a product passport
Issuing gives the edited passport a product identity — a
did:web under this origin — signs it, and serves the product's DID document
(with a passport service endpoint) and the signed passport at stable URLs, the way the
public DPP demos do: the QR on the product carries the DID, and resolving it leads to the
passport. On a public origin any did:web resolver reaches it; locally this server's own
resolver closes the loop.
Built environment
Every thing in a building holds its own identity, and every claim about it is signed by whoever vouches. (Machine identity for construction — the framing Regulation (EU) 2024/3110 gives product passports; topology in Brick terms.)
The marker stands where the building's passport says it stands — the globe renders the data, not the other way around.
Wires = the semantic overlay: blue hasPart,
yellow feeds, teal DID services — how
one system reads another. Who may read them: the actors below.
Who is here
Many actors, granular access: reads are role-gated views, updates arrive as new signed credentials. The grey building belongs to another owner — pick it: it refuses. Select an actor to light up what they may touch:
The flow: 1 · Identify → 2 · Observe & attest. Each step builds on the last.
1 · Identify — every thing gets its own DID
Parts are issued first, then the building's passport signs over their DIDs — it vouches for what it actually contains. Pick a node (here or in 3D) to inspect its passport.
The signed document
2 · Observe & attest — signals become signed records
The towers share real operational data (Smartti energy + KONE occupancy) through the teal wires. Data → signals → decisions — and a decision is only as good as the record it stands on, so each signal below issues as a signed record. Select a tower: