Agree on the identification/authentication method of legal entities and natural persons
The following section is to 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 in the context of the supportive tools interconnected 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 mandate the commitment to any specific kind of authentication method, but we do highlight the importance of the following definition. Authentication is the procedure employed by organisations such as yours to verify that only authorised legal entities or natural persons with the appropriate permissions can access their resources. It plays a crucial role in cybersecurity as malicious actors prioritize gaining unauthorized access to systems. The authentication process comprises three main stages:
- Identification: Users establish their identity, typically by providing some kind of identifier like a username.
- Verification: Normally, users confirm their identity by entering a password, a piece of information known only to them. However, for enhanced security, many systems also require users to validate their identity using something they possess (like a phone or a token device) or something inherent to them (such as a fingerprint or facial scan).
- 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 attacks. Additionally, it empowers legal entities or natural persons (profiles) within your use case to maintain the confidentiality of their personal information. When authentication procedures are weak, it becomes simpler for attackers to compromise the profile part of your scenario. It is highly advised to adopt strong authentication methods for all profiles interacting within your scenario.
Authentication methods for your use case
Within contemporary authentication methods, the authentication process is commonly outsourced to a distinct 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.
- 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.
- For every authentication step, define their profile.
- 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 are in section Build your solution. 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 journey | Actor and relying party | Authentication method | Identity matching |
|---|---|---|---|
| Describe the step in your user journey where your project wishes authentication/identification to be required. Examples: Requesting VCs (Accreditations, Attestations) Issuing VCs Presenting VCs Other | Name 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 VC | Define 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, please move on to Identify your capabilities.