We’re using IC identities with ic-agent for canister calls, but we’d also like to use it in non-canister services e.g in our serverless functions for the frontend. This lets us use the same indentity for authorization both on and off-chain. Happy to explain the use case further in case this is of interest.
It would be SUPER helpful for us if ic-validator-ingress-message along with the required types from ic-types were published as a separate crate(s) to crates.io. Right now we’re importing them by referencing the IC repo in our Cargo.toml which downloads the entire IC repo before parsing and figuring out the subsequent build steps.
Another alternative is to publish this functionality as part of ic-agent itself. We are happy to submit a PR in case this is the direction you would like to go.
Any guidance is appreciated.
Thoughts?
Tagging @frederikrothenberger since we’ve received some input regarding a connected project on this and not sure who exactly to reach out to regarding this
@rupansh-gob from our team is tackling this. He can answer any followup questions
I absolutely agree, that this would be great to have. We have been pushing for that internally for quite a while. But it is not that easy, since in order for these crates to be published, all the transitive dependencies need to be published as well.
As it turns out, this is quite a bit of work, so we need to balance such efforts with work on other features.
Hey,
I tried using standalone-sig-verifier in our example, but our use case also requires the verification of messages signed by DelegatedIdentity
verify_basic_sig_by_public_key seems to be for signatures signed by standalone identities,
and I am guessing verify_canister_sig is not what we want to use (Its not clear how to serialize Signature from ic-agent into what it expects)
(Apologies for not including direct links as I am unable to post them right now)
As for supporting delegation chains within a published library: I’m all for that, but I would assume that this would only happen after the basic signature support has been made available in published libraries.
@saikatdas0790, @rupansh-gob, I’m currently looking into what it would take to publish various crypto utilities such as ic-crypto-standalone-sig-verifier and ic-validator-ingress-message on crates.io.
Unfortunately, the publishing wouldn’t be an easy task, because of all the transitive dependencies, which would also have to be published. For example, for the ic-validator-ingress-message that you are interested in, as it currently stands, we would have to publish ~87 crates, assuming we publish the crates as-is, i.e., including the tests. Roughly half of these crates are actual dependencies, and the rest are dev-dependencies. Likely we could optimize the crate landscape a bit through refactoring to get the numbers down, but the impact probably wouldn’t be very big.
The actual effort of publishing and maintaining so many crates on crates.io (including all the preparation work) would be quite significant. Because of this, I’d like to collect and understand the actual pain points developers have with the current situation (where the crates are not published on crates.io).
@saikatdas0790, you said that referencing the IC repo in your Cargo.toml “downloads the entire IC repo”: do I understand correctly that this is your major issue with the current situation? That is, is your biggest pain point the download and build time? Are there others, and if so, which exactly are those? Having more insight into this will help us in deciding how to move forward.
I’ve just run into this issue. I’m trying to get Azle (TypeScript/JavaScript sdk) to allow authentication in Express and similar web REST frameworks using regular libraries like JSON web tokens. I need a way for the Azle canister to verify everything from the frontend, and I’ve been guided to using this library, but because it’s not a crate I might have some trouble getting this to work.
This will be a core part of Azle I’m thinking, and I’m not sure the trouble I’ll have with all of these dependencies. There are a couple of other avenues I can go down like getting Wasm to work fully in Azle etc…but just letting you know my use case.
