draft-grothoff-taler.xml (26479B)
1 <?xml version="1.0" encoding="US-ASCII"?> 2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 3 <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 4 <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"> 5 <!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml"> 6 <!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> 7 <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 8 ]> 9 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 10 <!-- SEE ALSO: https://docs.taler.net/core/taler-uri.html --> 11 <?rfc strict="yes" ?> 12 <?rfc toc="yes" ?> 13 <?rfc symrefs="yes"?> 14 <?rfc sortrefs="yes" ?> 15 <?rfc compact="yes" ?> 16 <?rfc subcompact="no" ?> 17 18 <rfc category="info" 19 docName="draft-grothoff-taler-01" 20 ipr="trust200902"> 21 22 <front> 23 <title abbrev="The 'taler' URI scheme"> 24 The 'taler' URI scheme for GNU Taler Wallet interactions 25 </title> 26 27 <author fullname="Christian Grothoff" initials="C.G." surname="Grothoff"> 28 <organization>BFH</organization> 29 <address> 30 <postal> 31 <street>Höheweg 80</street> 32 <street></street> 33 <city>Biel/Bienne</city> 34 <code>CH-2501</code> 35 <country>CH</country> 36 </postal> 37 <email>christian.grothoff@bfh.ch</email> 38 </address> 39 </author> 40 41 <author fullname="Florian Dold" initials="F.D." surname="Dold"> 42 <organization>Taler Systems SA</organization> 43 <address> 44 <postal> 45 <street>7, rue de Mondorf</street> 46 <city>Erpeldange</city> 47 <code>L-5421</code> 48 <country>LU</country> 49 </postal> 50 <email>dold@taler.net</email> 51 </address> 52 </author> 53 54 <date day="07" month="January" year="2024" /> 55 56 <!-- Meta-data Declarations --> 57 <area>General</area> 58 <workgroup>Independent Stream</workgroup> 59 <keyword>payments</keyword> 60 61 <abstract> 62 63 <t> 64 This document defines the 'taler' Uniform Resource Identifier (URI) scheme 65 for triggering interactions with a GNU Taler wallet. 66 </t> 67 68 <t> 69 This URI scheme allows applications to trigger interactions with the GNU Taler wallet, 70 such as withdrawing money, making payments, receiving refunds and restoring a wallet 71 from a backup. Applications may receive such URIs in many ways (including via NFC, 72 QR codes, Web links or messaging applications), or might generate them internally to 73 interact with a wallet. By having a Taler wallet handle the respective URIs, 74 applications can integrate Taler payments without having to support the Taler protocol 75 directly. Furthermore, by passing control to a Taler wallet process, the wallet's 76 database with its financial data might be better protected from application failures. 77 </t> 78 79 </abstract> 80 81 </front> 82 83 <middle> 84 85 <section anchor="introduction" title="Introduction"> 86 <t> 87 This document defines the 'taler' Uniform Resource Identifier (URI) <xref target="RFC3986" /> scheme 88 for triggering interactions with GNU Taler wallets. 89 </t> 90 91 <section title="Objective"> 92 <t> 93 A 'taler' URI always instructs a GNU Taler wallet to perform a particular operation. 94 A 'taler' URI consists of an action and optional parameters. 95 </t> 96 <t> 97 The interpretation of the optional parameters depends on the action. 98 </t> 99 </section> 100 <section title="Requirements Language"> 101 <t> 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 14 105 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, 106 they appear in all capitals, as shown here. 107 </t> 108 </section> 109 110 </section> 111 112 <section anchor="syntax" 113 title="Syntax of a 'taler' URI"> 114 <t> 115 This document uses the Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/>. 116 </t> 117 <figure> 118 <artwork type="abnf"><![CDATA[ 119 taler-URI = ("taler://" / "TALER://" / "taler+http://" / "TALER+HTTP://" ) 120 action path-abempty [ "?" query ] 121 action = ALPHA *( ALPHA / DIGIT / "-" / "." ) 122 ]]> 123 </artwork> 124 </figure> 125 <t> 126 'path-abempty' is defined in <xref target="RFC3986" /> in Section 3.3. 127 'query' is defined in <xref target="RFC3986" />, in Section 3.4. 128 </t> 129 </section> 130 131 <section anchor="semantics" title="Semantics"> 132 <t> 133 The action of a Taler URI identifies the operation requested from the Taler 134 wallet. Actions are not case-sensitive. The actions are defined in the "Taler 135 URI Actions" sub-registry, see <xref target="taler-registry" />. 136 137 The path component of the URI typically provides a network address needed to 138 locate additional information or services relevant to the requested operation. 139 Paths are case-sensitive, but may contain case-insensitive portions, such 140 as domain names. 141 142 The query component of the URI provides immediate additional parameters or 143 options for the operation. The query is case-sensitive. 144 145 The default operation of applications that invoke a URI with the taler 146 scheme MUST be to launch a Taler wallet (if available). If no taler URI 147 handler is available, an application SHOULD show a QR code with the contents 148 of the URI. If multiple Taler wallets are registered, the user SHOULD be 149 able to choose which application to launch. This allows users with multiple 150 wallets (each possibly with its own money) to choose which wallet to perform 151 the operation with. 152 153 An application SHOULD allow dereferencing a "taler://" URI even 154 if the action of that URI is not registered in the "Taler URI Actions" sub-registry. 155 156 Wallets seeing a "taler://" URI MUST use HTTP over TLS when talking 157 to the respective network service. 158 Wallets seeing a "taler+http://" URI MUST use HTTP without TLS when talking 159 to the respective network service. Wallets SHOULD support 160 "taler+http://"-URIs only when run in developer or debug mode. 161 162 </t> 163 </section> 164 165 <section anchor="examples" title="Examples"> 166 <figure> 167 <artwork><![CDATA[ 168 taler://pay/example.com/2022.268-03G33PTAY2C6T/\ 169 00f68430-363a-46b7-8e33-241a0e49c430?c=KKBWMSTF4AZSP8XS0FFNE9KM5M 170 taler://pay-push/bank.example.com/\ 171 3BBW6N8PVDYBRT0DERT8YYARQGFYHVQFG3WVAN1D58FRP5JG3M4G 172 TALER://PAY-PULL/BANK.EXAMPLE.COM/\ 173 WB361HXN7BZ9ND1B9YP1Y20NB4H5WS0RNM4K8AFZ5Q2VRW577BPG 174 ]]> 175 </artwork> 176 </figure> 177 178 </section> 179 180 <section anchor="tracking" title="Tracking Taler URI Actions"> 181 <t> 182 A registry of Taler URI Actions is described in <xref target="taler-registry" />. 183 184 The registration policy for this registry is "Expert Review", 185 as described in <xref target="RFC8126" />. 186 When requesting new entries, careful consideration of the following criteria is strongly advised: 187 <list style="numbers"> 188 <t>The description clearly defines the semantics of the action and optional parameters if applicable.</t> 189 <t>The name states the unique name for the action that must be part of the URI.</t> 190 <t>The syntax defines the format of the action-specific part of the URI.</t> 191 <t>Relevant references are provided if they are available.</t> 192 <t>The chosen name is appropriate for the operation, and avoids potential to confuse users.</t> 193 <t>A libre software reference implementation is available.</t> 194 </list> 195 </t> 196 <t> 197 Documents that support requests for new registry entries should 198 provide the following information for each entry: 199 <list style="symbols"> 200 <t>Description: A description of the action, including 201 the semantics of the path in the URI if applicable.</t> 202 <t>Name: The name of the Taler URI action (case insensitive ASCII string, restricted to alphanumeric characters, 203 dots and dashes)</t> 204 <t>Syntax: summary of the syntax of the URI as a one-liner.</t> 205 <t>Example: At least one example URI to illustrate the action.</t> 206 <t>Contact: The contact information of a person to contact for further information</t> 207 <t>References: Optionally, references describing the action (such as an RFC) and target-specific options.</t> 208 </list> 209 </t> 210 <t> 211 This document populates the registry with $COUNT entries as follows (see 212 also <xref target="taler-registry" />). 213 </t> 214 215 <section anchor="registry-entry-withdraw" title="Action: withdraw"> 216 <t> 217 The action "withdraw" is used to trigger a bank-integrated withdrawal operation. 218 This means that the user has been interacting with some online banking App and 219 wants to instruct the bank to transfer money from the user's bank account into 220 a the GNU Taler wallet. The wallet now needs to allow the user to select the 221 GNU Taler exchange, and then ultimately provide the bank with its 222 reserve public key and await the completion of the wire transfer. 223 </t> 224 <t> 225 The specific arguments of a "withdraw" action are: 226 <list style="symbols"> 227 <t>bank_host: hostname of the bank (optionally including a port number)</t> 228 <t>bank_prefix_path: list of path components that identifies the path prefix of the bank integration API base URL</t> 229 <t>withdrawal_uid: the unique ID of the withdrawal operation</t> 230 <t>ext (optional): when set to "1", the wallet does not show a confirmation link to the user. 231 Useful when the withdrawal is initiated from an account that is not controlled by the same 232 user as the user of the wallet.</t> 233 </list> 234 </t> 235 <t> 236 <list style="symbols"> 237 <t>Name: withdraw</t> 238 <t>Syntax: taler://withdraw/{bank_host}{/bank_prefix_path*}/{withdrawal_uid}{?external-confirmation=ext}</t> 239 <t>Example: taler://withdraw/bank.example.com/wid</t> 240 <t>Contact: N/A</t> 241 <t>References: [this.I-D]</t> 242 </list> 243 </t> 244 </section> 245 246 <section anchor="registry-entry-pay" title="Action: pay"> 247 <t> 248 Payments are requested with the "pay" action. 249 The parameters are a hierarchical identifier for the requested payment, 250 and must include a hostname, order ID and session ID (which may be 251 an empty string). Additionally, a claim token and a prefix path to be used 252 as part of the HTTP REST API request to the hostname may be specified. 253 </t> 254 <t> 255 The specific arguments of a "pay" action are: 256 <list style="symbols"> 257 <t>merchant_host: hostname of the GNU Taler REST service of merchant (may optionally include a port number)</t> 258 <t>merchant_prefix_path: list of path components that identifies the path prefix of the merchant base URL</t> 259 <t>order_id: the order ID that the customer is asked to pay for</t> 260 <t>session_id: the session ID under which the payment takes place</t> 261 <t>ct: a high-entropy order "ClaimToken"</t> 262 </list> 263 </t> 264 <t> 265 <list style="symbols"> 266 <t>Name: pay</t> 267 <t>Syntax: taler://pay/{merchant_host}{/merchant_prefix_path*}/{order_id}/{session_id}{?c=ct}</t> 268 <t>Example: taler://pay/merchant.example.com/42/</t> 269 <t>Contact: N/A</t> 270 <t>References: [this.I-D]</t> 271 </list> 272 </t> 273 </section> 274 275 <section anchor="registry-entry-refund" title="Action: refund"> 276 <t> 277 A "refund" action instructs the wallet to download information about 278 an available refund. Wallet SHOULD consult the user about the refund and 279 then obtain the refund for an already paid order. 280 </t> 281 <t> 282 The specific arguments of a "refund" action are: 283 <list style="symbols"> 284 <t>merchant_host: hostname of the merchant (possibly including a port number)</t> 285 <t>merchant_prefix_path: list of path components that identifies the path prefix of the merchant base URL</t> 286 <t>order_id: the order ID to check for refunds</t> 287 </list> 288 </t> 289 <t> 290 <list style="symbols"> 291 <t>Name: refund</t> 292 <t>Syntax: taler://refund/{merchant_host}{/merchant_prefix_path*}/{order_id}/</t> 293 <t>Example: taler://refund/shop.example.com/42/</t> 294 <t>Contact: N/A</t> 295 <t>References: [this.I-D]</t> 296 </list> 297 </t> 298 </section> 299 300 <section anchor="registry-entry-pay-push" title="Action: pay-push"> 301 <t> 302 A pay-push URI instructs the wallet to ask the user about accepting a P2P 303 payment. The wallet should download, decrypt and display the underlying 304 contract and accept the offered money if the user agrees to the contract. 305 </t> 306 <t> 307 The specific arguments of a "pay-push" action are: 308 <list style="symbols"> 309 <t>exchange_host: the hostname of the exchange (possibly including a port number)</t> 310 <t>exchange_prefix_path: list of path components that identifies the path prefix of the exchange base URL</t> 311 <t>merge_priv: private key that grants the capability to take the money in the purse</t> 312 </list> 313 </t> 314 <t> 315 <list style="symbols"> 316 <t>Name: pay-push</t> 317 <t>Syntax: taler://pay-push/{exchange_host}{/exchange_prefix_path*}/{merge_priv}</t> 318 <t>Example: taler://pay-push/exchange.example.com/KAMRGDM8FNQ82HSBVDEH8MCAF13Q0B51P4R35RFG2CBVHKGT321G</t> 319 <t>Contact: N/A</t> 320 <t>References: [this.I-D]</t> 321 </list> 322 </t> 323 </section> 324 325 <section anchor="registry-entry-pay-pull" title="Action: pay-pull"> 326 <t> 327 A pay-pull URI instructs the wallet about a request made to the user to 328 pay an invoice (or to simply send money to another wallet). The wallet 329 should download, decrypt and display the underlying contract and ask the 330 user if they agree to pay the invoice. 331 </t> 332 <t> 333 The specific arguments of a "pay-pull" action are: 334 <list style="symbols"> 335 <t>exchange_host: the hostname of the exchange (possibly including a port number)</t> 336 <t>exchange_prefix_path: list of path components that identifies the path prefix of the exchange base URL</t> 337 <t>contract_priv: the private key of the peer push payment contract stored at the exchange</t> 338 </list> 339 </t> 340 <t> 341 <list style="symbols"> 342 <t>Name: pay-pull</t> 343 <t>Syntax: taler://pay-pull/{exchange_host}{/exchange_prefix_path*}/{contract_priv}</t> 344 <t>Example: taler://pay-pull/exchange.example.com/PN3W8SN6N8V1V5MTEZRPJJ2ANY8GGZMB1MBXC7NMSRXJN6MZ5SWG</t> 345 <t>Contact: N/A</t> 346 <t>References: [this.I-D]</t> 347 </list> 348 </t> 349 </section> 350 351 352 <section anchor="registry-entry-pay-template" title="Action: pay-template"> 353 <t> 354 A "pay-template" action instructs the wallet to ask its user to 355 manually complete an order template and submit the information 356 to the merchant to obtain a "pay" request. Wallets MUST fetch 357 meta data about the template from the merchant to determine which 358 information to request from the user. 359 </t> 360 <t> 361 Wallets MAY support users entering all possible fields of a 362 contract if allowed by the template. Fields that MUST be supported 363 at this time are the "amount" and the "summary". The wallet 364 MUST validate that the amount entered by the user is well-formed. 365 For the amount, it is possible that the template restricts 366 the currency in which case the wallet MUST only allow the user to 367 enter an amount in that currency. If the amount entered by the 368 user exceeds the wallet balance, the wallet SHOULD NOT allow the 369 user to submit the action. 370 </t> 371 <t> 372 The specific arguments of a "pay-template" action is: 373 <list style="symbols"> 374 <t>merchant_host: hostname of the merchant</t> 375 <t>merchant_prefix_path: list of path components that identifies the path prefix of the merchant base URL</t> 376 <t>template_id: identifier that uniquely identifies the template</t> 377 </list> 378 </t> 379 <t> 380 <list style="symbols"> 381 <t>Name: pay-template</t> 382 <t>Syntax: taler://pay-template/{merchant_host}{/merchant_prefix_path*}/{template_id}</t> 383 <t>Example: taler://pay-template/merchant.example.com/lunch</t> 384 <t>Contact: N/A</t> 385 <t>References: [this.I-D]</t> 386 </list> 387 </t> 388 </section> 389 390 391 <section anchor="registry-entry-restore" title="Action: restore"> 392 <t> 393 A "restore" action instructs the wallet to restore a wallet backup 394 and merge it into its current state. 395 </t> 396 <t> 397 The specific arguments of a "restore" action are: 398 <list style="symbols"> 399 <t>sync_rootkey: Root sync key of the wallet, used to derive the symmetric key to encrypt the backup with individual providers.</t> 400 <t>sync_provider_list: Comma-separated list of provider http or https URLs. If no scheme part is specified, https is assumed. Each URL is URI-encoded for all characters except "A-Z a-z 0-9 - _ . ! ~ * ' ( )" (matching the HTML5 encodeURIComponent).</t> 401 </list> 402 </t> 403 <t> 404 <list style="symbols"> 405 <t>Name: restore</t> 406 <t>Syntax: taler://restore/{sync_rootkey}/{sync_provider_list}</t> 407 <t>Example: taler://restore/backup.example.com/GJKG23V4ZBHEH45YRK7TWQE8ZTY7JWTY5094TQJSRZN5DSDBX8E0/prov1.example.com,prov2.example.com</t> 408 <t>Contact: N/A</t> 409 <t>References: [this.I-D]</t> 410 </list> 411 </t> 412 </section> 413 414 <section anchor="registry-entry-dev-experiment" title="Action: dev-experiment"> 415 <t> 416 An "dev-experiment" action instructs the wallet to simulate a particular 417 error scenario. This action can be used to test the user interface. 418 Wallets that are not in developer mode should not run 419 the specified action and instead inform the user that "dev-experiment" 420 actions are only supported in developer mode. 421 </t> 422 <t> 423 The specific arguments of a "dev-experiment" action are: 424 <list style="symbols"> 425 <t>name: specifies the specific type of dev experiment</t> 426 </list> 427 </t> 428 <t> 429 <list style="symbols"> 430 <t>Name: dev-experiment</t> 431 <t>Syntax: taler://dev-experiment/{name}</t> 432 <t>Example: taler://dev-experiment/xxx</t> 433 <t>Contact: N/A</t> 434 <t>References: [this.I-D]</t> 435 </list> 436 </t> 437 </section> 438 439 <section anchor="registry-entry-add-exchange" title="Action: add-exchange"> 440 <t> 441 An "add-exchange" action instructs the wallet to add an exchange to its list of 442 exchanges, download its meta data ("/config"), check that it is compatible with 443 the wallet, and if it is a new exchange, ask the user to agree to the 444 terms of service of the exchange. If the user agrees to the terms, 445 the currency of the exchange should be added to the list of currencies. 446 </t> 447 <t> 448 The specific arguments of an "add-exchange" action are: 449 <list style="symbols"> 450 <t>exchange_host: hostname of the exchange (possibly including a port number)</t> 451 <t>exchange_prefix_path (optional): list of path components that identifies the path prefix of the exchange base URL</t> 452 </list> 453 </t> 454 <t> 455 <list style="symbols"> 456 <t>Name: add-exchange</t> 457 <t>Syntax: taler://add-exchange/{exchange_host}{/exchange_prefix_path*}/</t> 458 <t>Example: taler://add-exchange/exchange.example.com/</t> 459 <t>Example: taler://add-exchange/exchanges.example.com/api/</t> 460 <t>Contact: N/A</t> 461 <t>References: [this.I-D]</t> 462 </list> 463 </t> 464 </section> 465 466 467 <section anchor="registry-entry-withdraw-exchange" title="Action: withdraw-exchange"> 468 <t> 469 A "withdraw-exchange" action instructs the wallet to display a prompt to the user, asking 470 the user to confirm/decline withdrawing from the exchange. The amount to be withdraw MAY be 471 specified in the URI with the "amount" parameter and this SHOULD be used as suggested input 472 for the withdraw. The user MUST accept the ToS and select the correct amount before starting 473 the withdrawal. 474 </t> 475 <t> 476 The specific arguments of a "withdraw-exchange" action are: 477 <list style="symbols"> 478 <t>exchange_host: hostname of the exchange (possibly including a port number)</t> 479 <t>exchange_prefix_path (optional): list of path components that identifies the path prefix of the exchange base URL</t> 480 <t>amount_value (optional): default value to use for the withdrawal amount, currency included</t> 481 </list> 482 </t> 483 <t> 484 <list style="symbols"> 485 <t>Name: withdraw-exchange</t> 486 <t>Syntax: taler://withdraw-exchange/{exchange_host}{/exchange_prefix_path*}/{?a=amount_value]}</t> 487 <t>Example: taler://withdraw-exchange/exchange.example.com/?a=KUDOS:10</t> 488 <t>Example: taler://withdraw-exchange/exchanges.example.com/exchange1/</t> 489 <t>Contact: N/A</t> 490 <t>References: [this.I-D]</t> 491 </list> 492 </t> 493 </section> 494 495 <section anchor="registry-entry-add-contact" title="Action: add-contact"> 496 <t> 497 An "add-contact" action instructs the wallet to add a contact to its list of 498 contacts. 499 </t> 500 <t> 501 The specific arguments of an "add-contact" action are: 502 <list style="symbols"> 503 <t>alias_type: the type of alias of this contact</t> 504 <t>alias: the alias of a contact</t> 505 <t>mailbox_host: hostname of the mailbox of the contact (possibly including a port number)</t> 506 <t>mailbox_prefix_path (optional): list of path components that identifies the path prefix of the mailbox base URL</t> 507 <t>mailbox_address: the contacts mailbox address.</t> 508 <t>source_base_url (optional): the source of this contact information (taler directory service base URL). Optional.</t> 509 </list> 510 </t> 511 <t> 512 <list style="symbols"> 513 <t>Name: add-contact</t> 514 <t>Syntax: taler://add-contact/{alias_type}/{alias}/{mailbox_host}{/mailbox_prefix_path*}/{mailbox_address}{?sourceBaseUrl=source_base_url}</t> 515 <t>Example: taler://add-contact/email/taler@example.com/mailbox.example.com/SOMEADDRESS/?sourceBaseUrl=https://taldir.example.com</t> 516 <t>Contact: N/A</t> 517 <t>References: [this.I-D]</t> 518 </list> 519 </t> 520 </section> 521 522 523 <section anchor="registry-entry-withdrawal-transfer-result" title="Action: withdrawal-transfer-result"> 524 <t> 525 A "withdrawal-transfer-result" action instructs the wallet to display the status of a withdrawal 526 to the user. Typically used to transfer control between a banking app/website and a Taler wallet. 527 Optionally, the URI can also specify an update to the status of the transfer 528 to the exchange for the withdrawal as a hint for the wallet. The wallet must only use this 529 value to show further hints to the user. 530 </t> 531 <t> 532 The specific arguments of a "withdraw-exchange" action are: 533 <list style="symbols"> 534 <t>ref_value: A reference for the transaction that must contain the reserve public key. Used to identify the 535 withdrawal transaction in the wallet.</t> 536 <t>status_value (optional): The status of the transfer, must be one of: "success", "aborted".</t> 537 </list> 538 </t> 539 <t> 540 <list style="symbols"> 541 <t>Name: withdraw-transfer-result</t> 542 <t>Syntax: taler://withdrawal-transfer-result{?ref=ref_value}{?status=status_value}</t> 543 <t>Contact: N/A</t> 544 <t>References: [this.I-D]</t> 545 </list> 546 </t> 547 </section> 548 549 550 </section><!-- tracking --> 551 552 <section anchor="security" title="Security Considerations"> 553 <t> 554 Interactive applications handling the taler URI scheme MUST NOT initiate any 555 unsafe payment operations prior review and confirmation from the user, 556 and MUST take measures to prevent clickjacking <xref target="HMW12"/>. 557 </t> 558 <t> 559 The authentication/authorization mechanisms and transport security services 560 used to process a payment encoded in a taler URI 561 are handled by the application and are not in scope of this document. 562 </t> 563 </section> 564 565 <section anchor="iana" title="IANA Considerations"> 566 567 <t> 568 IANA maintains a registry called the "Uniform Resource Identifier 569 (URI) Schemes" registry. 570 </t> 571 572 <section anchor="taler-uri" title="URI Scheme Registration"> 573 <t> 574 IANA maintains the "Uniform Resource Identifier (URI) Schemes" 575 registry that contains an entry for the 'taler' URI scheme. IANA is 576 requested to update that entry to reference this document when 577 published as an RFC. 578 </t> 579 </section> 580 </section> 581 582 <section anchor="taler-registry" title="Taler URI Actions"> 583 <t> 584 This document specifies a list of Taler URI Actions. It is 585 possible that future work will need to specify additional 586 actions. The GNUnet Assigned Numbers Authority (GANA) <xref target="GANA" /> 587 operates the "taler-uri-actions" registry to track 588 the following information for each payment target type: 589 <list style="symbols"> 590 <t>Name: The name of the action (case insensitive ASCII string, restricted to alphanumeric characters, 591 dots and dashes)</t> 592 <t>Contact: The contact information of a person to contact for further information</t> 593 <t>References: Optionally, references describing the payment target type (such as an RFC) and target-specific options, 594 or references describing the payment system underlying the payment target type.</t> 595 </list> 596 </t> 597 <t> 598 The entries that have been made for the "taler-uri-actions" 599 defined in this document are as follows: 600 </t> 601 <figure> 602 <artwork> 603 Name | Contact | Reference 604 ----------------------------+-------------------------+---------- 605 pay | N/A | [This.I-D] 606 withdraw | N/A | [This.I-D] 607 refund | N/A | [This.I-D] 608 pay-pull | N/A | [This.I-D] 609 pay-push | N/A | [This.I-D] 610 pay-template | N/A | [This.I-D] 611 restore | N/A | [This.I-D] 612 dev-experiment | N/A | [This.I-D] 613 add-exchange | N/A | [This.I-D] 614 add-contact | N/A | [This.I-D] 615 withdraw-exchange | N/A | [This.I-D] 616 withdrawal-transfer-result | N/A | [This-I.D] 617 </artwork> 618 </figure> 619 620 </section><!-- taler-registry --> 621 622 </middle> 623 624 <back> 625 626 <references title="Normative References"> 627 628 &RFC2119; 629 630 &RFC3986; 631 632 &RFC5234; 633 634 &RFC8126; 635 636 &RFC8174; 637 638 639 </references> 640 641 <references title="Informational References"> 642 643 <reference anchor="HMW12" target="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf"> 644 <front> 645 <title>Clickjacking: Attacks and Defenses</title> 646 <author initials="L.S." surname="Huang" 647 fullname="Lin-Shung Huang"> 648 </author> 649 <author initials="A." surname="Moshchuk" 650 fullname="Alexander, Moshchuk"> 651 </author> 652 <author initials="H.J." surname="Wang" 653 fullname="Helen J. Wang"> 654 </author> 655 <author initials="S." surname="Schecter" 656 fullname="Stuart Schecter"> 657 </author> 658 <author initials="C." surname="Jackson" 659 fullname="Collin Jackson"> 660 </author> 661 662 <date month="January" year="2012" /> 663 </front> 664 </reference> 665 666 <reference anchor="GANA" target="https://gana.gnunet.org/"> 667 <front> 668 <title>GNUnet Assigned Numbers Authority (GANA)</title> 669 <author><organization>GNUnet e.V.</organization> 670 </author> 671 <date month="April" year="2020" /> 672 </front> 673 </reference> 674 675 </references> 676 677 <!-- Change Log 678 v00 2022-11-11 CG Initial version 679 --> 680 </back> 681 </rfc>