allow the user to specify the front-end hostname (select "derivation")

[davidp94]

If we want to use the same Principal on multiple pages; we should allow the user and/or developers to pick a static hostname so that the Principal can be re-used on multiple front-end canisters

https://github.com/dfinity/internet-identity/blob/main/src/internet_identity/src/main.rs#L419

[nomeata]

Such a feature needs to be carefully design to be secure. If all B wants the user to get the same principal as they have on app B, then this must only work if B explicitly and securely whitelists A.

I'd recommend to not let the actual human user have a say here; at least not on the level of hostnames that contain canister IDs etc. Too easy to be abused for phishing etc.

We had a design for the former (allowing A to say they want the same principal as B, and a way for II to find out of B allows that), but I think it was on the internal notion page.

[davidp94]

Such a feature needs to be carefully design to be secure. If all B wants the user to get the same principal as they have on app B, then this must only work if B explicitly and securely whitelists A.

I'd recommend to not let the actual human user have a say here; at least not on the level of hostnames that contain canister IDs etc. Too easy to be abused for phishing etc.

We had a design for the former (allowing A to say they want the same principal as B, and a way for II to find out of B allows that), but I think it was on the internal notion page.

Another way to think about it, is to think about it as a wallet, whereas you will have non-hostname "hostname" so we can introduce notion of "accounts"

Account0 (hostname=accounts/0)

In term of security there can be a warning or for this kind of identity, it could work as metamask and post a message (window.postMessage) to the internet identity window; and the user would have to approve/discard(via modal or co) the to-be-signed query/shared messages going to back-end canisters with the possibility of "remember this target canister"

On that case we won't provision a delegateIdentity, but an Identity that post/receives messages to the internet identity window; a device key would be stored in the internet identity local storage.