Account ownership testaments

[lucasvo]

It is not always possible to verify & link account ownership across chains. This PR proposes a new message type that allows a chain to send a message to another chain indicating that the owner of an account successfully authenticated itself on the chain and intended to make such a claim on the target chain. This can be used to address an issue with the current crowdloan pallet discussed in polkadot/#2311

When thinking about this problem a bit, I arrived at the conclusion that this is essentially a "claim" an identity or account can make. At the very minimum I think such a claim must have some sort of "scope" and an expiration date allowing the claims to be protected against typical issues such as replay protection and front-running.

I think there is a case to be made to support both vertical message passing as well as horizontal message passing. We should be able to use the same format for both, I assume right?

[xlc]

How is timestamp going to be used? Upon receive the message, the dest chain should just transfer the assets into the destination account immediately.

[lucasvo]

This is not used for assets but merely indicates the validity of the claim. In the crowdloan example it would you would first sign an extrinsic on the relay chain instructing it to send a claim to the parachain with such a claim and an expiration date. Until such a timestamp has passed, the parachain would allow the user to then submit an extrinsic to withdraw their reward from the destination account.

[gavofyork]

when exactly would this be used?

[lucasvo]

Any certificate or claim should have an expiration IMO. Just looking at how signed statements would be used when working in different contexts. For aanything from SSL to meta-transactions in crypto, most often you do need some sort of expiry or nonce but nonces wouldn't make sense in this instance.

[lucasvo]

@gavofyork are you ok with leaving this in?

[gavofyork]

how is this defined?

[lucasvo]

For example if a claim was used to authorize another account to trade you would create a claim to the dex as destination and set the scope to the assets you would authorize a transfer for.

[h4x3rotab]

Looks like a Transact is sufficient to send a Call to the targeted parachain. IMHO "AccountClaim" is too specific use case to fit into XCM itself. I'd love to keep XCM more generic.

[lucasvo]

A transact would work indeed @h4x3rotab, if the plan is for the origin_type to be always the origin account on the chain sending the message. The spec is a bit hard to follow here.

[xlc]

I will prefer specific claim XCM over generic Transact.

With an universally implemented XCM, we can offer an unified flow to handle claims. It should work on all chains and sender does not need to worry about dest chain extrinsic format, which can change.

Especially for ledger or other hardware devices, it will be impossible for the device to correctly parse & show the payload of a Transact message.

[gavofyork]

@lucasvo / @xlc is this still needed? If so it will need to be resolved.

[xlc]

I still think this is a useful feature to have. It could also be used for example connecting identities across multiple parachains.

[lucasvo]

@xlc perhaps it would make sense to ask the Kilt team on this as well. I've opened a discussion in the polkadot builders wg #xcm channel (https://discord.com/channels/804712515313205299/804712609881522186/894896287525269544)

[weichweich]

Yes, this might make sense in cases where you have two incompatible address types. e.g. chain A only supports sr25519 and chain B only supports ed25519, then there is no way to translate addresses on A to addresses on B. The user won't be able to control the address on B since they don't have the private key.

Our current concept for DIDs already supports multiple keys with different key types. So in theory it could be used to link addresses together, but it's currently not designed for it. Our initial thoughts were to have something similar to the proxy pallet but the proxy account having a different address scheme/key type. As we currently see this issue can be solved either through XCM or through a third party chain (e.g. KILT) tracking address mappings. The two different solutions have different trade-offs regarding the trust model and flexibility. This is an interesting topic for us, however, we are currently focusing on decentralizing our chain.