Improve description for Figure 1 #300
Conversation
aj-stein-nist
requested review from
henkbirkholz,
ad-l,
fournet,
yogeshbdeshpande,
SteveLasker,
JAG-UK and
OR13
as code owners
| {{fig-concept-relationship}} illustrates entities and processes that comprise a Transparency Service independent of any one use case. | ||
| There are three main entities and their associated processes in SCITT: | ||
|
|
||
| * Issuers that use Statements about Artifacts and their credentials to create Signed Statements |
There was a problem hiding this comment.
| * Issuers that use Statements about Artifacts and their credentials to create Signed Statements | |
| * Issuers that use their credentials to create and register Signed Statements about Artifacts |
There was a problem hiding this comment.
I would prefer my edit. I specifically used those phrases to align with the different sections of the diagram because the request was to explain and reference it in the text, removing some of the words and terms misses the requirement.
If not, I would have been less wordy, believe you me. 😄
There was a problem hiding this comment.
I see you're trying to encompass Issers make a Statement about an Artifact, use their credentials to create a "Signed Statement", then register them. It just reads longer than needed. The sentence prior was trying to define the three roles. In the call, there was resistance to redefining roles as entities.
I've updated the suggestion a bit, which acknowledges a statement becomes a signed statement, with minimal text.
| There are three main entities and their associated processes in SCITT: | ||
|
|
||
| * Issuers that use Statements about Artifacts and their credentials to create Signed Statements | ||
| * Transparency Services that register Signed Statements and Transparent Statements and in doing produce Receipts |
There was a problem hiding this comment.
Removed the reference to Transparent Statements as those are assembled on the client
| * Transparency Services that register Signed Statements and Transparent Statements and in doing produce Receipts | |
| * Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration |
There was a problem hiding this comment.
I disagree with this loss of capabilities. A ledger should be able to take a transparent statement from another ledger and handle it as well.
There was a problem hiding this comment.
While accurate, a Signed Statement can be a previously Signed Statement with an attached receipt (Transparent Statement), it's not what the diagram currently shows.
The diagram shows a single signed statement being placed on one, two, or more Transparency Services. Each TS produces a receipt, which can be stapled into a single Signed Statement with two receipts.
The current text, nor the diagram cover the scenario of a Transparent Statement being re-registered. That could be a separate PR if we want to load the diagram with more lines.
The other suggested change describes the Signed Statement must be first evaluated against a registration policy before it's successfully registered.
| There are three main entities and their associated processes in SCITT: | ||
|
|
||
| * Issuers that use Statements about Artifacts and their credentials to create Signed Statements | ||
| * Transparency Services that register Signed Statements and Transparent Statements and in doing produce Receipts |
There was a problem hiding this comment.
I disagree with this loss of capabilities. A ledger should be able to take a transparent statement from another ledger and handle it as well.
|
Editors call notes:
If the PR can maintain the roles, and add diagram clarity, that would be preferred. |
| @@ -326,6 +326,16 @@ The SCITT architecture consists of a very loose federation of Transparency Servi | |||
| In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. | |||
| Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document {{-COMETRE}}. | |||
|
|
|||
| {{fig-concept-relationship}} illustrates entities and processes that comprise a Transparency Service independent of any one use case. | |||
| There are three main entities and their associated processes in SCITT: | |||
There was a problem hiding this comment.
| There are three main entities and their associated processes in SCITT: | |
| This section describes the three main roles and associated processes in SCITT: |
| {{fig-concept-relationship}} illustrates entities and processes that comprise a Transparency Service independent of any one use case. | ||
| There are three main entities and their associated processes in SCITT: | ||
|
|
||
| * Issuers that use Statements about Artifacts and their credentials to create Signed Statements |
There was a problem hiding this comment.
I see you're trying to encompass Issers make a Statement about an Artifact, use their credentials to create a "Signed Statement", then register them. It just reads longer than needed. The sentence prior was trying to define the three roles. In the call, there was resistance to redefining roles as entities.
I've updated the suggestion a bit, which acknowledges a statement becomes a signed statement, with minimal text.
| There are three main entities and their associated processes in SCITT: | ||
|
|
||
| * Issuers that use Statements about Artifacts and their credentials to create Signed Statements | ||
| * Transparency Services that register Signed Statements and Transparent Statements and in doing produce Receipts |
There was a problem hiding this comment.
While accurate, a Signed Statement can be a previously Signed Statement with an attached receipt (Transparent Statement), it's not what the diagram currently shows.
The diagram shows a single signed statement being placed on one, two, or more Transparency Services. Each TS produces a receipt, which can be stapled into a single Signed Statement with two receipts.
The current text, nor the diagram cover the scenario of a Transparent Statement being re-registered. That could be a separate PR if we want to load the diagram with more lines.
The other suggested change describes the Signed Statement must be first evaluated against a registration policy before it's successfully registered.
Closes #268.