[taler-docs] branch master updated (3f86f293 -> 47a86dfc)

[gnunet]

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

grothoff pushed a change to branch master
in repository docs.

    from 3f86f293 also make diagrams for latex
     new ced82b39 start docs for #7793
     new 47a86dfc document /login API for merchant

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 core/api-libeufin-bank.rst |  2 +-
 core/api-merchant.rst      | 65 ++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/core/api-libeufin-bank.rst b/core/api-libeufin-bank.rst
index ad6bb1b0..f7b1a7e9 100644
--- a/core/api-libeufin-bank.rst
+++ b/core/api-libeufin-bank.rst
@@ -73,7 +73,7 @@ client to authenticate as the admin.
 
    **Parameters**
 
-   .. ts:def:: LoginRquest
+   .. ts:def:: LoginRequest
 
      interface LoginRequest {
        scope: "readonly" | "write";
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index dbda8e61..bec280a1 100644
--- a/core/api-merchant.rst
+++ b/core/api-merchant.rst
@@ -99,12 +99,17 @@ Authentication
 Each merchant instance has separate authentication settings for the private 
API resources
 of that instance.
 
-Currently, the API supports two auth methods:
+Currently, the API supports two main authentication methods:
 
 * ``external``:  With this method, no checks are done by the merchant backend.
   Instead, a reverse proxy / API gateway must do all 
authentication/authorization checks.
 * ``token``: With this method, the client must provide a ``Authorization: 
Bearer $TOKEN``
-  header, where ``$TOKEN`` is a secret authentication token configured for the 
instance.
+  header, where ``$TOKEN`` is a secret authentication token configured for the 
instance which must begin with the RFC 8959 prefix.
+
+Additionally, clients can send a **login token** which they may obtain from
+the ``/private/login`` endpoint.  Such a login token is valid only for a
+limited period of time and can be used by clients to avoid storing the
+long-term login secrets from an authentication method.
 
 -----------------
 Configuration API
@@ -1004,6 +1009,62 @@ Setting up instances
 
     }
 
+.. http:post:: [/instances/$INSTANCE]/private/login
+
+   **Request:**
+
+   The request must be a `LoginRequest`.
+
+   **Response:**
+
+  :http:statuscode:`200 Ok`:
+    The backend is returning the access token in a
+    `LoginSuccessResponse`.
+
+   **Details:**
+
+   .. note::
+
+     Typically the ``access_token`` would be an EdDSA signature
+     over (username, scope, timestamp, expiry).
+
+     Alternatively, valid access tokens could also be random identifiers
+     stored in a database table.
+
+   .. ts:def:: LoginRequest
+
+     interface LoginRequest {
+       // Scope of the token (which kinds of operations it will allow)
+       scope: "readonly" | "write";
+
+       // Server may impose its own upper bound
+       // on the token validity duration
+       duration?: RelativeTime;
+
+       // Can this token be refreshed?
+       // Defaults to false.
+       refreshable?: boolean;
+     }
+
+   .. ts:def:: LoginSuccessResponse
+
+     interface LoginSuccessResponse {
+       // The bearer token that can be used to access resources
+       // that are in scope for some time.
+       access_token: string;
+
+       // Scope of the token (which kinds of operations it will allow)
+       scope: "readonly" | "write";
+
+       // Server may impose its own upper bound
+       // on the token validity duration
+       expiration: Timestamp;
+
+       // Can this token be refreshed?
+       refreshable: boolean;
+     }
+
+
 .. http:patch:: /management/instances/$INSTANCE
 .. http:patch:: [/instances/$INSTANCE]/private
 

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