Today, Smart Identity uses the Ethereum blockchain to represent an identity using a smart contract, attributes can be added by the identity owner and are stored in hash form. Attributes can be endorsed by any user, this is done by storing a corresponding endorsement hash against the attribute hash. Endorsements are revocable and are considered current if not revoked.
To verify underlying attribute and endorsement data, corresponding hashes must be computed, and their presence verified within the corresponding identity contract.
Attributes and endorsements are formed of field sets, merkle-root hashes are used to allow sharing and verification of partial data (such as date of birth within a driving license).
Smart ID is a platform that uses Ethereum and solidity smart contracts as a framework for its core protocol. A spring boot java application has been implemented to showcase how the protocol works and acts as an interface to the blockchain. Initial smart contracts written have been written in Solidity to the Solidity 0.4 specification. http://solidity.readthedocs.io/en/develop/.
xcode-select --install) and brew install libgcryptsudo apt-get install build-essential python-software-properties libssl-dev# Get the latest snapshot
#https
git clone https://github.com/SmartIdentity/smartId-contracts.git
#ssh
git clone git@github.com:SmartIdentity/smartId-contracts.git
# Change directory
cd openprep
# Install NPM dependencies
npm install
In a separate terminal run:
./node_modules/.bin/testrpc
to spin up a test blockchain (it doesn't mine, just runs and parses the commands sent to it).
It listens on the default RPC interface of localhost:8085, so you could also run against geth, or any other web3 enabled RPC.
Testrpc is designed to provide fast feedback, without rinsing your processor.
You can then execute the following functions:
truffle compile - checks that the contracts compile and there are no errors. Run this to setup the contract before truffle console.truffle console - spins up an interactive shell to interrogate the blockchaintruffle test - runs the unit tests in against testrpcThe vision for Smart Identity is to enable a universal platform for identity representation and verification, enabling people, organisations, IoT devices, Dapps, or anything else, to obtain, use and verify identity information with minimal reliance on centrally provided systems or services.
Such an outcome offers considerable social and economic advantage; in developing economies the ability to obtain credible identity offers value outright, whilst in developed economies the vision addresses higher-order efficiency and user experience imperatives by standardising the technical framework within which any identity artefact can be represented, shared and verified.
Beyond traditional identity data, a Smart ID is intended to serve as a container (wallet) for digital assets owned by an identity, for contracts an identity is party to, and as a controller to identity linked Dapps.
To offer global utility, Smart Identity should:
The Smart Identity construct uses an attribute-endorsement model enabled by the use of smart contracts which provide rudimentary role based permissions. An identity-owner can attest that an 'attribute' is a correct representation of a part of their identity (by storing a corresponding hash value within their identity), following which third parties are able to attest to the validity of each attribute (by storing a corresponding hash value against the attribute within the identity)
This is the Smart Identity contract as used by the Smart Identity instance. It describes the core functionality required as part of a Smart Identity contracts with encryption keys, attributes & endorsements.
A Smart ID is an Ethereum Smart Contract address. The smart contract must be constructed using valid Smart ID bytecode. It provides access to identity management commands and stores hash representations of identity data.
The Smart Contract has a constructor that defines the owner and core elements of the identity:
This contract holds a curated list of valid contracts that Deloitte (or any other registrar, there are no barriers to entry) have approved as valid implementations of Smart Identity. These are curated by hashing the bytecode of a known good contract. This should be maintained as a list on the Blockchain so that other contracts can perform (optional) real-time verification that a contract is present on this list, and therefore a valid smart identity. There may be multiple statuses on this registry (initially Pending / Accepted / Rejected) so that the contracts can be better maintained.
An Attribute is a specific instance of an attribute template which has been populated and (the corresponding hash) stored within a Smart ID.
If verification of attribute field subsets is required, for instance to use a digital driving license in order to prove age but not disclose address, the attribute hash should be the merkle root of the attribute field set (with appropriate salt or RND values applied at the leaf node level to prevent reverse engineering of leaf node hash values).
The attribute hash corresponds to an attribute record stored off-chain, which consists of at least:
Attribute creation/update/removal transactions can only be submitted by the identity owner.
An endorsement is a notarised record of attestation by a third party in relation to a specified attribute, stored with the attribute within the identity contract. Our initial implementation uses a single endorsement template. The definition of what 'endorsement' means for a given attribute can also be varied within the underlying attribute definition to provide some flexibility.
Receivers/consumers of identity data may (should) privately manage the Endorser identities they are prepared to trust.
The endorsement hash corresponds to an endorsement record stored off-chain, which consists of at least:
Whilst attributes can only be added by an identity owner, endorsements must be added anonymously from previously unused ethereum public keys. This is to preserve privacy and prevent unwanted identification of an endorsing party. This will also allow endorsements to be created 'off chain', and added in by the owner themselves, providing the signature of the endorsement can be verified against an on-chain Identity. The unrestricted ability to add endorsements presents a risk of spam or unwanted endorsements, for which there are a number of potential solutions, and for which future protocol updates may be introduced.
Given that an attribute has been endorsed by a trusted third party, the weight of that endorsement is what adds value to the attribute. An attribute without endorsement requires complete trust in the identity. For the benefit of the ecosystem, each time a user chooses to trust such an attribute, they should endorse the fact that they trust it.
The challenge lies in providing the transparency of endorsement types, if not endorsement people. For example, if I simply endorse a driving licence for the purpose of identifying a person qualfies for entry into a nightclub, then that same endorsement should hold far less weight on whether a person is entititled to drive. To that end I should only endorse the attributes of the driving licence that I have relied upon for my judgement, and rarely the document as a whole.
An Attribute Template can describe either a single field, or collection of fields representing a logical set of identity data.
Attribute templates are created and stored within the Smart Identity application instance (see Admin Microservice below).
The model for templates should follow that of jsonschemaform - whereby the definition of the form is kept in the attribute.
Whilst bespoke attribute templates can be configured for any purpose (consider an attribute template as a data collection form which facilitates personal data notarisation), it is expected that common attributes (e.g. driving license) will be standardised and endorsable, and in time repositories of common templates will be curated and shared for common reference.
The distributed ledger and identity smart contract form just one layer in the Smart Identity ecosystem, outside of this layer, numerous applications support the various off-chain storage and processing tasks needed during interaction with the blockchain. Operators are free to use alternative components, however Deloitte have developed a reference application formed of various capability microservices, and have begun a process of porting these into the opensource repository, components include:
This code is released under the Apache v2 open source licence.
We've launched the core Smart Contracts of SmartIDentity to allow third parties to start coming up with their own implementations of Smart Identity.
Please help by coming up with ways in which you could implement Smart Identity, share your ideas with us on the issues tab (first check the Use Cases list below in case we have already added it), and help us make sure that the solidity code is secure.
We've created two use cases in the test/scenario/ folder, to give an example of how Smart Identity could be used. Please add in some example tests of your own that either help support Smart Identity, or that come up with use cases that we need to think about further.
Direct your questions to the GitHub issue tracker, and we will endeavour to respond.
Understand the vision. Review and experiment with the code. Contribute to the design and build process.
We encourage all contributors and welcome all constructive input. By opening the project we reduce the barriers to access, and expose it to an exponentially expanding pool of rich and diverse brainpower; we do this to attract an open and collaborative community intended to validate, inform and accelerate the further development, testing and hardening of core components, and ultimately to build momentum for widespread adoption.
To contribute, please follow the process outlined below.
—
$ claude mcp add smartId-contracts \
-- python -m otcore.mcp_server <graph>