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

Hi Kerri,

Thank you for sharing it with us. I haven't yet had the opportunity to read
the full report end-to-end, but I did spend some time reading the executive
summary, the key sections, and the accompanying Medium article. It is
clearly a substantial effort, and reading those sections alongside this
discussion helped me better understand the motivation behind the issuer
identity registry and governance framework.

One point that stood out to me is the clear distinction between
cryptographic verification and institutional trust. The report reinforces
the idea that issuer identity registries are not intended to create trust,
but to make existing governance and trust relationships digitally
verifiable in a privacy-preserving and interoperable way. That seems to
align well with where the recent discussion ultimately converged.

Even from my initial reading, I found it to be a useful contribution to the
discussion. I would encourage others on this list who are interested in
trust, governance, and verifiable credential ecosystems to give it a read
as well. Once I have had the opportunity to read the report in full, I may
reach out with a few questions or comments.

Thank you again for making these resources openly available.

Best regards,
Amir Hameed Mir

On Mon, 20 Jul 2026 at 09:17, Kerri Lemoie <kerri.lemoie@dccommons.org>
wrote:

> Hello All,
>
> I'd like to introduce some additional references to this thread. The
> Digital Credentials Consortium (now the DIgital Credentials Commons) worked
> on an issuer registry project with Credential Engine. You can learn more
> about it here:
> https://blog.dcconsortium.org/the-dcc-and-credential-engine-publish-issuer-identity-research-report-and-governance-framework-6fb4efb64d23
>
> This is the project report:
> https://digitalcredentials.mit.edu/docs/Credential-Engine-and-Digital-Credentials-Consortium_-Issuer-Identity-Registry-Research-Report.pdf
>
> This is the governance framework research:
> https://digitalcredentials.mit.edu/docs/Governance-Framework-for-Issuer-Identity-Registries.pdf
>
> Best,
>
> Kerri
>
> Kerri Lemoie, PhD
> Executive Director
> Digital Credentials Commons <https://dccommons.org/>
> She/Her
>
>
> On Mon, Jul 20, 2026 at 3:26 AM Amir Hameed <amsaalegal@gmail.com> wrote:
>
>> Dear Shigeya,
>>
>> Thank you for the detailed explanation. It makes much more sense to me
>> now, particularly why the model starts from the verifier and how the
>> regress of authority ultimately terminates at the verifier’s choice of
>> trust assumptions.
>>
>> I also think this discussion could be valuable for our work in the
>> Universal DID Native Addressing (UDNA) Community Group. While the scope is
>> different, the Constitution, Logistics, and verifier-policy decomposition
>> provides a useful conceptual vocabulary for thinking about how
>> identity-native addressing, governance, and verification materials interact
>> across independently governed ecosystems.
>>
>> Thank you again for sharing the paper and for the thoughtful discussion.
>>
>>
>> Best regards,
>>
>> Amir Hameed Mir
>> Chair, Universal DID Native Addressing (UDNA) Community Group
>>
>>
>> On Sun, 19 Jul 2026 at 12:44 PM, Shigeya Suzuki <shigeya@wide.ad.jp>
>> wrote:
>>
>>> *(Re-adding public-did-wg and public-credentials to Cc, since the
>>> questions addressed below were originally asked there and the lists dropped
>>> off mid-thread — apologies for duplicates.)*
>>>
>>> Thank you all — this thread has been a pleasure to read. Rather than
>>> replying to each message, let me respond once to the points addressed to us.
>>>
>>> First, on where the discussion has landed. I agree with the position
>>> Steve, Amir, and Rodrigo converged on: governance establishes trust;
>>> cryptography makes it verifiable and portable. This is precisely what the
>>> model tries to formalize. In the paper's terms, "this issuer is authorized"
>>> is a proposition a verifying system cannot decide from computational
>>> evidence alone; verification becomes decidable logic only when such
>>> propositions are explicitly assumed true, and the Shinken framework's job
>>> is to make each such introduction of trust visible — who assumed what, on
>>> whose declaration, at which function (Section III-D).
>>>
>>> *On Amir's question — where does the regress of authority stop, and is
>>> its establishment beneath Constitution or part of it?*
>>>
>>> > If that authority itself comes from another governance framework,
>>> registry, consortium, legal framework, or institutional process, then it
>>> seems that the question of authority has only moved one level higher
>>>
>>> Yes — and the model's claim is that this regress does not continue
>>> upward indefinitely; it terminates at the verifier. Which authority's
>>> declaration to accept as the origin of the verification logic is the
>>> selection of assumptions, and it is the one function the model treats as
>>> non-delegable (III-D). Every chain of recognition, however many levels it
>>> has, starts from a trust anchor some verifier decided to build into its own
>>> logic. There is no global root that closes the regress for everyone; there
>>> are only verifiers closing it for themselves, each under its own policy.
>>> That — rather than any preference of implementation viewpoint — is why the
>>> model starts from the verifier: the party where the regress terminates is
>>> the only place from which the whole structure can be described without
>>> presupposing an outside authority. I believe this also answers your
>>> original question about the choice of starting point.
>>>
>>> On placement: establishing authority relations within one ecosystem is
>>> what the Constitution plane covers — the plane is named for constitution **and
>>> establishment**, not only for the resulting artifacts (III-C). The "one
>>> level higher" structure you describe is, in the model, the recursion of
>>> communities: a community's members may themselves be communities, and an
>>> upper community's constituent elements can be inherited or referenced by a
>>> lower one. This is not an afterthought — the community model this paper
>>> builds on (the Trusted Web White Paper, outlined in Appendix A) is
>>> recursive from the outset, and the conclusion sketches how the recursion
>>> appears in both planes. What the recursion does not change is where
>>> acceptance terminates: however deep the nesting, the verifier still fixes
>>> the anchor its reasoning starts from. Connecting **peer** communities'
>>> arrangements to one another — the horizontal case Rodrigo works in — is the
>>> part flagged as further development.
>>>
>>> *On Rodrigo's first question — selecting which Constitution to evaluate
>>> under.*
>>>
>>> > A verifier that has accepted several communities' arrangements must,
>>> on receiving a credential, select which Constitution to evaluate it under
>>> before L3 can proceed.
>>>
>>> Agreed, and the model splits this into two parts that land in different
>>> places. How a credential **names** its community — the identifiers,
>>> namespaces, and type conventions that let a verifier recognize "this claims
>>> to be issued under arrangement X" — is Constitution-plane content: an
>>> arrangement the community fixes and shares. Which Constitution the verifier
>>> actually **evaluates under** is not: it is origin selection with
>>> multiple roots (III-H). The verifier has accepted several communities'
>>> arrangements, each supplying its own trust anchor, and binding a received
>>> credential to one of those accepted Constitutions is fixed on the
>>> verifier's side, under its validation policy. The two should not be
>>> conflated: a credential claiming to be issued under X and a verifier
>>> evaluating it under X are different events, and the latter can refuse the
>>> former. So: not out of scope, but decomposed — the naming sits in the
>>> Constitution plane; the selection sits with the verifier.
>>>
>>> *On Rodrigo's second question — evaluating against which state of the
>>> arrangements.*
>>>
>>> > 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?
>>>
>>> The honest answer is that the question decomposes rather than landing in
>>> one box — and the decomposition is, I think, the useful part. What the
>>> community's time semantics **are** — whether membership is evaluated at
>>> issuance time or presentation time, how long a removed issuer's past
>>> credentials remain acceptable — is itself an arrangement: Constitution
>>> content. How a verifier **obtains** the arrangement state for a given
>>> point in time — versioned lists, archived declarations, status information
>>> — is Logistics; its fifth element covers exactly the time-varying material.
>>> And which state the verifier **requires** for acceptance — "the issuer
>>> must be in the set now" versus "must have been in the set at issuance" — is
>>> the L3 validation policy, and may legitimately differ between two verifiers
>>> looking at the same credential. In Shinken terms, assumptions placed in A
>>> should be recorded with their point in time (III-D) precisely so that the
>>> temporal scope of what was assumed stays explicit. Two data spaces choosing
>>> different answers here would, in the model's reading, be differing in
>>> policy, not disagreeing about facts.
>>>
>>> *On Carolynn's question — is a community more or less a silo?*
>>>
>>> Since this goes to the model's base concept, a direct answer. If
>>> "community" meant a closed group whose arrangements only insiders can use,
>>> it would indeed be a silo with better terminology. The model defines it the
>>> other way around: a community is constituted by shared arrangements, and a
>>> verifier that is not a member can accept those arrangements, including the
>>> origin of trust, and verify credentials issued there (III-A). The
>>> open-world assumption governs where claims can travel and who can state
>>> them; acceptance is never open-world — some verifier, under some accepted
>>> arrangements, decides. Roughly: the open world is where credentials travel;
>>> a community is where they are accepted. And multi-membership is the normal
>>> form, not an anomaly: III-H multiplexes the Constitution/Logistics pair per
>>> credential exactly because the same organization routinely stands in
>>> several arrangements at once. Rodrigo's members' bar is, incidentally, a
>>> textbook instance of III-H's basic form: the state ID is verified under one
>>> community's arrangements, the membership under another's, and the two
>>> chains merge at the bar's validation. Two authorities answering two
>>> different questions is precisely the multi-root picture.
>>>
>>> *On Manu's pointer to vc-recognized-entities.*
>>>
>>> In this model's vocabulary, that specification sits on the declaration
>>> side of the Constitution plane — a recognizing party stating, in verifiable
>>> form, which entities it recognizes for which actions — while declaration
>>> and acceptance remain independent: whether a verifier takes a recognition
>>> into its own verification logic is set by its policy, which matches the
>>> separation the model draws in III-F. I expect the model's decompositions
>>> could be useful to that discussion as it develops.
>>>
>>> Thanks again — this is exactly the discussion we hoped the preprint
>>> would start.
>>>
>>> Regards,
>>>
>>> Shigeya Suzuki, Ph.D
>>> Project Professor, Keio University Global Research Institute
>>> Chair of Technology Development, Originator Profile CIP
>>>
>>> On Fri, Jul 17, 2026, at 17:57, Amir Hameed wrote:
>>>
>>> +1 Rodrigo
>>>
>>> It’s a good distinction.
>>>
>>> To me, it also highlights that different governance domains answer
>>> different questions. A national register, regulator, or accreditation body
>>> establishes facts such as legal identity or institutional authority. A data
>>> space (or another ecosystem) establishes a different kind of assertion, for
>>> example whether that entity is authorized to participate within that
>>> particular ecosystem or under its governance rules.
>>>
>>> The resulting Verifiable Credentials may therefore contain attributes
>>> asserted by different authorities operating under different governance
>>> frameworks. Verification then depends not only on the cryptographic
>>> validity of those assertions, but also on the verifier understanding which
>>> authority is authoritative for which class of claims under its own trust
>>> policy.
>>>
>>>
>>> Best regards,
>>>
>>> Amir Hameed Mir
>>>
>>> On Fri, 17 Jul 2026 at 9:13 PM, rodrigo.menendez <
>>> rodrigo.menendez@upm.es> wrote:
>>>
>>> Hi all,
>>>
>>> I agree with where this has landed: governance establishes trust, and
>>> cryptography makes it verifiable and portable rather than creating it.
>>> Whether an entity is genuine is answered by a global authority, a
>>> register or an accreditation body, and I would not argue otherwise. What
>>> I would add is a second layer: whether that entity is a participant of a
>>> particular data space is not answered there, but by the data space
>>> itself. It is like a members' bar: they let you in on a membership they
>>> grant on their own authority, but to serve you alcohol they still check
>>> a state-issued ID. Two authorities answering two different questions,
>>> and neither replaces the other.
>>>
>>> Best regards,
>>> Rodrigo Menéndez
>>> Universidad Politécnica de Madrid
>>>
>>> El 2026-07-17 17:16, Amir Hameed escribió:
>>> > +1 Steve
>>> >
>>> > I agree with this.
>>> >
>>> > I think it is an important distinction that trust is not created by
>>> > cryptography. Rather, it emerges from governance, whether
>>> > institutional, legal, social, industry-led, or collectively governed
>>> > within a particular ecosystem. Cryptography can make those trust
>>> > relationships verifiable and portable, but it cannot establish them by
>>> > itself.
>>> >
>>> > I found this perspective helpful in clarifying the boundary between
>>> > governance and verification.
>>> >
>>> > Best regards,
>>> >
>>> > Amir Hameed Mir
>>> >
>>> > On Fri, 17 Jul 2026 at 7:57 PM, Steve Capell <steve@pyx.io> wrote:
>>> >
>>> >> Hmm - sounds like a bit of techno-fantasy going on here
>>> >>
>>> >> - who says that a business is really who they say they are? It’s
>>> >> the national business register, not some data space that the
>>> >> business might have joined
>>> >> - who says that a school that issues education credentials is a
>>> >> genuine school? It’s the department of education, not some data
>>> >> space the school might have joined
>>> >> - who says that beekeeper is a genuine Manuka honey producer? It’s
>>> >> the Manuka honey association, not some data space the beekeeper
>>> >> might have joined
>>> >>
>>> >> The key point here is that authorities of trusted assertions about
>>> >> who can say what have existed already for decades or centuries.
>>> >> Technologies such as recognised entity verifiable credentials that
>>> >> Manu highlighted are a great way to make existing trust systems
>>> >> digitally verifiable. They don’t magically create trust through
>>> >> cryptography where it didn’t exist before.
>>> >>
>>> >> For example https://grid.unece.org/ [1]
>>> >>
>>> >> Kind regards
>>> >>
>>> >> Steve Capell
>>> >> Mob/whatsapp: +61 410 437854
>>> >>> 
>>> >>>
>>> >>>>> On 17 Jul 2026, at 10:26 pm, rodrigo.menendez
>>> >> <rodrigo.menendez@upm.es> wrote:
>>> >>>>>
>>> >>>> Hi Carolynn, Shigeya and Ryosuke
>>> >>>>
>>> >>>> I would put it the other way round. Precisely because anyone can
>>> >> assert anything, a verifier cannot infer from a credential whether
>>> >> its issuer was authorised to issue it. That has to be stated by
>>> >> someone. And in every data space I have looked at, it already is:
>>> >> the ecosystem publishes its list of authorised issuers, and each
>>> >> verifier loads it as configuration. So the silo is not something
>>> >> anyone is proposing to add. It is already deployed.
>>> >>>>
>>> >>>> On your second point you are right that the phenomenon is not
>>> >> specific to data spaces, though DPPs are not a domain I know well
>>> >> enough to judge. Data spaces are the scope we work in, and they
>>> >> combine the conditions the problem needs: overlapping ecosystems,
>>> >> formal governance, and routine issuer rotation. I would be curious
>>> >> whether those hold in the domains you mention.
>>> >>>>
>>> >>>> Best regards,
>>> >>>> Rodrigo Menéndez
>>> >>>> Universidad Politécnica de Madrid
>>> >>>>
>>> >>>> El 2026-07-17 09:20, BERNIER Carolynn escribió:
>>> >>>>> Dear Rodrigo, Shigeya and Ryosuke,
>>> >>>>> There is something I don't understand in this conversation. I
>>> >> thought
>>> >>>>> we were working in an open-world assumption. And therefore the
>>> >> idea of
>>> >>>>> a "community" is more or less equivalent to "silo".
>>> >>>>> Data spaces is not the only place where an organisation can
>>> >>>>> participate in multiple "communities".  This is true for DPPs
>>> >> and
>>> >>>>> identity credentials (natural persons and organisations).
>>> >>>>> But perhaps I misunderstand ?
>>> >>>>> Best regards,
>>> >>>>> Carolynn
>>> >>>>> -----Original Message-----
>>> >>>>> From: rodrigo.menendez <rodrigo.menendez@upm.es>
>>> >>>>> Sent: Thursday, July 16, 2026 5:56 PM
>>> >>>>> To: Shigeya Suzuki <shigeya@wide.ad.jp>
>>> >>>>> Cc: public-vc-wg@w3.org; public-did-wg@w3.org;
>>> >>>>> public-credentials@w3.org; ryosuke@jaist.ac.jp
>>> >>>>> Subject: 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__;!!D9dNQ
>>> >>>>>>
>>> >>
>>> > wwGXtA!X4rjNpBg9XTkcxx0V8I0R02lol9BbwzOczPNYnrP8smb0gaGvtWblqbUaVUJL1m
>>> >>>>>> 8MGWcIV_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
>>> >>>>
>>> >
>>> >
>>> > Links:
>>> > ------
>>> > [1]
>>> >
>>> https://urldefense.com/v3/__https://grid.unece.org/__;!!D9dNQwwGXtA!R2xR_7alHEtAfwgSmWm016iYKaUMcR5ENNhfXyfTN97Om-s3hOTR330T4HMPetckiimOX0F_wkMVXE0u_Va9XuFo$
>>>
>>>
>>>
> PLEASE NOTE: The information contained in this email may be legally
> privileged and confidential, and is intended only for the use of the
> individual(s) or entity named above. If you have received this
> communication in error, please immediately notify us by reply email and
> delete the original message. If you are not the intended recipient of this
> message, please be aware that any unauthorized access, disclosure, copying,
> distribution, or use of any parts of the contents of this message or any of
> the information contained herein is strictly prohibited by federal law.
>