Re: The German Government slams JSON-LD

maybe entities should be able to announce who they reconize as
authorities(root recognizers) as well in a type of verifiable credential🤔

pe 27.2.2026 klo 22.20 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:

> > the neutral language approach
>
> Means for example that there is no authority stated explicitly, but the
> tool provides an ability for any implementing context to decide that via
> the recognizers role, any actor could take upon, and then the verifying
> application decides who it needs to be to establish trust.
>
> pe 27.2.2026 klo 22.16 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:
>
>> >  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
>>> >
>>> >
>>>
>>>