Validating Electronic Travel Documents & ICAO PKI Certificates

When validating electronic Travel Documents, applications need to validate against corresponding issuer certificates not managed by the operating system. To do that, the application needs to get access to these certificates somehow, and build custom X.509 chains during validation. To avoid having such an application to embed the entire list of all these issuer certificates, a list which also get regularly updated, a new repository and package is available that publishes these certificates on Neurons where the package gets installed. Applications can easily check with the corresponding neuron and download the required certificates, based on the Authority Key Identifiers available in the Electronic Travel Document certificates.

Information about the ICAO PKI Certificate package
Package	`IcaoPkiCertificates.package`
Installation key	`vAa0l/iFHVogQYUzm+Zs6qPsw+7lYrnyFn4MNAGA7+Gso442gJJMKjknHqka/YjM6gZZSS65HL8Adbfba1067a1a27163b905869469d6f0d`
More information	https://github.com/Trust-Anchor-Group/IcaoPkiCertificates

#features, #id, #kyc, #neuron, #api, #repository, #package, #new

Creating broker accounts using script

One way to prepare a set of Neuro-Access accounts for a predefined set of users, is to pre-create them using script and then generate onboarding codes that can be sent to the users. Once they receive their corresponding code, they can download the app, scan the code, and connect directly to the predefined account. This method allows you to create accounts on a predefined Neuron for a known set of users, without having to create API keys, and minimizing the risk of the users creating accounts on other neurons. It also allows you to predefine the account names.

To try the following tutorial, you need access to the script prompt on your neuron. The script prompt is available from the administrative page via this option:

Creating the account

The main module of the XMPP broker, hosting the accounts, is Waher.Service.IoTBroker.XmppServerModule, or XmppServerModule for short. It has a property called PersistenceLayer that acts as an interface to the database for the XMPP server. This interface has a method called CreateAccount that allows us to create accounts. This method performs necessary checks to ensure the name is not occupied elsewhere, to protect integrity. Typing its fully qualified name into the prompt allows us to find its arguments:

Note: Finding the names of the types, properties and methods is a combination of using the Namespaces & Types option from the administrative portal, and/or using the script prompt together with the methods and properties functions. You can also use the Neuron Documentation with its DoxyGen code documentation site where you can search for classes and other relevant names.

We are now ready to create accounts. We will generate account names that are GUIDs, using the NewGuid() script function. Each account will receive a random password with sufficient entropy, generated using the RandomPassword() script function. We will not use an API Key (leaving it empty), making the account behave as a manually created account. We will not assign e-mail adddresses or phone numbers to the accounts either. To ensure the account object has a proper remote endpoint associated with its creation, we will use the Request.RemoteEndPoint value, which will contain the remote endpoint of the person executing the script function via the script prompt. (If executing the script via some other interface, you might have to change this reference to something else.) The result of calling the CreateAccount method, is a KeyValuePair<IAccount,string[]> result, where the Key portion contains the new account, if created (or null if not), and the Value portion any alternative name suggestions in case the account could not be created.

P:=Waher.Service.IoTBroker.XmppServerModule.PersistenceLayer.CreateAccount("",Str(NewGuid()),RandomPassword(),"","",Request.RemoteEndPoint);
Account:=P.Key;
AlternativeNames:=P.Value;

Note: You can call properties(Account) to review the properties of the account. You can also see that access to the generated password is protected to reduce the risk of unauthorized access to the account.

Note 2: If you want, you can create a separate API key, and reference it when you create the account. This way, you can separate the accounts from other manually created accounts. You can also control the amount of accounts that can be created.

Creating an onboarding code

Next step is to create an onboarding code. This is done in cooperation with the onboarding neuron configured for the neuron on which the account was created. The onboarding code is a URI with the obinfo: URI scheme, that references the onboarding neuron, and contains a key and a secret. The onboarding neuron on the other hand receives an encrypted BLOB containg the information necessary to access the account. This information can only be decrypted using the secret key available in the onboarding code. Furthermore, the onboarding code can only be used once. You can also define a point in time when the code expires, if it has not been used.

Note: Since the code can only be used once, it is important to transfer the code in a way where it cannot be previewed by mistake. Previewing it will result in the code automatically expiring.

To create the code, we will call the GetOnboardingUrl method on the Account object. It takes one argument: The point in time when the code will expire if not used before. In the following example, we create a code that will be valid for three days:

Code:=Account.GetOnboardingUrl(Now.AddDays(3));

The Code will contain a string representing the onboarding URI. It will be of the form:

obinfo:id.tagroot.io:14gsjgK56X6.................................:NKxDui0EMoLb1....................................

The Onboarding URI contains four parts, delimited by colons (:):

The obinfo URI scheme identifying the URI as an onboarding URI.
The onboarding neuron that contains the encrypted BLOB (but not the key).
The identifier of the encrypted BLOB.
The secret key necessary to decrypt the BLOB.

Creating an onboarding QR Code

The Neuron has a QR Code API that permits you to create QR codes for the onboarding URIs generated. The procedure is simple: A URL is generated pointing to the /QR resource on the neuron. After the resource name you add the contents you want to encode into the URI, prefixed by a /. The contents must be URL encoded. After the contents, you can add query parameters controlling how the QR code should be generated. This includes controlling the quality of the image, resolution and colors. Displaying a QR code on screen, or in an email requires less resolution, that including the image in print, for instance. A QR code for light mode displays (or white paper) should look different from QR codes for dark mode displays, for instance.

In the following example, we use the Waher.IoTGateway.Gateway.GetUrl(LocalResource) method to generate an absolute URL to an image containing a 400x400 pixel QR code encoding the onboarding URI just created. It uses a quality setting of 2, meaning 2x2 points are evaluated for every pixel generated, creating an anti-aliasing effect to create smoother edges.

CodeUrl:=Waher.IoTGateway.Gateway.GetUrl("/QR/"+UrlEncode(Code)+"?w=400&h=400&q=2");

For our example, this would result in a URL similar to the following:

https://lab.tagroot.io/QR/obinfo%3Aid.tagroot.io%3A14gsjgK56X6.................................%3ANKxDui0EMoLb1....................................?w=400&h=400&q=2

As an image, this QR code would look like:

The QR Code API documents parameters that can be used to control the colors used when generating the QR code. By appending &fg=white&bg=black&c=c0ffc0 to the URL, for instance, a QR code for dark-mode can be generated instead, as an example:

If higher resolution images are required, you can increase the w (width), h (height) and q (quality) settings. For example, an 800x800 image with 3x3 points per pixel quality would look like:

Batch creation of accounts

We are now ready to create script for the batch creation of accounts, and generate QR codes that can be distributed separately, for each account created. We will use the preview() function to display current progress in the prompt (and the batch procedure may require some time to execute, depending on the number of accounts and QR codes to create), the Get() function to retrieve the image from the generated QR Code URLs, and the SaveFile() function to save the QR codes generated, and the results of the batch procedure into a single JSON file. We will use the Waher.IoTGateway.Gateway.AppDataFolder property to save files in a location that is easily accessible, and where the Neuron has write-access. We will create a subfolder called Batch for the generated files. Finally, we generate an XML document with the same information, and store it as an XML file also. At the end we have a set of onboarding QR code image files, a JSON file with an index of all accounts created, and a similar XML file with the same information. We create the following batch account-creation function:

CreateAccounts([N]):=
(
	Created:=NowUtc;
	Accounts:=
	{
		"NrAccounts":N,
		"Created":Created
	};
	Records:=[];
	AccountNr:=1;

BatchFolder:=Waher.IoTGateway.Gateway.AppDataFolder+"Batch";
if !System.IO.Directory.Exists(BatchFolder) then
	System.IO.Directory.CreateDirectory(BatchFolder);

while AccountNr<=N do
(
	AccountNrStr:=Str(AccountNr);
	preview("Creating account "+Str(AccountNrStr)+"...");

do
(
	P:=Waher.Service.IoTBroker.XmppServerModule.PersistenceLayer.CreateAccount("",Str(NewGuid()),RandomPassword(),"","",Request.RemoteEndPoint);
	Account:=P.Key;
	AlternativeNames:=P.Value
)
while !exists(Account);

Code:=Account.GetOnboardingUrl(Now.AddDays(3));
CodeUrl:=Waher.IoTGateway.Gateway.GetUrl("/QR/"+UrlEncode(Code)+"?w=400&h=400&q=2");
QrCode:=Get(CodeUrl);

QrCodeFileName:=BatchFolder+"\\"+Left("00000000",9-len(AccountNrStr))+AccountNrStr+".png";
SaveFile(QrCode,QrCodeFileName);

Record:=
{
	"AccountNr":AccountNr,
	"UserName":Account.UserName,
	"OnboardingUrl":Code,
	"QrCodeUrl":CodeUrl,
	"QrCode":QrCodeFileName
};

PushLast(Record,Records);
AccountNr++;
);

Accounts["Records"]:=Records;

SaveFile(Accounts,BatchFolder+"\\Accounts.json");

AccountsXml:=<Accounts nrAccounts=N created=Created>
	<[[foreach Record in Records do 
		<Account accountNr=(Record.AccountNr) userName=(Record.UserName) onboardingUrl=(Record.OnboardingUrl) qrCodeUrl=(Record.QrCodeUrl) qrCode=(Record.QrCode) />
	]]>
</Accounts>;

SaveFile(AccountsXml,BatchFolder+"\\Accounts.xml");
);

You can download the script file from the following link: CreateAccount.script

#tutorial, #script, #account, #neuro-access, #onboarding

Page retrieved from simulation

This page is retrieved as part of a multi-modal simulation, available in the ComSim repository. It simulates web actors that also connect using web-sockets and use digital identities via XMPP, which they use for MFA and for QuickLogin. The report contains more details about an execution of the simulation.

#comsim, #example

10 Simulated Accounts with Digital Identities online for test

10 accounts with simulated digital identities are now available online, accessible via XMPP. They can be used for test, for instance, if you are implementing a service relying on Multi-Factor Authentication using the Remote Login API, or similar.

Following is the list of accounts being used, and the corresponding digital identities:

Simulated identities
JID	Legal ID
`SimLegal1@lab.tagroot.io`	`30f421e9-c12c-4731-d432-0c297a1697db@legal.lab.tagroot.io`
`SimLegal2@lab.tagroot.io`	`30f421ea-c12c-4736-d432-0c297a3d84c9@legal.lab.tagroot.io`
`SimLegal3@lab.tagroot.io`	`30f421ea-c12c-4750-d432-0c297a14f4b8@legal.lab.tagroot.io`
`SimLegal4@lab.tagroot.io`	`30f421ea-c12c-4758-d432-0c297aaeb627@legal.lab.tagroot.io`
`SimLegal5@lab.tagroot.io`	`30f421eb-c12c-476d-d432-0c297a7108a0@legal.lab.tagroot.io`
`SimLegal6@lab.tagroot.io`	`30f421eb-c12c-4788-d432-0c297a728f7e@legal.lab.tagroot.io`
`SimLegal7@lab.tagroot.io`	`30f421eb-c12c-4794-d432-0c297ae03870@legal.lab.tagroot.io`
`SimLegal8@lab.tagroot.io`	`30f421ec-c12c-47aa-d432-0c297a24fd6c@legal.lab.tagroot.io`
`SimLegal9@lab.tagroot.io`	`30f421ec-c12c-47b8-d432-0c297a2fade1@legal.lab.tagroot.io`
`SimLegal10@lab.tagroot.io`	`30f421ec-c12c-47be-d432-0c297a74a7e4@legal.lab.tagroot.io`

QR Codes

The following QR codes are available for ease of access to the above devices.

Petitions

The accounts will automatically accept the following petitions:

Identity Petitions: Scan the QR Codes (or enter the Legal IDs manually) using the Neuro-Access App to send an Identity Petition to the account. The petition will be accepted and approved automatically.
Signature Petitions: Initiating a Remote Login using the Remote Login API will send a Signature Petition to the account. This petition will be automatically approved as well. The Remote Login API will return a JWT token as soon as the petition has been approved and signed.

Note: The model controlling the simulation can be reviewed in the ComSim repository

#simulation, #comsim, #iot, #iotid

Remote Login API

Since Build 2025-12-30, extended in Build 2025-12-31, a new API called the Remote Login API is available on the TAG Neuron®. It is a complement to the Quick Login API, in the following ways:

The Quick Login API is initiated by the client itself, for instance, by scanning a QR-code, clicking a link or logging in to a web site, for instance.
The Remote Login API on the other hand, is initiated by a remote service, that wants to use the digital identity of the user in a second (or multi) factor authentication process (2FA, or MFA).
The Quick Login API allows anonymous access (on the HTTP resource level), while the Remote Login API requires authorized access. This authorized access can be granted using WWW-Authenticate or Mutual TLS (mTLS). Mutual TLS is recommended, as it avoids the use of passwords. In both cases, the administrator of the Neuron providing access to the API needs to create a corresponding user and grant the user the corresponding privileges. (See the API documentation for details.)

#new, #api, #neuron, #security, #id

Posts by user

No more posts authored by the user could be found. You can go back to the main view by selecting Home in the menu above.