jiebi/CodeConvo huggingface dataset:
Code change:
compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within <del> the referenced status list JWT. </del> <ins> the referenced Status List Token. </ins> The JWT MUST contain an "status" (status) claim conforming to the rules outlined in

Related discussion:
text: NAME Whats' failing on the build here?
breaks the build All RFC references are resolved interally and linked
There are possible applications of this draft that go beyond just verifiable credentials, hence we do not want to use that term in this draft IMO. "Token" is already a term broadly used in this space e.g CWT and JWT both use it, "subject" was used in this context because it is also a term used heavily w.r.t tokens, feel free to suggest alternative terminology but at this point I think subject token is the best I've heard suggested.
can we simply use JWT/CWT instead of creating any kind of abstraction term like ? One person i asked for feedback associated with a token used to communicate a subject of an email.
or, bottomline, please stick to . is very confusing.
I'm with Tobias on this and prefer introducing a new term here. Otherwise things get really weird because the status list is also a JWT/CWT and a token. We need something that clearly separated the status list token and the other token. I think subject token is the best we have. Also subject is leaving towards what we have as credentialSubject in the VC world, so the term subject is kind of established in this context
I am really strongly against "Subject Token". Not only because it is not intuitive (I have been asking various people in this space and no one would associate what it trying to be conveyed), but we should not be introducing a new term in this already confusing ecosystem. Moreover, this status list mechanism can be used with a JWT/CWT that does not necessarily contain a subject (like SD-JWT-VC), so using a term subject because it is widely used is not a sufficient reason. Keep referring to it as a token, because this draft should not be opinionated about what is in the JWT/CWT whose status is being expressed should be fine, if a "status list JWT/CWT" is always referred as such. there are multiple occurrences where "status list JWT" is referred to simply as a JWT which should be fixed IMO.
We need clear terminology for: the status list token (i think this one fits pretty well) the credential / token that is bound to the status list I do believe only calling it token will cause confusion with the status list token.
Code change:
compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within <del> the referenced status list JWT. </del> <ins> the referenced Status List Token. </ins> The JWT MUST contain an "status" (status) claim conforming to the rules outlined in

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
Code change:
The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (RFC2616, Section 1.3). </del> <ins> (RFC7230, Section 2). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it is receiving an HTTP response (i.e., the name of the host to which it sent the corresponding HTTP request). <del> The term request-uri is defined in Section 5.1.2 of RFC2616. </del> <ins> The term request-uri refers to "request-target" as defined in Section 5.3 of RFC7230. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap

Related discussion:
text: I left the term "request-uri" untouched (it was renamed in the base spec because it's not always a URI). We may want to change that separately, or even refer to the effective request URI (URL)
NAME - ping?
LGTM, thank you for the patch, and for the ping!
Code change:
attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. <del> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC </del> <ins> URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </ins> 8.2.

Related discussion:
text: In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL
Code change:
Error code: "entryNotFound" The retrieved Receipt may be embedded in the corresponding COSE_Sign1 <del> document in the unprotected header, see draft-birkholz-scitt-receipts (TODO [1]: replace with final reference). </del> <ins> document in the unprotected header. </ins> 9.

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

Related discussion:
text: I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.
Code change:
Specification document(s): save-data of this document Related information: for Client Hints <del> 6.6. </del> <ins> 6.7. </ins> Header field name: Viewport-Width Applicable protocol: HTTP

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
5.2.2.3. The "no-store" response directive indicates that a cache MUST NOT <del> store any part of either the immediate request or response.  This directive applies to both private and shared caches.  "MUST NOT </del> <ins> store any part of either the immediate request or response, and MUST NOT use the response to satisfy any other request. This directive applies to both private and shared caches.  "MUST NOT </ins> store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as

Related discussion:
text: The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.
Code change:
HTTP GET method, which requests that a server return a representation of the resource identified by the target URI (as defined by RFCHTTP), the QUERY method is used to ask the server to perform a query <del> operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in </del> <ins> operation (described by the request content) over some set of data scoped to the effective request URI.  The content returned in </ins> response to a QUERY cannot be assumed to be a representation of the resource identified by the effective request URI. <del> The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the QUERY method, </del> <ins> The content of the request defines the query.  Implementations MAY use a request content of any media type with the QUERY method, </ins> provided that it has appropriate query semantics. QUERY requests are both safe and idempotent with regards to the

Related discussion:
text: This spec uses 'body' and 'payload' a lot; I think most should be 'content'.
Code change:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using <del> HPACK RFC7541 or QPACK I-D.ietf-quic-qpack) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </del> <ins> HPACK HPACK or QPACK QPACK) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </ins> 3.2.

Related discussion:
text: update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204
Code change:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using <del> HPACK RFC7541 or QPACK I-D.ietf-quic-qpack) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </del> <ins> HPACK HPACK or QPACK QPACK) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </ins> 3.2.

Related discussion:
text: Martin kindly suggested that I was making this too complicated and to just make the change (paraphrasing). I've tried to do that with changes in PR .
This works well enough on the critical points. Some points about readability though.
Code change:
The status code indicates that one or more conditions given in the <del> request header fields evaluated to false when tested on the server. This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. </del> <ins> request header fields evaluated to false when tested on the server (conditional.requests).  This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. </ins> 15.5.14.

Related discussion:
text: I wasn't sure where exactly to include the citation, but the end of the sentence seemed harmless.
Code change:
represented either literally or as a reference to an entry of the header table.  The header value is represented literally. <del> Three different literal representations are provided: </del> <ins> Two different literal representations are provided: </ins> A literal representation that does not add the header to the header table (see literal.header.without.indexing). <del> A literal representation that adds the header at the end of the header table (see literal.header.with.incremental.indexing). A literal representation that uses the header to replace an existing entry of the header table (see literal.header.with.substitution.indexing). </del> <ins> A literal representation that adds the header at the beginning of the header table (see literal.header.with.incremental.indexing). </ins> The indexed representation defines a header as a reference in the header table (see indexed.header.representation).

Related discussion:
text: We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .
Code change:
Add key param_name with value param_value to parameters. <del> Return the tuple (primary_identifier, parameters). </del> <ins> Return the tuple (primary_item, parameters). </ins> 4.2.6.

Related discussion:
text: in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?
Code change:
of COSE, and used to indicate that a signed object is a Signed Statement). <del> 6.3. </del> <ins> 6.4. </ins> Transparency Service implementations MUST indicate their support for registration policies and MUST check that all the policies indicated

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