jiebi/CodeConvo huggingface dataset:
Code change:
There is no standardized way to: enable the consumer to verify that software originated from a <del> 'duly authorized signing party' on behalf of the Supplier. </del> <ins> 'duly authorized signing party' on behalf of the supplier, and is still valid. </ins> 3.2.

Related discussion:
text: Updated firmware and Software integrator use case to the same format as the ones above.
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
Code change:
3.3.1. An end-user sets up a new smart TV and wants to connect it to their <del> favorite streaming service.  The TV displays a QR code that the user scans with their mobile phone.  The user is redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service.  The user enters their credentials and grants authorization, after which the streaming service is available on the smart TV. </del> <ins> favorite streaming service.  The streaming service displays a QR code on the TV that the user scans with their mobile phone.  The user is redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service.  The user enters their credentials and grants authorization, after which the streaming service is available on the smart TV. </ins> 3.3.2.

Related discussion:
text: Addresses feedback in issue NAME
Feedback from Dean Saxe on WGLC Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. URL
Adressed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know.
Code change:
3.3.1. An end-user sets up a new smart TV and wants to connect it to their <del> favorite streaming service.  The TV displays a QR code that the user scans with their mobile phone.  The user is redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service.  The user enters their credentials and grants authorization, after which the streaming service is available on the smart TV. </del> <ins> favorite streaming service.  The streaming service displays a QR code on the TV that the user scans with their mobile phone.  The user is redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service.  The user enters their credentials and grants authorization, after which the streaming service is available on the smart TV. </ins> 3.3.2.

Related discussion:
text: Thanks, -dhs Dean H. Saxe, CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: EMAIL | M: 206-659-7293 From: OAuth on behalf of Rifaat Shekh-Yusef Date: Monday, April 22, 2024 at 7:57 AM To: oauth Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat All, This is a WG Last Call for the Cross-Device Flows BCP document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by April 29th. Regards, Rifaat & Hannes
Code change:
Enforcing uniqueness of the "nonce" parameter. <del> Requiring an application-specific value for the "context" parameter. </del> <ins> Requiring an application-specific value for the "tag" parameter. </ins> Application-specific requirements are expected and encouraged.  When an application defines additional requirements, it MUST enforce them

Related discussion:
text: Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.11. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.11.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.

Related discussion:
text: Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review
Code change:
Verifiers MUST apply the verification process as described in Section 4.4 of RFC9052. <del> In order to verify the inclusion proof that is included in the Receipt, the verification process for the inclusion proof MUST be performed as described in the document that registers corresponding Verifiable Data Structure Parameters (see I-D.draft-steele-cose- merkle-tree-proofs). APIs exposing verification logic for Transparent Statements may wish to provide more details that a single boolean result, for example, indicating if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. </del> <ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an API may indicate if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. </ins> The algorithm-specific details of checking inclusion proofs are <del> covered in I-D.draft-steele-cose-merkle-tree-proofs.  The pseudo-code </del> <ins> covered in I-D.draft-ietf-cose-merkle-tree-proofs.  The pseudo-code </ins> for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be

Related discussion:
text: Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.
Code change:
and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 8. </del> <ins> 5.5. </ins> In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: <del> 9. </del> <ins> 5.6. </ins> This document has no IANA actions. <del> 10. </del> <ins> 5.7. </ins> Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
It is possible that the GOAWAY will not be reliably received by the receiving endpoint.  In the event of a session error, GOAWAY only provides a best-effort attempt to communicate with the peer about why <del> the session is going down. </del> <ins> the session is being terminated. </ins> An endpoint can end a session at any time.  In particular, an endpoint MAY choose to treat a stream error as a session error if the

Related discussion:
text: Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.
Code change:
All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: <del> The request MUST be denied presented authorization grant is not audienced to the authorization server that processes the request </del> <ins> The request MUST be denied if the presented authorization grant is not audienced to the authorization server that processes the request </ins> The authorization server SHOULD deny the request if it is not able to identify the subject

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the history of Signed Statements registered by a given Issuer via a <del> certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints, except if it is necessary to compute a Registry </del> <ins> certain Subject.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints, except if it is necessary to compute a Registry </ins> consistency proofs.  Other evidence to support the correctness and completeness of the audit response MUST be computed from the Registry.

Related discussion:
text: PR addressing the conversation around Feed is redundant with Subject, as defined in CWT This PR intentionally contrasts Choice for folks to vote upon: [ ] Rename Feed to Subject [ ] Should we also include CWT_Claims, which contains the subject
Copied over from: URL A feed is a great base for how we can create a series of statements for different artifacts, getting freshness for a receipt/or VEX report. The current definition likely needs to expand a bit to account for: What are the versions of a specific artifact What are all the statements for a version of an artifact What is the latest statement for a specific of a specific versioned : (eg: what's the latest or for the software? If the is a referenced , which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload of satementByReference?
I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.
This is a good point and one possible improvement that was already brought up at the previous IETF meeting is to enable some structure in the feed header. For instance, using an array of strings would capture many of the common patterns (such as product > model > release), and allow some advanced functions in the API (such as prefix-based querying). Another approach would be to allow each issuer to structure their feed using arbitrary CBOR representations; while this captures many more complex usages (e.g. packages for different Linux distributions, binaries for different architectures) it becomes harder for the transparency service to understand what constitutes related claims (it requires interpretation of the feed format), and thus, harder to define auditing APIs.
NAME I've got the notes on feeds and I've been working on a proposal. Would you like to collaborate on it? Deferring to 117 for prioritization, but a great discussion as many things will be built upon feeds.
Code change:
Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the history of Signed Statements registered by a given Issuer via a <del> certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints, except if it is necessary to compute a Registry </del> <ins> certain Subject.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints, except if it is necessary to compute a Registry </ins> consistency proofs.  Other evidence to support the correctness and completeness of the audit response MUST be computed from the Registry.

Related discussion:
text: A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
Code change:
aliases" list would be the name that ultimately resolved to one or more addresses. <ins> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com":

Related discussion:
text: Agreed, but I don't see a way around having a "." be allowed there. If a system wants to further escape dots within labels if they know about them, that's OK...
The current text says names MUST be represented using a percent-encoded value instead. However, domain names can also contain and , so I think the escaping rule has to be a bit more generic than just escaping commas, as indicated in the current text.
Wire format DNS names can contain arbitrary octets. I'd suggest allowing characters in the set and %-encoding any other character. This is similar to the filtering that the glibc stub resolver performs on CNAME alias chains.
Reference RFC 1035 section 3.1 for the fact that these can be arbitrary Percent encode everything that it not alphanumeric or dash Mention in the security considerations that if you don't do this, you could inject newlines, etc.
Actually, sf-string already prohibits things like newlines:
The unreserved characters are: is a valid interior label character in a wire-format DNS name, which seems like it would allow spoofing a label boundary. Not sure how much of a problem this is.
Code change:
A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is received in response which contains a prefix information option <del> (RFC4861) </del> <ins> (RFC4861) for that prefix. </ins> After an RA message containing a suitable prefix has been received, it can be assumed for some period of time thereafter that that prefix

Related discussion:
text: Actually, the two stub routers might not be connected to the same stub network, and that should be okay. The point is to stabilize the on-link prefix on the AIL if it's provided by a stub router. If stub routers A and B are connected to the same AIL, only one will advertise an on-link prefix. If that one reboots, the other will remember that that prefix is on-link, so it will do the right thing with responses send to hosts on that prefix. The goal is to make sure that the router that rebooted also considers that prefix on-link, even though it's never seen an RA. I think this section needs a bit of work; the clarifications you've requested would be part of that, but it was useful to re-think this based on your comments as well, because I think I see how to make this work in a relatively clean way. If we are not advertising the prefix on the link, because there's a usable prefix on the link, and we get a message from the stub network for an address on the remembered prefix, there are the following possibilities that I can think of: The prefix is a DHCP prefix, meaning it's routable and doesn't belong to the stub router. In this case, the stub router could try to renew it; if that succeeds, it could assume that the prefix is valid on the AIL and forward packets to that prefix to the AIL. If that fails, it assumes the prefix is only reachable through a router, so it forwards the packet using its routing table, and hopes for the best. The prefix is a prefix generated by that stub router. In this case, if the stub router is on a different AIL, it's immaterial, since the prefix isn't routable. So the stub router can assume that that prefix is on-link and forward packets for that prefix to the link; if they reach their intended destination, great. If not, nothing is lost. The prefix is a stub-network-specific prefix. As an example, Thread uses the thread XPANID, which is a 48-bit number unique to a Thread network and its set of credentials, to generate a ULA prefix for the AIL.
Code change:
A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is received in response which contains a prefix information option <del> (RFC4861) </del> <ins> (RFC4861) for that prefix. </ins> After an RA message containing a suitable prefix has been received, it can be assumed for some period of time thereafter that that prefix

Related discussion:
text: This means that if there are several stub routers connected to the same AIL and the same Thread network, they will all always advertise the same ULA on the AIL if there's no usable prefix there. This has a really nice benefit of increasing the stability of numbering on the wire in the presence of stub router reboots. This prefix isn't routable, so if the stub router gets connected to a different AIL, there's not much it can do about it. It's not actually clear what to do in this situation, since if there's another stub router still connected to the old AIL, we have ambiguous routing to that prefix on the stub network. In the case of Thread, we don't consider this a serious concern, since thread has similar locality to home networks: if you can't reach the home router, you probably can't reach the thread network you were connected to before either.
Not all aspects described here are fully clear yet, and there's a tension between this text and other PR text that says ULA Site Prefix is used to generate the AIL ULA link prefix. But it's best to merge the new text now and use that as a basis for further review!