[urn] Registration for the TEI: URN identifier

**Namespace Identifier:**  tei  
**Version**:  1  
**Date**:  2026-03-03

**Registrant**:    
	ECMA International, TC54, task group 1  
	Contact:  
		Olle E. Johansson  
		\+46 70 593 68 51  
		[email protected]

TC54 is formed with OWASP CycloneDX project. The TEA specification is developed by the OWASP CycloneDX community and will be standardised in ECMA International during 2026\.

**Purpose**:   
The TEI identifier is a core component of the Transparency Exchange API developed by OWASP Foundation in ECMA TC54. The API is providing an automatic way to download and query software transparency artefacts, ranging from SBOMs to certificates and attestations. The protocol includes a discovery function with a persistent identifier, the transparency exchange identifier (TEI) that is a URN for a distributed product. With the URN a client can discover the API services for a given product. The URN supports existing identifiers, like bar codes and vendor specific article numbers, but also new ones if there’s no existing identifier. The TEI is meant to be distributed with the product, either in a GUI or outside of a box as a QR code.

By having a persistent identifier that is disconnected from the actual HTTPS API endpoints, there is long term stability in the identifiers, which is a requirement.

The TEA platform will provide automation in the delivery of software supply chain artefacts, something that works well with legislations like the EU Cyber Resilience Act as well as vertical industry regulations.

The TEA API will be used by purchasing departments, compliance departments as well as product development team to manage their upstream software supply chain. Applications that currently use SBOMs has no automatic and standardised way of discovering the source, staying up to date and alerting the users of changes. This fits well into the architecture of, as an example, OWASP Dependency Track (Open Source).

The work with the API is reaching a 1.0 release to be defined as an ECMA standard by the end of 2026 together with the update of CycloneDX, which is already a standard. (https://tc54.org)

   Syntax:    
	The TEI consists of three core parts

**urn:tei:\<type\>:\<domain-name\>:\<unique-identifier\>**

* The **type** which defines the syntax of the unique identifier part  
* The **domain-name** part resolves into a web server, which may not be the API host.  
* The uniqueness of the name is the domain name part that has to be registred at creation of the TEI.  
* The **unique-identifier** has to be unique within the domain-name. The syntax of this is set by the **type** field. Recommendation is to use a UUID but it can be an existing article code too

For more information, please see:   
[https://github.com/CycloneDX/transparency-exchange-api/tree/main/discovery](https://github.com/CycloneDX/transparency-exchange-api/tree/main/discovery)

**Assignment**:  As we base the TEI uniqueness on the domain name, the assignment is open for any vendor. One product may have multiple TEIs with different types. The vendor is responsible for uniqueness within the registered domain.

**Security and Privacy:**  The TEI is for products only, like sold products or open source software projects. We can’t immediately spot any privacy concerns.

**Interoperability**:  We have defined types for many different software identifiers, including the Package URL (ECMA-427) and have not seen any specific issues of using standard encoding formats. There are at least three open source implementations that have proved interoperability. We have also consulted standard organisations for various bar codes used as product identifiers and have not gotten any concerns.

**Resolution**:  Not applicable.

**Documentation**:    
	The TEA spec is currently hosted on github:  
	[https://github.com/CycloneDX/transparency-exchange-api/tree/main](https://github.com/CycloneDX/transparency-exchange-api/tree/main)