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

Simulating Identity and Signature Petitions

A new ComSim simulation called LegalIdentities.xml simulates a series of XMPP-connected devices that apply for digital identities, and automatically respond to identity and digital signature requests. This simulation can be used for test purposes, to test function and load, as well as measure performance. It can also be used during development of other services interacting with users of digital identities for the purposes of Multi-Factor authentication. By using the digital identities of the simulated users, automatic signatures are created, which simplifies the development life-cycle, as the developer does not need to manually sign each time the MFA procedure takes place.

Report

To review the simulation model, check out the XML definition. It contains references to both the XMPP and XMPP Legal modules of ComSim. Each actor checks if they have a digital identity. If not, the actor applies for a new simple digital identity. From Build 2026-01-07 of the Neuron®, such digital identities are automatically approved. Once such approved digital identities exist, the actors stochastically send identity and signature petitions to each other. They also accept each other’s petitions automatically. This means that they will approve external requests also. This allows them to be used for other purposes as well, as mentioned earlier. You can use this simulation together with integration of the QuickLogin API and RemoteLogin API for instance.

Also review the full report generated by one simulation of the model, for more information.

#new, #comsim, #simulation, #id, #tagsign

Custom Event Sinks

From Build 2026-01-06 the IoT Gateway now supports configuration of custom Event Sinks in the gateway.config file. On the TAG Neuron, the contents of this file is editable, via the corresponding data source. From the Sources & Nodes menu in the administrative panel, the data source Gateway configuration now contains a new node called EventSinks:

Adding custom event sinks

By selecting the EventSinks node, and pressing the Add button, you can add new event sinks. The options available depend on what services are hosted on the Neuron:

Default Event Sink Types

The following event sink types are available by default, at the time of writing:

• Event Filter allows you to filter out a subset of events of interest. The Event Filter sink then passes it on to child-sinks, which propagate them in accordance with their instructions.

• MQTT Event Sink propagate incoming events to a topic on an MQTT broker.

• Pipe Event Sink forwards events to an operating system Pipe, allowing another process on the machine access to the events.

• TCP/IP Socket Event Sink sends the logged events via TCP/IP to a remote machine.

• Text File Event Sink stores events in text files. By including date and time tags in the file name, a sequence of files can be generated. The event sink also automatically delete old files.

• WebHook Event Sink forwards events to an external source using POST. The protocol used depends on the URI scheme used by the Callback URI. The WebHook Event Sink can also collect and group events together, for easier processing on the recipient side.

• XML File Event Sink records events into XML files. Date and Time tags in the filename allow you to create a sequence of XML files generated. Old files are automatically deleted.

• XMPP Event Sink sends logged events to an XMPP recipient. Child Nodes

#new, #features, #neuron, #gateway