jiebi/CodeConvo huggingface dataset:
Code change:
Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency <del> Services.  If more than one service is configured, the Verifier MUST return which service the Transparent Statement is registered on. In some scenarios, the Verifier already expects a specific Issuer and Subject for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID document is not available or if the Statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </del> <ins> Services. Verifiers MAY be configured to re-verify the Issuer's Signed Statment locally, but this requires a fresh resolution of the Issuer's verificaton keys, which MAY fail if the key has been revoked. </ins> Some Verifiers MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.  In addition, Verifiers MAY apply arbitrary validation <del> policies after the signature and Receipt have been checked.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </del> <ins> policies after the Transparent Statement has been verified and validated.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </ins> Verifiers MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case

Related discussion:
text: This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Code change:
frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a StreamErrorHandler. <del> Streams in either of the "reserved" states do not count as open. </del> 5.2. Using streams for multiplexing introduces contention over use of the

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
5.1.2. If the Issuer wants to enable Key Binding, it includes a public key <del> associated with the Holder, or a reference thereto.  The </del> <ins> associated with the Holder, or a reference thereto, using the </ins> <del> member of the </del> <ins> claim as defined in RFC7800.  The </ins> <del> claim as defined in Section 3.2 of RFC7800 is suggested for doing so, however, other means can be used. </del> <ins> confirmation method, as defined in Section 3.2 of RFC7800, is suggested for doing so, however, other confirmation methods can be used. Note that, as was stated in RFC7800, if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to , to hold the additional proof-of-possession key information. </ins> It is out of the scope of this document to describe how the Holder key pair is established.  For example, the Holder MAY create a key

Related discussion:
text: More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key
Code change:
knowledge of server support. The request MUST use the "DELETE" method.  The request MUST NOT <del> include the "Upload-Offset" header or the "Upload-Incomplete" header. </del> <ins> include the "Upload-Offset" header or the "Upload-Complete" header. </ins> The server MUST reject the request with the "Upload-Offset" header or <del> the "Upload-Incomplete" header by sending a "400 (Bad Request)" </del> <ins> the "Upload-Complete" header by sending a "400 (Bad Request)" </ins> response. If the server has successfully deactivated this upload URL, it MUST

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."
Code change:
knowledge of server support. The request MUST use the "DELETE" method.  The request MUST NOT <del> include the "Upload-Offset" header or the "Upload-Incomplete" header. </del> <ins> include the "Upload-Offset" header or the "Upload-Complete" header. </ins> The server MUST reject the request with the "Upload-Offset" header or <del> the "Upload-Incomplete" header by sending a "400 (Bad Request)" </del> <ins> the "Upload-Complete" header by sending a "400 (Bad Request)" </ins> response. If the server has successfully deactivated this upload URL, it MUST

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
deploying and publishing such requirements) is out of scope for this document. <del> Furthermore, this specification defines additional </del> <ins> Furthermore, this specification defines the following </ins> <del> auth-param values to convey the authentication requirements back to the client. </del> <ins> auth-param values for those OAuth authentication schemes to convey the authentication requirements back to the client. </ins> acr-challenge below is an example of a <ins> authentication scheme challenge with the </ins> header using the error code value to inform the client that the access token presented

Related discussion:
text: changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
1. <del> Digital Map provides a core multi-layer topology model and data and connects them to the other models and data.  This includes layers from physical topology to service topology. </del> <ins> Digital Map is a data model that provides a view of the operator's networks and services, including how it is connected to other models/ data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi- layered topology and appropriate mechanism to navigate amongs layers and correlate between them.  This includes layers from physical topology to service topology.  This model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). </ins> The Digital Map modelling defines the core topological entities (network, node, link, and interface) at each layer, their role in the

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
e.g. according to the type and status of the primary document in which the algorithm is defined; "insecure" when the <del> algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </del> <ins> algorithm is insecure; "reserved" when the algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
assigned incorrect or default priority values. Similarly, streams that are in the "idle" state can be assigned <del> priority or become a dependency for other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </del> <ins> priority or become a parent of other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </ins> more flexible expressions of priority.  Idle streams that are made a <del> dependency are assigned a pri-default. </del> <ins> parent of another stream are assigned a pri-default. </ins> The retention of priority information for streams that are not counted toward the limit set by

Related discussion:
text: As discussed on the mailing list.
:+1:
Make it so that PRIORITY can be sent on a stream in ANY state. i.e., change so that PRIORITY is permitted in the "idle" state.
Discussed in Honolulu; seems reasonable and no objection. Take to list to confirm.
Code change:
7.5.1. <del> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can completely negate the benefits of Txn-Tokens.  When issuing replacement Txn-Tokens, a Transaction Token Server therefore: </del> <ins> When issuing replacement Txn-Tokens, a Txn-Token Service: </ins> MAY enable modifications to asserted values that reduce the scope of permitted actions

Related discussion:
text: a replacement request. Removed vague language
There was a point in Yaron's about specifying in 7.4.1 that sub must be unchanged, and although this is mentioned in 7.4, perhaps we should add bullet points in 7.4.1 (Txn-Token Service Responsibilities) that specify that MUST NOT be modified and MUST NOT be modified.
LGTM
Code change:
apply the redirection directly in an immediate subsequent upload append (upload-appending). <del> 12. </del> <ins> 13. </ins> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the

Related discussion:
text: As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.
Code change:
2.2. <del> The Identity Chaining flow outlined below describes how these specifications are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used when the resource server acts as the client an another that describes what happens when the authorization server acts as the client. </del> <ins> The Identity Chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client. </ins> The flow illustrated in Figure 1 shows the steps the client in trust <del> domain A needs to perform to access a protected resource in trust </del> <ins> Domain A needs to perform to access a protected resource in trust </ins> domain B.  In this flow, the client has a way to discover the <del> authroization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g. through federation).  It includes the following: </del> <ins> authorization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g., through federation).  It includes the following: </ins> (A) The client of Domain A needs to discover the authorization server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of its own domain (Domain A) for an authorization grant that can be <del> used with the authorization server in Domain B.  See token- exchange. </del> <ins> used at the authorization server in Domain B.  See token-exchange. </ins> (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with Domain B.  This requires a trust relationship between Domain A and Domain B (e.g. through federation). </del> <ins> returns an authorization grant that the client can use with the authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation). </ins> (D) The client presents the authorization grant to the <del> authorization server of Domain B.  See present-authorization- grant. </del> <ins> authorization server of Domain B.  See authorization-grant. </ins> (E) Authorization server of Domain B validates the authorization grant and returns an access token.

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
6.3.2. A Consumer MAY use a registry to retrieve Type Metadata for a SD-JWT <del> VC type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </del> <ins> VC type, e.g., if the type is not an HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </ins> The registry MUST provide the Type Metadata in the same format as described in type-metadata-format.

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.