SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
1
A Verifier-Centric Conceptual Model for Digital Credential Ecosystems Decomposing Verification into Establishment, Acceptance, and Materials Acquisition
arXiv:2607.10747v1 [cs.CR] 12 Jul 2026
Shigeya Suzuki, Member, IEEE, and Ryosuke Abe
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 elementby-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 verifiercentric 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. Index Terms—Conceptual model, decentralized identity, digital credential, interoperability, trust assumptions, trust establishment, verifiable credential, verifier-side reasoning.
I. I NTRODUCTION
T
HIS paper treats the activity spanning the issuance and verification of digital credentials as a single ecosystem and presents a conceptual model of it. The discussion assumes the Issuer–Holder–Verifier (IHV) model; the activities of these three parties, together with the shared arrangements that support them, combine to form one ecosystem. This ecosystem is not closed under a single standard or a single operating authority. In practice, multiple technical stacks that do not interoperate coexist under the common label “digital credential.” Juxtaposing technical elements such as identifier schemes, data models, and signature algorithms S. Suzuki is with the Global Research Institute, Keio University, Tokyo, Japan (e-mail: [email protected]). R. Abe is with the Japan Advanced Institute of Science and Technology, Ishikawa, Japan (e-mail: [email protected]). Preprint. To be submitted to IEEE Access; not yet peer-reviewed. This preprint is typeset with IEEEtran; the version submitted to IEEE Access uses the IEEE Access class.
offers no handle for answering why interoperability does not hold, or what must be present for a verifier to verify. The position of this paper is that interoperability is not a matter of format compatibility: it is the condition that a verifier can obtain the necessary verification materials and reach an acceptance decision under explicitly stated assumptions. Such questions can be discussed only after introducing a model of the ecosystem’s structure: what is shared where, how it reaches the verifier, and how the verifier’s role is divided. We therefore replace the juxtaposition of technical elements with a conceptual model that decomposes the activities constituting the ecosystem into functional layers and planes and captures how their combination enables verification. The model prescribes no particular standard; its purpose is to provide a common frame for interpreting and comparing existing standards and systems across stacks, and for evaluating designs. The paper is organized as follows. We first present, as observations, phenomena that the existing comparison axes fail to capture, and distill them into a problem statement. After reviewing related work, the conceptual-model section presents a model responding to those points: three layers and two planes, the Shinken framework that makes the introduction of trust explicit, and three dimensions of role decomposition. The application-and-evaluation section applies it to existing stacks in the learner-credential domain and to related ecosystems, confirming its interpretive power. We conclude with a summary. The appendix gives an overview of Trusted Web and the Shinken model, sources of this model that are available only in Japanese. A. Observations: Four Viewpoints The use of digital credentials advances through combinations of multiple standards and specifications, including W3C VCDM [1], ISO/IEC 18013-5 (mdoc) [2], SD-JWT VC [3], OpenID for Verifiable Credentials [4], [5], eIDAS 2.0 [6], and Open Badges 3.0 [7]. Standards grounded in the issue–hold– verify IHV model coexist with those built on the pre-existing X.509 PKI and on federated identity infrastructures, and with platform-proprietary schemes. Because design and implementation have proceeded independently in each domain, systems described under the common label “digital credential” are implemented as multiple stacks that do not interoperate. The phenomenon is especially pronounced in the learner-credential domain, where at least
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
four kinds of stacks (the 1EdTech family, the unprofiled use of W3C DID/VC [1], [8], the European EDC/ELM/EUDI-Wallet, and platform-proprietary ones) and more than six silos formed by their combinations can be observed [9]. Examining these silos, we identify four viewpoints. 1) Viewpoint 1: The existing comparison axes and their limits: In discussing differences among standards, it is conventional to compare technical elements such as identifier schemes, transport protocols, data models, credential formats, and signature algorithms. Such a comparison table is useful as an overview of standards and implementations. This comparison axis, however, has the following limitations: • It does not explain why stacks fail to interoperate even when they adopt the same data model. • It offers no comparable terms in which to organize the different mechanisms by which stacks confirm issuer legitimacy. • It does not answer, across stacks, what must be present for a verifier to receive and verify a credential, or by what mechanism it comes to be present. 2) Viewpoint 2: A tendency for the discussion to center on the issuer: Existing discussion tends to concentrate on issuer-side design (which standard to issue with, which data model to choose, under which governance to operate), leaving verifier-side design (on what premises the verifying system runs, what it trusts, what must be present for verification to hold) comparatively underexamined. This bias is coupled with a terminological confusion in which terms such as registry, trust framework, trust list, and issuer metadata are used across stacks while pointing at different objects. Because discussion proceeds without agreement on what the terms denote, consensus is hard to accumulate. 3) Viewpoint 3: The missing discussion of the storage and supply of issuer information: As a third viewpoint, stacks differ greatly in how far they specify the mechanism by which the information needed for credential verification is actually stored and reaches the verifying system. In the European EDC/ELM [10]/EUDI-Wallet [11] stack, the storage and supply paths of issuer information are specified at the protocol level, so that the information needed at verification time is systematically assembled. Other stacks lack specification from this viewpoint and leave the matter to implementation or to implicit premises. A frame that treats this viewpoint as an object of discussion has been lacking. 4) Viewpoint 4: The missing discussion of the division of the verifier’s role: As a fourth viewpoint, who divides—and when and where—the work the verifier must perform to reach trust establishment is not discussed explicitly. Even for the same work of tracing a trust chain, the verifier-side burden, privacy, and network cost differ greatly depending on whether the verifier performs it itself, delegates it to an external resolver, has the issuer bundle the trust chain into the credential in advance, or has a pre-aggregator aggregate and distribute the whole. Judgments such as “Federation is too heavy” or “aggregated distribution is centralized” rest on this division of roles; yet because no frame treats the division of roles as an independent
2
object of discussion, the grounds for such judgments remain unorganized. B. The Problem This Paper Addresses The phenomena captured by the four viewpoints above are what juxtaposed comparison of technical elements has overlooked. This paper discusses these points along the following four axes, which become the pillars of the analysis the model performs from the conceptual-model section onward: • how the set of issuers is structured and what is shared as a community; • how the content shared in the community, and the credential itself, reach the verifying system; • from the verifier’s viewpoint, what is built into the verification logic and what is fetched at runtime; and • who divides the verifier’s role, and when and where. In what follows, this paper presents a conceptual model for organizing these points. As a starting point, we rely on the abstract model of a community that uses digital signatures, presented in the Trusted Web White Paper ver.3.0 [12], and on our own research results that develop this notion [13], [14]. C. Contributions The contributions of this paper are as follows: • A functional decomposition of credential verification into three layers that carry the establishment and acceptance of verification—Signature Verification (L1), Semantic Interpretation (L2), and Validation (L3)—and two orthogonal planes that carry the acquisition of verification materials—Constitution and Logistics. The Shinken framework, a formalization of trust, is then applied across these five functions, making the introduction of trust explicit (the conceptual-model section). • A decomposition of roles along three dimensions (placement, timing, disclosure). It makes the verifier’s role an explicit object of analysis and yields seven consequences drawn from the condition of being verifiable (Sections III-E, III-G). • A cross-sectional application to four learner-credential stacks and to existing ecosystems including authentication systems. We show that the model resolves wellknown terminological confusions (the application-andevaluation section). II. R ELATED W ORK The IHV model mentioned at the outset specifies credential formats, identifier abstractions, and issuance/presentation protocols, but largely leaves both the constitution of the community and the supply of verification materials to implementations. The European EDC/ELM [10]/EUDI-Wallet [11] stack is a rare example in which the storage and supply paths of issuer information are specified at the protocol level. The governance aspect is addressed by the Trust over IP dual-stack model [15], [16] and the Open Identity Exchange (OIX) trust-framework methodology [17]; both are normative, methodological frameworks prescribing how an ecosystem
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
should be built and governed. SIDI Hub (Sustainable and Interoperable Digital Identity Hub) [18], a community activity involving standards bodies and governments, addresses crossborder interoperability of digital identity through use-case identification, minimum interoperability requirements, and the mapping of trust frameworks across jurisdictions; it frames the problem as connecting arrangements among communities, not as the decomposition of verification or the supply structure of verification materials. To our knowledge, no existing framework treats either the storage-and-supply plane or the division of the verifier’s role as an independent object of analysis. The OpenID4VC High Assurance Interoperability Profile (HAIP) [19] secures interoperability at the level of a profile: combining OID4VCI, OID4VP, SD-JWT VC, and mdoc, it fixes each specification’s optionalities to define interoperability requirements among issuers, wallets, and verifiers. The standardization practice that individual specifications alone do not suffice for cross-stack interoperability, and that a profile fixing the choices is required, is consistent with the background of Viewpoint 1. HAIP itself, however, explicitly places trust management, such as the authorization of issuers, outside its scope—including the methods for establishing trust and obtaining root certificates; that is, it does not define what this paper calls the Constitution as a whole—and provides no analytical frame for the acquisition structure of verification materials or the division of the verifier’s role. For the publication and discovery of trust schemes, the lineage of LIGHTest [20] and its successor TRAIN [21] uses DNS as the delivery path, and its application to crossdomain decentralized-identity infrastructures continues in recent work [22]. Krul et al.’s SoK [23] systematizes the requirements and assumptions of trust in SSI. As specifications that prescribe trust declarations themselves as a data model, DIF’s Trust Establishment [24] and, building on it, Credential Trust Establishment (CTE) [25] address the authorization of issuers: CTE describes participants’ roles and authority as a governance document that an authority signs and publishes, supplying materials for judging whether an issuer may be trusted. Trust Establishment defines only the data model of trust documents, leaving their integrity protection, format, publication, and discovery to profiles; CTE likewise leaves the specifics of signing and publishing the declarations to separately defined profiles. These efforts share subject matter with the Constitution and Logistics planes in that they treat trust schemes, trust declarations, and their delivery paths; their concern, however, lies in describing, publishing, discovering, and systematizing them, not in connecting them to verifier-side processing. The model presented here builds on our own results. The Trusted Web White Paper ver.3.0 [12] presents a model of an ecosystem that uses digital-signature technology—how signed data can be handled within a community. The Claim Validation model [13] separates verification (confirmation of integrity and data origin, independent of subject and context) from validation (acceptance against the verifier’s criteria, dependent on the verifier’s intent). The Shinken model [14] is an abstract model for implementing validation as an information system; it formalizes trust as assuming some propositions true within a
3
logic of verification that can contain propositions not decidable from computational evidence alone. Making this introduction of trust explicit yields determinism and transparency, and localizes which assumption to revise when one breaks. This paper adopts these as the core of the model’s design, refining the Claim Validation model’s verification into L1 and L2 and extending the Shinken model’s formalization of trust into the Shinken framework that runs across all three layers and two planes. An overview of Trusted Web and the Shinken model, which are available only in Japanese, is given in Appendix A. A. Difference from Existing Work The novelty of this paper lies not in proposing a new governance framework but in an analytical model that connects verifier-side reasoning (L1–L3) with the acquisition of verification materials (Constitution and Logistics), and further treats the freedom of placement of roles (the three dimensions) and the introduction of trust (the Shinken framework) in a single vocabulary. The model does not replace these existing efforts; it connects the scopes they address to verifier-side reasoning and to the structure of acquisition. Table I maps the scope of the existing efforts discussed in this section onto the components of this model. Each effort addresses a subset of these; to our knowledge, no existing framework treats them jointly as a single object of analysis. Here, “No” does not mean that the work is silent on governance or trust frameworks, but that it does not treat them as an object of analysis connected to verifier-side reasoning (L1–L3) and role placement in the sense of this paper. III. T HE C ONCEPTUAL M ODEL A. Overview of the Model This section develops a conceptual model of the digital credential ecosystem, starting from existing discussions of digital credential models. The distinctions introduced here are not meant to replace the terminology of individual specifications; they are analytical distinctions for comparing different stacks from the same standpoint. 1) Base concept: credentials and signed data: A credential in this model is data in which an issuer states, under its signature, a claim about some subject, represented as cryptographically signed data. We call this signed data and describe it with the following vocabulary. Payload: the body of data over which the signature is computed. It holds the content (the claim) that the credential asserts. Key: the key used to produce and verify a signature. In public-key cryptography, a signing key (the private key) and a verification key (the public key) form a pair. Hereafter “key” denotes this pair; this paper deals chiefly with the verification key. Signed data usually carries either the verification key itself or a clue for discovering it. Signer: the party that controls the signing key and applies a signature to the payload. Controller of the signing key: the party that keeps the signing key—the secret part of the pair—under its control. Usually identical to the signer.
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
4
TABLE I S COPE OF RELATED WORK MAPPED ONTO THE COMPONENTS OF THIS MODEL (Y ES : TREATED AS AN OBJECT OF ANALYSIS ; PARTIAL : PARTIALLY; N O : NOT, IN THE SENSE OF THIS PAPER ) Work ToIP dual-stack OIX trust-framework methodology SIDI Hub
Constitution plane Yes (normative) Yes (normative)
Logistics plane
Role placement
Trust formalization
No No
Connection to L3 Validation No No
No No
No No
No
No
No
No
Yes (publication, discovery, delivery) No
No
No
No
No
No
No
Krul et al.’s SoK
Partial (intercommunity connection) Partial (content of trust schemes) Partial (trustdeclaration data model) Partial
No
No
No
This paper
Yes
Yes
Yes
Yes
Partial (requirements and assumptions) Yes
LIGHTest/TRAIN DIF TE/CTE
Signature: the cryptographic evidence the signer applies to the payload with the signing key. With the verification key one can confirm that the payload has not been tampered with and that the controller of the signing key signed it. A signature establishes only two facts: that the controller of the signing key signed the payload, and that the payload is identical to what was signed. The intent behind the signature, and whether the claim may be accepted, are not settled by the signature itself; the model assigns these to two further layers, semantic interpretation and validation. 2) Base concept: community: At the base of the model lies the notion of a community: a group that shares common arrangements concerning digital credentials, with various parties involved as stakeholders. The arrangements cover which data models and protocols to use, whom to recognize as issuers, and what to take as the origin of trust; sharing the technical stack is a particularly important part. The “coexistence of multiple non-interoperable technical stacks” observed in the introduction is, seen this way, precisely the coexistence of multiple communities, each sharing different arrangements. A community holds together because issuer, holder, and verifier share its arrangements: the issuer issues credentials, the holder carries them, and the verifier verifies by relying on those arrangements, in particular the origin of trust. All three are members, with differing modes of involvement. Membership here requires neither legal personality nor a formal membership system. Whom to recognize as an issuer is prescribed by the arrangements, and that collection forms the issuer set; although community and issuer set may look identical from some viewpoints, this model treats the issuer set as one constituent element among the arrangements—the policy, identifiers and namespace, the issuer set, the origin of trust, and other metadata. How these arrangements are constituted, and how a community comes to be established, are discussed in Section III-C1 (the Constitution plane); the overall picture of the ecosystem is shown in Fig. 1. A community is not a closed group: a verifier need not handle only the credentials of the community to which it belongs. By accepting the arrangements of an external community, including its origin of trust, the verifier can verify and accept a
Digital Credential Ecosystem Community Shared Information Origin of Origin of
Trustof Trust Origin Trust
Issuer Issuer Issuer
Arrangements Arrangements
Arrangements
Holder
Verifier
Set of Issuers Credential
Fig. 1. Overview of the digital credential ecosystem
credential issued in that community. The community boundary can thus be crossed depending on which community’s arrangements the verifier accepts; such connection among coexisting communities remains a topic for further development. 3) Contour of the model: decomposition of function and decomposition of placement: The model organizes the four axes set out in the problem statement into two groups of functions. The first group is the establishment and acceptance of verification: by what logic a single credential comes to be verified and accepted. It comprises three layers—from the bottom, signature verification (L1), semantic interpretation (L2), and validation (L3)—where an upper layer holds only once the lower one holds. This dependence is logical: it does not require that the processing be executed in this order at runtime, nor that the layers be placed in the same location. This section discusses a single credential; Section III-H generalizes to combinations of multiple credentials. The second group is the acquisition of the materials that support verification: from where and how the materials needed for the establishment and acceptance of verification are assembled. It comprises two planes: a Logistics plane, handling the delivery path of verification materials, and a Constitution
L3: Validation L2: Semantic Interpretation
Constitution
Establishment and Acceptance of Verification Gives the framework of Semantics
Formalization of Trust (Shinken)
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
L1: Signature Verification
Delivery of Materials
Logistics
Fig. 2. The model of three layers and two planes
plane, providing, as part of those materials, the arrangements a community shares. The two planes are orthogonal, standing to the three layers in the relation of carrying materials (Logistics) and giving the frame of meaning (Constitution). From the supply side the same flow is the supply of verification materials; we use the verifier-side word acquisition to align with origin selection (Section III-D). Fig. 2 shows the configuration of the five functions. Table II summarizes what each function handles and its key property. TABLE II S UMMARY OF THE FIVE FUNCTIONS . T HE S HINKEN FRAMEWORK APPLIES TO ALL FIVE FUNCTIONS . Function What it handles Key property L1 Signature Veri- Confirmation of integrity Independent of the verification and data origin fier and of context L2 Semantic Inter- Interpretation of claims Depends on the shared pretation per the vocabulary or vocabulary schema L3 Validation Acceptance decision Depends on the verifier’s against the validation purpose and context policy Constitution The community’s arrange- Gives the layers their inments and its composition terpretive frame and establishment Logistics Paths by which verifica- Carries materials to the tion materials reach the layers verifier (five elements)
All five functions are interpreted end to end through the formalization of trust, which makes explicit which function, or which verification material, has trust introduced into it. The method is due to our prior work “Shinken” [14], which organizes as the introduction of trust the moment of assumingtrue a proposition that is not decidable by the verifying system from available computational evidence alone; in this model it belongs to no single function but provides a viewpoint cutting across all of them. Shinken is detailed in Section III-D after the functions are described; Appendix A outlines the original argument. The three model elements that carry the establishment of verification are called “layers,” and the two that carry the acquisition of verification materials are called “planes,” referred to by individual names (signature verification, semantic interpretation, and so on) as needed. The layers point at phases of the act of verification and stack: an upper layer holds only
5
once the lower one holds. The planes point at the structure of a community’s constitution and of information flow; without stacking order, they cut across all three layers, supplying verification materials. Distinguishing the words layer and plane makes this heterogeneity explicit in the terminology itself. For the plane that expresses a community’s constitution, the model uses the word Constitution; the reason for this choice is discussed in Section III-C1. The model is thus built on two decompositions. The first, the decomposition of function described above, divides the activity surrounding verification into five functions. The second, the decomposition of placement, treats the work these functions carry—excluding the non-delegable selection of assumptions (III-D)—as a freedom of placement along three dimensions (where the function is executed, when the inference is raised, and how far it may be disclosed) (III-E). In what follows, III-B and III-C present the five functions, III-D the formalization of trust acting on all of them, and III-E the decomposition of placement; III-F then synthesizes the two decompositions, and III-G draws the consequences of being verifiable. B. Establishment and Acceptance of Verification (L1–L3) 1) L1 Signature Verification: Signed data consists of three elements: the verification key (or a reference to it), the payload, and the signature. By verifying the signature with the verification key, the recipient confirms two things: that the payload has not been tampered with after signing (integrity), and that the party controlling the signing key bound to the verification key applied the signature (confirmation of data origin). Strictly, the cryptographic computation itself returns no more than “this signature is valid for this payload under this verification key”; the latter confirmation—attribution to the controller of the signing key—holds by depending on verification materials showing the binding between the verification key and its controller, and on the assumption taking that binding to be true (Section III-D). This confirmation is deterministic: given the same signed data and the same verification key, the result is the same whoever verifies, independent of the verifier’s intent or context. If the result changes when different verification keys or binding information are obtained, that is not because the cryptographic computation depends on context but because the inputs differ. Schemes using selective disclosure or zero-knowledge proofs are also positioned in the same framework, with L1 returning a verification result according to the proof scheme in question. Signature verification itself is a cryptographic operation completing in the verifying system’s local computation, provided the full set of signed data from the trust anchor to the target credential, with each signature’s verification key, is present. From where that set is acquired is a separate matter, generally handled as an external dependency under the acquisition of verification materials (Section III-C); where the computation runs is a matter of placement, discussed under the decomposition of roles (Section III-E). What can be delegated is the materials of verification and their processing; what cannot is the determination of the criteria of what to
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
accept—the validation policy and the selection of assumptions (Section III-D). Once the criteria are fixed, the execution of validation (L3) may itself be entrusted to another; but if another party fixes those criteria in its place, the verifying party in question can no longer be said to accept. The party in the IHV model is a composite of three roles: signature verifier, interpreter, and validator. In this paper “verifier” denotes that composite party; the role that bears L1 alone is named the signature verifier, avoiding confusion between the party and the role, and we write the verifying party where the contrast with the individual roles needs emphasis. The signature verifier confirms integrity and data origin over signed data and—to repeat—does not enter into what the payload means or whether it may be accepted. Table III maps the three roles to the terminology of the models this paper builds on. TABLE III C ORRESPONDENCE OF THE VERIFIER ’ S THREE ROLES TO THE TERMINOLOGY OF THE REFERENCED MODELS ( EACH REFERENCED MODEL TREATS THE VERIFIER AS A SINGLE ROLE ) This paper
Layer carried
Claim Validation Shinken model model signature verifier L1 Signature Verification Validator Verifier interpreter L2 Semantic Interpretation (same) (same) validator L3 Validation (same) (same)
2) L2 Semantic Interpretation: Success at signature verification (L1) confirms only that “the controller of this signing key signed this payload”; what the payload asserts is not yet settled. Signature verification guarantees the origin of a byte sequence but does not give it meaning. Semantic interpretation is the activity of interpreting what a claim asserts, according to the vocabulary and schema on which the payload relies. For a learner credential, for instance, one reads off, against the payload’s vocabulary definitions, which institution awarded which degree or title to which learner, and by which criteria. The flexibility of semantic expression depends on the descriptive power of the vocabulary used. An extensible framework such as JSON-LD lets a claim’s meaning be described flexibly, referring to external vocabularies and fitting existing credentials; the learner domain has vocabularies that describe credential meaning in detail, such as CTDL (Credential Transparency Description Language) [26], built on JSON-LD. Used appropriately, such vocabularies can improve interoperability. The higher the descriptive power, however, the heavier the burden of interpretation: the greater the cost of discovering and fetching the external vocabularies interpretation requires, expanding schemas, and confirming semantic consistency. What tends to be overlooked is the verifier-side burden: having the verifier perform full semantic interpretation of a domain’s credentials entirely on its own would be heavy; keeping a vocabulary referable to secure interoperability and having every verifier resolve the whole of it by itself are different matters. From these viewpoints, semantic interpretation can be seen as a layer with freedom of placement; it need not be completed
6
by the verifier alone. Three divisions of roles, for instance, are conceivable: The verifier resolves everything itself : it obtains all needed information, fully resolves the vocabulary, and interprets the payload’s meaning entirely by itself. Delegating interpretation: it entrusts part (or all) of vocabulary resolution and semantic interpretation to an external party and receives the result. Limiting the scope of interpretation and resolving details when needed: it refers only to the parts needed, handling the rest uninterpreted, and refers to details later as needed. These divisions of roles differ greatly in the verifier’s burden, the cost of network dependence, and the dependency relations. Where to place semantic interpretation is an instance of the placement problem in the decomposition of roles (Section III-E); among the layers of the establishment of verification, its freedom of placement is the most conspicuous. Delegating semantic interpretation to an external party means the verifier newly trusts the interpreting party: to accept the result, including vocabulary resolution, is to assume that that party performed them correctly—that is, to trust it. Such an introduction of trust should be made explicit under the formalization of trust (Section III-D). Delegation lightens the burden but increases the number of parties to be trusted. The role responsible for this layer is called the interpreter in this model. It may or may not be the same party as the signature verifier; distinguishing the two lets us state clearly the difference between “the signature can be verified but the meaning is not interpreted” and “the meaning too has been interpreted.” 3) L3 Validation: Once semantic interpretation (L2) fixes what a claim asserts, whether the verifier accepts it is still undecided. Validation is the activity of evaluating an interpreted claim against the verifier’s own criteria and deciding whether it may be accepted. These criteria are called the validation policy, determined by the verifier’s purpose and context: for the same claim, one verifier may accept and another may not. Whereas the result of signature verification (L1) is constant independent of verifier and context, the result of validation depends on the policy the verifier adopts, reflecting its purpose and use; if the policy differs, so may the result. Validation asks, among other things: is the issuer that emitted this claim acceptable as a party that emits claims of this kind; does the claim’s content satisfy the verifier’s conditions; and is the claim still in a state worthy of acceptance? Note that matters such as whether a signed object has been revoked or whether it is within its validity period are confirmations of objective facts, dependent on when validation is performed, and differ from the acceptance judgment: the facts can be confirmed mechanically, but whether one may accept on that basis is a separate question. Whether, having confirmed the certificate valid and not revoked, to impose a criterion such as “accept only those issued within one month” is set by the verifier’s validation policy. Of these questions, whether an issuer is acceptable cannot be answered by the verifier alone: the materials for that judgment are supplied chiefly from the Constitution plane introduced in Section III-A (details
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
in Section III-C1). Which materials enter the acceptance judgment, however, is set by the validation policy, and the verifier may also refer to materials beyond the Constitution plane. Here lies the contact point between the topmost layer of the establishment of verification (L3) and the Constitution plane on the acquisition side: validation can decide “to which set does this issuer belong, and may that set be accepted” by referring to the issuer set the Constitution plane defines. The form of the acceptance judgment is not uniform: it may be a static match against a list the verifier holds in advance, or a trace of the trust chain linking the trust anchor to the issuer in question. These differences of form appear in the Constitution plane’s design choice of how the set is constituted (Section III-C1). Common to both, validation refers to the constitution the Constitution plane defines to decide whether an issuer is acceptable. That W3C VCDM 2.0 [1] places validation outside its scope reflects validation’s dependence on the verifier’s intent. In the specification’s normative terminology, verification is defined as confirmation that includes conformance to the specification, satisfaction of the securing mechanism, and, if present, a successful status check, while the means of validation— judging conformance to business requirements—are left out of scope. In this model, the confirmations included in verification decompose into results of L1 and L2 or factual inputs to L3, and validation corresponds to the acceptance decision of L3. What a specification can prescribe extends to confirming integrity and data origin (L1) and to the vocabulary framework on which L2 relies; what to accept is left to each verifier. The role responsible for this layer is called the validator in this model. The signature verifier that verifies signatures, the interpreter that interprets meaning, and the validator that decides validity are logically distinct roles: typically implemented in a single party, yet conceptually distinct activities that may be divided among different parties. Once validation (L3) fixes acceptance, the establishment and acceptance of verification that this model handles is complete. Actually using an accepted claim—the consumption of a credential by a relying party—is an activity outside the model, premised on that acceptance: the model shows on what acceptance consumption rests, without entering into consumption itself. This acceptance presupposes that the verifier takes in the issuer set through its own policy (Section III-F). C. Acquisition of Verification Materials In this paper we call “verification materials” the collective term for what is supplied to the establishment of verification (L1–L3), and “verification artifacts” the individual fragments that compose those materials and that are treated as units of storage, retrieval, and bundling in acquisition. 1) The Constitution Plane: Constitution and Establishment of a Community: When the verifier judges an issuer’s acceptance in validation (L3), the verification materials are generally supplied directly from the issuer or from the community to which it belongs. The Constitution plane handles the arrangements a community shares and how, under them,
7
the community is constituted and established. As stated in Section III-A, the issuer set is one constituent element of a community, and the verification materials referred to in validation are constituted and managed under the community’s agreement. a) Constitution of a community’s arrangements: A community is constituted under the arrangements it shares. At their root lies the policy, through which governance works, fixing the governance of the community as a whole and of its constituent elements (how governance is exercised is beyond this paper’s scope). The policy includes the conditions for joining the set, the approach to managing the origin of trust, and the agreement on the protocols and data models used within the community. The constituent elements the policy prescribes are four— identifiers and namespace, the issuer set, the origin of trust, and other metadata—given either as independent elements or as consequences the policy yields. Identifiers and namespace: the identifiers that uniquely identify each party, including each issuer, within the set, and their namespace, or the definition thereof. Issuer set: the collection of issuers recognized in this community. Origin of trust: the set of propositions, shared in this community, assumed true as the starting point of the reasoning of verification. In this model, the key that serves as the handle for the reasoning of verification; in implementations it is represented as a trust anchor, a technical entity consisting of a signing key (or its digest) and associated data [27], [28]. Other metadata: additional information shared as needed. b) Derivation of the issuer set: logic and parameters: Among these elements, the origin of trust and the issuer set are often conflated but differ in function: the origin of trust gives “from where the reasoning of verification starts” (a key), the issuer set “who issues the credentials shared within that community.” How the issuer set is identified is prescribed by the policy: in this model it is viewed as obtained by one step of derivation through the logic and parameters the policy defines. How concrete the logic and parameters are admits variation, of which enumeration is an extreme case. Derivation: feeding parameters, including context, into logic prepared in advance to judge whether a given issuer belongs to the issuer set. The judgment is not a simple match against a list but a dynamic resolution based on parameters and context. An example is OpenID Federation [29], where an entity’s acceptance is resolved from information showing the chain and relations of authorities linking that entity to the origin; the logic is the chain-resolution procedure the federation shares. Enumeration: the case, within derivation, where the logic is simplified down to reference to a list and the judgment reduces to a static match. The parameter is an explicit list of issuers, against which the verifier judges membership in the set. The eIDAS Trusted List is one example. The origin of trust, by contrast, is independent of this derivation: it is what the verifier accepts from the community and uses as the starting point of the reasoning of verification (Section III-D, origin selection).
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
The choice of means for judging membership in the issuer set connects directly to the form in which validation (L3) is executed. Under derivation, the L3 acceptance judgment becomes the resolution of a chain, and the Constitution plane is expressed as the metadata and authority relations composing that chain; under enumeration, it becomes a match against a list, and the information the Constitution plane provides is a static list. How the policy defines the means of judging the issuer set is received differently on the issuing and accepting sides: the issuing side needs conformance to the policy to enter the issuer set; the accepting side, the verifier, needs acceptance of the policy. Merely receiving an issued credential does not complete validation (L3): only by also accepting that community’s Constitution—the arrangements such as the issuer set and the origin of trust—can the verifier complete the processing across the three layers. c) The word “Constitution”: As the name for this plane we use Constitution (constitution and establishment). What matters is less the static content of “what is shared” than the constitutional viewpoint of “how the set is constituted and how it is established and governed.” Constitution carries both senses—“the constituted state” and “the act of constituting”— and conveys the essence of this plane. One point needs care: a recursive structure is possible in which a community’s own members are themselves further communities. We deliberately avoid the term “Trust Framework”: what it denotes is precisely what this model tries to analyze finely, and the term is used polysemously, without agreed definitions. The model does not deny the notion but refines it by decomposing it into multiple layers and planes. d) The supply of verification artifacts concerning credential semantics: Semantic interpretation (L2) interprets a claim according to the vocabulary and schema on which the credential relies; from where that vocabulary itself is supplied is an important viewpoint. A vocabulary such as CTDL is given not as inherent in each credential but as a framework, shared by the issuer set, for describing meaning. The supply source of this vocabulary belongs to the Constitution plane. When the issuer set uses a particular vocabulary together, as “the agreement on the data model used within the set” (part of the policy), the vocabulary’s definition becomes part of the information constituting the issuer set. From which issuer set’s agreement the vocabulary derives, and from where it is fetched, is realized across the Constitution plane (the shared frame of meaning) and the Logistics plane (the delivery path of that definition). The framework includes artifacts of differing granularity or abstraction: the vocabulary itself (the language for description) and the definitions of individual credential types written in it (what is described in the language) can both become constituent information. A clue to whether a piece of information belongs to the Constitution plane is whether it is a type-level arrangement, fixed prior to an individual act of verification, and shared across the community. Note that sharing a vocabulary (the Constitution plane), interpreting individual claims with it (L2), and judging acceptance based on membership in the issuer set (L3) are distinct activities: describing a credential’s semantics finely
8
and accepting its issuer as a member of the set, for instance, belong to independent axes. 2) The Logistics Plane: The Delivery Path of Verification Materials: Signature verification (L1) completes in the verifying system’s local computation if the full set of signed data from the trust anchor to the target credential is present— but that “if present” is a premise, not a given. The Logistics plane handles where each verification artifact, including the signed data, actually resides and by what means it reaches the verifying system. a) The five elements of the Logistics plane: The Logistics plane prescribes the means by which each verification artifact, including the signed data, reaches the verifying system. We capture this in five elements. Element 1. Storage location: the verification materials are not necessarily gathered in one place. The trust anchor is often pre-embedded (bundled) in the verifying system; the middle of the chain of trust may lie at issuer endpoints or third-partyoperated repositories, with embedding into the credential and name-resolution systems such as DNS as further means; in the IHV model the target credential itself can be assumed to be in the holder’s hands, and dynamically fetched information, such as revocation information, is placed at pre-designated locations. Where the artifacts composing the chain reside is the first condition determining how the verifying system discovers and retrieves them. Element 2. Supply timing: even for the same artifact, the nature of verification changes with when it reaches the verifying system. Distributed before verification (pre-provisioning), it need not be retrieved at verification time; handed over with the presentation of the credential (bundling at presentation), it is present at that point; retrieved only when verification is executed (runtime retrieval), verification depends on the success or failure of that retrieval—a viewpoint of availability becomes necessary at verification time. A configuration in which the means differ by artifact—the trust anchor preprovisioned, the target credential bundled at presentation, revocation information retrieved at runtime—is entirely plausible. Element 3. Supply protocol: what communication procedure is used to retrieve each artifact. Retrieval over HTTP, retrieval involving name resolution, retrieval by dedicated issuance/presentation protocols—the means differ according to the artifact and its storage location. Element 4. Use of standard protocols: whether the protocol for supplying artifacts is specified as a standard or left to implementation. If standardized, verifying systems of different implementations can retrieve data by the same means, forming a basis for interoperability; without firm specification, each implementation uses its own means, and how artifacts arrive differs by verifying system. Element 5. Retrieval path of dynamic information: by what mechanism to retrieve information that can change over time, such as revocation information and various statuses. Whereas the preceding four elements chiefly target materials for static verification, this element targets time-varying information, and its method depends strongly on the nature of the target credential. Note that the five are not mutually orthogonal dimensions: element 4 is a property of element 3; element 5 is
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
elements 1 through 3 applied anew to time-varying material; and elements 1 and 2 constrain each other (bundling, for instance, fixes storage location and supply timing at once). The intent of the enumeration is not independence as dimensions but coverage of the viewpoints for examining a supply design. b) Orthogonality to the Constitution plane: The Logistics plane is orthogonal to the Constitution plane: the Constitution plane prescribes “what is shared” (the constitution of the community), the Logistics plane “how it reaches the verifying system.” What the Constitution plane defines (the origin of trust, the issuer set, the vocabulary definition, and so on) is of no use unless it reaches the verifying system, and that delivery path is carried by the Logistics plane. Only when both planes are present do the materials needed for the establishment of verification gather at the verifying system. c) Handling of dynamic information: The retrieval of dynamic information, the fifth element of the Logistics plane, can differ in means by credential type: for a credential with no notion of revocation—a degree certificate that is not revoked once conferred, for instance—this element can be unnecessary, whereas for one where revocation, suspension, or renewal can occur at any time, such as a driver’s license, revocation information is indispensable. How dynamic information is used reflects requirements from the establishment side of verification: under what intent and conditions the signature over a claim was made (the payload and its meaning, handled by L1 and L2), and what the verifier requires in validation (the L3 validation policy), together prescribe what dynamic information becomes necessary. Managing the freshness of materials is not a task the Logistics plane completes alone; it is achieved only when each layer of the establishment of verification and the Logistics plane act in concert. d) Network independence of verification: Whether verification is independent of the network—making offline verification possible—is determined by the design choices of the Logistics plane. With a pre-provisioned trust anchor and intermediate artifacts bundled at presentation, for instance, offline verification holds. A design in which artifacts depend on runtime retrieval means that the verifying system depends, directly or indirectly, on network availability at verification time and on the legitimacy of the retrieval source, which affects the acceptance judgment.
D. Formalization of Trust (The Shinken Framework) The three layers carrying the establishment of verification (L1–L3) and the two planes carrying the acquisition of verification materials (Constitution and Logistics) do not operate independently: each of the five functions necessarily contains a moment of assuming-true a proposition that is not decidable by the verifying system from available computational evidence alone. The Shinken framework gathers these moments under a single viewpoint—not a function that a particular layer or plane carries, but a cross-cutting viewpoint acting on all five functions that makes visible on what trust each function of the model stands.
9
1) Formalization of trust: The verifying system is constituted as logic that derives a verification result from given inputs. It is required to settle its result deterministically (determinism) and, when a false positive or false negative occurs, to allow the cause to be identified (transparency). The logic of verification, however, can contain propositions that are not decidable by the verifying system from the available computational evidence alone (hereafter undecidable propositions; the term is used in this operational sense, not that of computability theory). For instance, the proposition that “the controller of some signing key states, as authentic, what it signs with that key” concerns the operational reality of that party, and its truth cannot be confirmed by computation. The difficulty is resolved by assuming the proposition in question true within the logic of verification; this introduction of an assumption is what the model calls trust. Fixing an undecidable proposition as an assumption lets the whole logic of verification be constituted as decidable logic. Nor is the introduction of trust limited to undecidable propositions: even for a decidable one whose criteria are complex and whose effect at revision is hard to explain, trust can be introduced and the criteria omitted, keeping the logic tractable. Trust is thus an unavoidable introduction of an assumption for making verification hold, and making its point of introduction explicit is itself a condition of transparency. This structure admits a minimal notation. Let E be the set of computational evidence available to the verifying system, A the set of explicitly accepted assumptions, R the set of inference rules, and P the validation policy; the acceptance decision is then determined as D(E, A, R, P ). Determinism means that D is uniquely determined for the same E, A, R, and P ; transparency means that the origin of an outcome of D can be traced separately to E or to A. The introduction of trust is precisely the operation of placing an undecidable proposition explicitly in A. An assumption placed in A should, wherever possible, be recorded with its subject, scope, point in time, and responsible party: when an assumption breaks, this localizes the identification of the affected range and the re-examination. 2) Ubiquity of trust across the functions: The introduction of trust is not concentrated in a particular function but appears in each of the five functions. In the three layers of the establishment of verification, the assumptions appear as follows. Signature verification (L1), to derive “the controller of that key signed this payload” from success, assumes the binding of a key to its controller and that the signature was applied under that controller’s intent. Semantic interpretation (L2), when delegated externally, assumes that the interpreting party resolved the vocabulary correctly. Validation (L3) assumes that the materials the acceptance judgment relies on—the issuer set referred to and the trustworthy information obtained from multiple sources— hold as declared; the judgment deriving acceptance under a validation policy that deemed those materials worthy of trust likewise involves the introduction of an assumption. The two planes of the acquisition of verification materials are no different: the Constitution plane assumes that the community is actually constituted and established under its
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
arrangements (the policy) and that the issuer set and the origin of trust given from it are as the policy prescribes; the Logistics plane assumes that an artifact’s retrieval source is legitimate and that the retrieved artifact satisfies the declared correspondence and freshness. Each of these assumptions posits, as true, an operationally undecidable proposition. That trust gathers at no single point but is ubiquitous across all functions is itself the premise for discussing where to place roles. 3) Origin selection: Applying the formalization of trust to the trust anchor, the starting point of verification, yields one viewpoint on the structure of verification. The verifying system’s trust anchor is built into the logic of verification as “the set of propositions assumed true”: not an objective fact given from outside, but the set of assumptions from which the verifier decided to begin its reasoning. This re-frames, from origin selection, how the chain of trust is described. Naively, the chain runs from the issuer to the verifier. Seen from the verifier’s side, however, the reasoning does not arrive from the issuer: it begins with the trust anchor placed inside the verifying system—a reference to the origin of trust—and is traced from there, through the issuer, to the target credential. The issuer-to-verifier description is the same chain captured with its origin taken on the verifier’s side. All verification needs is that the full set of signed data from the origin of trust to the target credential be present; the party that raises that reasoning is the verifier. The logical direction of the reasoning must be distinguished here from the procedural direction of the implementation. Implementations often build a path by tracing signing-key references from leaf to root—from the target credential to its issuer and upward. Even so, the logical origin of the reasoning remains the root: the origin of trust the verifier assumed true. Which end a procedure builds from and where the logic places its origin are independent; origin selection shows the latter— it is the verifier’s side that fixes the origin of the logic. This contrast is shown in Fig. 3. In IETF documents, a trust anchor is described as a technical entity: a signing key (or its digest) together with associated data. This paper uses the term according to the role that the entity plays in the verification logic. The technical entity is a representation of this set of propositions, and is also one of the components constituting the signed data that the Logistics plane handles. 4) Mobility of the reasoning steps: The viewpoint of origin selection gives a logical foothold for the question of where to place roles. If verification is a reasoning chain originating at the verifier’s trust anchor, then each step composing that reasoning— each of the five functions—may be executed by the verifier itself or delegated to a trusted other, with the result received. As long as the reasoning chain is composed on the verifier’s side, who executes each step and where does not change whether the logic holds. That each function has freedom of placement (Section III-E) derives from this mobility. 5) Non-delegable functions: One thing, however, cannot move.
10
Origin of Trust
Origin of Trust
Issuer
Issuer
Credential
Verifier
Procedure direction: from leaf to root
Credential
Verifier
Logical direction: from root to leaf
Fig. 3. Origin selection: the procedural direction (left: the verifier traces signing-key references from leaf to root) contrasted with the logical direction of inference (right: the verifier takes its trust anchor as the root and proceeds toward the credential it holds)
It is the selection of assumptions. Which propositions to assume true—which trust anchor, which authority’s declaration, to accept as the origin of the verification logic—fixes the origin of the reasoning chain itself, and only the verifier can do it. To entrust this externally is to hand over to another the decision of what to trust: the logical subject of the acceptance decision D moves to the delegatee, and at that point it is no longer “the verifier’s own verification.” The selection of assumptions cannot be delegated—a natural consequence of the verifier itself fixing the origin of the logic. Put differently, what cannot be delegated is not a computational operation such as signature verification but the responsibility for choosing which propositions to accept as assumptions. Even the computation of signature verification is no exception to this mobility. With the signed data from the trust anchor to the target credential present, the computation can complete locally at the verifier (Section III-B1); it can also be entrusted to an external party with only the verification result received—a validating resolver in DNSSEC [28], [30], [31] is a typical example (in this configuration, the delegating side is required to receive the responses from the delegate over a secure channel). Yet delegation is not semantically neutral. If the delegatee returns evidence that can be independently re-verified, that evidence joins E as computational evidence. If only an attestation of the result is returned, accepting the delegated result is to assume true that the delegatee performed the verification correctly: an addition of a proposition to A, simply a new introduction of trust. The computation can be delegated; the selection of the assumption that trusts the delegatee remains on the verifier’s side. The decomposition of roles (Section III-E) targets the remaining functions, excluding this non-delegable one: of the model’s functions, all but the selection of assumptions have freedom of placement. The next section discusses the dimensions that govern that placement. E. The Three Dimensions of Role Decomposition, and Availability The preceding section showed that verification is a reasoning chain originating at the verifier’s trust anchor, that
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
each composing step has freedom of placement, and that the selection of assumptions cannot be delegated. For the remaining functions—the parts of each function’s work that can be put outside or delegated—this section asks where, when, and how far they may be disclosed, in three dimensions. This freedom is not unconditional: changing the placement leads to the same acceptance decision only where the meaning of, and the dependencies among, the processing each function performs are preserved. The three dimensions pose separate questions but are not mathematically orthogonal coordinates: a single design choice may affect several dimensions at once. 1) Dimension 1: Placement: The first dimension is where to place a function in the information space: at the verifier itself, entrusted to an external proxy, shifted upstream, into the neighborhood of the issuer, or bundled into the credential and carried along. The word “placement” is used in two senses— a broad sense (freedom of placement) denoting the freedom that the three dimensions together define, and a narrow sense denoting this dimension, i.e., spatial placement. Alongside the other two dimensions, “placement” takes the narrow sense. The object of placement is not limited to the two planes of the acquisition of verification materials (Constitution and Logistics); semantic interpretation (L2) is one as well. Resolving a vocabulary need not always be completed at the verifier’s edge: it can be delegated externally, or only the parts needed referred to. The “heaviness in processing” of a highly expressive vocabulary is thus not inherent in the vocabulary itself but governed by where the work of interpretation is placed: performed at the verifier’s edge, the burden there grows; placed elsewhere, the verifier’s burden changes. Where to place a function can be organized from the viewpoint of three asymmetries. Resource asymmetry: resolving a vocabulary or verifying a chain requires commensurate computational resources and code. Whether a party can meet this need varies, and can prompt delegation to a party that can secure the resources. Trust asymmetry: each time a function is delegated, the verifier newly trusts the delegatee. Delegation lowers the verifier’s burden while increasing the parties it must trust. If many verifiers delegate to the same proxy, a reconcentration of trust can arise there. Information asymmetry: whether the information a function needs can be fixed in advance or only at runtime changes the placement. A function depending on information fixable in advance can be shifted upstream, toward the issuer side. A function depending on runtime state cannot be served by prior placement alone, but this does not mean the processing must sit at the verifier’s hands: it can also be delegated to an external service reachable at runtime. 2) Dimension 2: Timing: The second dimension is when to begin the reasoning. It may be raised while a session with the counterpart is ongoing (the authentication flow), or a signature may be applied at issuance and verified at presentation (credential issuance and presentation): the same tracing of a chain of trust is done within a session in the one case and split between issuance and presentation in the other. From the viewpoint of origin selection, the reasoning on either side is isomorphic; only the timing of raising it differs. This
11
dimension concerns when to raise the reasoning—independent of when the verification materials are supplied (retrieved at runtime or bundled at presentation), the supply-timing choice of the Logistics plane. Even a design that raises the reasoning at presentation may retrieve materials at runtime or bundle them at presentation. 3) Dimension 3: Disclosure: The third dimension is whether the verification materials may be disclosed: whether the materials needed for verification (the list of issuers and the origin of trust held by the Constitution plane, the storage locations and supply paths prescribed by the Logistics plane, and so on) may be referable by anyone or should go only to limited parties differs by ecosystem and context. This dimension has two poles. At one, publicity of the verification materials is itself a requirement: in uses aimed at letting the public confirm the origin of emitted information, the issuer set and its constitution may—indeed should—be referable by anyone. At the other, disclosing the materials is not permitted in itself: where transaction or supply-chain relations appear in them, the very existence of those relations is information to be concealed, and disclosure would expose the structure independently of verification; verification is needed, yet the materials must be disclosed selectively, only to legitimate parties. For the same mechanism of verification, the required design differs entirely between the two. Even when the content of the materials is kept confidential, runtime retrieval can expose metadata—the retrieval endpoint, the time, the frequency—to observation. The publicity dimension covers not only the disclosure of content but also this range of observation. 4) Consolidating the availability discussion into the Logistics plane: In verification, “the availability of the retrieval source of an artifact at verification time” is often spoken of as an independent property. In this model, however, that verification-time dependence is organized as primarily shaped by the choice of supply timing in the Logistics plane. Suppose validation takes the form of deriving the issuer set. If the artifacts the derivation needs are, by design, retrieved at verification time, the establishment of verification depends on the availability of the retrieval source. If enough artifacts to make the derivation hold are instead bundled into the credential at presentation, the verifier can derive at runtime without querying anyone, removing the runtime dependence on availability (the dependence does not vanish; it shifts to the burden at issuance, distribution, and update time). What decides it is not the choice of the form of derivation but the timing choice in the Logistics plane—whether the artifacts are retrieved at runtime or bundled at presentation. The discussion also bears on privacy. A design that fetches materials at runtime discloses to the retrieval source “who is now verifying whose what”; this can be concealed by not retrieving—that is, by bundling into the credential. The design choice between depending on runtime retrieval of artifacts and completing with bundling thus decides the dependence on the availability of the retrieval source, and also how far the verifier exposes its own verification context externally.
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
F. The Whole Model in Overview, and the Position of the “Registry” Up to here, the model has been built on two decompositions. The first, the decomposition of function, divides the activity surrounding verification into five functions: three layers (signature verification, semantic interpretation, validation) and two planes (Constitution, Logistics). The second, the decomposition of placement, captures the parts of those functions, excluding the non-delegable function, as a freedom of placement along three dimensions (where to place spatially, when to raise the reasoning, how far to disclose). The former asks “what work it is,” the latter “where, when, and how far it may be disclosed.” This section surveys the model on that basis. 1) Conditions for the establishment of verification: Verification holds only when two planes of differing nature are present together: the Constitution plane, which prescribes how a community is constituted and established, and the Logistics plane, which delivers to the verifying system both the content of that constitution and the credential itself. Through them, the verifier obtains the trust anchor to be built into the verifying system and the chain of signed data reaching the target credential. The two planes are a division of function, not a requirement for two independent organizations or separate protocols: the same party or the same implementation may carry the functions of both planes. The constituent elements of the two planes differ in freedom of placement: each function, excluding the non-delegable selection of assumptions, can be placed according to the three dimensions of role decomposition. In this model, verifiability can be viewed as the relation of these two planes and as a freedom of placement. 2) The relation of the “registry” to the discussion of this model: Around the supply of verification materials, the word “registry” is often used. We show what this word can denote in the model. A registry is not the Constitution plane itself: it is one implementation form of that plane in the enumeration form— a data store that, as an authority, holds and declares the issuer set. Mechanisms providing an explicit enumeration of a list of issuers correspond to it. The Trust over IP Trust Registry Query Protocol (TRQP) [32] standardizes queries against implementations of this enumeration form, and is consistent with this model’s organization. By contrast, the collection of declarations obtained under the derivation form is not appropriately called a “registry.” The word carries connotations of a single authority, a centralized ledger, and a static reference source—connotations that do not fit a structure deriving membership by tracing distributed declarations, as in a federation. The Constitution plane can, as a concept, take both forms; a registry merely expresses the enumeration form. In practice, however, structures that derive membership by tracing distributed declarations, as in a federation, are sometimes also called registries. When the word is used, it should at least be made explicit which of the following is meant: (a) a static enumeration, (b) relations and declarations serving as inputs to derivation, (c) a repository or API for delivery, or (d) a combination of these.
12
This decomposition avoids inferring issuer-acceptance rules or interoperability from the single word “there is a registry.” 3) Independence of declaration and acceptance: On the other hand, an authority’s declaring the issuer set and the verifier’s taking that constitution into its own verification logic are independent. Acceptance is not an implicit, automatic process; it is mediated by the verifier’s validation policy. Whether to trust some authority’s declaration, or to accept some issuer set, is set as policy, and the verifier decides acceptance accordingly. That a registry declared does not, in itself, mean the verifier accepts. This independence also appears explicitly on the specification side: DIF’s Credential Trust Establishment states that publishing the governance file itself places no requirement on other participants to accept it [25]. This separation corresponds to two elements of the model. In validation (L3), a registry’s declaration is an input to the acceptance judgment, not the judgment itself; a validation policy may have multiple inputs, referring to multiple trustworthy materials from different sources and integrating them into one acceptance judgment. And in the formalization of trust (Section III-D), to trust some authority’s declaration is itself the introduction of trust into an undecidable proposition—an assumption introduced explicitly as policy rather than given implicitly—and the choice of which authority to trust is the non-delegable selection of assumptions. 4) A registry does not carry the delivery path: A registry is an authority that holds and declares what is correct; it does not carry how that content reaches the verifying system. Artifacts are carried by the Logistics plane—the registry does not transport. The model’s picture that the Constitution plane (with a registry as its enumeration form) and the Logistics plane are orthogonal rests on this distinction. A registry is the substance of a declaration placed on the side of the issuer set; the verifier refers to and accepts it through its own policy, the acceptance is fixed in validation (L3), and beyond it a relying party consumes the credential (Section III-B3). Declaration, acceptance, and consumption are separate activities of the authority, the verifier, and the relying party, respectively. G. Consequences of Being Verifiable, and a Worked Example We present seven consequences derived from the conditions of being verifiable. The seven are not claims of equal strength; they divide into three kinds: definitional corollaries that follow directly from the definitions (the first and fourth), operational implications that follow from design conditions (the second, third, and fifth), and design trade-offs whose evaluation varies with placement (the sixth and seventh). First (a definitional corollary), the scope within which verifiability holds is bounded by the set of arrangements and trust assumptions the verifier accepts: a chain from the trust anchor to the target credential can hold only where the verifier accepts the constitution making it hold—that is, within the community. Following directly from the definition of community, its significance is to carve out cross-boundary connection as an explicit object of analysis. In this sense, verifiability is not an absolute property: it is relative to the verifier, the use,
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
the point in time, and the accepted arrangements and trust assumptions—the same credential can be verifiable to one verifier and unverifiable to another. Nor does this boundary always coincide with a legal or geographic enclosure; it is drawn by the acceptance of arrangements and assumptions. Second (an operational implication), verification is reasoning that starts at the verifying system’s trust anchor and proceeds toward the target credential (Section III-D, origin selection). Third (an operational implication), once the trust anchor and the chain of signed data are present at the verifying system, verification completes as a local computation and requires, in principle, no runtime inquiry to any external party. Fourth (a definitional corollary), verifiability holds only when the two planes, Constitution and Logistics, are both designed; neither alone suffices. The two planes are orthogonal yet not unrelated: under the derivation form, the chain of declarations deriving membership composes the content of the Constitution plane, yet if the artifacts making that chain hold are bundled at presentation, even they can be carried by the Logistics plane. The timing choice of the Logistics plane thus governs the form in which the content of the Constitution plane reaches the verifying system. Fifth (an operational implication), offline verifiability is determined by the choices of storage location and supply timing in the Logistics plane (Section III-C2, network-independence of verification). If, however, the validation policy demands an up-to-date status check at execution time, bundling the materials alone cannot make verification offline: offline verifiability holds when both the Logistics choices and the policy’s freshness requirements permit it. Sixth (a design trade-off), how the “weight” of a given placement is evaluated is relative to how the verifier’s role is set: the “weight” of placing vocabulary resolution at the verifier’s edge grows under a role setting that performs it there; change the placement, and the evaluation changes too. Seventh (a design trade-off), the model captures two important sources of privacy risk, and their interaction. One is leakage of the verification context: a design that retrieves materials at runtime exposes the verification context to the retrieval source—a matter of supply timing in the Logistics plane. The other is the disclosability of the verification materials themselves: whether they may be public or require limited disclosure is shown by the disclosure dimension (Section III-E). Where disclosing the materials is not permitted in itself, runtime retrieval compounds the exposure, and leakage becomes most severe; between uses where disclosure is permitted and where it must not be, the designs required for privacy are opposite. The relation of these two planes, the placement along the three dimensions, and the consequences drawn from them organize, under one model, the phenomena presented at the outset (the four observations of Section I, and the many senses in which terms such as registry are used). 1) Worked example: tracing a single diploma: We now trace the decomposition end to end through one concrete example: a university (issuer) issues a diploma to a graduate
13
(holder), who presents it to a company (verifier) in a hiring process. In signature verification (L1), the verifying system follows the reference to the verification key bundled with the diploma and verifies the signature. What is confirmed is that the payload has not been altered since signing and that the controller of the corresponding signing key signed it—a confirmation that yields the same result no matter who performs it. In semantic interpretation (L2), the payload is interpreted against the vocabulary it relies on: which institution awarded which degree, to whom, and under which criteria. The vocabulary is not intrinsic to each individual diploma; it is supplied as something the community shares. In validation (L3), acceptance is decided against the verifier’s validation policy—for example, “accept only what an accredited institution of higher education has issued.” The materials for judging whether the issuer belongs to that set cannot be prepared by the verifier alone; they are supplied from the Constitution plane. Suppose the Constitution plane in this example takes the enumeration form: a list of accredited institutions (a trust list) is maintained under the policy and shared together with the identifier namespace and the origin of trust. The verifier judges the issuer’s membership by matching against this list. On the Logistics plane, the origin of trust is provisioned to the verifying system in advance, the diploma and the intermediate signed data are bundled at presentation, and revocation information is unnecessary (we take a degree to be of the type that, once awarded, is not revoked). With these choices, verification completes at the point of presentation without depending on the network. Retracing this sequence through the Shinken framework brings out the propositions posited as true at each step: the binding of key and controller (L1), the correct resolution of the vocabulary (L2), the list’s declaration being as the policy prescribes (Constitution), and the bundled artifacts satisfying the declared correspondences (Logistics). The choice of which of these to accept as assumptions remains on the verifier’s side. The same example takes a different shape as the choices along the three dimensions change: delegating vocabulary resolution to an external interpreting agent changes the placement and adds a new introduction of trust to be made explicit; a credential type with revocation brings in runtime retrieval, and supply timing begins to bear on availability and privacy; a list requiring restricted disclosure lets the disclosure dimension reshape the whole design. The model’s vocabulary describes these as differences of choice over the same skeleton. H. Generalization to Combinations of Multiple Credentials The discussion so far has been built around a single credential (Section III-A): the three layers and two planes form a skeleton stating by what logic a single credential is verified. Real verification, however, often involves multiple credentials—one might even say the situation truly to be discussed is one where a credential confirming identity and one asserting an attribute (a national ID and a learner credential, say) satisfy the verifier’s purpose only in combination. This section generalizes the model to such combinations.
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
Delivery of Materials
L2: Semantic Interpretation L1: Signature Verification
Constitution
L1: Signature Verification
L3: Validation Gives the framework of Semantics
L2: Semantic Interpretation
Gives the framework of Semantics
L3: Validation
Constitution
Handover of Acceptance Result
Formalization of Trust (Shinken)
The generalization requires no new layer; it can be expressed as an extension of the structure already described, in particular the integration of multiple sources in validation (Section III-F). 1) Multiplexing of the Constitution/Logistics pair: First, the Constitution and Logistics planes are not one pair for the whole model: a corresponding pair exists per credential, each with its own logic and parameters for deriving the issuer set (via the Constitution) and its own delivery path (Logistics). Combining credentials from different governance systems, such as a national ID and a learner credential, hands multiple Constitution/Logistics pairs to the verifier. This does not mean, however, that each pair is a distinct entity: the same Constitution may be shared by multiple credentials. Even then, the picture is unchanged—for each credential, the Constitution and Logistics on which it relies are identified. The acquisition of verification materials in combined verification is therefore assembly from multiple supply systems, not retrieval from a single one: the verifier gathers, under its own validation policy, materials arriving by different paths, with different constitutional declarations and trust anchors per credential. The picture of the two planes is preserved per credential while the whole is multiplexed. 2) The chaining of the establishment of verification: the basic form: How are the verifications of multiple credentials related? In the basic form, the establishment of verification of one credential becomes an input to the validation of another: one completes its own three layers (signature verification, semantic interpretation, validation), and the other’s validation refers to that fixed result as one of its verification materials. Typically, the verification of a credential confirming identity holds first, and, premised on that, the acceptance of an attribute credential is judged. This basic form is shown in Fig. 4. This form simply generalizes the picture of Section III-F (integrating multiple trustworthy materials into one acceptance judgment). “Materials” has so far meant those directly involved in verification, such as declarations and revocation information; the generalization is that the result of the establishment of verification of another credential—complete with its own three layers, two planes, and Shinken framework—can itself be such a material. No new layer is stacked on top of validation; the input to validation can simply be the output of another establishment of verification. Origin selection (Section III-D) is preserved under this generalization too. The verifier’s reasoning is now not a single chain rooted at one trust anchor but a structure in which multiple chains, each rooted at a different trust anchor per credential, merge at the verifier’s validation. The roots multiply, but every chain still starts from the assumptions of trust the verifier itself holds: the origin of the reasoning remains on the verifier’s side even with multiple roots. 3) A special form, and making the introduction of trust explicit: Against this, there can also be a form in which multiple credentials each complete signature verification and semantic interpretation, and a single validation accepts the whole at once—a special case of the basic form. Instead of fixing each credential’s acceptance judgment independently, one validation policy treats all credentials as inputs of equal
14
Delivery of Materials
Logistics
Logistics
Supporting Credential
Target Credential
Fig. 4. An example of nesting in the establishment of verification under combined verification. A three-layer stack with its Constitution/Logistics pair is placed once each for the supporting credential and the target credential. The result of the supporting credential’s validation (L3) is passed as an input to the target credential’s validation. Each stack is given its interpretive frame under its own Constitution and follows an independent set of arrangements.
standing and decides acceptance in a single judgment. Only the number of judgment stages differs; gathering materials from multiple supply systems and consolidating them under the verifier’s policy is shared with the basic form. In either form, the objects the Shinken framework (Section III-D) requires to be made explicit increase. Accepting another credential’s verification result as an input to validation is to assume true that that verification was performed correctly— a new introduction of trust. The assumption tends to be placed tacitly when the referred verification was performed by a different party, that is, when only the result of a delegated verification is received; the merge point of combined verification is thus a typical position where Shinken requires trust to be made visible. And where the verifying party’s consolidated acceptance itself feeds yet another party’s validation, a need can arise to make explicit, to that party, which verification results were consolidated under which assumptions. This concludes the presentation of the model. The next section applies it to the stacks presented earlier and attempts an analysis. IV. A PPLICATION AND E VALUATION We apply the model to the four kinds of stacks observed in the learner-credential domain [9], interpret the phenomena presented in the introduction, and then cross-compare existing ecosystems, including authentication systems, along the three dimensions of role decomposition. The learner domain serves as the main concrete example; the model itself is not limited to learner credentials. This section’s evaluation is an analytical demonstration based on public documents; it does not rank the stacks’ performance or maturity. The four stacks are not at a uniform level of abstraction or completeness, ranging from base specifications alone to an ecosystem equipped with regulation, a trust model, and protocol profiles. The purpose of this section is not to rank them but to make visible, in a single vocabulary, which functions each stack specifies itself and what it leaves to external parties in composing a complete verification stack. A conceptual model cannot be evaluated through quantitative performance measurement; this section evaluates against three criteria: whether it can explain the phenomena of Section I (explanatory power), distinguish design
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
differences across stacks in a single vocabulary (discriminating power), and derive design implications from the analysis (derivation of implications). Such criteria-based evaluation follows the notion of evaluation in design science [33] and taxonomy development [34]. The judgment criteria of this section’s tables are as follows. In Table IV, “explicit” means that the constituent element is specified in normative statements of a public specification or regulatory document; “undefined,” “out of scope,” and “not specified” mean that no specification could be confirmed in the stack’s public documents. All judgments rest on the analyses in Sections IV-A to IV-D and the specifications cited there (reference time points: Section IV-H); the judgments in Table I likewise rest on the explicit scope of description of the works concerned. A. Stack A: Open Badges / CLR (1EdTech) Constitution plane: among the community’s constituent elements, the sharing mechanisms for the “origin of trust” and the “issuer set” are undefined; policy too is left to each issuer, and no community-wide policy exists as a structure. Logistics plane: it relies on HTTP reference to issuer URLs, with weak specification of storage location and supply path at the protocol level. As a result, the verifying system comes to depend implicitly on the Web PKI TLS certificate chain—which shows “that this domain communicates legitimately,” not “that it is legitimate as an issuer of learner credentials.” The analysis targets the operational reality of the Open Badges 2.0 generation. In the current-specification generation, Open Badges 3.0 [7] and the Comprehensive Learner Record Standard 2.0 [35] prescribe VCDM-conformant signature representations, and CLR 2.0 reuses the EndorsementCredential—a credential carrying third-party endorsement—defined by OB 3.0. The credentialtransfer API was historically specified as the Badge Connect API of OB 2.1; in OB 3.0 the Open Badges API, integrated into the specification body, provides the standard path. In addition, the TrustEd Credential Coalition (announced in March 2024 as the TrustEd Microcredential Framework and later renamed) provides a framework that supplements metadata quality outside the specification layer [36]. Even so, usespecific issuer authorization, the trust anchors to adopt, and the final validation policy are not fixed by the specifications, and the Constitution plane’s sharing mechanism remains undefined at the specification layer—a gap that marks the boundary of responsibility between the specification layer and the ecosystem layer rather than a defect. The breakdown of email-addressbased learner identification in Open Badges 2.0 is due to this deficiency of the two planes, in addition to an email address not proving control by a particular subject (SP 800-63B [37]). B. Stack B: Unprofiled DID/VC (W3C) Constitution plane: what the VCDM and DID [8] specifications provide extends to the structure of signed data and the abstract definition of identifiers; the sharing mechanisms for “policy,” “origin of trust,” and “issuer set” are outside the
15
scope of the W3C specifications and left to the application side. Logistics plane: it is DID-Method-dependent, with resolverbased runtime retrieval as the representative form (a DID Document can also be obtained through peer methods or prior distribution). The proliferation of more than 260 DID Methods [38] can be described as the consequence of no convergence pressure being applied to the Logistics plane. C. Stack C: EDC/ELM/EUDI-Wallet (European Commission) Constitution plane: the trust lists of eIDAS 2.0 provide the constituent elements in a nearly complete form. Policy is prescribed as the eIDAS regulation; identifiers and namespace as per-member-state namespaces. The issuer set is enumerated explicitly—in Trusted Lists for QEAA and PuBEAA providers, and in a List of Trusted Entities (LoTE) for PID Providers. The origin of trust is the trust anchors these lists carry, discoverable through a common trust infrastructure maintained by the European Commission.1 Providers of nonqualified EAAs are also subject to registration by a Member State Registrar, but they are not notified to the European Commission, and their trust anchors are not automatically included in a Trusted List or the LoTE. The ARF recommends (SHOULD) that the applicable Attestation Rulebook define a domain-specific mechanism for obtaining trust anchors, and methods other than the LoTE are permitted. Logistics plane: OID4VCI [4]/OID4VP [5] prescribe the issuance and presentation protocols of credentials, the Status List prescribes the retrieval path of dynamic information, and a Trusted List distribution protocol prescribes the supply of the Constitution plane’s content. OID4VCI itself leaves out of scope how trust in the signer of signed issuer metadata is established (its Section 12.2.3); in the EUDI ecosystem this is supplemented by the ARF, which prescribes certificate chains leading to the trust anchors of Access Certificate Authorities [11]. Within the scope treated in this paper, this is the only stack in which both planes are designed. Offline verifiability also holds, within the profiles analyzed here, by combining the holder-bundled type of mdoc/SD-JWT VC with the preprovisioned type of the Trusted List—under configurations where status information, including revocation status and the currency of the pre-provisioned list, is either not required or is available under the freshness policy the deployment assumes. Its community boundary, however, is fixed within the EU; connection beyond it requires additional inter-community mapping and mutual acceptance arrangements. From the model’s viewpoint, the design of Stack C is an example other stacks should take as reference, though the handling of the community boundary remains a topic for further development. 1 The specification analysis of Stack C is based on ARF v2.9.0 [11], the current version as of the literature-access date (July 11, 2026). Although this postdates the observation window of the operational analysis (November 30, 2025; Section IV-H), the revisions since v2.0 chiefly refine the trust-list structure and systematize the catalogues, and do not change the conclusions of this section.
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
D. Stack D: Platform-proprietary Constitution plane: a single platform operator prescribes the constituent elements. Logistics plane: it completes within the platform’s own internal protocol. This is a vertical integration in which a single operator holds both planes. It functions as a community, but its governance is concentrated in a single party, and interoperability beyond the boundary depends on the platform operator’s intent. Table IV summarizes the analyses of Stacks A–D in a unified format using the model’s vocabulary: aligning the Constitution plane’s constituent elements (policy, issuer set, origin of trust) and the Logistics plane’s specification status under the same viewpoints makes the design differences across the stacks readable within a single vocabulary. E. Worked Example: Sharing the Same Data Model Is Not Sufficient for Interoperability How the coexistence of stacks appears as a failure of interoperability can be confirmed with one concrete example. An OpenBadgeCredential of Open Badges 3.0 is a verifiable credential conforming to the VCDM [7]. Suppose it is presented to a verifier—corresponding to Stack B—that implements only the base specifications of the VCDM and DID Core. At L1, the signature cannot be processed unless a compatible proof scheme and a way to obtain the verification key have been selected. At L2, without an arrangement for interpreting the OB 3.0 vocabulary (Achievement and the like), the meaning of the claims is not determined. At L3, the materials for judging which issuers may be accepted (the issuer set and the origin of trust) are not supplied by any Constitution plane. That is, this failure is positioned not as a mismatch on the single item “whether the same JSON-LD or VC is used,” but as the absence, somewhere in L1–L3, Constitution, or Logistics, of a shared choice, material, arrangement, or policy. The agreement “the same data model” that element-by-element comparison exhibits shares only part of the premises of L2. F. Cross-Ecosystem Comparison by the Three Dimensions of Role Decomposition Stacks A–D are cases confined to the learner-credential domain. This section uses the three dimensions of role decomposition (placement, timing, disclosure) to cross-compare existing ecosystems, including authentication systems; widening the comparison is warranted because the discriminating power of the three dimensions appears most clearly among ecosystems whose choices of timing and disclosure diverge. Stack C (Section IV-C) corresponds to the EUDI / EUDIWallet row and is analyzed both from the specification status of the two planes and from its position on the three dimensions. We also include Originator Profile (OP) [39], a proposal for originator-attribute disclosure and content protection in media publishing, although its use case differs from credential issuance; OP is a system of static attribute disclosure, premised on the information being public. The authors are involved
16
in the design of OP; we state this explicitly and include it in the comparison. Table V presents this cross-ecosystem comparison. The same trust-establishment mechanism, Federation, appears in both the authentication context (resolving the counterpart) and the credential context (resolving the signer); that the same word appears in two contexts is one cause of the terminological confusion arising across multiple ecosystems. As a function set of the three layers, the two planes, and the Shinken framework, these ecosystems do isomorphic work but differ in the choices along placement, timing, and disclosure; the model can provide a vocabulary that describes functional isomorphism and placement difference at the same time. G. Demonstrating the Model’s Interpretive Power Two examples show that the model has the power to interpret existing systems and discussions: eduGAIN [40], where the three dimensions of role decomposition analyze how the same function appears at different timings and placements; and the Registry of the CTDL ecosystem, where decomposition into the two planes analyzes one word bundling entities of different planes. 1) eduGAIN: distinguishing authentication and credential: eduGAIN was originally a federation of authentication/authorization (an IdP passes in-session attributes to an SP as SAML assertions), and it operates as an interfederation service in which the MDS aggregates, validates, signs, and republishes the participating federations’ metadata [40]; those attributes are not portable credentials. Learner records such as a diploma, by contrast, are credentials “issued, held by the person, and presented at an arbitrary time”; the two are different activities. eduGAIN has been running a pilot of OpenID Federation since July 2025 [41]; this is a trial toward updating the trustestablishment mechanism of authentication and is not directly linked to credential issuance. Yet because Federation appears as a “trust layer” in both contexts, the question “with the Federation move, will diploma issuance also be done with Federation?” binds two different activities in one word. From the model’s side, this can be explained as “the same function merely appearing at two different timings (issuance vs. session) and placements,” and a model equipped with the three dimensions makes the underlying isomorphism explicit: Federation appearing as a “trust layer” in both authentication and credential presentation is the same work—as a function set of the three layers, the two planes, and the Shinken framework—done in two places with different choices along dimension 2 (timing) and dimension 1 (placement). Recognizing this, the discussion can separate “the Federation update on the authentication side” from “the trust-chain design on the credential issuance/presentation side.” 2) CTDL Registry: two planes bundled in one word: The CTDL ecosystem (operated by Credential Engine) consists of three kinds of information: individual issued credentials; individual credential type definitions published on the Credential Registry [42]; and the CTDL vocabulary as the language of description. A type definition is a type-level descriptive record
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
17
TABLE IV U NIFIED ASSESSMENT OF THE FOUR LEARNER - CREDENTIAL STACKS : SPECIFICATION STATUS OF THE C ONSTITUTION AND L OGISTICS PLANES Viewpoint
Stack A: Open Badges/CLR
Stack B: unprofiled DID/VC
Policy
Left to each issuer; no community-wide policy Sharing mechanism undefined
Outside W3C specification scope (left to the application) Out of scope
Origin of trust
Undefined dependence on PKI TLS chain)
Out of scope
Delivery (Logistics)
HTTP reference to issuer URLs; storage and supply weakly specified
DID-method-dependent; runtime retrieval via resolvers as the representative form
Not specified
Not specified
Neither is sufficient
Neither is sufficient
Issuer set
path
Retrieval path of dynamic information Design status of the two planes
(implicit the Web
Stack C: EDC/ELM/EUDIWallet Explicit, as the eIDAS regulation Explicit: Trusted Lists (QEAA/PuB-EAA); a LoTE (PID Providers) Explicit: trust anchors in the Trusted Lists/LoTEs (discovered via the common trust infrastructure) Prescribed by OID4VCI/OID4VP and a Trusted List distribution protocol Status List Both planes designed (the only case within the scope of this paper)
Stack D: platformproprietary Prescribed solely by the operator Prescribed solely by the operator Prescribed solely by the operator Within the platform’s internal protocol Within the internal protocol A single operator holds both planes
TABLE V C ROSS - ECOSYSTEM COMPARISON ALONG THE THREE DIMENSIONS OF ROLE DECOMPOSITION Ecosystem eduGAIN (SAML/MDS)
Timing session time
Disclosure public (aggregated distribution)
OpenID Federation (per-entity)
session time (runtime resolution)
public (resolvable)
EUDI Wallet
/
EUDI-
issuance + presentation
public (Trusted List)
Originator (reference)
Profile
issuance + viewing
public availability is a requirement
Placement characteristics A pre-aggregator aggregates and signs the distribution; the verifier accepts the aggregated set en bloc. Simple but centrally aggregated: pre-distribution removes dependence on a retrieval source at verification time, at the cost of aggregation freshness and trust concentrated in the aggregator. The verifier resolves dynamically or delegates to a resolver. Distributed, with fetch/privacy cost; runtime resolution depends on the availability of the retrieval source. Three functions separated: Federation as the issuer trust layer, VCI as issuance, VP as presentation. The trust chain is verified at presentation; bundling there removes dependence on the issuer’s runtime availability. The verifier (a browser extension) is kept minimal; materials shift to the issuer side or are bundled with the content. Bundled verification is self-contained, requiring no reachability to the issuer at verification time; dynamic retrieval from the verifier side is also supported.
bound to a CTID (Credential Transparency Identifier). Individual credentials pass from issuer to holder; type definitions and the vocabulary are published from the Registry and its related infrastructure.
the form of enumeration appears in two places across layers. Indeed, Credential Engine itself operates, separately from the Credential Registry, an Issuer Identity Registry that enumerates the issuer set [43], [44].
Applied to the model: the vocabulary is “the agreement on the data model used within the set” (part of the policy) that the issuer set shares—content of the Constitution plane. Individual credential type definitions are likewise type-level, prior to individual acts of verification, and arrangements the community shares, so they too belong to the Constitution plane’s content. The two correspond to the units of differing granularity stated in Section III-C1: the language for description and what is described in that language.
By contrast, the mechanisms of the Registry, such as CTID resolution and record retrieval, are paths that deliver this content to the verifying system, and belong to the Logistics plane. A status list, by comparison, is dynamic information bound to an instance: a verification material carried by the fifth element of the Logistics plane, not content of the Constitution plane.
Here a parallelism with the trust list holds: just as the eIDAS Trusted List is Constitution-plane content that enumerates membership toward the acceptance judgment (L3), the collection of credential type definitions on the Registry is Constitution-plane content that enumerates type-level descriptions of meaning toward semantic interpretation (L2)—
The interpretation from applying the model is this: the single word “Registry” bundles the entities of two different planes— the institution on the Constitution side and the mechanism on the Logistics side. As limited in Section III-F, a registry in this model is the substance of a declaration and does not carry the delivery path; the CTDL Registry bundles the two under one word and one operating party, and the confusion around the word stems from that consolidation. Decompose them, and
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
each entity settles into its own plane. Just as the eduGAIN analysis showed one mechanism (Federation) appearing at two timings and placements, here one word straddles two planes. This decomposition also reformulates the often-noted point of single-operator operation by Credential Engine: the core of the problem is not single operation in itself, but that the declaring authority of the enumeration-form Constitution content and its supply point on the Logistics side are held concurrently by a single operator—leaving the non-delegable choice of which authority to trust (Section III-F) without a substantive alternative. The two-plane decomposition shows that the authority of declaration and the path of distribution could be carried by different parties, and shows this state as a design choice rather than a necessity. Table VI summarizes the explanatory power of the model for the cases applied in this section, contrasted with elementwise juxtaposed comparison. In this table, “Yes” means that the cause of the phenomenon can be identified in the vocabulary of the approach; “Partial,” partially; “No,” that the approach lacks the vocabulary to identify it. The four observations of the introduction are likewise grounded in this section’s analyses. That stacks do not interoperate (Observation 1) is a consequence of each stack’s Constitution and Logistics planes being designed independently; the worked example of Section IV-E located where the failure arises. The tendency of discussion to center on the issuer (Observation 2) appears in the thin specification of the Logistics plane in Stacks A and B that Table IV makes visible, and is paired with the polysemy of terms such as “registry,” which the CTDL analysis above decomposed into the two planes. The differing granularity of specification for the storage and supply of issuer information (Observation 3) can be read off Table IV as a design difference in the tier at which the five elements of the Logistics plane are prescribed. And for the missing discussion of the division of the verifier’s role (Observation 4), the cross-comparison along the three dimensions in Section IV-F supplied the analytic means. H. Limitations of the Evaluation The evaluation in this section has limitations. First, the stacks and cases treated center on the learner-credential domain and reflect the authors’ selection; they are not exhaustive. Second, what has been shown is interpretability for existing ecosystems; the effectiveness of using the model to design a new ecosystem is a task to be verified through future application. Third, the analysis of each stack is based on the published specifications and observable operational reality as of November 30, 2025 (due to the drafting timing of the paper [9]), and may not reflect internal design intent. Fourth, the judgments in Tables IV and VI were made by the authors; the agreement independent raters would reach when reclassifying with the same criteria has not been measured. Fifth, this section presents cases the model could explain; it does not conduct a systematic search for phenomena the model cannot explain (a search for counterexamples). Sixth, because judgments such as “explicit” and “not specified” take public documents as their range of evidence, they cannot distinguish
18
what is not public from what does not exist. The literature survey and the access to the referenced specifications are as of July 11, 2026; a referenced specification postdating the observation window is used only to characterize the current status of that specification, not to infer prior implementation or deployment intent. The specification analysis of Stack C is based on ARF v2.9.0 [11], the current version as of the literature-access date (see the footnote in Section IV-C). V. C ONCLUSION This paper presented a conceptual model for organizing the siloing, the lack of interoperability, and the confusion of discussion observed in the digital credential ecosystem. In the introduction we presented, as phenomena that the existing comparison axis of juxtaposing technical elements fails to capture, four observations together with the polysemy of terms such as registry. In the conceptual-model section, taking the framework of the Trusted Web White Paper ver.3.0 as upstream and incorporating the refinement by the Claim Validation model and the Shinken model [13], [14], we presented a model of five functions: three layers that carry the establishment of verification (signature verification (L1), semantic interpretation (L2), validation (L3)) and two planes that carry the acquisition of verification materials (Constitution and Logistics), with the Shinken framework acting on all five to make the introduction of trust explicit. Constitution and Logistics are orthogonal, and verifiability holds only when both are present. On top of this decomposition of function we introduced a decomposition of roles—where to place each function, excluding the nondelegable selection of assumptions—along three dimensions (placement, timing, disclosure). We limited the word “registry” to one implementation of the Constitution plane’s enumeration form, and made explicit that declaration and acceptance are separate activities. The generalization to combinations of multiple credentials requires no new layer: it is the integration of multiple sources in validation, whose point of integration becomes a new introduction of trust made explicit (III-H). From this structure we drew seven consequences, concerning the scope within which verifiability holds, origin selection, offline verifiability, and the constitution of privacy, among others (III-G). In the application-and-evaluation section, we applied the model to the four kinds of stacks in the learner-credential domain and cross-compared existing ecosystems, including authentication systems, along the three dimensions of role decomposition. In Stacks A and B, neither plane is sufficiently prescribed; Stack C is, within the scope treated in this paper, the only example in which both planes are designed; Stack D is a structure in which a single operator holds both planes. In the cross-comparison, we organized eduGAIN, OpenID Federation, EUDI / EUDI-Wallet, and Originator Profile as differences in the choices along the three dimensions, and showed, as a demonstration, that the model makes explicit the isomorphism underlying the eduGAIN question. We summarize the utility of the model in three points. A frame for evaluating proposals: for a proposed new standard or protocol, one can ask which of the Constitution
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
19
TABLE VI E XPLANATORY POWER OF ELEMENT- WISE COMPARISON VERSUS THIS MODEL (Y ES : EXPLAINS ; PARTIAL : PARTIALLY; N O : DOES NOT EXPLAIN ) Case Open Badges/CLR
Element-wise comparison Partial
This model Yes
unprofiled DID/VC
Partial
Yes
EDC/ELM/EUDIWallet CTDL Registry
Yes
Yes
No
Yes
eduGAIN
No
Yes
plane’s constituent elements it prescribes at which tier, how it prescribes the five elements of the Logistics plane, and how it places each function along the three dimensions. A proposal that cannot answer these questions leaves a hole in the implementability of the verifying system. The utility of terminological organization: when terms such as “registry,” “trust list,” “issuer metadata,” “Trust Framework,” and “Federation” are used, making explicit which element of the Constitution or Logistics plane each denotes, and which choice along the dimensions of role decomposition it implies, enables cross-cutting discussion. The eduGAIN analysis is a concrete example of this utility. Concretizing the verifier’s viewpoint: discussion from the verifier’s viewpoint can be reduced to concrete questions— how to acquire the trust anchor to be built into the verifying system, how to gather the signed data composing the chain of trust, and where to place each function. To correct discussion biased toward the issuer’s viewpoint, it is effective to keep these questions always on the table. Premised on the model, several topics remain as future work. The first is the recursive structure of communities: a community does not exist alone but can be organized, as a part of a larger community, into a nested structure—a community within a community. The recursion appears in both planes: in the Constitution plane, the constituent elements of an upper community can be inherited by or referred to from a lower community; in the Logistics plane, a lower community can use the supply path of an upper community, or an upper community can aggregate the supply paths of lower communities. A resolution mechanism for contradictions between the policies of an upper and a lower community also belongs to this topic. The second is the design of inter-community mapping, which requires the elements of both communities’ Constitution and Logistics planes to be made mutually referable, with explicit rules for how trust propagates; trust cannot be assumed to be transitive [45], and the machine-readable publication of mutual recognition between trust schemes [46] directly overlaps with this problem. The third is principles of supply design that ease connection, such as separating the constituent elements and making role placement explicit. These, together with the correspondence of the existing “Trust Framework” notion to this model, are planned to be developed in separate manuscripts.
Key point of the explanation The TLS chain shows the legitimacy of a domain, not legitimacy as an issuer of learner credentials (deficiency of both planes) A DID Method gives the resolution path (Logistics); policy, issuer set, and origin of trust (Constitution) are out of scope Both planes are designed; offline verifiability is explained as the combination of bundling and pre-provisioning The single word “Registry” bundles two planes: Constitution (governance of what is registered) and Logistics (the delivery infrastructure for resolution and retrieval) Isomorphism: the same trust-establishment function appears at two different timings (session vs. issuance) and placements
A PPENDIX A OVERVIEW OF T RUSTED W EB AND THE S HINKEN M ODEL The model of this paper builds on the Trusted Web White Paper ver.3.0 (in Japanese) [12], the Claim Validation model by Abe et al. [13], and the development by the Shinken model (in Japanese) [14]. This appendix gives a brief overview of the two sources available only in Japanese; for the Claim Validation model, we refer the reader to the original paper. The Claim Validation model and the Shinken model are described in the vocabulary of three parties: the verifier (the Validator in the former, the Verifier in the latter), the Claimant, and the Certifier. The “issuer” of this paper corresponds to the Certifier; the verifying party divided here into the three roles of L1–L3 corresponds to the verifier of both models. A. Trusted Web Trusted Web is an initiative, studied by the Trusted Web Promotion Council established under the Digital Market Competition Council of the Cabinet Secretariat, aimed at building a new framework of trust—strengthening the control of data by individuals and corporations without excessive dependence on a particular service, and making the data exchanged and the counterpart verifiable—with its root value placed on “raising Trust by expanding the region that can be verified.” White Paper ver.3.0 [12] presents an architecture whose constituent elements are Verifiable Data, Verifiable Messaging, Verifiable Identity, and the Verifiable Identity community: a set of identities that, under a certain governance, shares information including the community’s policy, community-specific namespaces and identifiers, a list of identities, the origin of trust, and other metadata. A community can take a recursive structure, can be established at will as long as the elements for establishment are shared, and is designed to be able to encompass what is called a Trust Framework. B. The Shinken Model The Shinken model is an abstract model for implementing the Claim Validation model’s validation as an information system (a verifying system) satisfying two requirements: determinism (the verification result for the system’s input settles deterministically) and transparency (when a false positive or false negative arises, its cause can be identified). The logic of verification, however, can contain propositions not decidable
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
from available computational evidence alone—for instance, that the certificate issuer records an authentic claim in the certificate, a matter of the issuer’s operation. The Shinken model resolves this by assuming some propositions true within the logic of verification, defining this introduction of an assumption as “trust”: the whole logic can then be constituted as decidable logic, and because the part into which trust was introduced is made explicit, transparency too is secured and one can identify which part to update when an assumption is broken. ACKNOWLEDGMENT This paper was prepared with the assistance of generative AI. Specifically, Anthropic Claude Opus 4.6, 4.7, 4.8, Fable 5, and OpenAI GPT-5.5 Pro and GPT-5.6 Pro were used, across all sections, to assist with literature research, drafting, translation, and editorial refinement of the manuscript. The authors independently verified all technical claims and bear sole responsibility for all content of this paper. R EFERENCES [1] M. Sporny, T. Thibodeau, Jr., I. Herman, G. Cohen, and M. B. Jones, “Verifiable credentials data model v2.0,” W3C, W3C Recommendation, May 2025, https://www.w3.org/TR/vc- data- model- 2.0/. Accessed: 2026-07-11. [2] ISO/IEC, “ISO/IEC 18013-5:2021. personal identification—ISOcompliant driving licence—part 5: Mobile driving licence (mDL) application,” 2021. [3] O. Terbu, D. Fett, and B. Campbell, “SD-JWT-based verifiable digital credentials (SD-JWT VC),” IETF Internet-Draft, draft-ietf-oauth-sd-jwtvc-17 (work in progress), https://datatracker.ietf.org/doc/draft-ietf-oau th-sd-jwt-vc/, Jul. 2026, accessed: 2026-07-11. [4] T. Lodderstedt, K. Yasuda, T. Looker, and P. Bastian, “OpenID for Verifiable Credential Issuance 1.0,” OpenID Foundation, https://open id.net/specs/openid-4-verifiable-credential-issuance-1 0.html, Sep. 2025, accessed: 2026-07-11. [5] O. Terbu, T. Lodderstedt, K. Yasuda, D. Fett, and J. Heenan, “OpenID for Verifiable Presentations 1.0,” OpenID Foundation, https://openid.net /specs/openid-4-verifiable-presentations-1 0.html, Jul. 2025, accessed: 2026-07-11. [6] European Union, “Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending regulation (EU) no 910/2014 as regards establishing the European Digital Identity Framework (eIDAS 2.0),” OJ L, 2024/1183, 30.4.2024, 2024, eLI: http://data.europa.eu/eli/reg/2024/1183/oj. [7] 1EdTech, “Open badges specification v3.0 (document version 1.4.5),” 1EdTech, https://www.imsglobal.org/spec/ob/v3p0/, Jun. 2026, accessed: 2026-07-11. [8] M. Sporny, D. Longley, M. Sabadello, D. Reed, O. Steele, and C. Allen, “Decentralized identifiers (DIDs) v1.0,” W3C, W3C Recommendation, Jul. 2022, https://www.w3.org/TR/did-1.0/. Accessed: 2026-07-11. [9] N. Fujie, R. Abe, and S. Suzuki, “The current state and challenges of digital credentials for learning records,” IPSJ Magazine, Vol.67, No.5 (invited, web-only), https://www.ipsj.or.jp/dp/contents/publication/66/ DP66-S03.html, May 2026, in Japanese. [10] European Commission, “European learning model (ELM) browser,” ht tps://europa.eu/europass/elm-browser/, accessed: 2026-07-11. [11] European Digital Identity Cooperation Group, “The european digital identity wallet architecture and reference framework (ARF), version 2.9.0,” European Commission, Tech. Rep., May 2026, https://eu- dig ital-identity-wallet.github.io/eudi-doc-architecture-and-reference-fra mework/2.9.0/architecture-and-reference-framework-main/. Accessed: 2026-07-11. [12] Trusted Web Promotion Council, “Trusted web white paper ver.3.0,” https://www.digital.go.jp/en/policies/trust/trustedweb, Nov. 2023, in Japanese; community model in the Implementation volume. Accessed: 2026-07-11. [13] R. Abe, S. Suzuki, and O. Nakamura, “A conceptual model for claim validation based on cryptographically signed data,” IEEE Access, vol. 13, pp. 2723–2735, 2025.
20
[14] R. Abe, R. Mochizuki, S. Suzuki, and O. Nakamura, “Shinken: An adaptive and transparent model for claim verification,” IPSJ Journal, vol. 66, no. 6, pp. 941–952, Jun. 2025, in Japanese. [15] Trust over IP Foundation, “Introduction to trust over ip, version 2.0,” Trust over IP Foundation, https://trustoverip.org/wp- content/uploa ds/Introduction-to-ToIP-V2.0-2021-11-17.pdf, Nov. 2021, accessed: 2026-07-11. [16] M. Davie, D. Gisolfi, D. Hardman, J. Jordan, D. O’Donnell, and D. Reed, “The trust over IP stack,” IEEE Communications Standards Magazine, vol. 3, no. 4, pp. 46–51, Dec. 2019. [17] Open Identity Exchange, “A Guide to Trust Frameworks for Smart Digital ID,” Open Identity Exchange, https://openidentityexchange.o rg/a-guide-to-trust-frameworks-for-smart-digital-id, 2022, accessed: 2026-07-11. [18] SIDI Hub, “Sustainable and Interoperable Digital Identity (SIDI) Hub,” https://sidi-hub.community/, 2023, accessed: 2026-07-11. [19] K. Yasuda, T. Lodderstedt, C. Bormann, and J. Heenan, “OpenID4VC High Assurance Interoperability Profile 1.0,” OpenID Foundation Final Specification, https://openid.net/specs/openid4vc-high-assurance-inter operability-profile-1 0-final.html, Dec. 2025, accessed: 2026-07-11. [20] B. P. Bruegger and P. Lipp, “LIGHTest—a lightweight infrastructure for global heterogeneous trust management,” in Open Identity Summit 2016, ser. LNI, vol. P-264. Gesellschaft für Informatik, 2016, pp. 15–26. [21] M. Kubach and H. Roßnagel, “A lightweight trust management infrastructure for self-sovereign identity,” in Open Identity Summit 2021, ser. LNI, vol. P-312. Gesellschaft für Informatik, 2021, pp. 155–166. [22] I. H. Johnson Jeyakumar and M. Kubach, “A trust implementation model for cross-domain decentralized identity ecosystems: Architecture, use case, and implementation,” Procedia Computer Science, vol. 254, pp. 10–19, 2025. [23] E. Krul, H.-y. Paik, S. Ruj, and S. S. Kanhere, “SoK: Trusting selfsovereign identity,” Proceedings on Privacy Enhancing Technologies, vol. 2024, no. 3, pp. 297–313, 2024. [24] Decentralized Identity Foundation, “Trust establishment 1.0,” DIF Editor’s Draft, https://identity.foundation/trust-establishment/, accessed: 2026-07-11. [25] M. Ebert and S. Curren, “Credential trust establishment 1.0,” DIF Ratified Specification, https://identity.foundation/credential-trust-est ablishment/, accessed: 2026-07-11. [26] Credential Engine, “Credential transparency description language (CTDL),” https://credentialengine.org/credential-transparency/ctdl/, accessed: 2026-07-11. [27] R. Reddy and C. Wallace, “Trust anchor management requirements,” IETF RFC 6024, https://www.rfc-editor.org/info/rfc6024, Oct. 2010, DOI: 10.17487/RFC6024. Accessed: 2026-07-11. [28] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “RFC 4034: Resource records for the DNS security extensions,” IETF, Mar. 2005. [29] R. Hedberg, M. B. Jones, G. De Marco, A. Å. Solberg, J. Bradley, and V. Dzhuvinov, “OpenID Federation 1.1,” OpenID Foundation Final Specification, https://openid.net/specs/openid-federation-1 1-final.html, May 2026, accessed: 2026-07-11. [30] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “RFC 4033: DNS security introduction and requirements,” IETF, Mar. 2005. [31] ——, “RFC 4035: Protocol modifications for the DNS security extensions,” IETF, Mar. 2005. [32] Trust Over IP Foundation, “ToIP trust registry query protocol (TRQP) specification v2.0,” ToIP Approved Deliverable, 2026, DOI: 10.5281/zenodo.18789010. [33] A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design science in information systems research,” MIS Quarterly, vol. 28, no. 1, pp. 75– 105, 2004. [34] R. C. Nickerson, U. Varshney, and J. Muntermann, “A method for taxonomy development and its application in information systems,” European Journal of Information Systems, vol. 22, no. 3, pp. 336–359, 2013. [35] 1EdTech Consortium, “Comprehensive learner record standard, version 2.0,” 1EdTech Final Release, Document Version 1.0.16, https://www.im sglobal.org/spec/clr/v2p0/, Apr. 2024, accessed: 2026-07-11. [36] TrustEd Credential Coalition, “TrustEd credential framework,” 1EdTech Consortium, https://www.1edtech.org/program/trusted-credentials, Mar. 2024, announced as TrustEd Microcredential Framework (2024-03-05), later renamed. Accessed: 2026-07-11. [37] D. Temoshok, J. L. Fenton, Y.-Y. Choong, N. Lefkovitz, A. Regenscheid, R. Galluzzo, and J. P. Richer, “Digital identity guidelines: Authentication and authenticator management,” National Institute of Standards and Technology, NIST Special Publication 800-63B-4, Jul.
SUZUKI ET AL.: A VERIFIER-CENTRIC CONCEPTUAL MODEL FOR DIGITAL CREDENTIAL ECOSYSTEMS
2025, final, 2025-07-31. Supersedes SP 800-63B (2017, updated 2020). https://csrc.nist.gov/pubs/sp/800/63/b/4/final. Accessed: 2026-07-11. [38] The Decentralized Identifier Working Group, “DID methods,” W3C Group Note, https://www.w3.org/TR/2026/NOTE-did-extensions-m ethods-20260710/, Jul. 2026, accessed: 2026-07-11. [39] S. Suzuki and M. Kuriyama, “Originator Profile Framework— Architectural Overview v0.1 (Public Draft),” Originator Profile Collaborative Innovation Partnership, https://docs.originator-profile.org/aov/, Sep. 2025, accessed: 2026-07-11. [40] eduGAIN (GÉANT), “eduGAIN policy framework: SAML profile, version 0.5,” https://technical.edugain.org/doc/eduGAIN-saml-profile.pdf, Apr. 2018, accessed: 2026-07-11. [41] L. Fuglevaag, “eduGAIN piloting use of OpenID federation,” GÉANT CONNECT Online, https://connect.geant.org/2025/10/13/edugain-pilot ing-use-of-openid-federation, Oct. 2025, accessed: 2026-07-11. [42] Credential Engine, “Credential registry,” https://credentialengine.org /credential- transparency/credential- registry/, Mar. 2024, accessed: 2026-07-11. [43] ——, “Credential engine launches issuer identity registry to strengthen trust in credential ecosystems,” https://credentialengine.org/2026/05/27/ credential-engine-launches-issuer-identity-registry-to-strengthen-trust-i n-credential-ecosystems/, May 2026, accessed: 2026-07-11. [44] ——, “Issuer identity registry service governance framework,” https: //credentialengine.org/iir- governance- framework/, May 2026, last updated 2026-05-27. Accessed: 2026-07-11. [45] B. Christianson and W. S. Harbison, “Why isn’t trust transitive?” in Security Protocols Workshop, ser. LNCS, vol. 1189. Springer, 1996, pp. 171–176. [46] S. More, “Trust scheme interoperability: Connecting heterogeneous trust schemes,” in Proc. 18th International Conference on Availability, Reliability and Security (ARES 2023). ACM, 2023.
Shigeya Suzuki (Member, IEEE) is a researcher specializing in computer networks, distributed systems, and software development. He is an active participant in the W3C Decentralized Identifier (DID) and Verifiable Credentials (VC) Working Groups, and a principal architect of the Originator Profile technology. Suzuki received his Ph.D. from the Graduate School of Media and Governance at Keio University, where he currently serves as a Project Professor at the Keio Global Research Institute. He also holds the position of Associate Director at both the Data Architecture Laboratory and the Auto-ID Laboratory within the Keio Research Institute at SFC. Suzuki is affiliated with professional organizations such as ACM, IEEE, IACR, and IPSJ, and serves on the board of the WIDE Project, which was instrumental in introducing the Internet to Japan.
Ryosuke Abe is an Assistant Professor at the Center of Information Infrastructure, Japan Advanced Institute of Science and Technology (JAIST), and a Project Assistant Professor at the Global Research Institute, Keio University. He received the B.A. in policy management, the M.M.G., and the Ph.D. in Media and Governance from Keio University, Kanagawa, Japan, in 2017, 2019, and 2025, respectively. From April 2022 to March 2026, he was a Project Research Associate at the Graduate School of Media and Governance, Keio University; he has held his current position since April 2026. Since 2016, he has been engaged in research on the application and infrastructure of digital certificates and blockchain. He has served on the WIDE Project Board since March 2022. He is a member of ACM and IPSJ.
21