Question:
Would it make any sense to have a dedicated origin canister on the fiduciary subnet, that would be a thin rarely-updated asset canister – not a frontend – serving the specific mission to be the `derivationOrigin` value for different frontend canisters sitting on other subnets?
It would simply hold the .well-known/ii-alternative-origins JSON file,
and be reachable at https://<canister-id>.icp.net
Pros i see:
- subnet resilience
- rare reinstalls: zero drops
- independent of any frontend’s lifecycle
Cons? What do you think?
Thanks!
Your rational makes sense, the derivation origin is your applications sole identifier, so you’d either make it:
- Centralized: use a domain you control and own e.g. example.com
- Decentralized: use a canister you control and own
In case 2 it’s indeed very important to not lose access to this canister id, so you can indeed take the following considerations into account:
- Putting it on a fiduciary subnet → higher assurances
- Separating it from your application itself → future flexibility
- Make sure the canister has enough cycles to not freeze and disappear.
Keep in mind canisters can be migrated between subnets, so it’s not forever tied to a subnet, so point 1 isn’t critical for most applications and can be applied whenever necessary.
Also the HTTP gateway domain e.g. icp.net does not play a role in how Internet Identity recognizes your application, only the canister id by itself is considered an identifier, any past and future domain that indicates ICP mainnet will resolve to the same identities.
Similarly with the centralized approach it’s common to see explicit auth domains e.g. auth.example.com for the same isolating from application reasons.