add discussion about need for another transition

1 files changed, 19 insertions, 4 deletions

diff --git a/doc/sphinx/reducer.rst b/doc/sphinx/reducer.rst
index cc696a9..5a92d9d 100644
--- a/doc/sphinx/reducer.rst
+++ b/doc/sphinx/reducer.rst
@@ -1369,14 +1369,12 @@ choose which challenges to satisfy:
           {
             "uuid": "MW2R3RCBZPHNC78AW8AKWRCHF9KV3Y82EN62T831ZP54S3K5599G",
             "uuid-display": "MW2R3RC",
-            "cost": "TESTKUDOS:0",
             "type": "question",
             "instructions": "q1"
           },
           {
             "uuid": "TXYKGE1SJZHJ4M2FKSV1P2RZVNTHZFB9E3A79QE956D3SCAWXPK0",
             "uuid-display": "TXYKGE",
-            "cost": "TESTKUDOS:0",
             "type": "email",
             "instructions": "e-mail address m?il@f*.bar"
           },
@@ -1415,8 +1413,6 @@ four mandatory fields:
       send to the user.  Allows the user to
       distinguish different PIN/TANs should say the same phone number be
       used for SMS-authentication with different providers.
-    - **cost**: This is the amount the Anastasis provider will charge
-      to allow the user to pass the challenge.
     - **type**: This is the type of the challenge, as a string.
     - **instructions**: Contains additional important hints for the user
       to allow the user to satisfy the challenge.  It typically includes
@@ -1447,6 +1443,25 @@ However, in general it should be sufficient to display the slightly
 more generic Taler error code that is returned with the new state.
 
 
+**FIXME: add new transition: sync_providers**
+
+The downloaded policy may include secrets from providers for which
+we do not (yet) have the cost structure or even the salt. So here
+a client/UI should have _again_ the opportunity to explicitly request
+providers to be downloaded to fill in missing cost(s) and salts.
+
+As providers may fail to respond, this action may need to be called
+repeatedly ("sync" button in the UI?).  Once all providers are in
+'sync', that button should be hidden/obscured.  Alternatively, we
+may want to enable long-polling on this one => no button!
+
+Furthermore, we likely need an additional *error* case in case a
+challenge is selected for which the provider details are unknown
+(invalid input!), and the UI should somehow disable buttons for
+challenges for which the provider details are unknown.
+
+
+
 **select_challenge:**
 
 Selecting a challenge takes different, depending on the state of the payment.