Skip to content

§ DIDAS Glossary

§ Purpose

This glossary establishes a common language for all actors participating in the swiyu trust ecosystem — Switzerland’s open, interoperable infrastructure for digital credentials based on the Federal Act on Electronic Proof of Identity (BGEID). It is intended for public-sector bodies, private organizations, technology providers, and civil society alike.

Clear, shared terminology is a prerequisite for interoperability. When issuers, holders, verifiers, and governance actors use the same concepts in the same way, trust can be established and verified reliably — across cantonal boundaries, sector lines, and organizational contexts.

§ Scope

The glossary covers concepts in the following areas:

  • Digital identity and credentials — the core data structures and roles of the swiyu ecosystem (credentials, verifiable credentials, holders, issuers, verifiers)
  • Decentralized identity infrastructure — identifiers, registries, wallets, and cryptographic foundations
  • Governance — trust frameworks, governance documents, and the regulatory context of the BGEID
  • Alignment with international standards — terms are aligned with the Trust over IP (ToIP) Main Glossary and eSSIF-Lab where applicable. Note that the swiyu credential format is IETF SD-JWT VC as profiled by the Swiss Profile; the W3C Verifiable Credentials Data Model is referenced for terminology only and is not a supported format in the Swiss Profile
  • Applications — Swiss use cases building on the trust infrastructure, such as E-Collecting and the digital product passport

Where a term is fully covered by the ToIP glossary, the DIDAS glossary cross-references it rather than duplicating the definition.

§ About DIDAS

The Digital Identity and Data Sovereignty Association (DIDAS) is a charitable, not-for-profit association under Art. 60 ff. of the Swiss Civil Code, seated in Rotkreuz in the Canton of Zug. Its purpose under the statutes is the establishment and promotion of Switzerland as a leading ecosystem in the development and adoption of technologies, services and products for the protection of privacy and of data sovereignty, which make digital identities together with electronically verifiable data and credentials possible, protect them and render them usable.

The statutes name the orchestrator role: DIDAS takes on the role of ecosystem orchestrator for building, coordinating and sustainably developing a digital trust ecosystem on the basis of the federal trust infrastructure swiyu and beyond. In February 2026 the Federal Office of Justice designated DIDAS a swiyu Orchestrator, consolidating requirements from business, government and society and supporting their implementation in interoperable applications.

This glossary is maintained by the DIDAS community. Contributions and corrections are welcome via the DIDAS Glossary repository on GitHub.

§ Status

Specification Status: Living Document — continuously maintained by the DIDAS community. Changes are proposed via GitHub issues, reviewed by the glossary editors, and published automatically on merge.

Latest published version: didas-swiss.github.io/didas-glossary

Editors:

Participate:

Federation: terms are adopted from or aligned with the Trust over IP Main Glossary per the three-tier rule in GOVERNANCE.md.

Licensing: glossary content CC BY 4.0, software components MIT; third-party notices in NOTICE.md.

§ Terms and Definitions

The following terms are defined for use across the swiyu trust ecosystem. Definitions marked with [[xref: toip-glossary, ...]] are adopted from or aligned with the Trust over IP Main Glossary. Terms are listed alphabetically.

ambition levels (AN1, AN2, AN3, Ambitionsniveau, niveau d'ambition, livello di ambizione, ambition level)

One of three levels of scope defined for the Swiss e-ID trust infrastructure, describing which credentials the infrastructure carries and who may issue them.

AN1 covers the e-ID only.

AN2 adds other authoritative public issuer credentials, from federal, cantonal or municipal authorities.

AN3 is the open ecosystem, where private and public issuers and verifiers meet and private organisations issue on the same infrastructure.

The levels are policy-scope categories originating in Swiss e-ID policy work — they are not runtime trust levels, not assurance levels, and not technical capability tiers. Ambition level describes the scope of an ecosystem; assurance level describes confidence in an identity claim; the abbreviations look alike and are easily confused. As policy targets, the levels can differ from delivered capability: a capability may be delivered for AN1 and AN2 while AN3 remains the stated goal.

Source: Diskussionspapier zum «Zielbild E-ID», Federal Office of Justice, September 2021, chapter 4.2 (consultation page); confirmed as direction by the Federal Council’s decision of 17 December 2021 that the trust infrastructure should carry more than the e-ID and be made available to cantonal authorities and private entities.

Relation to ToIP: no equivalent term. Not to be confused with assurance-level, which is a level of confidence in a claim.

Language equivalents:

[DE] Ambitionsniveau

[FR] niveau d’ambition (proposed — the official French version of the Zielbild paper should decide this)

[IT] livello di ambizione (proposed — the official Italian version should decide this)

Beta-IDs (BetaID, Beta ID, Bêta-ID, Beta-ID)

A pseudo-identity test credential issued in the swiyu Public Beta (sandbox) environment, carrying the same attribute definitions as the coming Swiss e-ID. The Beta-ID is a blueprint of the e-ID credential for building and testing use cases; it is not a proof of identification: its attribute values are chosen by the requester in the request form, and the issuing service does not check them.

Issuance and lifecycle: anyone can obtain a Beta-ID from the Beta Credential Service (BCS), which also verifies and revokes it. After issuance, the BCS deletes all data except the Beta-ID number, which is retained for revocation; the credential data then exists only in the wallet it was issued to. A revocation cannot be reverted — a governance decision, not a technical limitation.

Format and identification: the Beta-ID is issued as an SD-JWT VC per the Swiss Profile. Its credential type (vct) is urn:vct:ch.admin.bcs.betaid (activated 2026-06-25; the previous value betaid-sdjwt remains in use during migration, so verifier queries list both). The credential schema and the concepts behind the attributes are published on the Confederation’s interoperability platform I14Y as dataset urn:vct:ch.admin.bcs.betaid.

Schema — the selectively disclosable attributes, as in the issued credential:

Person attributes: given_name, family_name, birth_date, birth_place, place_of_origin, sex, nationality, personal_administrative_number (AHV/AVS number; a protected field for verification under the trust protocol — test values should match the 756-prefix EAN-13 check-digit pattern), portrait, additional_person_info.

Derived age attributes: age_over_16, age_over_18, age_over_65, age_birth_year.

Document attributes: document_number, issuance_date, expiry_date, issuing_authority, issuing_country. The document_number is not a persistent identifier: it changes with each new Beta-ID, and — like the e-ID — the Beta-ID contains no persistent identifier for private-sector use.

Verification metadata: reference_id_type, reference_id_expiry_date, verification_organization, verification_type.

Technical claims (not selectively disclosable, per the Swiss Profile): vct, iss, cnf, iat, status (Token Status List reference — see status list).

I14Y dataset record (verified against the official I14Y export): the dataset urn:vct:ch.admin.bcs.betaid is published by the Federal Office of Police (fedpol) and has been recorded since 18 February 2025, with the Beta Credential Service listed as its distribution. The record classifies access as restricted and the content as containing particularly sensitive personal data — consistent with the guidance not to enter real personal data when creating a Beta-ID.

Relation to ToIP: no equivalent term. The Beta-ID is a specific credential type of the swiyu ecosystem, an instance of the generic credential concept, not a term ToIP defines.

Does not imply: because all attribute values are self-declared, a cryptographically verified Beta-ID presentation establishes issuer authorship, integrity and status — nothing about the person. Verifier and holder applications must treat Beta-ID data as untrusted user input (including the portrait image), and the Beta-ID must not be used as an identity credential in productive business cases.

Sources: How to use Beta-ID for my business (swiyu cookbook, including the issued-credential example this schema listing is taken from); I14Y dataset urn:vct:ch.admin.bcs.betaid (dataset record verified 2026-09-14 against the official export; the attribute-level structure view on I14Y is access-restricted, consistent with the record’s restricted classification — the swiyu cookbook example is the publicly accessible schema source); vct activation per swiyu release note 2026-06-25.

Language equivalents:

[DE] Beta-ID

[FR] Bêta-ID (spelling per the official French I14Y description)

[IT] Beta-ID

claims (Angabe, Angaben, affirmation, affirmations, affermazione, affermazioni, claim)

An assertion about a subject. A claim is asserted by the issuer of the credential that carries it; whether it is disclosed in a given presentation is decided by the holder; whether the received proofs verify is evaluated technically by the verifier; and whether the claim is accepted for a purpose is a decision of the relying party. None of these four steps implies any of the others, and none of them establishes the factual truth of the assertion.

Relation to ToIP: equivalent with Swiss extension — claim.

swiyu context (Swiss Profile, swiss-profile-vc:1.0.0): credentials are issued in the IETF SD-JWT VC format, in which the claim is the unit of selective disclosure — with defined exceptions. Application claims must be selectively disclosable (the issuer-signed payload “MUST NOT contain one or more permanently disclosed claims”), while specified registered JWT claims are excluded from disclosure: iat, exp and vct_metadata_uri must not be disclosures, whereas sub and the business claim expiry_date — contrary to the upstream standard’s default — must be disclosures (Swiss Profile VC, sections 4.1 and “SD-JWT VC”). It is therefore not the case that every claim in a credential can independently be released or withheld.

swiyu governance context: the Swiss Profile Trust defines protected fields — claims that a verifier needs a specific authorisation to verify, enforced through the trust protocol. The currently listed protected field is the AHV number, carried as personal_administrative_number. Which claims a verifier may request or process is a governance question, separate from the disclosure mechanics above.

Supporting definitions:

W3C VC: An assertion made about a subject.

Language equivalents:

[DE] Angabe (proposed: usage is unsettled between Angabe, Aussage and Attribut, and an editor should rule)

[FR] affirmation (proposed)

[IT] affermazione (proposed)

credentials (Nachweis, Nachweise, attestation, attestations, attestato, attestati, credential)

A set of claims and associated metadata issued by an issuer about one or more subjects. A credential is given to a holder and typically includes a signature or another means by which its authorship and integrity can be checked. A credential may be a physical credential or a digital credential; a digital credential whose authorship and integrity can be cryptographically verified is a verifiable credential.

Relation to ToIP: equivalent with Swiss extension — credential. The upstream definition describes a credential as a “container of claims”; this glossary prefers “a set of claims and associated metadata” as the more exact formulation, without changing the concept.

swiyu context (Swiss Profile, swiss-profile-vc:1.0.0): credentials are issued as verifiable credentials in the IETF SD-JWT VC format (Swiss Profile VC). The credential format profiles “W3C VCDM” and “ISO mdoc” are NOT SUPPORTED (Swiss Profile Issuance §3.3.1). Under the BGEID, the legal term for a credential issued on the trust infrastructure is elektronischer Nachweis (electronic credential); the e-ID is one such credential among others.

Does not imply: possession of a credential establishes neither the factual truth of its claims, nor that the issuer was authorised to issue it, nor that any relying party will accept it. Those are separate properties, established (or not) by separate mechanisms.

Supporting definitions:

[eSSIF-Lab]: data, representing a set of assertions (claims, statements), authored and signed by, or on behalf of, a specific party.

[W3C VC]: A set of one or more claims made by an issuer.

Language equivalents:

[DE] Nachweis, Beglaubigung — im BGEID-Kontext auch: elektronischer Nachweis

[FR] attestation — dans le contexte de la LSIE: attestation électronique

[IT] attestato — nel contesto della LSIE: attestato elettronico

Digital Identity and Data Sovereignty Association (DIDAS)

The association «Digital Identity and Data Sovereignty», DIDAS for short. A charitable, not-for-profit association under Art. 60 ff. of the Swiss Civil Code, seated in Rotkreuz in the Canton of Zug, politically and confessionally neutral.

Its purpose under the statutes is the establishment and promotion of Switzerland as a leading ecosystem in the development and adoption of technologies, services and products for the protection of privacy and of data sovereignty, which make digital identities together with electronically verifiable data and credentials possible, protect them and render them usable. DIDAS understands this to mean in particular authentic, machine-verifiable data and credentials that enable digital self-determination, resilience and sovereign control over one’s own information.

The statutes name the orchestrator role: DIDAS takes on the role of ecosystem orchestrator for building, coordinating and sustainably developing a digital trust ecosystem on the basis of the federal trust infrastructure swiyu and beyond. In February 2026 the Federal Office of Justice designated DIDAS a swiyu Orchestrator.

The statutes commit DIDAS further to supporting Swiss organisations in building a multi-stakeholder ecosystem, to operating technology components including nodes in networks, to bringing together organisations of every kind from start-ups to public authorities and to working with educational institutions on curricula and research. The association is politically neutral and technically independent. It may publish expert opinions and respond to government consultations.

DIDAS maintains this glossary.

Source: Statuten des Vereins «Digital Identity and Data Sovereignty», version 2.0 of 10 April 2026, §1 to §3, on the basis of version 1.0 of 9 September 2020. Published with the regulations at didas.swiss.

Relation to ToIP: no equivalent term. DIDAS is an organisation rather than a concept.

DPP (digitaler Produktpass, passeport numérique de produit, passaporto digitale del prodotto, digital product passport)

A structured collection of product-related data with pre-defined scope and agreed data management and access rights conveyed through a unique identifier, accessible via electronic means through a data carrier. The intended scope of the DPP is information related to usage, maintenance, sustainability, circularity, value retention for re-use, remanufacturing, and recycling.

Source: CIRPASS — DPP in a nutshell.

Relation to ToIP: no equivalent term.

Language equivalents:

[DE] digitaler Produktpass

[FR] passeport numérique de produit

[IT] passaporto digitale del prodotto

ecosystems (Ökosystem, Ökosysteme, écosystème, ecosistema, ecosystem)

In the digital-trust sense used throughout this glossary: a set of independent actors, technical components, governance arrangements and shared protocols that interact to issue, hold, present, verify and rely on digital credentials or related trust information.

In the general business sense: a network of organizations that enables its participants to tap into the resources, capabilities, products and services of their partners (adapted from Mark Greeven, IMD). A digital trust ecosystem is not necessarily centred on one core product or service.

Relation to ToIP: equivalent with Swiss extension — digital-trust-ecosystem. The swiyu ecosystem is a digital trust ecosystem in the ToIP sense; the broader upstream concept is digital-ecosystem.

swiyu context: “the ecosystem” refers to the swiyu trust ecosystem: the totality of actors — issuers, verifiers, holders, orchestrators, governing authorities, service providers — that build on the trust infrastructure established under the BGEID and act in one or more trust domains, interacting through common protocols under shared governance.

Language equivalents:

[DE] Ökosystem

[FR] écosystème

[IT] ecosistema

elektronische Unterschriftensammlung (récolte électronique de signatures, raccolta elettronica delle firme, E-Collecting)

The electronic collection of signatures for popular initiatives and referenda in Switzerland, as a digital counterpart to the paper-based signature collection governed by the Federal Act on Political Rights.

Scope note: whether an electronically collected signature is legally valid, and under which conditions, is determined by the applicable legislation and any pilot ordinances — not by the collection technology. Architectures under discussion build on the trust infrastructure and the e-ID for signer identification; such architecture statements describe proposals, not enacted law, unless a legal source is cited.

Relation to ToIP: no equivalent term.

Language equivalents:

[DE] E-Collecting, elektronische Unterschriftensammlung

[FR] récolte électronique de signatures

[IT] raccolta elettronica delle firme

Epidemiology Biostatistics and Prevention Institute (Institut für Epidemiologie Biostatistik und Prävention, EBPI)

The Epidemiology, Biostatistics and Prevention Institute (EBPI) of the University of Zurich — in German: Institut für Epidemiologie, Biostatistik und Prävention. A university institute working in four interconnected areas: research, research methods, services, and teaching & training, with the stated mission of improving people’s health by better understanding what keeps people healthy and what makes them ill.

The cantonal programme Prävention und Gesundheitsförderung Kanton Zürich operates on behalf of the Zurich Health Directorate and is structurally affiliated with the EBPI.

In the DIDAS digital-health context: the EBPI is a domain actor in the health ecosystem in which credential-based use cases (such as immunisation records referencing the International Patient Summary vocabulary) are discussed. Any specific role of the EBPI in a swiyu use case is defined by that use case’s own documentation, not by this glossary.

Relation to ToIP: no equivalent term. The EBPI is an organisation rather than a concept.

Source: EBPI — About us, University of Zurich; Prävention und Gesundheitsförderung Kanton Zürich — Das EBPI.

Language equivalents:

[DE] Institut für Epidemiologie, Biostatistik und Prävention (EBPI)

[FR] EBPI (le nom de l’institut n’est pas traduit officiellement)

[IT] EBPI (il nome dell’istituto non è tradotto ufficialmente)

gouvernance (governance)

The system by which an organisation is controlled and operates, and the mechanisms by which it, and its people, are held to account.

Source: Chartered Governance Institute of Australia.

Relation to ToIP: equivalent with Swiss extension — governance.

[DIDAS — ecosystem governance]: the operational rules of a digital trust ecosystem: who holds which decision rights and responsibilities; who is accountable to whom; who may participate in which role and under which requirements; how authorisations are granted, published and withdrawn; how policies evolve; and how non-compliance is detected and handled. In the swiyu ecosystem, parts of these rules become technically checkable through the trust protocol; a governing authority exercises them for a trust domain.

Supporting definitions:

[Chartered Governance Institute UK & Ireland]: Governance is a system that provides a framework for managing organisations. It identifies who can make decisions, who has the authority to act on behalf of the organisation and who is accountable for how an organisation and its people behave and perform. Governance enables the management team and the board to run organisations legally, ethically, sustainably, and successfully, for the benefit of stakeholders, including shareholders, staff, clients and customers, and for the good of wider society.

[Corporate governance]: the framework of rules, relationships, systems and processes within and by which authority is exercised and controlled in corporations. It encompasses the mechanisms by which companies, and those in control, are held to account.

Language equivalents:

[DE] Governance

[FR] gouvernance

[IT] governance

governing authorities (autorité de gouvernance, autorità di governance, governing authority)

The governance body of a digital trust ecosystem that is responsible for its governance framework.

Relation to ToIP: equivalent with Swiss extension — governing-authority.

swiyu context: the competent body that makes governance decisions for a trust domain. Such decisions can include which issuers may issue particular credential types, which verifiers may request protected claims, which use cases require authorisation, which fields are protected, and which participation requirements apply.

Under the trust protocol, the governing authority publishes, or causes the publication of, the applicable trust statement using the statement type defined for that purpose, such as piaTS for protected issuance or pvaTS for protected verification. trust markers are subsequently derived by actors evaluating those statements; the governing authority does not issue the marker.

Language equivalents:

[DE] Governing Authority (der englische Begriff wird auch im Deutschen verwendet)

[FR] autorité de gouvernance

[IT] autorità di governance

IPS (patient summary, International Patient Summary)

An electronic health record extract containing essential healthcare information about a subject of care. This is the definition of the underlying standards: the IPS document is composed from the IPS dataset, a minimal, non-exhaustive set of data elements that is specialty-agnostic and condition-independent, yet clinically relevant. The dataset is designed to support the use-case scenario of unplanned, cross-border care, but is not limited to it.

Standards lineage, in order: EN 17269:2019 “Health informatics — The International Patient Summary” (CEN/TC 251) defines the dataset; it was taken over internationally as ISO 27269:2021. Representation is specified separately from the dataset: the HL7 FHIR International Patient Summary Implementation Guide (Edition 2) defines the FHIR representation, and an HL7 CDA IPS guide exists for CDA. IHE profiles the exchange. Dataset (what), representation (how) and exchange (transport) are three separate layers and must not be conflated.

In the DIDAS digital-health context: the IPS is the standards anchor for what “essential health data about a person” means when health credentials are discussed for the swiyu ecosystem — a shared vocabulary between the health domain (HL7/ISO) and the credential domain (this glossary). Whether and how IPS content is carried in a swiyu credential is a design decision of the respective use case, not a property of either standard.

Does not imply: an IPS is a data structure, not a credential. Conformance to the IPS dataset establishes neither the clinical correctness of its content, nor consent to share it, nor any authorisation of a party to request it — those are governed by the applicable health legislation and, where credentials are used, by the mechanisms this glossary describes under trust protocol and claim.

Relation to ToIP: no equivalent term. The IPS is a health-informatics standard, not a digital-trust concept; the nearest ToIP notion is the generic claim content a credential could carry.

Sources: ISO 27269:2021 (Health informatics — International patient summary); EN 17269:2019 (CEN/TC 251); HL7 FHIR IPS Implementation Guide; IHE IPS profile overview; international-patient-summary.net.

Language equivalents:

[DE] International Patient Summary (der englische Begriff wird verwendet; wörtlich: internationale Patientenkurzakte — proposed, an editor should rule)

[FR] International Patient Summary (terme anglais en usage; littéralement: résumé international du patient — proposed)

[IT] International Patient Summary (termine inglese in uso; letteralmente: sintesi internazionale del paziente — proposed)

issuers (Aussteller, Ausstellerin, émetteur, émettrice, emittente, emittenti, issuer)

The role an actor performs when it signs a set of claims as a credential and provides that credential to a holder.

Relation to ToIP: equivalent with Swiss extension — issuer.

swiyu protocol context: before issuing, an issuer registers a did:webvh identifier (version 1.0) in the Base Registry and publishes the verification material for the keys used to sign its credentials (Swiss Profile Anchor). This publication provides the information a verifier needs for cryptographic signature verification — no more: it identifies the signing key, not the organisation’s legitimacy. Issuance itself follows OpenID4VCI 1.0 as profiled by Swiss Profile Issuance.

The following are separate properties and none follows from another: that a credential’s signature verifies (cryptography); who the issuer is (identifier registration); whether the applicable trust statements about the issuer are valid; whether the trust protocol evaluation derives viTM for the issuer in this interaction; whether that evaluation derives the governed use case authorization marker (gucaTM) for the issuer and credential type in this interaction; what the credential’s current status is (status list); and whether a relying party accepts credentials from this issuer (acceptance policy).

swiyu governance context: for governed use cases, the governing actor publishes the applicable authorisation statement for the issuer and the credential type. An actor that validates the applicable statements can derive the corresponding trust markers for its own interaction under the trust protocol; the Swiss Profile Trust defines the normative force of each marker. A trust marker is an evaluation result for an interaction, not a persistent attribute of the issuer.

Language equivalents:

[DE] Aussteller, Ausstellerin

[FR] émetteur, émettrice

[IT] emittente

Minute of Agreement

A legal procedure available in Scotland: a document drawn up between two or more parties in the presence of their solicitors, without the need for formal court action. In its usual format, it contains numbered paragraphs that record formal but legally binding provisions by which each party has agreed to be bound. If it contains any provision which is enforceable in Scotland, it can be registered in other parts of the United Kingdom for recognition and enforcement. A Minute of Agreement can also be registered for recognition and enforcement in EU Member States or non-EU European Free Trade Association (EFTA) countries. A separate arrangement applies to Gibraltar. A foreign equivalent may also be known as an Authentic Instrument.

Source: Wikipedia.

Relation to ToIP: no equivalent term.

protocols (Protokoll, protocole, protocollo, protocol)

An agreement that governs the procedures used to exchange information between cooperating entities.

Source: Oxford Reference.

Etymology: late Middle English, originally denoting the original Minute of Agreement, forming the legal authority for future dealings relating to it (Oxford Languages).

For the named swiyu artefact that governs authorisation in the trust ecosystem, see trust protocol — a term of its own, not a species of this generic definition.

[ToIP — Trust Spanning Protocol (TSP)]: quoted as upstream ToIP material; the claims in this paragraph are ToIP’s, not assertions of this glossary: “facilitates secure communication between endpoints with potentially different identifier types, using message-based exchanges. As long as these endpoints use identifiers based on public key cryptography (PKC) with a verifiable trust root, TSP ensures their messages are authentic and, if optionally chosen, confidential. Moreover, it presents various privacy protection measures against metadata-based correlation exploitations. These attributes of TSP together allow endpoints to form authentic relationships rooted in their respective verifiable identifiers (VIDs), viewing TSP messages as virtual channels for trustworthy communication.”

Relation to ToIP: no equivalent term for the generic concept. ToIP defines particular protocols and the layering around them, such as trust-spanning-protocol and protocol-stack.

Language equivalents:

[DE] Protokoll

[FR] protocole

[IT] protocollo

selektive Bekanntgabe (divulgation sélective, divulgazione selettiva, selective disclosure)

Selective disclosure allows selected claims from a credential to be included in a presentation while other selectively disclosable claim values are omitted.

Four separate points, none of which follows from the definition above: the scope of a request is defined by the presentation request; whether a verifier is authorised to request a claim is a governance question, not a property of the disclosure mechanism; omitted claim values are not included in the presentation — no stronger secrecy property is implied; and which claims are selectively disclosable at all is determined by the credential format profile at issuance time.

Relation to ToIP: no equivalent term; defined locally. The nearest upstream concepts are presentation and verifiable-credential, and neither names this property.

swiyu context (Swiss Profile, swiss-profile-vc:1.0.0): credentials use SD-JWT (RFC 9901) as profiled by the Swiss Profile VC: the issuer commits to each selectively disclosable claim separately at issuance, and the holder chooses at presentation time which disclosures to include. Application claims must be selectively disclosable, while specified registered JWT claims (such as iat and exp) are excluded from disclosure — see claim for the exact rules. A verifier can check every disclosed claim against the issuer’s signature.

Does not imply: selective disclosure does not by itself establish anonymity, unlinkability, verifier authorisation or legal data-minimisation compliance. In particular, it does not prevent two verifiers, or one verifier across two presentations, from recognising that they saw the same holder — unlinkability is a separate property with separate mechanisms.

Language equivalents:

[DE] selektive Bekanntgabe (proposed: selektive Offenlegung is also in use and an editor should rule)

[FR] divulgation sélective

[IT] divulgazione selettiva

status lists (Statusliste, Statuslisten, liste de statut, elenco di stato, status list)

A published data structure carrying status information for referenced credentials: each referenced credential carries an index that locates its entry, and the entry holds a status value for that credential. A status value is one input to credential acceptance, not a statement of overall validity: acceptance may additionally depend on signature verification, temporal validity, trust information, holder binding, and the relying party’s policy and business rules.

Relation to ToIP: no equivalent term. The nearest upstream concept is revocation — the event in which an issuer stops attesting to a credential it has issued; a status list is one mechanism through which the consequence of such an event can be checked by a verifier.

swiyu context (Swiss Profile, swiss-profile-vc:1.0.0): status lists follow the IETF Token Status List specification (draft-ietf-oauth-status-list-20) as profiled by the Swiss Profile VC: the status list token must be signed by the same entity as the referenced credential (a different key is permitted), and the status provider MUST be the registry provided by FOITT — the profile states this requirement as preventing observability of issuers.

Privacy properties, stated precisely: the status-list representation does not encode credential claim values or subject identifiers. Retrieving a published status list does not require the verifier to query the issuer for the specific credential being checked; this does not imply the absence of all other correlation channels.

Language equivalents:

[DE] Statusliste

[FR] liste de statut (proposed)

[IT] elenco di stato (proposed)

trust domains (trust space, trust spaces, Vertrauensraum, Vertrauensräume, espace de confiance, spazio di fiducia, trust domain)

A governance-defined scope in which actors apply a common set of rules for evaluating identifiers, roles, credential types, authorisations, trust information and acceptance policies. Multiple trust domains can coexist on the same trust infrastructure — sectoral, federal or international — each with its own governance, its own acceptance rules and, where applicable, its own trust statements.

A trust domain is to be distinguished from the trust infrastructure (the federal technical and organisational basis) and from the ecosystem (the totality of actors building on it). A trust domain becomes concretely visible where a governing authority publishes via the trust infrastructure which actors may issue which credential types.

DIDAS governance guidance (community proposal, not asserted by a swiyu specification): complementary registries of a trust domain’s own are possible, provided they remain connected to the Confederation’s trust infrastructure; the governing-authority role and registry operation lie with the respectively competent bodies.

Relation to ToIP: related but not equivalent — trust-domain. The upstream definition is technology-oriented (a security domain defined by an architecture, security policy or trust community); this entry is the Swiss governance definition. Where the distinction matters, “swiyu trust domain” may be used. Nearby upstream: trust-context and trust-community.

Language equivalents:

[DE] Vertrauensraum

[FR] espace de confiance

[IT] spazio di fiducia

trust markers (Vertrauensmerkmal, Vertrauensmerkmale, marqueur de confiance, marcatore di fiducia, trust marker)

An evaluation result derived by an actor, for a specific trust relationship in an ongoing interaction, from applicable valid trust statements and the validation rules of the trust protocol. The applicable statement is issued or published under the trust protocol; the evaluating actor derives the marker.

A trust marker is not a credential issued to an actor, not a persistent attribute stored against a DID or held by an organisation, not a registry entry, and not an authorisation document. Two evaluations may produce different marker sets where the applicable statements, the interaction context or the validation inputs differ. The evaluating actor subsequently applies the applicable Swiss Profile requirements and its own policy to those markers when deciding how to proceed.

The sequence is: applicable statements → protocol-defined validation → trust markers for the interaction → applicable Swiss Profile requirements and local policy → decision. Policy determines which markers are required and how an actor acts on the result; it does not alter the protocol-defined conditions from which the markers are derived.

Relation to ToIP: no equivalent term. The nearest upstream concept is trust-decision — the decision a party makes about whether to engage in an interaction. A marker is an input to such a decision rather than the decision itself: deriving a marker does not settle whether to proceed.

swiyu context (Trust Protocol 2.0, draft): the protocol describes five markers. viTM, Verified Identity, where the identity of the actor is validated by the governing actor. caTM, Compliant Actor, where the actor was not identified as a non-compliant actor in the ecosystem. tvTM, Transparent Verification, where the type of verification is published for third-party review, not the individual verification. gucTM, Governed use case, where the issuance or verification is identified as protected by a governing actor, so an authorisation is needed to proceed. gucaTM, Governed use case authorization, where the applicable authorisation for that use case has been established for the actor in this evaluation.

swiyu context — normative force (Swiss Profile Trust, version 1.0, draft): an ecosystem actor MUST validate the trust relationship; an actor MUST decline a trust relationship for which the evaluation derives gucTM without gucaTM; an actor SHOULD decline one without viTM; and the wallet MAY decline, during verification, one without caTM or without tvTM.

Does not imply: a derived marker indicates only the property defined for that marker and does not establish additional properties. viTM does not establish authorisation for a governed use case. gucaTM does not establish the factual truth of credential claims. A marker does not by itself oblige a relying party to accept a transaction unless the applicable specification or policy requires that result.

On implementation objects: a verifier’s API response may carry a field named for a marker. Such a field is the result of that verifier’s evaluation for that interaction, and is not a property of the counterparty that can be cached and reused as one.

Language equivalents:

[DE] Vertrauensmerkmal — in der Praxis wird meist Trust Marker verwendet

[FR] marqueur de confiance

[IT] marcatore di fiducia

trust protocols (Vertrauensprotokoll, protocole de confiance, protocollo di fiducia, trust protocol)

The rules and mechanisms by which actors in a digital trust ecosystem publish, provision, retrieve, validate and evaluate trust and governance statements, and derive trust markers for an ongoing interaction.

Authorisation is one application of the protocol, not its definition. Statements evaluated under a trust protocol can also express validated identity, non-compliance information, verification transparency, and whether an issuance or verification is governed.

A trust protocol answers a different question from the protocols that carry credentials. OpenID4VCI and OpenID4VP are protocols for credential issuance and presentation respectively; the trust protocol is the mechanism for publishing and evaluating ecosystem trust information, governed-use-case information and authorisations.

Relation to ToIP: no equivalent term. The nearest concept is trust-spanning-protocol, but it differs because TSP addresses message transport between endpoints (authenticity and optional confidentiality of the channel), whereas the trust protocol addresses authorisation and trust information about the parties. For the generic concept, see protocol.

swiyu context — specification (Trust Protocol 2.0, draft, introduced by change dossier CD-006): the protocol is based on JWTs signed by a root trust anchor. Three concepts must be kept apart, and they sit at different layers. trust statements are the signed artefacts published under the protocol: trust statements about a single subject, trust list statements applying to several subjects, and public statements such as the vqPS. Trust evaluation is the validation of the applicable statements for a particular relationship or interaction. trust markers are the result the evaluating actor derives from valid applicable statements and the protocol’s rules. A statement that fails validation MUST NOT contribute to setting the corresponding marker.

Authorisation is not a separate artefact class. It is represented through specific statement types, including piaTS for protected issuance and pvaTS for protected verification, and is reflected in the resulting trust marker when the required validations succeed.

The protocol describes five trust markers:

viTM (Verified Identity Trust Marker) — the identity of the actor is validated by the governing actor.

caTM (Compliant Actor Trust Marker) — the actor was not identified as a non-compliant actor in the ecosystem.

tvTM (Transparent Verification Trust Marker) — the type of verification being performed is published for third-party review; not the individual verification, only its published type.

gucTM (Governed use case Trust Marker) — the issuance or verification is identified as protected by a governing actor; a valid authorisation is needed to proceed.

gucaTM (Governed use case authorization Trust Marker) — the governing actor’s authorisation for the issuer or verifier to process this use case has been established in this evaluation.

swiyu context — normative force (Swiss Profile Trust, version 1.0, draft): an ecosystem actor MUST validate the trust relationship; an actor MUST decline a trust relationship for which the evaluation derives gucTM without gucaTM; an actor SHOULD decline one for which viTM is not derived; and the wallet MAY decline, during verification, where caTM or tvTM is not derived. The Swiss Profile Trust also defines the environment specifics: root trust anchors, the swiyu Trust Registry, and the protected fields (currently the AHV number, personal_administrative_number).

Does not imply: a derived trust marker indicates only the property defined for that marker and does not establish additional properties. In particular, viTM does not establish authorisation for a governed use case, gucaTM does not establish the factual truth of credential claims, and no marker by itself obliges a relying party to accept a presentation.

Language equivalents:

[DE] Vertrauensprotokoll — in der Praxis wird auch im Deutschen meist Trust Protocol verwendet

[FR] protocole de confiance

[IT] protocollo di fiducia

trust statements (Vertrauensaussage, Vertrauensaussagen, déclaration de confiance, dichiarazione di fiducia, trust statement)

A signed artefact issued under a trust protocol that expresses trust or governance information about one or more actors or interactions and can be validated as an input to trust evaluation. A statement may concern a specific actor identifier and may be provisioned by that actor through the protocol, for example in issuer metadata or an authorization request. It is not a credential held by the subject. Being the subject or carrier of a statement does not itself establish a trust marker or determine whether an interaction may proceed. An evaluating actor validates the applicable statement and applies the trust protocol rules to derive the relevant marker.

Relation to ToIP: related but not equivalent — attestation, whose definition is the issue of a statement, based on a decision, that fulfilment of specified requirements has been demonstrated, usually carrying a digital signature. The concepts overlap in shape. They differ in scope: an attestation is any such signed statement, while a trust statement is the specific artefact class a trust protocol defines, publishes and evaluates for evaluating trust and governance conditions relevant to an interaction. For the list-shaped case see also trust-list.

swiyu context (Trust Protocol 2.0, draft, introduced by change dossier CD-006): statements are JWTs signed by a root trust anchor, and the protocol distinguishes three shapes. Trust statements concern a single subject and follow a verification process. Trust list statements apply to several subjects at once. Public statements are published for third-party review rather than about a counterparty; the Verification Query Public Statement (vqPS), in which a verifier publishes the query it will send and the purpose it will send it for, is one. The specification defines statement types including idTS (Identity Trust Statement), vqPS (Verification Query Public Statement), pvaTS (Protected Verification Authorization Trust Statement), piaTS (Protected Issuance Authorization Trust Statement), piTLS (Protected Issuance Trust List Statement), and ncTLS (Non-Compliance Trust List Statement).

Where statements are published and retrieved: the Swiss Profile Trust names the swiyu Trust Registry as the component through which applicable statements are published and served, and names the root trust anchors. The registry is infrastructure for publication and retrieval; it does not decide what an actor may do.

Does not imply: a valid statement does not by itself establish that an interaction may proceed, oblige a relying party to accept the interaction, or establish the factual truth of information outside the statement’s defined semantics. A statement that fails validation MUST NOT contribute to setting the corresponding trust marker.

Language equivalents:

[DE] Vertrauensaussage — in der Praxis wird meist Trust Statement verwendet

[FR] déclaration de confiance

[IT] dichiarazione di fiducia

verifiable credentials (VC, VCs, verifizierbarer Nachweis, attestation vérifiable, attestato verificabile, verifiable credential)

A tamper-evident credential whose authorship by an issuer can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, whose integrity can also be cryptographically verified. The claims in a credential can be about different subjects.

Relation to ToIP: related but not equivalent — verifiable-credential. The upstream definition ties the term to the W3C Verifiable Credentials Data Model specifically. This glossary uses the term format-neutrally for the concept, because the Swiss Profile instantiates it with a different format (IETF SD-JWT VC) and does not support W3C VCDM.

swiyu context (Swiss Profile, swiss-profile-vc:1.0.0): verifiable credentials are issued, held, presented and verified using the IETF SD-JWT VC format, per the versions referenced by the current Swiss Profile VC: SD-JWT (RFC 9901), SD-JWT VC (draft-ietf-oauth-sd-jwt-vc-15) and Token Status List (draft-ietf-oauth-status-list-20). Holder/key binding uses the cnf claim with the SD-JWT+KB mechanism where the issuer enables it. The W3C VCDM and ISO mdoc credential format profiles are NOT SUPPORTED (Swiss Profile Issuance §3.3.1).

Does not imply: cryptographic verifiability establishes issuer authorship and integrity of the presented data. It establishes neither the factual truth of the claims, nor the issuer’s authorisation to issue them, nor business acceptance by a relying party, nor legal validity under Swiss law. Credential status is a separate check against the referenced status list entry.

Supporting definitions:

[W3C VC]: A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified.

Language equivalents:

[DE] verifizierbarer Nachweis — im BGEID-Kontext: elektronischer Nachweis

[FR] attestation vérifiable — dans le contexte de la LSIE: attestation électronique

[IT] attestato verificabile — nel contesto della LSIE: attestato elettronico

verifiers (Verifikator, Verifikatorin, vérificateur, vérificatrice, verificatore, verificatrice, verifier)

The technical role an actor performs when it requests a presentation of claims from a holder and evaluates the returned proofs. Distinct from the relying party, the business or legal role that decides whether to accept the presented claims for a purpose. One organisation often performs both roles, but the roles remain distinct: proof evaluation is a technical act; acceptance is a business and legal decision.

What proof evaluation can establish, each as a separate check: integrity and issuer authorship of the presented credential (signature verification against the issuer’s published key); integrity of the presentation; holder/key binding, where the credential carries a cnf key and the presentation includes a key-binding proof; and credential status, where the verifier reads the referenced status list entry. What it does not establish: the factual truth of the claims, the issuer’s authorisation to issue them, the verifier’s own authorisation to request them, any legal entitlement, or acceptance by the relying party.

Relation to ToIP: equivalent with Swiss extension — verifier.

swiyu protocol context (Swiss Profile Verification, version 1.0): a verifier sends verification requests as JWT-Secured Authorization Requests (JAR) under OpenID4VP 1.0, names the claims it seeks in a DCQL query, and receives the response in direct_post.jwt mode. The presentation request identifies the claims sought by the verifier; separate governance rules and wallet policy may restrict which claims the verifier is authorised to request or process — see the protected fields in claim and the trust markers in trust protocol.

swiyu governance context: trust and governance information about a verifier can be evaluated by the wallet before disclosure. Under the trust protocol the wallet retrieves the applicable trust statements about the verifier, validates them, derives the trust markers for that interaction, and can display them; it then applies its own policy, and the Swiss Profile Trust attaches normative force to specific markers. The resulting trust marker is an evaluation result for that interaction, not a persistent property of the verifier.

Language equivalents:

[DE] Verifikator, Verifikatorin

[FR] vérificateur, vérificatrice

[IT] verificatore, verificatrice

Vertrauensinfrastruktur (infrastructure de confiance, infrastruttura di fiducia, trust infrastructure)

The federal technical and organisational infrastructure that supports credential issuance, presentation and verification through common identifier, registry, status, trust and protocol components. In the swiyu ecosystem these components include the Base Registry (identifiers and published keys, Swiss Profile Anchor), the status registry (status list publication), and the swiyu Trust Registry with its root trust anchors (Swiss Profile Trust).

Credentials themselves are issued, held, presented and verified by the ecosystem’s actors: they are held in wallet components, not stored centrally by the trust infrastructure. The infrastructure publishes the identifiers, keys, status information and trust information those actors rely on.

To be distinguished from the trust domain (a governance-defined scope of common rule application built on the infrastructure) and from the ecosystem (the totality of actors building on it). The trust infrastructure is the common foundation of all trust domains.

Relation to ToIP: no equivalent term. The nearest concept is digital-trust-utility, a supporting service at Layer 1 of the ToIP stack, but it differs because the swiyu trust infrastructure is a specific, federally operated instance with a legal basis (BGEID), not a general utility category.

Language equivalents:

[DE] Vertrauensinfrastruktur

[FR] infrastructure de confiance

[IT] infrastruttura di fiducia

wallets (Wallet, portefeuille, portefeuilles, portafoglio, portafogli, wallet)

A user agent, optionally including a hardware component, that stores and processes cryptographic keys and credentials and enables its controller to perform cryptographically verifiable operations — in particular to receive credentials at issuance and to release claims from them in presentations. Wallets exist in different models: personal and organisational, custodial and non-custodial; the holder and the wallet operator need not be the same party.

Relation to ToIP: equivalent with Swiss extension — digital-wallet. The ToIP Main Glossary files wallet as a pointer to digital wallet and explicitly covers custodial and non-custodial, personal and enterprise forms; this glossary keeps that breadth.

swiyu context: the swiyu wallet is one specific instance — a non-custodial personal wallet application published by the Confederation, holding the e-ID alongside credentials from other issuers, with keys held on the holder’s device. In issuance it follows Swiss Profile Issuance (OpenID4VCI 1.0, DPoP; hardware-bound key attestation where a credential requires it), in presentation Swiss Profile Verification (OpenID4VP 1.0), including the wallet-side validation duties the profiles assign to it — for example verifying that a verifier’s client_id belongs to the entity that signed the request before including it in the key-binding JWT (Swiss Profile VC, “Validation of aud claim”). Statements about other wallet models in the swiyu ecosystem (organisational wallets, backup and recovery arrangements) belong to the respective specifications and are not asserted here.

In an interactive presentation flow, the wallet may require the holder to approve or decline the requested presentation, and under the trust protocol it can show the verifier’s trust markers before the holder decides. This user interaction must not automatically be interpreted as legal, medical or research consent — whether a disclosure approval also constitutes consent in a legal sense is determined by the applicable law, not by the protocol flow.

Language equivalents:

[DE] Wallet (der englische Begriff wird auch im Deutschen verwendet; die Anwendung des Bundes heisst swiyu Wallet)

[FR] portefeuille

[IT] portafoglio

§ Contributing

This glossary is a living document maintained by the DIDAS community. New terms, corrections, and improvements can be proposed by opening an issue or pull request in the DIDAS Glossary repository.

§ Authoring conventions

Terms are defined using the spec-up-t toolchain. Every term file lives in spec/terms-definitions/ and follows one of three patterns:

Tier 1 — Adopt a ToIP definition (preferred for common SSI/VC terms)

Use [[tref:]] as the first and only line. The full definition is fetched from the Trust over IP Main Glossary at build time and embedded in the rendered output. Include all language aliases so the term is reachable via [[ref:]] in any of the four working languages (EN/DE/FR/IT).

[[tref: toip-glossary, holder, Inhaber, Inhaberin, détenteur, détentrice, titolare]]

Tier 2 — Extend a ToIP definition (Swiss/swiyu-specific additions)

Define the term locally with [[def:]], add the Swiss or swiyu-specific context, and close with [[xref: toip-glossary, term]] as a “See also” link.

[[def: credential, credentials, Nachweis, Nachweise, attestation, attestato]]

~ <DIDAS/swiyu-specific definition body>

~ See also: [[xref: toip-glossary, credential]]

Tier 3 — Own term (Swiss law, swiyu-specific, or no ToIP equivalent)

Define fully locally. Cite the legal source (BGEID article, ZertES, etc.) where applicable. Map to the nearest ToIP concept via [[xref:]] if one exists.

[[def: Aussage, Behauptung, assertion, affirmation, affermazione]]

~ <Swiss legal / DIDAS definition>

~ Nearest ToIP equivalent: [[xref: toip-glossary, claim]]

§ Multilingual aliases

Every term file must include aliases for all four working languages as part of the [[def:]] or [[tref:]] block. The alias order is: EN primary, DE, FR, IT (or DE primary, EN, FR, IT for terms originating in Swiss law). The first alias after the canonical term name becomes the display label in the rendered glossary.

Add a Language equivalents: section in the definition body for human-readable cross-language notes:

~ Language equivalents:
~ [DE] **Nachweis**, **Beglaubigung**
~ [FR] **attestation**
~ [IT] **attestato**

§ The ToIP relation line

Every term file carries one line stating its relationship to the ToIP Main Glossary, placed after the definition body so a reader always finds it in the same position. It takes one of three shapes, and the wording carries the tier judgement rather than leaving a reader to infer it.

Where the upstream term means the same thing and this glossary adds Swiss or swiyu context:

~ Relation to ToIP: equivalent with Swiss extension — [[xref: toip-glossary, credential]]

Where an upstream term is adjacent and the concepts differ:

~ Relation to ToIP: related but not equivalent — [[xref: toip-glossary, trust-domain]],
whose definition is technology-oriented where this one is a governance definition.

Where none exists, the absence is stated, with the nearest concept named when there is one:

~ Relation to ToIP: no equivalent term. The nearest concept is
[[xref: toip-glossary, revocation]], which names the event where an issuer
stops attesting to a credential; the status list is the mechanism that makes
such an event checkable.

“No equivalent term” is a finding rather than an omission. It is what makes a Tier 3 definition defensible, so the file says it out loud instead of leaving a reader to wonder whether anyone looked.

Always write the reference as [[xref: toip-glossary, <term>]] and never as a link to glossary.trustoverip.org. An [[xref:]] renders with the upstream definition attached, and the federation workflow keeps it current; a pasted URL does neither.

npm run check:toip enforces all of this: one relation line per term, every [[xref:]] resolving to a cached upstream definition, every [[ref:]] resolving to a term this glossary defines and no bare upstream URLs. It runs in CI on every pull request that touches a term.

§ Keeping federation up to date

After adding any [[xref:]] or [[tref:]] reference, run:

npm run xrefs

This fetches the current definition from the Trust over IP Main Glossary via the GitHub API and caches it in output/xrefs-data.json. Commit the updated cache file so the rendered output is reproducible without network access.

A GitHub Actions workflow (fetch-and-push-xrefs.yml) runs this automatically on schedule.

§ ToIP cross-reference-first policy

Before writing a new local definition, check whether the term is already covered by the Trust over IP Main Glossary. If so, use [[tref:]] (Tier 1) or [[xref:]] on the ToIP reference line (Tier 2) rather than duplicating the definition. Local definitions should capture meaning that is specific to the Swiss, BGEID, or DIDAS/swiyu context only.

Record the outcome of that check either way. Whichever answer it produced, it goes on the ToIP reference line described above, so the next reader inherits the check instead of repeating it.

§ Further Resources