Code change:
and
In section 5.2.3.3 appears out of the blue. It is not clear what a is.
Hi, NAME I'm looking for the reference to 5.2.3.3 in URL and other versions. I don't see where that section exists. Are you referring to a reference where a client is calls the Transparency Service APIs? Or, as there a mention of "client, synonymous with consumer, verifier, etc?
E.g., Is the client the issuer itself? A piece of software that the issuer uses (e.g., a la OAuth2 client)? Does it refer to any role (issuer, verifier, auditor)? IMHO the text should be more specific, e.g., Certificate Transparency RFC explicitly mentions
Thanks, NAME The above text is from Draft 04: I've labeled it for terminology clarification.
In that vein, I would support clarifying it with a "an Issue or Verifier's Transparency Service API client" in the applicable areas of the draft. Would that be more helpful or does it not reduce ambiguity?
Just an update, I plan to send a PR with proposed changes this week.
From the architecture/editors meeting Differentiating: Issuer who signs the statement (The identity of the software component - Wabbit Networks) Client who initiates the registration operation, which encompasses RBAC which is not part of the spec, beyond being authenticated (the build system's identity for access control. The build system has a role to perform operations) - possibly refer to OAuth's definition of client Verifier who evaluates a statement. The verifier cares about the issuer, to know it was signed by a particular issuer. The audit of a supply chain will check the identities involved in the operations.
AJ and I will review this
NAME and I met today to discuss a recap of the authors/editorial meeting (sorry I missed) and how we need to think about 1) a better alternative name and 2) provide a rationale to why we need to have 1, terminology change or not (part of that is the subject of this issue and pending work that should come up in for the latter). For 1, Monty and I are leaning towards agent for now, but we need to brainstorm on adjusted architecture to reflect 2 and "the way" and how it relates to requested edits for the relying party issue in . 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

Related discussion:
text: 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>