In case you missed the recent workshops for Hyperledger Aries and Indy, you can check out the recordings for both. The Build Your Identity Solution with Aries and the Hyperledger Indy Technical Deep Dive workshops are both on the Hyperledger YouTube channel.2021 Q4 Hyperledger Aries
2021 Q3 Hyperledger Aries
Aries Interop Profile (AIP) 2.0, which extends the AIP 1.0 from 2020 to achieve Aries stated goal of being both ledger and verifiable credential format agnostic
allowing for opportunities to interoperate with products and tools from other verifiable credential ecosystems. A collaborative effort (called WACI-PEx) started at the Internet Identity Workshop is bringing together teams from the W3C, DIF and Hyperledger Aries communities.
Link to quarterly Report Q1, 2021
| Project |
|
| Status | |
| CII Badge | |
| Description | Infrastructure for blockchain-rooted, peer-to-peer interactions. It provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. |
Project:
There are three major Frameworks in Aries – Aries Cloud Agent Python (ACA-Py), Aries Framework Go (AFGo) and Aries Framework .NET (AFD)
Feb 9, 2021
Hyperledger Aries
|
|
|---|
11/17
Project Health
Project health continues to improve. A minor difficulty arose as members of the Sovrin Foundation paid staff were laid off. As members of that paid staff contributed to several code projects and community coordination within the Aries project some of those efforts briefly struggled as other community sponsors were found to help support that work. That disruption unfortunately includes the timely generation of this quarterly report. Overall, the Aries project was only very lightly affected; meetings were held, major code projects continued work without interruption, and releases continued. The lack of major disruption is a credit to the health and diversity of the project and broad support of active community members.
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.
- Aries provides client tools for blockchains
- Wallets and Secrets Management
- Encrypted Messaging
- Signing and Submitting Transactions
- Edge Protocol Support
- 1.0 Interop Profile Work
- Aries RFCs
- Standardization across blockchains needing identity-related solutions
- Use cases for Aries
- BCGov's work
- Sovrin Network use cases
Key Characteristics
- A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions
- A cryptographic wallet that can be used for secure storage of cryptographic secrets and other information (the secure storage tech, not a UI) used to build blockchain clients
- An encrypted messaging system for allowing off-ledger interaction between those clients using multiple transport protocols.
- An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
- An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
- A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier.
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.
Documentation
Project Management
JIRA issues:
Repositories
https://github.com/hyperledger/aries
https://github.com/hyperledger/aries-rfcs
https://github.com/hyperledger/aries-cloudagent-python
https://github.com/hyperledger/aries-staticagent-python
https://github.com/hyperledger/aries-framework-go
All Aries repositories - https://github.com/hyperledger?utf8=%E2%9C%93&q=aries&type=&language=
Communication
Mailing List
Chat (for questions and ephemeral discussions)
Meetings
Aries Working Group
People who want to learn about or contribute to Aries should join this call. This does not replace our asynchronous collaboration, but should help us keep everyone up-to-date and moving together.
Discussion items: upcoming releases, current PRs, work that will generate future PRs, architecture changes that will impact downstream teams, project standards, best practices, design, etc.
For call details and agendas, see: Aries Working Group
Calendars
History
This repo holds Request for Comment (RFCs) for the Aries project. They describe important topics (not minor details) that we want to standardize across the Aries ecosystem.
If you are here to learn about Aries, we recommend you use the the RFC Index for a current listing of all RFCs and their statuses.
There are 2 types of Aries RFCs:
- RFCs that describe individual features (in the features folder)
- RFCs that explain concepts underpinning many features (in the concepts folder)
RFCs are for developers building on Aries. They don't provide guidance on how Aries components implement features internally; individual Aries repos have design docs for that. Each Aries RFC includes an "implementations" section and all RFCs with a status greater than
Proposedshould have at least one listed implementation.RFC Lifecycle
RFCs go through a standard lifecycle.
PROPOSED
To propose an RFC, use these instructions to raise a PR against the repo. Proposed RFCs are considered a "work in progress", even after they are merged. In other words, they haven't been endorsed by the community yet, but they seem like reasonable ideas worth exploring.
DEMONSTRATED
Demonstrated RFCs have one or more implementations available, listed in the "Implementations" section of the RFC document. As with the PROPOSED status, demonstrated RFCs haven't been endorsed by the community, but the ideas put forth have been more thoroughly explored through the implementation(s). The demonstrated status is an optional step in the lifecycle. For protocol-related RFCs, work on protocol tests SHOULD begin in the test suite repo by the time this status is assigned.
ACCEPTED
To get an RFC accepted, build consensus for your RFC on chat and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the test suite repo, it MUST list the test suite in the protocol RFC's Implementations section, at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.
ADOPTED
To get an RFC adopted, socialize and implement. An RFC gets this status once it has significant momentum--when implementations accumulate, or when the mental model it advocates has begun to permeate our discourse. In other words, adoption is acknowledgment of a de facto standard.
To refine an RFC, propose changes to it through additional PRs. Typically these changes are driven by experience that accumulates during or after adoption. Minor refinements that just improve clarity can happen inline with lightweight review. Status is still ADOPTED.
RETIRED
An RFC is retired when it is withdrawn from community consideration by its authors, when implementation seems permanently stalled, or when significant refinements require a superseding document. If a retired RFC has been superseded, its
Superseded Byfield should contain a link to the newer spec, and the newer spec'sSupersedesfield should contain a link to the older spec. Permalinks are not broken.
2021 Q3 Hyperledger Aries
Aries Interop Profile (AIP) 2.0, which extends the AIP 1.0 from 2020 to achieve Aries stated goal of being both ledger and verifiable credential format agnostic
allowing for opportunities to interoperate with products and tools from other verifiable credential ecosystems. A collaborative effort (called WACI-PEx) started at the Internet Identity Workshop is bringing together teams from the W3C, DIF and Hyperledger Aries communities.
Link to quarterly Report Q1, 2021
| Project |
|
| Status | |
| CII Badge | |
| Description | Infrastructure for blockchain-rooted, peer-to-peer interactions. It provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. |
Project:
There are three major Frameworks in Aries – Aries Cloud Agent Python (ACA-Py), Aries Framework Go (AFGo) and Aries Framework .NET (AFD)
Feb 9, 2021
Hyperledger Aries
|
|
|---|
11/17
Project Health
Project health continues to improve. A minor difficulty arose as members of the Sovrin Foundation paid staff were laid off. As members of that paid staff contributed to several code projects and community coordination within the Aries project some of those efforts briefly struggled as other community sponsors were found to help support that work. That disruption unfortunately includes the timely generation of this quarterly report. Overall, the Aries project was only very lightly affected; meetings were held, major code projects continued work without interruption, and releases continued. The lack of major disruption is a credit to the health and diversity of the project and broad support of active community members.
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.
- Aries provides client tools for blockchains
- Wallets and Secrets Management
- Encrypted Messaging
- Signing and Submitting Transactions
- Edge Protocol Support
- 1.0 Interop Profile Work
- Aries RFCs
- Standardization across blockchains needing identity-related solutions
- Use cases for Aries
- BCGov's work
- Sovrin Network use cases
Key Characteristics
- A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions
- A cryptographic wallet that can be used for secure storage of cryptographic secrets and other information (the secure storage tech, not a UI) used to build blockchain clients
- An encrypted messaging system for allowing off-ledger interaction between those clients using multiple transport protocols.
- An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
- An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
- A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier.
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.
Documentation
Project Management
JIRA issues:
Repositories
https://github.com/hyperledger/aries
https://github.com/hyperledger/aries-rfcs
https://github.com/hyperledger/aries-cloudagent-python
https://github.com/hyperledger/aries-staticagent-python
https://github.com/hyperledger/aries-framework-go
All Aries repositories - https://github.com/hyperledger?utf8=%E2%9C%93&q=aries&type=&language=
Communication
Mailing List
Chat (for questions and ephemeral discussions)
Meetings
Aries Working Group
People who want to learn about or contribute to Aries should join this call. This does not replace our asynchronous collaboration, but should help us keep everyone up-to-date and moving together.
Discussion items: upcoming releases, current PRs, work that will generate future PRs, architecture changes that will impact downstream teams, project standards, best practices, design, etc.
For call details and agendas, see: Aries Working Group
Calendars
History
This repo holds Request for Comment (RFCs) for the Aries project. They describe important topics (not minor details) that we want to standardize across the Aries ecosystem.
If you are here to learn about Aries, we recommend you use the the RFC Index for a current listing of all RFCs and their statuses.
There are 2 types of Aries RFCs:
- RFCs that describe individual features (in the features folder)
- RFCs that explain concepts underpinning many features (in the concepts folder)
RFCs are for developers building on Aries. They don't provide guidance on how Aries components implement features internally; individual Aries repos have design docs for that. Each Aries RFC includes an "implementations" section and all RFCs with a status greater than
Proposedshould have at least one listed implementation.RFC Lifecycle
RFCs go through a standard lifecycle.
PROPOSED
To propose an RFC, use these instructions to raise a PR against the repo. Proposed RFCs are considered a "work in progress", even after they are merged. In other words, they haven't been endorsed by the community yet, but they seem like reasonable ideas worth exploring.
DEMONSTRATED
Demonstrated RFCs have one or more implementations available, listed in the "Implementations" section of the RFC document. As with the PROPOSED status, demonstrated RFCs haven't been endorsed by the community, but the ideas put forth have been more thoroughly explored through the implementation(s). The demonstrated status is an optional step in the lifecycle. For protocol-related RFCs, work on protocol tests SHOULD begin in the test suite repo by the time this status is assigned.
ACCEPTED
To get an RFC accepted, build consensus for your RFC on chat and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the test suite repo, it MUST list the test suite in the protocol RFC's Implementations section, at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.
ADOPTED
To get an RFC adopted, socialize and implement. An RFC gets this status once it has significant momentum--when implementations accumulate, or when the mental model it advocates has begun to permeate our discourse. In other words, adoption is acknowledgment of a de facto standard.
To refine an RFC, propose changes to it through additional PRs. Typically these changes are driven by experience that accumulates during or after adoption. Minor refinements that just improve clarity can happen inline with lightweight review. Status is still ADOPTED.
RETIRED
An RFC is retired when it is withdrawn from community consideration by its authors, when implementation seems permanently stalled, or when significant refinements require a superseding document. If a retired RFC has been superseded, its
Superseded Byfield should contain a link to the newer spec, and the newer spec'sSupersedesfield should contain a link to the older spec. Permalinks are not broken.