Re: [Taler] [address@hidden: 'Oh, that's an idea...': U.S. parents respond to China screen time ban]

[Jeff Burdges]

> On 4 Sep 2021, at 23:32, Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>> There is however a problem of authenticating the context, but what I’d 
>> suggest there is that TLS certificates embed whatever attributes like age 
>> the site requests. In other words, if a site wants over 18 then they must 
>> say so in their TLS certificate and users not over 18 could not create 
>> anonymous identity on that site because their own browser would not do so.
> 
> And how is this supposed to work with Free software?  The user's program 
> refuses to do what the user wants; this looks suspiciously like DRM.

You’ve miss-understood what I’m saying..  There are afaik zero problems from 
these protocols being implemented in free software.  

Ring VRFs prove correctness of a context specific identifier for each user.  
Anonymity depends upon the context being correct however, so the site 
requesting an identity must first prove its own identity to the user agent, 
presumably via TLS certificate. 

Attributes are dangerous however, like you and I both said, so if one wants 
attributes then one should restrict attribute usage in some way.  Any standards 
for an “employed” attribute should be rejected for example.  You could argue 
all attributes should be rejected of course, but what happens if people reach 
consensus that they want an attribute for over 18?  

In this case, you’d want an attribute channel that nobody could broaden in 
dangerous ways.  There exists an obvious way to do this:   TLS certificates 
says which “rings” aka authentication providers they accept.  Attributes 
**sets** are represented by rings, making the number of rings aka 
authentication providers in the world is exponential in the number of 
simultaneous attributes.

If a user is under 18 then use ring that accepts under 18.  If they’re over 18 
then they could use a ring that only accepts over 18.  If the W3C wants 
attributes for “employed”, “over 18”, “homeowner”, and “medical degree” then 
they kinda need 16 different rings, which becomes unworkable fast.  

At this point, we observe that if a site accepts k rings then users could’ve k 
identities on the site, thanks to multiple-devices, open source, etc., which 
increases the site’s moderation arbitration workload, so sites have some 
incentive limit rings in their TLS certificate.

We should not leak the set of rings a user joined because this deanonymizes the 
user, assuming many rings exist, so our ring VRFs only proves the users’ 
membership in some allowed ring from the TLS certificate, but *not* which ring. 
 At this point, a website could permit both “Alice’s over 18 ring” and “Bob’s 
over 18 ring” if it wanted “over 18” and does not mind users being Sybil at 
most twice, but if it then adds “Carol’s anybody ring” then the website no 
longer gains any information about news users age! 


There is no "refusing” user requests here because the users' machines cannot 
produce impossible zero knowledge proofs. 

Your browser says 
  “This website requests user uniqueness.  You have joined ring X which they 
permit.  Do you consent to being unique on this website?” 
or sometimes
  “You currently identify yourself to this website using ring Y, which this 
website is deprecating.  You have also joined ring X which they permit in 
future.  Do you wish to transition your existing ring Y identity to ring X?  If 
yes, an anonymized ring transition certificate transparency report shall be 
published to help prevent websites from abusing the transition process.  If 
not, would you like a fresh unlinkable identity under ring X?"

In either case, saying no or no+no could result in less functionality in the 
site, like being blocked from adult content.  In particular, if an adult site 
requires membership in one “over 18” ring then users’ browser can either 
provide the ring VRF proof if the user joined the ring, or else fail to do so.. 
 no other option exists.

Jeff