gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] W3C Verifiable Claims WG approved


From: Jeffrey Burdges
Subject: [GNUnet-developers] W3C Verifiable Claims WG approved
Date: Fri, 21 Apr 2017 13:43:10 +0200

We mentioned EME (evil) and Solid (incompetent) recently, so I figured I
let folks know about the W3C's "Verifiable Claims Working Group".
https://www.w3.org/2017/vc/

I've raised my concerns on their github issue tracker here : 
https://github.com/w3c/verifiable-claims/issues/1


It not quite a government identity scheme for the web yet because they
removed browser-based APIs.  If its original incarnation had taken off,
then it could be used to require you to give your real name and provide
proof with a government id just for wifi access with captive portals.

Their original publicity indicated non-identifying use cases, like you
might prove your age without proving your identity, but digital
signatures do not usually work that way. 

An ECDSA or EdDSA signature includes a unique nonce, and RSA signatures
must cover a unique message, so even if the message says nothing about
you, the signature itself still links all your interactions across all
web sites.  


As a rule, signatures that breaks this linkage is an open problem
problem in cryptographic research.  Two working approaches : 

- Ring signatures provide anonymity to group members, but group members
cannot be added or revoked, making it an unlikely target here.  Bryan
Ford's DEDIS group at EPFL has a scheme for proof-of-person-hood
parties, but it requires organizing real parties periodically to work:
https://pop.dedis.ch/ 

- Single-use signatures avoid the problem by never reusing the same
message twice.  Blind signatures, as in Taler, are single-use signatures
where the signer cannot identify the message they signed.  There are
single-use token schemes that do not count as signatures too, like
CloudFlare's new approach to CAPTCHAs for Tor users.


I mentioned all this early during their formation.  I felt ignored but
maybe those complaints helps keep browser APIs out of this WG.

Best,
Jeff


Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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