taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Taler] age-restriction is about coins, not currencies


From: Özgür Kesim
Subject: [Taler] age-restriction is about coins, not currencies
Date: Mon, 6 Sep 2021 20:19:21 +0200

Hi Fabian,

As Sebastian already pointed out, using different currencies
(denominations in the Taler-lingo) for attributes is indeed a
possible technical solution for the problem of - say -  age
verification, it would reveal private information about the
withdrawer to the exchange.  On larger scales we would partition
the population by these visible attributes.

We can do better.

If we focus only on age restriction, here are some basic
questions we should ask and find good answers for in GNU Taler:

Q: Who needs to be able to verify the required age?
A: The merchant, according to the law.  But _not_ the exchange.

   This pretty much rules out using multiple currencies/
   denominations as encoding of the age restriction.


Q: Who should be able to set the maximum age "attribute" on 
   a coin?
A: The parent/warden, according to the subsidiary principle.

   It should be set by the parent/warden at the time of
   withdrawal of a coin.  And no other external authority should
   be able to see or even given control over setting the maximum
   age for a coin (this rules out ID-based solutions).


Q: Should the coin (its public information) be visibly tainted as
   age restricted?
A: No, this has the same drawback as age-specific currencies: it
   would reveal the maximum age of a coin to the exchange.  It
   also it to a merchant, even when a purchase was not age
   restricted.


So, because multiple currencies or tainted coins are not good,
nor are ID-based systems, we should bake anonymous age
restriction into the coins and protocols of Taler.

My design for anonymous age restriction in GNU Taler takes the
above points into consideration and has the following properties:

- Age restriction is set in a coin at withdrawal time.

- The age restriction is opaquely signed by the exchange, along
  with the coin, but the actual maximum age set is not revealed
  to the exchange and not part of the public information of the
  coin.

- If a purchase requires a certain minimum age and the buyer has
  coins to prove that, the merchants can verify the validity of
  the coin and the required age during the purchasing process.
  The _actual_ maximum age set in the coin can be higher, but
  this is not revealed to the merchant.

- When a buyer refreshes coins with age restriction ("gets
  change"), the exchange will ensure - with certain probability
  1-1/kappa - that the new coins have the same age restriction
  applied as the original coin, but does _not_ learn about the
  actual set age.

- The protocols for the anonymous age restriction fulfill
  sufficiently strong security requirements for anonymity and
  unlinkability of coins and transactions.  All existing
  anonymity and unlinkability guaranties of Taler remain intact.

Technical details will be posted soon(ish).

Cheers,
Özgür



Thus spake Fabian Kirsch (fabian.kirsch@posteo.de):

> Hi
> 
> The whole capabilities feature is a currency feature. And therefor outside
> of talers implementation concern.
> 
> So as taler coins can reflect any currency on earth, i suggest to run a bank
> which has "$18+", "$21+" as well as "$" in their currency portfolio. And
> then any service may say "please id, or use $21+ coins". The bank knows
> their customers but not their spending behaviour. Europeans may choose "€",
> "€16+", "€18+".
> 
> For other caps like "$,food only" it is the bank that checks its merchants
> to be eligible. The service could advertise "we accept $-food-only". This
> allows questions like "does beer count as food" to be settled different in
> different parts of the world.
> 
> 
> This also makes the whole topic a regional one, where cultural norms are
> more likely to find agreement whether they want the capabilty feature or
> not.
> 
> greetings Fabian
> 

Thus spake Sebastian Javier Marchano (sebasjm@gmail.com):

> Hi Fabian,
> 
> So as taler coins can reflect any currency on earth, i suggest to run a
> > bank which has "$18+", "$21+" as well as "$" in their currency
> > portfolio. And then any service may say "please id, or use $21+ coins".
> > The bank knows their customers but not their spending behaviour.
> > Europeans may choose "€", "€16+", "€18+".
> 
> 
> one attribute you want the system to have is that the user of the GNU Taler
> reveals no information about it's condition when spending the coins.
> So in your case, having different currencies (EUR+16, EUR+18, EUR) will
> make the information about the user age available to merchants.
> 
> The goal of Ozgur's proposal is to achieve the same behavior and the
> receiver of the coins should only know if you have enough money or not.
> 
> My guess (because I haven't see the details :) ) is that if the user have
> coins just for under-18-products and the contract terms says that you are
> buying restricted products (like beer) when the merchant tries to deposit
> the coins using the /coins/$COIN_PUB/deposit endpoint the exchange will end
> with some of the error codes.
> 
> Best regards
> --
> Sebastian
> 
> 
> On Mon, 6 Sept 2021 at 04:19, Fabian Kirsch <fabian.kirsch@posteo.de> wrote:
> 
> > Hi
> >
> > The whole capabilities feature is a currency feature. And therefor
> > outside of talers implementation concern.
> >
> > So as taler coins can reflect any currency on earth, i suggest to run a
> > bank which has "$18+", "$21+" as well as "$" in their currency
> > portfolio. And then any service may say "please id, or use $21+ coins".
> > The bank knows their customers but not their spending behaviour.
> > Europeans may choose "€", "€16+", "€18+".
> >
> > For other caps like "$,food only" it is the bank that checks its
> > merchants to be eligible. The service could advertise "we accept
> > $-food-only". This allows questions like "does beer count as food" to be
> > settled different in different parts of the world.
> >
> >
> > This also makes the whole topic a regional one, where cultural norms are
> > more likely to find agreement whether they want the capabilty feature or
> > not.
> >
> > greetings Fabian
> >
> >





reply via email to

[Prev in Thread] Current Thread [Next in Thread]