| hip | title | author | working-group | type | category | needs-council-approval | status | created | discussions-to | updated |
|---|---|---|---|---|---|---|---|---|---|---|
762 |
AnonCreds Verifiable Data Registry |
Sumabala Nair (@sumapnair-ibm) |
Jack Hsu (@jackhsu-boeing) |
Standards Track |
Application |
false |
Review |
2023-07-10 |
2023-08-04 |
AnonCreds, short for Anonymous Credentials, refers to a system for issuing and verifying credentials while preserving the privacy and anonymity of the credential holder. This technology has applications in various fields, including identity management, digital privacy, and secure authentication. This HIP defines and discusses a way to support the issuance of AnonCreds Credentials using the Hedera ledger as the Verifiable Data Registry.
The AnonCreds (Anonymous Credentials) specification is based on the open source verifiable credential implementation of AnonCreds, which has been widely used since 2017 as part of the Hyperledger Indy and now the Hyperledger AnonCreds project. It is based on the concept of zero-knowledge proofs (ZKP), which allow the verification of certain statements without revealing any sensitive information. AnonCreds enable individuals or entities to present verifiable credentials to prove specific attributes about themselves without disclosing unnecessary personal details. It has become the de facto standard for ZKP-based verifiable credentials globally, The Hyperledger AnonCreds 1.0 specification eliminates the need for dependency on Hyperledger Indy by removing any prerequisites related to the storage of AnonCreds objects. Ongoing implementation efforts aim to expand AnonCreds support to did:web (Verifiable Data Registries residing on a well-known web domain) , HTTP (using HTTP URLs as object identifiers) as well as other ledger technologies (cheqd.io and Cardano implementations for AnonCreds Verifiable Data Registry).
The objective of this HIP is to be able to build SSI solutions with Hedera as the Verifiable Data Registry and in the future support migration of current pilots / older implementations to the Hedera network as needed. Enabling AnonCreds support on the Hedera network offers organizations and entities developing Self Sovereign Identity (SSI) solutions the opportunity to leverage the exceptional benefits provided by the Hedera Hashgraph Ledger. Since AnonCreds is being re-architected to be ledger / data store agnostic for public artifacts, extending support for this implementation will encourage wider adoption of Hedera as the Verifiable Data Registry and promote interoperability with implementations that are not on the Hedera ledger. With prominent council members such as IBM, Boeing, Standard Bank, and others expressing active interest, Hedera can serve as an ideal Verifiable Data Registry for these solutions. This HIP proposes that requisite changes be made to enable Hedera so that solution builders can choose to use Hedera as a Verifiable Data Registry for AnonCreds implementations.
- As an implementer of an SSI solution based on AnonCreds, I can leverage the superior capabilities of Hedera to persist and manage the Verifiable Data Registry.
AnonCreds enable individuals or entities to present verifiable credentials to prove specific attributes about themselves without disclosing unnecessary personal details. AnonCreds possesses several key features that establish it as a robust ZKP verifiable credentials system.
- Full implementation of the Trust over IP Model's "Trust Triangle."
- Comprehensive flows for issuing, generating, and verifying credentials.
- Well-defined data models for all objects involved in the process.
- Utilization of cryptographic primitives.
- Privacy-enhancing features using Zero Knowledge Proofs (ZKPs):
- Blinding issuer signatures to prevent correlation.
- Unrevealed identifiers for holder binding to prevent correlation.
- Predicate proofs to reduce sharing of personally identifiable information (PII) and potentially correlating data.
- Revocation scheme proving credential validity without revealing correlatable identifiers.
In SSI, and AnonCreds as an example of the same, a number of artifacts are persisted in the public domain in a Verifiable Data Registry (VDR). These include DIDs and DID Documents, public credential definitions, revocation registries and often schema definitions. These are created and persisted by the issuer in the VDR and queried by the verifier from the same.
The support for Hedera as an AnonCreds Verifiable Data Registry can be accomplished without any changes to the core Hedera platform. There are multiple approaches that can be considered to meet this objective.
Hyperledger Aries is an open-source framework for building interoperable, self-sovereign identity (SSI) solutions. It provides tools, protocols, and libraries to facilitate secure, peer-to-peer interactions, credential exchange, and identity management in decentralized systems. Aries Cloud Agents (ACAs) play a crucial role in the integration and utilization of AnonCreds within the Hyperledger Aries framework. ACAs facilitate the management and interaction with AnonCreds' anonymous credentials in cloud-based environments. These agents enable secure issuance, exchange, and verification of AnonCreds within self-sovereign identity (SSI) systems deployed in the cloud. By incorporating ACAs, developers can harness the scalability and flexibility of cloud infrastructures to effectively handle and utilize AnonCreds within their SSI solutions. ACAs come in multiple flavors, the python version, ACA-PY, probably the most popular.
The Hedera DID method aims to be W3C compliant and outlines the process to be followed for implementing Verifiable Credential solutions with did:hedera. The specification is a bit out of data with the standards, but there are HIPs approved and possibly work in progress to address most of the gaps and bring the specification to compliance with W3C standards. SDKs for did:hedera are currently available as JavaScript and Java implementations and are under review and refinement. The SDKs could be extended to support AnonCreds so Hedera can function as the VDR for such implementations.
There is a very active community around Aries, AnonCreds and the ACA implementations. Adoption is less for did:hedera and there are specification gaps. Current / potential Indy-Aries-AnonCreds implementations would benefit from extending an Aries Cloud Agent implementation to support the Hedera public ledger as the Verifiable Data Registry. Aca-py, the Python implementation of Aries Cloud Agent (ACA), has gained popularity due to its easy integration, flexibility, comprehensive functionality, strong community support, and focus on interoperability. It provides developers with the tools and capabilities needed to build and manage self-sovereign identity (SSI) solutions effectively. We recommend that as a first step, ACA-Py be extended to support the AnonCreds VDR requirements. This can then be extended to other ACAs. The DID':Hedera specification enhancements can be separately pursued and will require updates to the core did:hedera specification first. But an integration of some sort between the two in future cannot at present be ruled out.
We recommend the Cardano Anoncred Method as a reference method. Accordingly, we recommend the following:
- The identifiers used for AnonCreds Objects should follow the DID-Linked Resources Specification defined at the Utility Foundry Working Group at Trust Over IP (ToIP)
- AnonCreds Objects could adopt the following format, similar to the approach taken by Cardano: {publisherDID}/resources/{objectId}.
- In Cardano, AnonCreds objects are typically stored on the ledger as transaction metadata. The objectId associated with these objects is defined as the transaction hash of the specific transaction used to publish the metadata on the blockchain. However, considering the architecture of Hedera, an alternative approach could be to post these objects as a topic entry and utilize the topicId as a reference. This approach would allow for efficient storage and retrieval of AnonCreds objects within the Hedera network.
- The following considerations are crucial and strongly recommended to be mandatory for the implementation:
- Set the submitKey so unauthorized persons cannot update the AnonCreds object.
- Set Autorenewal information so that the topic does not automatically expire in Hedera. Ensure that the Autorenewal account also signs the transaction.
- The following considerations are crucial and strongly recommended to be mandatory for the implementation:
- A TopicMessageSubmitTransaction can be used to submit the AnonCreds objects to the Hedera network and the submitKey should sign the transaction.
- Anoncred Object structure could be similar to Cardano’s approach. The message to the topic will be a JSON object consisting of two parts - the ResourceObject and the ResourceObjectMetadata. Please see the JSON object definition here for details.
- Resource Objects could be of type SCHEMA (credential schema), PUBLIC_CRED_DEF (the public credential definition that maps the schema, the issuer's public key, and other related cryptographic parameters) , REV_REG (Revocation registry) , REV_REG_ENTRY (Revocation registry entries).
- The Cardano method suggests utilizing an Indy Tails server for receiving, storing, and serving Tails files, which play a critical role in credential revocation. Similarly, this approach can be considered for implementation in this scenario. However, it's worth noting that if a different implementation of a Tails server using the Hedera File Service, for example, is identified as a superior solution, it can be implemented at a later stage. This allows for flexibility in choosing the most suitable technology for hosting and managing the Tails files while maintaining compatibility with the overall revocation system.
ACA-Py enhancements to support Hedera as the VDR are to be identified and scoped.
A ‘Hedera AnonCreds Method’ along the lines of the Cardano implementation referenced above, with the recommended suggestions could be a starting point. There is also a Python reference implementation of the Cardano Anoncred Method that could serve as a starting point.
Some considerations:
- There could be administration /configuration changes in the context of VDRs,
- Hedera topics could be used for creating and managing the Verifiable Data Registry. DID, Schema, Credential Definition and Revocation Registry can all be managed as Hedera Topics.
- The messages to the topics should ideally not expire, expiration should be a conscious delete operation from an issuer.
- Messages to a DID topic could include DID/DID Document creation and lifecycle management. Access control to update the did document should be closely managed and possible only for the issuer, whereas the the did document should be available for public queries. Support for DID resolution is agnostic to the VDR.
- Schema creation by version and the lifecycle management of the same is to be supported. Schema editing privileges may perhaps be broader, though not open to all, based on business rules.
- Credential Definitions and edits are also the privilege of the issuer, but could be read by others.
- Creating revocation registries, publishing registry definition and revoking credentials are all limited to the issuer, whereas read permissions should be public.
- Verifiable Credentials, in any form should not be persisted to the ledger and revocation status should not be a factor of the same. This is explicitly being called out since the Hedera DID method allows hashed VCs to be persisted and status be associated to the same.
Once the solution is at the right maturity level to be shared with the broader Aries community, it is advisable to submit it to the AnonCreds Method Registry.
Aries Cloud Agents enhancements to support the evolving ledger-neutral AnonCreds specification is not in scope for this implementation as this is still being refined.
DID:Hedera enhancements if any is also not in scope and can be raised as a different HIP with potential for interoperability at a later date.
No other potential compatibility scenarios are envisioned at present.
No security implications are at present identified.
Resources that provide a general awareness of Self Sovereign Identity and AnonCreds and details with examples on the Hedera support for the same are recommeneded.
No current implementation for a Hedera AnonCreds method exists. Other References to similar extensions of AnonCreds can be found at https://hyperledger.github.io/anoncreds-methods-registry/#registry
https://hyperledger.github.io/anoncreds-spec/ https://github.com/hashgraph/did-sdk-js https://github.com/hashgraph/did-sdk-java https://github.com/roots-id/cardano-anoncreds/blob/main/cardano-anoncred-methods.md https://wiki.trustoverip.org/display/HOME/DID-Linked+Resources+Specification https://trustoverip.org/ https://docs.hedera.com/hedera/sdks-and-apis/sdks/consensus-service/create-a-topic https://docs.hedera.com/hedera/sdks-and-apis/sdks/consensus-service/submit-a-message https://github.com/roots-id/cardano-anoncreds/tree/main/reference-implementations/py https://hyperledger.github.io/anoncreds-methods-registry/#registry
This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)