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 the identification of participants in the data space. It MAY define its own identifier for use within the data space, keeping the following in mind:

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

  • The identification must comply with the <method>:<value> format

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

  • The use of a DID method is recommended, but other methods, including self-defined methods, are also permitted

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

  • The iSHARE-ID will be 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 Participant Registry where a party onboards

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

Note

For example, when a Participant is onboarded using an 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

1. Primary Identifier (id)

   • This is the iSHARE DID of the party.

   • It is the canonical identifier for the party across Data Spaces.

2. 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:

<method> : <value>

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

{
  "id": "did:ishare:EU.NL.NLNTR-12345678",
  "alsoKnownAs": [
    "did:ebsi:LEIXG-724500AZSGBRY55MNS59",
    "did:key:z6MkhfrsD3GUMjGvRxTTSamE1WnS9w3nDJLeZzT1KZVrU5tE",
    "AS.JA.NTA:1234567890123"
  ]
}

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:

"eori:EU.EORI.NL123456789"