Code change:
<del> 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. </del> <ins> A client application authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more issuers. 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, 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. </del> <ins> 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: This is an alternate proposal to to This PR: Keeps Client as : an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization. Replaces Verifier with Relying Party: a relying party depends on Signed or Transparent Statements to verify an Artifact.,
Thanks, NAME Definitely looking for more input, and I’m also ok to close the PRs and issue and use the existing terminology. My main concern is a Relying Party is a consumer of information. They rely on the receipts and signed statements from the Transparency Service. Which makes it a good candidate to replace Verifier If we replace Client with Relying Party, this confuses what we call the entity that registers signed statements. They are not the issuer, as the issuer signs statements, but is not the entity with access rights to the Transparency Service. Both the producer and consumer need access rights. That was what we had as client.
There is still additional work that needs to be done. Client applications submit signed statements, and obtain receipts, so they can include transparent statements in downstream products. A consumer of a downstream product is a relying party, they either verify the transparent statements themselves, or they delegate the verification role to the "verifier" role.
As discussed on today's call. Folks expressed concern that "Verifier" was not friendly enough to "Consumers or Relying Parties", that are supposed to process receipts. Editors Update: We can choose to: [ ] Accept [ ] Accept [ ] Close both PRs and this issue, and keep the doc with Client and Verifier
NAME wanted to take a look for a proposal
Just an update, I plan to send a PR with proposed changes this week. NAME shall we sync up in the comments or out of band elsewhere?
A.J. Yes, let’s get together and work out a proposal. I’m booked today but tomorrow is open except for 07:00-08:00 and 14:00-15:00 PST (10:00-11:00 and 17:00-18:00 EST) Monty
Sorry, NAME I had to dig a bit to find your email in my inbox from the mailing lists but I found it. Invite sent. I think we can make quick progress and draft a PR tomorrow.