Specification Status: Working Draft
Latest Draft: https://did.ishare.eu
Draft Created: March 25, 2024
Latest Update: February 17, 2025
Editors: ~ Rajiv Rajani
Contributors: ~ iSHARE CAB
Participate: ~ Git repo ~ File a bug
As data-sharing ecosystems gain prominence, it becomes imperative to enable legal entities to participate seamlessly. A crucial aspect is the requirement for a valid identifier to facilitate the identification and authentication of legal entities within the data-sharing context. Currently, there is no universally accepted legal entity identifier across various regions and sectors. We propose a new Decentralized Identifier (DID) method that leverages existing identifiers validated by Certificate Authorities, such as electronic Seals (eSEALS) as defined in eIDAS and similar frameworks globally. The identifier’s syntax and the accompanying data model conform to the DID-Core specification.
This document is a draft of the iSHARE DID Method Specification.It holds no official status and does not represent the endorsement or consensus of any standards organization.
The keywords MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [spec:RFC2119] [spec:RFC8174] when, and only when, they appear in all capitals, as shown here.
The target of ishare DID method is the legal entity who can be identified and resolved through a iSHARE Framework compliant Participant Registry.
The namestring that shall identify this DID method is: ishare. A DID that uses this method MUST begin with the following prefix: did:ishare. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.
The method specific identifier is an identifier of a legal entity that MUST be derived from a credential and/or digital certificate issued by an Authority that is defined as valid Authority in the iSHARE Framework.
The format of the identifier starts with 2 Letter Continent code followed by 2 Letter Country ISO Code [ISO 3166-1] where ISO has published the codes followed by identifier value as validated by the Authority. Typically, the value is an attribute in an eSEAL or similar PKI digital certificate (x509) issued by the authority.
For example, eSEAL certificates issued by eIDAS certified CAs will have such an value in organisationIdentifer(asn1 oid - 2.5.4.97) attribute following ETSI standards. This value in organisationIdentifer is complaint to */joint-iso-itu-t/ds/attributeType/organizationIdentifier or /joint-iso-ccitt/ds/attributeType/organizationIdentifier *
Alternatively, where applicable, an certified Identity Provider (such as an eID provider in EU, for example) could also provide the identifier contained in a signed token as a verifiable credential (format/schema agnostic), provided that the identity provider also includes information about the level of assurance value which indicates that the provider has validated the identifier and can provide assurances of its validity. Such identity provider must include organisationIdentifer as an attribute in the credential. For the format of such an identifier, please refer to Identity Provider role specifications in iSHARE Framework.
Therefore following shows the full format of the did:ishare identifier
did-ishare-format := did:ishare:<2 letter Continent code>.<ISO 3166-1 alpha-2>.<organizationIdentifier>
| # | Legal Entity Name | Country | Continent | ID | ID type | iSHARE DID |
|---|---|---|---|---|---|---|
| 1 | ABC Corp | Netherlands (NL) | Europe (EU) | 123456789 | NTR/CoC | did:ishare:EU.NL.NTRNL-123456789 |
| 2 | ABC Corp | Great Britain | Europe (EU) | NTRGB-12345678 | NTR scheme | did:ishare:EU.GB.NTRGB-12345678 |
| 3 | ABC Corp | United States ‐ California | North America | NTRUS+CA-12345678 | NTR scheme | did:ishare:NA.US.NTRUS+CA-12345678 |
| 4 | ABC Corp | Germany | Europe (EU) | VATDE-123456789 | VAT Scheme | did:ishare:EU.DE.VATDE-123456789 |
| 5 | ABC Corp | Belgium | Europe (EU) | PSDBE-NBB-1234.567.890 | PSD Scheme/NBB | did:ishare:EU.BE.PSDBE-NBB-1234.567.890 |
| 6 | ABC Corp | United States | North America | 54930067T9R7M9865D2M312 | LEI* | did:ishare:NA.US.54930067T9R7M9865D2M312 |
| 7 | ABC Corp | India(IN) | Asia | 335800684DF7433C5212 | LEI* | did:ishare:AS.IN.335800684DF7433C5212 |
[!NOTE:]
- LEI, is shown as example, however it is only usable when a trusted root issues qualified certificates with this value in it and that trusted root is also in the trusted list
A sample of did document can be generated based on the method explained above :
DID Document
{
"id": "did:ishare:EU.NL.NTRLNL-123456789"
}
Entries to the [[ref:ishare]] MUST follow requirements as per iSHARE framework specifications. The DID is derived and can be created automatically. The verification of the ID must follow requirements as laid down in iSHARE framework.
Since the DID only contains ID that is also retrieved from PKI certificate and/or provided by the certified party, anyone can create such an identifier as long as they meet the requirements of ID.
Reading of the DID is decoding the ID to retrieve the identifier and verify it against valid digital certificate and/or verifiable credential
Update to DID (ID) would mean it references another party and one cannot update an existing ID.
Not applicable as the ID is derived. However, the party status may be deactivated or their certificates revoked and this may be checked against the digital certificate or verifiable credential or in context of the framework against the registration in the certified participant registry.
Types of Attacks and Mitigations
Given that all data is public, the risk of unauthorized data interception (eavesdropping) is mitigated as the data is not sensitive by design.
Replay attacks are mitigated as the DID document does not contain any other information except for the ID itself. So every transaction must be validated and verified. Replay attacks during the verification and validation are beyond the scope of this specifications and must be addressed in specific designs.
By design any modifications to leads to referring to another identity and therefore the risks are mitigated as the verification will not match with the id in the digital certificate
Since users are not expected to host DID document anywhere, this risk is mitigated
Given that the DID has just the attribute of ID and the document is not hosted anywhere and by itself the DID is not trustable, hence no residual risks are foreseen
Any update to ID leads to either non-resolution or incorrect resolution (different identity) which will fail any verification checks being made, thereby mitigating this risk.
The security of the authentication method relies on digital signatures generated from the controller’s public keys.
It is forbidden to create a DID with an ID of a natural person. However, in some countries an organisation Identifier (usually for freelancers/sole proprietorships) is based on their national identification number (like, social security number, tax number, etc.). Therefore, it is recommended to users of this DID method to use DID’s with appropriate regulatory measures as applicable. For example, IDs of such parties established in the European Union are subject to GDPR regulations across the globe.
Since the transactions are to happen between two participants on an encrypted channel and there is no storage of the DID required, thereby mitigating this risk.
The DID is not expected to be stored, except for in combination with other data, where the security aspects of that solution would handle this issue. As such the DID data itself is public information hence no such risk is foreseen
Since DIDs are generated based on pre-existing identifiers, the risk of misattribution is low. However, if the issuer is compromised, it could lead to incorrect associations.
DID only contains ID that is already public information, hence no risk of disclosure is seen.
[DID-CORE]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/
[iSHARE Framework]
iSHARE is a collaborative effort to improve conditions for data-sharing for organizations. URL: https://framework.ishare.eu/