- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 27 Feb 2026 12:33:26 +0100
- To: carsten.stoecker@spherity.com
- Cc: 'W3C Credentials CG' <public-credentials@w3.org>
Hi All, This was an example of "journalism" as it stands today. That is, somewhat alarming messages and no finesse. Anyway, putting JSON-LD in wallets seems to be a problem. Maybe the conclusions are wrong? Anders On 2026-02-27 12:04, carsten.stoecker@spherity.com wrote: > Hi all, > > The subject line “The German Government slams JSON-LD” is not supported by the sources linked in the post. > > (1) The original message in this W3C mailing list thread only links to a Medium article. It does not quote any German government statement or publication. > > (2) The Medium article is authored by an individual on Medium. It is not an official publication of the German Federal Government. > > > (3) The author of the Medium article is publicly listed as working on the EUDI Wallet topic at SPRIND. SPRIND is the Federal Agency for Breakthrough Innovation (SPRIN-D). The Federal Government is the sole shareholder. This does not mean that a personal Medium post either represents SPRIND or an official German government position. > > (4) Germany uses JSON-LD in production public-sector data infrastructure today. Evidence: > > + GovData’s metadata catalogue is available via endpoints “in RDF, Turtle and JSON-LD” > > + IT-Planungsrat/GovData documentation describes harvesting DCAT-AP.de RDF endpoints, including RDF-XML, JSON-LD, and Turtle > > + DCAT-AP.de documentation (Pflegehandbuch) references RDF/XML and JSON-LD conventions > > + Mobilithek metadata upload documentation expects metadata as JSON-LD or RDF/XML > > (5) In European data sovereignty and space trust models, JSON-LD and W3C VC concepts are in active use (especially for machine-readable, semantic statements). > > + Example: Gaia-X, Manufacturing-X and Caten-X (AND many data spaces in other European countries) credentials are described as W3C VCDM in JSON-LD > + The same data space work describes EDC catalogue exchange as DCAT (dcat:Catalog) serialized as JSON-LD and Credential Exchange in DCP protocol in JSON-LD > > (6) Eclipse Dataspace Components (EDC) a key connector implementation in this space and supported by the German Government’s R&D arm: https://github.com/eclipse-edc/Connector <https://github.com/eclipse-edc/Connector> > > There are differences between JSON-only credential formats (e.g., SD-JWT VC or ISO mdoc) and JSON-LD credentials with Data Integrity. B2B and B2G scenarios often require machine-processable semantics, policy enforcement, and provenance across many parties and systems, which can differ from typical citizen identity use cases. The community should assess these requirements case by case and choose architectures alternatives and credential profiles accordingly. > > Regards, > > Carsten > > *Von:*Melvin Carvalho <melvincarvalho@gmail.com> > *Gesendet:* Freitag, 27. Februar 2026 07:25 > *An:* Anders Rundgren <anders.rundgren.net@gmail.com> > *Cc:* W3C Credentials CG <public-credentials@w3.org> > *Betreff:* Re: The German Government slams JSON-LD > > pá 27. 2. 2026 v 7:04 odesílatel Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> napsal: > > https://mmollik.medium.com/why-the-eudi-wallet-should-stop-pretending-it-needs-json-ld-in-credentials-a37d09a26d06 <https://mmollik.medium.com/why-the-eudi-wallet-should-stop-pretending-it-needs-json-ld-in-credentials-a37d09a26d06> > > I appreciate the elegance of JSON-LD, but I recognize it can be too heavyweight for certain applications. That's why I sought a more lightweight alternative with Linked Objects. > > https://linkedobjects.org/ <https://linkedobjects.org/> > > I will be doing a new round of work on this, quite soon. > > > > Anders > > > > Spherity GmbH <https://www.spherity.com/>|Emil-Figge-Straße 80|44227 Dortmund > > LinkedIn <https://www.linkedin.com/company/spherity>|YouTube <https://www.youtube.com/@spherity2407> > > Managing Directors: Dr. Carsten Stöcker, Dr. Michael Rüther > > Registered in Dortmund HRB 31566 >
Received on Friday, 27 February 2026 11:33:32 UTC