# iSHARE Issuer Qualification — Onboarding and Offboarding Procedure

**Version** 3.0-draft.2 · **Date** 7 September 2026 · **Status** draft for discussion · **Owner** iSHARE Foundation (Scheme Owner)
**Portal** issuer.ishare.eu (alias issuer.ishare.vc)

This procedure replaces the Excel-based *Assessment Framework for Certified Parties* with one digital process on issuer.ishare.eu. It covers the full lifecycle of a credential issuer under the iSHARE Trust Framework 3.0: interest, application, assessment, accreditation, registration, operation, annual review and offboarding. It is written in the vocabulary of the verifiable-credential issuer world (GLEIF vLEI, EBSI, eIDAS 2.0, Trust over IP) and is aligned with the iSHARE VC membership model.

---

## 1. Terminology

| Term (3.0) | Meaning | Legacy iSHARE term | GLEIF vLEI | EBSI | eIDAS 2 / ETSI | ToIP / TRQP |
|---|---|---|---|---|---|---|
| **Scheme Owner** | iSHARE Foundation: defines rules, qualifies issuers, never issues credentials to end parties | Scheme Owner | GLEIF (Root of Trust) | Root TAO | Supervisory body / LOTL operator | Governing Authority |
| **Candidate Issuer** | Organisation in the qualification programme | Prospective Certified Party | Candidate vLEI Issuer | Legal entity requesting accreditation | Applicant TSP | Applicant governed party |
| **Qualified Issuer** | Organisation accredited to issue iSHARE credentials; public status "iSHARE Qualified Issuer" | Certified Party (contract role, unchanged) | Qualified vLEI Issuer (QVI) | Trusted Issuer (TI) | (Q)TSP / EAA provider | Authorised issuer |
| **Issuer Qualification Framework** | The digitised control set (50 controls, 5 domains) | Assessment Framework for Certified Parties | Qualification Program Checklist | Accreditation policy | Conformity assessment (ETSI EN 319 401/403) | Governance framework |
| **Accession Agreement** | Contract with the Scheme Owner incl. Terms of Use and financial terms | Accession Agreement for Certified Parties | vLEI Issuer Qualification Agreement | — | — | Governance framework accession |
| **Trusted Issuers Registry** | Machine-readable list of qualified issuers: keys, metadata, status, assurance level | Participant Registry / Satellite (for participants) | List of QVIs, GLEIF root AID | Trusted Issuers Registry (TIR) | Trusted List (ETSI TS 119 612 / 119 602) | Trust Registry |
| **Issuer Accreditation** | The proof that an issuer is qualified: registry entry, Accreditation Credential, Assessment Report | Certification, Level of Assurance | QVI vLEI Credential + TrustMark | Verifiable Accreditation to Attest | Trusted-list entry, status "granted" | Authorisation (Does X hold Y under Z?) |
| **Level of Assurance (LoA)** | Low / Substantial / High per Regulation (EU) 2015/1502 | Level of Assurance | — | — | LoA low / substantial / high | Assurance level |
| **Annual review** | Yearly re-verification of compliance | Yearly certification renewal | Annual vLEI Issuer Qualification | — | Conformity assessment every 24 months | — |
| **Offboarding** | Withdrawal, downgrade, suspension, exclusion | Withdrawal or Downgrade; Warnings, Suspension and Exclusion | Termination of the Qualification Agreement, 90-day grace period | Accreditation revoked | Status "withdrawn" | Authorisation revoked |

A note on the word *qualified*: it is used here in the GLEIF sense (Qualified vLEI Issuer). It is **not** the eIDAS legal term "qualified trust service provider". Public copy must not imply eIDAS qualified status.

Roles that can be accredited (an issuer may hold several under one accreditation):

| Role (3.0) | Issues | Legacy role | Applicable framework domains |
|---|---|---|---|
| Participant Credential Issuer (PCI) | Participant, Compliance, Dataspace Participant Credentials | Participant Registry / Satellite | 1, 2, 3, 4, 5 (the framework applies sections 1–3 to the Participant Registry) |
| Data Rights Controller (DRC) | Data Rights Credentials | Authorisation Registry | 4, 5 |
| Identity Credential Issuer (ICI) | Identity Credentials (H2M, EUDI-wallet ready) | Identity Provider / Identity Broker | 1, 2, 3, 4, 5 |
| Participant Registry operator (PR) | Participant Credentials for a Data Space Authority | Participant Registry / Satellite | 1, 2, 3, 4, 5 |

---

## 2. Principles

1. **Three things to bring.** Who you are (legal entity and representative), how you operate (the framework controls with evidence), and that your software works (Conformance Test Tool suites per version and a witnessed dry run). Nothing else.
2. **One dossier, one deadline, one decision.** All evidence lives in the portal. The candidate sees one completeness meter and one due date. The Foundation records one decision with one assurance level.
3. **Evidence once, reused everywhere.** Each evidence item has a type, a hash, an owner and a validity period. It is reused across controls, across annual reviews and across roles.
4. **Fast tracks by recognition.** ISO/IEC 27001, an eIDAS notified eID or qualified trust service, GLEIF QVI status and an existing Certified Party accreditation pre-fill controls. The Foundation reviews the delta only.
5. **Machine-verifiable proof.** The outcome is a registry entry any verifier can resolve, an Accreditation Credential the issuer can present, and an Assessment Report that references the evidence pack by hash.
6. **Same door in, same door out.** Offboarding runs in the same portal, with the same statuses, and keeps the historic record so credentials issued while active stay verifiable.
7. **Aligned with the business model.** €3,500 one-time accreditation (one re-assessment included), annual membership by revenue tier (50% in year 1), publication on the Trusted Issuers Registry, all credential types under one accreditation.

---

## 3. Roles in the process

**Candidate / Qualified Issuer**
- *Designated Authorised Representative (DAR)*: signs the Accession Agreement and attestations; legally binds the organisation (verified against the business register).
- *Technical contact*: keys, endpoints, conformance test, dry run.
- *Compliance contact*: evidence, policies, annual review, incident notification.

**iSHARE Foundation**
- *Intake*: registration, intake call, NDA, portal invitation, impediment check.
- *Assessor*: reviews controls and evidence, requests clarifications, witnesses the dry run, writes the Assessment Report. May be Foundation staff or an independent assessor. Recuses on conflicts.
- *Certification Committee* (two persons, four-eyes): records the decision, conditions and assurance level. Handles disputes.
- *Registry Operator*: publishes and maintains the Trusted Issuers Registry entry and status history.

**Data Space Authority (DSA)**: may add data-space-specific criteria; is informed of accreditations, suspensions and withdrawals affecting its data space.

---

## 4. Lifecycle overview

| # | Stage | Who acts | Output | Service level |
|---|---|---|---|---|
| 0 | Interest | Candidate, Intake | Registration record, intake call, NDA, portal invitation | Intake call within 5 working days |
| 1 | Application | DAR, Intake | Verified legal entity, roles and credential types, target LoA, revenue tier; impediment check passed | Within 5 working days |
| 2 | Self-assessment and evidence | Compliance contact | Complete dossier (all applicable controls answered with evidence) | 30 calendar days for the candidate; completeness feedback within 5 working days |
| 3 | Conformance testing (CTT) | Technical contact, Assessor | CTT suite passed per requested role and per supported framework version; reference code access granted; chain and metadata validated; dry run signed off | Test-network access at application; gate before stage 4; re-runs unlimited |
| 4 | Review and decision | Assessor, Certification Committee | Assessment Report, decision, assurance level, conditions | Within 30 calendar days of a complete dossier (4–6 weeks end-to-end); one re-assessment included, within 10 working days of remediation |
| 5 | Accreditation | DAR, Foundation | Signed Accession Agreement, accreditation invoice paid, membership invoice issued | Payment activates the accreditation |
| 6 | Registration | Registry Operator | Registry entry live, Accreditation Credential issued, public listing | Within 2 working days of payment |
| 7 | Operate and manage | Qualified Issuer, Foundation | Self-service management of public profile, visibility, team and access; change requests for keys, endpoints and scope; monthly reporting, incident notification, key rotation, evidence kept current, annual review | Annual review opens 60 days before the anniversary; change requests decided within 10 working days |
| 8 | Offboarding | Either party, Registry Operator | Withdrawal plan, status "suspended"/"withdrawn"/"revoked", holders migrated, data handled per exit plan | 6 months notice; 90-day holder grace period |

Registry status vocabulary (kept as a dated history, never overwritten): `candidate` → `under-assessment` → `accredited` → `suspended` → `withdrawn` | `revoked`. Only `accredited` authorises issuance. Verifiers accept a credential if the issuer was `accredited` at the time of issuance and the credential is not revoked on its status list.

---

## 5. Stage-by-stage procedure

### Stage 0 — Interest
1. The organisation submits the registration form on ishare.vc (name, organisation, e-mail, country, revenue tier, credential types of interest).
2. Intake confirms receipt and schedules an intake call within 5 working days. The call covers roles, credential types, target assurance level, fast tracks, timeline and fees.
3. A mutual NDA is signed in the portal (the Trust Framework allows the candidate to ask for one before providing assessment material).
4. The DAR receives the portal invitation. The candidate record is created with status `candidate`.

### Stage 1 — Application
1. The DAR completes the organisation profile: legal name, registered identifier (Chamber of Commerce, EUID, LEI, VAT, EORI; any is accepted, its assurance is recorded), address, contacts.
2. The portal verifies the identifier against the authoritative register (KvK API, GLEIF API) and checks that the DAR is an authorised signatory.
3. The DAR selects roles, credential types, target LoA and applicable fast tracks. The portal derives the applicable controls and the evidence checklist.
4. Intake performs the impediment check: no exclusion in the last 12 months, no sanctions hit, no open dispute. Result recorded.
5. Status becomes `under-assessment`. The 30-day evidence window starts and test-network access for the Conformance Test Tool is issued (stage 3).

### Stage 2 — Self-assessment and evidence
1. The candidate answers each applicable control (Yes/No, LoA, or attack potential), writes a short narrative and attaches evidence. Evidence types: policy, register extract, certificate, report, signed attestation, demonstration, third-party verifiable credential, public URL.
2. Fast tracks pre-fill controls. ISO/IEC 27001 covers controls 24–36 on presentation of certificate and Statement of Applicability. An eIDAS notified eID or qualified trust service covers controls 4–15. GLEIF QVI status covers governance and security evidence. An existing Certified Party accreditation carries over controls 1–36.
3. The portal shows one completeness meter and blocks submission until every applicable control has an answer and at least one evidence item.
4. On submission, the Assessor gives completeness feedback within 5 working days. Missing items are listed as tasks with due dates.

### Stage 3 — Conformance testing (CTT)
The Conformance Test Tool is an explicit stage: it starts as soon as the application is accepted and it is a gate before the decision. No dossier goes to the Certification Committee without a passed CTT suite for every requested role and every framework version the issuer supports.
1. On acceptance of the application the portal issues test-network access: a test client id and an iSHARE test certificate, plus the CTT account on ctt.isharetest.net.
2. The candidate declares the framework versions it supports (2.2 JWT/API profile, 3.0 verifiable-credential profile). The portal derives one CTT suite per role per version: for 2.2 the Participant Registry, Authorisation Registry or Identity Provider suites; for 3.0 the Participant Credential Issuer, Data Rights Controller, Identity Credential Issuer or Participant Registry suites (schemas v3, DCP 1.0 or OpenID4VCI/OpenID4VP, status lists, holder binding).
3. The candidate runs the suites in the CTT. Results are imported into the portal with the test run identifier and the per-case JSON logs of failing cases. Re-runs are unlimited.
4. A passed suite for version V and role R grants access to the reference code for V and R (see section 8). The invitation is sent within 1 working day.
5. Upload the certificate chain (eIDAS qualified certificate for electronic seals or an accepted equivalent). The portal validates the chain against the EU trusted list and records key type and expiry.
6. Register the issuer identifier (iSHARE DID method), the metadata document and the status list URL. The portal resolves, validates and starts monitoring them.
7. Technical dry run, witnessed by the Assessor, once all suites are green: issue one credential per requested type, present and verify it, revoke it and observe the status list, rotate the signing key and re-verify. The Assessor signs the dry-run playbook in the portal. The CTT results and the signed playbook are the evidence for controls P03, P04 and P11.

### Stage 4 — Review and decision
1. The Assessor reviews each control: verdict (Met, Partially met, Not met, Not applicable), assessed LoA for LoA controls, note. Clarification requests go through the portal and stop the clock.
2. The Assessor writes the Assessment Report: per-domain findings, achieved LoA, conditions, evidence-pack hash.
3. The Certification Committee records the decision within 30 calendar days of a complete dossier: **Accredited**, **Accredited with conditions** (remediation with due dates), or **Not accredited** (one re-assessment within the accreditation fee, within 10 working days of remediation).
4. Assurance level: the lowest LoA achieved on applicable LoA controls. The Committee may accredit at a lower level than requested.
5. Disputes: the candidate may object within 5 working days; the Committee replies within 5 working days; the candidate has a final 5 working days. Beyond that, the Board of the Foundation decides.

### Stage 5 — Accreditation
1. The DAR e-signs the Accession Agreement for Certified Parties (Trust Framework 3.0) including Terms of Use and financial terms, marking the accredited roles.
2. The Foundation invoices the one-time accreditation fee (€3,500). Payment activates the accreditation.
3. The annual membership is invoiced by revenue tier (non-profit €2,000; startup €3,000; scale-up €8,500; growth €18,000; enterprise €40,000; year 1 at 50%).

### Stage 6 — Registration
1. The Registry Operator publishes the registry entry: legal name, identifiers, certificate chain and public keys, issuer DID, endpoints, credential types, assurance level, status `accredited` with effective date, accreditation reference.
2. The Foundation issues the Accreditation Credential (W3C VC 2.0, type `iSHAREIssuerAccreditation`) to the issuer's DID. It references the Assessment Report hash, the roles, credential types, LoA and validity. Holders may present it to third parties and to trusted-list-of-trusted-lists resolvers.
3. The issuer appears on the public Trusted Issuers page. Credentials signed with the registered key are verifiable ecosystem-wide.

### Stage 7 — Operate and manage
After registration the portal becomes the issuer's management environment. The issuer manages its own public profile and visibility on the Trusted Issuers page of ishare.vc, its team and access, and its reference-code access; it requests changes to keys, endpoints and scope through change requests (see section 9).

Obligations of a Qualified Issuer (from the Terms of Use, the service levels for Certified Parties and the framework):
- Availability 99% per calendar month, performance 95% of messages within 2 s and 99% within 5 s, at least 100 simultaneous messages.
- Incidents: notify the Foundation immediately on discovery; updates as prescribed (minor: end of each working day; calamity/crisis: within 2 hours of significant updates); resolution target 3 working days.
- Support: confirm receipt within 1 working day; substantive answer within 5 working days.
- Reporting: monthly management information (availability, transactions, incidents, party relations) before 23:59 on the 5th working day.
- Keys: planned rotation before expiry; emergency rotation and notification within 24 hours on suspected compromise; registry updated.
- Status lists: updated within 1 working day of revocation or suspension; immediately on compromise.
- Changes: notify the Foundation before changing keys, endpoints, credential types, sub-processors or scope.
- Evidence: keep evidence current; the portal tracks validity (register extract 3 months, insurance 12 months, audit report 12 months, certificates until expiry) and creates tasks when items expire.
- **Annual review**: opens 60 days before the accreditation anniversary. The DAR confirms a delta attestation (what changed), refreshes expired evidence, uploads the latest audit report and monitoring report. The Assessor reviews the delta. The Committee renews the accreditation for 12 months. Membership renewal is invoiced at the same time.

### Stage 8 — Offboarding
Triggers: (a) the issuer gives notice, (b) the issuer downgrades to an Adhering Party, (c) the Foundation terminates after the non-compliance process, (d) force majeure or bankruptcy.

Non-compliance process (Trust Framework, Warnings, Suspension and Exclusion), run in the portal:
- *Minor* (e.g. expired evidence, service-level breach): notification with a rectification period (proposed 30 days).
- *Major* (recurring minor, serious impediment, reportable breach): official warning with a rectification period (proposed 14 days), then final warning.
- *Critical* (recurring major, threat to the integrity of the framework, key compromise not handled): immediate suspension; status `suspended`; issuance stops; final warning before exclusion.
- Dispute window 5 working days per step. Continued non-compliance escalates one level. Exclusion terminates the Accession Agreement; status `revoked`; no re-application for 12 months.

Withdrawal steps (Certified Party):
1. Notice through the portal, 6 months before the intended end date (downgrade follows the same steps).
2. Withdrawal plan submitted within 20 working days, based on the exit plan of control 20: timeline, communication to holders, verifiers and data spaces, credential handling, data protection, retention and destruction, hand-over to another Qualified Issuer where relevant.
3. Foundation and affected Data Space Authorities review and approve the plan.
4. Holders receive a 90-day grace period to obtain replacement credentials from another Qualified Issuer.
5. At the end date the Registry Operator sets status `withdrawn` with an effective date, marks remaining credentials revoked on the status list, and retains the historic entry and keys so past credentials remain verifiable.
6. Data is retained and destroyed per the retention policy; the evidence pack is archived for the audit retention period; final settlement of fees; the Accreditation Credential is revoked.
7. Closure is recorded and communicated to the data spaces.

---

## 6. The Issuer Qualification Framework 3.0

The 36 controls of the current Excel framework are kept with their numbering and content (control 14 stays removed). They mirror Regulation (EU) 2015/1502 and are already mapped to ISO/IEC 27001 controls. Domain 5 is new and adds 14 controls specific to credential issuance; they mirror GLEIF's technical qualification (issuance, verification, revocation, key rotation) and the iSHARE VC profile. Subsection 5.4 applies to Data Rights Controllers only. It requires that the Data Rightsholder is identified and its mandate verified (P12), that the issuer verifies before issuance that the rightsholder actually holds the rights to the data at the Service Provider concerned (P13), and that every credential is traceable to the rightsholder's instruction and revoked when the entitlement ends (P14). Without 5.4 the framework asks an Authorisation Registry nothing about data ownership: sections 1 to 3 apply to identity providers and participant registries only.

| Domain | Controls | Applies to | Answer types |
|---|---|---|---|
| 1 Enrolment | 1–4 | PCI, PR, ICI (Identity Provider and Participant Registry in the framework) | Yes/No, LoA |
| 2 Electronic identification means management | 5–12 | PCI, PR, ICI | LoA, Yes/No |
| 3 Authentication | 13, 15 (14 removed) | PCI, PR, ICI | LoA, attack potential |
| 4 Management and organisation | 16–36 | All roles | Yes/No, LoA |
| 5 Credential issuance operations (new) | P01–P14 | All roles; 5.4 Data Rights Controllers only | Yes/No, LoA |

Each control in the machine-readable framework (`framework/issuer-qualification-framework.v3.json`) carries: id, domain, roles, question, guidance, examples, answer type, required evidence with validity period, mappings (2015/1502, ISO/IEC 27001, GLEIF QVI checklist, EBSI/ETSI where relevant) and fast-track eligibility.

Decision rules: all applicable controls must be answered with evidence (completeness); all Yes/No controls must be Met, or Partially met with an accepted remediation plan; the issuer LoA is the minimum across applicable LoA controls; accreditation is valid 12 months and renewed through the annual review.

---

## 7. Issuing proof — what the Foundation can show

For every Qualified Issuer the portal holds and can produce:

1. **Registry entry** (JSON, and ETSI TS 119 612-style trusted-list form for European consumers): identity, keys, endpoints, credential types, LoA, status history.
2. **Accreditation Credential**: W3C VC signed by the Foundation, type `iSHAREIssuerAccreditation`, with roles, credential types, LoA, valid-from/until, assessment-report hash, status-list entry.
3. **Assessment Report**: per-control verdicts and LoA, findings, conditions, fast tracks applied, assessor and committee signatures, evidence-pack hash (Merkle root of all evidence items).
4. **Evidence pack**: every evidence item with type, hash, uploader, timestamp, validity, reviewer verdict. Exportable for audits.
5. **Audit trail**: every state change with actor and timestamp; every message between candidate and Foundation.

This satisfies the Trust over IP question "Does entity X hold authorisation Y under governance framework Z?" with an explainable answer, and makes iSHARE's list consumable by the trusted list of trusted lists.

---

## 8. Conformance testing and reference code

**Why an explicit stage.** GLEIF makes candidates install the vLEI software and test issuance, verification, revocation and key rotation before qualification; EBSI runs conformance tests before accreditation. iSHARE has the same instrument in the Conformance Test Tool. Making it a named stage with a visible gate, instead of an attachment in the dossier, is what lets the Foundation say with confidence that every registered issuer works against every version it claims.

**Versions and suites.**

| Version | Profile | Suites (one per role) |
|---|---|---|
| 2.2 | JWT / iSHARE API profile | Participant Registry (Satellite) API; Authorisation Registry (/token, /capabilities, /delegation with Permit and Deny masks); Identity Provider (/capabilities, /authorise, /token M2M and H2M, /userinfo) |
| 3.0 | Verifiable-credential profile | Participant Credential Issuer; Data Rights Controller; Identity Credential Issuer; Participant Registry (schemas v3, DCP 1.0 or OpenID4VCI/OpenID4VP, status lists, holder binding, issuer metadata) |

An issuer passes one suite per role per version. The registry entry lists the versions passed, so verifiers know which profile an issuer supports. Adding a version later is a change request with a delta CTT run.

**Reference code access.** Passing a suite for version V and role R grants access to the reference implementations for V and R:
- Open-source repositories (AuthorizationRegistry, python-ishare, openapi, code-snippets, the 3.0 VC toolkit) are always available.
- Restricted repositories (the Participant Registry / Satellite codebase and, for 3.0, the reference issuers) are shared under the NDA until the Accession Agreement is signed. The Accession Agreement 3.0 already provides that this codebase is not released to the public and is used only to build on the iSHARE framework.
- Invitations go to the issuer's GitHub organisation, per version team, within 1 working day of the passed suite. Access is withdrawn on offboarding and every grant and withdrawal is logged.

## 9. Self-service management

issuer.ishare.eu is not only the qualification portal but the management environment of every Qualified Issuer. The rule is simple: what only changes how you appear is self-service and immediate; what changes what you are accredited for, or what verifiers rely on, goes through a change request.

| Change | Handling | Effect |
|---|---|---|
| Display name, tagline, description, logo, website, contact, sectors, visibility toggles | Self-service | Published immediately on the Trusted Issuers page; logged |
| Data spaces served | Notify | Data Space Authority informed |
| Team members and roles (except the DAR), notifications, API tokens | Self-service | Logged in the audit trail |
| Keys, endpoints, status-list URL | Change request | Foundation approval within 10 working days; registry entry updated with effective date |
| Roles, credential types, framework versions | Change request | Delta assessment and CTT for the added scope |
| Legal name, identifier, DAR | Change request | Register check; agreement addendum |

Self-service functions: public profile and preview of the listing on ishare.vc; visibility toggles (listed, show contact, accepting new customers); team and roles (DAR, Admin, Technical, Compliance, Billing, Read-only); API tokens for automated monthly reporting and monitoring callbacks; notification preferences; invoices; reference-code access; change requests with status; the annual review; and offboarding.

## 10. Fees (alignment with the membership model)

| Item | Amount | When |
|---|---|---|
| Accreditation (one-time, incl. one re-assessment, all credential types) | €3,500 | Invoiced on positive assessment; payment activates the accreditation |
| Annual membership: non-profit | €2,000 (€1,000 year 1) | At accreditation, then yearly at the anniversary |
| Annual membership: startup (< €1M) | €3,000 (€1,500 year 1) | idem |
| Annual membership: scale-up (€1M–€10M) | €8,500 (€4,250 year 1) | idem |
| Annual membership: growth (€10M–€100M) | €18,000 (€9,000 year 1) | idem |
| Annual membership: enterprise (> €100M) | €40,000 (€20,000 year 1) | idem |
| Data Space Authority contract | €25,000 / year (CPI-indexed from 1 Jan 2027) | Separate contract |

Note: the financial terms in Appendix 2 of the Accession Agreement 3.0 (January 2026) use five revenue tiers with slightly different amounts (€3k / €9k / €15k / €30k / €40k). The membership page is taken as leading here; Appendix 2 should be updated to match.

---

## 11. Open decisions for the Foundation

1. **Public name**: "Qualified Issuer" (aligned with GLEIF and with the Trusted List of Trusted Lists paper) versus "Certified Party" (Accession Agreement, membership page). Recommendation: Qualified Issuer publicly, Certified Party as the contract role.
2. **Accreditation Credential**: issue one (recommended; it is proof about the issuer, not a credential to end parties, so it stays within "the Foundation never issues") or rely on the registry entry only.
3. **Independent assessors**: Foundation staff only, or an accredited assessor panel with recusal rules (needed once volume grows and for High assurance).
4. **Domain 5 thresholds**: HSM at Substantial and certified QSCD at High; status-list update within 1 working day; 90-day holder grace period.
5. **Mutual recognition**: formal acceptance of GLEIF QVI qualification and eIDAS conformity assessments as evidence.
6. **Non-compliance rectification periods**: 30 days (minor) and 14 days (major) are proposals; the Trust Framework leaves them to the steering body.
7. **Appendix 2 alignment**: bring the financial terms in the Accession Agreement 3.0 in line with the membership page.
8. **CTT for 3.0**: the VC-profile suites (issuance, presentation, status list, holder binding) have to be built in the CTT; until then the 3.0 gate is the witnessed dry run.
9. **Reference-code licensing**: which 3.0 repositories are open source and which stay restricted under the Accession Agreement clause; whether access is per GitHub organisation or per named developer.
10. **Version policy**: how long 2.2 suites and reference code remain available once 3.0 is live.

---

## 12. Sources

- iSHARE Assessment Framework for Certified Parties (Excel, 36 controls, Trust Framework 2.x)
- iSHARE Trust Framework: Admission; Withdrawal or Downgrade; Warnings, Suspension and Exclusion; Service levels for Certified Parties (framework.ishare.eu)
- Accession Agreement for Certified Parties, Trust Framework 3.0 (26 January 2026), Appendix 2 Financial Terms
- iSHARE VC membership model (inpreparation.ishare.vc/membership.html) and positioning (inpreparation.ishare.vc)
- GLEIF vLEI Issuer Qualification Program: process, required documents, lifecycle (gleif.org)
- EBSI Trusted Issuers Registry and accreditation flows (hub.ebsi.eu)
- Regulation (EU) 2015/1502 on assurance levels; ETSI TS 119 612 and TS 119 602 trusted lists
- Trust over IP Trust Registry Query Protocol v2.0
- A Trusted List of Trusted Lists, Part I Governance, v0.9 (iSHARE, September 2026)
- iSHARE General Brandbook (2026)