[GNUnet-SVN] [taler-docs] branch master updated: summarize ebics transactions

[gnunet]

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new b19e355  summarize ebics transactions
b19e355 is described below

commit b19e35583e7d1c88a92a3851c3276e4aee22cb55
Author: Florian Dold <address@hidden>
AuthorDate: Fri Sep 27 01:50:42 2019 +0200

    summarize ebics transactions
---
 libeufin/ebics.rst | 41 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/libeufin/ebics.rst b/libeufin/ebics.rst
index 862cec2..6e1990f 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
 =======

-- 
To stop receiving notification emails like this one, please contact
address@hidden.