TIP proposal: signed generic payload

[sdellava]

Many data-generating applications can benefit from the IOTA network as a transport layer. The STREAM protocol/library is designed to fulfill this purpose, ensuring that the sender is identified and thus that messages containing false data cannot be created.

However, for many low-cost applications STREAM can be too expensive and complex while writing data into the generic payload of a Tange Message (TIP-6) is very simple.

The receiver, however, has only one element to distinguish a message containing data of interest to him from all others: the tag.

The tag is ignored by the network protocol, yet it is part of the L1 specification, i.e., the protocol itself.

Problem: anyone can publish a message with a tag, making it more complicated for the receiver to distinguis from valid and invalid messages.

To solve this problem I propose three alternative solutions:
(a) add to the format of the Tangle Message (TIP-6) an additional (optional) protocol-ignored field that can be used to contain a signature, using the contents of the tag as a private key.
b) extend the maximum size of the tag so, if required, it can contain a public key and an ED25529 signature of the generic paylod
(c) define a generic payload type (L2 message type) consisting of:

• payload
• public key
• signature

There are multiple use cases where being able to immediately verify that the payload of a message is valid is advantageous. The simplest is the implementation of a Selective Permanode Plug-in that instructed to store messages with a given TAG, can distinguish valid ones from malicious ones.

[lzpap]

Problem: anyone can publish a message with a tag, making it more complicated for the receiver to distinguis from valid and invalid messages.

Stardust provides a simple and elegant solution to this problem: data published in the Tangle via Metadata feature of an output of a transaction can be authenticated via the Sender feature.

What this means in practice, is that a data-generating application can publish data to an application defined targetAddresss authenticated via senderAddress and optionally tagged via a Tag feature.
Consumers of the data may query the indexer API (defined in TIP-26) with the following query parameters:

• adress=targetAddress,
• sender=senderAddress,
• tag=appSpecificTag

to obtain the output object(s) holding the actual data. The protocol ensures that such data was indeed published by whoever holds the keys to senderAddress.

[sdellava]

Can the transaction be at zero value?

If yes, I think the solution is appropriate. If no obviously the solution is only suitable for applications where the sender can move tokens and in that case selective permanode is not necessary.

[lzpap]

A transaction can not be of zero value. Storing data in the ledger must be covered with a storage deposit.
If you are looking for pure data blocks without tokens, the best way IMO is:

1. Define your own data structure (binary serialized, JSON, or whatever) that can hold public keys, signatures and data.
2. Publish blocks with Tagged Data Payloads. Obviously, put your custom data structure inside the data field of such a payload.
3. Implement an INX module that filters such payloads based on the Tag, parses the content of the inner data field and performs the signature checks.
4. Your INX module then can expose filtered, authenticated and processed data via API to consumers.

[sdellava]

Exactly. What I am suggesting is to make this method a standard.

[lzpap]

Feel free to propose such an application level standard in the form of a TIP 👍