The private key from the identity.pem file will be verified by the corresponding subnet public key which I’m going to deploy my canister or I interact with my principal ID.
And this is the corresponding sentence in the documentation:
The first time you run the dfx canister create command to register an identifier, your public/private key pair credentials are used to create a default user identity. The credentials for the default user are migrated from $HOME/.dfinity/identity/creds.pem to $HOME/.config/dfx/identity/default/identity.pem .
I can`t find this file on my machine:
$HOME/.dfinity/identity/creds.pem
And all further identities are created based on the first default identity?
I don’t think that’s how it works, you can create private keys offline, they don’t need to be verified by a subnet and you can use and idenity dervied from a private key to communicate with different subnets, it’s not tied to a specific one.
The reason you can’t this file is probably that you used the default identity to create a canister, which migrates it to $HOME/.config/dfx/identity/default/identity.pem as stated in the sentence you quoted.
And to my understanding further identites are created independent of the default identity.
Thanks for your answer.
But, if a private key is not verified by someone what is it for ?
I agree that the public key will not firmly bound to a particular subnet, because if you deploy a canister then no one has the possibility to select a subnet (at least I haven’t seen it yet).
I think the private key must be verified by every subnets public key.
This file is also not available if use a completely new installation. It looks to me, that the documentation is not up to date for that point, maybe ??
I think i misunderstood your question, in this context the signature of a message is being verified before it reaches a canister. Usually you don’t say that a private key is verified, you say that a signature is verified.
Your private key and the subnets public key aren’t in any relationship.
If you want to find out more about the topic there are a couple of nice resources out there.
When an identity deploy a canister, per default this identity gets the controller of that canister. So I need this identity to interact with that canister for state changing requests.
If I want an other identity to allow also to interact with that canister I can add another controller or custodian to that canister. This process is called delegation in that content, right?
You don’t need the identity to make state changing (upgrade) calls. Only if you explicitly restrict access to that method in your code.
Controllers of canisters in general have “admin” access to the canister itself, this means they can upgrade, delete or uninstall the canister andl also add/remove other controllers for the canister.