13.70. DD 70: Alias Lookup and Mailbox#
13.70.1. Summary#
GNU Taler is a payment system that makes privacy-friendly online transactions fast and easy. This project will facilitate the support of peer-to-peer payments (P2P) for the GNU Taler payment system between users by implementing a privacy-friendly directory service and lightweight inbox service (TALer DIRectory). The services will allow users to securely associate their online identities (such as email addresses, phone numbers, X/Twitter/Mastodon handles or other suitable verifiable addresses and accounts) with their wallet public keys and the URL of an inbox service and use it for P2P payments. Storage and retrieval may also be offloaded to distributed directory services such as DNS or GNS (RFC 9498) instead of a database and web service while maintaining the respective privacy guarantees.
13.70.2. Motivation#
The Digital Euro is current in development and as a part of it the so-called “Alias Lookup Service” is being developed for at least 28 Millon Euros (Tender “PRO-009485”).
To enable peer-to-peer payments for the GNU Taler payment system between users such a directory service and lightweight inbox service are also required. But, this service one the one hand has delicate privacy requirements not found in . We believe that the estimated development costs from the ECB tender are unreasonably and unexplicably high and we can demostrate how an efficient, privacy-friendly and lean service that offers this kind of functionality can be developed within this proposal at a fraction of the cost of the “Alias Lookup Service”:
The directory service will allow users to securely associate their online identities (such as email addresses, phone numbers, X/Twitter/Mastodon handles or other suitable verifiable addresses and accounts) with their wallet public keys and the URL of an inbox service. Additionally we found that storage and retrieval may also be offloaded to distributed directory services such as DNS or GNS (RFC 9498) instead of a database and web service while maintaining the respective privacy guarantees. We have added such a task to the estimate.
In order to facilitate fund transfers in the P2P context, we will extend the Taler wallet (in particular, the browser-based WebExtension) to allow users to associate the wallet with one or more (waller) addresses, to query the directory to send money or invoices, to encrypt the payment messages to the public key obtained from the directory, to transmit the message via the lightweight inbox service, and to poll the inbox service for incoming requests and show them to the user. Both the key directory service and the inbox service may provide their services for a fee to compensate the operator for operational costs including the validation of addresses.
13.70.3. Requirements#
The implementation must take great care to ensure the privacy and integrity of the mappings from the identity to the wallet keys. For this, plain text identity information such as email addresses should only be processed as part of the validation and registration processes. The actual mappings will be indexed using salted hashes.
Queries for wallet keys also should require the caller to provide the already hashed identity to minimize data leakage from requests.
This minimizes the handling of personally identifyable information (PII) at the service and limits exposure in case of data leaks at the operator.
The service must be suitable to be operated at very high availability constraints. As such, the service must be scalable and ideally have a small footprint and computing base.
13.70.4. Proposed Solution#
The directory and mailbox services will be implemented as two distinct services. Both with have an open REST API which will be specified as part of the protocol.
13.70.4.1. Directory#
The directory will support an extensible interface for alias validators. Validators will ensure that users that want to register mailbox URIs under an alias are actually the owner/in control over the particular alias. For example, in order to use an email address as the alias a verification link will be sent to that address and the user needs to confirm registration.
In addition to the REST API, the directory will support an extensible interface for alias disseminators. Disseminators will publish the alias-mailbox mapping. For example, DNS or GNS validators will publish the mappings under zones of the operator.
13.70.5. Definition of Done#
(Only applicable to design documents that describe a new feature. While the DoD is not satisfied yet, a user-facing feature must be behind a feature flag or dev-mode flag.)
13.70.6. Alternatives#
13.70.7. Drawbacks#
13.70.8. Discussion / Q&A#
(This should be filled in with results from discussions on mailing lists / personal communication.)