I cannot speak to how much TBF-specifics are already embedded in the general AppID infrastructure, but I do recall that it was supposed to be mostly independent of the particular application binary format, loading procedure, or other specifics. So that would make me hesitant to include this type in a core AppID-API such as Compress. Could this information also be provided on the Process trait, or perhaps an extension trait?

Besides, this would warrant an update of the (non-finalized) TRD. Nevermind, I can't read.

Are you looking at the TRD or the actual code? The TRD had &Process being the argument, and I updated that to have both process and the credentials. The actual code only had the credentials, and I updated that to have the &Process as well.

Sorry, I clearly got confused by what's been changed here and the discrepancy between the TRD and the implementation. With this actual change I fully agree -- although I'm still unsure whether the TbfFooterV2Credentials should be passed at all.

although I'm still unsure whether the TbfFooterV2Credentials should be passed at all.

I think this is a good question. I do think we agree that for apps that use TbfFooterV2Credentials the compress trait should have access to them. This is I believe the only way to get access to them at the moment, so I think it makes sense to leave it there for now. If we decide to reorganize this further, they could be provided through ProcessStandard somehow.