Joshua Lock

Thanks for this discussion @erickt. My interpretation of the spec is that we assume we're only ever bootstrapping from a local trusted `root.EXT` and can talk to the repository for...

Thank you for working on this Marina! FYI I'm planning to review this early next week.

> (I'll squash these last few commits once we finalize) Possibly better to do it now, as squash & force push will discard any approvals.

There are several related issues and discussions on Canonical JSON, i.e. secure-systems-lab/securesystemslib#159 and theupdateframework/tuf#457

The specification is now in a separate repository [theupdateframework/specification](https://github.com/theupdateframework/specification/), should this issue be moved there?

I'm planning to take a stab at this over the next week or two.

For the interested, I submitted theupdateframework/taps#117 to try and clean up TAP 4 before I work on this.

I haven't forgotten this work, but I want to discuss and resolve https://github.com/theupdateframework/specification/issues/109 on documenting concepts first.

I think option 2 above makes more sense: > During the update, we delay writing all the metadata to disk until all the files have been downloaded and verified. Then...

The [detailed client workflow](https://github.com/theupdateframework/specification/blob/a765b3e1275cd023d5fe11ad08fb296c3eb95ff3/tuf-spec.md#5-detailed-workflows) states: > Note: If a step in the following workflow does not succeed (e.g., the update is aborted because a new metadata file was not signed),...