A new open repository has been published that simplifies the creation of new identity authenticator services on the TAG Neuron® to customize KyC. The repository also contains instructions on how to implement such a service, what interfaces to use, and the different steps that need to be completed in order to create an installable package for the service, to distribute it in a Neuron® network.
Selecting the Identity Authenticator Template when creating a new repository
As of build 2024-01-16 configuring the Onboarding Neuron® has been refactored. Articles earlier written on the subject (which have now been updated accordingly) include:
The purposes of hosting an Onboarding Neuron® include:
Acting as the first contact point for a client application (such as a digital ID), helping the client to find a suitable service provider hosting their own Neuron®.
Validating e-mail and phone numbers.
Sending validation messages via e-mail and SMS.
Configuring Onboarding Domain
You now configure the domain name of the Onboarding Neuron® under the Notarius Electronicus menu (previous versions had a Neuro-Access button under the Software menu, which has been removed):
Onboarding Menu
Clicking on this menu item opens a simple dialog where you enter the domain name of the Onboarding Neuron® you want to use:
You can also access the service from the Admin menu, by pressing the Neuro-Access button:
Neuro-Access Button
Configuration of the Onboarding Neuron®, used by this service, has been moved to the Neuron® itself. See the article Configuring alternative onboarding Neuron for more information.
Onboarding process
During the onboarding process, the user validates its e-mail address and phone number with an onboarding Neuron®, who directs the app to the most suitable host for the Neuro-Access account. If the user chooses to create a simple Neuro-Access digital identity (i.e. only containing the phone number and e-mail address provided) the digital identity can be automatically approved, if the host Neuron® is able to validate the information with the onboarding Neuron. This service performs this task: It registers an Identity Authenticator with the Neuron®, which authenticates such simple Neuro-Access digital identities with the onboarding Neuron®, and approves the applications automatically, if the information matches the information validated during the onboarding process.
Configuration page
The configuration page for the service is very simply. All you need to do is provide the domain name of the onboarding Neuron® used. By default, the TAG ID Onboarding Neuron® will be selected.
Neuro-Access Settings
Configuration of the Onboarding Neuron®, used by this service, has been moved to the Neuron® itself. See the article Configuring alternative onboarding Neuron for more information.
It is now (from build 2023-08-10) possible to create smart contracts containing a new type of parameter, the Role Reference Parameter. When creating contracts that need to reference properties of the identities of any of the signatories, you had to previously create duplicate contract parameters to reflect these values. This gave rise to integrity problems, as you had no automatic check that the values were correct. It was also problematic for users, as they had to provide the infomration manually multiple times. With the new type of Role Reference Parameter, the assignment of these parameter values is automatic when the corresponding role signs the contract.
When defining a Role Reference Parameter, you provide:
The Role
An Index, where 1 means the first signatory that signs using the corresponding role, 2 means the second, and so on.
A Property, which references a property in the Legal Identity of the signatory. You can use any well-known ID property, Organization ID property or custom ID property you like.
If the property is Required or not. If required, a signature from a party lacking this property will not be accepted.
LegalLab
LegalLab has been updated to support Role Reference Paramters. There is also an new example showing how Role Reference Parameters can be used. When loading this example into LegalLab, you will notice that the parameters have been divided into two sections in the Design Tab, the Editable Parameters and the Referenced Signatory Properties:
Role Reference Parameters in LegalLab
Before signature, these properties have now values:
Before Signature
Once the contract is signed however (here I’ve signed the contract twice, as illustration), the values automatically become available, and visible in the contract:
After Signature
ID App
The ID App has also been updated. As soon as the app has been published to App and Play stores, it will be available to users. Meanwhile, develops can access this feature by retrieving the latest version from the repository.