This document is not a W3C Standard nor is it on the W3C Standards Track. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The EOSIO Identity Working Group is an open working group where we, the EOSIO community, discuss identity on EOSIO chains and progress work such as this DID specification and it's implementation. We have a weekly meeting and a Slack channel.
Join the EOSIO Identity Working Group
Comments regarding this document are welcome. Please file issues and PRs directly on Github. Contributors are recognized through adding commits to the code base.
Contributors:
- Jack Tanner [email protected]
- Jonas Walter
- Julius Rahaus
- Sana Rauf | Block One
- Andres Gomez Ramirez | EOS Costa Rica
- Introduction
- Design Goals
- DID Method Schema: did:eosio
- DID Document
- Method Operations
- Security Considerations
- Privacy Considerations
- Reference Implementations
Self sovereign identity is an evolving Internet architecture for how applications store and process identity data. It is driven by the need for data privacy over personal information.
The architecture has two layers:
- Identity - the management of accessible public key infrastructure and identifies. Decentralized Identifiers is the W3C standard that allows this. Compliance with this standard allows application layers to interoperate without a need to understand the base layer decentralised protocols that power identities.
- Application - use of the identity layer to interact and provide meaningful, secure and verifiable data communications and interaction. The Verifiable Credentials W3C standard is the most prominent and adopted standard here which is a data structure and message protocol allowing people and organisations to securely and in a verifiable way send and verify information about themselves "credentials" to each other. DIDComm is another important application layer that uses DID methods to communicate between SSI identities.
On top of the application layer, use cases in industry can be built which are then interoperable and independent of base protocols. The standards focused heavily on data privacy and security.
More information:
- SSI Architecture Stack and Community Efforts
- Self Sovereign Identity
- Self-Sovereign Identity: The Ultimate Beginners Guide!
Decentralized Identifiers (DIDs) provide a standard data model to encapsulating unique identifiers and cryptographic material that can be used to interact, verify information from and contact entities. Each decentralised data layer protocol (such as EOSIO, Bitcoin, Hyperledger Indy) creates a DID Method Specification (not a W3C standard) which complies to the DID-core W3C standard. This DID Method Specification describes the compliance data model used by the data protocol to encapsulate a unique identifier and the cryptographic material.
The EOSIO blockchain platform is the next-generation, open-source platform with industry-leading transaction speed and a flexible utility. As a blockchain platform, EOSIO is designed for enterprise-grade use cases and built for both public and private blockchain deployments. EOSIO is customizable to suit a wide range of business needs across industries with role-based permissions system and secure application transactions processing.
Building distributed applications on EOSIO follows familiar development patterns and programming languages used for developing non-blockchain applications. For application developers, familiarity with the development environment results in a seamless user experience as it allows developers to use their preferred development tools.
The EOSIO platform provides functionalities such as accounts, authentication, databases, asynchronous communication, and the scheduling of applications across multiple CPU cores and clusters. These functionalities are also common in non-blockchain software development environments.
Some of the groundbreaking features of EOSIO include:
- WebAssembly C++ Compilation
- High Throughput and Low Latency (0.5s block time)
- Customizable Resource Model
- Efficient and Flexible Persistent Data Indexing
- Support for Human Friendly Account Names
- Hierarchical Role Based Transparent Permissions
- Transparent and Synchronous Smart Contract Upgradability
- Transparent and Synchronous Protocol Upgradability
- On-chain Governance
- Efficient Energy Consumption
- Webauthn and Biometric Hardware Secured Keys Support
The EOSIO technology ecosystem has been adopted by approximately 20 public blockchain is and over 100 private blockchains (source). This includes a wide variety of industry applications.
The growing SSI ecosystem is being adopted by industry and governments alike. Decentralised identifiers are the key layer in the SSI tech stack to be included in this ecosystem. EOSIO presents a number of unique advantages for managing self sovereign identity solutions, including its account and key structure and highly flexible governance features. This DID Method Specification allows EOSIO to enter this ecosystem through compliance with the standards, bringing the following benefits:
- Interoperability with the rest of the SSI ecosystem. This allows EOSIO based identities to be consumed by governments and industries alike. It provides external interoperability outside of EOSIO.
- Interoperability with other EOSIO based identities. Due to the large number of EOSIO chains this could be a great way to strengthen the collaboration between all of these projects.
- Provide transparency of identities through standardisation.
- Improve security and privacy by bringing the SSI architecture model to EOSIO identity systems. This architecture ethically protects human rights while reducing cumbersome data regulation liability from organisations.
The EOSIO account abstraction is unique within the blockchain industry. There are two features relevant for a DID method:
- Account names are not bound to cryptographic material. Accounts names are chosen by the creator of the account, which may or may not be the entity that controls the account. Account names are short strings up to 13 characters making them memorisable.
- Each account can have one or more public-private key pairs which can be used to authorise and assert data about that account. Keys are organised in a hierarchy tree, with human friendly labels for the permission name. Key material can be delegated to another EOSIO account. A weighted multi-signature scheme can be used. See combination.eosio.json for an example of a typical EOSIO account's key structure that includes both delegated and multi-signature requirements in the hierarchical tree.
This key material and structure needs to be expressed in the "verificationMethod" property of the EOSIO DID Document. Numerous conversations have and are still taking place to create a DID compatible method spec. The result of this has been to create a new verification method type called Verifiable Conditions which has been drafted and is being reviewed by the W3C Credentials Community Group.
More information:
- EOSIO Accounts and Permissions
- DID core issue 963: Support for threshold multi-sig verificationMethod
- DID core issue 964: Support for delegated verificationMethods
- DID core issue 965: Support for combination of threshold multi-sig and delegated verificationMethod
- DID core - multisig and delegated use case
- Verifiable Conditions
The EOSIO protocol is the set of rules within the system cryptographically enforced and historically auditable through a peer to peer network of computer nodes (servers). Fairly unique to the EOSIO protocol is that a large degree of these rules are defined in smart contract that live on the blockchain and can be highly-customised and upgraded over time (source).
In this way, each EOSIO blockchain can have significantly different rules while staying protocol compatible at the peer to peer network layer.
Account creation and updates to account permissions (keys and delegates) are part of the rules defined through smart contracts. This means that different EOSIO chains will have different DID method operations (Create, Read, Update, Deactivate).
To achieve the design goals, the EOSIO DID method specification implementation SHOULD be generic and provide the default EOSIO method operation CRUD features while also allowing these to be customised by consumers of the implementation (through a constructor or options parameters in function calls). "Implementation" and "consumers" of this implementation will be the terminology used to explain how this design goal is achieved.
In practice, this means that the DID implementations should be imported and the DID create, update and deactivate functions should be overloaded as needed for the EOSIO blockchain. This should be done instead of forking the implementations to create more modular software and reduce upstream dependency mismatch issues.
More information:
The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
The design goals of the EOSIO DID Method Specification are to:
- Create a method spec that can be used for all blockchain powered by the unmodified EOSIO protocol. Blockchains that have modified the EOSIO protocol are not explicitly supported, but may still be compatible and use this method spec if there have not been any incompatible changes to the EOSIO protocol such as the account, permissions and key features.
- Support all relevant and non-depreciated features of EOSIO from version 2.0 (time weight permissions are not supported).
- Support public (EOS, Telos, Europechain, WAX and more), private and hybrid permission EOSIO blockchains.
- Stay as close to the EOSIO protocol as possible, do not introduce EOSIO chain specific features to the method.
- Avoid the need for EOSIO compatible chains to register separate official DID Methods. Due to the ever expanding number of EOSIO chains, this could quickly be a large number and would cause problems to the way DIDs are registered and consumed in the SSI ecosystem.
The EOSIO method-specific DID schema allows for two distinct method-specific-id schemata.
- Registered chain name schema
- Chain-id schema
While one uses the plain chain-id, represented as a generic hash-based identifier for a specific chain, the other utilizes a pre-registered human readable chain name that acts in a similar fashion to domain names and only points toward the actual chain-id. In both cases the chain specific identifier is followed by the name of an account on that chain, separated by a colon.
did:eosio:{chain_id/registered_chain_name}:{account-name}
Due to the strict requirements registered chain names have to adhere to, a clash with the chain id schema is impossible.
These are the properties that make up an EOSIO DID:
{registered_eosio_name}is a pre-registered name of the EOSIO chain consisting of one or more colon separated name blocks, each complying to the EOSIO account name type (one to thirteen lowercase English characters a-z, period . or digits 1-5). This should be registered in the below table and additionally in the EOSIO DID chain method json registry, including at least one service.{account_name}is the name of the account on the chain, also of EOSIO account name type type.{chain_id}is the hash of the genesis block of the chain, expressed in a 64 character string representing a hexadecimal number.
All property schemas are provided with a Regex specification.
did:eosio:{registered_eosio_name}:{account_name}
registered_eosio_name = ([a-z][1-5].){1,13}(:([a-z][1-5].){1,13})*
account_name = ([a-z][1-5].){1,13}
e.g. did:eosio:telos:example
Each chain name may consist of multiple name blocks, separated by colons. This could be used to represent hierarchical relationships as in domains and subdomains.
e.g. did:eosio:eos:testnet:jungle:example
Registered EOSIO chain summary:
| Registered EOSIO Name | Chain Id |
|---|---|
| eos | aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906 |
| eos:testnet:jungle | 2a02a0053e5a8cf73a56ba0fda11e4d92e0238a4a2aa74fccf46d5a910746840 |
| telos | 4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11 |
| europechain | f778f7d2f124b110e0a71245b310c1d0ac1a0edd21f131c5ecb2e2bc03e8fe2e |
did:eosio:{chain_id}:{account_name}
chain_id = ([a-z][0-9]){64}
account_name= ([a-z][1-5].){1,13}
e.g. did:eosio:4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11:example
(equivalent to did:eosio:telos:example)
There is no standardised path schema yet, but there could be in the future.
There is no standardised query schema yet, but there could be in the future.
Fragments are used to dereference a DID URL to a specific verification method. Fragments for the EOSIO DID Method are used to identify the EOSIO permission name primarily. They can be additionally used to specify sub verification methods within a permission with indexes.
The fragment string must begin with the permission name. You can optionally present indexes to look directly into the permission structure. Indexes are unsigned integers starting at 0.
If a fragment is provided and the permission does not exist in the resolved account, an error MUST be thrown. e.g. #active framement for an account with no "active" permission.
If a fragment is provided with indexes which do not exist within the permission of the resolved account, an error MUST be thrown. e.g. #active-1 framement for an account with an "active" permission that only has one key for authorization (not two).
Fragments can be used with either of the DID methods schemas.
did:eosio:{chain_id}:{account_name}#permission_name}-{index_1}-{index_2}-...-{index_N}
did:eosio:{registered_eosio_name}:{account_name}#{permission_name}-{index_1}-{index_2}-...-{index_N}
registered_eosio_name = ([a-z][1-5].){1,13}
chain_id = ([a-z][0-9]){64}
account_name = ([a-z][1-5].){1,13}
permission_name = ([a-z][1-5].){1,13}
index = (\d+)
e.g. did:eosio:telos:example#active
e.g. did:eosio:4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11:example#active
(both equivalent)
e.g. did:eosio:telos:example#active-2-0
e.g. did:eosio:4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11:example#active-2-0
(both equivalent)
As described in the 3. DID Method Schema: did:eosio.
The "subject" property does not need to be specified as it is always equal to the DID.
The "controller" property SHOULD NOT be set. Information regarding eosio top level permission will be included inside the verification methods.
The verification Methods are populated using information from the EOSIO account's permission structure. This can be obtained by requesting the accounts data from any of the API services using the nodeos get_account API call.
This permission data is presented in the DID document using the draft "VerifiableCondition" type. This new verification type is a current work item by the W3C credentials community group and is expected to become a W3C standard.
If the account permission contains a threshold greater than one with one or more keys/delegations with a weight of more than one, then the verification condition MUST use a "conditionWeightedThreshold" property as seen in example 5.1.2 Multi-sig delegated account.
If the account permission contains a threshold greater than one and all weights are 1, then the verification condition MAY use the "conditionThreshold" property instead of "conditionWeightedThreshold".
If the account permission contains a threshold of 1 with more than one key/delegation, then the verification condition MAY use "conditionOr" property instead of "conditionThreshold". An example is seen in 5.1.1 Simple account.
If the account permission contains a threshold of 1 with only one delegation and no keys, then the verification condition MAY use "conditionDelegated" property instead of "conditionDelegated".
All permissions except the root permission MUST have the "relationshipParent" property sets to the parent property DID URL with fragment.
EOSIO uses several key types for authorization. The public key is stored on chain. When an account's information is requested, the keys are part of the permissions array. In EOSIO client SDKs, the keys can be read as a single string with a prefix with their type. The SDK and other libraries can be used to extract the relevant material needed to map the key into a verification method object. The table below shows the string prefixes and the corresponding verification method type to use:
| EOSIO key prefix | Verification Method type | Key format |
|---|---|---|
| EOS_ (legacy) | EcdsaSecp256k1VerificationKey2019 | publicKeyJwk with "crv" = "secp256k1" |
| PUB_K1_ | EcdsaSecp256k1VerificationKey2019 | publicKeyJwk with "crv" = "secp256k1" |
| PUB_R1_ | JsonWebKey2020 | publicKeyJwk with "crv" = "P-256" |
| PUB_WA_ | JsonWebKey2020 | publicKeyJwk with "crv" = "P-256" |
K1 key types MUST use the official EcdsaSecp256k1VerificationKey2019 material type. The key material MUST be represented with in a Json Web Key with the "publicKeyJwk" property.Example:
{
"id": "did:eosio:telos:example#active-1",
"controller": "did:eosio:telos:example",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyJwk": {
"crv": "secp256k1",
"x": "NtngWpJUr-rlNNbs0u-Aa8e16OwSJu6UiFf0Rdo1oJ4",
"y": "qN1jKupJlFsPFc1UkWinqljv4YE0mq_Ickwnjgasvmo",
"kty": "EC"
}
}The R1 and WA key types both use the Secp256r1 (sometimes referred to as P-256) elliptic curve. It is similar to the Secp256k1 curve as explained here. The R1 and WA key types MUST use the official JsonWebKey2020 material type. The key material MUST be represented with in a Json Web Key with the "publicKeyJwk" property. Example:
{
"id": "did:eosio:telos:example#active-1",
"controller": "did:eosio:telos:example",
"type": "JsonWebKey2020",
"publicKeyJwk": {
"crv": "P-256",
"x": "yLSTsJxPc76EHc0RKdxnT+726KHa7jkgUnHejK3ULSE",
"y": "6HB9sZjpi69VqpCt68BuHOUadA4aaUf2iPdmuUxFY00",
"kty": "EC"
}
}For more background on EOSIO key types for the DID Document see Issue #5
If an account permission delegates to another account, a verification method of type "VerifiableCondition" MUST be used with the "conditionDelegated" property set to the DID URL of the other EOSIO account's verification method corresponding to the delegated permission.
An example is seen in 5.1.1 Simple account.
The way in which EOSIO account permissions are used is not specified in the protocol and cannot be extracted from the EOSIO blockchain. It is expected that applications that consume an EOSIO DID Method implementation will know more information about how the verification methods are used. This also applies to specific blockchains that consume the implementations.
Consumers of the EOSIO DID Method implementation are RECOMMENDED to extend the DID Document's verification relationships with lists of fragments that point to verification methods adequate for relationships.
At least one service SHOULD exist on a DID Document of LinkedDomains type. This can be used to resolve the DID and connect to the EOSIO chain through a supported API.
Registered EOSIO chain names should add at least one service in the EOSIO DID chain method json registry.
{
"eos:testnet:jungle": {
"chainId": "2a02a0053e5a8cf73a56ba0fda11e4d92e0238a4a2aa74fccf46d5a910746840",
"service": [
{
"id": "https://jungle3.cryptolions.io",
"type": "LinkedDomains",
"serviceEndpoint": "https://jungle3.cryptolions.io"
}
]
}
}See the EOSIO DID chain method json registry for more examples.
{
"@context": ["https://www.w3.org/ns/did/v1",
"https://raw.githubusercontent.com/Gimly-Blockchain/eosio-did-spec/master/eosio-did-context.json"],
"id": "did:eosio:telos:example",
"verificationMethod": [{
"id": "did:eosio:telos:example#owner",
"controller": "did:eosio:telos:example",
"type": "VerifiableCondition2021",
"conditionOr": [
{
"id": "did:eosio:telos:example#active-1",
"controller": "did:eosio:telos:example",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyJwk": {
"crv": "secp256k1",
"x": "NtngWpJUr-rlNNbs0u-Aa8e16OwSJu6UiFf0Rdo1oJ4",
"y": "qN1jKupJlFsPFc1UkWinqljv4YE0mq_Ickwnjgasvmo",
"kty": "EC"
}
}
],
}, {
"id": "did:eosio:telos:example#active",
"controller": "did:eosio:telos:example",
"type": "VerifiableCondition2021",
"conditionOr": [
{
"id": "did:eosio:telos:example#active-1",
"controller": "did:eosio:telos:example",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyJwk": {
"crv": "secp256k1",
"x": "IF/eIukZZ8lixpp57o7vgAm8qN1Z3Nf+6AM67o2o6FS",
"y": "VJfQeWtL5LIs5JAri44RvQ77nq5tRg50lvQHZT7smal",
"kty": "EC"
}
}
],
"relationshipParent": "did:eosio:telos:example#owner",
}]
}{
"@context": ["https://www.w3.org/ns/did/v1",
"https://raw.githubusercontent.com/Gimly-Blockchain/eosio-did-spec/master/eosio-did-context.json"],
"id": "did:eosio:telos:example",
"verificationMethod": [{
"id": "did:eosio:telos:example#owner",
"controller": "did:eosio:telos:example",
"type": "VerifiableCondition2021",
"threshold": 3,
"conditionWeightedThreshold": [{
"weight": 1,
"condition": {
"id": "did:eosio:telos:example#owner-0",
"controller": "did:eosio:telos:example",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyJwk": {
"crv": "secp256k1",
"x": "NtngWpJUr-rlNNbs0u-Aa8e16OwSJu6UiFf0Rdo1oJ4",
"y": "qN1jKupJlFsPFc1UkWinqljv4YE0mq_Ickwnjgasvmo",
"kty": "EC"
}
}
}, {
"weight": 2,
"condition": {
"id": "did:eosio:telos:example#owner-1",
"controller": "did:eosio:telos:example",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyJwk": {
"crv": "secp256k1",
"x": "IF/eIukZZ8lixpp57o7vgAm8qN1Z3Nf+6AM67o2o6FS",
"y": "VJfQeWtL5LIs5JAri44RvQ77nq5tRg50lvQHZT7smal",
"kty": "EC"
}
}
}, {
"weight": 2,
"condition": {
"id": "did:eosio:telos:example#owner-2",
"controller": "did:eosio:telos:example",
"type": "VerifiableCondition2021",
"conditionDelegated": "did:eosio:telos:example2#active"
}
}
]
}, {
"id": "did:eosio:telos:example#active",
"controller": "did:eosio:telos:example",
"type": "VerifiableCondition2021",
"relationshipParent": "did:eosio:telos:example#owner",
"threshold": 1,
"conditionWeightedThreshold": [{
"weight": 1,
"condition": {
"id": "did:eosio:telos:example#active-0",
"controller": "did:eosio:telos:example",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyJwk": {
"crv": "secp256k1",
"x": "ymK3uZFQRP55ZII5eUc4hAxFgLTBy3eWgbllMoBm4nD",
"y": "xFgLTBy3eWgbllMoBm4nD9Jqo249Mj_mjjJt6fFUCGI",
"kty": "EC"
}
}
}
]
}]
}EOSIO accounts are created with an on-chain transaction. The default is to call the "newaccount" action on the system contract from an existing account on the blockchain. This action can be changed on each EOSIO chain, and upgraded over time. For some EOSIO systems, the on-chain account creation process is not openly accessible, and users will use a different mechanism (such as an email and password request to an organisation) to create an account.
Implementations of the EOSIO DID Method SHOULD implement the create operation according to the default "newaccount" action defined in the eosio.bios contract. This function SHOULD be polymorphic and can be overridden by a consumer of the implementation. It is recommended that the EOSIO DID implementation constructor, or an options parameter can be used to achieve this.
Consumers of a EOSIO DID Method implementation SHOULD override the default create behaviour if a different mechanism exists to create an EOSIO DID.
Resolution of a DID Document can be done by a service API. This may be an authorised or rate limited API. There are different types of EOSIO APIs as outlined in Service Types.
Placeholder: Description of method of creating an authorized (permissioned) read request with private EOSIO blockchains in mind.
EOSIO account's permissions are updated with an on-chain transaction. The default is to call the "updateauth" action on the system contract from your account. This action can be changed on each EOSIO chain, and upgraded over time.
Implementations of the EOSIO DID Method SHOULD implement the update operation according to the default "updateauth" action defined in the eosio.bios contract. This function SHOULD be polymorphic and can be overridden by a consumer of the implementation. It is recommended that the EOSIO DID implementation constructor, or an options parameter can be used to achieve this.
Consumers of a EOSIO DID Method implementation SHOULD override the default update behaviour if a different mechanism exists to update an EOSIO DID.
EOSIO blockchains do not have a default mechanism to deactivate accounts.
Implementations of the EOSIO DID Method SHOULD implement a deactivate function which throws an error. This function SHOULD be polymorphic and can be overridden by a consumer of the implementation. It is recommended that the EOSIO DID implementation constructor, or an options parameter can be used to achieve this.
Consumers of a EOSIO DID Method implementation SHOULD override the default update behaviour if a different mechanism exists to deactivate an EOSIO DID.
Europechain is an example of EOSIO blockchain with a deactivated feature.
For public EOSIO blockchains, all transactions, history and stateful information is public.
For private and hybrid EOSIO blockchains, access to the data via API or P2P protocol are limited and permission based depending on the blockchain. Private EOSIO blockchains SHOULD use encrypted data transport between clients and nodes.
All EOSIO DID method default operations are done through an on-chain transaction are protected by including the blockchain's chain id and a recent block header hash in the transaction (called Transaction as Proof of Stake).
EOSIO DID consumers MAY override the method operations with off-chain mechanisms which may be susceptible to replay attacks. This only applies to permissioned EOSIO blockchains.
All EOSIO DID method default operations are done through an on-chain transaction and signed by the accounts authorized private key. There is no way for a party without these keys to act on behalf of the DID.
Note that EOSIO accounts may delegate authorisation control to other EOSIO accounts on the same blockchain, who are then authorised to send certain transactions on behalf of them. This consent is done through a transaction on chain and must be signed by an existing authorised key of the EOSIO account. Delegation can be revoked at any time by the EOSIO account.
EOSIO DID consumers MAY override the method operations with off-chain mechanisms which may be susceptible to message insertion attacks. This only applies to permissioned EOSIO blockchains.
Deletion is not a feature of the EOSIO P2P protocol.
Functionality to allow users to delete their account can be superimposed over the chain at the API level (such as what is done by Europechain). In such a case, the deletion mechanism will be controlled by such an implementation (for Europechain, deletion is an on-chain transaction signed by the EOSIO account's authorized keys)
All EOSIO DID's updated through an on-chainon-chain transaction signed by the accounts authorized private key. There is no way for a party without these keys to act on behalf of the DID.
Note that EOSIO accounts may delegate authorisation control to other EOSIO accounts on the same blockchain, who are then authorised to send certain transactions on behalf of them. This consent is done through a transaction on chain and must be signed by an existing authorised key of the EOSIO account. Delegation can be revoked at any time by the EOSIO account.
EOSIO DID consumers MAY override the method operations with off-chain mechanisms which may be susceptible to modification attacks. This only applies to permissioned EOSIO blockchains.
All EOSIO DID method default operations are done through an on-chain transaction signed by the accounts authorized private key. An attacker that gains access to a signed transaction message before it is submitted, cannot duplicate this on the same or other chains due to uniqueness in the transaction that is checked for uniqueness by the EOSIO protocol. Each transaction has an expiration time, usually set to 30 seconds, and the attacker may choose to delay the submission of this transaction up until the expiration time.
The ability to limit the service of an EOSIO blockchain depends on its infrastructure, governance structure and server API figuration. DID controllers and subjects should be aware of these fundamentals to assess the security of the system.
Infrastructure can be centralised or decentralised.
Blockchains can be configured to have multiple independent organisations that run EOSIO peer nodes. More independence block producers running infrastructure increases infrastructure availability reducing service outages and reduces governance attacks (discussed next).
Each node can also be configured to have redundancy capacity through the blockvault_client_plugin. This can be used for centralised blockchains, or for individual block producers in a centralised blockchain.
The EOSIO protocol and DID method is governance agnostic. EOSIO blockchains can be Proof of Authority (default), Proof of Stake, Delegated Proof of Stake and more (source) modifying the system contract.
An EOSIO blockchain can be attacked by vulnerabilities in the governance model. Examples:
- block producers that run a Proof of Authority blockchain may be bribed
- block producers slots for a Proof of Stake blockchain can be bought
- block producers slots for a Delegated Proof of Stake blockchain can be bought
If enough of the EOSIO blockchain governance is compromised, the blockchain service as a whole may be compromised. DID subjects and controllers should feel comfortable with the governance model of the EOSIO blockchain they are using. EOSIO blockchains may use internal or external regulation to enforce protection of their governance system.
Privileged EOSIO account are able to submit transactions to the EOSIO blockchain that bypass signature validation checks (source). The intention of this feature is to be used to administer the blockchain in consensys with all of the operators of the EOSIO chain. Such an administration task may be recovered a users account in the event they lose their private key.
Each EOSIO chain implements what accounts are privileged and what privileged actions they can perform. This is limited to be accessible only by the current block producers and only in consensus.
By bypassing signature validation checks, privileged accounts can submit transactions on behalf of any other account on the same EOSIO blockchain. This includes updating the DID Document. It is for this reason that the governance of the EOSIO chain must be trusted.
If an API service fails completely, a DID will need to find another service to connect to the EOSIO blockchain.
The system's overall security and integrity can only be as good as the DID controller's ability to manage private keys. This is made easier with the ability for wallets to create hierarchies of keys and complex structures. This is still a difficult problem for organizations and people.
In a public EOSIO network, all communication is visible by watching the blockchain. In a private network both the peer-to-peer and the node to client communication should be encrypted to ensure data surveillance protection.
The DID Document data and history is stored in the blockchain state and can be done through access to a synchronising EOSIO blockchain node in the network. In a public network, this can be done through public node APIs or by running a node that synchronises with the public network. A private network has restrictions on the peer-to-peer synchronisation and APIs.
Create, update and (if supported) deactivate DID operations require transactions signed by the private keys only owned by the DID controller and cannot be forged. Public API nodes do not identify read operations to DIDs, and may receive unsolicited traffic from unintended parties. Public and private APIs do enforce IP or registered API account based rate-limiting to ensure service is not affected by this.
Create, update and (if supported) deactivate DID operations require transactions signed by the private keys only owned by the DID controller and cannot be forged.
The DID Document data and history is stored in the blockchain state and can be done through access to a synchronising EOSIO blockchain node in the network. State and historic data from interaction of the DID with smart contracts on the blockchain is also accessible through a blockchain node which can be directly correlated with the DID. It is therefore important for DID users to carefully consider what applications they use that have on-chain data to the blockchains.
Private blockchains will ensure that this correlation cannot be done publicly, but can still be done between permissioned and peer-to-peer nodes.
If personal information is added to the blockchain, potentially a viable credential, this can be permanently accessed through access to a synchronising EOSIO blockchain node in the network. With enough identifying information, an identity can be deduced.
For this reason, it is very strongly suggested that personal information is not added to the blockchain, even in private networks.
EOSIO blockchain software does not make secondary use of transaction data other than for the purpose of synchronising the blockchain and maintaining the state.
DID users should carefully consider blockchain applications, which may store additional information about the DID, the identity of the DID and other data in off-chain data storage systems. Application providers should clearly state data storage policy and purposes and users should consider this when deciding to use such applications.
DID users of public blockchains should understand that on-chain data is public and does not have limitations on its use or disclosure.
Private blockchains may enforce data privacy restrictions which should be stated and considered by the DID user.
DID users of public blockchains should understand that on-chain data is public and does not have limitations on its use or disclosure.
Private blockchains me support the ability for DID users to control exclusion of their data. This is done on a per-blockchain basis.
| Name | Language | Package | Repository |
|---|---|---|---|
| DID Resolver | Javascript | npm package | https://github.com/Gimly-Blockchain/eosio-did-resolver |
| DID Operations (CRUD) | Javascript | npm package | https://github.com/Gimly-Blockchain/eosio-did |
| Universal Resolver Driver | Docker | Docker Hub | https://github.com/Gimly-Blockchain/eosio-did-universal-resolver-driver |