Issuer Qualification: onboarding to offboarding

Today a prospective Certified Party fills in a 36-question Excel sheet, e-mails evidence, and waits for a decision that lives in someone's inbox. This procedure moves the same framework into one portal, adds the controls a credential issuer actually needs (keys, status lists, schemas, dry run), and produces a machine-verifiable proof of accreditation on the Trusted Issuers Registry. The candidate brings three things; the Foundation gives one decision; verifiers get one answer.

Terminology

The vocabulary follows the verifiable-credential issuer world. The legacy Trust Framework terms stay valid in contracts; the new terms are used in the portal and in public copy.

Roles that can be accredited

Principles

1. Three things to bring. Who you are (legal entity and representative), how you operate (controls with evidence), and that your software works (Conformance Test Tool suites per version and a witnessed dry run).
2. One dossier, one deadline, one decision. 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, hash, owner and validity period and is reused across controls, reviews and roles.
4. Fast tracks by recognition. ISO/IEC 27001, eIDAS, GLEIF QVI and an existing accreditation pre-fill controls; the Foundation reviews the delta.
5. Machine-verifiable proof. A registry entry any verifier can resolve, an Accreditation Credential the issuer can present, and an Assessment Report bound to 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.
7. Aligned with the business model. €3,500 accreditation with one re-assessment, annual membership by revenue tier at 50% in year 1, all credential types under one accreditation.

Roles in the process

Candidate / Qualified Issuer

• Designated Authorised Representative (DAR): signs the Accession Agreement and attestations; verified against the business register as an authorised signatory.
• 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. Foundation staff or an independent assessor; recuses on conflicts.
• Certification Committee: two officers, four-eyes; records decision, conditions and assurance level; handles disputes.
• Registry Operator: publishes and maintains registry entries and status history.

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

Lifecycle

Registry status

Stage by stage

The Issuer Qualification Framework 3.0

The 36 controls of the Excel framework are kept with their numbering and content; control 14 stays removed. They mirror Regulation (EU) 2015/1502 and are mapped to ISO/IEC 27001. Domain 5 is new: 14 controls specific to credential issuance that mirror GLEIF's technical qualification (issuance, verification, revocation, key rotation) and the iSHARE VC profile.

Domain 5, proposed controls

Decision rules

• Completeness: every applicable control answered with at least one evidence item.
• Mandatory: every Yes/No control Met, or Partially met with an accepted remediation plan recorded as a condition.
• Assurance level: the minimum LoA across applicable LoA controls; the Committee may accredit lower than requested.
• Validity: 12 months, renewed through the annual review. Evidence with a validity period is tracked and requested again when it expires.

The framework is available as data in framework/issuer-qualification-framework.v3.json: every control with roles, question, guidance, examples, answer type, evidence with validity, mappings to 2015/1502, ISO/IEC 27001, the GLEIF checklist and EBSI/ETSI, and fast-track eligibility.

Issuing proof

For every Qualified Issuer the Foundation can produce, from the portal:

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

Conformance testing and reference code

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.

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. The invitation goes to the issuer's GitHub organisation within 1 working day.
• 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.
• Access is withdrawn on offboarding. Every grant and withdrawal is logged in the audit trail.

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.

Self-service functions: public profile with a live 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.

Ongoing obligations

From the Terms of Use, the service levels for Certified Parties and the framework:

• Availability 99% per calendar month; 95% of messages within 2 s, 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 or 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; on suspected compromise emergency rotation and notification within 24 hours; registry updated.
• Status lists: updated within 1 working day of revocation or suspension; immediately on compromise.
• Changes: notify before changing keys, endpoints, credential types, sub-processors or scope.
• Evidence: kept current. The portal tracks validity (register extract 3 months, insurance 12 months, audit report 12 months, certificates until expiry) and creates tasks 30 days before expiry.
• Annual review: delta attestation by the DAR, refreshed evidence, latest audit and monitoring reports; Assessor reviews the delta; Committee renews for 12 months.

Offboarding

Triggers: the issuer gives notice; the issuer downgrades to an Adhering Party; the Foundation terminates after the non-compliance process; force majeure or bankruptcy.

Non-compliance

Dispute window: 5 working days per step. Continued non-compliance escalates one level. Exclusion terminates the Accession Agreement, sets status revoked, and bars re-application for 12 months. Rectification reinstates accredited.

Withdrawal (Certified Party)

1. Notice through the portal, 6 months before the intended end date. Downgrade follows the same steps.
2. Withdrawal plan 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. The Foundation and affected Data Space Authorities review and approve the plan.
4. Holders get a 90-day grace period to obtain replacement credentials from another Qualified Issuer.
5. At the end date the Registry Operator sets 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; fees are settled; the Accreditation Credential is revoked.
7. Closure is recorded and communicated to the data spaces.

Fees

The portal: issuer.ishare.eu

One portal for the whole lifecycle, and the system of record for the Foundation's issuing proof. Workspaces: candidate and issuer; assessor; certification committee; registry operator; data space authority (read only).

Build on the BDI Onboarding Portal stack (React, Vite, TypeScript, Docker, nginx, OIDC). Load the framework JSON at build time so the control set is versioned with the code. Integrations: ishare.vc registration form, KvK and GLEIF APIs, EU trusted lists, conformance test tool, test network, Trusted Issuers Registry, e-signature, invoicing. The clickable prototype shows the candidate and assessor views with example data.

Open decisions for the Foundation

1. Public name: "Qualified Issuer" (GLEIF-aligned, used in the Trusted List of Trusted Lists paper) or "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) or rely on the registry entry only.
3. Independent assessors: Foundation staff only, or an accredited assessor panel with recusal, needed at volume and for High assurance.
4. Domain 5 thresholds: HSM at Substantial, 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. Rectification periods: 30 days minor, 14 days major are proposals; the Trust Framework leaves them to the steering body.
7. Appendix 2: align the financial terms with the membership page.
8. CTT for 3.0: the VC-profile suites 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; access 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.

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
• Accession Agreement for Certified Parties, Trust Framework 3.0 (26 January 2026), Appendix 2 Financial Terms
• iSHARE VC membership model and positioning (inpreparation.ishare.vc)
• GLEIF vLEI Issuer Qualification Program: process, required documents, lifecycle
• EBSI Trusted Issuers Registry and accreditation flows
• Regulation (EU) 2015/1502; ETSI TS 119 612 and TS 119 602
• 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