[taler-docs] branch master updated: DD 38.

[gnunet]

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

ms pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 2ff6b62  DD 38.
2ff6b62 is described below

commit 2ff6b62b66024f9e43d7cbae5e8405b7b8ba8404
Author: ms <ms@taler.net>
AuthorDate: Tue Mar 21 17:46:38 2023 +0100

    DD 38.
    
    Framing the current implementation with the
    design described in the document.
---
 .../038-demobanks-protocol-suppliers.rst           | 62 +++++++++++++++++++++-
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/design-documents/038-demobanks-protocol-suppliers.rst 
b/design-documents/038-demobanks-protocol-suppliers.rst
index 3b62d53..f4523d2 100644
--- a/design-documents/038-demobanks-protocol-suppliers.rst
+++ b/design-documents/038-demobanks-protocol-suppliers.rst
@@ -85,10 +85,68 @@ doesn't respect this `mutual exclusivity 
<demobank-mutually-exclusive_>`_.
 
 3.  A XML-based protocol that lets user access their bank accounts
 always under the 'default' demobank belongs to this category.  It
-is a dynamic supplier with static demobank.  Note: this is the case
-of EBICS access offered in LibEuFin 0.9.2.
+is a dynamic supplier with static demobank.
 
 Supplier reachability
 =====================
 
 Each supplier must be available under its own URI.
+
+
+Current protocol suppliers design
+=================================
+
+Static X-LIBEUFIN-BANK with dynamic demobank
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``x-libeufin-bank`` protocol supplier is reachable under
+``/demobanks/{demobankName}/access-api/``.  As the path suggests,
+it offers banking operations via the :doc:`Access API </core/api-bank-access>`.
+It is static in the sense that it's not possible to assign a name
+to one particular x-libeufin-bank protocol supplier.  On the other
+hand, the demobank is dynamic because can be specified along the path
+in the ``demobankName`` placeholder.
+
+Dynamic EBICS supplier with dynamic demobank
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Every protocol supplier of this type is reachable under ``POST /ebicsweb``
+and by specifying its EBICS host name inside the EBICS message.
+
+As of the internal representation, Sandbox keeps a database table called
+``EbicsHostsTable`` that does **not** point at any demobank.  Such table
+is the one that provides the bank's EBICS private keys and has **no** business
+implications.
+
+CCT (Payment initiations)
+-------------------------
+
+This handler gets the bank account directly from the IBAN that was
+carried along the pain.001, therefore -- as long as every IBAN is
+unique -- this works with **any** demobank that hosts such IBAN.  The
+EBICS subscriber public keys are extracted differently: they come from
+the tuple [userID, partnerID, systemID?] held in the request.  Hence as
+long as such tuple is unique for each subscriber (Sandbox checks that),
+even the subscriber public keys are found regardless of the demobank name.
+
+.. note::
+
+   The 'context' object found via the [userID, partnerID, systemID?] tuple
+   has **also** a reference to the bank account.  The consistency with the
+   other bank account reference returned by the IBAN is currently NOT checked.
+
+C52 (transactions report)
+-------------------------
+
+This handler gets the reference to the subscriber public keys and bank
+account via the [userID, partnerID, systemID?] tuple.  It then uses
+this bank account label to find the transactions that belong to the
+subscriber that made the request.
+
+.. note::
+
+   The current implementation does NOT uses any demobank name along
+   the transactions research: only the bank account label.  This can
+   lead to **ambiguity**, in case two different demobanks host respectively
+   one bank account under the same label.  This is not possible however
+   in the current version, as Sandbox only admits one ``default`` demobank.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.