jiebi/CodeConvo huggingface dataset:
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Integer and Byte Sequence.  This document uses the notation from QUIC. </del> <ins> This document uses the notation from QUIC. </ins> 2.

Related discussion:
text: This nags at me a bit. I think you want to be crystal clear are what parts of Stuctured Fields you are and what you aren't. As far as I see, you want to use the aspect in order to reuse the serialization/deserialization, legal characters, legal range, etc., for the auth parameter values. But you don't need the aspect, which would allow you to parameterise the parameters. Does that sound accurate?
We added this sentence based on a URL from NAME Martin, do you have thoughts here? I think the intent was just to point out that we're in the new structured fields world even though Authorization hasn't been retrofitted yet
In , NAME pointed out that we can't simply use byte sequences from structured fields because authentication parameter values need to be which doesn't allow non-quoted colons. So I switched to double-quotes in dcc520544cf98cf634c9ca0a24119256fd18d58e, but that makes the usage of structured fields somewhat messy. Thoughts?
Copying my comment from the change
Good call. I now added both colons and double-quotes via 690ee072bb450ab631db5b32a23b457cec9bb6be
From Ilari Liusvaara on the : I renamed this issue to track whether we want to keep structured fields or not. Personally, I don't have a strong opinion either way.
I could live without structured fields here, presumably there are servers that already have to handle Authorization fields using the more-traditional encodings
I'll note however that if we go with we'll need to either double-quote it or explicitly ban padding, because is not allowed as part of
While base64 proper is often padded, it is more common for base64url to be unpadded (indeed, I think that the string "base64url" specifically refers to the unpadded version if you follow it to its origin, which I think is URL).
dates back at least as far as and that spec explicitly : None of which is a problem, we just need to be explicit. We know how to do that.
Right, the 7515 thing was what we ended up using in another context, where padding was explicitly not included. Clearly, we shouldn't use it here either[^1].
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Integer and Byte Sequence.  This document uses the notation from QUIC. </del> <ins> This document uses the notation from QUIC. </ins> 2.

Related discussion:
text: [^1]: I hold the view that it shouldn't be used in any situation, because if knowing the length is important, you would have a length prefix or delimiter, rendering padding pointless for anything other than protection against traffic analysis. And you can't arbitrarily pad with base64 padding, so that's no good.
I'd ideally want to align with draft-ietf-privacypass-auth-scheme. We reviewed this a lot with NAME and went back and forth and ended up with: So from a syntax standpoint, this is "base64url and you don't need quotes, but do include quotes if you have padding". If you define that you don't use padding, then you don't need quotes. So I think things can be consistent here.
Based on the conversation in the room at IETF 117, I'm inclined to make these no longer structured headers, and to use base64url without padding, without quotes, and without colons.
Code change:
requests to different origins onto a single persistent connection. Therefore, a server might refrain from sending Early Hints over <del> HTTP/1.1 unless when the client is known to handle informational responses correctly. </del> <ins> HTTP/1.1 unless the client is known to handle informational responses correctly. </ins> HTTP/2 clients are less likely to suffer from incorrect framing since handling of the response header fields does not affect how the end of

Related discussion:
text: removes statements that are either redundant or contradicts with RFC 7230, 7231 clarifies how a server is expected to do when generating a response
While it is not required to specify how an intermediary might behave, doing so might be beneficial as suggested in URL We could possibly have something like the following below the example.
works for me.
NAME Thank you for the answer. Adopted the text (with nits) in d0903d6.
NAME Thank you for the review!
Looks good to me!
Code change:
finally a message body containing the payload body (if any, message.body). <ins> Some requests can be retried by clients in the event of failure; see idempotent.methods. </ins> A connection might be used for multiple request/response exchanges. The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of

Related discussion:
text: See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then.
Code change:
finally a message body containing the payload body (if any, message.body). <ins> Some requests can be retried by clients in the event of failure; see idempotent.methods. </ins> A connection might be used for multiple request/response exchanges. The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of

Related discussion:
text: I suspect clients will not...
There's two things you might consider here: noting that clients might do some things to retry based on their own determination of when that is appropriate (for example, in the extreme, retrying if the connection breaks before any byte of a response is seen).recommendations about good practice, which probably doesn't want to point at what the most aggressive clients (i.e., browsers) might choose to do Trying to walk the line without making that distinction is probably too hard.
That seems like a good direction, except that the spec currently contains a MUST NOT; "good practice" isn't that strong... MUST NOT (BUT WE KNOW YOU WILL)?
Yep. Part of this work is in aligning the spec with reality. A SHOULD NOT is probably appropriate. No need to resort to RFC 6919 language.
Proposal:
LGTM. s/; f/. F/
While I'm fine with this, I'm stil having a big problem with retries. Some of our (haproxy) users are pressuring us to implement the so-called "L7 retries" by which if the intermediary faces a problem with the server after the request was delivered, it happily retries it, even for a POST! Not only it's a technical problem (requires all requests to be buffered for the time it takes a server to respond) but it's in total violation of all rules. The problem here is that there's an ongoing trend for doing this and users find it normal since it allows them to hide their constantly crashing servers... And usually they consider that the application deals with replay protection by itself so obviously the infrastructure must retry. Thus my big concern here is to figure till what extent an intermediary could reasonably retry, or how we could have signals between UA and server to indicate if the request is retry-safe.
A protocol extension seems reasonable for that case; I think it could be interesting to clients -- both intermediary and otherwise.
Just leaving a note to remember to go through to make sure we got everything.
I had a bunch of editorial suggestions to make and decided to just make them directly to the pull request to save you the time and annoyance. I hope that is okay, since my changes just reduce the prior diffs.
Code change:
attacker gathers a large number of access and refresh tokens on a single device and then sells them for profit more difficult, since the attacker would also have to export the cryptographic keys used to <del> sender constrain the tokens or be able to access them and generate </del> <ins> sender-constrain the tokens or be able to access them and generate </ins> signatures for future use.  If the attack is being executed on a trusted device to a device with anti-malware, any attempts to exfiltrate tokens or keys may be detected and the device's trust <del> status may be changed.  Using hardware keys for sender constraining </del> <ins> status may be changed.  Using hardware keys for sender-constraining </ins> tokens will further reduce the ability of the attacker to move tokens to another device. Sender-constrained tokens, especially sender-constrained tokens that require proof-of-posession, raise the bar for executing the attack <del> and and profiting from exfiltrating tokens.  The quality of key protection has an impact on the effectiveness of the attack. Although a software proof-of-posession key is better than no proof- of-posession key, an attacker may still exfiltrate the software key. Hardware keys will be harder to exfiltrate, but come with additional implementation complexity.  An attacker that controls the Initiating Device may still be able to excercise they key, even if it is in hardware, thus the main protection derived from sender constrianed tokens is preventing them from being moved from the Initiating Device to another device that can be used to profit from the attack. </del> <ins> and profiting from exfiltrating tokens.  Although a software proof- of-posession key is better than no proof-of-posession key, an attacker may still exfiltrate the software key.  Hardware keys are harder to exfiltrate, but come with additional implementation complexity.  An attacker that controls the Initiating Device may still be able to excercise the key, even if it is in hardware. Consequently the main protection derived from sender-constrained tokens is preventing tokens from being moved from the Initiating Device to another device, thereby making it harder sell stolen tokens and profit from the attack. </ins> 5.1.13.

Related discussion:
text: Consistently hypheante and clarify section on sender constrained tokens
consistently hyphenate sender-constrained tokens. Clarify limitations.
One typo from earlier.
Code change:
. <del> The issuer MUST choose a unique and cryptographically random salt value for each claim value.  Each salt value SHOULD contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be encoded as a string.  It is </del> <ins> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is </ins> RECOMMENDED to base64url-encode the salt value. The issuer MUST build the digests by hashing over a JSON literal

Related discussion:
text: added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged
Code change:
18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. <ins> 10.1. In retrieving-type-metadata, various methods for distributing and retrieving Type Metadata are described.  For methods which rely on a network connection to a URL (e.g., provided by an Issuer), third parties (like the Issuer) may be able to track the usage of a credential by observing requests to the Type Metadata URL. Consumers SHOULD prefer methods for retrieving Type Metadata that do not leak information about the usage of a credential to third parties.  The recommendations in robust-retrieval apply. </ins>

Related discussion:
text: Add general SD-JWT VC Type Metadata framework based on NAME work: URL See preview here: URL
Yep, good point. I18N is definitely needed although I'm not too sure about name/description since those are intended for developers only, not for end-users. I'll create a ticket to consider I18N, and also discuss whether this is needed for dev-only fields. I18N is definitely something we should add to metadata but needed some PR to start with first.
We have 3 approvals and no new comments coming in after 2 weeks. I propose to merge this PR NAME NAME . PR was created 1 month ago.
We should define more clearly what a credential type (identified by the claim) actually means. The current description is a bit handwavy and that may be a sign that we have not yet defined the concept well. I think that there is a set of metadata usually associated with each SD-JWT VC type, for example Display information for the whole credential A schema for the JSON structure (may or may not be defined in JSON schema) Information about the claims, including Display information Type information Status information (self-attested vs. verified etc.) Maybe: What kind of binding is supported/usually used for this credential type Maybe: What issuers are allowed to issue this credential type Such metadata would help Wallets (e.g., for displaying the credential to the user) and Verifiers (e.g., for determining the status of claims). It would also help developers of Verifiers, as they would get structured information about the credential they can expect. The need for such metadata has been discussed in Issue and similar approaches have shown up in . The metadata may or may not be embedded into the credential itself, or provided externally. Assuming we allow for registered values (e.g., ), this metadata could go into the registry. It could also be distributed manually. But it can also be made discoverable, e.g., by providing it at a .well-known URI derived from the URL in . Here is a completely made-up example of what this metadata could look like: Important: This mechanism will not be format-agnostic, but defined only for SD-JWT VC for now.
Code change:
18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. <ins> 10.1. In retrieving-type-metadata, various methods for distributing and retrieving Type Metadata are described.  For methods which rely on a network connection to a URL (e.g., provided by an Issuer), third parties (like the Issuer) may be able to track the usage of a credential by observing requests to the Type Metadata URL. Consumers SHOULD prefer methods for retrieving Type Metadata that do not leak information about the usage of a credential to third parties.  The recommendations in robust-retrieval apply. </ins>

Related discussion:
text: Let's imagine that Giuseppe Marco would be swapped to Marco Giuseppe and pass through a supervised verifier as Marco, while the credential is still valid and verified
I like the idea to define schema and display information in the context of the credential definition (in contrast to issuance protocol) as I believe this information should be consistent across issuers and needs to be available for verifier developers. I also believe some information could be useful at the level of individual credentials for visual customization in the wallet.
we may add: type of binding of the vc ,e.g. key-binding, claim-based-binding, none vct could be either URL linking to the resource directly or an identifier that links to e.g. an (ISO) specification to get the credential metdata IANA registry is probably not a good option versioning of the metadata protection against change e.g. put a hash of metadata in the vc It might be worth to consider reducing the credential format specific Issuer metadata defined in OpenID4VCI and define that in a credential format specific credential metadata resource: However, there will remain issuer-specific things e.g. cryptographic support that should stay in the Issuer Metadata. These would need to be defined in SD-JWT-VC.
Using the VC type metadata, one could also include an ecosystem-specific parameter that contains a that allows you to map to any data model one want. It would also allow automatic fetching and executing the transformation algorithm quite easily.
I prepared a first draft for the SD-JWT VC metadata. I wrote this as a separate draft for working on it, but of course we can consider integrating this into SD-JWT VC — whatever works best. I'm looking forward to your feedback. URL
NAME I like the document and think it's a great start. I think there's a lot more to do around JSON Schema, similar to the work we've put into . I'm happy to help here. Similarly, the display reminds me of , which could be a standalone thing. Perhaps the types document should be transformed to a 'hub' document?
For all these "human readable strings", please make sure to have an i18n story, and ideally reference PRECIS, or DisplayStrings, etc .
Code change:
Status: As specified in algorithms. <del> 9.6. </del> <ins> 9.7. </ins> This memo registers the "ID-SHA-512" digest algorithm in the HTTP <del> Digest Algorithm Values [9] registry: </del> <ins> Digest Algorithm Values [10] registry: </ins> Digest Algorithm: ID-SHA-512

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
stored) from a prior request. An origin server that receives an If-Unmodified-Since header field <del> MUST evaluate the condition as per evaluation prior to performing the method. </del> <ins> without an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method. </ins> <del> If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the origin server MAY indicate that the conditional request failed by responding with a </del> <ins> To evaluate a received If-Unmodified-Since header field: An origin server MUST NOT perform the requested method if an If- Unmodified-Since condition evaluates to false.  Instead, the origin server MAY indicate that the conditional request failed by responding with a </ins> status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)
Code change:
The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: <del> 6.3. The Verifier MUST process and verify a presentation of SD-JWT VC as follows: </del> 7. TBD: Verifier provided

Related discussion:
text: We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.
Code change:
These bits are concatenated: <del> Resulting in the byte array and compressed/base64url encoded status </del> <ins> Resulting in the byte array and compressed/base64url-encoded status </ins> list: 11.

Related discussion:
text: Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?