taler/wallet-core
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Activity

krista pass

Browse Source
This commit is contained in:
Christian Grothoff 2016-08-30 09:46:37 +02:00
parent 5e595863bd
commit f88abffb28
1 changed files with 23 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
articles/ui/ui.tex
View File

@ -141,8 +141,9 @@ transactions involving the exchange of physical goods. Consequently,
if we want to associate payments with these types of transactions, we if we want to associate payments with these types of transactions, we
face the challenge of reducing the mental and technical overheads of face the challenge of reducing the mental and technical overheads of
existing payment systems. For example, executing a 3DS payment existing payment systems. For example, executing a 3DS payment
process (Figure~\ref{fig:cc3ds}) takes too long, is way too complex process (Figure~\ref{fig:cc3ds}) takes too long, is way too complex,
and way to expensive to be used for payment for typical Web articles. and way too expensive to be used for payment for typical Web articles.
%KG: Define 3DS. I have no idea WTF you're talking about throughout the paper with this.
Addressing this problem is urgent: ad-blocking technology is eroding Addressing this problem is urgent: ad-blocking technology is eroding
advertising as a substitute for micropayments~\cite{adblockblocks}, advertising as a substitute for micropayments~\cite{adblockblocks},
@ -166,23 +167,23 @@ means that for any transaction the state can easily obtain the
necessary information about the identity of the merchant and the necessary information about the identity of the merchant and the
respective contract in order to levy income, sales, or value-added respective contract in order to levy income, sales, or value-added
taxes. Taler uses blind signatures~\cite{chaum1983blind} to create taxes. Taler uses blind signatures~\cite{chaum1983blind} to create
digital coins, and a new {\em refresh} protocol~\cite{talercrypto} to digital coins and a new {\em refresh} protocol~\cite{talercrypto} to
allow giving change and refunds while maintaining unlinkability. allow giving change and refunds while maintaining unlinkability.
This paper will not consider the details of Taler's cryptographic This paper will not consider the details of Taler's cryptographic
protocols.\footnote{Details of the protocol are documented at protocols.\footnote{Details of the protocol are documented at
\url{https://api.taler.net/}} The basic cryptography behind \url{https://api.taler.net/}} The basic cryptography behind
blind-signature based payment systems has been known for over 25 blind-signature based payment systems has been known for over 25
years~\cite{chaum1990untraceable}. However, only in 2015 the W3c years~\cite{chaum1990untraceable}. However, it was not until 2015 that the W3C
started the payments working group~\cite{pigs} to explore requirements started the payments working group~\cite{pigs} to explore requirements
for deploying payment systems that are more secure and easy to use for for deploying payment systems that are more secure and easy to use for
the Web. Our work describes how a modern payment system using blind the Web. Our work describes how a modern payment system using blind
signatures could practically be integrated with the modern Web to signatures could practically be integrated with the modern Web to
improve usability, security and privacy. This includes the challenge improve usability, security, and privacy. This includes the challenge
of hiding the cryptography from the users, integrating with modern of hiding the cryptography from the users, integrating with modern
browsers, integrating with Web shops, providing proper cryptographic browsers, integrating with Web shops, providing proper cryptographic
proofs for all operations, and handling network failures. We explain proofs for all operations, and handling network failures. We explain
our design using terms from existing {\em mental models} users have our design using terms from existing {\em mental models} that users have
from widespread payment systems. from widespread payment systems.
%\newpage %\newpage
@ -215,7 +216,7 @@ based on resources from the W3C payment interest group.
Cash has traditionally circulated by being passed directly from buyers Cash has traditionally circulated by being passed directly from buyers
to sellers with each seller then becoming a buyer. Thus, cash is to sellers with each seller then becoming a buyer. Thus, cash is
inherently a {\em peer-to-peer} payment system as participants all inherently a {\em peer-to-peer} payment system, as participants all
appear in both buyer and seller roles, just at different times. appear in both buyer and seller roles, just at different times.
However, this view is both simplified and However, this view is both simplified and
somewhat dated. somewhat dated.
@ -246,7 +247,7 @@ for the customer. Instead, the merchant provides paper
{\em receipts}, which are generated independently and do not receive {\em receipts}, which are generated independently and do not receive
the same anti-forgery protections that are in place for cash. the same anti-forgery protections that are in place for cash.
Against most attacks, customers and merchants {\em limit} their risks Against most attacks, customers and merchants {\em limit} their risk
to the amount of cash that they carry or accept at a given to the amount of cash that they carry or accept at a given
time~\cite{Bankrate}. Additionally, customers are advised to choose time~\cite{Bankrate}. Additionally, customers are advised to choose
the ATMs they use carefully, as malicious ATMs may attempt to the ATMs they use carefully, as malicious ATMs may attempt to
@ -266,6 +267,7 @@ issued by the customer's bank.
\caption{Card payment processing with 3DS. (From: W3C Web Payments IG.)} \caption{Card payment processing with 3DS. (From: W3C Web Payments IG.)}
\label{fig:cc3ds} \label{fig:cc3ds}
\end{figure*} \end{figure*}
%KG: I hope they can print this larger, because this is WAY too small to be of any use.
Credit and debit card payments operate by the customer providing their Credit and debit card payments operate by the customer providing their
credentials to the merchant. Many different authentication and credentials to the merchant. Many different authentication and
@ -286,13 +288,14 @@ entering the credit card details like the owner's name, card number,
expiration time, CCV code, and billing address; and {(4.)} expiration time, CCV code, and billing address; and {(4.)}
(optionally) authorizing the transaction via mobile TAN, or by (optionally) authorizing the transaction via mobile TAN, or by
authenticating against the customer's bank. Due to the complexity authenticating against the customer's bank. Due to the complexity
of this the data entry is often performed on a Web site that of this, the data entry is often performed on a Web site that
is operated by a third-party payment processor and {\em not} the merchant or is operated by a third-party payment processor and {\em not} the merchant or
the customer's bank. Figure~\ref{fig:cc3ds} shows a typical card-based payment the customer's bank. Figure~\ref{fig:cc3ds} shows a typical card-based payment
process on the Web using the UML style of the W3C payment interest process on the Web using the UML style of the W3C payment interest
group~\cite{pigs}. Most of the details are not relevant to this group~\cite{pigs}. Most of the details are not relevant to this
paper, but the diagram nicely illustrates the complexity of the common paper, but the diagram nicely illustrates the complexity of the common
3-D secure (3DS) process. 3-D secure (3DS) process.
%KG: Define 3DS the FIRST time you use it.
Given this process, there is an inherent risk of information leakage Given this process, there is an inherent risk of information leakage
of customers' credentials. {\em Fraud detection} systems attempt to detect of customers' credentials. {\em Fraud detection} systems attempt to detect
@ -325,9 +328,9 @@ malicious merchants to later change the terms of the contract.
Beyond these primary issues, customers face secondary risks of Beyond these primary issues, customers face secondary risks of
identity theft from the personal details exposed by the authentication identity theft from the personal details exposed by the authentication
procedures. In this case, even if the financial damages are ultimately procedures. In this case, even if the financial damages are ultimately
covered by the bank, the customer always has to deal with the hassle covered by the bank, the customer always has to deal with the procedure
of {\em notifying} the bank in the first place. As a result, of {\em notifying} the bank in the first place. As a result,
customers must remain wary about using their card, which limits their customers must remain wary about using their cards, which limits their
online shopping~\cite[p. 50]{ibi2014}. online shopping~\cite[p. 50]{ibi2014}.
% There is nevertheless a trend towards customers preferring cards % There is nevertheless a trend towards customers preferring cards
% over cash even in face-to-face purchases \cite{} in part because % over cash even in face-to-face purchases \cite{} in part because
@ -515,7 +518,7 @@ ago, cryptographers have viewed blind signatures as the optimal
cryptographic primitive for privacy-preserving consumer-level transaction systems. cryptographic primitive for privacy-preserving consumer-level transaction systems.
However, previous transaction systems based on blind signatures have However, previous transaction systems based on blind signatures have
failed to see widespread adoption. This paper details strategies for failed to see widespread adoption. This paper details strategies for
hiding the cryptography from users and integrating smoothly with the hiding the complexity of the cryptography from users and integrating smoothly with the
Web, thereby providing crucial steps to bridge the gap between good Web, thereby providing crucial steps to bridge the gap between good
cryptography and real-world deployment. cryptography and real-world deployment.
@ -562,7 +565,7 @@ hold, and spend coins. Wallets manage the customer's accounts
at the exchange, and keep receipts in a transaction history. Wallets can be at the exchange, and keep receipts in a transaction history. Wallets can be
realized as browser extensions, mobile Apps or even in custom realized as browser extensions, mobile Apps or even in custom
hardware. If a user's digital wallet is compromised, the current hardware. If a user's digital wallet is compromised, the current
balance may be lost, just like with an ordinary wallet containing cash. balance may be lost, just as with an ordinary wallet containing cash.
A wallet includes a list of trusted auditors, and will warn A wallet includes a list of trusted auditors, and will warn
users against using an exchange that is not certified by a trusted users against using an exchange that is not certified by a trusted
auditor. auditor.
@ -591,9 +594,9 @@ auditor.
customers to withdraw anonymous digital coins, customers to withdraw anonymous digital coins,
and merchants to deposit digital coins, in exchange for and merchants to deposit digital coins, in exchange for
bank money. Coins are signed by the exchange using bank money. Coins are signed by the exchange using
a blind signing scheme~\cite{chaum1983blind}. Thus, only a blind signature scheme~\cite{chaum1983blind}. Thus, only
an exchange can issue new coins, but coins cannot be traced back an exchange can issue new coins, but coins cannot be traced back
to the customer that withdrew them. to the customer who withdrew them.
Furthermore, exchanges learn the amounts withdrawn by customers Furthermore, exchanges learn the amounts withdrawn by customers
and deposited by merchants, but they do not learn the relationship and deposited by merchants, but they do not learn the relationship
between customers and merchants. Exchanges perform online detection between customers and merchants. Exchanges perform online detection
@ -606,7 +609,7 @@ by customers' wallets. Merchants deposit these coins at the
exchange used by the customer in return for a bank wire exchange used by the customer in return for a bank wire
transfer of their value. While the exchange is determined by transfer of their value. While the exchange is determined by
the customer, the merchant's contract specifies the currency, the customer, the merchant's contract specifies the currency,
a list of accepted auditors and the maximum exchange deposit a list of accepted auditors, and the maximum exchange deposit
fee the merchant is willing to pay. Merchants consist of a fee the merchant is willing to pay. Merchants consist of a
{\em frontend}, which interacts with the customer's wallet, and a {\em {\em frontend}, which interacts with the customer's wallet, and a {\em
backend}, which interacts with the exchange. Typical frontends include backend}, which interacts with the exchange. Typical frontends include
@ -653,7 +656,7 @@ operation. Restarting the browser is not required.
As with cash, the customer must first withdraw digital coins As with cash, the customer must first withdraw digital coins
(Figure~\ref{fig:taler-withdraw}). For this, the customer must first (Figure~\ref{fig:taler-withdraw}). For this, the customer must first
visit the bank's online portal. Here, the bank will visit the bank's online portal. Here, the bank will
typically require some form of authentication, the specific method typically require some form of authentication; the specific method
used depends on the bank (Figure~\ref{subfig:login}). used depends on the bank (Figure~\ref{subfig:login}).
The next step depends on the level of Taler support offered by the bank: The next step depends on the level of Taler support offered by the bank:
@ -671,8 +674,8 @@ The next step depends on the level of Taler support offered by the bank:
54-character reserve key, which includes 256 bits of entropy and an 54-character reserve key, which includes 256 bits of entropy and an
8-bit checksum into the transfer subject. Naturally, the above is 8-bit checksum into the transfer subject. Naturally, the above is
exactly the kind of interaction we would like to avoid for exactly the kind of interaction we would like to avoid for
usability reason. usability reasons.
\item Hence, if the bank fully supports Taler, the \item Otherwise, if the bank fully supports Taler, the
customer has a form in the online banking portal in which they can specify customer has a form in the online banking portal in which they can specify
an amount to withdraw (Figure~\ref{subfig:withdraw}). an amount to withdraw (Figure~\ref{subfig:withdraw}).
The bank then triggers an interaction with The bank then triggers an interaction with
@ -1547,7 +1550,7 @@ at \url{https://demo.taler.net/}.
This work benefits from the financial support of the Brittany Region This work benefits from the financial support of the Brittany Region
(ARED 9178) and a grant from the Renewable Freedom Foundation. We (ARED 9178) and a grant from the Renewable Freedom Foundation. We
thank Bruno Haible for his financial support enabling us to thank Bruno Haible for his financial support enabling us to
participate with the W3c payment working group. We thank the W3c participate with the W3c payment working group. We thank the W3C
payment working group for insightful discussions about Web payments. payment working group for insightful discussions about Web payments.
We thank Krista Grothoff and Neal Walfield for comments on an earlier We thank Krista Grothoff and Neal Walfield for comments on an earlier
draft of the paper. We thank Gabor Toth for his help with the draft of the paper. We thank Gabor Toth for his help with the