Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Sign-in with Ethereum (SIWE) is an open standard for decentralized authentication that allows users to sign in to websites and applications using their Ethereum accounts. Unlike traditional centralized authentication methods, this innovative approach allows users to access various online services and applications using their Ethereum wallet address and cryptographic keys. This groundbreaking login solution represents a significant step forward in the evolution of decentralized identity management, empowering users with enhanced privacy and ownership of their digital identities.
The Ethereum Foundation and Ethereum Name Service (ENS) had put forward a Request for Proposal for Sign-in with Ethereum in 2021, based on EIP-4361 (ERC-4361: Sign-In with Ethereum). The reference implementation of Sign-In with Ethereum by SpruceID (SpruceID ) provides an easy integration with Application’s Identity services and assures smooth Sign-In user experience. It has numerous benefits over other PKI based signatures, such as :
A standard human readable verifiable message to confirm signatures.
An EIP-standard message schema to incorporate all the information needed for a secure authentication.
Verification for domain and uri, this assures the authenticity of the requester / verifier. Users can validate the domain the transaction was initiated from and the URI to which the access would be provided to (redirection) upon signing for authentication / authorization.
Preventing replay attacks with a nonce, which could be a challenge from a server or a random token .
authority is the RFC 3986 authority that is requesting the signing.
address is the Ethereum address performing the signing conformant to capitalization encoded checksum specified in EIP-55 where applicable.
statement (optional) is a human-readable ASCII assertion that the user will sign, and it must not contain '\n' (the byte 0x0a).
uri is an RFC 3986 URI referring to the resource that is the subject of the signing (as in the subject of a claim).
version is the current version of the message, which MUST be 1 for this specification.
chain-id is the EIP-155 Chain ID to which the session is bound, and the network where Contract Accounts must be resolved.
nonce is a randomized token used to prevent replay attacks, at least 8 alphanumeric characters.
issued-at is the ISO 8601 datetime string of the current time.
expiration-time (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message is no longer valid.
not-before (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message will become valid.
request-id (optional) is an system-specific identifier that may be used to uniquely refer to the sign-in request.
resources (optional) is a list of information or references to information the user wishes to have resolved as part of authentication by the relying party. They are expressed as RFC 3986 URIs separated by "\n- ".
Given all these advantages, Sign in with Ethereum proved to be an ideal choice for Energy Web in implementing authentication for our decentralized applications (DApps). Authentication with SIWE is supported by our Passport strategy (available in passport-did-auth from v2.0.0 ).
A signature request with Metamask SIWE will look something like :
Note: The text block in the above MetaMask pop-up for signing is the SIWE message.
During each session initiation, it is crucial to select a nonce with sufficient entropy to thwart replay attacks – a type of man-in-the-middle attack where an adversary intercepts the user's signature and uses it to initiate a new session on their behalf.
To ensure security, implementers have the option to utilize privacy-preserving but readily accessible nonce values. For instance, they may consider using a nonce derived from a recent Ethereum block hash or a recent Unix timestamp. These methods offer a balance between safeguarding privacy and ensuring widespread applicability.
Wallets are required to verify that the domain aligns with the actual source of the signing request.
It is recommended to cross-check this value with a trusted data source, such as the browser window, or through another reliable protocol. By doing so, wallets can enhance security and mitigate potential risks associated with fraudulent or unauthorized signing requests.
Many organizations aim to deploy a unified Identity Service that can be utilized across all federated services, employing OpenID Connect for efficient user session management. Thanks to SIWE-OIDC (OpenID Connect Identity Provider for Sign-In with Ethereum), this objective has now become achievable.
SpruceID has deployed an OpenID Connect Provider (OP) which has support for SIWE and hosted under SIWE Open ID Connect . This deployment is a DAO-governed OP supported by ENS DAO.
To use the hosted OIDC server it is required to register the application as an OIDC client using the OIDC client registration of SIWE Open ID Connect . Currently, no user interface for OIDC client registration is supported. For that reason, developers will need to use the REST API.
The following is an example response:
A client can then be updated or deleted using the registration_client_uri with the registration_access_token as a Bearer token. The authentication could be similar to
Note : This flow is just a possible flow, it could be different for a different use case.
Apart from the existing functionalities offered by SIWE, there is potential for future extensions, including support for Decentralized Identifiers and Verifiable Credentials, as well as integration with EIP-712 for Type structured data hashing and signing.
In the context of EW-DOS, an Asset is a digital representation of a physical or virtual device on the . An Asset could represent, for example, a solar photovoltaic panel, a battery, an electric vehicle, or an IOT device.
Assets must have a in the Energy Web Chain's in order to participate in applications and marketplace activities. Once an Asset has a DID, it can take on roles within an organization or application. This is discussed further .
Assets and their chain of custody are managed by that are deployed on the Energy Web Chain.
When an Asset is first created, it is registered in the as an owned identity (the owner address being the Asset owner, discussed ).
The main purpose of the IdentityManager smart contract is to have a on-chain location which aggregates known assets. In other words, it provides a kind of "asset-registry" functionality. This can allow one for instance, to more easily answer questions such as "how many assets have been registered in total?".
While there are many OfferableIdentity smart contracts, there is intended to be fewer IdentityManager smart contracts as the IdentityManager's main purpose is the aggregation of OfferableIdentity information. For instance, an enterprise could have a single IdentityManager to all assets which are registered by their employees.
The Asset owner can offer ownership to another DID. The provides methods to verify, offer and transfer (these concepts are discussed in further detail ).
Other contracts in the Ethereum ecosystem exist which track ownership such as popular NFT contract or contracts which implement such as . However, a key requirement of Energy Web's asset implementation was that ownership transfers cannot be performed unilaterally and so these aforementioned options were not used.
Every Asset must have an owner. Asset owners initiate the registration, transference and enrolment activity of their Assets. This requires them to make transactions on behalf of their Asset, so the owner must have an address on the Energy Web Chain that is connected to an . The owner of an Asset is recorded in the Asset's identity on-chain.
When a transfer is initialized, an 'offer' of transfer is made to the recipient DID.
If the Asset's owner is an authorized issuer of the desired role, the Asset owner can directly issue a role-based verifiable credential to their Asset.
If the Asset's owner is not an authorized issuer of the desired role, the owner can submit an enrolment request on behalf of their Asset to the issuer.
The goal of this collaboration was to:
VC-API is specification of a data model and HTTP protocols to issue, verify, present, and manage data in a ecosystem.
Energy Web provides an implementation of to reduce difficulties for organizations to start issuing and verifying Verifiable Credentials. Using these APIs it becomes easy for anyone to do Proof of Concepts for SSI use cases.
VC-API can be easily integrated with existing systems and are configurable for complex exchanges. Implementers can choose to implement APIs that fits their use case. One can keep it simple with minimal set of APIs even for complex data exchanges (presentation).
Refer for more information.
Portable, can be easily deployed to any environment and can be kept generic.
Easy integration and configuration.
Selective implementation of APIs based on the use case. For an application that provides feature to issue a credential only need to consume APIs specific to .
Supports both Mediated and Unmediated exchange.
The Verifiable Credentials data model introduces three actors . VC-API defines components that these actors may use for credential issuance, verification and exchange.
Each actors can have their own set of components to participate in the credential exchange.
Energy Web's implementation of VC-API only provides services which enable VC-API functionality. A developer can implement their own components that are mentioned above.
Applications can perform authorisation, issuance, verification and presentation exchanges using VC-API.
Servers implementing VC-API can confirm clients to utilise authorisation mechanism when performing certain requests. The request APIs endpoint can specify whether authorisation is needed or not.
For issuance of Verifiable Credentials, a holder can request any authority (Issuer) to issue a credential or can self-sign a credential.
A Holder can present their Verifiable Credential to the Verifier for verification. The Verifier can request the required credential from the holder using presentation-exchange protocol.
The sharing / exchange of Verifiable Credentials happen through presentation. These exchanges are executed based on the exchange-definition that are configured at run time.
A general exchange flow would look like :
The VC-API implementation can be easily deployed to any environment and can be kept generic, in other words exchanges are configured rather than coded in the application. This configuration is done at runtime via the use of Exchange Definitions.
Some different types of exchange definitions are :
Sample DIDAuth query VP Request
Sample PresentationDefinition query VP request
Exchange Definition Structure and Properties
exchangeId
exchangeId is definition identifier, used to fetch exchange-definition
Exchange Queries
The DIDAuth query type is used for exchange needed for authorisation, while PresentationDefinition could be used to request certain data from the Holder.
Exchange Callbacks
When defining an exchange, callbacks can be configured to allow parties to receive notice of a VP submitted in response to an exchange. Notifications consist of POST requests to the configured URLs. A callback is configured by adding an entry to the callback array in the Exchange Definition.
Exchange Interact Services
The exchange interaction types used by this VC-API implementation are directly related to Verifiable Presentation Request Interaction Types. The interaction types indicate to the receiver of the presentation request how they can expect to interact further with the issuer/verifier.
Mediated Exchange Interactions
Mediated exchange interactions signal to the receiver of the presentation request that the exchange is mediated by an additional component and may not be automatically processed. Mediated exchanges therefore allow for a review of presentation submission by a human or automated process as well as the issuance of credentials based on this review.
Due to the duration of the mediation process being unknown, the submitter of the verifiable presentation may have to query repeatedly in order to check if the result of the mediation is available.
Unmediated Exchange Interactions
Mediated exchange interactions signal to the receiver of the presentation request that the exchange is not mediated by an additional component and can be automatically processed.
serviceEndpoint
serviceEndpoint is used to continue exchanges
Presentation Definitions.
The presentation_definition are constructed of inputs, that describe the format and details for proofs required. They may also contain selection or filter rules for the presented Verifiable Credentials.
A presentation_definition has input_descriptors property which has an array of objects with properties describing what type of input data (credential) or sub-fields are required for submission.
Presentation exchange between Holder and Issuer
Presentation exchange between Holder and Verifier
This is a walk-through covering the main functionality of the system released to date. It assumes you already have a wallet in either a WalletConnect-compatible mobile application or MetaMask browser
-> The of the system leverages the Energy Web Volta test network. Therefore, all chain transaction fees use Volta tokens, which have no value and are freely obtainable . Here you can try and become familiar with what the system can do for you.
-> The of the system is on the Energy Web Chain and uses Energy Web Tokens for transactions. You can view the cost of transactions for each operation using this .
We recommend using Switchboard on Chromium (Google Chrome, Brave, etc.) or FireFox browsers.
Please note that some privacy-related browser extensions could cause problems with the system. Therefore, if you find that you are unable to complete a step described below, please try disabling your privacy extensions and reloading the page.
Using a web browser on your computer, visit the system landing page. It should appear similar to the image below.
->
->
The system is a progressive web app, meaning that if you access the system website via a browser on your mobile device, you can add the system as an app on your device’s home screen (without using the iOS App Store or Google Play Store).
To do this, first, open your browser and navigate to the system landing page.
Using Chrome on an Android device, click the three-dot overflow menu in the upper-right corner to reveal a menu similar to that shown at the right. Click on “install app” to initiate the download. You should then see the system logo as an app on your home screen.
On an iOS device, the process is similar. Navigate to the welcome page in Safari, then tap the “share” button and scroll down to “add to the home screen.” the system will now appear on your home screen.
As noted above, you may connect to the system using either a WalletConnect-compatible mobile wallet app (on your mobile device) or a MetaMask browser extension. Each of these methods is described below. You can complete either one and skip the other option.
This step requires that you have two devices: a primary device (e.g., a computer) with a browser displaying the system landing page, and a mobile device (tablet or smartphone) on which you have installed a WalletConnect-compatible application.
First, on your primary device, click “use mobile wallet” to view a QR code similar to that in the image at the right. Next, on your mobile device, open the mobile application you use as a wallet, and use that mobile app to scan the QR code on your primary device’s screen.
The app on your mobile device will ask you to confirm that you wish to connect to the system. Your mobile app might then ask you to sign one or more messages. Finally, your mobile app might ask to confirm the connection. After signing and confirming as instructed in your mobile app, your primary device should automatically bring you to the Switchboard dashboard screen.
When you click the “use MetaMask” button, the MetaMask browser extension should open automatically. After you sign in to MetaMask, click the “connect” button. You will be requested to sign a message; do this to complete the connection to the system. You should land on the Switchboard dashboard screen.
The Switchboard dashboard contains functionality related to assets (creating managing an asset DID), governance (managing organizations, applications, and roles), and enrolments (issuing, viewing and revoking roles).
If you click "Manage Profile" button on the top right corner of the dashboard, you can access the user profile menu.
You can add a human-readible name label to your DID account using this menu item. The name is only stored locally and viewable by you.
DIDs are not very human-readible and hard to memorize, therefore you can use the DID Book function to store the most used DIDs with labels to access them quickly.
You can use this function to scan DID encoded QR Codes.
You can use this function to see the DID document in raw JSON format and copy it.
You can use this function to logout from the current DID account.
An asset is a virtual representer of the user’s solar panels, smart energy meters, batteries and other devices in the system. Each asset is assigned its own DID that gives them the ability to be a part of the Energy Web Network, so they can be transferred or enrolled in a role.
By clicking on the “Register Asset” button on my assets tab, you add one more asset to your list. It will get its own DID automatically.
You should see a general list of assets similar in appearance to the image below.
As an owner, you can perform several options under the three vertical dots button (next to the last updated date in the list).
Assets can be enroled to a role credential. By clicking on the Enrolments button (next to the asset name) you can see all roles that the chosen asset has. We recommend adding this issued claim to the asset's DID document so that you have the credentials you need in order to access the application with the appropriate role, you can use the Publish button to do this operation.
One set of functionality in the system relates to governance: managing organizations and applications. To explore this, click on the “governance” button from the system main screen. You should see a governance dashboard similar in appearance to the image below.
The development version of the system is built on Energy Web’s Volta test chain. As you set up your organization, applications, and roles, these will be anchored to Volta. We hope that you test out all available functionality, but we also recommend that you do not enter any sensitive information into the fields at this time. For example, when you create an application in part B below, use a test name if you wish to keep secret the real name of your application for now.
The first tab within governance relates to organization management.
If you haven’t had an organization yet, you can add it by clicking on the “Create Organization” button. The system asks you to fill the form and submit the request.
The “Create Organization” button allows creating only one organization per wallet. After using, the button is hidden from UI.
Assume that you already own an organization, on the Organization management tab you can perform several options related to your organization and its EWNS namespace, each using the options under the three vertical dots button (next to an organization namespace in the list).
After you have created an organization and set its root namespace, you may wish to set the namespace for decentralized applications your organization will own/operate.
The first step is to create the new application namespace, using the “create an application” option on the organization management tab. You will then see a pop-up with several fields to complete. Starting with step 5 of this process (registering the namespace for the app), you will be asked to confirm the transaction using your linked wallet.
Note that any application namespace you define will automatically be created under an “apps” subdomain within your organization’s namespace. For example, if your organization’s namespace is “exampleco.iam.ewc" and you wish to create a new subdomain for an application you call "DERmanager," then your resulting namespace will be "dermanager.apps.exampleco.iam.ewc" (the "apps" subdomain is added automatically, to organize applications separately from other subdomains).
After you have completed all steps to create the new application, your application management tab should appear similar to the image below.
You have several possible actions, similar to your options under organization management. Note that you also have the option to filter your applications by the organization; this may be helpful if, for example, different subsidiaries within your corporate umbrella wish to manage applications separately, but you as a designated super admin need to be able to view all of them.
The final governance task is perhaps the most powerful use of the system, and it builds on the organization and application management functionalities described above. It is governance related to roles—not only roles within your organization but also roles that different users might have in your applications.
As noted above, the system allows you to define two types of roles:
Roles associated with an organization - these roles are independent of any particular application. For example, you might create the role “global dApp admin” to manage all of your organization’s applications. This role is created under your organization or chosen sub-organization on the Organization management tab.
Roles associated with an application - these roles are specific to a particular application. For example, you might create the role “installer” or “renewable energy buyer” in an application that you own. These roles relate to your application but are not necessarily part of your organization. This role is created under your application on the Application management tab.
For creating a role, you should fill the role definition form. You can find detailed explanation of the each step below;
At this step, you will choose an unique role name to host the role definition, full domain path will be shown including application and organization names. The system will prompt if the name is already in-use.
At this step, you will select who is allowed to issue this role. As a role definition creator, your DID will be listed as an issuer by default. You can easily override it by adding another DID or even a role name.
At this step, you will select who is allowed to revoke this role. As a role definition creator, your DID will be listed as a revoker by default. You can easily override it by adding another DID or even a role name.
At this step, you can define a precondition for the user to request this role from the issuer. The user needs to obtain the precondition role and publish it to its DID document and afterwards can continue to requesting this role.
At this step, you can define a default validity period to guide the issuers. The issuers have authority to override it at the time of the issuence.
At this step, you can create custom input fields that will be used to collect data from the user at the time of the role request. This data is only for the issuer to get some more information about the user before the issuence. The data is not stored on the role credential.
At this step, you can create custom input fields that will be used to collect data from the issuer at the time of the issuence. The data will be stored on the role credential.
When you have at least one role, the role governance tab should look similar to the image below.
Each role in the list has the same list of options: View Details, Edit and Copy Role Enrolment URL. The first two are the same as we described above. By choosing the latter one you will copy a link to a URL that others can use to enroll as that role type. You will try this in the next section of this document below.
Users of the system can use the enrolments functionality in two ways. Recall that, because the system uses a decentralized system of identity and access management, any person can own a DID and add claims verified by authorities, which are then used to take on roles in applications. This system of enrolment has three key users:
An authority (issuer) who can verify claims about users, so that the users can add the verified claims to their DID documents (and use them to enroll in an application).
Users who request claims from authorities, so that users can add the verified claims to their DID documents.
The owner of an application, who specifies what claims (the content of the claim, and from whom) are required in order to enroll in that application.
Example: Imagine you wish to deploy an application related to electric vehicle smart charging. Your application might include the roles of vehicle owner, vehicle manufacturer, __ and vehicle dealer. In order for a DID to enroll in your application as a vehicle owner, you might require a verified claim from a vehicle dealer that this DID is in fact the person to whom it sold a particular vehicle (you might require many more claims, including claims from the manufacturer about the vehicle’s model, identification number, battery capacity, and other things, but let us keep the example simple for now). In this example, you can use the system to set up these roles and requirements: a DID can enroll in you application as a vehicle owner only if it has a verified claim from a dealer that the DID is the owner of the vehicle.
Returning to the work you have done so far, you have set up the required claims and issuers. Now let us see how a new user can enroll in an example application. First, ensure you have the enrolment URL. Next, open a new browser window, and paste that URL in the navigation bar. This will load the sign-in page, and you can sign in with your existing address (i.e., the same DID and thus the same user) or create and sign in with a new wallet address (simply create one in your mobile wallet or MetaMask browser extension) if you wish to test this from the perspective of a new user. Either way, you will see an enrolment screen similar to the example below.
When you complete these fields and register, the system sends the enrolment request to the issuer(s) who had previously been specified to approve the role.
Return now to your sign-in as the issuer who can approve the role. The issue will be informed about the new request by Task Manager in the top navigation. The notification’s bubble disappears as soon as the task has been completed.
Your enrolments screen should display the request from the new user.
“View Request” pop-up under the three vertical dots button contains information about the requestor, chosen role, and the fields from the enrolment form. If you approve this request, you have issued a verified claim that the new user can add to that user’s DID document and thereby access your application in the appropriate role.
Return one final time to the new user’s sign-in. You can view this pending role request on your “my enrolments” screen, which should appear similar to the image below.
You can add this newly received role credential to your DID document and publish it to on-chain ClaimManager smart contract, so that you have the credentials you need in order to access the application with the appropriate role. Use the “Publish” button, in order to publish the role credential.
You can also revoke a role credential if your DID is listed as one of the revokers. In order to revoke a role credential, you should navigate to "Revocable Enrolments" tab and click "Revoke Off-Chain Enrolment" or "Revoke On-Chain Enrolment" to revoke.
Because the system leverages EWNS, it is instantly possible for any user to search for organizations and applications that have defined namespaces.
To see an example, return to the main landing page by clicking on the system logo in the top left of your browser window. Your screen should appear similar to the image below.
In the search bar below your name and address, enter any search term. Try “flex” for an example. The system will display all organizations and applications that have the word “flex” in their EWNS namespaces. You are likely to see many examples and test applications. When you click on any of these, you will see the relevant public information associated with this namespace. For example, clicking on the Energy Web Flex (example) “application” displays information about that app, including the roles defined in that app’s namespace. In this way, you can view what roles (user types) are part of a given application.
You can even request to enroll your DID in one of these roles directly from this screen, using the action buttons in the roles list at right. Your enrolment request will be submitted to the relevant issuer, as defined by that app owner via the process described in Part V of this document.
The provides high-level methods to facilitate the chain of custody for an Asset.
Chain-of-custody events (, and ) for an Asset are emitted from the . listens for and persists the details of these events. All historical owners of an Asset and the dates of offer, transference and acceptance are accessible through SSI Hub's API.
Registering as Asset involves creating an OfferableIdentity smart contract for the Asset on the Energy Web Chain, and registering its identity in the . This is initiated by the Asset owner. Because each Energy Web Chain address is a valid DID under the did:ethr DID method, each asset inherently has a DID.
The owner of a registered Asset can transfer ownership to another address on the Energy Web Chain. (The new owner's address must have signing capabilities in order to associated with asset management).
The provides methods to facilitate Asset transferance. This contract makes calls to the so that the state of the Asset is updated at each phase of the transfer.
The state of the Asset identity is marked as 'offered' in the .
The DID that the Asset was offered to must accept the Offer before it is transferred to them. provides a method to accept the transfer. The Asset's owner is updated in the to reflect the new ownership.
The DID that the Asset was offered to has the option to reject the transfer. The Asset's 'offered' status in the is set to 'false'.
An Asset can take on . If their enrolment request is approved by the role issuer, the Asset is issued a role-based .
Read more about role-based credentials in the documentation
Read more about credentials in the IAM stack .
provides the high-level methods to request and issue enrolments. See the API documentation .
provides an interface for users to register, transfer and enroll Assets. If you are logged into Switchboard, you can view the Asset management interface .
contains the high-level functions for managing (registering, fetching, transferring, etc.) assets and their corresponding data. You can view the service API documentation for Assets in the library .
Energy Web and the (DSO) jointly developed a decentralized energy asset management system leveraging the EW-DOS components and architecture .
Facilitate secure, encrypted communication between (i.e. solar panels, batteries, etc) and the grid
Enable to provide grid services (e.g. selling excess energy back to the grid)
Grid assets (e.g, smart meters, distribution automation devices), and were assigned DIDs. The DID is anchored on the asset's pre-existing SIM cards. Each asset exists as an identity in the on the Energy Web Chain. Cryptographically signed information (such as control signals and commands) from the DSO (Stedin) can then be sent to targeted assets. This allows for an awareness and exchange of grid services between the DSO and DERs.
You can read more about this use case in the official press release .
: execute the business rules and policies set by the actors. Also acts as mediator between these actors.
: enable general VC-API functionality.
: facilitate publishing and checking of status of Verifiable Credentials.
: responsible for configuring and managing all the other components.
: provide mechanisms to store and manage Verifiable Credential of the associated actor.
In order to configure the credential exchange, you can use the exchange definition data transfer object. For reference see the implemented by Energy Web.
The Exchange Definition has a query property that tells which data needs to be requested. The type of queries that are supported are defined by VerifiablePresentationQueryType, for reference see .
These presentation exchange take place on the basis of . Verifiers articulate these definitions of what they require for proofs. The issuer then wraps their Verifiable Credentials on the basis of presentation-definition in a VP and provide a response to the Verifier.
See to know more.
Example for a VC issuance and presentation using VC-API can be seen in .
This step requires that you already have installed the MetaMask browser extension and created a wallet in MetaMask. See the page on for more details.
The system leverages the (an implementation of the Ethereum Name Service for Energy Web). With EWNS, you can organize your organization, any applications your organization owns/operates, and all roles within your organization or those applications.
If you wish to use more than one DID, then it is recommended to either (a) use a different browser for each user or (b) use a browser extension that manages multiple sign-ins to a single website, such as .
iam-client-libraryiam-client-libraryiam-client-libraryPossible credential metadata
In a verifiable credential ecosystem, there are various metadata that are useful for effectively using the data in the credentials. This page aims to describe possible metadata specifications and technologies that may be used with credential data.
Note: Not all of the following metadata is available for all credentials within the Energy Web credentials ecosystem.
Data semantics refers to the meaning of the data. This includes semantic disambugation (know precisely what a term is refering to) as well as data descriptions and relationships.
Linked Data provides semantic disbiguation by requiring that terms be IRIs.
Linked Data context maps terms to IRIs. This allows JSON-LD documents to be written in more concise, readable manner, without sacrificing accuracy.
The VC Implementation Guide also has instructions on how to create new contexts for verifiable credentials.
Linked Data can also be used to provide further information about the semantics of a term. This is provided in a data vocabulary or ontology.
For example, the RDF Schema comment property can be used to provide further description of a resource.
Note that vocabularies can be used to infer data validation but this is non-standard and violates the open-world assumption of W3C ontology languages.
This point is made in SHACL and OWL Compared
Although data validation is an important practical use case for the RDF stack, until SHACL came around, there was no W3C standard mechanism for defining data constraints. Over time, people became creative in working around this limitation. Many tools simply decided that for all practical purposes, the open-world and non-unique-name assumptions should simply be ignored. OWL-aware tools including TopBraid and Protégé, for example, provide data entry forms that restrict users from entering more than one value if there is a corresponding owl:maxCardinality 1 restriction, or require the selection of a specific instance of ex:Person if that class is the rdfs:range of the property. The GAIA-X FAQ makes a similar point SHACL shapes are not an ontological models. They serve a different purpose. Ontologies describe concepts and help in inferring additional knowledge. Firstly, the W3C ontology languages follow the Open World Assumption, secondly SHACL follows the Closed World Assumption. If a self-description is missing an attribute, it is an error in the shape validation (and that’s how it should be!). From the ontology’s point of view, the attribute could be defined somewhere else in the WWW, if not in the JSON-LD file at hand (but this extremely decentralised view is not compatible with Gaia-X’s trust-building approach).
Data structure validation is used to validate that data, for example, contains specific properties or that properties have specific values.
There does not seem to be a single way of describing data structures in the Verifiable Credentials ecosystem as different methods have different tradeoffs.
For verifiable credentials, the schema of a credential can optionally be linked using the credentialSchema property.
JSON Schema can be used to describe the precise shape required by the a credential.
The JsonSchemaValidator2018 credentialSchema type is defined in the Verifiable Credentials Vocabulary
SHACL is the W3C standard for validating RDF graphs.
SHACL is being used by GAIA-X for their self-descriptions.
To check whether the claims in a Self-Description follow all constraints, such as including all mandatory attributes, the claims are validated against a shape. Technically, these shapes follow the W3C Shapes Constraint Language (SHACL). The claims themselves are represented as an RDF graph, serialised in the W3C JSON-LD format, where JSON is a data interchange format widely supported by programming languages, and JSON-LD (LD = “linked data”) makes it compatible with RDF.
JSON-LD Schema is a pre-alpha project that attempts to reconcile the trade-offs of JSON Schema and SHACL.
It notes:
JSON-LD documents can be seen from two points of view: as regular JSON documents following certain conventions or as RDF graphs encoded using JSON syntax. Validation mechanisms indeed exist for both ways of looking at the information in a JSON-LD document, but each of them has important drawbacks when working with JSON-LD:
JSON-Schema can be used to validate JSON-LD as plain JSON documents. However, the information in a JSON-LD document can be encoded through multiple, syntactically different, documents, so it is hard to write a generic JSON-Schema validation without going through a normalisation step, and even if the validation is written for a normalised JSON-LD document, the description of the validation becomes verbose and complex to write, relying, for example, on the usage fo fully expanded URIs. There is also the issue of the implications for the validity of the RDF information encoded in the document when we are just validating the JSON syntax.
SHACL can be used to validate the RDF graph encoded in the JSON-LD document. SHACL is powerful and expressive but difficult to write and learn, especially for users that do not want to work with JSON-LD as an RDF format. Additionally, the performance of SHACL validators is far from the performance of syntactical JSON-Schema validators
The Wallet Rendering specification describes how a credential can be displayed.
Symbol | Name | Description |
View Ownership History | View the history of owners and transaction of chosen asset. |
Verification Method | Existence of the asset can be verified by a third-party. For this you should know the third-party public DID and type of Network. |
Transfer Ownership | Transfer ownership of your asset. For this you should know public DID of a new owner. As soon as a request submited your asset from My assets tab will be moved to Previously owned assets. |
Edit | At any time, you can set a personal name and icon for each of your items. For security reasons, assets names are blurred in the general list. |
Generate QR-Code | Generate a QR-code for a chosen asset. |
Issue Claim to Asset | Inform about Verified Claim of a chosen asset. |
Symbol | Name | Description |
View Details | View the basic details of your organization, including the logo, namespace, organization name, website, description, and other data. |
Create Sub-Organization | Create a new sub-organization owned by the organization. This allows you to define applications and roles for specific subsidiaries or business units within your organizational umbrella. For example, you might create “subsidiary1.exampleco.iam.ewc” and “subsidiary2.exampleco.iam.ewc” so that you can define applications and roles specific to those subsidiaries (as described in the following sections of this document). |
View Applications | View the applications owned by this organization (i.e., go to application management tab). |
View Roles | View the roles associated with this organization or with any application owned by this organization (i.e., go to role governance tab). Note that that are two kinds of roles:
|
Create Application | Create a new application owned by the organization. |
Create Role | Create a new role associated with either this organization or a specific application owned by this organization. |
Edit | Change the details of your organization. Please note that it is not possible to change the root namespace of an organization. For example, after you have defined “ The “others (JSON)” field allows you to specify formatting-related details (e.g., color scheme) that should be applied, so that when you integrate the system into your decentralized applications the branding is consistent. For example, you could add into this field the text:
The above text will set the background color for the system in your application to be the light blue color with hex code |
Transfer Ownership | Transfer ownership of your organization and its root namespace to another address. |
Delete | Delete your organization. |
Governance frameworks in the IAM stack
Governance provides the rules and procedures to establish behavior, expectations and trust within an environment. While governance is a critical component of any multi-party network, it is especially critical in decentralized environments, where there is no central authority to define and orchestrate governance mechanisms over every component of the ecosystem.
As an example, consider an application built on top of the Energy Web Chain. Each application must ensure that:
Components are in compliance with existing digital frameworks that their application depends on (e.g. cryptocurrency wallets, peer-to-peer protocols or smart contracts)
The application has a governance framework that is robust enough to garner stakeholder trust and compliant participation within the application itself (i.e. defining and enforcing who is allowed to do what within the application)
Governance in a network is established through a governance framework (also referred to as a trust framework). The framework provides concrete policies, rules and expectations for the stakeholders within the network.
Energy Web’s IAM governance relies on two systems: role-based hierarchies and verifiable credentials. Used together, these components provide a governance framework for users to interact with the digital infrastructure, and with other users in a secure and self-sovereign manner.
Role credentials are associated with a user’s Decentralized Identifier (DID), which is anchored on the Energy Web Chain in the DID registry. This means that a user’s roles and credentials are not siloed within any one application; because a user can use their DID to register with any application built on top of the Energy Web Chain, their roles and credentials are portable.
In the Energy Web IAM ecoystem, role-based hierarchies are defined by organizations, applications, and designated roles within them. The tech stack leverages Energy Web’s Ethereum Name Service to define and namespace relational hierarchies within a system. We decided to deploy our own copy of ENS on the Energy Web Chain as it provides a standard set of widely-used, well-tested smart contracts. Read more about the ENS smart contracts deployed on the Energy Web Chain here.
The namespace hierarchy is built on four levels:
Organization: a top-level organizing body
Sub-organization(s)
Application: a distinct service or functionality provided by an organization or sub-organization
Role: a distinct functionality within an application or within an organization
When roles are created within an organization or an application, the creator can define conditions or criteria that restrict who is qualified to take on the role. The role creator can also determine which users (by DID or role) are authorized to issue or revoke a role.
Below is a resolved role definition for a role of "install lead". Note that it contains an enrollment precondition that the subject already has the role (credential) of 'project installer'. The role definition also specifies an expiration date, and asserts that only users that have the role of 'install manager' can issue or revoke this role.
Verifiable Credentials enable users and their assets to take on roles within a system (that is, within an organization, a sub-organization or an application within a hierarchy, as discussed above).
See more extensive documentation on credentials in the IAM stack here.
Switchboard provides the user interface for creating and defining these hierarchies. See the Switchboard guide on Governance and role creation here.
The supporting IAM libraries provide the functionality for persisting and resolving namespaced domains Namespace domains that are registered and managed in the Energy Web Ethereum Namespace smart contracts. Read more about the role of Ethereum Name Space in Energy Web Digital Infrastructure here.
These libraries also support governance by providing credential verification mechanisms. This is discussed further in the Credential documentation.
A TypeScript library that provides high-level functions related to the identity and access management (IAM) for all users, assets, organizations and applications that are anchored on the Energy Web Chain. This includes:
Management of Switchboard namespaces
DID/DID Document management
Creation and governance of organizations, applications and their associated roles. Once created, these are persisted on the IAM Cache Server
Claim requests, verification and issuance for role permissioning. Once created, claims are persisted on the IAM Cache Server
Staking functionality
| EW-DOS Dependencies | EW-DOS Dependents |
|---|---|
A class-based TypeScript library that provides an abstraction layer to manage and interact with DIDs and Verifiable Credentials on the Energy Web Chain.
The DID Library enables users to adopt and/or implement different DID methods, which promotes interoperability with other methods of decentralized identifiers. The DID library currently implements the ERC1056 standard for creating and updating identities on the blockchain.
The DID library interacts with the Energy Web Chain using the ethers.js library.
GitHub repository (includes documentation)
A backend class-based TypeScript library that allows other JavaScript/TypeScript applications to easily add authentication and authorization based on Switchboard roles to their applications. This allows any application to use Switchboard's decentralized approach to identity and access management.
You can refer to the Identity and Access Management (IAM) Client Examples application to see an example of Passport-DID-Auth integration into an application
A multi-package library for CRUD operations specific to Energy Web Verifiable Credentials. The repository is a module-based library built with Lerna.
The credential lifecycle in the IAM stack
This page documents the role and lifecycle of credentials in the IAM stack.
Credentials are documents that allow individuals to show that they possess certain accreditations (this is discussed further in depth below - 'Credentials Overview'). Credentials are traditionally document or paper-based, such as a driver's license or a passport, and are typically registered in a centralized repository under the stewardship of the issuing body.
Verifiable credentials are purely digital components that can be verified cryptographically. Verifiable credentials are a secure and self-sovereign alternative to traditional paper-based credentials or documents, which typically must be physically or electronically transmitted for verification, and have the potential to be intercepted, altered or tampered with.
In general, verifiable credentials do not rely on Decentralized Identifiers (DIDs) but they are often used together. If DIDs are used, decentralized ledger technology (i.e. a blockchain) can provide the public key infrastructure for the cryptographic verification.
The specification that defines verifiable credentials was established and is maintained by the World Wide Web Consortium (W3C). This protocol continues to evolve. Verifiable credentials are one of the three core pillars of self-sovereign identity, along with decentralized identifiers (DID) and distributed ledger technology.
See the W3Cs use cases and requirements for verifiable credentials here
Verifiable credentials are a key component of Energy Web's Identity, authorization and access management. In current use cases, credentials are used to authorize users' or assets' enrolment into applications and organizations. Each credential is associated with the subject's DID that is anchored on the Energy Web Chain. Energy Web's Switchboard application provides a user interface for creating, requesting, issuing and revoking role-based credentials. Energy Web's IAM libraries and APIs facilitate the full lifecycle of verifiable credentials. The Energy Web blockchain serves as the trust or verification layer for digital proof. This documentation provides references to these libraries, and to supporting W3C documentation that is used to guide and inform the development of Energy Web's IAM solution.
Click below to see a current diagram of Energy Web IAM architecture:
A claim is an assertion that is made about a subject. A claim could assert, for example, that a battery meets specific manufacturing standards.
A credential is a claim(s) made by an issuer about a subject. When the credential issuer makes a claim about a subject, they issue a verifiable credential. For example_,_ an issuer can issue a credential for a battery that asserts that it was manufactured on a specific date in a specific location.
In order for a credential to be verifiable, it must contain a proof mechanism and supporting information to evaluate the proof. The proof must be able to be verified through cryptographic (i.e. algorithmic) means, typically through a digital signature. Energy Web's IAM libraries support digital signatures of Ethereum-compatible wallets, such as MetaMask.
Proofs provide two primary functions:
To verify the authorship of a credential
To detect tampering or alteration to the credential/presentation
In the example of the battery mentioned directly above, the proof will verify that
The issuer is authorized to assert that the battery was manufactured on a specific date and in a specific location
That the credential data and digital signature has not been changed or compromised
Note that proof mechanisms do not validate the facts that the claim asserts (in the example above, the providence of the battery). It only verifies the issuer of the claim and the integrity of the claim's data over time (i.e. has the data been altered or tampered with).
There are two main proof mechanisms for verifying credentials, both of which are used in the IAM stack. These will be discussed further below.
External proofs, which are commonly expressed by JSON Web Tokens. An external proof is one that wraps an expression of the credential data model, such as a JSON Web Token. See the W3C JSON payload encoding standards for verifiable credentials here. Verifiable Credentials expressed as JSON Web Tokens in the IAM stack is discussed below.
Embedded proofs, in which the proof is included directly in the credential's JSON data. To be compatible with W3C Verifiable Credentials standard, the credential JSON must have a property of 'proof'. Verifiable credentials expressed as JSON/JSON Linked Data in the IAM stack are discussed below.
The Energy Web IAM stack provides API methods to request, issue, publish, verify and revoke credentials.
Our ecosystem offers persistence for credentials on the Energy Web blockchain, and off the blockchain using the decentralized file system IPFS.
Credentials that are persisted on the Energy Web Chain are referred to as 'on-chain' credentials
Credentials that are persisted off-chain are referred to as 'off-chain' credentials
The distinctions are discussed in the following section.
Note that whether a user chooses to persist credentials on-chain and/or off-chain, credential data is also persisted in the SSI Hub. SSI Hub facilitates credential exchange by persisting credential request and issuance messages
On-chain credentials are registered on the Energy Web blockchain in the Claim Manager smart contract. The contract source code can be found here. A credential is registered in the contract when the credential is published by the holder.
The Energy Web Chain is a public blockchain. This means that smart contracts and their data are public, and their public methods can be called by anyone. This is an important point of consideration when deciding whether to publish credentials to the blockchain.
There are currently two smart contracts deployed on the Energy Web Chain that are used for verifying and persisting verifiable credential data (for 'on-chain credentials' only). The source code for these contracts can be found in the @energyweb/onchain-claims package.
Off-Chain credentials are not referenced on the blockchain. Off-chain credential data is persisted as a JSON web token on IPFS, a decentralized public filesystem. IPFS, like a blockchain, is a decentralized system and relies on a network of peer nodes to create a distributed system.
When a token is stored on IPFS, it has a content identifier (CID) that points to its location on the file system. This CID is linked to the credential's corresponding DID Document through a service endpoint. A service endpoint points to any service that supports or acts on behalf of a DID. The CID is used to fetch and resolve the full credential from IPFS when necessary.
DID Document data, including service endpoints, are publicly available on the Energy Web Chain. IPFS data is accessible to anyone who has the service endpoint that contains its location on IPFS. This is an important consideration when deciding to publish credentials to IPFS.
For each off-chain credential request, iam-client-library issues two credentials of different format and proof type.
Both signature mechanisms can be performed by Ethereum-based wallets such as MetaMask.
A JSON web token is a common standard for transferring encoded, verifiable data between parties. The JSON web token payload is generated from the claim data.
Proof Mechanism: EIP-191 signature standard
Data Model: The JWT payload partially conforms to the properties established by W3C for verifiable credentials as a JWT. You can view these properties here.
Persistence: The issued token is included in an object that contains other data about the issued credential request. (Read more about claim issuance below). The token is persisted in the SSI Hub's database when the credential is issued, and persisted in IPFS when a credential is published by the subject. The credential's location in IPFS is referenced in the user's DID Document's service endpoints.
Proof Mechanism: EIP-712 signature specification. This allows the credential data to be displayed in a human-readable format when digitally signing the message:
See the W3C documentation on the EIP-712 signature here.
Data Model/Interface: The Verifiable Presentation interface conforms to W3C credential schema, which includes JSON-LD (JSON Linked Data) data format. JSON linked data ensure that credentials and presentations are universally machine readable and compatible. Read more about JSON-LD formatting in verifiable presentations and credentials in the W3C documentation here.
Persistence: The verifiable presentation is included in an object that contains other data about the issued credential. This object is persisted in SSI Hub database.
In addition to the above, there are a few distinctions to consider when deciding to register credentials off-chain or on-chain.
On-chain credentials can be read by any smart contract deployed on the Energy Web Chain, and thus used in many decentralized applications. This allows for greater application interoperability.
Off-chain credentials in IPFS do not require any transaction costs that are associated with a blockchain, and can be resolved by an IPFS client in any application.
A credential request occurs when a user requests to enrol to an organization or application’s pre-defined role. The role may have specified criteria that the subject must meet in order to take on the role. The user who is requesting to take on the role is the claim ‘subject’.
iam-client-library contains high-level methods to initiate credential requests. These methods indicate whether a credential should be registered 'on-chain' or 'off-chain'.
Claim requests are persisted in the SSI Hub.
A user makes a request to the credential issuer to enrol into Organization A as a 'Battery Installer'. This role is pre-defined by Organization A, and has a designated set of issuers (each with a DID) who are authorized to approve and issue a credential for the 'Battery Installer' role. At the time of request, the subject must specify if they want this credential to be persisted on-chain or off-chain.
The credential's issuer approves and issues (or rejects) a subject’s credential request. By issuing the credential, they are verifying that the subjects meets the requirements needed to obtain the credential.
Using the example **** above, the issuer is issuing a credential of 'Battery Installer' to the subject. In doing so they are asserting that the subject meets the requirements to hold this credential. They are signing the credential (providing proof) with their digital signature using an Ethereum- compatible wallet such as MetaMask.
If a credential has an **'**on-chain' registration type, the verified credential is registered in the Claim Manager smart contract.
As discussed above, off-chain credentials are issued in two formats:
A verifiable presentation ****
A signed JSON Web token****
The verifiable presentation and issued token are appended to the claim data, which is updated in the SSI Hub.
Once an issuer has issued a credential, the subject has the option to publish (persist) the credential. The persistence location depend on if the credential is registered on-chain and/or off-chain. Persistence for on-chain credentials is discussed above here. Persistence for off-chain credentials is discussed above here.
The W3C Verifiable Credential protocol includes revocation as a standard operation in the credential lifecycle. Credentials can be revoked due to a breach in proof integrity (digital signature), or because the subject no longer meets the requirements to hold the credential.
The IAM stack provides methods for a revoker to revoke a credential after it has been issued.
Revocation for Energy Web credentials is executed based on the Role Governance. Only an authorised revoker (a DID or any DID with specific role credential) can revoke a credential.
When an on-chain credential is revoked, the revocation is registered in the ClaimsRevocationRegistry smart contract. This smart contract holds a reference to every revoked credential. The ClaimsRevocationRegistry contract references the ENSRegistry contracts to ensure that the revoker has the right authority to execute revocation and ClaimManager contract to validate if the subject has the role credential (to be revoked) and if revoker's authoritative credential has either expired or revoked (for the case where revoker's authority is based on a specific role credential).
For a revoker to be able to revoke an on-chain credential, their authoritative credential should also be published on-chain.
For a credential to be verifiable on-chain, a verifier should be able to check the revocation status of the issued credential along with the issuance.
It should be possible to get a single source of truth for a revocation status i.e. a verifier should be able to get a valid revocation from a registry without the need to verify it again.
For a revocation to be registered on-chain it is necessary that the credential first be registered on-chain with ClaimManager, where holder has provided their consent to make the credential publicly available.
The publishing of a holder's credential reduces the privacy and allows someone to determine if a holder has been issued a role credential or not.
In other words, revocation of a credential which has not been published yet would imply that the holder holds the role credential reducing the privacy of the holder's credential.
Therefore, the revocation registry requires that the holder consent to their credential being on-chain and publishing it to the ClaimManager registry.
Having the credential in the ClaimManager allows the ClaimsRevocationRegistry to provide verifiability of:
Only verified and valid credential being revoked, ClaimManager verifies credential's integrity and its issuer's authority before registration.
Credential's validity with regards to expiration.
Revoker's authority who revoked Holder's credential.
Thus establishing a design which provides Verifier with a trusted mechanism for revocation status check which ensures that a valid credential can only be revoked by an authoritative revoker.
When an off-chain credential is revoked, the credential JSON is updated with a "credentialStatus" property that is conformant to W3C's StatusList2021 data model. This data model provides a link for verifiers to use to see the status of a credential (i.e. if a credential has been revoked by the revoker). The verifier can verify this credentialStatus property and derive the revocation status of the credential. You can view the properties of the StatusList2021 data model here.
When a credential is revoked using iam-client-library, which utilises status-list module to append this credentialStatus property to credentials, the credentialStatus will have a statusPurpose that reflects it has been revoked:
Status list credentials are persisted in SSI Hub. The credentialStatus object has an attribute statusListCredential that provides a URL thorugh to fetch the credential's status for verification purposes.
More detailed documentation around StatusList2021 can be found here
A verifier is responsible for verifying the authenticity of a credential. The criteria for this evaluation is specified by the W3C Verification standards here. iam-client-library provides verification methods that evaluates these criteria, namely:
The credential proof (typically the digital signature) is valid.
The credential is not revoked.
The credential is not expired.
Beyond the scope of basic verification, iam-client-library's verification methods also validate the issuer's authorization to issue the credential and does this for all the issuers in the hierarchy.
This verification is executed for off-chain credentials and relies on the subject's (holder or issuer) DID Document resolution.
When using Switchboard, users can create and update data that is stored in smart contracts on the Energy Web Chain. These actions require users to pay a small transaction cost. Users pay transaction costs using their cryptocurrency wallet such as MetaMask. Transaction costs on the Energy Web Chain are in Energy Web Token. Transaction costs on the Volta Test Network on are in Volta Tokens.
Read more about transactions and transaction costs in the Energy Web Tech Stack here.
The transaction cost amount depends on what action the user is performing, and the current gas cost. Actions and their estimated associated total transaction cost are listed below. They are organized according to the three main domains of Switchboard: Enrolments, Governance and Assets.
The total costs calculated below is the sum of the cost to process the metadata and the current gas cost. The costs below are approximate values per operation. The total cost can change:
Based on the user input data (e.g. number of input fields)
Based on congestion (i.e. how many transaction requests are currently in the pool to be processed), which affects gas price
Switchboard is used to request, issue, publish and revoke role-based credentials. These credentials are persisted on the Energy Web Chain (read more about on-chain credentials here). As such, they require transaction costs to cover their on-chain lifecycle events.
Switchboard is used to create and manage organizations, applications, and roles associated with them. These elements are persisted in Energy Web's Ethereum Name Service smart contract. ٍ Each time a user creates or updates one of these entities, they must pay a small transaction cost
Read our documentation on SSI Credential Governance using ENS Domains here.
Switchboard is used to create (register), manage and transfer Assets. Each Asset is registered in a smart contract on the Energy Web Chain (read more about Assets as ownable smart contracts here.) Each time a user interacts with these contracts for Asset management, they must pay a small transaction cost:
NodeJS server application using NestJS framework. The server caches specific smart contract data such as ENS namespaces and DID documents in order to improve read-query performance for applications and packages that rely on on-chain data.
The SSI Hub also facilitates the credentials exchange between credential requesters and issuers, which enables other applications such as Switchboard or Decentralized Service Bus to use credentials for role permissioning.
SSI Hub persists the following information that is created, read and updated by the IAM library:
Organization namespaces
Application namespaces
Role namespaces
User credentials
| EW-DOS Dependencies | EW-DOS Dependents |
|---|---|
Identity and access management (IAM) refers to the frameworks and procedures that provide the users of a technology with appropriate access to the technology’s resources (i.e. what a user is allowed to do and access within a system). It includes the processes for validating user identities and establishing the hierarchies they exist in.
IAM plays a critical role in Energy Web tech stack. The IAM components are responsible for creating user identities and defining and enforcing that identities participate in. These governance structures that users must have in order to take on roles within an application or organization, and provide the mechanisms to request, verify and issue these roles.
The Energy Web IAM architecture is informed by and implements the principles of . SSI is a paradigm that promotes an individual’s control over their digital identity and how it is used. This is in contrast to traditional, centralized IAM approaches, where a third party is responsible for storing a user's identity and/or their data in a proprietary database.
Self-sovereign identity exists to address the shortcomings and vulnerabilities of centralized identity approaches. Some of these include:
Users lack custody over their digital identity and its associated data (what data is shared and with whom).
Applications and systems do not provide interoperability or portability of user data. User identifiers and data are typically sequestered within an application and are not accessible to the user outside of that context.
Centralized systems are vulnerable to attack, resulting in exposure and dissemination of sensitive user data.
The (Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) serve as the fundamental components of Energy Web's IAM framework.
Similar to a traditional 'username', A DID is a user's primary identifier in the Energy Web ecosystem. A DID is , and is anchored on the in the DID Registry. See further documentation on DIDs in self-sovereign identity and the IAM stack .
Verifiable credentials are digital credentials that can be verified cryptographically using public-key infrastructure. In the Energy Web ecosystem, verifiable credentials are used to authorize a user's or enrolment into an application or organization. See further documentation on verifiable credentials in self-sovereign identity and the IAM stack
DIDs and Verifiable Credentials are used together within a framework of role-based hierarchies to create permissioning systems. You can read more about the role of DIDs and verifiable credentials in our governance framework .
For further documentation on our IAM stacks:
| EW-DOS Dependencies | EW-DOS Dependents |
|---|---|
| EW-DOS Dependencies | EW-DOS Dependents |
|---|---|
| Package | Description |
|---|---|
| Contract | Purpose | Address - Energy Web Chain | Address - Volta |
|---|---|---|---|
| Action | Cost in EWT |
|---|---|
| Action | Cost in EWT |
|---|---|
| Action | Cost in EWT |
|---|---|
| Action | Cost in EWT |
|---|---|
| Action | Cost in EWT |
|---|---|
(how to use IAM stack apps)
(cross-cutting concepts across the IAM stack):
: the role and lifecycle of verifiable credentials in the IAM stack
: defining and managing digital identities for assets (digital representation of a physical or virtual device)
: Energy Web's role-based governance frameworks
Switchboard
Code to verify role based verifiable credential.
Smart contract and client code specific to EnergyWeb IAM roles.
exposes code to support role/claim lifecycle.
Claim Manager Source Code
Holds mapping of issued verifiable credentials; Provides methods for credential verification
Claims Revocation Registry Source Code
Holds mapping of revoked credentials
Publish role to DID Document
0.00031849
Revoke on-chain role
0.00016711
Create Organization
0.00077047
Create Sub-Organization
0.00077047
Create an organization-level role
0.00085867
Transfer organization ownership
0.00013159
Edit organization details
0.0001474
Delete organization
Not Available
Create application
0.00064152
Create an application-level role
0.00085867
Edit application-level role details
0.00032897
Edit application details
0.0001474
Delete application
0.00010978
Edit application role details
0.00032897
0.0002375
Transfer ownership (offer) of Asset
0.0000956
Publish Asset role to DID Document
0.00010972
Accept/decline Asset offering
0.00007288
Switchboard
EV-Dashboard
