## Add support in Aries Framework JavaScript and Aries Bifold for Hyperledger AnonCreds using the W3C Verifiable Credentials Data Model Standard
### About the team
- **Ariel Gentile** (Github Id [genaris](https://github.com/genaris)) is an experienced electronics engineer focused on digital identity and authentication systems. He has been contributing in several open source projects under the Hyperledger umbrella, including [AnonCreds RS](https://github.com/hyperledger/anoncreds-rs), [Aries Askar](https://github.com/hyperledger/aries-askar) and [Aries Framework JavaScript](https://github.com/hyperledger/aries-framework-javascript), of which he is an active maintainer.
He is co-founder and CTO of [2060.io](https://2060.io/), a full stack set of tools that aim to use DIDComm and Verifiable Credentials at large scale, connecting end users and businesses in a secure, private yet efficient and user friendly manner, providing an experience not different from mainstream messaging apps.
In the past year he designed a number of DIDComm protocols, and currently is an active participant of DIDComm User Group and Aries Working Group.
He has also contributed to [Aries Agent Test Harness](https://github.com/hyperledger/aries-agent-test-harness) and has a solid background for validation and testing of embedded systems such as medical devices and smart cards.
- **Patrick St-Louis** (Github Id [PatStLouis](https://github.com/PatStLouis)) is a DevOps specialist with a background in cybersecurity. His field of expertise is digital identity. He attends multiple OpenSource working groups meeting from foundations such as Hyperledger, W3C, DIF and OWF.
He previously demonstrated interoperability between the AnonCreds v1 specification and the VC-API/CHAPI protocols using did:web and the W3C Data Model. He is also a co-author of the did:web AnonCreds method and currently working on a project Fast-Anoncreds, a web API for creating storage-agnostic AnonCreds resources.
He currently works for IDLab where he gets to experiment with open source projects with a focus on test-suites and test-harnesses. He takes pride in demonstrating his creativity by exploring cross framework interactions, trying to facilitate collaboration of different working groups.
### Proposal overview
In this section we will summarize some of the most important topics we have identified in order to accomplish this CWU opportunity goals.
#### AFJ Credential storage
In its current release (0.4.2), Aries Framework JavaScript does include support for both AnonCreds and W3C credential records, which at the moment are used in DIDComm and OpenId4VC flows respectively. Given the (up to now) differences between both formats, they are treated separately in the storage and agent API (there are `AnonCredsApi` and `W3CCredentialsApi` to manage them). In case a consumer app wants to show all stored credential, it must either show them separately or convey both record types into their common data for display.
Making AnonCreds compatible with W3C may allow to store and manage all credentials through the `W3CCredentialsApi`, while still being able to handle them from `AnonCredsApi` for compatibility with existing consumers and flows. Some extensions in terms of metadata and tags would be needed in order to allow for efficient searches.
#### AFJ Credential exchange
If we consider that the tasks related to credential format conversion and configuration will be managed by `anoncreds-rs` (and its wrappers), we identify credential exchange as the main challenge for `aries-framework-javascript`: the framework currently supports issuing and receiving credentials in JSON-LD format through Issue Credential V2 DIDComm protocol and [Aries RFC 0593](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md): we have been recently testing interoperability between latest versions of ACA-Py and AFJ and they succeed in completing this flow. However, it is not yet the case for proof exchange.
The framework does support Present Proof V2 DIDComm protocol, which allows using different attachment formats. At the moment, both legacy Indy and AnonCreds are supported. In order to present W3C credentials it feels natural to use DIF Presentation Exchange attachment format as defined in [Aries RFC 0510](https://github.com/hyperledger/aries-rfcs/blob/main/features/0510-dif-pres-exch-attach/README.md), already supported in ACA-Py.
There is some ongoing work in a development branch to support DIF PEX, which must be deeply tested and updated to match current AFJ architecture and latest version of the libraries from Sphereon it relies on.
We think that, apart from creating a proper test suite within Aries Framework JavaScript for these flows, it will be useful to perform some updates in AFJ backchannel for [Aries Agent Test Harness](https://github.com/hyperledger/aries-agent-test-harness) in order to be able to test JSON-LD credential issuance and proof presentation, at least in those tests that are using legacy connection protocol (as most tests are using DID Exchange protocol, and ACA-Py currently uses unqualified dids while AFJ uses did:peer:1).
#### Bifold updates
Bifold currently makes use of proof exchange and credential exchange records to access the credentials in the wallet. This approach can be extended to credentials whose format is different from "legacy" Indy/AnonCreds, as the same DIDComm protocols will be used (which create the `Credential Preview` required for display). The Agent must be instantiated with the JSON-LD Credential Format Service and the (yet to be implemented) JSON-LD Proof Format Service supporting DIF PEX.
#### Coordination with AnonCreds Rust and ACA-Py CWU opportunities
We believe it will be crucial to have a good communication with those who are assigned to the other two opportunities:
- With the ones implementing `anoncreds-rs` updates it will be important to foresee the required API updates in their JavaScript wrapper in order to allow a comfortable usage from within Aries Framework JavaScript. Our team has good knowledge of the JS wrapper, as Ariel was one of the ones who wrote its main API since the times of indy-credx and also the one who wrote `@aries-framework/anoncreds-rs` module (its main consumer nowadays)
- With the ones implementing ACA-Py updates, first of all, we will need to agree on the credential exchange protocols to be used (as previously discussed, it will be most likely Issue Credential V2/Present Proof V2 with DIF PEX attachment format) and coordinate end-to-end testing through the development process, ideally by using the Aries Agent Test Harness. This might represent some extra effort (mostly due to the issues with DID Exchange myarnentioned before) but it will certainly give benefits for the whole Aries community
- We think it will be interesting for the three participants to follow the phase 1, so all can review the AnonCreds data model structure and anticipate issues that may arise with it. As Patrick is an active member of W3C-CCG, we can help on the exchange of peer reviews with that community.