taler
[Top][All Lists]
Advanced

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

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


From: Christian Grothoff
Subject: Re: [Taler] age-restriction is about coins, not currencies
Date: Tue, 7 Sep 2021 11:47:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Hi Martin,

Stefan is looking into this legal aspect. From what I hear so far, it
might indeed suffice (maybe not for all products, but maybe at least for
digital media). And even if in _some_ countries the proposed
age-restrictions are not legally sufficient, they might be in others. Or
the laws could theoretically be changed. For me, this debate is still
more about what we (ethically) should build, what features we do want to
have (or not have), and what a payment system could offer to a libre
society.

After all, one of the questions the central banks are asking is "what
could be the value-add of a Digital Euro for society?". I think one
answer could very well be: "make digital ID solutions obsolete for many
contemporary use-cases, reducing the negative effects of digital ID
solutions". And here the "this is incompatible with current laws" issue
is mood, as most central banks are wondering already if the laws
wouldn't have to be changed before they can offer a central bank digital
currency in the first place.

So yes, the legal question is interesting, but needs to be looked at
(and possibly fought as part of the fight against government overreach
on E-ID mandates) in each country. And sure, it only makes sense to
enable this kind of feature if the legal environment is suitable ---
which is IMO one key reason to make it always optional.


My 2 cents

Christian


On 9/6/21 8:46 PM, Schanzenbach, Martin wrote:
> Hi,
> 
> I am not sure this would actually address the compliance/legal issue a 
> merchant would have to deal with.
> The merchant is usually responsible to determine if the buyer is underage, 
> not if the coin was given to somebody who is underage.
> Simply having a tainted coin (tainted by the parent when giving the pocket 
> money) is not sufficient from a compliance perspective as the acquisition of 
> the money is irrelevant in this case.
> The transaction with the minor is the issue, and the minor may have acquired 
> the coins through other means.
> (Even excluding other, more creative means we could simply limit this to your 
> own example: The coins acquired over time through refreshing).
> For example: It is still illegal to sell alcohol to a minor even with the 
> parent's consent (in most countries I can think of).
> 
> Additionally, it seems to me that (unlike getting a fake ID in the current 
> procedures in real life cash transactions) getting "untainted" coins would be 
> quite trivial for the average teenager.
> So the system is in my opinion quite ineffective with respect to child 
> protection, but the core issue is that it will not fix the issue for the 
> merchant.
> The merchant will be forced to verify some kind of attestation from a trusted 
> authority that would also enforce the respective law if broken. In other 
> words, an attestation by the state.
> In such cases I really do not see a way around a third party attestation, 
> ideally a ZK proof over the date of birth attested by the state, which is not 
> ideal in itself...
> 
> The above only really applies if you want to address child protection 
> regulations, not "I am a parent and want to control what my kids do".
> The latter may be best addressed by your approach, but again, I would not 
> underestimate the creativeness of your average teenager ;)
> 
> my 2 cents
> 
>> On 6. Sep 2021, at 20:19, Özgür Kesim <oec-taler@kesim.org> wrote:
>>
>> 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
>>>>
>>>>
>>
>>
>>
> 

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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