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

Party identification

PreviousFunctional requirements per roleNextUser interface requirements

Last updated 2 months ago

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

In order for parties to identify other parties, any party fulfilling a role in an iSHARE based Data Space MUST provide a unique identifier. The following rules apply:

  • Each Data Space MUST select one or more appropriate legal entity identifier(s) used for identification of participants in the data space. It MAY define its own identifier for use within the data space, keeping following in mind:

    • The identification (number/string) MUST be unique for each participant of the Data Space

    • There will be no predefined list of approved identifiers published by the Scheme Owner

    • The use of a is advised, but other methods including self-defined methods are also allowed.

  • Each participant of a Data Space MUST be provided with an iSHARE-ID, which is derived with following considerations:

    • The iSHARE-ID will be provided in the form of an

    • The iSHARE-ID uniquely identifies an iSHARE participant across data spaces

    • The iSHARE-ID must be provided to the participants by the first iSHARE Satellite where a party onboards

    • The iSHARE-ID will be equal to the organization identifier in an attribute of PKI certificate of the participant. alternatively, for the parties onboarded via the certified identity providers without PKI certificates, the organization identifier MUST be equal to organization identifier provided by identity provider.

Note

For example, when Participant is onboarded using and eIDAS certificate, the identifier in the Subject of the eIDAS certificate is in the ASN.OID - "2.5.4.97" or commonly known as OrganizationIdentifier (issued by a Trust Service Provider (TSP)), with the format of this field described in .

The party identifier will be stored in the form of an array and contain any number of identifiers. An example value is:

[
    did:ishare:EU.NL.NTRNL-12345678,
    did:elsi:LEIXG-724500AZSGBRY55MNS59,
    did:web:example.com
    dataspace_selfdefined_identifier:123456
    kvk:12345678
    eori:EU.EORI.NL123456789
    ...
]

Note on backwards compatibility Any existing participants that have been registered with an EORI number will be migrated and the EORI number will be kept in the party identifier array eori:<existing eori number>.

The iSHARE DID method is specified on .

DID-method
iSHARE DID
ETSI EN 319 412-1 V1.5.1, paragraph 5.1.4
https://did.ishare.eu/