Issuance Capabilities for our SDKs

[elribonazo]

When we initially started building the SDKS we had our main focus on the holder side, ensuring to cover all the use-cases a holder can require:

1. Connecting with other peers (Agent, Wallets) through DIDComm
2. Receive and process CredentialOffers, CredentialRequests
3. Receive and process PresentationRequests, PresentationSubmissions
4. Securely store the key, credentials and DIDComm messages (phone and browsers)

Right after, part of the team was already envisioning a future where we could move all the core logic that is needed for Issuance, Holder and Verification flows into the SDK. This directly benefits the development and maintenance of Identus.

Benefits

1. Our JVM SDK can be used for Java, android projects but also be integrated in the Cloud Agent.
2. By not splitting each implementation across different languages and projects keeping this up to date and solving issues is easier to manage.
3. Enabled custom agent solutions, either by extending the existing agent or implementing a custom solution another one using other languages, while we keep the core logic centered and secure.

Where we are

SDKS currently can process all what a holder needs to process but we also gave holders the ability to verify Credentials directly to other holders, virtually becoming verifiers.

Still the SDK's have no ability to:

1. Create and publish prism:dids on chain (as issuer would do)
2. Create and store credential schemas (as an issuer would do) in the VDR
3. Issue Credentials through DIDComm.

Proposed roadmap

1. Allowing the SDK to create and publish a prism:did directly into Cardano blockchain.
2. Allowing the SDK to Issue Credentials (without a VDR component)
3. Allowing the SDK to create, store and resolve assets from the VDR component.
4. Allow the SDK to Issue Credentials without any other Agent involved

[elribonazo]

My 2 cents

I think adding Issuance to the SDK is a really good idea, because we're basically making the SDK become a robust toolkit to implement any kind of Agent (Issuer, Holder or Verifier) making our ecosystem more diverse.

By also adding Issuance to SDK, we will also be able to migrate and transition the Cloud Agent to use the KMM SDK and make it easier to maintain, less code less bugs but also less duplicate code, interfaces, etc.
Core logic will reside in the SDK and the business logic instead will reside in the Agent.

Direct benefit

I'm also was as a side project with [DJACK], a peer to peer email service in Cardano. For this project, I'm using a peer to peer networking stack which is not available in the CloudAgent (it was never intended to be) and I had to implement many things as an Issuer, having the SDK with all the issuer part would simplify integrating a lot!

[FabioPinheiro]

I'm also in favor of this. On my point of view, I see SDKs as a library or framework that will fulfill the web3 use cases.
I believe the Cloud Agent is it great tool/service to help integrate more traditional backend service with new web3 paradigm and SSI.

So both are very important in my opinion.

[mixmix]

Matou's work involves building tools that our Maori communities can spin up and run themselves. The biggest barriers to entry to this space have been the costly centralized infrastructure - it is hard and expensive for small communities to run their own "Cloud Agent" ... let alone running it in a way that we're confident that their authorship of core identity is safe (i.e. assuredly in their control, and free from vulnerabilities of dependence of foreign cloud infrastructure). Identity is a very important and dangerous topic for Indigenous people who have been marginalized by colonisation (had "identity systems" used against them), so we must get this right.

While this introduces some challenges, our commitment to pursuing "easy to run" infrastructure through building p2p systems has proven that it is possible for Maori to host and run powerful and ultra-resilient infrastructure. Resilient to vendor-lock ins, resilient to price fluctuations, connectivity fluctuations, natural disasters.

The future we're building sees Identus as a key part of what we're doing. For that Identus needs to evolve in this direction, and we're excited for everyone to share in the benefits of this cutting edge, and radically democratising approach 🙏

[mixmix]

By not splitting each implementation across different languages and projects keeping this up to date and solving issues is easier to manage.

Can you speak to this? (I'm unsure if you're saying "yay all our code can share the same libraries" or "we should drop some of the SDKs" or something else)

[FabioPinheiro]

I think is more the first option, of sharing code and don't split functionality.
cc @elribonazo

[elribonazo]

All the code will share dependencies, correct and adding more diversity of options, enabling other people to implement their own Edge or Cloud agents using Java, Kotlin or any TS language will allow further adoption of Identus as a whole.

Not about removing SDK, more the contrary :)

[elribonazo]

There's a high chance that this epic gets approved and prioritised by the Identus team if voting does not radically change in about a week.
Next Tuesday November 12, 2024 we will be closing the ticket and start creating the tasks

[elribonazo]

As agreed, the team is going to prioritize this tasks in the following weeks, the voting is now closed and we will proceed first with specifying the cards.