[taler-docs] branch master updated (d88de457 -> eb28baea)

[gnunet]

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

sebasjm pushed a change to branch master
in repository docs.

    from d88de457 update DD23
     new 8b6aba5d update see #8728
     new eb28baea change in challenger spec

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-challenger.rst            | 75 +++++++++++++++++++++++++++++++-------
 design-documents/053-wallet-ui.rst | 23 ------------
 2 files changed, 61 insertions(+), 37 deletions(-)

diff --git a/core/api-challenger.rst b/core/api-challenger.rst
index 759d4e70..e95434ef 100644
--- a/core/api-challenger.rst
+++ b/core/api-challenger.rst
@@ -120,6 +120,19 @@ Receiving Configuration
       // @since v0, may become mandatory in the future.
       implementation?: string;
 
+      // @since v2.
+      // Object; map of keys (names of the fields of the address
+      // to be entered by the user) to objects with a "regex" (string)
+      // containing an extended Posix regular expression for allowed
+      // address field values, and a "hint"/"hint_i18n" giving a
+      // human-readable explanation to display if the value entered
+      // by the user does not match the regex. Keys that are not mapped
+      // to such an object have no restriction on the value provided by
+      // the user.  See "ADDRESS_RESTRICTIONS" in the challenger configuration.
+      restrictions: Object;
+
+      // @since v2.
+      address_type: "email" | "phone";
     }
 
 .. _challenger-setup:
@@ -216,15 +229,8 @@ Login
   .. ts:def:: ChallengeStatus
 
     interface ChallengeStatus {
-      // Object; map of keys (names of the fields of the address
-      // to be entered by the user) to objects with a "regex" (string)
-      // containing an extended Posix regular expression for allowed
-      // address field values, and a "hint"/"hint_i18n" giving a
-      // human-readable explanation to display if the value entered
-      // by the user does not match the regex. Keys that are not mapped
-      // to such an object have no restriction on the value provided by
-      // the user.  See "ADDRESS_RESTRICTIONS" in the challenger configuration.
-      restrictions: Object;
+      // @deprecated since v2, use /config
+      restrictions?: Object;
 
       // indicates if the given address cannot be changed anymore, the
       // form should be read-only if set to true.
@@ -232,11 +238,29 @@ Login
 
       // form values from the previous submission if available, details depend
       // on the ``ADDRESS_TYPE``, should be used to pre-populate the form
-      last_address: Object;
+      last_address?: Object;
 
       // number of times the address can still be changed, may or may not be
       // shown to the user
       changes_left: Integer;
+
+      // when we would re-transmit the challenge the next
+      // time (at the earliest) if requested by the user
+      // only present if challenge already created
+      // @since v2
+      retransmission_time: Timestamp;
+
+      // how many times might the PIN still be retransmitted
+
+      // how many times might the PIN still be retransmitted
+      // only present if challenge already created
+      // @since v2
+      pin_transmissions_left?: Integer;
+
+      // how many times might the user still try entering the PIN code
+      // only present if challenge already created
+      // @since v2
+      auth_attempts_left?: Integer;
     }
 
 
@@ -259,10 +283,17 @@ Challenge
   **Response:**
 
   :http:statuscode:`200 OK`:
-    If the request ask for application/json the response is 
`ChallengeCreateResponse`. Since protocol **v1**.
+    If the request ask for application/json the response is 
`ChallengeResponse`. Since protocol **v2**.
     Otherwise, the body contains a form asking for the answer to
     the challenge to be entered by the user using the
     template :ref:`enter-tan-form <challenger_enter-tan-form>`.
+  :http:statuscode:`302 Found`:
+    Only possible if request didn't ask for application/json. Since protocol 
**v2**.
+    The user is redirected to the redirect URI of the client to pass the
+    grant to the client.  The target will be the redirect URI specified
+    by the client (during registration and again upon ``/authorize``),
+    plus a ``code`` argument with the authorization code, and the
+    ``state`` argument from the ``/authorize`` endpoint.
   :http:statuscode:`400 Bad Request`:
     The request does not follow the spec.
     If the request ask for application/json the response will include error
@@ -289,6 +320,14 @@ Challenge
 
   .. ts:def:: ChallengeCreateResponse
 
+    interface ChallengeResponse = ChallengeRedirect | ChallengeCreateResponse
+
+    // @since v2
+    interface ChallengeRedirect {
+      // challenge is completed, use should redirect here
+      redirect_url: string;
+    }
+
     interface ChallengeCreateResponse {
 
       // how many more attempts are allowed, might be shown to the user,
@@ -304,10 +343,13 @@ Challenge
       // might make a useful hint to the user
       transmitted: boolean;
 
-      // timestamp explaining when we would re-transmit the challenge the next
-      // time (at the earliest) if requested by the user
-      next_tx_time: string;
+      // @deprecated in v2, use retransmission_time
+      next_tx_time?: string;
 
+      // when we would re-transmit the challenge the next
+      // time (at the earliest) if requested by the user
+      // @since v2
+      retransmission_time: Timestamp;
     }
 
 
@@ -330,7 +372,10 @@ Solve
 
   **Response:**
 
+  :http:statuscode:`200 OK`:
+    If the request ask for application/json the response is 
`ChallengeSolveResponse`. Since protocol **v2**.
   :http:statuscode:`302 Found`:
+    Only possible if request didn't ask for application/json. Since protocol 
**v2**.
     The user is redirected to the redirect URI of the client to pass the
     grant to the client.  The target will be the redirect URI specified
     by the client (during registration and again upon ``/authorize``),
@@ -362,6 +407,8 @@ Solve
 
   .. ts:def:: InvalidPinResponse
 
+    type ChallengeSolveResponse = ChallengerRedirect | InvalidPinResponse;
+
     interface InvalidPinResponse {
       // numeric Taler error code, should be shown to indicate the error
       // compactly for reporting to developers
diff --git a/design-documents/053-wallet-ui.rst 
b/design-documents/053-wallet-ui.rst
index 7b5fdf73..57f9b1f2 100644
--- a/design-documents/053-wallet-ui.rst
+++ b/design-documents/053-wallet-ui.rst
@@ -282,16 +282,8 @@ Issues
 
 * WebEx (text): Iconography (T), (W) is not as
   nice as iconography in on Android.
-* WebEx (text): The balance is not labeled as the balance.
-* WebEx (text): Button is labeled as "Add",
-  while above says to use "Receive" which is
-  a better dual with "Send".
 * WebEx (image): Screenshot does not show any
   pending transactions.
-* WebEx (nit): Android has different order of
-  items on top (send+receive, then balance).
-  This places the balance on top of the other
-  amounts, which is nicer.
 * Android (text): Iconography (same icon for push
   payments and debit and POS) and again same icon
   for invoice and withdraw) is sub-optimal. Should
@@ -324,13 +316,8 @@ Issues
   exchange URL for withdraw
 * iOS (major): The balance is not shown. The
   "send" and "receive" buttons are missing.
-* WebEx (minor): lacks search button (see Android)
 * iOS (minor): has top/buttom scroll buttons not present
   in other UIs (likely too much, better to have search!)
-* WebEx (minor): unclear how to do bulk-deletion;
-  other platforms make it easy to select multiple
-  rows. Maybe have some checkboxes and then a
-  "delete selected" button at the bottom?
 * iOS (critical): the buttons to send/receive funds
   are not even shown in the screenshot, likely because
   of balances vs. banking distinction, which should
@@ -596,11 +583,6 @@ Actions
 Issues
 ^^^^^^
 
-* WebEx(text): wire transfer subject is last, should be first!
-* WebEx(text): Receiver name is not shown (except within payto URI); must be 
shown above IBAN!
-  and only a link shown (see iOS)
-* WebEx(text): PaytoURI should not be expanded on-screen
-  and only a link shown (see iOS)
 * All(text): if there is no fee, no point in showing
   the amount **3** times. Maybe only show the amount
   on top with the wire transfer details, and then at
@@ -729,7 +711,6 @@ Actions
 Issues
 ^^^^^^
 
-* WebEx(text) has additional actions "clear" (not necessary, I can manually 
clear), "Read QR from file" (who does that!???!) that should be removed.
 * Android(text) has button label "OK", should probably be "Open" for 
uniformity.
 * Android(text) has "Enter Taler URI", while WebEx has clearer text "enter 
taler:// URI".
 * iOS (screenshot): lacks dialog (or screenshot?) entirely, not sure if we 
need manual URL-entry on mobile though, so could be OK!
@@ -782,9 +763,7 @@ Actions
 Issues
 ^^^^^^
 
-* WebEx(Text): showing price/total without fees is a bit excessive, could be 
simplified in absence of fees
 * WebEx(Text): "Valid until" is likely confusing, not shown on other 
platforms. Maybe only show "offer expired" instead of pay button (on all 
platforms!)?
-* WebEx(Text): Receipt number is not shown on other platforms at this time, 
which also makes sense as it is only an order number and certainly nothing like 
a receipt before payment! (Remove!)
 * WebEx(Screenshot): would be good to show the dialog with expanded order 
details as well, maybe even expand by default like on Android (and forgo the 
button?)
 * WebEx(Screenshot): would be good to show a version of the dialog with fees 
in the screenshot.
 * iOS(text): the label 'Summary' appears only on iOS, and seems unnecessary. 
Especially since no long-form is available anywhere.
@@ -846,7 +825,6 @@ Actions
 Issues
 ^^^^^^
 
-* WebEx(text): Details should be simplified if there are no fees
 * Android(text): details say receipt, but WebEx uses the slightly more 
accurate "Invoice ID". Could also use "Order #"?
 * iOS(major): delete button is missing, instead only has "Done"
 
@@ -969,7 +947,6 @@ Actions
 Issues
 ^^^^^^
 
-* WebEx(text): 20 days is odd, Android has 30 days instead
 * Android(text): Webex uses "1 Week" instead of "7 days", let's use "week".
 * iOS(text): 3 min/ 1h are inconsistent; other wallets have 1 day, 7 days, 30 
days. We should be consistent.
 

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