DTRANS Standard

Mit DTRANS steht ein neuer webnativer, offener und freier Übertragungsweg für Geschäftsdaten bereit. DTRANS macht die vollautomatisierte Übertragung zu beliebig vielen Empfängern möglich und bietet einen sicheren Weg für eine Empfangsbestätigung. DTRANS verwendet bewährte Internetstandards: DNS SRV Einträge zum Entdecken (neudeutsch Discovery) bzw. Aushandeln des Kommunikationskanals und Formats und dann HTTPS + .well-known URLs zum Übertragen der Dokumente. Eine aufwändige und zeitintensive Einrichtung zwischen den Geschäftspartnern ist nicht erforderlich. Für den automatischen Erhalt des 1Lieferschein müssen lediglich via DTRANS die entsprechenden DNS-Einträge gesetzt werden und der Webserver entsprechend konfiguriert sein. Die Einstiegshürde gerade für DTRANS und damit auch 1Lieferschein ist somit sehr gering.

Abstract

There are various standards that define standard business documents, most notably UBL and UN/CEFACT, plus lots of derivative work, e.g. X-Rechnung, Order-X, ZuGFERD or 1Lieferschein and competing ones like openTRANS. Those standards define the structure and format of the documents, however they either do not define a standard way to exchange the documents between parties or lack a discovery process to find out which standard to use. This RFC closes this gap by providing a standard way of discovery and transmission of standard business documents that requires zero configuration for the sending and receiving parties.

Introduction

In order to submit transactional data from the sender to the receiver, the sending party will need to know from the receiver:

1. Which data format to use to encode the data
2. Which mechanism of transport to use
3. And how to use it the transport mechanism

This document specifies 1.) & 2.) for most established business documents, using DNS SRV and defines a transport standard for 3.) using .well-known URI.  First, the sender will discover a receiving server using a defined DNS lookup, then connect via https to the receiving server, reaching out to a .well-known URI. The sender sends the document via the transmission standard that is also specified in the DNS SRV record.

Notational Conventions

The key words „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, “SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „NOT RECOMMENDED“, „MAY“, and „OPTIONAL“ in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Discovery

The sender uses the DNS SRV record discovery approach of RFC2782 to discover the target server responsible for the recipient’s domain. Determining the domain name of the recipient is out of scope of this RFC, typically this can be derived from existing email addresses. The new SRV records defined are listed in table 1 in section Supported Document Types. As both a sender and a receiver might support multiple, alternative document formats and transmission schemes, this lookup process can be used as a way to negotiate the used protocol, with the sender making the final choice and the receiver giving priorities. Example record for format UBL, specifying domain erp.example.com as receiving server:  _dtrans_https_ubl._tcp SRV 0 0 443 erp.example.com.

Record Format

The DNS Records follow the format _dtrans_TRANSID_FORMATID with TRANSID listed in the Supported Transaction Standards table 2 and FORMATID listed in the Supported Document Types table 1. The rest of the record is per RFC2782.

Transmission Standards

There are multiple standard ways to transmit documents to a target system. DTRANS specifies its own below, others can be standardized in other RFCs or by general agreement of the participating parties. See following table:

Table 1: Defined Transmission Standards It is up to the Transmission Standard to define how to submit a document. The sender of the document can select from the available transmission and document formats which one to use. It SHOULD respect the servers priorities.

DTRANS Document Transmission

Once the destination server has been discovered, the sender will connect to it using standard HTTPS mechanism, accessing the defined URL dtrans in the .well-known name space according to RFC 8615, adding the FORMATID as parameter format: https://servername/.well-known/dtrans?format=FORMATID For the example receiving server erp.example.com in format UBL, that results in the following URI: https://erp.example.com/.well-known/dtrans?format=ubl The client then uses HTTP POST to transmit the xml document in the request body. The server replies using a standard HTTP return code.  For document standards that specify multiple document types, e.g. UBL and UN/CEFACT, the server should reply with http 501 Not Implemented when the submitted document type is not supported.

Test Transmission

In order to validate a connection, the client may append URL parameter test=true to the URL. The server MUST IGNORE the document for operational purpose but SHOULD try to validate the document against internal rules as much as possible. This results in sample URLs like https://servername/.well-known/dtrans?format=FORMATID&test=true

Cryptographic proof of delivery

In case of a successful transmission (HTTP Code 200), the server also returns a cryptographic acknowledgment of receipt inspired by DKIM [RFC 6376] signature as such: Using any currently valid DKIM signature algorithm, and retrieving the valid keys using the selector dtrans as per DKIM, the server will generate a signature over: T=,S=,M= Adding the fields t, v, a, b, q, s, as per RFC 6376 in the signature. Other fields are not supported, specifically no canonicalization will take place. The signature always covers the whole document. The timestamp in the signed part has the same format and value as the t value of the signature. It is also signed, as having a proof of the time of reception might be crucial for some document types. The client SHOULD validate that value against it’s own clock to be sure that the receipt is useful. <

Key Retrieval

Using DKIM, with:

• Selector “dtrans”, or any DNS style subspace of that, in case larger organizations choose to use multiple keys. See RFC 6376 section 3.1 for details. Given a signature field with a „d=“ tag of example.com, the DNS query will be for „dtrans._domainkey.example.com“, or any subspace thereof, e.g.

„erp.dtrans._domainkey.example.com“

• Service type “dtrans” in the key data as per RFC 6376 section 3.6.1

Supported Document Standards

The following document specifications can be supported by this standard. Others are to be added later by updating this RFC.

Table 1: Defined Document Standards

Contributions

Acknowledgments

Internationalization Considerations

References

Security Considerations „

The use of unauthenticated transmission is desired, as this is a prerequisite to allow zero configuration on the sending side. Server operators MUST take care of potential attack vectors, similar to e-mail, i.e. DOS, spam etc. The UBL standard supports inline signatures, which verify the authenticity of the server. E-Mail doesn’t support proof of delivery for a historic reason: When E-Mail was invented it was common practice that the receiving party’s computer is offline, and only the email infrastructure was up and running, but very likely a system not under control of the receiving party. As such, delays and multi hop connections were the common case. With DTRANS we expect this not to be the common case, and albeit multi hop is technically possible the receiving server is supposed to be under (contractual) control of the receiving legal entity. This allows it to sign the reception. The server MUST make sure not to reveal business secrets when validating test transactions.

IANA Considerations

_dtrans needs to get registration via https://datatracker.ietf.org/doc/html/rfc8552  dtrans needs to get gestiration via https://datatracker.ietf.org/doc/html/rfc8615