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

[Schanzenbach, Martin]

> On 9. Sep 2021, at 12:01, Oezguer Kesim <oec-taler@kesim.org> wrote:
> 
> Thus spake Schanzenbach, Martin (mschanzenbach@posteo.de):
> 
>> Is it ethical for a shop to sell hard alcohol to minors if the parents
>> do not care / do not know / disagree with the law?
>> Is the shop ethically responsible to verify the age of a customer
>> before selling certain items? If yes, who sets the rules (legal age,
>> restricted items)?
>> In other words, how do you (as a shop owner) enforce it given the
>> above constraint that parents do not play along?
> 
> Hard alcohol is a good example where society might require a more strict
> age verification, and I would agree.
> 
> But there are still enough use cases for my proposal to become an
> acceptable age restriction mechanism.  The initial post from RSM to this
> thread is about online games, which seem to be a good use case for the
> proposed mechanism.  Others might be: streaming services with age
> restrictions, social networks with age restrictions, etc.
> 
> I consider the proposed extension to GNU Taler as an _additional_ tool
> that society can use for age restriction that is better in some aspects
> of privacy and control than other tools.  Other tools might be more
> appropriate or required in some situations.
> 
> I don't see how the proposal _substracts_ from the options society can
> choose from or _reduces_ the freedom of its citizens.

But is your proposal actually fit for that?
(correct me if I understood it wrong):
(1) The parent/warden cannot expect or verify that any service actually 
enforces restrictions or what they are (over 20? over 18?).
(2) The service cannot rely on parent/wardens to have tainted the coins for 
their kids.

Basically, in your proposal the service/merchant would have to define and 
signal what kind of domain-specific "tainting" it does enforce and the 
"tainter" would have to take it or leave it.
The taint is thus service-specific, subject to change and not binding unless 
you have an enforced standard (regulation).
I think your approach needs a trust basis. If you do not want this to be a 
state, it can be something else, but there is a puzzle piece missing here I 
think.

As proposed in another mail by Jacob another option is to enforce restrictions 
in the wallet/client only on a per service basis (a whitelist I would assume) 
or on a restricted good basis (difficult, requires definition and harmonization 
of "goods").

BR


> 
> -- oec

signature.asc
Description: Message signed with OpenPGP