Hyperledger Aries and Aries Interop Profile
Initially, Credo was built as an Hyperledger Aries framework, focusing on implementing the Aries RFCs and supporting the Aries Interop Profile.
Support for Hyperledger Aries, DIDComm and AnonCreds is at the core of Credo, and thus if you're building an identity solution supporting these standards, Credo is a great fit.
Aries Interop Profile
Credo currently has full support for Aries Interop Profile 1.0 (AIP 1) as well as most of the features from Aries Interop Profile 2.0 (AIP 2)
The following table lists which parts of AIP 2 are supported by Credo:
| Feature | Support | Notes |
|---|---|---|
| Base Requirements | ✅ | |
| Mediator Coordination | ✅ | |
| Indy Based Credentials | ✅ | Also support for the newer ledger-agnostic AnonCreds attachment format |
| JSON-LD Based Credentials | ✅ | |
| BBS+ Based Credentials | ✅ | |
| Chat related features | ✅ | |
| DIDCommm v2 Prep | ❌ |
Additional Aries RFCs
In addition to the Aries RFCs listed by the Aries Interop Profile, Credo also supports the following Aries RFCs:
| Aries RFC | Support | Notes |
|---|---|---|
| Aries RFC 0212 Pickup V1 | ✅ | |
| Aries RFC 0685 Pickup V2 | ✅ | |
| Aries RFC 0721 Revocation Notification V2 | ✅ | |
| Aries RFC 0771: AnonCreds Attachment Format | ✅ | |
| Aries RFC 0794: DID Rotate V1 | ✅ |
Divergence from Aries RFCs
Although Credo tries to follow the standards as described in the Aries RFCs as much as possible, some features in Credo 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 Credo 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 Credo. 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. |