Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This document is for the Hyperledger TSC to use in considering whether to have Hyperledger Aries exit incubation status. This document assumes the reader has some knowledge of Hyperledger Aries, the  concept of Trust over IP (ToIP) and the role that Hyperledger Aries plays at Layers 2 and 3 of the ToIP stack. Aries is not a blockchain, but rather a set of protocols and implementations that enable secure communications and the use of verifiable credentials based on Decentralized Identifiers (DIDs) and related public keys that are often stored on blockchains. Aries evolved from work in Hyperledger Indy and some (but not all) implementations depend on both Indy and Hyperledger Ursa, but those are not required for Aries.

Hyperledger Aries was formed in May, 2019 based on this proposal. 

Project Structure

There are four key types of open source elements in the Hyperledger Aries project, as outlined below.

Aries RFCs

Aries RFCs, managed in the aries-rfcs repo and the primary output of the Aries Working Group, is a set of interoperable protocols that define the interaction between Aries agents, regardless of the implementer or deployer of the agents. The Aries Interoperability Profile (AIP) RFC defines how a set of Aries RFCs (each at a specific version/commit) describe an interoperability target for separate implementations. AIP 1.0 was approved in January, 2020 and has been implemented by many organizations across the world. AIP 2.0 has been proposed and the Aries Working Group is currently discussing it's final contents and structure.

Aries Frameworks

Aries Frameworks are open source implementations of the Aries RFCs that can be used to build an Aries Agent. The frameworks implement the Aries interactions with ledger and other agents, and provide an interface to a controller that implements the business logic for a specific agent use case. For example, in a mobile verifiable credential wallet built on Aries, the controller is a User Interface to allow the user to interact with other agents. In an enterprise use case, a controller might be a legacy system containing authoritative information suitable for issuance as verifiable credentials to it's subject – e.g. a database of driver's license data to be issued to drivers.

There are three major Aries frameworks and a number of other frameworks at various levels of maturity. The major implementations are:

  • Aries Framework .NET is a .NET implementation that implements AIP 1.0 that powers both major enterprise deployments (e.g. Trinsic, estatus AG, IDRamp, etc.) and a number of mobile wallets (Trinsic, estatus, LISSI and many of others). Aries Framework .NET currently implements support for Indy ledgers and Indy's AnonCreds verifiable credential format.
  • Aries Cloud Agent Python (ACA-Py) is a Python implementation of AIP 1.0 that powers a number of major Aries enterprise deployments, including those at BC Gov, SICPA, Bosch, BMW and others. ACA-Py currently implements support for Indy ledgers and Indy's AnonCreds verifiable credential format.
  • Aries Framework Go is a pure Go implementation of (the to be finalized) AIP 2.0. Aries Framework Go maintainers (SecureKey and others) choose not to implement support for Indy (and hence, do not support AIP 1.0), but do support other DID methods (including Hyperleder Fabric-based TrustBloc and Sidetree DIDs) and W3C Standard JSON-LD verifiable credentials.

There are also a number of other language-based Aries open source frameworks (JavaScript, Ruby, Java). The Aries VCX framework is a Rust implementation recently derived (by ABSA) from the Indy-SDK. Aries Mobile Agent Xamarin (Aries-MAX) is an open source mobile wallet that is built on Aries Framework .NET.


  • There are Aries common components that can be used (or not) within each of the Aries Frameworks.


Aries Status Against Project Exit Incubation Criteria

Minimum requirements

  • Legal

    • All code has been made available under the Apache License and is free of incompatible dependencies

    • Project name has been checked for trademark issues

  • Community support

    • The project must have an active and diverse set of contributing members representing various constituencies

    • The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

    • Release plans are developed and executed in public by the community.

  • Sufficient test coverage
    The project must include a comprehensive unit and integration test suite and document its coverage. Additional performance and scale test capability is desirable.

  • Sufficient user documentation
    The project must including enough documentation for anyone to test or deploy any of the modules.

  • Alignment

    • Requirements fulfillment
      The project must document what requirements and use cases it addresses.

    • Architecture
      The project must document how it fits within the Hyperledger Architecture

    • Compatibility with other Hyperledger projects
      Where applicable, the project should be compatible with other active projects.

    • Release numbering: the project should use the Hyperledger standard release taxonomy, once that is agreed upon.

    • Project must make a release, even a “developer preview”, before graduation.

  • Infrastructure

    • Gerrit or Github repo has been created

    • Mailing lists have been created and are archived

    • Other communication means used, such as slack channels, are set up

    • Project is set up with Continuous Integration

    • All information necessary for someone to join the community and be able to start contributing is duly documented (location of repo, list of maintainers, mailing lists addresses, slack channels if used, etc) following the Hyperledger Project standard practice (CONTRIBUTING.md, MAINTAINERS.txt, etc)

  • CII Badge 
    A team seeking to graduate from incubation shall have started the CII Badge application and be nearly complete with incomplete badge requirements referenced in their graduation proposal. 100% of the applicable criteria for the CII Badge is a requirement for releasing a 1.0 of the project. That does not mean the project must have 100% of all criteria, just 100% of the applicable criteria. This is to allow for projects such as test harnesses, that have “N/A” answers for questions that don't offer that as an option.

Additional considerations

In addition to the above, requirements such as the following may be defined at the onset of the project and considered as goals to be met to exit incubation:

  • Sufficient real world use
    The project should be used in real applications and not just in demos. Because not all real applications may be discussed publicly, in such cases statements providing as much details as possible should be made.

  • Sufficient scalability
    The project must demonstrate sufficient scalability and document its scalability over various dimensions such as:

    • Maximum number of transactions per second

    • Maximum number of transactions per chain

    • Maximum size of a block

  • Minimum test code coverage expected, such as, for example:

    • Minimum coverage for Security & cryptography

    • Minimum coverage for other functionality

    • Minimum coverage for Business logic/smart contract

  • No labels