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
  • Goal
  • Responsibilities
  • Sequence
  1. Detailed descriptions
  2. Operational
  3. Operational processes

Withdrawal or Downgrade

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

The withdrawal process describes the steps that parties MUST take to withdraw from a particular data space or the iSHARE network.

Withdrawal or downgrade includes:

  • A Certified Party or Adhering Party wants to withdraw from the data space/iSHARE network;

  • A Certified Party wants to downgrade to an Adhering Party;

  • Any other situation in which an Adhering party or Certified Party (un)expectedly withdraws from the data space or iSHARE network (e.g. bankruptcy).

The term of notice for withdrawal is 1 month for Adhering Parties, and 6 months for Certified Parties.

Goal

The goal of the withdrawal process is to let parties withdraw from the data space/iSHARE network in a simple and controlled way, minimising impact to the trust and disruption to the functioning of the data space/iSHARE network.

Responsibilities

Several parties have responsibilities and tasks in the withdrawal process:

  • The Data Space Governance Body/Scheme Owner is responsible for facilitation of the process, so that continued operation of the data space and the iSHARE network is not disrupted in any way;

  • The withdrawing/downgrading party is responsible for delivering a withdrawal plan and to minimise the disruption to the functioning of the data space/iSHARE network. The withdrawing party also benefits from a controlled process itself, as it should help to minimise disruption to internal operations.

Sequence

Withdrawal of an Adhering Party

  1. The withdrawing party formally indicates its intention to withdraw from the data space to the Data Space Governance Body.

  2. The Data Space Governance Body has 5 working days to acknowledge the intention to withdraw of the withdrawing party; the Data Space Governance Body makes the acknowledgement known to the withdrawing party, and provides a date on which the withdrawing party will be considered withdrawn from the data space;

  3. The withdrawing party communicates its withdrawal to the parties it interacts (interacted) with in the data space;

  4. The withdrawing party, in cooperation with the Data Space Governance Body, withdraws from the data space.

Withdrawal of or Downgrade of a Certified Party

  1. The withdrawing/downgrading party formally indicates its intention to withdraw/downgrade from the data space to the Data Space Governance Body. It includes a withdrawal plan based on the (to be set up) template withdrawal procedure;

  2. The Data Space Governance Body has 5 working days to acknowledge the intention to withdraw/downgrade of the withdrawing/downgrading party; the Data Space Governance Body makes the acknowledgement known to the withdrawing/downgrading party, and provides up to date guidelines;

  3. If necessary, the withdrawing/downgrading party sends an updated withdrawal plan to the Data Space Governance Body, keeping in mind the guidelines provided by the Data Space Governance Body;

  4. The Data Space Governance Body accepts the withdrawal/downgrading plan or indicates where it requires changes;

  5. The Data Space Governance Body and the withdrawing/downgrading party communicate the intended withdrawal with the data space per date in a dd-mm-yyyy format;

  6. The withdrawing/downgrading party, in cooperation with the Data Space Governance Body, withdraws/downgrades from the data space in accordance with the withdrawal plan;

  7. The Participant Registry registers and communicates the completed withdrawal to the data space.

Withdrawal of or Downgrade of a Participant Registry

  1. The withdrawing/downgrading party formally indicates its intention to withdraw/downgrade from the iSHARE network to the Scheme Owner. It includes a withdrawal plan based on the (to be set up) template withdrawal procedure;

  2. The Scheme Owner has 5 working days to acknowledge the intention to withdraw/downgrade of the withdrawing/downgrading party; the Scheme Owner makes the acknowledgement known to the withdrawing/downgrading party, and provides up to date guidelines;

  3. If necessary, the withdrawing/downgrading party sends an updated withdrawal plan to the Scheme Owner, keeping in mind the guidelines provided by the Scheme Owner;

  4. The Scheme Owner accepts the withdrawal/downgrading plan or indicates where it requires changes;

  5. The withdrawing/downgrading party, in cooperation with the Scheme Owner, withdraws/downgrades from the iSHARE network in accordance with the withdrawal plan;

  6. The remaining participants in the data space operated by the withdrawing/downgrading Participant Registry are free to join a different data space, create a new data space or select a new Participant Registry. This is subject to the reason for withdrawal of the Participant Registry. If security/ compliance breach is reported and the reason for suspension/ withdrawal, the compliance of all members will need to be reevaluated before allowing their participation in the iSHARE network.

PreviousAdmissionNextWarnings, Suspension and Exclusion

Last updated 3 months ago