jiebi/CodeConvo huggingface dataset:
Code change:
With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1

Related discussion:
text: Many Issuers issue Signed Statements about different Artifacts under the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed <del> Statments what Artifact it is referring to.  This information is </del> <ins> Statements what Artifact it is referring to.  This information is </ins> stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same
Code change:
With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1

Related discussion:
text: COSE Envelope of the Signed Statement.  The key of the map entry corresponds to the name of the policy, while its value (including its type) is policy-specific.  For instance, the "register_by" policy <del> defines the maximum timestamp by which a Signed Statemnet can be </del> <ins> defines the maximum timestamp by which a Signed Statement can be </ins> registered, hence the associated value contains an unsigned integer. While this design ensures that all verifiers get the same guarantee
Code change:
With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1

Related discussion:
text: details. Some Verifiers may systematically resolve Issuer DIDs to fetch the <del> latest corresponding DID documents.  This behaviour strictly enforces </del> <ins> latest corresponding DID documents.  This behavior strictly enforces </ins> the revocation of compromised keys: once the Issuer has updated its Statement to remove a key identifier, all Signed Statements include the corresponding "kid" will be rejected.  However, others may
Code change:
NAME PTAL
Since the use of COSE is mandatory, shouldn't this be MUST? Originally posted by NAME in URL
It would seem more appropriate to just say , rather than introduce the notion of a "standard COSE implementation". The latter would seem to involve a need to have a certification program for COSE implementations or something unnecessarily involved like that. I don't follow the implications of this. Can it be spelled out some more? I'll also note LGTM!

Related discussion:
text: latest version, Issuers SHOULD use the "sequence_no" or "issuer_ts" attributes. <del> Once all the Envelope headers are set, an Issuer SHOULD use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed </del> <ins> Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed </ins> Statement). 6.3.
Code change:
NAME Incorporated Review Comments!
Thanks NAME lets see if we can agree on append-only log|registry today so we can adapt and merge.
For the sake of clarity, suggesting "append only log"
LGTM

Related discussion:
text: Signed Statement Issuers rely on being discoverable and represented as the responsible parties for their registered Signed Statements via <del> Transparency Services in a believable manner.  Analogously, </del> <ins> Transparency Services in a believable manner.  The issuer of a Signed Statement should be authenticated and authorized according to the registration policy of the transparency service.  Analogously, </ins> Transparent Statement Consumers rely on verifiable trustworthiness assertions associated with Transparent Statements and their processing provenance in a believable manner.  If trust can be put <del> into the operations that record Signed Statements (i.e., a believable notarization function) in a secure, append-only Registry via online operations, the same trust can be put into a corresponding Receipt that is the resulting documentation of these online operations issued by the Transparency Services and that can be validated in offline operations. </del> <ins> into the operations that record Signed Statements in a secure, append-only log via online operations, the same trust can be put into the resulting transparent statement, issued by the Transparency Services and that can be validated in offline operations. </ins> The Transparency Services specified in this architecture can be implemented by various different types of services in various types
Code change:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Related discussion:
text: components are based on the Concise Signing and Encryption standard specified in RFC9052, which is used to sign released Statements about Artifacts and to build and maintain a Merkle tree that functions as <del> an append-only Registry for corresponding Signed Statements.  The format and verification process for Registry-based transparency receipts are described in I-D.birkholz-scitt-receipts. </del> <ins> an append-only Registry for corresponding Signed Statements. </ins> 1.1.
Code change:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Related discussion:
text: of COSE, and used to indicate that a signed object is a Signed Statement). <del> 6.3. </del> <ins> 6.4. </ins> Transparency Service implementations MUST indicate their support for registration policies and MUST check that all the policies indicated
Code change:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Related discussion:
text: guarantee out of the registration policies regardless of where it is registered. <del> 6.4. </del> <ins> 6.5. </ins> The same Signed Statement may be independently registered in multiple Transparency Services.  To register a Signed Statement, the service
Code change:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Related discussion:
text: re-issue Receipts for the Registry content, for instance after a transient fault during Signed Statement Registration. <del> 6.5. </del> <ins> 6.6. </ins> This section provides additional implementation considerations.  The high-level validation algorithm is described in validation; the <del> Registry-specific details of checking Receipts are covered in I- D.birkholz-scitt-receipts. </del> <ins> Registry-specific details of checking Receipts are covered in -COMTRE. </ins> Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency
Code change:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Related discussion:
text: Error code: "entryNotFound" The retrieved Receipt may be embedded in the corresponding COSE_Sign1 <del> document in the unprotected header, see draft-birkholz-scitt-receipts (TODO [1]: replace with final reference). </del> <ins> document in the unprotected header. </ins> 9.
Code change:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Related discussion:
text: Repository: http://www.iana.org/assignments/scitt Index value: No transformation needed. <del> 12.  References 12.1.  URIs [1] more error codes to be defined, see [#17](https://github.com/ ietf-wg-scitt/draft-ietf-scitt-architecture/issues/17) </del>
Code change:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Related discussion:
text: in how each Transparency Service is implemented and operates.  Each service MAY enforce its own Registration Policy for authorizing entities to register their Signed Statements to the append-only Log. <del> Some Transparency Services may also enforce role based access control (RBAC) policies limiting who can write, read and audit specific Feeds or the full Registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is ever-changing and always in flux. </del> <ins> Some Transparency Services may also enforce authorization policies limiting who can write, read and audit specific Feeds or the full registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is ever-changing and always in flux. </ins> A Transparency Services provides visibility into Signed Statements associated with various supply chains and their sub-systems.  These
Code change:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Related discussion:
text: Signed Statement about an Artifact.  Issuers may Register new Signed Statements about Artifacts, but they cannot delete or alter Signed Statements previously added to the append-only Log.  A Transparency <del> Service may restrict access to Signed Statements through Role Based Access Control, however third parties such as Auditors would be </del> <ins> Service may restrict access to Signed Statements through access control policies.  However, third parties (such as Auditors) would be </ins> granted access as needed to attest to the validity of the Artifact, <del> Feed or entirety of the Transparency Service. </del> <ins> Feed or the entirety of the Transparency Service. </ins> Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication,
Code change:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Related discussion:
text: The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for <del> issuing, registering and auditing Transparent Statements. </del> <ins> issuing, registering Signed Statements and auditing Transparent Statements. </ins> In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed
Code change:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Related discussion:
text: Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle-tree- proofs. <del> In this section, a high level the three main roles and associated processes in SCITT: Issuers and the Signed Statement issuance process, transparency Registry and the Transparent Statement Registration process, as well as Verifiers and the Receipt validation process. </del> <ins> This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and the Signed Statement issuance process, Transparency Service and the Signed Statement Registration process, as well as Verifiers of the Transparent Statements and the Receipt validation process. </ins> 5.1.
Code change:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Related discussion:
text: Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the <del> history of Transparent Statements registered by a given Issuer via a </del> <ins> history of Signed Statements registered by a given Issuer via a </ins> certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints; as much as practical, the Registry SHOULD contain enough
Code change:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Related discussion:
text: the Transparency Service Registration Policy and that has been persisted in the Registry.  Unless advertised in the Transparency Service Registration Policy, the Verifier should not assume that the <del> ordering of Transparent Statements in the Registry matches the ordering of their issuance. </del> <ins> ordering of Signed Statements in the Registry matches the ordering of their issuance. </ins> Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or