[Bug] identity.rs blocks modern Rust async stack: no support for tokio 1.44+, axum 0.8+, reqwest 0.12

[theweboftrust]

Summary

The current version of identity.rs is pinned to tokio 1.43 and is not compatible with the latest Rust async ecosystem, including axum 0.8+ and reqwest 0.12. This is blocking integration for projects that need both IOTA identity features and a modern web backend.

Details

• Our project (wot.id) requires both IOTA identity (via identity.rs) and a modern REST API backend (axum/reqwest/tokio).
• All recent Rust web frameworks (axum 0.8+, reqwest 0.12) require tokio 1.44+ and are incompatible with the current identity.rs dependency.
• Downgrading axum/reqwest to match identity.rs results in significant code rewrites and loss of ecosystem support.
• Temporarily, we have removed all identity.rs integration from our backend and are waiting for an update to re-enable full IOTA functionality.

Request

• Please update identity.rs to support tokio 1.44+ and the latest versions of axum, reqwest, and related async crates.
• If there is a roadmap or timeline for this, please share it with the community.
• If help is needed, we (and likely others) can assist with migration/testing.

Impact

This issue blocks modern Rust projects from integrating with IOTA identity, and is likely affecting others in the ecosystem as well.

Thank you for your work!

[eike-hass]

Hi there, thank you for taking the time to open an issue 👋
Unfortunately the upstream iota dependency pins tokio to 1.43 for now. There is some ongoing work to move to 1.44 here.
As soon as that dependency is bumped (hopefully in one of the next releases) you should be able to update too.

[eike-hass]

@iotaledger/dev-tools FYI

[eike-hass]

@Aconitin FYI

[ft-filancore]

As a side note we at filancore also stumbled across this (the opinion in this post is my own, though). The solution cannot be to pin things and wait for updated versions. The solution is not to pin upstream.

If I understand things correctly, IOTA upstream also only needs the pin for tests, so probably this should really be a different test package which does not propagate pins downstream.

Pinning dependencies like tokio or chrono (both currently pinned at older versions) is not only a dependency hazard for downstream users but also causes audit lints to fail because of identity.rs and IOTA. To people checking on the binary audits, the constant exception bump for IOTA sheds the picture of “insecure software that requires constant exclusion from audit lints” in the best case. In the worst case it is the picture of “if they are such a bad citizen in the crate ecosystem, what are the costs of replacing the dependency”. None of these takes is beneficial in the long run.

[ft-filancore]

As I recognize that this cannot be really addressed without upstream addressing it, I created iotaledger/iota#7934. @theweboftrust Feel free to weigh in with your issues there as well.

[theweboftrust]

Date: August 12, 2025
Target: #1665
Context: Strategic update on modern Rust async stack compatibility

---

Status Update - August 2025

Hi team! Following up on the tokio/axum compatibility issue I reported in May. The situation has evolved significantly, and I wanted to provide an updated assessment with broader context about IOTA protocol compatibility.

Current wot.id Development Status

• Still blocked by identity.rs tokio 1.43 limitation
• Production deployment delayed due to inability to integrate IOTA Identity with modern Rust stack
• Temporarily removed all identity.rs dependencies from backend to maintain development velocity
• Active development continues on wot.id with IOTA SDK v1.3.1 (Protocol 9) for transaction functionality

Expanded Compatibility Context

Since my original report, I've discovered this issue is part of a broader compatibility gap between IOTA Identity and current IOTA mainnet infrastructure:

Protocol Version Misalignment

• IOTA Mainnet: Currently on Protocol 9 (IOTA SDK v1.3.1) - stable since July 2025
• IOTA Identity SDK: Still locked to IOTA SDK v1.2.3 (Protocol 8)
• Protocol 10: Coming in IOTA v1.4.1 with Move framework breaking changes

Specific Technical Blockers

1. Rust Ecosystem: tokio 1.43 vs modern stack requiring tokio 1.44+
2. IOTA SDK Version: v1.2.3 vs v1.3.1 API incompatibilities
3. Protocol Support: Protocol 8 vs Protocol 9/10 feature gaps
4. Move Framework: Upcoming stdlib changes in Protocol 10

Real-World Impact

This compatibility gap is blocking production deployment of decentralized identity applications that need:

• ✅ Modern web backends (axum 0.8+, reqwest 0.12, tokio 1.44+)
• ✅ IOTA mainnet compatibility (Protocol 9, SDK v1.3.1)
• ✅ W3C DID/VC compliance (IOTA Identity features)
• ✅ Production reliability (latest security updates, ecosystem support)

Strategic Questions

1. Timeline: Is there a target timeline for tokio 1.44+ support in v1.6?

2. Protocol Strategy: Will IOTA Identity skip Protocol 9 and target Protocol 10 directly?

3. Version Strategy: Should projects wait for v1.6 incremental fixes or v2.0 breaking changes?

4. Move Framework: How will Protocol 10's Move stdlib changes affect Identity contracts?

Concrete Offer to Help

I'm actively developing wot.id and can provide:

Beta Testing

• Immediate testing of compatibility fixes against real production use case
• Integration testing with modern Rust stack (axum, reqwest, tokio)
• Protocol compatibility validation across mainnet environments

Technical Contributions

• Migration assistance for tokio/axum compatibility updates
• Documentation of integration patterns for modern Rust projects
• Use case feedback from production decentralized identity application

Development Context

• Active codebase: https://github.com/theweboftrust/wot.id
• Production deployment: Render + Vercel with IOTA mainnet integration
• Real users: Waiting for full Identity feature integration

Current Workaround Strategy

While waiting for compatibility:

• Maintaining IOTA SDK v1.3.1 for transaction functionality
• Monitoring IOTA Identity releases for Protocol 9/10 support
• Ready to integrate immediately when compatibility is available

Community Impact

Based on ecosystem observation, this issue likely affects many projects trying to build production applications with:

• Modern Rust web frameworks
• IOTA Identity integration
• Mainnet deployment requirements

Thank you for your continued work on IOTA Identity! This is a critical piece of infrastructure for the decentralized identity ecosystem, and I'm happy to contribute to making it production-ready for modern Rust applications.

---

Ready to test, integrate, and provide feedback as soon as compatibility updates are available.

Best regards,
Axel (theweboftrust)