jiebi/CodeConvo huggingface dataset:
Code change:
I think. <del> 4.1.1.3. </del> <ins> 4.1.1.4. </ins> The SD-JWT payload MAY contain other claims and will typically contain other JWT claims, such as

Related discussion:
text: adding SD-JWT claim Note: need to update the examples to include it once we agree this claim is needed (cc NAME )
We need to say in the checking algorithm that verifiers MUST check the alg and MUST only accept hash_algs they understand and deem secure.
information about the hash function should probably be included inside SD-JWT. Based on NAME 's comment to the PR URL
Yes, needed indeed. This and more details about hash formatting (how to transform inputs into byte arrays to be passed to the hash function).
The alternative is to use the same hash function as was used for the signature. This is done in OpenID Connect Core at URL in the definition (as well as in the definition. The language is:
You might want to use a different hash function to reduce the SD-JWT size (e.g., SHA-256 truncated to 128 bit), or decide on a stronger hash function with iteration to reduce the size of the salt (again, to minimize the size of the artefact). Bottom line, choosing the hash function independently might be useful.
As discussed in the call, if we allow different hashes to be used, we may want to make a recommendation that for simplicity an implementor may want to use the same hash algorithm to minimise implementation errors.
Assuming we're not going to use the trick that OpenID Connect uses to determine the hash algorithm implicitly, then I approve of this approach.
Code change:
Implementations of Transparency Services may protect their Append- only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an <del> offline, universally-verifiable proof that an entry is recorded in </del> <ins> offline, universally-verifiable proof that an entry is registered in </ins> the Append-only Log.  Requesting a receipt can result in the production of a new receipt for the same signed statement.  A Receipt's verification key, signing algorithm, validity period,

Related discussion:
text: We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM
Code change:
SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: <del> Bit 1 being set indicates that this frame acknowledges receipt and </del> <ins> Bit 0 being set indicates that this frame acknowledges receipt and </ins> application of the peer's SETTINGS frame.  When this bit is set, the payload of the SETTINGS frame MUST be empty.  Receipt of a SETTINGS frame with the ACK flag set and a length field value

Related discussion:
text: Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.
Code change:
Repository: http://www.iana.org/assignments/scitt Index value: No transformation needed. <del> 12.  References 12.1.  URIs [1] more error codes to be defined, see [#17](https://github.com/ ietf-wg-scitt/draft-ietf-scitt-architecture/issues/17) </del>

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:
Remove all whitespace from value. <del> Let items be the result of splitting value on ";". </del> <ins> Append value to variant-keys. </ins> <del> append items to variant-keys. Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </del> <ins> Return variant-keys. </ins> 4.

Related discussion:
text: For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,
Code change:
When a stream begins with "STREAM_HEADER_SUBGROUP", all objects on the stream belong to the track requested in the Subscribe message <del> identified by "Subscribe ID" and the subgroup indicated by 'Group ID' </del> <ins> identified by "Track Alias" and the subgroup indicated by 'Group ID' </ins> and "Subgroup ID". All Objects received on a stream opened with "STREAM_HEADER_SUBGROUP"

Related discussion:
text: As of now, we use Subscribe ID for operations on a subscriber, and Track Alias for operations on objects. In , there was an effort to remove referencing subscribe id within object header types, but one slipped through. This fixes that.
Code change:
4.1.3. *Senders/Receivers*: Many to Many *Bi-directional*: Yes *Latency*: <del> Ull-200 </del> <ins> Ull-50 to Ull-200 </ins> Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation.  This may be done as client/server, or peer to peer <del> with a many to many relationship of both senders and receivers. </del> <ins> with a many to many relationship of both senders and receivers.  The target for latency may be as large as Ull-200 for some media types such as audio, but other media types in this use case have much more stringent latency targets. </ins> 4.2. <ins> The use cases in this section, unlike the use cases described in interact, still have "humans in the loop", but these humans expect media to be "responsive", where the responsiveness is more on the order of 5 to 10 RTTs.  This allows the use of protocol mechanisms that require more than one or two RTTs - as noted in interact, end- to-end recovery from packet loss and congestion avoidance are two such protocol mechanisms that can be used with Live Media. To illustrate the difference, the responsiveness expected with videoconferencing is much greater than watching a video, even if the video is being produced "live" and sent to a platform for syndication and distribution. </ins> 4.2.1. *Senders/Receivers*: One to One *Bi-directional*: No *Latency*:

Related discussion:
text: WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.
Code change:
To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. <del> The value of the "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation". The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs seperated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST the client attestation PoP defined in client- attestation-pop-jwt. </del> <ins> The value of the "client_assertion_type" parameter (as defined in RFC7521) set to "urn:ietf:params:oauth:client-assertion-type:jwt- client-attestation". The value of the "client_assertion" parameter (as defined in RFC7521) set to a value containing two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs separated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST be the client attestation PoP defined in client-attestation-pop-jwt. </ins> The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an

Related discussion:
text: Minor language tweaks aligning more to RFC 7521 in how the client authentication mechanism is defined as to not limit its application to only being used at the token endpoint.
There is an idea to send the Client attestation already in Authorization Request or PAR instead of with the Token Request. I see the following advantages: the client attestation could act as some kind of mobile capability descriptor, thus allowing the Authorization Server(Issuer) to check these before the user performs user authentication, otherwise this could result in poor UX as the user authenticates and the AS realizes only afterwards in Token Request that the level of client attestation is not enough (e.g. wallet can only handle key type xyz or LoA low) I see the following disadvantage: some flows do not require Authorization Request the user usually does not give consent before sending Authorization Request
The client attestation can for sure be used to authenticate with PAR. The HAIP already requires that.
The draft just needs to be clarified that this is a general purpose client authentication method that can be used with any interaction with an AS that is requiring or making use of client authentication.
Code change:
The encoder decides how to update the header table and as such can control how much memory is used by the header table.  To limit the <del> memory requirements on the decoder side, the header table size is strictly bounded (see maximum.table.size). </del> <ins> memory requirements of the decoder, the header table size is strictly bounded (see maximum.table.size). </ins> The header table is updated during the processing of a set of header field representations (see header.representation.processing).

Related discussion:
text: Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.
Code change:
The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified- <del> Since, If-Match, If-None-Match, or If-Range header field (RFC7232). </del> <ins> Since, If-Match, If-None-Match, or If-Range header field (RFCHTTP). </ins> A conditional SEARCH requests that the query be performed only under the circumstances described by the conditional header field(s).  It is important to note, however, that such conditions are evaluated

Related discussion:
text: content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See
Code change:
This example shows catalog for a sports broadcast sending time- aligned audio and video tracks using CMAF packaging.  Init segments <del> are delivered as inband data. </del> <ins> are delivered as inband data.  The data has been truncated for clarity. </ins> 3.4.10.

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
Code change:
The JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm with a JOSE Implementation Requirement of "Prohibited". <del> There is no use of the explicit "alg" signature parameter when using JOSE signing algorithms, as they can be signaled using JSON Web Keys or other mechanisms. </del> <ins> JWA algorithm values from the JSON Web Signature and Encryption Algorithms Registry are not included as signature parameters.  In fact, the explicit "alg" signature parameter is not used at all when using JOSE signing algorithms, as the JWS algorithm can be signaled using JSON Web Keys or other mechanisms common to JOSE implementations. </ins> 4.

Related discussion:
text: Includes several document cleanups for signatures, to publish as -09
Also: If there is no query string should the corresponding signing text be or ie. should the query value be empty or just consist of one Should we return with this request and return on this request This is what I opted for in my implementation. See shows that http4s makes the distinction between blank queries and empty queries is simpler I think this is a corner case that is worth explicating very clearly, perhaps even with a test.
There are quite a few occurrences of the header in the draft. From an implementation point of view, Go "swallows" the header and it is not part of the standard Request structure. There's a good reason for the Go library to do it, and in fact the draft recommends to use NAME instead. Can we remove from examples, e.g. Sec. 2.1, so we don't train people to do the wrong thing?
There are only a couple instances of the "host" header in the current draft left, and one of them (section 2.1) is specifically about how to format headers. It could be removed from the other example signature input strings without affecting anything negatively. Same with the "date" header, which could be confused with the "created" parameter, see
This sentence is correct: But it's true for most reasonable uses of , and people will still be using this parameter. So why not add:
No, we explicitly did not want to conflate this with the jwa registry. We also didn't want to have a second tier choice like having "alg=jose" and then having the actual algorithm elsewhere, since a big problem with late editions of the Cavage draft were exactly that process. (See the mess around "hs2019"). The editors discussed this at length and decided the best compromise was to define a way that jwa algorithms could be used in an interoperable fashion, but not to allow runtime signaling with them. Better to have the choice of jwa be signaled within the application level. Additionally, it's preferable to not use the runtime parameter to signal the algorithm any way, which is discussed at length in the security considerations.
All good, so why aren't you using normative language?
It's not normative because this section defines the algorithms, not the parameter.
Code change:
The JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm with a JOSE Implementation Requirement of "Prohibited". <del> There is no use of the explicit "alg" signature parameter when using JOSE signing algorithms, as they can be signaled using JSON Web Keys or other mechanisms. </del> <ins> JWA algorithm values from the JSON Web Signature and Encryption Algorithms Registry are not included as signature parameters.  In fact, the explicit "alg" signature parameter is not used at all when using JOSE signing algorithms, as the JWS algorithm can be signaled using JSON Web Keys or other mechanisms common to JOSE implementations. </ins> 4.

Related discussion:
text: We didn't want to make it seem like the parameter was the "right" way to signal algorithms here, and most certainly is not required. You'll notice that none of the other sections have "MUST use the alg parameter value of 'foo'" either. Older Cavage drafts relied on the parameter, albeit in a much less secure fashion, and implementations were susceptible to algorithm substitution in the same way that naive JOSE implementations tend to be -- the "alg: none" attack all over again, more or less. The value of the parameter already MUST be something from the registry, and the registry does not (and will not) contain JWA values. So you already aren't allowed to do it, normatively, and the note is our attempt at explaining the why. Ultimately, an implementation is allowed to use whatever algorithm they want and makes sense. What this whole section does is define a set of common usable algorithms as well as provide a pattern of applying crypto primitives that applications can follow for their own algorithms. If someone defines a new algorithm that's generally useful, like we recently did with the ed25519 here, it can be registered for use with the parameter. But if a system can base the algorithm selection off of the key material or another part of the protocol (like with GNAP), that's highly preferable and less vulnerable to substitution at runtime. I'd be happy to know how we can make this clearer in the text, but I'm not comfortable with that kind of normative construct in that section.
NAME -- would you like to chime in? I recall from our discussions you having another, more specific reason for this decision, but I can't remember the details beyond us agreeing to do it the way we have it in the spec right now.
Neither Java nor JS subtleCrypto come out of the box with PKCS1 PEM support. (for java ). It is not immediately obvious to work out that the PEM formats of the private key in in PKCS1 format (the spec could point that out). When building an implementation it helps to have the test suite clearly map to the data in the spec (e.g. ) so as to make error reporting clearer. That is even though using the following openssl command to convert the keys work, it makes it difficult to see if an error was introduced at some point.