CitizenKey

One issue that is particularly important to pay attention towards is the issue of not only the necessity of blinding but on doing blinding right. Blinding is essential to separate context so security control can stay decentralized with each stakeholder.

But we can do blinding wrong.

If we create ZKF (zero-knowledge keys and architecture) that can be reused, we design the need for revocation into structures and thus the need for data retention to ensure revocation.

Beyond the fact that it is security-wise destabilizing and behavioral unrealistic to design tech with such massive dependencies, we should not neglect the fact that in EU, data retention is illegal.

This problem deserves more scrutiny but it is - for now at least - a scientific showstopper for building identity and security on blinding-at-use and long-lived keys.

Restriction at issuance can avoid the problem

It was more than enough to make us rethink and design differently. This problem can be entirely avoid if we restrict use at time of issuance and thus ensure graceful degradation, i.e. so we don't have to do anything as system security adapt automatically over time.

U-Prove is based on the principle of Blinding-at-Issuance which is the one of the main reason to chose this approach over any other.

Blinding-at-issuance do not accept reuse of keys and therefore key management becomes more complex, but that is a cheap price to pay to avoid built-in data retention and trustworthy security.

Identity is context and context require integrity

The implication of the above is two very direct problems.

1. Blockchain is a deliberate failure by design
2. DID is missing the point

In connection with 1)

In the blockchain model, accounts and identity is incorporated into an only heavily redundant ONLINE database with long-lived and reusable keys.

The stupidity and unrealistic redundancy is from a computer science perspective an obvious failure that will and have very fast lead to managed accounts where some entity is in control and blockchain is just the back-end synchronization tool for a "cloud" database. Even more when the control cartels and authoritarian governments take control through permissioned blockchain that is fully negating all claims of "decentral". Blockchain is just a cloud database where some try to build blinding-at-use on top of this structure, i.e. bad on bad.

This simple fact is of course - as all other problems - ignored in the unilateral marketing for blockchain

But in our opinion, the real problem is that not even permissionless blockchains can get around the same fundamental problem that trying to build a structure of blinding-at-use applying reuse of long-lived keys in an online database is simply a fatal flaw that cannot be accepted.

In connection with 2)

DID is just another failed cartel standard

The above also reflect on DID (https://www.w3.org/TR/did-core/) which is essentially an attempt to design the problem into standards.

DID builds on the notion of atomized proofs and thus that each identity element has to stand on its own.

Problem is that identity does not work like that. Trustworthy Identity has to it the context with integrity and thus require a full set of constructs to get the balances right. If identity is atomized, then this integrity is not only bordering impossible, you also create a divide-and-conquer where horizontal infrastructure can cherry-pick the elements that they want to control citizens and markets while ignoring the empowering elements that are the essential part of trustworthiness.

CitizenKey policy and design

Whereas we all realize the need for identity standards, they are also dangerous - standardizing in a way that does not work or ensure empowerment is working against the purpose and just feed control to central infrastructure (including surveillance capitalism and authoritarian state) which is already the main problem.

So - for now - our public policy is this:

We will not rely on nor feed any structure based on reuse of long-lived for identity or security. It is our stated policy that such structures wether based on PKI or blockchain are the problem which need to be designed-out of infrastructure.

This explicitly mean that we consider all blockchain as cloud and thus inherently untrustworthy. Blockchain accounts need to be isolated BELOW blockchain, i.e. each account must be wrapped and isolated in a trustworthy security container with ZERO dependency on third party security proofs.

This explicitly means that we will not rely on nor feed DID-structures and instead focus on the identity level. We consider identity as something that must be under personal control and thus the control of the collection and integrity of ZKF proofs. Most of the work on identity and security is about compensating for bad standards such as PKI, 4G, EMV etc. - it would be stupid to address this by building-in the next technology failure by relying on DID.