[{"author": "Cedric Fournet", "text": "

Why would we need to surface the gatekeeper in a standard, as opposed to a fine local implementation choice?

", "time": "2023-02-27T16:30:13Z"}, {"author": "Henk Birkholz", "text": "

@cedri: that is an excellent scope question

", "time": "2023-02-27T16:31:20Z"}, {"author": "Steve Lasker", "text": "

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/7 is expanded upon here:
\nhttps://scitt.io/distributing-with-oci-scitt.html#distributing-
\nwith-oci-registries-with-scitt-enhancements

", "time": "2023-02-27T16:32:18Z"}, {"author": "Roy Williams", "text": "

My preference is that the validation of the signature gates the transaction of the data to storage. This stops SPAMMIN anonymously. The belief that the storage iteration is looking at data that went through that bar.

", "time": "2023-02-27T16:32:42Z"}, {"author": "Cedric Fournet", "text": "

I'd argue registration policy is the main concept here, with the main requirement that it needs to be enforced before recording in the log and receipt issuance. Conversely the name of the internal component that enforces it seems less important here.

", "time": "2023-02-27T16:35:13Z"}, {"author": "Roy Williams", "text": "

If you think about transactions, the data + signature are tied at submission. The feed of data into a SCITT instance may be over a federated factory pipe. Think GitHUB or AWS build services are authenticated to submit the content, but the content is user or product specific.

", "time": "2023-02-27T16:35:35Z"}, {"author": "Roy Williams", "text": "

This means that there is a distinction between contracted factory and product owner scenario needs to be kept. As we found the cost of setting up and maintaining secure build services and evidence collection may be too complex for most and will open up a mode where a factory can fulfill that role.

", "time": "2023-02-27T16:37:16Z"}, {"author": "Steve Lasker", "text": "

I had an alternate version of the drawing that showed the eNotary calling out to \"the cloud\" to verify the identities.

", "time": "2023-02-27T16:37:25Z"}, {"author": "Steve Lasker", "text": "

It was just too dense for the focus.

", "time": "2023-02-27T16:37:53Z"}, {"author": "Cedric Fournet", "text": "

I am still struggling with the need to separate 1 and 2 in the picture. Unless of course they are not 1-to-1.

", "time": "2023-02-27T16:39:16Z"}, {"author": "Cedric Fournet", "text": "

May I suggest we schedule a separate discussion of registration policies? This is interesting but not terminology.

", "time": "2023-02-27T16:44:37Z"}, {"author": "Dick Brooks", "text": "

A Transparency Service Operator needs to specify the policies that dictate when type of statements can be placed into their Registry. The TS needs to perform a Gatekeeper role to ensure that policies are being followed.

", "time": "2023-02-27T16:45:10Z"}, {"author": "John Andersen", "text": "

Sorry, forgot about the queue

", "time": "2023-02-27T16:47:16Z"}, {"author": "Steve Lasker", "text": "

Just a point of discussion, Cedric brings up the point that we've off of the current topic on terminology

", "time": "2023-02-27T16:47:17Z"}, {"author": "Jon Geater", "text": "

+1 we definitely need these identity concepts separated

", "time": "2023-02-27T16:50:49Z"}, {"author": "Dick Brooks", "text": "

Registry integrity is teh responsibility of the Gatekeeper role. This is how it works today with REA's SAG-CTR. Evidence is submitted to the Gatekeeper, which is evaluated and, if it passes, an entry is placed in the SAG-CTR registry, that consumers query.

", "time": "2023-02-27T16:52:23Z"}, {"author": "Henk Birkholz", "text": "

Neal is next

", "time": "2023-02-27T16:52:48Z"}, {"author": "Steve Lasker", "text": "

I've got a hard stop at the top of the hour...

", "time": "2023-02-27T16:58:07Z"}, {"author": "Steve Lasker", "text": "

I need to drop.
\nThanks folks, and looking forward to the discussion on the list and PR:

", "time": "2023-02-27T17:01:08Z"}]