Original text:
5. <del> This topic is still under discussion, see issue 79 [1] </del>  <del> Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single, centralized service trusted by all parties.  For example, multiple Transparency Service instances may be governed and operated by different organizations that are either unaware of the other or do not trust one another. </del>  <del> This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration Policy. </del>  <del> This may also involve attaching multiple Receipts to the same Signed Statements. </del>  <del> For example, a software producer of a supply chain artifact might rely on multiple independent software producers operating transparency services for their upstream artifacts.  Downstream producers benefit from upstream producers providing higher transparency regarding their artifacts. </del>  6.

Reviewer comments:
In case there is no rough consensus to keep federation section, I raised URL to remove it.
I'd suggest we've had a few different conversations about federation of everything in a transparency service, vs. selective promotion of a subset of information across Transparency Services. The later being the ability for a consumer of one or more Transparency Services to promote the content for a subset of their software. Microsoft ships lots of software, However a consumer may only want to promote the Office suite of products into their Transparency Service for internal validation. I'd suggest the wording, as current, isn't well defined and I'd vote to cut this section until more well defined.
If this PR is dropped then we should create an issue to address the underspecification of unpotected headers at registration, especially the idea to preserve unprotected headers. Federation is a simple use case that highlights this problem
Its not simple, and we have seen no implementation support for it to date.
If we are at the point where we need to start from scratch on configuration/registration policy and scrap the initialization section, I personally do not see how we can keep federation and not just remove it (not to drive you and others mad, we can always add back later).I think the new text is too specific. To me (and as in the prior text) Federation refers to having multiple TS, and one TS accepting receipts from another TS at registration time is just an advanced case, for which we don't have clarity yet. As discussed earlier, letting the TS decide what unprotected headers to authenticate in its receipts is a major complication. My preference would be (1) keep a general placeholder on Federation --- better than nothing; or else (2) cut the section. But this leaves many questions unanswered, starting with the two TS in the arch diagram.

Revised text:
5.  <ins> Transparency Services MAY have Registration Policies that require Receipts from other Transparency Services to be included in the Unprotected Header of Signed Statements at the time of Registration. </ins>  <ins> Transparency Services MUST reject Signed Statements that are invalid according to their Registration Policy, which can include requirements associated with the unprotected bytes comprising the cose-sign1 unprotected header. </ins>  <ins> A Receipt for a Transparent Statement, proves that a Transparent Statement is included in an Append-only Log. </ins>  <ins> Receipts for Transparent Statements, are a special case of Receipts for Signed Statements. Verifying Receipts for Transparent Statements can be difficult. Transparency Services SHOULD copy the unprotected header they observed at the time of registration into the Protected Header of their Receipt. This ensures that the exact bytes which they have included in their append only log, can be reconstructed, even though some of those bytes lacked integrited protection, due to being located in the unprotected header of a Signed Statement. </ins>  <ins> Depending on the complexity of the unprotected header, additional cannonicalization operations MAY be required in order to recover the exact bytes that were included in the Append-only Log of a specific Transparency Service. Implementers are cautioned that maintaining the order of Receipts in the unprotected header is essential for uniquely identifying a Signed Statement with a specific series of Receipts in its unprotected header. </ins> 6.