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. Detailed descriptions
  2. Functional
  3. Functional requirements per role

User interface requirements

PreviousParty identificationNextTechnical

Last updated 2 months ago

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

For all Human to Machine interactions, as in , an interface is required. This interface MUST comply with the following guidelines:

  • The name of the legal entity that provides a broker service or identity provisioning service MUST be clearly visible;

  • During the process of authentication, information not directly relating to the identity provision process or supporting the identity provision process MAY NOT be present. Links to websites irrelevant to the identity provisioning process or advertisements MAY NOT be present;

  • Parties facilitating the identity provision process MAY use their own corporate styling and logos;

  • The iSHARE brand MUST be shown during the identity provision process. Showing the iSHARE brand MUST be in line with iSHARE guidelines;

  • Human Service Consumer that are being identified through the use of a browser MUST be able to verify the URL and used SSL certificate during all steps of identity provisioning process.

Please note that extra guidance will need to be added for the context of apps: how can Human Service Consumers verify that they are not being tricked?

primary use case 3
communication