[GNUnet-SVN] [taler-marketing] branch master updated: payto v02

[gnunet]

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

dold pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new a91f437  payto v02
a91f437 is described below

commit a91f43730af4bc07e729d8faaf0964f5cf7829bf
Author: Florian Dold <address@hidden>
AuthorDate: Mon Oct 8 23:23:44 2018 +0200

    payto v02
---
 standards/draft-dold-payto.xml | 74 +++++++++++++++++++++++++++++++++---------
 1 file changed, 59 insertions(+), 15 deletions(-)

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 389f0ee..f2eefec 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -12,7 +12,7 @@
 <?rfc subcompact="no" ?>
 
 <rfc category="info"
-     docName="draft-dold-payto"
+     docName="draft-dold-payto-02"
      ipr="trust200902">
 
   <front>
@@ -33,7 +33,7 @@
          <code>F-35042</code>
           <country>FR</country>
         </postal>
-        <email>address@hidden</email>
+        <email>address@hidden</email>
       </address>
     </author>
 
@@ -62,7 +62,7 @@
     <abstract>
 
       <t>This document defines the 'payto' Uniform Resource Identifier (URI) 
scheme
-      for specifying payments.</t>
+      for designating targets for payments.</t>
 
     </abstract>
 
@@ -73,9 +73,13 @@
 <section anchor="introduction" title="Introduction">
 <t>
   This document defines the 'payto' Uniform Resource Identifier (URI) <xref 
target="RFC3986" /> scheme
-  for specifying payments.  In its simplest form, a 'payto' URL
-  identifies a payment method and optionally an account identifier.  
Additional parameters
-  for a payment, such as an amount or a payment reference, can be provided.
+  for designating targets for payments.  In its simplest form, a 'payto' URL
+  identifies a payment target type and optionally a target identifier.  
Additional parameters,
+  such as an amount or a payment reference, can be provided.
+</t>
+<t>
+  The interpretation of the target identifier is defined by the payment target 
type, and typically
+  represents either a bank account or an (unsettled) transaction.
 </t>
 </section>
 
@@ -101,19 +105,24 @@
 
 <section anchor="semantics" title="Semantics">
 <t>
-  The authority component of a payment URI identifies the payment method.  The
-  payment methods are defined in the Payto Payment Method Registry, see <xref
+  The authority component of a payment URI identifies the payment target type. 
 The
+  payment target types are defined in the Payto Payment Target Type Registry, 
see <xref
   target="payto-registry" />.
 
-  The path component of the URI identifies the target account for a payment as 
interpreted
-  by the respective payment method.
+  The path component of the URI identifies the target for a payment as 
interpreted
+  by the respective payment target type.
 
   The query component of the URI can provide additional parameters for a 
payment.
   Every payment method SHOULD accept the options defined in generic-opt.
 
   The default operation of applications that invoke a URI with the payto scheme
   SHOULD be to launch an application (if available) associated with the payment
-  method that can initiate a payment.  Details of the payment MUST be taken
+  target type that can initiate a payment.  If multiple handlers are 
registered for the same
+  payment target type, the user SHOULD be able to choose which application to 
launch.
+  This allows users with multiple bank accounts (each accessed the respective 
bank's
+  banking application) to choose which account to pay with.
+  
+  Details of the payment MUST be taken
   from the path and options given in the URI.  The user SHOULD be allowed to
   modify these details before confirming a payment.
 </t>
@@ -190,7 +199,9 @@
 
 <section anchor="security" title="Security Considerations">
 <t>Applications handling the payto URI scheme MUST NOT initiate any
-transactions without prior review and confirmation from the user.</t>
+  financial transactions without prior review and confirmation from the user,
+  and MUST take measures to prevent clickjacking <xref target="HMW12"/>.
+</t>
 </section>
 
 <section anchor="iana" title="IANA Considerations">
@@ -217,12 +228,12 @@ The "payto" URI scheme is to be registered in the 
"Permanent URI Schemes" regist
 <section anchor="payto-registry" title="Payto Payment Method Registry">
 <t>
 This document defines a registry for payment methods.  The name of the registry
-is "Payto Payment Method Registry".
+is "Payto Payment Target Type Registry".
 </t>
 <t>The registry shall record for each entry:
 <list style="symbols">
-<t>Name:  The name of the payment method (case insensitive ASCII string)</t>
-<t>Description: A description of the payment method, including the semantics 
of the path in the URI if applicable.</t>
+<t>Name:  The name of the payment target type (case insensitive ASCII 
string)</t>
+<t>Description: A description of the payment target type, including the 
semantics of the path in the URI if applicable.</t>
 <t>Contact: The contact information of a person to contact for further 
information</t>
 <t>References: Optionally, references describing the payment method (such as 
an RFC) and method-specific options</t>
 </list>
@@ -236,6 +247,7 @@ The registration policy for this registry is "First Come 
First Served", as descr
 <c>sepa</c><c>Single European Payment Area. The path is an 
IBAN.</c><c>N/A</c><c><xref target="ISO20022" /></c>
 <c>upi</c><c>Unified Payment Interface. The path is an account 
alias.</c><c>N/A</c><c><xref target="UPILinking" /></c>
 <c>bitcoin</c><c>Bitcoin protocol. The path is a "bitcoinaddress" as per <xref 
target="BIP0021" />.</c><c>N/A</c><c><xref target="BIP0021" /></c>
+<c>ilp</c><c>Interledger protocol. The path is an ILP address as per <xref 
target="ILP-ADDR" />.</c><c>N/A</c><c><xref target="ILP-ADDR" /></c>
 </texttable>
 
 </section>
@@ -332,6 +344,29 @@ The registration policy for this registry is "First Come 
First Served", as descr
 
          <date month="January" year="2012" />
      </front>
+   </reference>
+
+   <reference anchor="HMW12" 
target="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf";>
+     <front>
+         <title>Clickjacking: Attacks and Defenses</title>
+         <author initials="L.S." surname="Huang"
+                 fullname="Lin-Shung Huang">
+         </author>
+         <author initials="A." surname="Moshchuk"
+                 fullname="Alexander, Moshchuk">
+         </author>
+         <author initials="H.J." surname="Wang"
+                 fullname="Helen J. Wang">
+         </author>
+         <author initials="S." surname="Schecter"
+                 fullname="Stuart Schecter">
+         </author>
+         <author initials="C." surname="Jackson"
+                 fullname="Collin Jackson">
+         </author>
+
+         <date month="January" year="2012" />
+     </front>
   </reference>
 
   <reference anchor="UPILinking" 
target="http://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf";>
@@ -344,6 +379,15 @@ The registration policy for this registry is "First Come 
First Served", as descr
     </front>
   </reference>
 
+ <reference anchor="ILP-ADDR" 
target="https://interledger.org/rfcs/0015-ilp-addresses/";>
+   <front>
+       <title>ILP Addresses - v2.0.0</title>
+      <author><organization>Interledger Team</organization>
+      </author>
+       <date month="September" year="2018" />
+   </front>
+ </reference>
+
   </references>
 
   <!-- Change Log

-- 
To stop receiving notification emails like this one, please contact
address@hidden