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
  1. Main aspects of the iSHARE Trust Framework
  2. Key functionality

Enable control over own data through management of consent

PreviousEnable data exchange based on delegations - even between unknown partiesNextProvide a Trust Framework

Last updated 1 year ago

As described under key functionalities '' and '', the iSHARE Trust Framework aims to enable parties to grant other parties or persons access to (parts of) their data or services. At least as important is the aim to allow parties to modify or withdraw these access rights, to their data or services, whenever they wish. This is called management of consent, and enables full control over own data at any moment in time.

Example:

  • In the example described under key functionality '', Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

    • Now imagine that moments before Trucking Company B's ERP system asks Party C's ERP system for a time slot, Party C revokes Party A's access to requesting a time slot. Consequently, Trucking Company B's request for a time slot gets an access forbidden message; Trucking Company B's request is NOT accepted because Party A, and therewith delegated Trucking Company B, is no longer authorised to ask for a time slot.

Party C, as showcased, remains in full control over its own data and services at any moment in time. This example is detailed under .

facilitate flexible authorisations
enable data exchange based on delegations
enable data exchange based on delegations
use cases