Original text:
<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>  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> 

Reviewer comments:
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.
Met with NAME and we discussed perspectives and work on this in the near-term, summarized with URL More to follow.
Adding some more notes to plot out the work, Monty and I discussed aligning the diagram with the separate/distinct RATS architecture, but the separate call out of a distinct Relying Party role and how it pertains to agent was discussed when we met, per discussion I missed in today's author/editor meeting. For my future reference, I need to re-review the doc, as well as compare/contrast ,
So I did not make as much tangible progress today and have spent a lot of time thinking and reading as I re-read this SCITT Architecture draft and related WG drafts (RATS, OAuth) where Relying Party is defined. So, before I spend a significant effort in drawing this with aasvg, I would like to quickly highlight the gaps in my understanding via Mermaid so I can quickly iterate. I have tried reading the mailing list but it not 100% clear where the dichotomy between Auditor and Verifier occurred, but they seem overlapping and redundant to me unless Verifier is, in fact, some non-person entity, like the software doing the verification itself (so this goes to what should we rename client to in , separate of this), but does that not in fact mean Auditor is the Relying Party of sorts? It seems Auditor is just giving a specific name to a general kind of consumer and that is not what a Verifier is. So on that note, this is the current version of the SVG diagram in Mermaid ( I hope I got this right, I cannot just have labels like "Issuer" on the left-hand side so I use subgraphs to box those and not do something clever with dotted lines and cause more problems). (Source: URL) It would seem we really need to change the diagram and the terminology to get rid of Auditor altogether, so first, we would move to this. (Source: URL) I was going to do a subsequent edit, but at this point I will have to ask the group: what is a verifier doing that is different from a relying party owner with a relying party? Could you separate one from the other? (Don't you need to replay the log to verify the sequence of statements?) For reference, there is so much overlap with I think we need to either add compare statements to terminology and touch up the current state diagram to disambiguate the use of these terms. Screenshot below. ! So would that mean, if they are in fact separate, Edit 2 incrementing after Edit 1 to reflect my understanding would be ... this? (Source: URL) If we start to think this way, do we consider the software (client/agent/what have you) used by the Issuer to be distinct? Similar but with one of two functionalities (an agent/client/what have you can be for Issuers to get receipts of signed statements or a verifier that reads all of them)? /cc NAME I am not sure this update at the end of the day reflects our discussion, but I feel like I lost the thread of what we discussed and seemed concrete in discussion. Translating it into diagram and wording updates has left me scratching my head.
And just for the sake of dissing RATs... ! IMO this is reversed... to rely on something you must trust a verifier or be a verifier. I think what they mean is for the relying party to depend on a verifier, but what it looks like is that a verifier sits in front of an RP.
A verifier can be a person or automation that was configured by a person. This is likely a great conversation for the NAME would you be able to lead that discussion with NAME
hm... if we are talking RATS an entity can take on both the Roles of Verifier and Relying Party at the same time (rendering the creation and conveyance of Attestation Results moot)
It seems now obsoletes the diagrams in URL and review in a previous meeting reflecting improvements and viable changes based upon answers to the questions posed in strawman diagrams in that comment.
Also of not my updates to the potential (and beneficial) overlap and possible alignment between relying party and client per URL
Ping NAME NAME
I wrote some of my thoughts on URL and aj-stein-nist/ietf-wg-scitt, but for me Client was going to replace Relying Party (Client==RP), so I am not sure if making Verifier==RP is what my intent was when I revived the issue, so I will leave to others to decide.

Revised text:
 <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  <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>