Consider making TUF a proper subset of Uptane...

[JustinCappos]

In general, Uptane is a superset of TUF. It borrows roles, delegations, and the vast majority of other concepts from TUF. Changes needed in TUF for Uptane, such as some of the multi repository support have been upstreamed back into TUF.

Uptane has several changes that are not in TUF, such as manifests, partial verification secondaries, and similar which we likely do not want to upstream. Also, TUF assumes that the client is the one making the decision about what to install, which is a change we will need to relax if Uptane were a superset of TUF. There are likely more considerations, I haven't thought of.

Making TUF a subset of Uptane might simplify some of the specification changes, etc. but does have some issues.

1) Terminology -- Uptane uses automotive friendly terms everywhere. We started with the TUF specification and moved over to this. How would a change back to TUF impact this?

2) Changes in TUF not needed in Uptane -- As TUF adds functionality for things that are not needed in Uptane (like self-key rotation), should Uptane adopters need to add them?

[pattivacek]

I shouldn't be surprised that this is more complicated than I was originally expecting.

Also, TUF assumes that the client is the one making the decision about what to install, which is a change we will need to relax if Uptane were a superset of TUF.

Yeah, that doesn't really make as much sense in the Uptane model.

1. Terminology -- Uptane uses automotive friendly terms everywhere. We started with the TUF specification and moved over to this. How would a change back to TUF impact this?

Just an idea -- we could use both, or we could provide some sort of glossary or translation chart.

2. As TUF adds functionality for things that are not needed in Uptane (like self-key rotation), should Uptane adopters need to add them?

Probably not. We could include them as optional features, but if they aren't useful for Uptane, we shouldn't include them.

In my opinion, the thing that would be most helpful would be if the parts that are meant to be functionally the same also looked similar in terms of format, design, and language (... to some extent), and if Uptane contained specific references to corresponding sections in TUF. Back when I was an implementer, I found it confusing to sometimes have to jump back and forth when I was seeking clarification and detail on specific points. I knew Uptane came from TUF, but that wasn't always obvious. There was nothing to in place to support doing that, and I don't think that's changed.

Then again, if no one else cares or needs this, we don't have to do anything. If we know that they are similar and have overlapping parts, and we generally try to keep them in sync (as in, fix shared bugs and carry over shared features), maybe the status quo is fine.

[jhdalek55]

After a discussion at the 12/20 Uptane Standard meeting, it was decided we will leave this issue open, but will not actively seek to address the issue at this time. Instead, it was decided that a broader community discussion may be needed about future directions for Uptane, including determining short and long-term project goals, and we can most effectively address changes that would occur in applying Uptane outside the automotive markets. This discussion would be held in a meeting separate from our regular biweekly meetings. @jhdalek will set up a Doodle poll after the first of the year to check on interest and availability of attendees for such a meeting.