Identus incubation project proposal #17
Conversation
Signed-off-by: essbante-io <103904161+essbante-io@users.noreply.github.com>
Signed-off-by: essbante-io <103904161+essbante-io@users.noreply.github.com>
| - Marcus Ubani - marcus@larissa.health | ||
|
|
||
| # Abstract | ||
| Identus provides components to develop decentralized identity solutions that adhere to widely recognized self-sovereign identity (SSI) standards. |
There was a problem hiding this comment.
As a comparison
Hyperledger Aries is your complete toolkit for decentralized identity solutions and digital trust. Issue, store and present verifiable credentials with maximum privacy preservation, and establish confidential, ongoing communication channels for rich interactions. It supports multiple protocols, credential types, ledgers and registries. It has frameworks in multiple development languages, and interoperability tools and profiles to help everything work together seamlessly.
Distinguishing between Aries and Identus could be a challenge. What are the reasons for not bringing the code base into Aries? This is something that we will need answered in this proposal (not in the abstract, but this is something that I will be looking for as I review this proposal).
There was a problem hiding this comment.
Identus was conceived as a standalone set of tools. It effectively takes from Aries specs, but it wasn't designed as an extension to Aries functionalities but rather an implementation of the specs using different technologies. Additionally, Aries and Identus are not interoperable, mainly due to a difference in the DIDComm version. Aries uses DIDComm v1, while Identus only supports DIDComm V2. I must highlight that there may be additional complexities in achieving compatibility, but the DIDComm versioning is the first hurdle.
So, our viewpoint is that it will be confusing to have components under the Aries umbrella that are not compatible with the rest of the Aries code base, while the Identus set of components works in conjunction as it is; therefore, It would be more logical to consider Identus as a standalone project.
HIPs/incubation/identus.md
Outdated
|
|
||
| Identus builds upon the foundational protocols defined in Hyperledger Aries RFCs, which provide secure communication and verifiable credential exchange standards. While adhering to these Aries standards, Identus offers a distinct implementation using the Scala programming language, which aligns with other Aries-inspired frameworks such as AcaPy (Python) and AFJ (JavaScript). | ||
|
|
||
| A key difference lies in Identus' emphasis on DIDComm v2, the latest version of the DIDComm messaging protocol, while many existing Aries implementations currently focus on DIDComm v1. |
There was a problem hiding this comment.
Is the work done here something that could be contributed to Aries? Specifically, is there a library that could be utilized by Aries implementations?
There was a problem hiding this comment.
Is the work done here something that could be contributed to Aries?
Due to the above reasoning, I can't think of any component that can be directly contributed to Aries.
Specifically, is there a library that could be utilized by Aries implementations?
None at the moment. If Aries adopts DIDComm v2, the Identus Mediator could most likely be used by Aries implementations with little effort.
|
|
||
| ## Collaboration Opportunities | ||
|
|
||
| Identus and Aries hold the potential for valuable collaboration. Identus' experience with DIDComm v2 could aid in its adoption within Aries. Additionally, exploring the integration of Aries Askar as a secure storage and key management solution for Identus could prove beneficial. |
There was a problem hiding this comment.
Has any work been done on this collaboration while in Hyperledger Labs?
There was a problem hiding this comment.
No, these are simply items that have been identified as potential starting points for collaboration engagement
| When selecting a framework for decentralized identity solutions, consider the following factors: | ||
| - Programming Language Preference: Although writing business logic can be done in any language, if your development team favors Scala (JVM) based backends, Identus offers a natural fit. On the other hand, Aries provides implementations in Python and JavaScript, among others. | ||
| - DIDComm Version: If your project's requirements necessitate DIDComm v2, Identus would be the more suitable choice. | ||
| - Community: To determine whether Identus and Aries suit your project, you must evaluate the community composition. Although Identus aims to be VDR agnostic, it has a more substantial presence within the Cardano communities due to its association with IOG, which offers better synergies for use cases that target the Cardano ecosystem. |
There was a problem hiding this comment.
What other VDRs does Identus support besides Cardano?
There was a problem hiding this comment.
At the moment, only Cardano. The plan is to improve the design to provide an interface so that the adoption of other VDRs can be done by implementing the interface
|
|
||
| Beyond the components presented here, the proposal extends to other features we plan to develop. | ||
|
|
||
| # Solution |
There was a problem hiding this comment.
Is there an architecture diagram available showing how all of these different components fit together?
There was a problem hiding this comment.
I added a diagram to the proposal.
|
@essbante-io : Thank you for the proposal. When were you thinking you would like to present this to the TOC? Would April 4th work for you and the team? |
There was a problem hiding this comment.
LGTM with the assumption that @tkuhrt 's comments will be addressed sufficiently.
It is a very frequent question projects get that go like "So how does X is different from Y, they sound like they are might be doing roughly the same thing" so we definitely have a good answer to that. :-)
Co-authored-by: Tracy Kuhrt <tracy.a.kuhrt@accenture.com> Signed-off-by: essbante-io <103904161+essbante-io@users.noreply.github.com>
Signed-off-by: essbante-io <103904161+essbante-io@users.noreply.github.com>
|
@tkuhrt, Thanks for reaching out! I apologize for the delay, I was on holiday last week. I've added my responses to the comments on the PR, and April 4th would work well for us to present this to the TOC. |
|
Great! I have scheduled the discussion for April 4th. |
No description provided.