I have been building on the IC for a while and trying to release my app pretty soon.
I know since the beginning that our Internet Identities our unique url wide but I think It would be better if they could be unique canister wide.
What i’m trying to say is if you go to https://.raw.ic0.app/ and https://.ic0.app/, Internet Identity will not authenticate you with the same principal even if you are calling the same asset canister.
Is it possible to address this “issue” ? I guess a lot of dapps are on the way so it could be interesting to find a way to also be able to have the same principal when using a dns address when it’s released.
This is by design. The Internet Identity authentication should work for any kind of URL – after all, we’ll hopefully soon be able to have websites at http://my-own-domain.com/ backed by the Internet Computer (I don’t fully understand why we don’t have that yet, actually; with a DNS-based approach it’d be a relatively isolated change with a huge impact). Or even websites that are not backed by the IC can use this.
Also, you really shouldn’t be using .raw.app for stuff that needs authentication. Maybe raw should have been called insecure.
There are designs for allowing multiple host names share the same II identity (unfortunately, in the internal wiki only, I believe) that would solve this problem without the II making assumptions about how URLs are backed like the one above. For example, maybe you have multiple canisters that are part of the same DApp and want to see the the same II identity on all of them? So if the issue needs a fix, it ought to be more general than the II making assumption about how hostnames are mapped to canisters.
I understand the design but i’m starting to find it overkill. Most of the time you navigate to an asset canister which asks you to log in through II.
Example with distrikt, you can access the app with https://az5sd-cqaaa-aaaae-aaarq-cai.raw.ic0.app/ and https://az5sd-cqaaa-aaaae-aaarq-cai.ic0.app/ and you will have two separate identities since the principal is generated by II using only the url.
I know the .raw.app is only for insecure data but are the “assets” canister really sensitive data ? Are all the call to backend canister also insecure if we are logged in through .raw.app ?
I still personally think that the endgame for performant IC websites will involve pushing the responsibility of verifying certified assets from the serviceworker back into the DNS resolver. ic0.app has significant flaws for all kinds of content sharing, SEO, performance, and more. If we come up with a decentralized, trustworthy proxy, we should be able to have it cache assets more aggressively and offer a normal web experience.
As for the topic of this thread - we’ve discussed the idea of allowing devs to configure “canonical” II domains with some sort of verification, so that people can migrate their users to a new domain. The scheme would have the existing URL people have logged into be kept as the canonical entry, while using headers or some other strategy to allow the new domain to request its users to be sent back the delegated identity hashed from the canonical URL. For security purposes, we’d need to have some sort of allowlist that the canonical domain will permit
how can the DNS resolver verify assets? The DNS resolver only sees hostnames and IP adresses, and possibly other data stored in DNS, but surely not HTML pages and images.
Hmm, but you can’t move the validation to an untrusted component (like the boundary node). I think I’m missing something in the picture you are painting.
I’ve had tackling authentication across canisters on my todo list for a while. Part of my avoidance is a lack of understanding of how the inner workings of the session, header, and other request info is passed into the IC. Ideally, once I’ve had a user login I’d like my app canister to issue them some kind of signed token(a session) that will be passed to any other content requests on my page that also go to x.ic0.app. Then my other canisters can inspect this session and verify the signature of some timestamp+secret+IC_wide_novel_info came from the validating canister and that I can assume that the requestor controls the principal identity in the request. The use case here is to gate content in my asset canisters by the principal from my app canister. It is another reason I want some Motoko crypto libraries so that I can sign and verify signatures.
That is trivial and needs no further work in canisters, let along crypto: The Internet Identity creates an identity per “web application” so to say, and it doesn’t matter which canisters this web app is then talking to. So if the login button is on https://foo.ic0.app, then this web app performs query or update calls to canister X (your app canister) and canister Y (your asset canister), then it performs these requests as the same identity. Identities are not tied to canisters, but to the URL (more precisely, the “origin” in web tech speak) of the web application; no matter which canisters (if any) the web app then talks to.
Ok…So the subdomain doesn’t mess this up? aaaaaa-bbbbbb.ic0.app is going to get the same session info via an https request that bbbbbb-bbbbb.ic0.app is going to get? This is helpful if so. And do the boundary nodes pass this info along such that it is accessible via the http_request function in a canister?
Now, what I mean is that if aaaaa-bbbbb.ic0.app is the url of the web app, and it uses the agent to talk to canisters aaaaa-bbbbb and bbbbb-bbbbb, then the canisters will see the same identity as the caller.
Tl;DR: no matter how many canisters you have, serve the web application (HTML and JS) from a single one and all is well.
