Please consider defining a "Gatekeeper" Role with a Transparency Service operation

[rjb4standards]

A Gatekeeper role is needed to ensure that only verified materials, based on registration policy criteria, are placed into a Transparency Service Registry and Log.

[rjb4standards]

Issue posted.

[SteveLasker]

Thanks, @rjb4standards What you're describing is a registration policy, which the Transparency Services Registration/Notary would enforce.
Is there some additional info needed?

[rjb4standards]

Steve, a registration policy is the basis upon which trust is established. The registration policy must make clear that a high integrity and thorough vetting process is enforced before any material is allowed into the registry and any rejections are recorded, outside of the transparency service log along with justification. That's how BCG views and implements the SAG-CTR registration policy. Proper registrations are recorded in the registry and improper requests are rejected and documented. This provides a complete view of the Transparency Service process for accepting/rejecting signed receipts, based on registration policy criteria.

[rjb4standards]

It's important to distinguish the functions performed by each "Auditor Role". During signed statement processing the role is required to enforce registration policies, ensuring that only proper materials are being recorded in the Registry and improper filings are being properly rejected. This Auditor Role has the authority to approve changes/additions to the Registry Log. ( I refer to this as the Gatekeeper role)

After statements are validated against registration policies and data is placed in the Registry, on the Log, the Auditor Role is to verify that registration policies are being properly applied and notify proper authorities when there are violations. This Auditor Role has no authority to make changes/additions to the Registry Log.

[SteveLasker]

Thanks, @rjb4standards, There are few main points I'm seeing here:

• Definition of the entity that defines Registration Policies
• Elements that are implementation-specific. An instance of a Transparency Service will be a "Trust Registry" for its defined scope (Financial, Gaming, Emergency Management, M5 Screws, ...)
• What is captured for rejections? This is a very interesting point as "Transparency" for what's rejected could be just as important as what's accepted. It's been vaguely discussed, but no content in the Architecture or SCRAPI address this, yet.

I'd suggest bringing this up in one of the next meetings, and/or provide a PR to address the rejection of signed statements scenario.

[SteveLasker]

@rjb4standards, The issue as titled, does reflect the registration portion of the spec. I'd like to close this Issue, as titled, and ask you open a new issue, or start a new discussion about capturing the denied registration. It might almost be obvious we need ledger entries to capture declines. There's a line of DOS type flooding attacks, but seems there's something we should take as an output.

[rjb4standards]

It's not just rejections that need to be captured in order to have a "closed loop" process. Ideally, each request to register a signed statement needs to be tracked and the status recorded in order to conduct a proper audit against the "registered" signed statements in the log to verify that the log and the "tracker process" match. Rejected requests would appear in the tracker as rejected. Accepted requests would appear as approved.

This would produce a high integrity, closed loop process, needed for a trustworthy, auditable registration service. Integrity of the registry is key to its success.

Close this issue if you are compelled to do so and I can open a new issue later to address this matter.

[SteveLasker]

• Accepted Registrations: The accepted are captured as they are registered. I believe we've covered that from an Architecture, and a product can implement that.
• Rejected Registrations: These are not currently covered in the architecture and could be covered by a product, but I do see the value in specifying rejections should be captured. I think that's the most actionable thing from this discussion that I'd personally encourage and support a PR for. That said, I don't think this issue as titled and initially discussed fit that, which is why I'm suggesting creating an Issue/PR specific to rejected registrations. I also encourage others to comment.