Code change:
4.2.1. <del> The same Signed Statement may be independently registered in multiple Transparency Services.  To register a Signed Statement, the Transparency Service performs the following steps: </del> <ins> To register a Signed Statement, the Transparency Service performs the following steps: </ins> <del> This is implementation-specific and MAY be unrelated to the Issuer identity.  Signed Statements may be registered by a different party than their Issuer. </del> <ins> A Client authenticates with the Transparency Service, to Register Signed Statements.  Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </ins> The Transparency Service MUST perform resolution of the Issuer's <del> identity.  This step may require that the service retrieves the Issuer ID in real-time, or rely on a cache of recent resolutions. For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </ins>

Related discussion:
text: We will post in progress work and continue to collaborate and sync, updating the WG via mailing list when it is ready for review and feedback across the WG. More to follow.
Thanks, NAME NAME for the focused discussion.
OK, my work on also led me to be confused and think maybe we have meant agent/client when we said verifier. I made some strawman diagrams to discuss this WG members in URL /cc NAME
OK, it seems we are converging in a direction on around verifier and relying party. The diagram based on author feedback demonstrates that with likely updates to the spec forthcoming if that is approved. It turns out, not surprisingly, we need both verifier and relying party. The latter, if tweak terminology, could more clearly refer to client and resolve this issue as well. Given that, and how it relates to here, I would argue that relying party is the correct substitute for client and this could be closed as a duplicate or modified accordingly to address that. This change would be in line with with the RATS specification iff we distinguish between Verifier Owner/Verifier (person entity/logical system for that entity) and Relying Party Owner/Relying Party (person entity/logical system for that entity) and ironically , various OAuth WG drafts (even if it seems not formally defined), and . It was unclear in previous discussion with authors if this is preferable or required, but it nicely aligns with small tactical changes to the diagram in and relevant spec alignment in terminology and explanations.
Still active. NAME do you have time to complete this item?
I had presented on this topic and we had agreed some key revisions had to take place before we could decide to make adjustments. Are we at that point? Additionally, the alignment with RATS and other specs: is this necessary or not? There are some open questions that are not covered, re URL I guess I will take it to the list.
good enough