# Tackling CertifiedData in Motoko **URL:** \ **Category:** Language Support\ **Tags:** Motoko\ **Created:** [August 3, 2021, 12:17am UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272 "2021-08-03T00:17:10Z")\ **Posts on this page:** 17\ **Page:** 2
**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\ **Post date:** [August 13, 2021, 6:39pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/21 "2021-08-13T18:39:06Z")
> [@skilesare](#): > > I think it is cbor encoded so we’d need to parse a subset of cbor values. What are the fields and types? See [the CDDL spec](https://sdk.dfinity.org/docs/interface-spec/index.html#certification-encoding). CBOR tags, arrays, records and `bytes`. > [@skilesare](#): > > What crypto library do we need for validating the signature? Oh, right, you still need to validate the signature. That would require an implementation of BLS. Probably not fun in pure Motoko… maybe we should bet on developer-accessible FFI. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [August 13, 2021, 7:56pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/22 "2021-08-13T19:56:50Z")
Thank you for the link! FFI means being able to reference and call rust functions from our motoko code right? That would be game-changing. ---
**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\ **Post date:** [September 15, 2021, 1:47pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/23 "2021-09-15T13:47:37Z")
I am building a proof of concept Motoko canister that serves a dynamic HTTP asset and certifies it, including CBOR encoding etc.: Code at [https://github.com/nomeata/motoko-certified-http](https://github.com/nomeata/motoko-certified-http) It’s still buggy ([https://ce7vw-haaaa-aaaai-aanva-cai.ic0.app/](https://ce7vw-haaaa-aaaai-aanva-cai.ic0.app/) doesn’t work) and I am out of time for today; I’ll create a new post once it actually works. But at least it works already on [https://ce7vw-haaaa-aaaai-aanva-cai.raw.ic0.app/](https://ce7vw-haaaa-aaaai-aanva-cai.raw.ic0.app/). ---
**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\ **Post date:** [September 15, 2021, 4:37pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/24 "2021-09-15T16:37:03Z")
Works now, see [Certified Assets from Motoko (PoC/Tutorial)](https://forum.dfinity.org/t/certified-assets-from-motoko-poc-tutorial/7263) ---
**Author:** ![LightningLad91](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lightninglad91/32/5373_2.png) [@LightningLad91](https://forum.dfinity.org/u/LightningLad91)\ **Post date:** [August 17, 2022, 2:07pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/25 "2022-08-17T14:07:01Z")
@nomeata @skilesare @claudio I have a question about using Certified Variables and I think its relevant to this thread. I am trying to understand how Canister Signatures work so that I may use them in Motoko to create a canister-controlled neuron, as described by @bjoern [here](https://forum.dfinity.org/t/how-to-create-a-decentralized-community-neuron/12564). I just finished watching @nomeata’s video presentation [Inside the Internet Computer | Certified Variables](https://internetcomputer.org/how-it-works/response-certification/) and one question I have is how this subnet certified data will be handled in the future if a canister migrates from one subnet to another. Specifically, if I create a canister-controlled neuron that can only be controlled via certified data from a given subnet, do I run the risk of losing control of that neuron in the future if my canister migrates to a different subnet? ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [August 17, 2022, 2:17pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/26 "2022-08-17T14:17:49Z")
I don’t think you can do that quite yet. But we are close. Watch the skies! You’ll need to use a t-ecdsa signature I think. I don’t think canister signatures are going to let you control a neuron. ---
**Author:** ![LightningLad91](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lightninglad91/32/5373_2.png) [@LightningLad91](https://forum.dfinity.org/u/LightningLad91)\ **Post date:** [August 17, 2022, 2:18pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/27 "2022-08-17T14:18:41Z")
I suspected as much, but I’ve been told differently and I wanted to do my due diligence. Edit: For clarification, do you not think it can be done at all or do you think this is only a limitation for Motoko? ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [August 17, 2022, 2:24pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/28 "2022-08-17T14:24:49Z")
I think they limit canisters from holding neurons on purpose. The t-ecdsa routes around that. Seems like it will be a silly restriction once we have t-ecdsa, so hopefully we can have it removed. I think the canister signatures are used for delegations, so maybe you could delegate to a canister your ownership of a neuron…but you’d need some way to prove you’d destroyed the private key. ---
**Author:** ![LightningLad91](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lightninglad91/32/5373_2.png) [@LightningLad91](https://forum.dfinity.org/u/LightningLad91)\ **Post date:** [August 17, 2022, 2:30pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/29 "2022-08-17T14:30:14Z")
> [@skilesare](#): > > Seems like it will be a silly restriction once we have t-ecdsa, so hopefully we can have it removed I agree. > [@skilesare](#): > > …but you’d need some way to prove you’d destroyed the private key. Not sure I follow. If I eventually remove the controller of the canister, or hand control to the DAO wouldn’t that be verified by checking the canister’s controller list? ---
**Author:** ![LightningLad91](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lightninglad91/32/5373_2.png) [@LightningLad91](https://forum.dfinity.org/u/LightningLad91)\ **Post date:** [August 17, 2022, 2:34pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/30 "2022-08-17T14:34:50Z")
@skilesare here is the process that @bjoern provided to me on Twitter. > ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [August 17, 2022, 3:10pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/31 "2022-08-17T15:10:29Z")
Ha! Ok…so that is interesting. I’d be happy to outline that out a bit here. I’m clearly missing something here. A canister can sign a root, but I don’t think it can sign data. Wouldn’t it need to sign the transaction? (Maybe the key here is that all that needs to be signed is a transaction hash.) If that is the case then you aren’t really signing a Merkle tree, you are just signing a root that isn’t a root, but a hash of a transaction. Maybe @bjoern can give some clarity. Steps: 1. Send Transaction hash and candid to the canister. Have the hash written to the certified data. 2. Have the canister submit a query via the new HTTP interface to get the signature 3. Do a second HTTP call to send the call to the management canister and the signed hash to the IC. I wish I’d thought of that before because we could have been doing this manually for a while…now with HTTP requests, we can automate it. ---
**Author:** ![bjoern](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/bjoern/32/2100_2.png) [@bjoern](https://forum.dfinity.org/u/bjoern)\ **Post date:** [August 17, 2022, 3:51pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/32 "2022-08-17T15:51:34Z")
The canister would create the ingress message and would put the request id into a Merkle tree structure as described in the [section on canister signatures](https://internetcomputer.org/docs/current/references/ic-interface-spec#signatures). In a subsequent query call to that canister, one can request the signature on the root of the Merkle tree, and the canister can also return the path in the Merkle tree. Together, those form the “canister signature”. This is exactly what we do in Internet Identity; well, we “sign” a delegation not an actual request id, but that doesn’t really matter, just do what II does but “sign” the request id instead. That said, as @skilesare pointed out, canister signatures (and the tECDSA feature as well) together with the HTTP request feature make the restriction that canisters cannot hold neurons somewhat artificial. So maybe there is a discussion to be had (maybe first in a dedicated thread here in the forum, and maybe that could lead to an NNS proposal) about lifting that restriction. ---
**Author:** ![LightningLad91](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lightninglad91/32/5373_2.png) [@LightningLad91](https://forum.dfinity.org/u/LightningLad91)\ **Post date:** [August 17, 2022, 3:58pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/33 "2022-08-17T15:58:17Z")
Thanks @bjoern, I have a few follow-up questions: > [@LightningLad91](#): > > if I create a canister-controlled neuron that can only be controlled via certified data from a given subnet, do I run the risk of losing control of that neuron in the future if my canister migrates to a different subnet? Do you know if I risk losing control of the neuron in the scenario described above? > [@bjoern](#): > > The canister would create the ingress message Do you have a reference for doing this? I’m still learning the ins/outs of Motoko. I thought only external actors could create ingress messages. > [@bjoern](#): > > In a subsequent query call to that canister, one can request the signature on the root of the Merkle tree, and the canister can also return the path in the Merkle tree. So does this mean that the canister itself would not be submitting the neuron management calls to the NNS? I would need some authorized third party to retrieve these variables and then pass them to the NNS indirectly? ---
**Author:** ![bjoern](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/bjoern/32/2100_2.png) [@bjoern](https://forum.dfinity.org/u/bjoern)\ **Post date:** [August 17, 2022, 4:23pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/34 "2022-08-17T16:23:56Z")
> [@LightningLad91](#): > > Do you know if I risk losing control of the neuron in the scenario described above? That is not a risk. Let us look at the [spec](https://internetcomputer.org/docs/current/references/ic-interface-spec#signatures), in particular the part that defines the “public key” for canister signatures: > The `BIT STRING` field `subjectPublicKey` is the blob `|signing_canister_id| · signing_canister_id · seed`, where `|signing_canister_id|` is the one-byte encoding of the the length of the `signing_canister_id` and `·` denotes blob concatenation. The key only depends on the `signing_canister_id` and a canister-chosen `seed`. No information about the subnet is used. In fact, we will be moving the Internet Identity canister to a new subnet soon, which is only possible due to the described property. > [@LightningLad91](#): > > Do you have a reference for doing this? I’m still learning the ins/outs of Motoko. I thought only external actors could create ingress messages. I don’t, unfortunately. It’s a mess, since you have to first encode the argument as Candid, then you have to assemble the ingress message as CBOR and compute the request id. I was saying that it’s possible, not that it’s easy… > [@LightningLad91](#): > > So does this mean that the canister itself would not be submitting the neuron management calls to the NNS? Well the canister can use the HTTP request API to make a query call to itself. And then it could use the HTTP request API to submit the request to the boundary node. So once we have HTTP queries, the canister can do this. But yeah, all this wouldn’t be necessary if canisters could control neurons directly. ---
**Author:** ![LightningLad91](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lightninglad91/32/5373_2.png) [@LightningLad91](https://forum.dfinity.org/u/LightningLad91)\ **Post date:** [August 17, 2022, 6:45pm UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/35 "2022-08-17T18:45:50Z")
> [@bjoern](#): > > The key only depends on the `signing_canister_id` and a canister-chosen `seed`. No information about the subnet is used. In fact, we will be moving the Internet Identity canister to a new subnet soon, which is only possible due to the described property. Thank you! This is good to know. I misunderstood the video when it said the subnet would sign the certificate and had not taken a look at the spec yet. > [@bjoern](#): > > I was saying that it’s possible, not that it’s easy… Copy that. I may still try to build this just to learn from the experience. > [@bjoern](#): > > But yeah, all this wouldn’t be necessary if canisters could control neurons directly I would like to draft a governance proposal requesting that DFINITY add this feature to their roadmap, or at least consider it in their horizon planning. I’m just not sure how that process works now given recent discussions on the topic. I want to respect y’alls processes. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [August 18, 2022, 10:08am UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/36 "2022-08-18T10:08:28Z")
> [@LightningLad91](#): > > I would like to draft a governance proposal requesting that DFINITY add this feature to their roadmap, or at least consider it in their horizon planning. I’m just not sure how that process works now given recent discussions on the topic. I want to respect y’alls processes. > [@Proposal: Remove the is\_self\_authenticating restriction on Neuron Ownership](https://forum.dfinity.org/t/proposal-remove-the-is-self-authenticating-restriction-on-neuron-ownership/14948): > > Given the upcoming t-ecdsa functionality going beta, and the HTTP interface enabling using canister signatures( [Tackling CertifiedData in Motoko - #32 by bjoern](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/32)), the restriction on canisters not being able to hold neurons is a merely an inconvenience. A good bit of code needs to be written to enable either t-ecdsa ownership of neurons or certificate ownership. To avoid wasted effort, we recommend removing the restriction at the following lines that will enable canisters to hold neurons(deleti… ---
**Author:** ![bjoern](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/bjoern/32/2100_2.png) [@bjoern](https://forum.dfinity.org/u/bjoern)\ **Post date:** [August 18, 2022, 10:19am UTC](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272/37 "2022-08-18T10:19:35Z")
> [@LightningLad91](#): > > I would like to draft a governance proposal requesting that DFINITY add this feature to their roadmap, or at least consider it in their horizon planning. I’m just not sure how that process works now given recent discussions on the topic. I want to respect y’alls processes. If you’re referring to [the recent discussion on priorities](https://forum.dfinity.org/t/proposal-to-prioritize-55651-periodic-confirmation-38985-manual-voting-over-48623-compounding-maturity/14461/26): I think the proposal you have in mind is clearly a (technically straightforward) proposed change to the IC governance system. Especially if it is phrased like that (a proposal to change the governance system, not necessarily about who implements it and when), I think it is clearly suitable and expect that fact to be uncontroversial. That said, it may make sense to describe the intent in a forum thread first. [Previous page](https://forum.dfinity.org/t/tackling-certifieddata-in-motoko/6272.md?page=1)