iSHARE Trust Framework
Other resources
Version 2.1 (current version)
Version 2.1 (current version)
  • iSHARE Trust Framework
  • Introduction
    • Goals and scope of the iSHARE Trust Framework
    • Guiding principles
    • Governance
  • Releases
    • Release notes
    • Release planning
    • Version history
  • Main aspects of the iSHARE Trust Framework
    • Key functionality
      • Support Machine to Machine (M2M) interaction
      • Support Human to Machine (H2M) interaction
      • Facilitate portable identity(s) for parties and humans
      • Facilitate flexible authorizations, applicable in any context
      • Enable data exchange based on delegations - even between unknown parties
      • Enable control over own data through management of consent
      • Provide a Trust Framework
    • Technical overview
    • Framework and roles
    • Legal provisions
    • Operational provisions
  • Use cases
    • Use case: M2M interaction (with fine-grained authorization)
    • Use case: H2M interaction (with coarse-grained authorization)
    • Use case: portable identity
    • Use case: delegation (and management of consent)
  • Detailed descriptions
    • Functional
      • Primary use cases
        • 1. M2M service provision
          • 1b. M2M service provision with the EP as the delegation info PIP
          • 1c. M2M service provision with the AR as the delegation info PIP
          • M2M service provision including an app
        • 2. H2M service provision with identity info at the IP
          • Without Identity Broker
          • With Identity Broker
      • Secondary use cases
      • Licenses
      • Delegation paths
      • Functional requirements per role
        • Party identification
        • User interface requirements
    • Technical
      • Technical standards
      • Structure of delegation evidence
        • Example cases
    • Operational
      • Operational processes
        • Admission
        • Withdrawal or Downgrade
        • Warnings, Suspension and Exclusion
        • Incident Management
        • Change Management
        • Management reporting
      • Service levels
        • Service levels for Adhering Parties
        • Service levels for Certified Parties
      • Communication
    • Legal
      • Legal context
        • Dutch Civil Code
        • Regulation on Electronic Identification and Trust Services (eIDAS)
        • Applicable competition law
        • General Data Protection Regulation (GDPR)
  • Glossary and legal notices
    • Glossary
    • Legal notices
    • Assumptions
Powered by GitBook
LogoLogo

  • Cookie Policy

  • Privacy Policy

  • Imprint

  • Contact Us

Copyright © 2024 iSHARE Foundation

On this page
  • Availability
  • Performance
  • Incidents
  • Support
  • Reporting
  1. Detailed descriptions
  2. Operational
  3. Service levels

Service levels for Certified Parties

PreviousService levels for Adhering PartiesNextCommunication

Last updated 2 months ago

This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.

For Certified Parties, the following service levels apply:

Availability

Availability is a measure of the time a service is in a functioning condition. It includes the availability window and the maintenance window.

Availability window

The availability window includes the times at which Certified Party guarantees the availability of their service.

Norm: 24 hours * all days of the year

Minimum level required: 99% availability* per calendar month, from 00:00-23:59h

*Planned maintenance does NOT count as unavailability

Maintenance window

The maintenance window includes the times at which Certified Party can perform planned maintenance, that is likely to result in downtime, to their service(s). If no downtime is expected, maintenance can take place outside of the maintenance window. Planned maintenance does NOT include incident resolution, as this can take place outside the maintenance window as described under .

Norm:

  • The maintenance window includes the nights from Friday to Saturday and from Saturday to Sunday, from 00:00-5.59h;

  • Maintenance MUST be announced to the impacted parties directly as well as to the Data Space Governance Body/Scheme Owner**;

  • Announcements MUST be made at least 10 working days before the maintenance and MUST include date, time, and impacted service(s).

**The Scheme Owner/Data Space Governance Body presents an overview of its Certified Parties' current and planned maintenance on its website.

Performance

Performance includes the time it takes for a service to respond when requested or called upon; i.e. the time an Certified Party's service takes to respond to a received message.

Norm:

  • 95% of Certified Parties' messages MUST be responded within 2 seconds;

  • 99% of Certified Parties' messages MUST be responded within 5 seconds;

  • Each Certified Party MUST be able to process at least 100 simultaneous messages while meeting above requirements.

Incidents

An incident is an event, not part of the standard service operation, that results in a potential impact or risk with regards to the quality, availability, confidentiality and/or integrity of (data within) the iSHARE Trust Framework. This ONLY includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but not the contents of the actual data exchange.

  • Minor incident;

  • Calamity;

  • Crisis.

Norm:

  • All incidents MUST be communicated by the Certified Party(ies) to the Scheme Owner/Data Space Governance Body directly after they are discovered;

  • Communication MUST include date, time, incident level as estimated by the Certified Party(ies), argumentation including impacted service(s), and a potential incident manager;

  • In case of a calamity or crisis, the Certified Party MUST have an incident manager available during working days, and SHOULD have an incident manager available 24 * 7;

  • An update on the incident MUST be communicated to the Data Space Governance Body/Scheme Owner*:

    • For minor incidents, at the end of each working day;

    • For calamities, within 2 hours of every significant update and at the end of each working day;

    • For crises, within 2 hours of every significant update and every 4 hours.

Support

Support by Certified Party includes answering questions and requests from Adhering Parties.

Norm: Certified Parties are available for support via e-mail; they MUST confirm receiving a question/request within 1 working day. They SHOULD send an underpinned reaction (with an answer/solution or at the very least a direction) within 5 working days.

Reporting

Certified party
Participant Registry

Availability

Yes

Yes

Number of relations with Adhering Parties

Yes

Only if operating standalone Participant Registry (disconnected from the distributed ledger)

Number of transactions

Yes

No

Number of transactions per Adhering Party

Yes

No

Number of incidents.

Yes

Yes

All Certified Parties are expected to collect management information about each month: 0:00h on the first day to 23:59h on the last.

Norm: All Certified Party MUST deliver the management information about the last month, conform the iSHARE template, before 23:59h on the 5th working day of the current month

Three classifications of incidents are recognised within iSHARE, as explained in the :

All incidents SHOULD be handled by the Certified Party (in cooperation with the Scheme Owner/Data Space Governance Body as per the ) within 3 working days after being appointed as the responsible party - unless agreed otherwise.

*In line with the , the Scheme Owner/Data Space Governance Body presents an overview of current calamities and crises on its website

Reports are meant to monitor both compliance to the service level agreements and the (growing) use of the iSHARE network, as described in the . The following will be reported on (non-exhaustive):

incident management process
incident management process
incident management process
management reporting process
Availability
Performance
Incidents
Support
Reporting
incidents