Discussion of TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata

TAP 13 was introduced in #118.

There is a reference implementation available (built on the legacy python-tuf code) at theupdateframework/tuf#1103.

Open questions (from the pr discussion):

• repository vs client hosted alternate top-level targets metadata The TAP currently describes repository hosted metadata that is pointed to by the client, but this does not give the client as much control over the subset of packages on a repository that they trust. For example, a client may want to limit the use of a repository to 2 specific packages. In the current proposal they would need to upload new metadata that specifies these exact packages, which may not be possible if the repository is controlled by a third party. For this reason, I think we should consider allowing the client to provide a mapping to a local top-level targets file.

• client mapping format This depends a bit on the above, but there are a couple of mapping formats described here and in the POC. One big question is whether this should be a part of the existing repository mapping metadata.

• metadata on multiple repositories How does this TAP interact with TAP 4? Specifically, does the targets mapping apply in the same way for every repository, or should a client be able to specify a different mapping for each repository. It would give the client more flexibility if they could set different mappings for each repository, though this may require a larger change to the repository mapping metadata.

Start by reading TAP 13, the discussion in #118, and the reference implementation at theupdateframework/tuf#1103. Resolve the questions about repository versus client-hosted metadata, mapping format, and behavior across multiple repositories, then update the TAP proposal to document the decided design.