summaryrefslogtreecommitdiff
path: root/libeufin
diff options
context:
space:
mode:
authorFlorian Dold <florian.dold@gmail.com>2019-09-27 01:50:42 +0200
committerFlorian Dold <florian.dold@gmail.com>2019-09-27 01:50:42 +0200
commitb19e35583e7d1c88a92a3851c3276e4aee22cb55 (patch)
tree5f6f8f6deb23074654024bd1195755292e78c389 /libeufin
parentda1bab8545f54e3866263323d3dc9f67867e8f8c (diff)
downloaddocs-b19e35583e7d1c88a92a3851c3276e4aee22cb55.tar.gz
docs-b19e35583e7d1c88a92a3851c3276e4aee22cb55.tar.bz2
docs-b19e35583e7d1c88a92a3851c3276e4aee22cb55.zip
summarize ebics transactions
Diffstat (limited to 'libeufin')
-rw-r--r--libeufin/ebics.rst41
1 files changed, 37 insertions, 4 deletions
diff --git a/libeufin/ebics.rst b/libeufin/ebics.rst
index 862cec24..6e1990f6 100644
--- a/libeufin/ebics.rst
+++ b/libeufin/ebics.rst
@@ -17,13 +17,13 @@ EBICS Glossary
:sorted:
A004
- Electronic signature process, used in H004, deprecated in H005 with EBICS 3.0.
+ Electronic signature process, used in :term:`H004`, deprecated in :term:`H005` with EBICS 3.0.
A005
- Electronic signature process. Used in H004 and H005.
+ Electronic signature process. Used in :term:`H004` and :term:`H005`.
A006
- Electronic signature process. Used in H004 and H005.
+ Electronic signature process. Used in :term:`H004` and :term:`H005`.
BTF
*Business Transaction Formats.* Before EBICS 3.0, many different order types were
@@ -82,7 +82,7 @@ EBICS Glossary
Each upload transaction gets a unique order number assigned by the bank server.
The Order Number is used to match VEUs in a second upload to the original order.
- An Order Number matches the format "[A-Z][A-Z0-9]{3}" (and is not really a number!).
+ An Order Number matches the format ``[A-Z][A-Z0-9]{3}`` (and is not really a number!).
Must be unique per customer ID and per order type
@@ -319,6 +319,39 @@ The following order types are, for now, not relevant for LibEuFin:
HAC order type.
+EBICS Transaction
+=================
+
+A transaction in EBICS simply refers to the process of uploading or downloading
+a file. Whether it is an upload or download transaction depends on the order
+type. Each transaction is either an upload transaction or a download
+transaction, neither both.
+
+Uploads and downloads must proceed in segments of at most ``1 MB``. The
+segmentation happens after (1) encryption (2) zipping and (3) base64-encoding
+of the order data.
+
+The number of segments is always fixed starting from the first message sent
+(for uploads) or received (for downloads) by the subscriber. The digest of the
+whole message is also sent/received with the first message of a transaction.
+The EBICS host generates a 128-bit transaction ID. This ID is used to
+correlate uploads/downloads of segments for the same transaction.
+
+If an attacker would be able to guess the transaction ID, they could upload a
+bogus segment. This would only be detected after the whole file has been
+transmitted.
+
+An upload transaction is finished when the subscriber has sent the last
+segment. A download transaction is only finished when the subscriber has sent
+an additional acknowledgement message to the EBICS host.
+
+When upload/download of a segment fails, the client can always re-try. There
+are some conditions for that:
+
+* Segment ``n`` can only be downloaded/uploaded when segments ``[0..n-1]`` have
+ been downloaded/uploaded.
+* The (implementation-defined) retry counter may not be exceeded.
+
Formats
=======