Party identification
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 DID-method 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 iSHARE DID
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 ETSI EN 319 412-1 V1.5.1, paragraph 5.1.4.
Party Identification Model
Primary Identifier (id)
This is the iSHARE DID of the party.
It is the canonical identifier for the party across Data Spaces.
Also Known As (alsoKnownAs)
This is an array containing all other identifiers by which the party is recognised.
It may include DIDs using other methods, web identifiers, or self-defined identifiers.
In the Party model, identification information is structured into two parts. This structure replaces the former single array of identifiers.
Format Definition
Each identifier follows the format:
Where:
<method> defines the namespace or identification method (e.g., did:ishare, did:web, did:key, eori, oin, dataspace_selfdefined_identifier, etc.).
<value> is the unique value within that method’s name space.
Example
The iSHARE DID method is specified on https://did.ishare.eu/.
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>.
Notes
The id element contains the primary iSHARE DID.
The alsoKnownAs array may contain zero or more additional identifiers.
Any identifiers previously stored in the old party identifier array MUST now be included under alsoKnownAs.
Existing participants with an EORI number will be migrated, and the EORI number will be retained in the alsoKnownAs array as:
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>.
Last updated