1 - Become operational as a Verifier
To verify Verifiable Credentials presented by Holders, you can choose to implement the Verifier functionality yourself or use an existing EBSI conformant implementation.
You can use the Find your wallet tool to help you find an EBSI Conformant Wallet that best suits the needs of your organisation. To find an appropriate option, tick Verify in the desired capabilities.
The rest of this section describes how build your own Verifier implementation if you choose to.
Step 1. Set up Authentication Service
The Authorisation Server (AS) is responsible for authentication and authorisation on behalf of the Verifier. The Authorisation Server has the capabilities to request Clients' ID Tokens, exchange information over Verifiable Presentation, and issue access Tokens.
Due to the nature of EBSI, the setup can be method-agnostic, which means that organisations can choose the method and protocol that best suits them. This allows organisations to configure the authorisation service according to their specific needs.
Let's see some examples:
- OpenID Connect (OIDC) is an identity protocol and open standard that is built using the OAuth 2.0 and that supports authorisation-based credential exchange where the holder authorises a verifier (client) to access information on his behalf.
- OpenID for VPs (OID4VP) is a protocol that supports self-sovereign credential exchange where the holder can autonomously control the exchange of credentials with any verifier they choose. Both specifications are complementary as they solve different problems.
Step 2. Set up Authorisation Service
First, choose the method and protocol that you want to use for the authorisation service. Next, configure the authorisation service according to the instructions for the method and protocol that you have chosen. The Verifier's Authorisation Server must provide an /authorize endpoint. This endpoint starts the authentication process.
As a response, the AS returns an HTTP redirect to the Client's redirect_uri with a request object as an URL parameter. Depending on the chosen protocol this request object is either an ID Token Request (response_type is id_token) or a VP Token Request (response_type is vp_token).
The Client processes the request and posts a response to the /direct_post endpoint of the AS.
Step 3. Set up Verification Capabilities
A verification service is a trusted party that can verify the authenticity of a Verifiable Presentation.
This is done by checking the signature of the credential issuer and verifying that the credential has not been revoked.
The verification service can be used by anyone who wants to verify the authenticity of a Verifiable Credential. This includes individuals, organisations, and applications.
A Verifiable Presentation is a collection of verifiable credentials that together represent a claim about the holder's identity or attributes. Learn more about the Verification Presentation Service here
Step 4. Set up the Verification Service
A Verifiable Presentation must be validated against the Verifiable Presentation data model. The VP must be signed by the Holder of the included VCs and identified by did:key for natural persons or did:ebsi for legal entities. In the case of legal entities, the DID must be resolved to the DID Document in EBSI DID Registry and validated with the keys therein.
In the case of natural persons, the did:key must not refer to any DID Document found in DID Registry. Instead, the VP signature is validated with the public contained in did:key. In addition to validating the VP itself, the contained Verifiable Credentials must also be validated. The VCs must also conform to the schema to which they refer. VC signatures must also be validated.
In the case of VCs issued by Legal Entities, the DID Document should be found in the DID Registry. In addition, the Verifier must check the Issuer's accreditation in the Trusted Issuer Registry. More comprehensive instructions on how to verify VCs and VPs can be found in the EBSI developers hub. In addition, EBSI provides a TypeScript implementation for verifying VCs and VPs.
2 - Request one or more Verifiable Credentials as a Verifier
To request VCs, the verifier needs to:
- Authenticate the user *
- Display the VC sharing options
- Give the user the possibility to redirect to their wallet or present a QR code
- Accept the Verifiable Presentation
- Validate the Verifiable Presentation and Verifiable Credentials
- Grant access for the verified purpose
- This can be direct (access_token) or indirect (platform integration).
*Optional or conditional steps