Indy-Besu Research Project Proposal

[TelegramSam]

Observations

• There is a significant amount of code for this project.
• Testing will be required to see what kind of behavior this work will yield.
• A go/no-go decision is difficult to make till the project is fairly mature.
• There is a risk of confusion about the direction of Indy as it relates to a direction that the community has not yet committed to.

Proposed Actions

• Work is created in new repositories
  • I understand a previous conversation decided to put the work in indy-node. I think this decision should be changed.
  • This will help the work move faster with less community bottlenecks.
• Related work should be clearly labeled as experimental or research
  • This includes a did method definition, for example
• Advance the project so that we are able to test the properties of the project, including speed, scale, bandwidth, processor load, and energy use.
• Delay commitment to the new approach until we reach sufficient confirmation of approach validity.

[Toktar]

Hello @TelegramSam, thank you for sharing your opinion. The Community considered the observations mentioned above (and other arguments) during the voting over a month ago.

I think this decision should be changed.

Are there any new reasons that warrant the Community reconsidering the decision?

PS: The pull request targets a feature branch, not the main branch.

[tkuhrt]

You could always create a new Hyperledger Lab for this work if necessary.

[TelegramSam]

Are there any new reasons that warrant the Community reconsidering the decision?

I don't believe the question being asked was clear enough or conveyed enough understanding to make the decision a solid one. The Thumbs-up responses to my issue post by main community members underlines this.

PS: The pull request targets a feature branch, not the main branch.

That is part of the problem. I'm not opposed to this work but this isn't an update to indy-node, it's a replacement of it. Given that, a new repository is (I believe) the right strategy given any outcome - including the possible outcome where this is fully adopted as a community.

This could be a lab, but it also fits well within the Indy community as a new development target.

[Patrik-Stas]

Hope it's okay if I use this thread to lay some of my open questions and high level thoughts.

Full ledger state migration

Although I was not part of Indy summits and possible other venues, platforms, where conversations about migrating Indy happened in past - I would like to know to parties who are today in favor of putting easy of migration as one of the upmost priorities - as the the enablement of state migration from Indy to Besu is reasoning for some major decisions made in the DSR PR.

I can only speculate that perhaps when nothing was tangible yet, and trade-offs were lesser known, no organization would object against solution which enable easy data migration.

From my review and analysis, I believe optimizing for easy migration and saving network participants from the "hassle" of having to reissue credentials comes with cost. As I am indicating above, I am not sure if the parties who voted at the time (or anyone really) for the decision were aware of what the cost is. And honestly, even if I was part of conversation back in the day, I am not sure I would be able to see it either - spotting these things is, sort of unfortunately, a lot easier after a prototype is hands-on done.

Speaking from own priorities

I understand that different companies have different interest, and different parties will promote ideas which better fit their needs. So for transparency I am speaking from position of member of Absa issuer team - the enablement migration is simply not adding any value to >us<. I understand the ledger state migration might be valuable to >other< organizations. From our perspective, re-issuance is a baseline capability issuers should be ready to do - for example if an anoncreds vulnerability is discovered. Instead, we value more longetivity of the design, therefore:

• minimizing complexity,
• reusing existing components,
• maximizing interop outside of ex-indy network members,
• maximizing chance of anoncreds method adoption by new non-ex-indy members.

DSR has expressed to ben keen to satisfy both words - like supporting did:ethr in addition to did:indy2. We definitely appreciate it, in some way it's also countering some of the bulletpoints above - supporting 2 type of DIDs is actually increasing in complexity in layers built on top (eg. CL registry, role management).

In nutshell, my main questions boils down to:

1. Which organizations are in favor of optimizng for full ledger state migration?
2. Why do organizations don't want / can't re-issue credentials?
3. Are the organizations aware of network level trade offs required to avoid credential re-issuance?

PS

Ultimately, I just want to say I am a bit sorry because I know I am questioning some of the most fundamental design objectives upon which DSR has invested huge amount of time and effort building upon. However I can not stop myself to advocating for what I believe is right, even though my thoughts would be likely more appreciated 3 months ago, rather than now. But because we are migrating to "new home", where we organizations might be residing for years again (like we did on Indy ledger), I believe on the grand scale of things, this is still very early, and getting things right is important. I am expressing what I value in role of issuer&verifier, prompting to hear positions of other organizations in the community.

[Toktar]

Thanks for this discussion and new ideas. At the last contributors call, we discussed the following ideas:

• We need to divide PoC and MVP phases.
• Approving PR to the experimental branch https://github.com/hyperledger/indy-node/pull/1821 will mean that the concept of using Besu for Indy logic has been proved.
• Looks like MVP as a new Indy project in a new repo is a good idea. The community likes this. DSR also supports this idea if it corresponds to the community vision.
• We need to get the answers for a list of questions to clarify MVP roadmap.

Questions that can be highlighted now:

• Which community members are interested in Indy data migration?
• What are the network level trade-offs required to avoid credential re-issuance?
• What DID methods do community members want to use?
• What business problems can Indy Besu solve now?
  • Proposed answer:
  • Lack of maintenance of Indy Ledger
  • No implementation of new features
  • No other option for a permissioned ledger as a VDR for CL Anoncreds
  • Complex codebase, custom consensus protocol
  • Outdated standards
  • Performance
• Do we want to keep the roles from Indy: Trustee, Steward, Endorser?
• Do we need Endorsement flow?
• Do we need tokens in the PoS network?
• Do we need tokens in the PoA network?
• Do we need TAA?

(to be continued, feel free to send your questions)

[ashcherbakov]

Community decisions (Indy Contributors call on 01/16/2024):

• Continue Indy Besu development in a new Indy repository 
• indy-besu as a new repo name
• Merged PoC PR https://github.com/hyperledger/indy-node/pull/1821 (the code will be moved to the new repo)

[ashcherbakov]

The new project has been created: https://github.com/hyperledger/indy-besu

[Patrik-Stas]

Which community members are interested in Indy data migration? Repeating, but for completeness sake Absa as member and steward of Sovrin, issuer on Sovrin Mainnet, is not interested in this. We will reissue credentials, we don't want our data to be migrated.

What are the network level trade-offs required to avoid credential re-issuance?

• Additional complexity of smart contracts
• brand new DID method needs to be adopted (while the DIDs itself looks similar to did:sov / did:indy, there's nothing in common. The DID Document CRUD works completely different) instead of adopting well established did:ethr method
• in case of supporting both did:ethr and did:indy2 the arguments circles back to the additional complexity

These decisions allegedly cater for the established members of community, but I am convinced the counter-effect is that it hinders adoption of anoncreds and didcomm. If the solution would be built on greenfield with established standards, the entry barrier would be smaller, it would be easier to argue about, easier "to sell".

In fact, greenfield design built purely on did:ethr would not prevent anyone from copying their anoncreds state from one ledger to the other. The only problem to solve would be how to safely map existing did:sov to your new did:ethr.

What DID methods do community members want to use? did:ethr by Absa

What business problems can Indy Besu solve now? Proposed answer:

• Lack of maintenance of Indy Ledger
• No implementation of new features
• No other option for a permissioned ledger as a VDR for CL Anoncreds
• Complex codebase, custom consensus protocol
• Outdated standards
• Performance

I agree. But to me also once-in-years opportunity to sync up with the developments in the ecosystem which happened since 2017 and leveraging the properties of the new ledger.

Do we want to keep the roles from Indy: Trustee, Steward, Endorser?

For me secondary problem, in ideal design this should be abstracted from DID method and Anoncreds method itself. These. contracts could rely on another "authorizing" smart contract interface which would encapsulate how authorization works and what roles exist. However it's worthy noting that while these words exists in this ledger proposal, they do not represent exactly what they represented before, because the inner working of the ledger are different. For example in this Besu proposal, Trustees are the ones which can update smart contract code. But we didn't have smart contracts before, and stewards could technically update the code they run themselves.

Do we need Endorsement flow?

IMO not. Correct me if I am missing something, the way I understand it is that in past endorsement flow existed to simplify the coordination between "ledger organizations" such as Sovrin and the parties who write on it. Instead of onboarding 100 companies and having to KYC them, get them all to pay for transactions individually, handful of highly trusted orgs were onboarded and these orgs could then go ahead and onboard smaller orgs from local ecosystem. Facilitate writes on the ledger on their behalf. This was before there was concept of trust registries, and groups like Sovrin (+ the endorsers) were taking some of the burden to guarantee trustworthiness of the parties writing on ledger. Now we have trust registries and can't see why someone should facilitate ledger writes on behalf of another organization - it's paradoxical to preserve such a paradigm in "self-sovereign identity" space, if even the issuing organization is not self-sovereign, but rather dependent on another middleman to write txs on ledger. We need mechanism to prevent sybil attacks, so I am not arguing against ledger-writer onboarding/whitelisting in public-permissioned deployments, but it really doesn't matter who writes what on ledger. They can write "passport" schema and creddef on ledger, issue credentials against that, but it's worthless if these are not part of accepted trust registries.

Do we need tokens in the PoS network? Do we need tokens in the PoA network?

In terms of PoS, is this referring to existing public PoS networks? Given these networks are inherently sibyl protected by transaction fees, I am not sure if I understand the question. If I'll interpret PoA as public permissioned deployment of besu, then I suppose not, as these would likely be managed on some whitelisting basis and the ledger operator can simply charge tradfi fee for issuing authorized eth address with capability of writes.

Do we need TAA?

No opinion

[WadeBarnes]

Now we have trust registries and can't see why someone should facilitate ledger writes on behalf of another organization

Some discussion regarding this from Discord:

• https://discord.com/channels/905194001349627914/933797403092475924/1202229182734802984
• https://discord.com/channels/905194001349627914/933797403092475924/1202236559546650657

[Toktar]

Some design/roadmap updates for better background understanding.

• Deprecate Indy2 method in favor of using did:ethr contract and specification
• CL Registry: implement event approach matching to did:ethr design
• Mapping of legacy identifiers to ethereum account
• Endorsement support for DID Documents and CL entities

Updated roadmap

Do we need Endorsement flow?

Thanks @WadeBarnes for a link. It's a good conversation about Endorsement flow. It seems to me that endorsement flow possibly is outdated but included in existing business processes of different organizations. Anyway, according to last design changes, I believe keeping this feature doesn't need additional effort anymore.

@Patrik-Stas: Trustees are the ones which can update smart contract code. But we didn't have smart contracts before, and stewards could technically update the code they run themselves.

Technically, stewards can launch their specific code with any kind of blockchain systems. Such nodes are called malicious. Upgrade process of Indy-node launch upgrade automatically and schedule this only after getting trustees' quorum of approvals.

@Patrik-Stas: The only problem to solve would be how to safely map existing did:sov to your new did:ethr.

We fully agree. Therefore, we got rid of Indy2 method and added a task for creating mapping of legacy identifiers to ethereum account.

[TelegramSam]

Do we need Endorsement flow?

but it really doesn't matter who writes what on ledger

Endorsement plays a huge role in preventing PII from being written to the ledger, in prevention of having a network be taken down on account of legal challenges.

On the general topics of migration, did methods, etc: The further this effort deviates from existing practices and standards within Indy, the more difficult it will be for any existing implementations to migrate. If existing implementations don't migrate, then all of the existing difficulties of Indy will persist and the community will divide.

I also support the option of updating the did:indy DID method to allow continued use with the new ledger backing. The method could resolve on both ledgers and allow both an easier transition while continuing to leverage the indy brand.