# Base requirements for recognising a trust framework **Status: draft for discussion.** Input for the whitepaper and for the meta-list's own ecosystem governance framework. These requirements describe what a **trust framework** and its **governance body** must demonstrate to be recognised on the meta-list. They are generalised from the iSHARE Trust Framework, which operates all of this in production, and are written to be satisfiable by a sovereign register, a sectoral scheme or a global framework alike. Two principles run through them: - **Criteria, not specifications.** A requirement names what must be demonstrated and to what assurance level, never a single named product, register or identifier scheme. Schemes compete on assurance. - **Light to start, designed to tighten.** A heavy gate at the outset excludes exactly the registries this layer most needs. Requirements marked *(baseline)* are the entry set; those marked *(maturity)* are expected as the layer proves itself, and a framework may be recognised while working towards them. --- ## A. The governance body **A1. Legal personality and public registration.** *(baseline)* The governance body is a legal entity, publicly registered and identifiable, and its statutes are available. > iSHARE: the iSHARE Foundation is the Scheme Owner, registered in the Dutch > Commercial Register (KvK 73058289); the rules on its organisation and > governance are captured in its statutes. **A2. Separation of executive and supervisory power.** *(baseline)* The body that runs the framework day to day is accountable to a distinct body that can appoint and dismiss it. One organ cannot be both the operator and its own supervisor. > iSHARE: an Executive Board, accountable to a Supervisory Board that elects and > dismisses its members; plus an operational branch for day-to-day management. **A3. A voice for the governed.** *(baseline)* The parties bound by the framework have a formal channel to advise it and to appoint at least part of its supervision. > iSHARE: the Council of Participants advises the Foundation and appoints the > Supervisory Board. **A4. Expert change advice, separated from decision-making.** *(maturity)* Changes to the specifications are advised on by delegated subject-matter experts — legal, operational, functional and technical — distinct from the body that decides. > iSHARE: a Change Advisory Board of experts delegated by participants and data > space governance bodies. **A5. Funding without control.** *(baseline)* Funders are disclosed, and funding does not confer control over admission or status decisions. Any funder representation in governance is bounded and published. > iSHARE: Sponsors may fund the Foundation; Sponsor status is granted by the > Supervisory Board and may account for at most one of its three seats. **A6. No competition with the governed.** *(baseline)* The governance body does not issue credentials into, or sell products in, the market it governs. Where it cannot avoid a role on both sides, the conflict is declared and handled by recusal. --- ## B. The legal instrument **B1. One binding agreement.** *(baseline)* Participation rests on a signed agreement between each participant and the governance body (or a body it has certified), which incorporates the framework's terms and specifications by reference. > iSHARE: the Accession Agreement, referring to the Terms of Use, which bind > participants to all iSHARE specifications. **B2. Effect between participants.** *(baseline)* The agreement gives participants standing to hold *each other* to the rules, not only the governance body. Without this the framework is a publication, not a regime. > iSHARE: one contract with the Scheme Owner binds all participants to the > common terms and lets them appeal to one another to abide by them — in Dutch > law, *derdenwerking*. **B3. Role-differentiated obligations.** *(baseline)* Obligations scale with the role. A party that merely consumes is not held to the same bar as one that accredits, issues or operates a registry. > iSHARE: separate Accession Agreements and separate criteria for Adhering > Parties and Certified Parties. **B4. Machine-readable conditions.** *(maturity)* Where the framework expresses usage or access conditions, they are expressed so they can travel with the transaction rather than living only in prose. > iSHARE: licences are included in delegation evidence and are legally binding > on all participants. --- ## C. Admission and accreditation of issuers **C1. Published, normative admission criteria.** *(baseline)* The criteria are public, written normatively, and applied uniformly. > iSHARE: the admission process is normative and RFC 2119-compliant. **C2. A verifiable legal entity identifier — of any recognised scheme.** *(baseline)* Every admitted party presents at least one valid legal entity identifier that is **nationally or internationally recognised and verifiable**. The framework states which schemes it accepts and at what assurance level. No single scheme is mandated. > iSHARE: "at least one acceptable, valid legal entity identifier … (nationally > or internationally recognised unique identifier which can be verified)." > Note this deliberately does not name a scheme — sovereign identifiers qualify. **C3. A cryptographic identity bound to that entity.** *(baseline)* Admission binds the legal entity to key material or an identity assertion of a stated assurance level. > iSHARE: an eIDAS Qualified Certificate for advanced or qualified eSeals, or > onboarding through a certified Identity Provider; a DID is derived from the > identification credential. **C4. Conformance testing, not self-declaration.** *(baseline)* Technical compliance is demonstrated by a test report from a conformance suite, not asserted. > iSHARE: a successful report from the iSHARE conformance test tool is required. **C5. An assessment framework for accrediting roles, with a declared assurance level.** *(baseline for issuer-accrediting frameworks)* Parties that accredit, issue or operate registries are assessed against a published assessment framework, submit evidence, and are certified *at a stated level of assurance*. > iSHARE: Certified Parties state the assurance level sought and submit a > completed Assessment Framework with evidence. **C6. An impediment check.** *(baseline)* Admission checks for prior exclusion from this or a related ecosystem. **C7. Published decision timelines.** *(maturity)* Applicants know how long a decision takes. > iSHARE: 5 working days for Adhering Parties, 30 days for Certified Parties. **C8. Responsibility is allocated and non-transferable.** *(baseline)* It is explicit who admits whom, and delegation of onboarding does not transfer accountability. > iSHARE: the Scheme Owner admits Participant Registries; a Registry may delegate > onboarding but remains responsible. --- ## D. Supervision, status and revocation **D1. Status is continuous and machine-readable.** *(baseline)* Accreditation carries a status from a published vocabulary that can change without re-issuing anything, and only reliable statuses may be relied upon. **D2. Defined suspension, removal and incident procedures.** *(baseline)* What triggers each, who decides, and what the party may do about it. **D3. Historical entries stay visible.** *(baseline)* Withdrawn and ceased entries remain published for at least as long as credentials issued under them can be presented. --- ## E. Change, appeal and dispute **E1. A normative change management process.** *(baseline)* Changes to the framework follow a published process with defined steps. > iSHARE: change management is normative and RFC 2119-compliant. **E2. An appeal path for admission and status decisions.** *(baseline)* Decisions are appealable, within a stated window, to a body that did not make them. The governance body's own judgment must be reviewable. **E3. Dispute resolution between participants.** *(maturity)* A named forum and applicable law, so a disagreement has somewhere to go. --- ## F. Publication **F1. A machine-readable list of accredited parties.** *(baseline)* Resolvable, signed, cacheable, at a stable location. **F2. Provenance preserved.** *(baseline)* Where the framework's list is mirrored elsewhere, its own signature or a content hash travels with it, so a verifier can return to the source of truth. **F3. A stable, resolvable authority identifier.** *(baseline)* The framework is identified by an identifier a verifier can resolve to current keys. --- ## What this deliberately does not require - **A specific identifier scheme.** Not the LEI, not any national register. A sovereign will not accept an external scheme as equivalent to its own, and requiring one would exclude the government registries this layer most needs. C2 asks for a recognised, verifiable identifier and a stated assurance level. - **A specific credential format, DID method or protocol.** Those belong to the technical profile, which is a separate artifact with its own lifecycle. - **Assessment of regulatory lists.** An authoritative regulatory list is referenced as authoritative. This framework has no authority over it and applies no admission criteria to it.