Re: [Preprint] A Verifier-Centric Conceptual Model for Digital Credential Ecosystems

Hi Shigeya, Ryosuke,

Thanks for posting this. The separation between Constitution and 
Logistics gives a vocabulary I had been missing for a problem I keep 
running into, and I would like to ask where that problem sits in your 
model.

You note that a community is not a closed group, that a verifier can 
accept the arrangements of an external community and verify credentials 
issued in it, and that "such connection among coexisting communities 
remains a topic for further development".

In European Data Spaces that situation is the norm rather than the 
exception: the same organisation participates in several ecosystems at 
once, and the same issuer may be authorised in one and not in another. A 
verifier that has accepted several communities' arrangements must, on 
receiving a credential, select which Constitution to evaluate it under 
before L3 can proceed.

Two questions:

Is that selection deliberately out of scope, or would you place it in 
the Constitution plane, as an arrangement about how a credential names 
its community?
There is a temporal counterpart. Arrangements change: issuers are added 
and removed, credential types are revised. Even once the community is 
identified, a credential issued under an earlier state has to be 
evaluated against some state of those arrangements. Does that choice 
belong to Constitution, to Logistics as dynamic information, or to the 
L3 validation policy?
Disclosure: this is the problem I work on in my PhD, so my interest is 
not a neutral one.

Best regards,
Rodrigo Menéndez
Universidad Politécnica de Madrid

El 2026-07-15 01:13, Shigeya Suzuki escribió:
> (Cross-posted to public-vc-wg, public-did-wg, and public-credentials —
> apologies for the duplicates.)
> 
> Dear all,
> 
> Ryosuke and I have posted a preprint that may be of interest to some of
> the discussions running across CCG, VCWG, and DIDWG:
> 
>   A Verifier-Centric Conceptual Model for Digital Credential Ecosystems
>   Decomposing Verification into Establishment, Acceptance, and
>   Materials Acquisition
> 
>   Shigeya Suzuki and Ryosuke Abe
> 
> https://urldefense.com/v3/__https://arxiv.org/abs/2607.10747__;!!D9dNQwwGXtA!X4rjNpBg9XTkcxx0V8I0R02lol9BbwzOczPNYnrP8smb0gaGvtWblqbUaVUJL1m8MGWcIV_4QAoajkVcbN0Q_K43$
> 
> The paper starts from a practical question: why do stacks that share a
> data model still fail to interoperate? Our position is that
> interoperability is not format compatibility — it is the condition that 
> a
> verifier can obtain the materials it needs and reach an acceptance
> decision under stated assumptions. To make that discussable, we 
> decompose
> credential processing into three layers (signature verification, 
> semantic
> interpretation, validation) and model the supply of verification 
> materials
> as two orthogonal planes (Constitution and Logistics), with a 
> formalization
> of trust running across all five functions.
> 
> The abstract follows. Comments, corrections, and disagreement are all
> very welcome — on-list or off.
> 
> Note: I will be at IETF 126 coming next week.
> 
> --- Abstract ---
> 
> Digital credential ecosystems increasingly combine multiple standards.
> Because implementations have evolved independently across jurisdictions
> and application domains, systems described under the common label 
> "digital
> credential" often remain mutually non-interoperable. Conventional
> element-by-element comparisons of identifiers, data models, credential
> formats, protocols, and signature algorithms do not explain why
> interoperability fails even when stacks share a data model, nor do they
> identify what a verifier must obtain, and what it must trust, before
> accepting a credential. We present a verifier-centric conceptual model
> built on two decompositions. The first separates credential processing
> into signature verification (L1), semantic interpretation (L2), and
> validation (L3), and models the supporting materials through two
> orthogonal planes: Constitution, which captures ecosystem-level
> arrangements and trust declarations, and Logistics, which captures how
> verification materials are stored and delivered; the Shinken framework
> makes trust assumptions explicit across all five functions. The second
> characterizes where each function may be placed along three dimensions
> (placement, timing, and disclosure). From the condition of being
> verifiable, the model derives seven consequences, distinguished as
> definitional corollaries, operational implications, and design 
> trade-offs.
> Applying the model to four learner-credential stacks and to existing
> ecosystems including authentication federations, we show that it 
> explains
> interoperability failures, verifier-side burden, offline verifiability,
> privacy implications, and terminological ambiguities that element-wise
> comparison leaves unresolved.
> 
> --- End of abstract ---
> 
> Two disclosures. This is a preprint, submitted to IEEE Access; it
> has not been peer-reviewed yet. And we are involved in the design of 
> Originator
> Profile, which appears in the cross-ecosystem comparison; this is 
> stated in
> the paper as well.
> 
> Regards,
> 
> Shigeya Suzuki, Ph.D
> Project Professor, Keio University Global Research Institute
> Char of Technology Development, Originator Profile CIP

Received on Thursday, 16 July 2026 19:07:21 UTC