jiebi/CodeConvo huggingface dataset:
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: Append-only Log, some Transparency Services may provide limited support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent <del> Registration or Issuer equivocation. </del> <ins> Registration or Issuer Equivocation. </ins> Verifiers and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: to notify Transparency Services of credential revocation to stop Verifiers from accepting Signed Statements signed with compromised credentials.  Issuers SHOULD register new Signed Statements <del> indicating the revocation, using the same "13" CWT "iss" and "sub" </del> <ins> indicating the revocation, using the same "15" CWT "iss" and "sub" </ins> claims. The confidentiality of any identity lookup during Signed Statement
Code change:
simplified a few references & added a WG, some reordering
Thanks, NAME
A small fix and then it will be ready to it.LGTM!LGTM

Related discussion:
text: <del> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </del> <ins> (label: "15" pending CWT_CLAIMS_COSE): A CWT representing the </ins> Issuer ("iss") making the statement, and the Subject ("sub") to correlate a collection of statements about an Artifact. Additional CWT_CLAIMS MAY be used, while "iss" and "sub" MUST be
Code change:
This PR elaborates on the privacy analysis a bit. Describe why it is important (because we cannot delete items from the log) Remove the BCP 14 keyword (MUST NOT). Both the Privacy and Security Considerations sections should have the character of an analysis. They should be recommendations, or highlight gotchas to implementors. Anything binding should be in the main body of the RFC. Yes, this would need to be fixed in the Security Considerations, too. Expand the "Unless advertised by a Transparency Service" phrase into a paragraph about access control. This way it's more actionable. (Why would you advertise it? When would it be okay to advertise?)
Authors: (NAME NAME NAME NAME NAME I'm inclined to merge this as is. Any disagreements, or additional changes? We can iterate afterward, but seems like a good baseline to add
Yes. this looks pretty stable and uncontroversial. Thanks a ton, NAME

Related discussion:
text: 8. <del> Unless advertised by a Transparency Service, every Issuer must treat Signed Statements it registered (rendering them as Transparent Statements) as public.  In particular, a Signed Statement Envelope and Statement payload MUST NOT carry any private information in </del> <ins> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in </ins> plaintext. <ins> Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </ins> 9. On its own, verifying a Transparent Statement does not guarantee that
Code change:
This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures

Related discussion:
text: 10.1. This section requests registration of the following media types <del> [@RFC2046] in the "Media Types" registry [@IANA.MediaTypes] in the manner described in [@RFC6838]. </del> <ins> RFC2046 in the "Media Types" registry IANA.media-types in the manner described in RFC6838. </ins> To indicate that the content is an scitt configuration represented as JSON:
Code change:
This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures

Related discussion:
text: encoding SHOULD be employed for the JSON object. Security considerations: See the Security Considerations section <del> of [[ this specification ]]. </del> <ins> of TBD. </ins> Interoperability considerations: n/a <del> Published specification: [[ this specification ]] </del> <ins> Published specification: TBD </ins> Applications that use this media type: TBD
Code change:
This is a simple dependency management PR to decouple SCRAPI from the architecture spec. See SCRAPI can be a layer above, and reference the architecture (dependency) as in HTTP implementation. Decoupling allows us to move forward with the architecture doc, continuing to iterate on SCRAPI independently.

Related discussion:
text: enforcing a Registration Policy.  It also maintains a service key, which is used to endorse the state of the Append-only Log in Receipts.  All Transparency Services MUST expose standard endpoints <del> for Registration of Signed Statements and Receipt issuance, which is described in TODO: scrapi.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </del> <ins> for Registration of Signed Statements and Receipt issuance.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </ins> The combination of Identity, Registration Policy evaluation, and the Transparency Service endpoint constitute the trusted part of the
Code change:
Looking at URL, I think a that some more diverse examples later that show how multiple statements about one Artifact using the same sub Claim can have different semantics than multiple statements about one Artifact using different sub Claims - including illustrating text when one choice can be used an when the other & pros and cons.
Covered above
LGTM

Related discussion:
text: 5.1.3. <ins> An Issuer can make multiple Statements about the same Artifact.  For example, an Issuer can make amended Statements about the same Artifact as their view changes over time. Multiple Issuers can make different, even conflicting Statements, about the same Artifact.  Verifiers can choose which Issuers they trust. Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. 5.1.4. </ins> SCITT payloads are opaque to Transparency Services.  For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a
Code change:
Explains Feed as the logical collection, with (Subject) as the property to represent the collection.
That seems pretty reasonable to me. Are there any reasons to keep both?
While I'd agree less is more, this keeps coming back when we try to explain it. A feed is a known concept for a collection of related data We're using CWTClaims , which also makes sense to align with existing specs We avoided Artifact ID Attempting to describe a collection of statements as a subject doesn't resonate. We can keep Feed as the concept, and simply say CWTClaims is how you set an identifier for the feed. How does that work?
Then we should deprecate the term feed in discussions, too, and just explain how a subject is used as a subject in this context?
Updated to merge in PR feedback
NAME NAME NAME PTAL as I've made some updates.

Related discussion:
text: are capitalized.  To ensure readability, only a core set of terms is included in this section. <ins> Verifiers use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating. </ins> 4. In this document, the definition of transparency is intended to build
Code change:
!
The diagram reflects my intention.
Here's a slightly modified view to remove the lines behind, add arrows consistenty !

Related discussion:
text: are capitalized.  To ensure readability, only a core set of terms is included in this section. <ins> The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052. </ins> 4. In this document, the definition of transparency is intended to build
Code change:
Reverts ietf-wg-scitt/draft-ietf-scitt-architecture

Related discussion:
text: are capitalized.  To ensure readability, only a core set of terms is included in this section. <del> Verifiers use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating. </del> 4. In this document, the definition of transparency is intended to build
Code change:
A set of consistency fixes for the next draft.
See URL for discussion on the terminology.
The doc uses the three interchangeably Is there a preferred reference to be consistent?
URL is about Media Type. And then references payload and content type. I've been through this confusion before, where Media Type is the definition of a type of identifier. The challenge becomes when using that type of identifier for different parts of a document. When does the media type refer to the envelope itself? When does the media type refer to a property (aka payload)?
I don't understand the question. is of content type and . It is generally a good idea to use a more specific media type. The payload of a cose-sign1 can have a media type, such as or .
It cuts out cruft, so I support this edit, just one minor nit (take or leave it, it's minor to me), before moving onto .

Related discussion:
text: CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> SCTs are checked by browsers (Verifiers) </del> <ins> Signed Certificate Timestamps are checked by Verifiers. </ins> <del> The Append-only Log can be checked by Auditors Note that just like CT logs are independent and their contents need not be consistent, Transparency Services are similarly independent of each other. </del> <ins> The Append-only Log can be checked by Verifiers and Auditors </ins> 3.
Code change:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Related discussion:
text: Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent <del> Statements registered by each Issuer.  However, the Registrations of </del> <ins> Statements registered by each Issuer.  However, the Registrations on </ins> separate Transparency Services are generally disjoint, though it is <del> possible to take a Transparent Statement from one Transparency Service and register it again on another (if its policy allows), so the authorization of the Issuer and of the Transparency Service by the Verifier of the Receipt are generally independent. </del> <ins> possible to take a Transparent Statement, a Signed Statement with a Receipt from the first Transparency Service in its unprotected header, and register it on another Transparency Service, where the second receipt will be over the first Receipt in the unprotected header. </ins> Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements.
Code change:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Related discussion:
text: Receipts for the software and configuration of the service, as measured in its attestation report. <del> 5.2.2. The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL </del> 5.2.3. <del> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would provide limited to no value to Verifiers.  More advanced use case will rely on the Transparency Service performing additional domain- specific checks before a Signed Statement is accepted.  For example, some Transparency Services may validate the non-opaque content (payload) of Signed Statements. </del> Registration Policies refers to the checks that are performed before <del> a Signed Statement is registered given a set of input values.  This specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </del> <ins> a Signed Statement is added to an append only log, and a corrosponding receipt becomes available. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As
Code change:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Related discussion:
text: 7. <del> : This topic is still under discussion, see issue 79 [2] </del> <ins> : This topic is still under discussion, see issue 79 [1] </ins> Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single,
Code change:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Related discussion:
text: use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <ins> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE). The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance (pBFT PBFT) and may be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. </ins> 9.1. SCITT provides the following security guarantees:
Code change:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Related discussion:
text: 11.1.  URIs <del> [1] https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry [2] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </del> <ins> [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </ins> issues/79
Code change:
In case there is no rough consensus to keep federation section, I raised URL to remove it.
I'd suggest we've had a few different conversations about federation of everything in a transparency service, vs. selective promotion of a subset of information across Transparency Services. The later being the ability for a consumer of one or more Transparency Services to promote the content for a subset of their software. Microsoft ships lots of software, However a consumer may only want to promote the Office suite of products into their Transparency Service for internal validation. I'd suggest the wording, as current, isn't well defined and I'd vote to cut this section until more well defined.
If this PR is dropped then we should create an issue to address the underspecification of unpotected headers at registration, especially the idea to preserve unprotected headers. Federation is a simple use case that highlights this problem
Its not simple, and we have seen no implementation support for it to date.
If we are at the point where we need to start from scratch on configuration/registration policy and scrap the initialization section, I personally do not see how we can keep federation and not just remove it (not to drive you and others mad, we can always add back later).I think the new text is too specific. To me (and as in the prior text) Federation refers to having multiple TS, and one TS accepting receipts from another TS at registration time is just an advanced case, for which we don't have clarity yet. As discussed earlier, letting the TS decide what unprotected headers to authenticate in its receipts is a major complication. My preference would be (1) keep a general placeholder on Federation --- better than nothing; or else (2) cut the section. But this leaves many questions unanswered, starting with the two TS in the arch diagram.

Related discussion:
text: Change Controller: IETF Provisional registration?  No <del> 9.  References 9.1.  URIs [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/79 </del>
Code change:
Retains the concepts and many of the same words as before, but addresses concerns form the mailing list and interim call
I've merged in suggestions. Please re-review, with LGTM or actionable suggestions.
yesLGTM

Related discussion:
text: 4.1. <del> An important function of a Transparency Service is to maintain Registration Policies for the Append-only Log.  The Append-only Log is the verifiable data structure which registers Signed Statements and supports the production of Receipts. </del> <ins> Transparency Services MUST feature an Append-only Log.  The Append- only Log is the verifiable data structure that registers Signed Statements and supports the production of Receipts. </ins> All Transparency Services MUST expose APIs for the registration of Signed Statements and issuance of Receipts.