jiebi/CodeConvo huggingface dataset:
Code change:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Related discussion:
text: Response: <del> 2.2.7. </del> <ins> 2.2.6. </ins> This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint.
Code change:
It's not clear why this would be needed, and it doesn't reflect any patterns in the Architecture. Remove?
NAME there's a reference to "proof of possession", so my guess it that this is meant to enable a flow where the client requests a nonce, includes it in the signed statement (protected header or payload) before signing and submission, to "prove" that they held the key at the time of submission, if it is substantially different from the time of signing. I agree that this should be removed because: It's poorly specified for its stated purpose, without mandatory transport-level security, it's possible to effectively DoS a client by using the nonce they requested quicker than they can. Without authentication, a malicious client can also spam the service for fresh nonce values, causing legitimate ones to fall out of the expiry window before they can be used. There is no mention of a scenario where this is helpful or necessary. If such a scenario emerges, where an issuer signs or has signed indiscriminately in advance, and it is desirable to be stricter about what can be made transparent, there are two easier mechanisms the registration policy can use that don't require an awkward stateful API extension such as this: in the signed statement a counter-signature with a submission control key (which may or may not be the same as one of the issuer keys) Neither requires additional API surface, nor creates additional DoS opportunities. Opened
agree to remove. I believe the intent for including that was the cnf claim in a cwt. But per URL it is for the protocol to define if and how a nonce should be used. Removing this does not preclude the use of cnf. And, at the same time, avoids under (or over) specifying in the wrong place.
Agree I don't believe this endpoint is necessaryLGTM

Related discussion:
text: Response: <del> 2.2.6. This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint. Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to demonstrate proof of possession, which is the reason that authentication is not required.  Client holding signed statements that require demonstrating proof of possession MUST use this endpoint to obtain a nonce. Request: Response: </del> 3. TODO
Code change:
Hackathon entry for 119, fill in required elements from RFC 3552
I merged the markdown nits, but left the suggestions that should be reviewed by others.
A bunch of Markdown Nits, and some questions on the correlation between Issuer and RBAC, but happy to merge and iterate through additional PRs

Related discussion:
text: URI suffix: issuer Change controller: IETF Specification document(s): RFCthis.  Related information: N/A <del> 5.3. </del> <ins> 6.3. </ins> The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785):
Code change:
Hackathon entry for 119, fill in required elements from RFC 3552
I merged the markdown nits, but left the suggestions that should be reviewed by others.
A bunch of Markdown Nits, and some questions on the correlation between Issuer and RBAC, but happy to merge and iterate through additional PRs

Related discussion:
text: TODO: Register them from here. <del> 5.4. </del> <ins> 6.4. </ins> This section requests registration of the "application/ scitt.receipt+cose" media type RFC2046 in the "Media Types" registry
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: SCITT architecture focuses on ensuring statement authenticity, visibility/transparency, and intends to provide scalable accessibility.  The following use case illustrates the scope of SCITT <del> and elaborate on the generic problem statement above. </del> <ins> and elaborates on the generic problem statement above. </ins> 3.
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: 3.2. <del> In IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. </del> <ins> In the IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. </ins> There are multiple such authoritative bodies that make such assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or <del> identity of the authoritative bodies adds a significant cost to the </del> <ins> identities of the authoritative bodies adds a significant cost to the </ins> end user or consumer of the product. A consumer of released software product wants:
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: entities to an entity who does it on their behalf to offload the burden to filter from and select all statements <del> that are applicable to a particular release of a multi release </del> <ins> that are applicable to a particular version of a multi release </ins> software product, to an entity who does this on their behalf to make an informed decisions on which authoritative entities to
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: statement on how to mitigate the vulnerability.  At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that <del> inhibits exploitation.  Later, A second update of the software </del> <ins> inhibits exploitation.  Later, a second update of the software </ins> product includes a security patch to the affected software component <del> from the software producer.  Finally, A third update includes a new </del> <ins> from the software producer.  Finally, a third update includes a new </ins> release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: to know where to get these security statements from producers and third-parties related to the software product in a timely and <del> unambiguous fashion, </del> <ins> unambiguous fashion </ins> <del> how to attribute them to an authoritative issuer, </del> <ins> how to attribute them to an authoritative issuer </ins> how to associate the statements in a meaningful manner via a set <del> of well-known semantic relationships, and </del> <ins> of well-known semantic relationships </ins> how to consistently, efficiently, and homogeneously check their <del> authenticity. </del> <ins> authenticity </ins> There is no standardized way to: <del> know the various sources of statements, </del> <ins> know the various sources of statements </ins> <del> how to express the provenance and historicity of statements, </del> <ins> how to express the provenance and historicity of statements </ins> how to related/link various heterogeneous statements in a simple <del> fashion, and </del> <ins> fashion </ins> check that the statement comes from a source with authority to <del> issue that statement. </del> <ins> issue that statement </ins> 3.4.
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: A consumer of a released software wants: to understand if a particular provider is actually the original <del> provider or a promoter, </del> <ins> provider or a promoter </ins> to know if and how the source, or resulting binary, of a promoted <del> software component differs from the original software component, </del> <ins> software component differs from the original software component </ins> to check the provenance and history of a software component's <del> source back to its origin, and </del> <ins> source back to its origin </ins> <del> to assess whether to trust a promoter or not. </del> <ins> to assess whether to trust a promoter or not </ins> There is no standardized way to:
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: artifact against a Reference Integrity Manifest (RIM).  Corresponding procedures are often called authenticated, measured, or secure boot. The output of these high assurance boot procedures is often used as <del> input to more complex verification known as remote attestation </del> <ins> input to more complex verifications known as remote attestation </ins> procedures. If measurements before execution are not possible, static after-the-
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: acquisition and deployment of software in certain security domains of the organization, a check of software quality and characteristics must succeed.  Compliance and requirement checking includes audits of <del> the results of organisational procedures and technical procedures, </del> <ins> the results of organizational procedures and technical procedures, </ins> which can originate from checks conducted by the organization itself or checks conducted by trusted third parties.  Consecutively, <del> consumers of statements about a released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews, certification documents (e.g., FIPS or Common Criteria), virus scans, vulnerability disclosure reports (fixed or not fixed), security impact or applicability justification statements.  Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats. </del> <ins> consumers of statements about released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews certification documents (e.g., FIPS or Common Criteria) virus scans vulnerability disclosure reports (fixed or not fixed) security impact or applicability justification statements Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats. </ins> A consumer of a released software wants:
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: compromised due to an insider risk - be it malicious or otherwise to confirm that the publishers know if their deliverable has been <del> compromised.  Can they trust their key protection or audit logging? </del> <ins> compromised.  (For example, can they trust their key protection or audit logging?) </ins> to know how the update client on an instance of a health monitoring system discerns a general update from one specially
Code change:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Related discussion:
text: of firmware revisions to verify that the firmware update seen by a single device, is <del> indeed the same as seen by all the devices. </del> <ins> indeed the same as seen by all the devices </ins> reliably discern an update that has been signed by the appropriate and intended signing identity make an informed judgement on all available information about <del> firmware at the install time.  For example, the firmware is still in a good state or otherwise? </del> <ins> firmware at the install time.  (For example, the firmware is still in a good state or otherwise?) </ins> 3.9. Software Integration is a complex activity.  This typically involves <del> getting various software components from multiple suppliers and </del> <ins> getting various software components from multiple suppliers, </ins> producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. <del> Consumer of an integrated software wants: </del> <ins> Consumers of an integrated software wants: </ins> all components presents in a software product listed, and the ability to identify and retrieve them from a secure and tamper-
Code change:
Provides baseline discussion for clarifying . See
Minor nits and there is no paragraph/subsection included in the proposed use case

Related discussion:
text: security scans of running software provide valid annotations on build integrity to ensure conformance <ins> 3.10. Software producers often have multiple and concurrent supported versions of a product.  The versions may represent major feature or compatibility differentiating releases (1.0, 2.0), or implementations for different Operating System Platforms and Architectures (Linux, Mac, Windows, AMD, ARM, x86, x64). For each release, the software producer must be capable of providing statements, unique to that version.  Producers may provide free patching to a specific version the consumer has purchased, while requiring upgrades to newer major releases.  Consumers need to know which updates are compatible with their environment.  Third parties that provide statements of quality need to know how to differentiate supported version bands, avoiding the recommendation to upgrade to an incompatible version. As versions age, and vulnerabilities are discovered, consumers need to know the newer version of a particular product.  Software producers implement versioning updates, however there are no standards for consumers and third parties to apply across software producers. Consumers and Producers want: a standard means to associate vulnerability information, statements of quality, statements of support and end of life (EOL) with a specific version of a product a standard means to identify a patched version, specific to their Operating System and Platform a standard means to differentiate major and minor version upgrades a standard means to provide concurrent versioned updates </ins>
Code change:
I believe this is a typo, but perhaps I misunderstood the intended meaning.
Good catch, NAME Thanks for the PR
LGTM

Related discussion:
text: must succeed.  Compliance and requirement checking includes audits of the results of organizational procedures and technical procedures, which can originate from checks conducted by the organization itself <del> or checks conducted by trusted third parties.  Consecutively, </del> <ins> or checks conducted by trusted third parties.  Consequently, </ins> consumers of statements about released software can be auditors. Examples of procedure results important to audits include:
Code change:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Related discussion:
text: host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. <del> It may be noted that just as you can plug several home routers together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </del> <ins> It may be noted that just as you can plug several CPEs together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </ins> The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support
Code change:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Related discussion:
text: described in RFC4861. Support for adjacent infrastructure links on networks where Neighbor <del> Discovery is not supported are out of scope for this document.  Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </del> <ins> Discovery is not supported and is out of scope for this document. Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </ins> 5.1.
Code change:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Related discussion:
text: A prefix is not considered a usable on-link prefix if it is advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the <del> Prefix option.  This indicates that node addressibility is being </del> <ins> Prefix option.  This indicates that node addressability is being </ins> managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it.
Code change:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Related discussion:
text: reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it need take no action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network. It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del> <ins> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been