§ AnonCreds Methods Registry

Registry Status: v0.1 Draft

Source Content:

https://github.com/hyperledger/anoncreds-methods-registry

Editors:

• Stephen Curran
• Hakan Yaldiz
• Sam Curran
• Victor Martinez Jurado

Participate:

GitHub repo

Commit history

Discord

§ Status of This Registry

This document is a product of the AnonCreds Working Group. It represents the consensus of the AnonCreds community.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://github.com/hyperledger/anoncreds-methods-registry.

§ Copyright Notice

This document is subject to the Creative Commons Attribution 4.0 International (CC BY 4.0) available at https://creativecommons.org/licenses/by/4.0/legalcode.

If source code is included in the specification, that code is subject to the Apache 2.0 license unless otherwise marked. In the case of any conflict or confusion within this specification between the Community Specification License and the designated source code license, the terms of the Community Specification License shall apply.

§ Introduction

The AnonCreds Methods Registry contains a list of entries that point to specifications and implementations for the publishing (registering) and retrieving (resolving) AnonCreds objects as defined in the AnonCreds Specification. The registry is managed by the AnonCreds Working Group, and is governed by the rules outlined in the Governance section of this document.

For more information about AnonCreds ZKP verifiable credentials, please see the latest AnonCreds Specification.

§ Registry

This section summarizes the AnonCreds methods currently in available. The links and status are updated by their respective implementers as they evolved, as per the registry governance rules.

The normative requirements for AnonCreds method specifications can be found in the AnonCreds Specification. AnonCreds methods that do not meet the guidelines as outlined in the method entry template will not be accepted.

§ Hyperledger Indy Legacy AnonCreds Method

The Hyperledger Indy Legacy AnonCreds method is the mechanism implemented in early Hyperledger Indy instances, prior to the implementation of did:indy support. It is unique in this registry in that its identifiers are not URIs, but instead are as defined by the original open source developers of Indy. This method is deprecated and issuers using Hyperledger Indy ledgers are recommended to use the did:indy AnonCreds method wherever possible.

• Status: Deployed
• Verifiable Data Registry: Hyperledger Indy instances
• Contact Name: Stephen Curran
• Contact Email: stephen.curran@sovrin.org
• Contact Website: Hyperledger Indy documentation
• Specification: Details can be found in Hyperledger Indy documentation on registering/retrieving AnonCreds objects

§ did:indy AnonCreds Method

The did:indy AnonCreds method uses registration and resolution methods implemented in later Hyperledger Indy clients (such as those based on Indy VDR). The did:indy AnonCreds identifiers are URIs (to be precise DID URLs with path elements to identify the specific AnonCreds object type), evolved from the identifiers used in the initial Hyperledger Indy AnonCreds implementatation. The objects are registered and resolved using the same tools as the Hyperledger Indy AnonCreds method, with the primary difference being the AnonCreds identifiers within the objects themselves.

• Status: Not deployed
• Verifiable Data Registry: Hyperledger Indy instances
• Contact Name: Stephen Curran
• Contact Email: swcurran@cloudcompass.ca
• Contact Website: https://github.com/hyperledger/indy-did-method
• Specification: https://hyperledger.github.io/indy-did-method/#other-indy-ledger-object-identifiers

§ did:web AnonCreds Method

This method defines a common way of referencing and resolving AnonCreds objects based on the security provided by did:web specification, where resources can be stored and accessed by simply using web servers and traditional databases.

It inherits the same advantages and drawbacks from did:web, such as the simplicity (which might be useful to encourage the adoption of AnonCreds) and the lack of decentralisation that a blockchain or DLT-based method can provide.

It does not enforce any particular API or implementation for object creation or storage, other than a few measures to ensure object immutability.

• Status: In Development
• Verifiable Data Registry: did:web
• Contact Name: Ariel Gentile / Patrick St-Louis
• Contact Email: a@2060.io / patrick.st-louis@idlab.org
• Contact Website: https://github.com/2060-io/did-web-anoncreds-method
• Specification: To Be Added

§ HTTP AnonCreds Method

The HTTP AnonCreds method uses HTTP URLs as AnonCreds object identifiers. For this method, the resolution is simple: dereference the URL to retrieve the published object. While this approach is fairly simple, it is not recommended for production use for a number of reasons:

• the lack of proof of immutability in the approach (although this could be alleviated through the use of hashlinks),
• the lack of a forced relationship between the issuer entity and the AnonCreds objects (such as a DID),
• the centralization of the Verifiable Data Registry and hence the possibility of surveillance by the web service operator,
• the possibility of rendering the issued credentials useless because the web service is removed by its operator, making the AnonCreds objects unresolvable.

The simplicity of this AnonCreds method may make it useful for testing. Those considering using a web server as a Verifiable Data Registry would likely be better to use an AnonCreds method based on did:web.

• Status: In Development
• Verifiable Data Registry: HTTP Web Servers
• Contact Name: Stephen Curran
• Contact Email: swcurran@cloudcompass.ca
• Contact Website: To Be Added
• Specification: To Be Added

§ cheqd AnonCreds Method

The cheqd AnonCreds method specifies how to register and resolve AnonCreds objects as general purpose resources on the cheqd.io Verifiable Data Registry. The identifiers for the resources are DID URLs that are dereferenced to return the AnonCreds objects.

The “In Development” below is the AnonCreds Method status. The cheqd.io network itself is fully deployed and operational.

• Status: In Development
• Verifiable Data Registry: cheqd Network
• Contact Name: Ankur Banerjee
• Contact Email: product@cheqd.io
• Contact Website: https://cheqd.io
• Specification: cheqd AnonCreds Object Method

§ Cardano AnonCreds Method

The Cardano AnonCreds method specifies how to register and resolve AnonCreds objects as general purpose resources on Cardano Blockchain. The identifiers used for Anoncreds Objects follow the DID-Linked Resources Specification defined at the Utility Foundry Working Group at Trust Over IP (ToIP).

This method is an effort from a collaborative working group with base on the Cardano SSI Alliance (CSSIA), and it’s composed by the Cardano Anoncreds Method specification and two reference implementations: python and TypeScript.

• Status: In Development
• Verifiable Data Registry: Cardano Blockchain
• Contact Name: Rodolfo Miranda
• Contact Email: rodolfo.miranda@rootsid.com
• Contact Website: Cardano Anoncreds WG at CSSIA
• Specification: Cardano Anoncreds Method

§ Adding a Registry Entry

To add a new AnonCreds Methods Registry entry please:

• Review the Governance section of this document that describes who can add/update registry entries, how such updates get approved and applied.
• Create a pull request in the GitHub repository (https://github.com/hyperledger/anoncreds-methods-registry) that is the source for generating this webpage, by following these steps:
  • Fork the repository.
  • In your local fork, copy the registry/method_template.md file to a new file in the same registry folder, named as appropriate for the new registry entry, prefix method_, and .md extension.
  • Update the new file for the AnonCreds Objects Methods Registry entry you are adding.
  • Update the specs.json file to include your entry within the list of methods, in alphabetical order.
  • Test your updates as outlined below.
  • Submit a pull request with your changes.

The registry source consists of the markdown files listed in specs.json and found in the /registry folder. The registry is automatically rendered as a webpage (using Spec-Up) to the /docs folder of the gh-pages branch of this repository on each pull request merge (using a GitHub Action), and then published (using GitHub Pages).

See the Governance document for information on how additions and updates to the Registry entries are processed.

§ Testing your Edits Locally

Full guidance for using Spec-Up is in its repository. The short version of the instructions to render the registry webpage locally while you are editing is:

• Install the prerequisites: node and npm
• Run npm install from the root of the repository
• Run npm run edit from the root of the repository to render the document with live updates to the docs/index.html as you edit the source files.
  • You can also run npm run render to just generate the specification file once.
• Open the rendered file in a browser and refresh to see your updates as you work.
• When you are done, hit Ctrl-c to exit the live rendering.

Please test your edits locally before you submit a pull request!

§ Governance

This registry is managed by the AnonCreds Specification Working Group. The contents of the registry is maintained in a GitHub repository and managed through a pull request submission, review and approval process. The details of how pull requests are managed is outlined in this Governance section of the registry.

§ Roles

• The AnonCreds Specification Working Group is the governing authority over this repository. Its members collaborate to approve and merge pull requests that result in changes to the Registry and the repository.

• Editors are individuals delegated by the AnonCreds Specification Working Group to process issues and pull requests according to the rules defined in the Pull Request Handling section of this document. Editors are given GitHub Maintain and Admin roles in the repository to manage their work.

• Implementers are individuals or organizations that add their AnonCreds method to the registry. Implementers MUST follow the guidelines in the Adding a Registry Entry documentation in submitting pull requests to add or update their method.

• Contributors are individuals that submit pull requests that propose changes to the registry or any part of the repository that is the source of the registry. Anyone with a GitHub account can be a contributor.

• Readers are individuals that read the registry and use the information there in to move forward their use of AnonCreds.

§ Types of Content

There are two types of content in the source repository for the registry:

• The entries in the AnonCreds Methods Registry.

  • The content of the entries are managed by the implementers of specific AnonCreds methods.
  • The format of the entries MUST adhere to the guidelines defined in the Method Template, as defined by the AnonCreds Specification Working Group.

• All other content in the registry and registry repository

  • Such content is governed by the AnonCreds Specification Working Group, and includes things like this Governance section of the registry, the format of the method entries, how the registry is published, and so on.
    • Anything about the management of the registry may be changed through an update to this type of content.

§ Pull Request Handling

The AnonCreds Specification Working Group MUST approve all changes to be merged into the registry (additions, updates and deletions) and to the rules for the management (governance) of the registry.

The AnonCreds Specification Working Group has delegated to the Editors the authority to merge pull requests of any type of content as follows:

• Based on an explicit vote of the AnonCreds Specification Working Group to merge the pull request; or
• When, in the judgement of the Editors, the change is simple editorial update that improves the content of any type; or
• When the pull request is to add or update a Registry method entry, and, in the judgement of the Editors,
  • the entry adheres to the registry entry guidelines, and
  • the links in the registry entries resolve to relevant content (e.g. the specification of the method), and
  • there is some evidence that the submitter is related or sufficiently familiar with the work being done on the method.

The AnonCreds Specification Working Group has delegated to the Editors the authority to cancel pull requests of either type of content as follows:

• Based on an explicit vote of the AnonCreds Specification Working Group to cancel the pull request; or
• When, in the judgement of the Editors, the change is spam or a mistake, or
• When, in the judgement of the Editors, the change is a simple editorial update that is either incorrect or does not improve the content

The AnonCreds Specification Working Group has delegated to the Editors the authority to raise (for discussion or vote) to the AnonCreds Specification Working Group any other pull requests. Prior to the raising of a pull request to the AnonCreds Specification Working Group for processing, the Editors (and any other contributor) may work with the submitter of the pull request to clarify and/or improve the pull request such that it fits in the categories above for merging or cancellation.