Move identity network type to IdentityContext

[Kailai-Wang]

Context

Many blockchains "share" the same key pair construction mechanism, which means owning one private key would grant you access to the same public key or address on different networks.

Examples:

• EVM based: ETH, Polygon, BSC -> they have the same public key and address
• Substrate based: relaychains + parachains -> they have the same public key, but different addresses due to different ss58 prefixes

We had discussions about whether we should treat the same public key on different networks as distinct identities, the decision was yes at that time. Reasons include:

• it gives the user finer control over their identities, e.g. they can link their polkadot address to the IDGraph and intentionally not link their kusama address
• without explicit network types, calculating specific VC would be unrealistic, e.g. the number of governance activities over all linked substrate identities

During the implementation of EVM-signin feature, we realised that we might be able to simplify this process - by moving the network type information away from Identity itself to IdentityContext.

Before:

pub enum Identity {
    Substrate { network: SubstrateNetwork, address: Address32 },
    Evm { network: EvmNetwork, address: Address20 },
    Web2 { network: Web2Network, address: IdentityString },
}

pub struct IdentityContext<T: Config> {
    // the sidechain block number at which the identity is linked
    pub link_block: BlockNumberOf<T>,
    // the identity status
    pub status: IdentityStatus,
}

After:

pub enum Identity {
        // web2
        Twitter(IdentityString),
        Discord(IdentityString),
        Github(IdentityString),
        // web3
    Substrate(Address32),
    Evm(Address20),

}

pub struct IdentityContext<T: Config> {
    // the sidechain block number at which the identity is linked
    pub link_block: BlockNumberOf<T>,
        // a list of networks on which this identity is used
        pub networks: Vec<Network>, 
    // the identity status
    pub status: IdentityStatus,
}

Rationale:

• Foremost: the TrustedCall/DI is authorised using signature, and signature is ignorant of network types. It's impossible to specify the identity network that can access/manage the IDGraph. So you can't say: we only allow litentry identities to manage the IDGraph, not polkadot identities. It doesn't make sense because the signature doesn't contain the network information, they are just calculated from key pairs
• it makes the linking process easier for the user. They don't have to repeatedly link identities with different networks despite sharing the same public key (thus the same validation data). They only link it once.
• it reduces the IDGraph size.
• it might lower the chance of cheating, given that one identity can only exist in one IDGraph and you can't unlink it.

Proposal

Meanwhile, we want to maintain flexibility, and the user should still have complete control over things like identities on which network should take part in the assertion building.

While we don't distinguish network types when adding identities to IDGraph, sometime, somewhere, we need to ask the user: for which networks do you want your identities in IDGraph to be used? It can be 3 such moments:

1. when the user links an identity
2. when the user builds a VC
3. somewhere in between

We propose a hybrid solution of 1 and 3.

Example:

• when the user links a substrate identity (EVM-based is similar), we give the user the initial possibility to specify which networks the identity should be used for. In UI it's something like a multi-select box, where we have some default networks that are ticked already (e.g. Litentry, polkadot, kusama, phala...) but the user is free to check or uncheck the network. Just so you know, it's a finite set of networks, mostly dependent on the data provider, so it won't be 100 parachain networks.
• we provide an extrinsic or DI called set_identity_network so that user can update the network list at any time
• the change will take effect in the next VC generation. So for example, when the user only sets kusama as active network, only activities on kusama will be considered when the user requests the VC "number of governance activities over all linked substrate identities", no polkadot, no litentry or any other substrate networks.

---

:heavy_check_mark: Please set appropriate labels and assignees if applicable.

[Teunhbrkn]

Sounds good. The only thing that comes to mind is that there probably should be some logic to help a user automatically select the most relevant 'identity networks' when generating specific VC's.

[Kailai-Wang]

Sounds good. The only thing that comes to mind is that there probably should be some logic to help a user automatically select the most relevant 'identity networks' when generating specific VC's.

Thanks! Maybe we can warn the user from UI if the current active set is different from the "recommended" network setting of VC - but we should respect the user's choice if they stick to it

[jonalvarezz]

It sounds good to me overall.

From a user perspective, it will be the same as it currently is: Adding a new network requires signing a new transaction.

Let's just be aware that this involves new UI and UX scenarios we need to consider, thus, it delays delivery further.

[Kailai-Wang]

it will be the same as it currently is: Adding a new network requires signing a new transaction

A bit better :) changing network does require a new tx or DI request, but not a second signature (since we don't have to validate it again).

We also hope in most cases people don't have to change it because we'll going to have network filter on VC level, like "the number of governance activities over the following networks: litentry, phala, bifrost"

[jonalvarezz]

changing network does require a new tx or DI request, but not a second signature

Awesome! out of curiosity: how do you validate the request comes from the owner of the account?

[Kailai-Wang]

how do you validate the request comes from the owner of the account?

I don't quite get the question - it's the same way as before. What I was trying to say is that linking the identity with network information would require an extra signature (for validataion_data) each time

[Kailai-Wang]

I've fixed the Before and After code example a little, as web2 identities inevitably need the network information :)

[hanwencheng]

Looks good to me, thanks for the proposal, have one question,

In After data structure, what will change if a user decide to unlink one identity?

[Kailai-Wang]

Looks good to me, thanks for the proposal, have one question,

In After data structure, what will change if a user decide to unlink one identity?

The user won't be able to unlink the identity according to the previous EVM-signin proposal They can:

• either deactivate the whole identity but set the status to Deactivated
• or partially deactivate it by unselecting some of the available networks

[hanwencheng]

OK, so the IdentityStatus record all of the changes

[ghost]

[ghost]

Sorry for the dump. We have taken into consideration few cases and tried to see how it potentially could look like.

As an advocate of UX from a user POV this feature of selecting network should be "advanced" Therefore making it as a default to select main networks and you could "opt out" if you want to.

Also we don't need to support all the variables from a day one. Let's have the ideal user scenario first and then slowly add those extra features.