HIP-22: ZKP-based Selective Attribute Disclosure in the DID SDK

Author	Maurizio Binello, Tim McHale
Discussions-To	https://github.com/hashgraph/hedera-improvement-proposal/pull/806
Status	Stagnant ⓘ
Needs Council Approval	No ⓘ
Type	Standards Track ⓘ
Category	Application ⓘ
Created	2023-09-13

Abstract

Hedera’s DID SDK supports creation of Verifiable Credentials “VCs” containing any specific set of credential attributes. Unfortunately, all attributes within that VC are implicitly exposed to a relying party when the subject needs to authenticate any one attribute. It is possible to work around this limitation by issuing multiple VCs containing subsets of the attributes, but this is somewhat inefficient.

Rationale

Emergence of zero-knowledge proof technology presents a possible mechanism to address this type of requirement by proving one or more facts about a credential without disclosing the credential itself. Specifically, the zk-SNARK (zero-knowledge Succinct Non-interactive ARgument of Knowledge) form of cryptography supports proof of possession of information without revealing that information.

The intent of this HIP idea is to propose this technique as a more elegant means to address selective disclosure of VC attributes. In the short term, the goal is to add an optional component to the DID SDK to support this functionality when appropriate.

With community agreement it may also become possible to extend the scope to encompass selective disclosure (in general) to the W3C DID specification.

Detail

Although the capability to prove the authenticity of attribute values is critical, it is highly desirable to be able to prove statements about attributes as well.

As an example, a driving license credential can be used to prove many things, such as address, date of birth, age, and permission to drive within a specified geography. It is commonplace to use a driving license to prove age to purchase controlled merchandise, but it should not be strictly necessary to disclose one’s name, address, or even date of birth to prove that one is over the age of 18. This can be achieved already using the Hedera DID SDK, but would require a subject to request a new VC (for this exact purpose) from the Issuer - in this case the licensing authority.

Simplified process (as-is)

Note: The process described below is a simplified illustrative subset of the real VC process and is not intended to represent all of the underlying complexities.

• White-listed issuers have known public keys. In our example, the issuer is the driving license authority.
• A subject requests a VC from an issuer. In the example, this would be a driver asking the authority to issue a digital equivalent of a driving license in the form of a VC. To do this, the driver has to authenticate with the authority and provide a public key.
• The issuer (a.k.a. authority) then signs a DID document encapsulating the data representing some or all of the license, resulting in a specialised form of cryptographic hash that is provided to the subject/driver.
• When the driver/subject is asked to prove anything demonstrated by the attributes withing the DID document, they can do so by providing this hash and the DID document itself. The relying party (verifier) can prove incontrovertibly that the hash was generated by the real issuer using their known public key.

Changes and Additions required for the proposed process

1. Strictly ordered organisation of attribute data and defined data-types within the DID document. The attribute values in the document should be considered as the leaves of an “Attribute Merkle tree”. This structure should be acceptable to the DI community and sufficiently generic to satisfy all significant use cases.
2. During the issuing process, the issuer would be required to sign the root of the above Merkle tree.
3. Known statement e.g. “age > 18 at current date” that is useful to be able to prove, as well as associated cryptographic keys: proving key and verification key. This known statement is commonly known as a “circuit” in the context of ZKP. Each circuit is dependent upon the mapping of the attributes to the Merkle tree representation of the DID document defined within point 1.
4. The proof will be verified against the Merkle root associated with a DID document, signed by the issuer/authority, and against the Verification Key for the specific statement. There may be additional parameters (known as “public inputs”) required - e.g. today’s date for age > 18

Specification

Technical Considerations

• It is necessary to define an upper-limit on the number of attributes that can be mapped to the Attribute Merkle tree within any given DID document.
• The Merkle tree needs to use a Snark-friendly hash function (e.g. Poseidon).
• A proving system and associated curve must be selected. Perhaps a R1CS based proving system (large implementation of circuits), that does not require a trusted setup, such as Marlin with dLog polynomial commitment. A pair of curves in a cycle would allow some level of recursions for future expansion. e.g. the Pasta Curves.

Next Steps

• Socialise this idea with the Hedera community as well as the wider DI community

• Identify (through community discussion) a set of typical/common use-cases for selective disclosure, such as:

  • Age > 18
  • EU residence status
  • Proof of vaccination
• It may be sensible to build an open-source repository of circuits associated with the most common use cases, with their corresponding proving keys and verification keys. It would, of course, be preferable to take advantage of existing repos that aim to meet this same requirement.

Backwards Compatibility

Everything described herein must be modular and optional. None of the proposed changes may impact solutions using the current version of the DID SDK.

Security Implications

Community comment is welcome here. As a minimum, the proving system and Snark-friendly hash function should be reviewed from a security/cryptography perspective.

Reference Implementation

TBD

Rejected Ideas

None as yet.

Open Issues

Nono as yet.

References

TBD

Copyright/license

This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

Citation

Please cite this document as: