Aries Framework JavaScript

Features  |  Getting started  |  Contributing  |  License

Aries Framework JavaScript is a framework written in TypeScript for building SSI Agents and DIDComm services that aims to be compliant and interoperable with the standards defined in the Aries RFCs.

Features

Some features are not yet supported, but are on our roadmap. Check the roadmap for more information.

• ✅ React Native
• ✅ Node.JS
• ✅ Report Problem Protocol (RFC 0035)
• ✅ Issue Credential Protocol (RFC 0036)
• ✅ Issue Credential Protocol V2 (RFC 0453)
• ✅ Present Proof Protocol (RFC 0037)
• ✅ Basic Message Protocol (RFC 0095)
• ✅ Connection Protocol (RFC 0160)
• ✅ Out of Band Protocol (RFC 0434)
• ✅ DID Exchange Protocol (RFC 0023)
• ✅ Mediator Coordination Protocol (RFC 0211)
• ✅ Indy Credentials (with did:sov support)
• ✅ HTTP & WebSocket Transport
• ✅ Connection-less Issuance and Verification
• ✅ Smart Auto Acceptance of Connections, Credentials and Proofs
• 🚧 Receiving and Verifying revocable Indy Credentials
• 🚧 W3C Linked Data VCs, BBS+ Signatures
• 🚧 Multi Tenancy
• ❌ Browser

Packages

Package	Version
@aries-framework/core
@aries-framework/node
@aries-framework/react-native

Getting Started

Documentation on how to get started with Aries Framework JavaScript can be found at https://aries.js.org

Publish new packages (SICPA's fork)

See docs here

Demo

To get to know the AFJ flow, we built a demo to walk through it yourself together with agents Getter and Faber.

• Demo

Divergence from Aries RFCs

Although Aries Framework JavaScript tries to follow the standards as described in the Aries RFCs as much as possible, some features in AFJ slightly diverge from the written spec. Below is an overview of the features that diverge from the spec, their impact and the reasons for diverging.

Feature	Impact	Reason
Support for imageUrl attribute in connection invitation and connection request	Properties that are not recognized should be ignored, meaning this shouldn't limit interoperability between agents. As the image url is self-attested it could give a false sense of trust. Better, credential based, method for visually identifying an entity are not present yet.	Even though not documented, almost all agents support this feature. Not including this feature means AFJ is lacking in features in comparison to other implementations.
Revocation Notification v1 uses a different thread_id format ( indy::<revocation_registry_id>::<credential_revocation_id>) than specified in the Aries RFC	Any agents adhering to the revocation notification v1 RFC will not be interoperable with Aries Framework Javascript. However, revocation notification is considered an optional portion of revocation, therefore this will not break core revocation behavior. Ideally agents should use and implement revocation notification v2.	Actual implementations (ACA-Py) of revocation notification v1 so far have implemented this different format, so this format change was made to remain interoperable.

Contributing

If you would like to contribute to the framework, please read the Framework Developers README and the CONTRIBUTING guidelines. These documents will provide more information to get you started!

The Aries Framework JavaScript call takes place every week at Thursday, 14:00 UTC via Zoom. This meeting is for contributors to groom and plan the backlog, and discuss issues. Meeting agendas and recordings can be found here. Feel free to join!

Comparison with upstream

This document provides key differences between Sicpa fork and upstream repository Aries Frameworks.

Additions in Sicpa Fork

• Packages for NFC and IPC transports.
• DIDComm V2 support:
  • Reworked Message Sender / Mesasge Receiver to support both types of messages DIDComm V1 and DIDComm V2.
    • DIDComm V1 has not been tested for a while. It may be broken, but there should not be difficult issues.
    • DIDComm V1 messages are still used for old V1 protocols like connection, issuance, verification. In the future, these protocols potentially can be adopted for DIDComm V2as well.
  • Added Key Service - an extra layer for keys generation, management, and storing into collection (Libindy wallet API is used as for other AFJ collections).
    • In the upstream (DIDComm V1) keys are fully managed by Libindy. But libindy does not provide an ability to get private part of a key.
    • In order to integrate DIDComm V2 packing library we have to resolve and pass private part of the keys.
  • Added DID Service - managing DIDs. The same reason as for Key Service - for DIDComm V1 DID's are completely managed by Libindy.
• Out-of-Band module - according to DIDComm V2 specification it seems to be a proper way exchange DIDs (create invitations and accept Contacts).
• Connection: DIDComm V1 protocols (like issuance, verification) depends on the Conenction module.
  • There is Connection protocol which is used for establishing of secure communication channel between parties.
  • Other protocols requires passing Connection for protocol execution.
  • For DIDComm V2 we just pass DID's directly.
• Message handlers for Value Transfer and Gossip modules for handling our protocols.
• Adopted Request Mediation protocol for DIDComm V2.
• Adopted Trust Ping protocol for DIDComm V2.

Important additions in the upstream

• Bugixes:
  • error if unpacked message does not match JWE structure
  • avoid crash when an unexpected message arrives
  • optional fields in did document
  • clone record before emitting event
  • initial plugin api
• Features:
  • Supported Postgres wallet type
  • Present proof as nested protocol
  • Supported advanced wallet query
  • Supported new did document in didcomm message exchange
  • add settings to control back off strategy on mediator reconnection
  • DIDComm V1 protocols:
    • Supported Out-of-Band DIDComm V1 protocol.
    • Supported Action Menu DIDComm V1 protocol.
    • Supported Question Answer DIDComm V1 protocol.

License

Hyperledger Aries Framework JavaScript is licensed under the Apache License Version 2.0 (Apache-2.0).