Extend or add Junction with signature

[mustermeiszer]

Currently, XCM does not support a way to prove ownership of an AccountId32 via a Junction. This leads to the need, that parachains need to trust the sender of an XCM that it has made proper checks of ownership when converting something like

let loc = Multilocation {
  parents: 1,
  interior: X2(Junction::Parachain(2), Junction::AccountId32{NetworkId::Any, id})
}

into either an Origin (e.g. in the Instructions::Transact) or an AccountId (e.g. in the AssetTransactor::* calls).

Adding both or one of the below could help here:

// Default that the signer signs the bytes of id 
Junction::SignedAccountId32{network: NetworkId, id: [u8; 32], sig: Option<[u8; 64]>} 

// Add explicit struct allowing to define costume messages to be signed
Junction::SignedWithMsgAccountId32{network: NetworkId, id: [u8; 32], verification: Option<Verification>} 

struct Verification {
    sig: [u8; 64],
    msg: [u8, 64], // Not sure how many bytes one should allow here. But making it an unbounded Vec seems like a bad idea
}

[dzmitry-lahoda]

Sounds interesting, I feel this lacking in XCM. So may be parity working on this?

What type of signature is used? various chains use different signature schemes? should it be enum variant somewhere?

Did you saw ORML remote chains XCM helper? Does it solves you problem?

[mustermeiszer]

Sounds interesting, I feel this lacking in XCM. So may be parity working on this?

I don't think so. I think the current solution is to just derive secure accounts that have no privat keys on the remote chains.

Did you saw ORML remote chains XCM helper? Does it solves you problem?

Can you point me to it?

[dzmitry-lahoda]

yeah, derived accounts (utility so limited to 65k of these) or https://github.com/open-web3-stack/orml-xcm-builder/blob/master/kusama/src/tinkernet_multisigs.rs

[mustermeiszer]

Closing as we are having remote account derivation now.