IOTA Standardization Update

As we proclaimed in 2019, IOTA is on a mission to set and become a de facto standard in DLT and IoT technology. Today, we will explain what standards are, the standards that apply in our space, and what we are doing specifically with standardization. In addition, we will discuss what we have in development for the IOTA Protocol and the progress we’ve made over the last few months.

Stay tuned for future updates, as we work our way through the various standards processes at the Object Management Group (OMG) and elsewhere, as well as communicate the state of IOTA’s own standards.

What does it actually mean to be a standard?

Standards are so ubiquitous that usually, we don’t need to think about them. For example, you don’t have to think about which way to turn a screw. For more complex requirements such as interoperability between computer models, some group of experts will have had to think long and hard about the requirements. Once they get this right, this can be published as an international standard, so that everyone can now refer to the same requirements.

A standard is really a special kind of requirement specification, in which everyone can agree what specification they are referring to, what the latest version is, and how to use it. In the Internet of Things, this is particularly relevant, since there will be several layers of protocols, each defined in its own standard. These include W3C standards, IETF, and industry de facto standards like Zero MQ.

At this level, when we use the word ‘standard’ we might just be referring to something that everyone has agreed to refer to, for example, a common industry standard or even the standard way some vendor does something. These are what we call ‘de facto’ standards. Effectively, IOTA is already a de facto standard — you need to refer to it in order to build anything that can be run on the IOTA Mainnet or that extends or exchanges data with an IOTA Node.

Standard setting is a key part of engineering. Standards are often quoted as part of a specification. Back in the days when everything was printed a specification might be more than a meter thick, as it contained copies of all the standards referenced in it.

The use of standards gives the user of any product a level of confidence that all aspects of a product covered by a standard will behave the same way. They don’t need to think about which way to turn a screw.

There are also times when more confidence in a standard is needed. How do I know your standard won’t change, is the latest version, and there aren’t any vulnerabilities or other gotchas that other users have found?

For this kind of confidence, we look to official standards bodies to manage and maintain formal standards, as international or industry standards. These are set by groups like theInternational Organization for Standardization(ISO), theObject Management Group (OMG), as well as more specialized ones like the World Wide Web Consortium (W3C) and the Internet Engineering Task Force(IETF).

Note that most standards bodies don’t ‘write’ the standards as such. Rather, a company or industry consortium will take a standard they have developed and submit it to the standards body. In doing so, they are subjecting it to a level of scrutiny, formal control and best practice that will give everyone more confidence in that standard than when it was just a group of people doing it on their own. The standards body will also take steps to make sure that your new idea for a standard isn’t doing something that already exists, and that a fair and level playing field exists among industry participants.

IOTA Foundation is looking to set and become a set of key standards for Distributed Ledger Technology and the Internet of Things. Through our work over the last few months, The IOTA Protocol has already become a ‘de facto’ standard, in the sense that existing node software (IRI, Bee and Hornet) behave in a standard way in order to participate in the Tangle. The next step is to submit the IOTA Protocol as a formal international standard via the Object Management Group (OMG), thereby introducing a level of formal control and governance while giving users confidence that the standard can be used consistently across industries.

Every standards body has its own formal processes for the development and publication of formal standards. These processes vary considerably but are geared towards the common outcome of publishing a formal specification that can be followed by anyone wishing to build a product or service that can assert conformance to that standard or to specific conformance points defined in the document. Standards-setting processes are designed to ensure a level playing field among participants. It is generally required that the standard is reflected in some real-world application before it can be published.

The currently active IOTA standards initiatives are being pursued through the Object Management Group. The OMG also has an arrangement whereby it is possible to ‘fast track’ an OMG standard to become an ISO standard.

The Object Management Group (OMG) has two routes towards the publication of a formal international standard specification. These are:

Request for Comments (RFC)
Request for Proposals (RFP)

These are shown in the diagram below. In some cases, the development of an RFP is preceded by a more general ‘Request for Information’ (RFI) in which the relevant OMG Task Force determines whether or not there is a need for a new standard for a particular set of requirements.

The ‘Request for Comments’ (RFC) process is intended for use when there is an existing de facto standard and there is no realistic chance that someone else may wish to propose a standard to meet the same requirement. An RFC is submitted directly by the organization that already maintains that standard, and if accepted by the relevant OMG Task Force, the initially submitted version is then put out for review to the public. Responses are sought by OMG members and non-members alike since the purpose of this process is to ensure that there is no competing specification. The RFC process is used with caution. If it is shown that someone else could also submit a specification to cover the same set of requirements, the proposal will be knocked back and replaced by the RFP process.

The ‘Request for Proposals’ (RFP) process is used when the OMG community sees the need for a standard and asks people to submit proposals. Whereas an RFC is submitted directly by the de facto standard maintainer, an RFP is drafted by an OMG Task Force. Once finalized, the RFP goes out to OMG members who are encouraged to submit a potential standard specification as a response to that RFP.

In special cases such as for DLT-related standards, a Special Interest Group such as the Blockchain Platform SIG may assist in drafting an RFP or RFI. This group then brings it to the appropriate OMG Task Force for formal voting and action.

Standards are a two-way street. We also benefit from and use existing standards in drafting our own specifications. This is a requirement for OMG RFC submissions and RFP responses. Our IOTA standards submissions will, therefore, use standard notations whenever possible to describe things in the specification — whether this is something as simple as mathematics, or industry notations like UML for class diagrams, state machines, and so on.

We have also started to fine-tune our own internal specifications to be more in line with formal international standards, as well as defining our own internal processes for RFI, RFP, and RFC in the development of IOTA specifications.

The IOTA Foundation is a member of the Object Management Group (OMG), the standards body responsible for the Unified Modeling Language (UML) and other international standards. IOTA also participates in the TangleEE consortium and in the Trust over IP Foundation (ToIP). We are also in the process of reaching out to the IEEE, ETSI and United Nations agencies like the ITU among others.

At OMG, IOTA participates in several task forces and special interest groups, including the Blockchain Platform SIG(Blockchain PSIG).

As a ‘citizen’ of the OMG ecosystem, IOTA has already played an active part in the Blockchain PSIG, which we co-chair. This is a symbiotic relationship in which we have been sharing updates and insights from IOTA as the Protocol has evolved from 1.0 through 1.5 to the present IOTA 2.0 Coordicide specifications. At each stage, we have updated the relevant OMG groups on these and other developments and gained valuable insights and feedback from them, such as how to apply existing OMG standards to our work. These conversations will start to bear more fruit as we introduce more IoT-specific features to the IOTA protocol.

Meanwhile, we have headed up most of the work in the Blockchain PSIG, where we have worked on:

Blockchain ecosystem interoperability RFI
IOTA Foundation response to the interoperability RFI
Potential RFPs for aspects of Interoperability coming out of the Interoperability RFI
Semantics for Smart Contracts
Self-sovereign identity — Disposable SSIDs RFI and future RFP
Linked Encrypted Transaction Streams (LETS) RFP
IOTA Streams practical demonstrations in mobility

In the past, we have also shared insights into the IOTA ‘EEE’ protocol and the Ternary specification, though these are not set to become OMG standards at this time.

At the OMG we have two things we are working on at the moment: the IOTA Protocol as an RFC, and a standard for IOTA Streams as a response to the LETS RFP.

“I’m proud and excited that the first DLT standardized will be IOTA and its Tangle architecture. This will make it much easier to achieve DLT interoperability for the user.”

— Richard Mark Soley, Ph.D., Object Management Group Chairman and CEO and IOTA Foundation Supervisory Board Chairman.

The IOTA Protocol defines what a piece of software needs in order to run it on the IOTA Tangle. This de facto standard already exists and anyone who refers to it may build a Tangle node.

In order to make it easier to refer to the IOTA Protocol specification, and so that the whole community can have confidence that they are referring to the most up to date version of the Protocol, we are submitting this to become a formal OMG standard.

The IOTA Protocol is following the OMG Request for Comments (RFC) process since it is a de facto standard specific to the Tangle.

The basis for the IOTA Protocol RFC will be the IOTA 2.0 Coordicide version, since this will be non backwardly compatible with the current IOTA 1.5 protocol that is implemented on the IOTA Mainnet.

A formal submission requires that a standard is in use somewhere in production, so this will be finalized after IOTA 2.0 is running on the IOTA Mainnet, but can be submitted as soon as we have a stable version, likely for the March OMG quarterly meeting. We will use the intervening time to get more feedback via the OMG, both from the technical experts and from a number of academic institutions that are OMG members. Part of the OMG way of working is that we share upcoming standards drafts early and often, to make the most of the expertise available to us.

The time that would normally elapse between submitting an initially proposed version of the specification, and this being approved as a formal international standard (‘Finalization’) can typically take around nine months and cannot be completed in less than six.

In discussions with the relevant OMG task force during the September meetings, we established that we could file the initial submission ahead of it being implemented on Mainnet, but only at the point where any changes between the submitted version and the later Final version would remain backwardly compatible. A formal communication that the IOTA Protocol is in deployment on Mainnet will need to be received by the OMG before the finalization by the OMG. This buys us some flexibility — we will file the initial submission as soon as we are fully confident that there will be no breaking changes, and have from then until final publication to complete deployment onto the Mainnet. This means that for example if the relevant tests at IOTA are completed by February, we could submit the initial draft as early as March 2021 and expect to complete the finalization process for the September or December quarterly meeting cycle.

Within the IOTA Foundation, the Formal specifications for Coordicide are in good shape and are in the process of being handed over to Engineering.

Between now and the initial submission of the RFC, we will be working at IOTA to take these specifications and refine them so as to separate the ‘What’ (Protocol) from the ‘How’ (Implementation specifications). This is part of the considerable work that is needed before IOTA 2.0 is ready to submit to the OMG. By the end of the next phase of development, the Protocol specification will be available to be submitted as an RFC proposal and will be under full formal change control as required for a standards submission.

For the next OMG quarterly meeting in December, we will present the current draft specifications from Research to get feedback from OMG. This will be submitted in 2021 via the OMG Middleware and Related Services (MARS) Platform Task Force, who will vote on this when it is formally submitted.

A future ‘Coordicide’ with support for more advanced Internet of Things functionality could be a further revision of the same standard if changes are backwardly compatible. If that version of the protocol represents breaking changes (which is a real possibility) then this will be submitted as a new RFC following the same process.

The OMG Blockchain Platform SIG has been working on a ‘Linked Encrypted Transaction Streams’ (LETS) RFP, based on the ideas set out in the IOTA Streams protocol. IOTA Streams is an open-source DLT framework for decentralized data streaming and encryption on embedded systems.

At the September OMG Quarterly Meeting, drafting continued on the LETS RFP. We discussed how submissions are expected to make use of the OMG’s Data Distribution Services (DDS) family of standards and finalized the wording in the RFP to reflect that.

The draft RFP was completed and submitted to the OMG in November and will be formally voted on at the December quarterly meeting. Assuming this is passed, the RFP will be formally issued by the OMG. Unless the dates are altered by the relevant OMG committees, this will have a response due date in February 2021, so that responses (the Streams-based proposed standard) may be reviewed at the March OMG Quarterly Meeting. The current progression from alpha through beta to the final status of the IOTA Streams protocol itself is expected to be completed within that same time frame.

Any suitable entity may respond to an RFP, as long as they are members of the OMG with the right level and type of membership. RFP responses are often submitted by consortia of member firms, and this is encouraged by the OMG.

The IOTA Streams specification is expected to form the basis for a formal response to the LETS RFP, using the ‘Framework’ part of that specification, which has been released in alpha. This IOTA proposal will be based on the OMG’s Data Distribution Services (DDS) family of standards and will make extensive reference to that. Similarly, the Streams Data Description and Modification Language (DDML), which forms part of this specification, would be expected to make use of the OMG Interface Definition Language (IDL) standard.

On the recommendation of people in the OMG community, we expect IOTA to work with one or more DDS vendor firms in the drafting and submission of the Streams Protocol as a response to the LETS RFP, to broaden our submission and improve take-up across a wider range of ecosystems. This activity can start now, and we will be reaching out to these DDS vendor firms during the current quarter.

We are also in discussions with a group in the Netherlands called SKALY, who have developed a protocol called Freighter that is also capable of being defined in terms of the ideas set out in the LETS RFP. We have updated the OMG LETS RFP document to include some of the specific features of Freighter and we anticipate having SKALY working alongside us in drafting the RFP response specification.

The submitted protocol needs to be independent of the Tangle in order to be a suitable response to the LETS RFP. This means that a LETS or Streams implementation can be built for other DLT environments as well as non-DLT deployments, for linked streams of messages. This also means that changes from IOTA 1.5 to IOTA 2.0 need to be transparent to the Streams protocol. This is made possible by IOTA’s layered architecture, where Streams represents a ‘Layer 2’ protocol that is already independent of any underlying transport arrangements.

There is a lot more to come. We participate in other DLT related initiatives such as self-sovereign identity (SSID). These activities take place at meetings of the Blockchain PSIG, which meets weekly and has a more formal meeting during the OMG Quarterly Meeting, typically on Wednesday. At the September OMG meeting, we had updates on the IOTA Protocol, held a drafting session for the LETS RFP, and worked on a new initiative in the area of self-sovereign identity, relating to disposable identities.

In the near future, the OMG Blockchain PSIG will also look at the recently-released IOTA Access work and determine whether there is potential for an RFP in that area, or as a deployment scenario for Disposable SSIDs.

Overall we will continue to work both within the IOTA Foundation and at the OMG to identify things that may benefit from standardization within the IOTA ecosystem, for example in Smart Contracts, Stronghold and other things as they come up. We will continue to work in both Research and Engineering to ensure that the IOTA Protocol proposed standard will work for the full range of possible usage scenarios, including through our work on supply chains, identity, mobility, Internet of Things and other uses of the IOTA distributed ledger technology stack that are yet to be thought of.

The OMG Blockchain PSIG has been exploring standards in the area of self-sovereign identity (SSID) and considering potential gaps in the standards space for these.

The PSIG is currently exploring the potential for a standard for ‘ephemeral’ or context-specific disposable SSIDs. This proposal was brought to the OMG by a group of researchers from the European Union. These would be context-specific identities using the W3C DID standard, that are disposed of as soon as the context they are created for no longer applies. Users can also choose different trusted third parties for different kinds of contexts.

In order to make sure there is a real need for a new standard for disposable SSIDs and to ensure that this would get used, the Blockchain PSIG is first following the ‘Request for Information’ (RFI) process. Assuming the RFI confirms such a need, the OMG would then issue an RFP.

The basis of the identity RFI is to get a good overall understanding of the landscape around cryptographically enabled identity solutions, including market needs for potential applications, coverage of any existing standards and alternative approaches to business problems including GDPR compliance.

Standards for SSID itself are well-established, for example, the W3C DID standard and the related Verifiable Credentials work.

The Blockchain PSIG worked on the draft RFI over the summer, reviewed it at the September quarterly meeting, and submitted a formal draft to the OMG in early November for discussion and formal voting at the December quarterly meeting, after which all being well this will be issued so that interested parties may respond to the questions it poses.

The IOTA Foundation will be responding to the Disposable SSIDs RFI as soon as this is issued by the OMG, just as we did for the earlier RFI on supply chain interoperability. We will also be reaching out to other partners that we are involved with such as the Trust over IP Foundation.

If the responses to the RFI indicate that there is potential for a Disposable SSID standard, the Blockchain PSIG would then draft an RFP for potential issuance through the MARS PTF, most likely in June 2021.

The Blockchain PSIG is also curating a wiki page for the information we learn from responses to that RFI.

For IOTA, this represents an opportunity to develop applications for this new kind of identity standard. IOTA has IOTA Identity, an implementation of the W3C DID standard. This RFI and any subsequent RFP gives IOTA the potential to shape the development of these standards going forward, working with other submitters and the relevant task force.

Through our involvement with the OMG, IOTA also has access to its sister organization, the Industrial Internet of Things Consortium (IIoT). The support for IoT-specific features is integral to the IOTA protocol.

We have also been looking at the home automation space, where we think there may be gaps in the existing standards. We will start to explore this, looking at the layers of the existing stack, what standards are in play for each layer (W3C / IETF, de facto protocol standards, and so on), and see where the gaps are. We would then reach out to whatever standards body is most suited to standardizing the relevant protocols. This is a further opportunity for IOTA to show leadership in the IoT space, supplementing our existing work in Industrial IoT, Smart Cities, and Mobility.

Going forward there are likely to be a number of other areas where we can contribute standards, including Access and Smart Contracts. We may start developing standard semantic representations (called ontologies) for business concepts referenced in Smart Contracts and applications while drawing on other specifications from the OMG in our standardization of things that are coming down the line.

Tangle EE is a working group collaboration with the Eclipse Foundation. It provides a governed environment for organizations and contributors to develop new ideas and applications using IOTA technologies. It brings together IOTA, OMG,Eclipseand a number of industry participants. There are a number of active TangleEE working groups looking at different areas and this is a good forum for helping people adopt and use the IOTA standards and specifications as well as for exploring new potential standardization opportunities. Exploration of the potential for an IOTA implementation of ephemeral (disposable) SSIDs is taking place within TangleEE.

Our vision for standards is that we have formal standards defined at the OMG (and other bodies as appropriate), while we publish software libraries via the Eclipse Foundation and publicize these to the wider community via TangleEE and elsewhere. People can use these libraries in the confidence that in doing so they are building in conformance with the latest standards in partnership with industry.

We will continue to develop IOTA standards internally, liaise with the OMG and other standards bodies, and pilot these through from IOTA de facto standards into internationally recognized standards as we launch IOTA 2.0. We look forward to sharing the progress with you over the coming months.

If you have any questions, you can find our team members on our Discord server. You are also welcome to follow us on our official channels:

Twitter: https://twitter.com/iotatoken

LinkedIn: https://linkedin.com/company/iotafoundation