Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
EBSI is a blockchain run by member states and public authorities. The idea is to create a trusted, public ledger that serves as a single source of truth for vital information. As such, EBSI instantiates different Trust Registries, such as
Trusted Issuers Registry (TIR), which contains information about organisations (e.g. public keys, accreditations, legal name, ...)
Trusted Accreditation Organisation Registry (TAOR), which is similar to the TIR, but contains information about organisations that can authorise Issuers to issue credentials in regulated fields.
Trusted Schemas Registry (TSR), which contains information about semantic contexts and vocabularies, policies and templates of VCs and their data models to ensure semantic interoperability.
ESSIF's goal is to bring SSI to Europe. To do so, it fullfills different functions:
Governance and Trust Framework: ESSIF drives the creation of a EU Governance and Trust Framework supported by Member States.
Standards and specifications: ESSIF creates business, functional and technical specifications, which make up the European “flavor of SSI”.
Facilitate Adoption: ESSIF coordinates the adoption of SSI across Europe starting with pilot projects of “Early Adopters” which are public authorities from different member states.
Note that ESSIF specifies its own DID Method and different types of Verifiable Credentials (VCs):
Verifiable IDs, which are mainly used to identify entities at a high-level of assurance. As such, they can be compared to passports or national IDs.
Verifiable Attestions, which encode basically any other type of identity information, such as education or work records, financial data or health data.
Verifiable Manadates, which enable delegation as outlined in this paper.
There are also other variations of VC that evolved over time such as Verifiable Accreditations (as issued by TAOS; see above) or Verifiable Authorizations (used to authorize parties to interact with EBSI).
ESSIF specific operations.
Commands:
onboard ESSIF Onboarding flow
auth-api ESSIF EBSI Authentication flow
did ESSIF DID operations.
tir ESSIF Trusted Issuer Registry operations.
timestamp EBSI Timestamp API operations.
taor ESSIF Trusted Accreditation Organization operations.
tsr ESSIF Trusted Schema Registry operations
This section shows how you can use the SSI Kit to interact with Europe’s emerging identity ecosystem based on the
EU Blockchain Service Infrastructure (EBSI)
EU Self-Sovereign Identity Framework (ESSIF)
Here **** you can find examples on how to use the SSI Kit command line interface to interact with the EBSI/ESSIF ecosystem.
Note, that some of the flows are not in their final version. Slight modifications are to be expected.
Creation and anchoring of a new DID on the EBSI ledger (incl. use of "Verifiable Authorizations" and EBSI access tokens).
For SSIKit usage examples, refer to: EBSI DID registration
Onboarding of a legal entity to the EBSI/ESSIF ecosystem (incl. combined VC request and DID registration).
Gaining access to protected EBSI/ESSIF services (incl. presentation of "Verifiable Authorization").
The ESSIF protocol for issuance of verifiable credentials aims to being compliant with the OIDC for credential issuance specification. Refer to the respective section for details:
The ESSIF protocol for presentation of verifiable credentials to a Verifier or Relying Party, aims to being compliant with the OIDC/SIOPv2 specification. Refer to this section for details:
OIDC/SIOPv2 for verifiable presentations
Several code-examples how to use the ESSIF functionality of the SSI Kit are shown on GitHub
Note, that EBSI/ESSIF specifications are evolving, which means that some flows are not available in their final version. Modifications are to be expected.
Creation and anchoring of a new DID on the EBSI ledger (incl. use of "Verifiable Authorizations" and EBSI access tokens).
For SSIKit usage examples, refer to: EBSI DID registration
Onboarding of a legal entity to the EBSI/ESSIF ecosystem (incl. combined VC request and DID registration).
Gaining access to protected EBSI/ESSIF services (incl. presentation of "Verifiable Authorization").
The ESSIF protocol for issuance of verifiable credentials aims to being compliant with the OIDC for credential issuance specification. Refer to the respective section for details:
The ESSIF protocol for presentation of verifiable credentials to a Verifier or Relying Party, aims to being compliant with the OIDC/SIOPv2 specification. Refer to this section for details:
OIDC/SIOPv2 for verifiable presentations
Several code-examples how to use the ESSIF functionality of the SSI Kit are shown on GitHub
This use case describes the steps, which are required to register a DID on the EBSI blockchain.
Key generation (type ECDSA Secp256k1, which is required for signing ETH transactions)
Generation of the DID document
EBSI/ESSIF Onboarding flow.
After successfully completing the onboarding process, the Verifiable Authorization (validity of 6 months) from the Ebsi Onboarding Service is placed in data/ebsi/verifiable-authorization.json
EBSI/ESSIF Auth API flow
After successfully completing the Auth API flow, the decrypted EBSI Access Token (validity of 15min) can be accessed in file: /home/pp/dev/walt/data/ebsi/ebsi_access_token.json
EBSI/ESSIF DID registration
DID Resolution (only to check if the DID was correctly anchored with the EBSI blockchain)
The resulting DID document from the EBSI blockchain:
First pull the latest container
Starting the container as RESTful service
Key generation (type ECDSA Secp256k1, which is required for signing ETH transactions)
Generation of the DID document
EBSI/ESSIF Onboarding flow
EBSI/ESSIF Auth flow
EBSI/ESSIF DID registration
DID Resolution (only to check if the DID was correctly anchored with the EBSI blockchain)
As prerequisite, the bearer token (validity of 15 min) from must be placed in file data/ebsi/bearer-token.txt
The shows how to register an EBSI DID in Java.
ESSIF REST API functions.
The ESSIF API exposes the necessary endpoints for running the ESSIF specific flows between Issuers (incl. ESSIF Onboarding Services), Holders and Verifiers.
Aligned with the ESSIF terminology, the API is grouped by the User Wallet (wallet API for consumers / natural persons) and Enterprise Wallet (wallet API for organisations / legal entities).
Note that the EBSI/ESSIF specifications are expected to evolve which will be reflected in continuous updates of the proposed APIs.
The following functions are available:
onboard - EBSI onboarding flow, requests a Verifiable Authorization from EOS
authorize - ESSIF authorization flow
register did - registers DID on the EBSI blockchain
create timestamp - creates a timestamp in EBSI ledger
load timestamp by id - loads a timestamp by the timestamp id
load timestamp by hash - loads a timestamp by the transaction hash
The /v1/client/onboard
endpoint onboards the specified DID to the EBSI blockchain. It runs the ESSIF onboard API and requires a Bearer token, which can be acquired from https://app.preprod.ebsi.eu/users-onboarding.
E.g. Onboard the did = did:ebsi:zYubw2L8tCZSKKpAcMmCY2Q.
The /v1/client/auth
runs the ESSIF authorization flow for the specified did.
E.g. Run the authorization flow for did = did:ebsi:zYubw2L8tCZSKKpAcMmCY2Q.
The /v1/client/registerDid
endpoint registers the specified DID on the EBSI ledger.
E.g. Register did = did:ebsi:zwdPobJGue3w86Gpqhq5Cni on the EBSI ledger.
The /v1/client/timestamp
endpoint creates a timestamp on the EBSI ledger, using the provided DID as a key. The data will be written to the data-field of the timestamp.
E.g. Create a timestamp using did = did:ebsi:zYubw2L8tCZSKKpAcMmCY2Q.
The /v1/client/timestamp/id/{timestampId}
endpoint loads the timestamp based on the provided parameter:
timestampId - path parameter (required) - the timestamp id
E.g. Load the timestamp having id = uEiBEtXzl3QXshn5Z1V4dgZVtMlvnx3E1f2IWFDQVqzEv_Q.
The /v1/client/timestamp/txhash/{txhash}
endpoint loads the timestamp based on the provided parameter:
txhash - path parameter (required) - the transaction hash
E.g. Load the timestamp having the transcation hash 0x9c60ca0094771afe4093b0e47260eb623d5d18140e188e671cf912609cd0e169.
The following subsections show examples of interactions with the EBSI/ESSIF frameworks using the SSI Kit command line interface, REST APIs and library SDK.
You can find more information about EBSI/ESSIF here.
This is a holistic SSI use case, which demonstrates the setup of two identities for an Issuer and a Holder on the EBSI blockchain. It also shows the steps to issue two diploma credentials to the Holder (e.g student), which then creates a Verifiable Presentation including both credentials in order to be verified. The Verifier then resolves the DIDs from the EBSI ledger and uses the corresponding public keys to verify the signatures from the issued credentials.
Creating a work-dir for all three parties of the trust triangle (Issuer, Holder & Verifier)
Setting up the Issuer (generating a key, EBSI DID and registering it on the EBSI ledger)
Setting up the Holder (generating a key, EBSI DID and registering it on the EBSI ledger)
Setting up the Verifier (only run ssikit in order to initialize the work-dir)
Creating the Verifiable Presentation containing both - the Master and the Bachelor credential
Verifying the Verifiable Presentation by resolving DIDs (public keys) from the EBSI ledger and verifying the signatures from each VC (Bachelor & Master degree credential) and from the VP itself.
Note that the order of the policies does matter. The TrustedIssuerDidPolicy & TrustedSubjectDidPolicy are verifying the presents of the DIDs on the EBSI ledger, and if they are, the keys are imported to the key-store. Once the keys are available, the SignaturePolicy can be applied in order to verify each signature.
Issuing two credentials, one Bachelor & one Master degree (values are defined by running the interactive shell). Both credentials are based on the