§ AnonCreds Methods Registry

Registry Status: v0.1 Draft

Source Content:

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

Editors:

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.

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.

§ 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.

§ did:prism AnonCreds Method

The did:prism AnonCreds Method specifies how to register and resolve AnonCreds objects as general purpose resources through the PRISM DID Method. The identifiers for the resources are DID URLs that are dereferenced to return the AnonCreds objects.

This method is defined upon the PRISM DID Method, however, it can be implemented on top of any DID method that supports services.

§ 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.

§ 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 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.

§ 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.

§ 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.

§ Adding a Registry Entry

To add a new AnonCreds Methods Registry entry please:

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:

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

§ Types of Content

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

§ 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:

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

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.

Table of Contents
undefined