Skip to main content
European CommissionEBSI European Blockchain

Identify the authentication patterns

Last updated on

This section will guide you in designing the processes that authenticate the Issuers, Holders or Verifiers in your user journey. The goal is to identify each step that requires authentication and, for every instance, define its profile within the context of the tools integrated with EBSI.

How can a legal entity or natural person gain legitimate access to their resources?

Authentication defined

The following description is non-prescriptive, as EBSI does not obligate adherence to any specific authentication method. However, we emphasise the importance of grasping the definition and purpose of authentication. Authentication is the procedure organisations use to ensure that only authorised legal entities or natural persons with the correct permissions can access their resources. It is pivotal in cybersecurity, with malicious actors often seeking unauthorised system access. The authentication process comprises three main stages:

  1. Identification: Users assert their identity, typically through an identifier like a username.
  2. Verification: Users normally confirm their identity by entering a password, a piece of information known only to them. For enhanced security, many systems also require users to validate their identity using something they possess (e.g., a phone or a token device) or something intrinsic to them (like a fingerprint or facial scan).
  3. Authorisation: The system validates whether users have the necessary permissions to access the system they are trying to enter.

Authentication is important for safeguarding your solution against potential threats. Additionally, it empowers legal entities or natural persons (profiles) within your use case to safeguard the confidentiality of their personal information. Weak authentication procedures simplify the process for attackers to breach the profiles involved in your scenario. It is highly advised to adopt strong authentication methods for all profiles interacting within your scenario.

Authentication methods for your use case

In contemporary authentication methods, the authentication process is commonly outsourced to a separate identity system. Your project must define what identification and authentication methods to implement in your use case so that every type of profile that is part of your trust chain can be authenticated. For guidance on how to achieve this, please follow the steps below.

Hands on!
  1. Identify each step in the user journey of your scenario where you wish to require an authentication method and the actors involved. List these instances in Section 2 Template #12.
  2. For every authentication step, define their profile.
  3. Once you have identified and defined the profiles of each step in the user journey that use an authentication method, and you have committed to specific authentication methods, you can return to these specifications when you reach the Build your solution section. For now, you can move on to the next subsection.

Please use the table in Section 2 Template #12 below to guide you.

Section 2 Template #12

Step in your user journeyActor and relying partyAuthentication methodIdentity matching
Describe the step in your user journey where your project wishes to require authentication/identification. Examples: Requesting VCs (Accreditations, Attestations) Issuing VCs Presenting VCs OtherName the actor that authenticates and who the actor authenticates with. Examples: Holder (of type X) authenticates Issuer (of type Y) before issuance of VC (of type Z). ...What authentication/identification method is used for each instance? Non-prescriptive examples: Username/password Federated IDP Existing eID VCDefine whether identity matching is required - an actor presents an identity credential that needs to be matched to an existing identity in the database.

Once you have filled in Section 2 Template #12, proceed to Identify your capabilities.