Delegation Exists in The Real World, So Why Not In Our Digital Worlds … Meet Delegated Anonymous…

Delegation Exists in The Real World, So Why Not In Our Digital Worlds … Meet Delegated Anonymous Credentials (DACs)

Bob has to submit his passport for an application for a Professorship at the University of Life, but is travelling. And so he calls up the relevant government agency for his passport verification ID, and then sends this to Carol. He then asks her to print it out, and to give it to a courier to deliver. It arrives on time, and the university is happy with this verification. This is the world of trust that we live in. Bob trusts Carol and the courier to delegate things for him.

Imagine a digital world where rather than you having to continually prove your age, your address, or even the registration number of the car that you drive, that someone else that you trust can pass on the proof for you. It would be a world of trust — a bit like our real world. In a digital world, though, there is very little sense of delegation.

We give away a little too much information within our on-line world. Every time we have to prove something, we often have to give away a whole lot of information about ourselves. When I show someone my passport, they can plainly see my date of birth, and my address. This leaks information out that should be private, as all the person should see if I am a UK citizen or not, and not where I live, my age, and so on.

The same problem exists with the PKI infrastructure, and where we release the credentials of the root CA, and also the full chain of issuers in the signing process. This could release the location of the person, as one of their signers could be their employer, and where their location will be revealed in the signing chain.

Jan Camenisch [here] defines the usage of an (attribute-based) anonymous credential signing process where Bob can reveal the required credentials in a new token each time it is required. This will use zero-knowledge proof (ZKP) to prove something. For example, he may prove that he is greater than 18 years old, without actually revealing his date-of-birth. In the following case, Alice asks for proof of age, and Bob goes to a government agency that Alice trusts and gets a signed age verification attribute from the agency. Bob then converts that into a zero-knowledge proof version for his age check, and passes it to Alice. The credential will be signed with the private key of the agency, and where Alice will check this against their public key.

The problem with this is that Bob is revealing the signer of the credential, and is likely to leak information about his location (as the signer may be his local government office).

Jan also outlines this problem in permissioned blockchains, and which are private blockchains in which a number of organisations share their transactions. In the following case, the blockchain is shared by EveCo, BobCo and AliceCo. Bob is a user, and his identity is created by BobCo. His identity will thus reveal that he is an employee of BobCo, and thus leaking information about his possible location (as BobCo’s public key will be needed to prove Bob’s identity):

This problem can be overcome with the usage of a delegatable anonymous credential (DAC), and where Bob can pass his credential onto Carol, and then onto Dave, and then who can send it to Alice. Alice will receive the credential from Dave, and not from Bob. In this way, only the public key of the original signer of the credential will be revealed.

In his paper on “Practical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain” [here], Jan Camenisch outlines that DACs have been proposed in the literature, but they are often not suitable for practical use. This is mainly because the methods defined do not use attributes, and these are often the key things that we use to prove things (such as “our height, our weight, and our age). Along with this, the proposed methods have significant computational resources and signature sizes related to the generation of the zero-knowledge proofs, and where the details of the implementation is often left out of the research papers. Jan also outlines that the methods previously proposed do not integrate well with existing systems, and can only run in isolation.

With DAC, we thus hide the delegatee (Carol and Dave) and the delegator (Bob). This protects identities in the delegation process within the presentation of the credentials (as other credentials related to Bob are not revealed). Jan’s viewpoint is that the hiding of identities in the delegation process is not necessarily required, as we might want Alice to know who those delegating entities are. For him, it is the privacy in the presentation of the credential that is the most important element. For example, if we were buying a house, and we were supplying a proof of income from our bank, we might pass this proof to our solicitor, and then who passes to the solicitor of the mortgage company. The delegation chain reveals a trusted route for the passing of the credential:

Jan, though, delivers on the promise with a new method, and his viewpoint is that we can reduce a significant overhead in processing by allowing the trusted delegates to sign their delegation part:

Conclusions

We live in a flawed digital world, and which does not mirror our real world of trust. Delegation is something that is natural in our lives, but in a digital space it has little effect. Within health and social care, and many areas of our lives, we need to understand how we can delegate things, especially to reduce the ever increasing burden of having to prove things within online spaces. Our research — through the work of Will Abramson — aims to build a new world of trust, so may sure you hear his vision.

Note: This article is based on the work of Will Abramson.

[1] Camenisch, J., Drijvers, M., & Dubovitskaya, M. (2017, October). Practical UC-secure delegatable credentials with attributes and their application to blockchain. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 683–699). ACM.