diff options
| -rw-r--r-- | design-documents/038-demobanks-protocol-suppliers.rst | 62 |
1 files changed, 60 insertions, 2 deletions
diff --git a/design-documents/038-demobanks-protocol-suppliers.rst b/design-documents/038-demobanks-protocol-suppliers.rst index 3b62d536..f4523d28 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. |