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: 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 .