Re: The German Government slams JSON-LD

>  Instead it’s more like a verifiable linked data chain from credential
(eg invoice) to trust anchor (eg to UN GRID via national register
credential)

In VC terms I think this would mean a presetend Verifiable Credential (the
invoice) contains a property pointing to a Verifiable Recognition
Credential that says the issuer of the invoice is recognized to do this by
enity X and that might point to another Verifiable Recognition Credential
saying the recognizer is recognized by entity X to recognize others to do X
until it reaches the authority the verifier implicitly trusts to tell who
can do what also presented as a Verifiable Recognition Credential of them
saying this is what we recognize our selves to do, and then you verify that
with their did:web method or just ./well-know/jwks would work I guess...

But I think the Verifiable Credentials and the Verifiable Recognition
Credentials type, covers all possible use cases and everyone should adopt
them for interoperability and clarity, I think the neutral language
approach is brilliant, the standards provide the perfect tools to
orchestrate trust between any set of entities...

I think....

With the EU thing, let's take a PID credential as an example when you get
presented a VC data model PID you could once again go up the chain to reach
the EU commision official (or whoever is the legally recognized LotL
issuer/maintainer) etc.

What I'm saying is the Verifiable Credential standards with JSON-LD are the
key to interoperability and it comes automatically and naturally everywhere
if adopted.

I think...

pe 27.2.2026 klo 21.59 Steve Capell (steve.capell@gmail.com) kirjoitti:

> The UN GRID (global registrar information directory) projects aims to
> solve cross border business identity with a similar approach to EUBW except
> there’s no assumption about wallets and an explicit assumption that the
> party verifying identity (eg an importing customs authority) has no
> relationship with the party with the verifiable identity (eg the exporting
> country trader) - so there is no sense of “presentation” by holder to
> verifier.  Instead it’s more like a verifiable linked data chain from
> credential (eg invoice) to trust anchor (eg to UN GRID via national
> register credential)
>
> So far Spain and India are committed to pilot the GRID with more nations
> interested.  Hopefully we can also prove interoperability with EUBW
>
> Kind regards
>
> Steven Capell
> UN/CEFACT Vice-Chair
> Mob: +61 410 437854
>
> > On 28 Feb 2026, at 1:03 am, Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
> >
> > Since I started this thread may I add "Anders slams the EUDIW project".
> >
> > WebAuthn/FIDO is a better choice for most commercial entities.  Strong
> multi-device authentication is here and now!
> >
> > Cross-border operation is severely hampered by many factors:
> > - Services typically only speak local languages.
> > - The Relying Party certificate requirement limits scaling.  For
> payments it becomes completely unmanageable [*].
> > - Very different ideas of what an "Identity" (PID) is.
> >
> > When it comes to "correlation" the fact that every service worth
> mentioning (as well as some that are not) requires a mobile phone number
> and/or an email address which undermines most privacy efforts.
> >
> > Regards,
> > Anders
> >
> > *] The "regular" payment industry delegates the trust in Merchants to
> the "Payment Network", an infinitely much simpler idea than requiring
> governments to administer every little Merchant and in some way equipping
> them with an appropriate Merchant certificate.  Why do I care about the
> payment scenario you may wonder?  Because a failure could cast a shadow
> over the rest.  I have therefore suggested splitting Identity and Payments
> project-wise:
> >
> https://www.linkedin.com/posts/andersrundgren_there-are-many-reasons-to-why-the-eudiw-project-activity-7309263061142454272-2w6W/
> >
> >> On 2026-02-27 13:59, Lluís Alfons Ariño Martín wrote:
> >> Dear all,
> >> Article raises operational questions that deserve serious engagement,
> and its conciliatory tone is welcome. Several of its observations about the
> verification flow are correct. But the article also contains factual
> errors, conflates distinct technical concepts, and rests on a false
> dichotomy that, if left unaddressed, could mislead the ecosystem at a
> critical moment - precisely when the draft amending Implementing
> Regulations are open for public consultation.
> >> I want to address the key issues as concisely as I can, while providing
> enough technical grounding for this audience to evaluate them independently.
> >> *1. SD-JWT VC does not provide unlinkability*
> >> SD-JWT VC provides selective disclosure - the holder can choose which
> claims to reveal. But it does not provide unlinkability. When the same
> SD-JWT VC credential is presented to two different verifiers, the signature
> and key binding remain constant across presentations, making them
> correlatable. This problem is amplified in the EUDI architecture, where
> presentations may be routed through qualified validation services -
> centralised points that receive a high volume of credential presentations
> and could technically link them across relying parties. Without additional
> measures such as single-use credentials (which impose a significant
> availability burden on issuers), SD-JWT remains linkable by design.
> >> To be clear: this is not a format-specific deficiency - any credential
> format that couples the signature to the payload without zero-knowledge
> proof mechanisms faces the same issue (W3C VC signed with JAdES included).
> The difference is that BBS cryptosuites, which are native to the JSON-LD
> W3C-VC ecosystem, provide a concrete path to unlinkability: each
> presentation generates a cryptographically distinct proof that cannot be
> correlated with other presentations of the same credential, even by
> colluding verifiers. This is not a minor distinction - it is the core
> privacy property that leading European cryptographers criticised the EUDI
> Wallet for lacking in 2024.
> >> Conflating selective disclosure with unlinkability is a category error
> that obscures what is at stake in the format debate.
> >> *2. The article addresses only half the verification flow*
> >> The article correctly observes that a verifier must construct the
> Presentation Definition before seeing the credential (what I'll call Moment
> 1: request construction). It then concludes that semantics inside the
> credential are "operationally useless" because they "arrive too late."
> >> This ignores the second half of the flow - Moment 2: response
> interpretation. When a German verifier receives a credential issued in
> Spain, it needs to know what the fields /mean/, not just that they exist.
> @context provides precisely this: a machine-readable link from each
> property in the credential to its definition in a governed vocabulary.
> >> The rulebook tells the verifier what to ask for. @context tells the
> verifier what it has received. Both are necessary. The article addresses
> only the first.
> >> Cross-border interoperability is fundamentally a Moment 2 problem. A
> verifier in one Member State receiving a credential from another needs to
> determine that the fields it received correspond to the concepts it
> expected, even when different national vocabularies, languages, or
> qualification frameworks are in play.
> >> This is what @context enables - and no amount of pre-agreed schemas
> eliminates this need at the point of credential interpretation.
> >> *3. JSON Schema cannot replace @context - they operate at different
> levels*
> >> The article asserts that "all the semantics defined in JSON-LD contexts
> can be expressed just as well in JSON Schemas with descriptions." This is
> false.
> >> JSON Schema validates /structure/: this field is a string, this array
> has at least one element, this value comes from an enumerated list. It
> answers: "is this credential well-formed?"
> >> @context provides /semantic binding/: this field corresponds to this
> concept in this ontology, accessible via a resolvable URI. It answers:
> "what does this credential mean?"
> >> JSON Schema cannot express that "architect" in a Spanish credential and
> "Architekt" in a German credential refer to the same regulated profession
> under Directive 2005/36/EC. It cannot express that a competency described
> using ESCO in one Member State is equivalent to a competency described
> using a national framework in another. SHACL - the Shapes Constraint
> Language for RDF, which is explicitly supported in ETSI TS 119 472-1 clause
> 7.2.1.3 as "ShaclSchemaCredential" - can validate both structural and
> semantic constraints. JSON Schema cannot.
> >> Adding a "description" string to a JSON Schema property gives you
> human-readable documentation. Adding a URI to @context gives you
> machine-readable semantic binding to a formal ontology. These are
> categorically different capabilities.
> >> Conflating them undermines the core argument of the article.
> >> *4. The rulebook proposal reinvents @context without the
> standardisation*
> >> The article's own example includes "rulebookURI" - a field that points
> to an external document defining the semantics of the credential, plus
> "schemaURIs" pointing to external schema definitions.
> >> This is functionally identical to what @context does: linking the
> credential to its semantic definitions via URIs. The difference is that
> @context is a W3C standard with deterministic processing rules (JSON-LD
> Processing Algorithms 1.1, W3C Recommendation), a global ecosystem of
> implementations across education (Open Badges 3.0, European Learning Model,
> Europass Digital Credentials), supply chain (Catena-X), and identity (EBSI,
> DC4EU), and years of interoperability testing. "rulebookURI" is a bespoke
> field with no formal specification, no standardised processing algorithm,
> and no implementation track record.
> >> Replacing a standardised mechanism with a non-standardised one that
> does the same thing is not simplification. It is a regression from
> standardised to ad hoc.
> >> *5. The vocabulary scale problem*
> >> A question in the LinkedIn thread deserves attention here, because it
> identifies the architectural fault line: would controlled vocabularies like
> ESCO (approximately 14,000 skills, 27 languages, regular update cycles)
> need to be /copied into/ each rulebook, or /referenced by/ each rulebook?
> >> If copied into: every vocabulary update requires synchronised updates
> across every rulebook that references it. Multiply ESCO by the European
> Learning Model, the thousands of regulated professions under Directive
> 2005/36/EC, and 27 national qualification frameworks, and you have an
> unscalable maintenance explosion.
> >> If referenced by: the rulebook needs a standardised, machine-readable
> mechanism for resolving those references by URI. That mechanism is @context
> - or rather, it is exactly what @context already provides.
> >> The article's position, followed to its logical conclusion, requires
> either vocabulary duplication (unscalable) or the reinvention of @context
> within the rulebook architecture itself.
> >> *6. The false dichotomy at the heart of the article*
> >> This is the central analytical error. The article presents a binary
> choice: either JSON-LD inside the credential /or /semantics in rulebooks.
> In reality, these are not alternatives. @context /is/ the mechanism that
> links the credential to its governing vocabulary - which can perfectly well
> be a rulebook, a catalogue, or any governed semantic framework.
> >> A credential with @context pointing to a rulebook-governed vocabulary
> is not "JSON-LD complexity inside the credential." It is a single JSON
> property containing a URI that provides machine-readable linkage to the
> governing semantic framework. Processing it requires a URI lookup, not an
> RDF reasoning engine.
> >> The article attacks a strawman - heavy semantic-web processing inside
> every wallet - rather than what @context actually does: a standardised
> pointer from the credential to its vocabulary. This is precisely what the
> article's own "rulebookURI" attempts to do, but without the standardisation.
> >> *7. What the formal specifications actually say*
> >> ETSI TS 119 472-1 V1.1.1 (December 2025) - which is part of the formal
> EUDI Wallet technical framework - explicitly mandates @context for JSON-LD
> W3C-VC EAAs (requirement EAA-7.2.1.2-01) and specifies that it shall
> contain URIs referencing documents that map URLs to short-form aliases
> (EAA-7.2.1.2-03). It supports SHACL as a schema mechanism alongside JSON
> Schema (EAA-7.2.1.3-03). It references BBS cryptosuites for selective
> disclosure with embedded proofs (EAA-7.4-02, citing W3C Candidate
> Recommendation "Data Integrity BBS Cryptosuites v1.0").
> >> The ecosystem it describes - where @context is unnecessary, JSON Schema
> suffices, and BBS is dead - does not match the ecosystem that ETSI's own
> experts have specified.
> >> The formal technical framework already provides for exactly the
> capabilities the article argues against.
> >> *8. BBS is not "dead" - it is in process*
> >> The article declares "BBS+ is dead. Regulation killed it." Several
> corrections are needed. First, BBS+ is not BBS - the BBS cryptosuites
> currently under development at IETF are a different scheme with different
> security properties; the terminology matters. Second, the claim that they
> are unusable because they are "not approved by BSI or ANSI" is circular:
> they are not yet approved because the standardisation process is ongoing,
> not because they have been evaluated and rejected. The same logic would
> have disqualified ECDSA before its own approval. Third - and this is
> architecturally important - neither BSI nor ANSI have a mandate to define
> cryptographic standards at European level. That mandate belongs to the
> European Standards Organisations. BSI itself references ETSI TS 119 312 in
> its national standards. The article elevates national agency positions to a
> regulatory veto they do not hold.
> >> ETSI TS 119 312 - the European cryptographic algorithm catalogue - is
> currently under revision, and the inclusion of privacy-preserving
> cryptographic mechanisms including BBS is within scope. It should be noted
> that the direct reference to this TS was removed in the latest adaptations
> of the Implementing Acts, which creates a regulatory gap that needs to be
> addressed. But the reference chain remains indirect (through EN 319 411-2
> via EN 319 411-1), and the ongoing revision is expected to be completed in
> the near term.
> >> To be clear: it is true that the EUDI Wallet ecosystem requires
> approved cryptographic algorithms, and BBS is not yet approved. This is a
> fact, not a disputed point. But "not yet approved" is not the same as
> "dead" or "killed by regulation." It means the standardisation process has
> not concluded.
> >> The question is not whether BBS will be standardised at European level,
> but when — and whether the regulatory framework will be ready to
> accommodate it when it is.
> >> *9. The cost asymmetry the article doesn't acknowledge*
> >> The article proposes that sectors "lift" their JSON-LD vocabularies
> into rulebook-format JSON Schemas and presents this as a painless
> migration. It is not. Rewriting the European Learning Model, ESCO mappings,
> and EQF ontologies as JSON Schemas would lose semantic expressiveness
> (because JSON Schema cannot represent ontological relationships), impose a
> massive re-engineering cost on the sectors that invested earliest, and
> require those sectors to adopt a solution they already evaluated and
> rejected precisely because it could not meet their cross-border
> interoperability requirements.
> >> The education sector did not choose JSON-LD by accident or fashion. It
> chose it because JSON Schema could not express the semantic relationships
> needed for cross-border credential recognition across 27 Member States with
> different national qualification frameworks.
> >> *In summary*
> >> The article is right that verifiers need to know what to ask for before
> seeing the credential. It is right that governance, versioning, and policy
> belong in governed registries. It is right that the ecosystem needs to be
> as simple as possible.
> >> But it is wrong that SD-JWT VC provides unlinkability. Wrong that JSON
> Schema can express what @context expresses. Wrong that @context is heavy
> semantic-web processing inside wallets. Wrong that BBS has been killed by
> regulation. And wrong that the choice is between JSON-LD inside credentials
> and semantics in rulebooks - because @context is the bridge between the
> two, not an alternative to either.
> >> The EUDI Wallet ecosystem needs three things that are not in
> competition: governed semantic frameworks (rulebooks, catalogues), a
> standardised mechanism for linking credentials to those frameworks
> (@context), and privacy-preserving cryptography for presentation (e.g.
> BBS). Removing the second does not simplify the architecture. It severs the
> link between the credential and its meaning - and either leaves that link
> broken or forces its reinvention under a different name, without the
> standardisation.
> >> Lluís
> >> *From: *carsten.stoecker@spherity.com <carsten.stoecker@spherity.com>
> >> *Date: *Friday, 27 February 2026 at 12:06
> >> *To: *'Melvin Carvalho' <melvincarvalho@gmail.com>, 'Anders Rundgren' <
> anders.rundgren.net@gmail.com>
> >> *Cc: *'W3C Credentials CG' <public-credentials@w3.org>
> >> *Subject: *AW: The German Government slams JSON-LD
> >> 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
> >
> >
>
>