HTTP-XMPP Bridge

The IoTBridgeHttp repository provides an IoT bridge between external devices that POST sensor data to the bridge using HTTP, for use in closed intra-networks or enterprise networks, or the public Internet, and the harmonized XMPP-based Neuro-Foundation network, for open and secure cross-domain interoperation on the Internet.

To run the bridge, you need access to an XMPP broker that supports the Neuro-Foundation extensions. You can use the TAG Neuron for XMPP.

Running and configuring the bridge

The code is written using .NET Standard, and compiled to a .NET Core console application that can be run on most operating systems. Basic configuration is performed using the console interface during the first execution, and persisted. You can also provide the corresponding configuration using environment variables, making it possible to run the bridge as a container. If an environmental variable is missing, the user will be prompted to input the value on the console.

Environmental Variable	Type	Description
XMPP_HOST	String	XMPP Host name
XMPP_PORT	Integer	Port number to use when connecting to XMPP (default is 5222)
XMPP_USERNAME	String	User name to use when connecting to XMPP.
XMPP_PASSWORD	String	Password (or hashed password) to use when connecting to XMPP. Empty string means a random password will be generated.
XMPP_PASSWORDHASHMETHOD	String	Algorithm or method used for password. Empty string means the password is provided in the clear.
XMPP_APIKEY	String	API Key. If provided together with secret, allows the application to create a new account.
XMPP_APISECRET	String	API Secret. If provided together with key, allows the application to create a new account.
REGISTRY_COUNTRY	String	Country where the bridge is installed.
REGISTRY_REGION	String	Region where the bridge is installed.
REGISTRY_CITY	String	City where the bridge is installed.
REGISTRY_AREA	String	Area where the bridge is installed.
REGISTRY_SRTEET	String	Street where the bridge is installed.
REGISTRY_STREETNR	String	Street number where the bridge is installed.
REGISTRY_BUILDING	String	Building where the bridge is installed.
REGISTRY_APARTMENT	String	Apartment where the bridge is installed.
REGISTRY_ROOM	String	Room where the bridge is installed.
REGISTRY_NAME	String	Name associated with bridge.
REGISTRY_LOCATION	Boolean	If location has been completed. (This means, any location-specific environment variables not provided, will be interpreted as intensionally left blank, and user will not be prompted to input values for them.
JWT_SECRET	String	Secret used to create JWT tokens. If not provided, a random secret will be created.
X509_FILENAME	String	File name to X.509 certificate to use. If not provided, HTTPS will not be enabled.
X509_PASSWORD	String	Password to X.509 certificate.
HTTP_PORT	Integer	Port number to use for unencrypted HTTP. (default is 80)
HTTPS_PORT	Integer	Port number to use for encrypted HTTPS. (default is 443)
ADMIN_NAME	String	Administrator User name.
ADMIN_PASSWORD	String	Administrator Password.
USER_COUNT	Integer	Number of users to create. (Default is 0, which will trigger manual input of users.)
USER_N_NAME	String	User name for user N. (where N is a number between 1 and USERS_COUNT)
USER_N_PASSWORD	String	Password for user N. (where N is a number between 1 and USERS_COUNT)
USER_N_PRIVILEGE	String	Regular expression specifying the privilege or privileges held by the user. (Default is Admin.SensorData.Post.)

Running in a Docker container

You can run the bridge in a Docker container. When doing so it is important to either configure all settings via the environment variables, or to redirect stdin and allocate a TTY. You do this using the -it switch to docker run. For example:

docker run -it iot-bridge-http

Setting up persistent storage

Persistent storage is required to store configuration, as well as data about the bridge, its nodes, and ownerships, etc. You can do this by mapping the local folder /var/lib/IoT Gateway to a Volume when creating the container.

Using an environment file

You can provide environment variables using an environment file. Create a new text file based on the IoTBridgeHttp.env file in the repository. Set the values you want to provide, and then use the --env-file switch when creating the container. For example:

docker run -it --env-file IoTBridgeHttp.env -v /my/local/folder:/var/lib/IoT\ Gateway iot-bridge-http

Note: If providing credentials, make sure the file is not accessible by others, and make sure it is not checked in to any repository. An alternative to providing credentials in an environment file, is to enable standard and terminal input, and provide it via the prompt (see above).

Claiming ownership of bridge

Once the bridge has been configured, it will generate an iotdisco URI, and save it to its programd data folder. It will also create a file with extension .url, containing a shortcut with the iotdisco URI inside. A .png file with a QR code will also be generated. All three files contain information about the bridge, and allows the owner to claim ownership of it. This can be done by using the Neuro-Access App. This app is also downloadable for Android and iOS. You scan the QR code (or enter it manually), and claim the device. Once the device is claimed by you, you will receive notifications when someone wants to access the deice. They will only be able to access it with the owner’s permission. For more information, see:

• Registration, discovery & ownership process
• Decision support for deviceos
• Provisioning for owners

Configuring the bridge

The bridge can be configured in detail by a client that implements the concentrator interface. Concentrators consist of data sources, each containing tree structures of nodes. Nodes may be partitioned into partitions, which permits the nesting of subsystems seamlessly into container systems. Each node can be of different types, and have different properties and underlying functionality. They can each implement then sensor interface and actuator interface.

You can use the Simple IoT Client to configure concentrators and their nodes in detail. An initial setup is done using the initial configuration of the bridge. The client is also available in the IoTGateway repository, in the Clients folder.

Node Types

The bridge includes several different node types that can be used to configure its operation:

• The Local Web Server Node represents the local web server in the gateway. This node hosts the web service that allows external devices to POST sensor data to the bridge. It also acts as the root node for the subtree of nodes representing devices that receive sensor data via HTTP POST requests.

• The XMPP Broker maintains a connection to an XMPP Broker. It allows the bridge to connect to other entities on the federated network and communicate with them. It supports communication with remote standalone sensors and actuators, as well as remote concentrators embedding devices into data sources and nodes. Such concentrators can be bridges to other protocols and networks.

  Note: The bridge has a client-to-server connection by default, setup during initial configuration. Through this connection, the bridge acts as a concentrator. Through the use of XMPP Broker nodes you can setup additional XMPP connections to other brokers. In these cases the bridge will only act as a client, to connect to remove devices for the purposes of interacting with them.

• IP Host nodes allow you to monitor network hosts accessible from the bridge.

• Script nodes allow you to create nodes with custom script logic. They can be used to interface bespoke devices in the network accessible from the bridge, for example.

• Virtual nodes are placeholders where external logic (or script logic) can aggregate information in a way that makes them accessible by others in the federated network.

API Reference

The local web service registers a series of web resources that external devices can use. Following is a brief overview, with references for more details.

Sensor Data Receptor

The Sensor data receptor resource /ReportSensorData is used by external devices to POST sensor data to the bridge. The device needs to authenticate with the bridge, before it can be authorized to access this resource. The device can use different mechanisms to authenticate itself with the bridge:

• Use of Mutual TLS (mTLS). This requires the bridge to be configured with a certificate.
• Use of WWW-Authenticate web login procedure.
• Use of JSON Web Tokens (JWT) Bearer tokens for authentication. This requires the device to login first using the Login resource (see below).

For details on how the resource works, see the Sensor Data Receptor API endpoint on lab.tagroot.io as an example. The same page can be viewed on the bridge, once it is up and running.

Login resource

The Login resource /Login is used to login to the bridge. If successful, a Bearer JWT token is returned. External devices need to login to the bridge before they can POST sensor data to it. A token is valid for 1 hour. The external device needs to renew the token by loggin in again, if accessing the bridge for a longer period of time.

Input payload is expected to be a JSON object of the following type.

{
	"UserName": Required(Str(PUserName)),
	"PasswordHash": Required(Str(PPasswordHash)),
	"Nonce": Required(Str(PNonce))
}

The response is a JSON object of the following type:

{
	"Ok": Required(Bool(POK)),
	"Message": Required(Str(PMessage)),
	"Token": Optional(Str(PToken))
}

See the Web login procedure article for more details on how to compute the password hash and nonce values, and use them in the login process.

Root folder resource

The Root folder resource /. If no specific resource above is referenced, the default is to look for a file resource in the Root folder, and return it if found. This allows you to host custom web content on the bridge.

Web Page

The root resource / makes a temporary redirection to /Index.md, which is the landing page for the bridge. It contains basic information about the bridge, as well as a login-mechanism to access the setup of the bridge. Once logged in, you can manually edit roles and users.

Security

The HTTP bridge supports multiple levels of security:

• Access to things published on the federated network is protected by provisioning. When the gateway starts, it generates an iotdisco URI, which can be used to claim ownership of the device. Once claimed, the owner receives notifications when someone wants to access the device, and can decide whether to allow access or not.

• The bridge supports a set of users and roles, each defining a set of privileges. During first start, the initial users and roles are configured. This can be done either using environment variables, or by providing input on the console. An administrator user is created, which will have all privileges. Once the bridge is up and running, the administrator can login and configure existing users and roles, and create new ones.

• A Web-Application Firewall (WAF) is included in the bridge. The administrator can configure the WAF to block or allow access to specific resources, based on application-level rules. This can be used to restrict access to certain pages (such as the administrative pages) to certain IPs, for instance, or rate-limit access to certain resources, such as sensor-data publication resrouces.

  The Web-Application Firewall is defined in the WAF.xml file. It is an XML file that needs to validate against the https://waher.se/Schema/WAF.xsd namespace. The default version restricts access to the administration pages to local area network IP addresses.

#new, #repository, #iot, #http, #xmpp, #bridge

Age-verification without leaking birth date

This article describes the process of how to create a Legal Identity that can be used to demonstrate you have reached a certain age, without having to disclose your actual birth date. This is an important mechanism to protect the integrity of personal information, especially if the person is a child.

Creating a Preview ID application

The first step is to create a Preview Legal Identity application containing sufficient personal information so that the age can be verified. This application will have to contain sensitive personal information, including birth date. But creating a Preview application ensures the data is not stored in a searchable database or logs. Instead it is stored in encrypted form, and only during the process to validate the information. Once the preview application has been validated, a new application can be created, containing a subset of the sensitive information, and once that is completed, the sensitive information will be removed.

The personal data necessary to include in the Preview application is:

Property	Description
BDAY	Birth Day
BMONTH	Borth Month
BYEAR	Birth Year
AGEABOVE	Age above the stated number of years

Creating real ID application

Once the Preview application has been approved, a new, real ID application is made. This new application has to have a reference to the Preview application, and should only contain a subset of the properties. At a minimum, the following properties should be included:

Property	Description
PREVIEW	Reference to the earlier Preview application.
AGEABOVE	Age above the stated number of years

Once this application has been approved, the sensitive personal information will be removed as the preview application is deleted.

Proving your age

Proving your age is as simple as performing a Quick Login with the new identity. If property filters are used, include the AGEABOVE property. As the new identity contains a reduced set of information, and no birth-date (if it was removed in the second step above), only the AGEABOVE property is received, together with proof the Neuron has validated the claim.

How to set AGEABOVE

The AGEABOVE property should not be set to the age of the user, as that can leak personal information. Instead, it should be set to a legal limit required for one or more specific purposes. If there’s an age requirement in a country for a particular purpose, that age should be encoded in the AGEABOVE property. The property will be accepted if the personal information provided in the preview can be validated, and the age of the person deduced is at or above the indicated number.

As there are different age limits for different purposes and countries (for instance, 13, 15, 16, 17, 18, 20 and 21 are common limits), the site that tests the age of a user should not expect the number to be a specific value. Instead, it should expect the number to be at least a specific number. If there’s an age requirement for a service of 16 years of age, identities with any number for AGEABOVE greater or equal to 16 should be accepted as proof ther person is at least 16 years old.

Ensuring you have reached a certain age to create an identity

The AGEABOVE property can also be used to ensure the user of the app attempting to create an identity, has reached a certain age. Adding the property ensures the identity attempted to be created only gets approved, if the person actually has reached the age.

If the person has not reached the corresponding age, the property will become invalid, and an error with error code AgeNotReached will be logged on the application.

#new, #neuron, #features, #id, #security, #privacy

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

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