jiebi/CodeConvo huggingface dataset:
We say that we don't restrict how other caches (e.g., higher-layer in the browser, back/forward) interpret cache directives, but I think it would be useful to give a bit more guidance here, as this causes a lot of confusion and interoperability problems (since the browsers still haven't sorted out the various other caches' operation). For example, we could give string guidance (non-normative) that should be respected by other caches.
All of these caches are in front of the networking stack and in theory might not even have all response headers if converted to a more optimal representation. If you consider JavaScript modules, they are de-duped based on their request URL in a module map. If the first response for such a URL had , we still wouldn't be making any further requests. The same goes for images, style sheets, and some other resources as I understand it and for some of these changing that would result in compatibility issues (or presumably functional errors in case of module maps). For back-forward in particular it might be worth reading URL There's a worry that an explicit opt-out could end up cargo-culted and make the feature unusable.
NAME that makes sense, I agree the current wording is too strong. How about changing apparent to or easily controllable by the user, it is strongly encouraged to honour basic control mechanisms like Cache-Control: no-store, as they indicate the resource's intent regarding caching. to: apparent to or easily controllable by the user, it is strongly encouraged to define its operation with respect to HTTP cache directives, so as not to surprise authors who expect caching semantics to be honoured. For example, while it might be reasonable to define an application cache "above" HTTP that allows a response containing Cache-Control: no-store to be reused for requests that are directly related to the request that fetched it (such as those created during the same page load), it would likely be surprising and confusing to users and authors if it were allowed to be reused for requests unrelated in any way to the one from which it was obtained.
I think that's good. Some of the caches I mentioned do cross page loads (e.g., images and style sheets). However, I think the statement about those is correct and we should be better about explaining how they fit in and make sense (and perhaps adjust if they don't).
: We had trouble parsing this sentence. Is a word missing? If neither suggestion below is correct, please clarify what "any frame carrying ... SETTINGS" refers to. Original: A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSHPROMISE, and CONTINUATION), SETTINGS, and any frame with a stream identifier of 0. Suggestion (... and a SETTINGS frame): A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSHPROMISE, and CONTINUATION) and a SETTINGS frame, and any frame with a stream identifier of 0. Suggestion (... or a SETTINGS frame): A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSH_PROMISE, and CONTINUATION) or a SETTINGS frame, and any frame with a stream identifier of 0.
Suggestion 1 is correct.
I think that the list structure is supposed to be... includes: any frame carrying a field block (...), a SETTINGS frame, and any frame with a stream identifier of 0. Which suggests option 3, in my PR.
LGTM.
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL
I know that Cory beat me to it with , but I had written text. I only forgot to make the PR. Cory can decide which he likes better :)
In the aside about HTTP/2 deliberately not supporting Upgrade, it feels worth mentioning that we later partially reversed ourselves and brought back a moral equivalent of Upgrade with a less obvious name. Reference to RFC8441 appropriate here?
You put more things in your citation block, so it’s clearly better.
URL This does not work. It's impossible to split multiple values (be it a list-based field or not) without knowledge of the field value's grammar. For example, what is the canonicalized value for: ?
The value would be Since it was sent as two instances, you combine the instances with a comma and space. The language to split the field values was added late based on several conversations about list type fields and how they can be combined, but we can remove this. If someone needs additional armoring they can use the "sf" flag on a list formatted field.
Ok, but what the spec currently says would result in: URL that sentence really needs to go.
No, it would not result in that, because as you point out those are not separate field values that can be separated.
So what does: mean then? When is it "necessary"? How does the code know that for any given field name?
I think what is meant is that you take a list of the values of a given field (one member of the list for each header line) and then concatenate them by separating them with ", ". In scala this is or just to make it explicit
Thanks NAME - I get that, but that doesn't address the question I asked...
Ok, I see the problem is: I would not know how to do that, whereas I do know how to seperate the fields in the list.
We need to be very clear with the terminology. What do you mean by "seperate the fields in the list"? Do you have an example?
If you are talking to me, I meant what the code above showed: the list is the list of header values (for a given header name). And I meant seperating the values of that list. I don't know how to write that up well in the spec though...
Ok, AFAIU: just drop "If necessary, separate individual values found in a field instance." from the spec.
URL I don't quite get the reasoning for the second "MUST". Why does it matter? What would break if the client uses a single comma, which is also allowed by HTTP? IMHO the exact delimiter sequence here does not matter at all, as long as it is allowed per HTTP. Note that HTTP allows combining field values, it does not allow splitting them afterwards.
This isn't combination at the HTTP level by the client or intermediary, this is combination by either the signer or verifier when making the signature base. It's a MUST here because there needs to be only one way to do it at that step. If the lines are already combined then leave them combined.
hm. ok. So one confusing thing here is that HTTP 5.2 is already only about combining field values. So the "Specifically" is a distraction. Also, 5.2 does not mandate using COMMA SP. The section doing that is 5.3.
Also...: I think I misread that as a recommendation to parse individual field values into a list, before recombining everything. Maybe "parsing out individual field values" needs to be rephrased.
You would only parse out individual values if you: 1: Know the overall syntax/grammar of the field 2: Know that it's a list separated by commas 3: Can't send everything as a single field line 4: Know that an intermediary is going to mess with things sent as multiple lines in a way that you don't want The recommendation is really only for that one corner case, not for every value.
I agree with that, but the spec really needs to be clearer here.
(but I'll note that github's way of displaying diffs in long lines makes it extrremely hard to find out what actually changed)
This PR introduces the following changes: - Made all public key validation rules conditional Rejecting the SD-JWT VC if public key validation cannot be done
This harms interoperability, since some implementations will use DIDs and others will use . A more interoperable approach would be to drop and to always use DIDs. Those who want to use domain names and web servers can then still use . DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document). Similar arguments apply to the vs discussion. But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)
NAME Let's have the discussion in . As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.
Let me try to update the PR.
NAME I made all rules now conditional from a verifier perspective. In this way a verifier is compliant if they don't support all rules but the SD-JWT VC would fail validation. Note, it is impossible for a verifier to support all rules that may be defined by ecosystems anyways. Are you ok with the updated language?
As a DID maximalist, I would personally prefer DIDs to be the only mechanism that is used whenever public keys are needed, instead of allowing more static public key mechanisms like "jwt-issuer" or "cnf". Unlike "jwt-issuer", DIDs support identifiers that are persistent, decentralized, and cryptographically verifiable. Unlike "cnf", DIDs support key rotation and other updates. And as I said above, with DIDs there would be only one syntax and one resolution mechanism and one metadata format, instead of multiple different ones that individual implementations may or may not support. But I also understand that for some communities, "keeping it simple" is more important than the above properties, so yes I'm fine with the language, thanks for the effort to update it!
While I understand your points, I think some of them are not true. DIDs may be decentralized, may support key rotations and may have other features.
There are enough examples of DID methods that do not have those properties. Making DIDs mandatory would limit optionality. But also with DIDs the optionality in my view shifts just shifts a layer further down as there are many DID methods. Indeed allowing DIDs expands optionality by 200+ did methods, so this could indeed be a counterargument. "Cnf" isn't actually far away from DIDs, as the content can vary, there is a registry at IANA for supported methods, with different properties. In my view the cleanest approach for the keybinding would be to register a new cnf type "did" in this registry. But that's off topic in this PR. I'm fine to keep some optionality in the specification at the beginning and then see what is actually being used
True. :) But with "JWT Issuer Metadata" discovered from domain names you will never have the kind of decentralization, persistence, and cryptographic verifiability that DIDs can offer. Sounds interesting! But I agree off-topic. You can still restrict the DID methods you want to use in a specific application such as eIDAS2. For example, if you want to support 1. domain names, 2. plain public keys, and 3. EBSI, then: With the current approach in this specification: For 1. you need to support JWT Issuer Metadata (= a new format introduced by this spec). For 2. you need to support "cnf" and JWK (= a format that has been around for a long time). For 3. you need to support DID documents (= a format that has been around for a few years). Compare that to a DID-only approach: For 1. you need to support did:web (= DID document format) For 2. you need to support did:jwk (= DID document format) For 3. you need to support did:ebsi (= DID document format) You see what I mean? Yes with a DID-only approach you would still have a layer of optionality with regard to DID methods, but you'd only have that ONE layer of optionality instead of TWO layers of optionality, and you'd have a harmonized identifiers syntax and harmonized metadata format.
But I understand there are communities that simply don't want to use DIDs, so I think this current PR is a good middle ground.
The current text is basically a normative requirement to support all DID resolution. Which is too much, even to the extent we want to allow for or support some DID usage. We need to revisit how this is phrased in the document and even how much (if any) is said. created from discussion in PR : B: "IMHO DIDs can be accounted/allowed for via the "Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above" criteria below and shouldn't receive 1st order treatment like this in the spec." O: "We added DIDs to make the spec useful also for the credential market that uses DIDs. For those people it is required to demonstrate how that can be done. I'm wondering how other folks are thinking about dropping DIDs from getting 1st order treatment. You are right, one can create another draft that just explains how to use DIDs with this spec." Originally posted by NAME in URL
It was definitely not the intend to support all DID methods and all kind of DID resolutions. We need to make DID support optional for verifiers and if they don't have support they won't be able to verify DID-based SD-JWT VCs which is fine.
I made a proposal here
includes security considerations from
NAME probably those considerations are redundant: implementers know that computing digest has a cost. Do you think it's worth spending more time to land this PR or we can close it?
I'd go with a simpler statement such as or say nothing.
NAME this PR contains your proposal.
A threat model for . is this useful/required? should this go into Security Considerations or in another document?
User User-Agent: see RFC7230 Intermediaries that do not do TLS termination Intermediaries that do TLS termination.Application: the application actually running the service Intermediaries can alter HTTP messages Intermediaries that do transport-layer termination can alter HTTP messages The application can erroneously or purposedly alter the message User can forge messages with the same checksum values An intermediary can alter an HTTP header by chance or purpose. [x] Use an end-to-end transport-layer security mechanism. A TLS-terminator intermediary can alter representation-metadata by chance or purpose. [x] Use a signature mechanism that covers both and the representation-metadata. A TLS-terminator intermediary can replace the representation-data with another one having the same digest-algorithm. A malicious User can forge two messages with: different representation-data same Digest header values send an HTTP message with the first representation-data then pretend he sent the one with the second representation-data. A malicious Server could implement a similar behavior. [x] Use a digest-algorithm that is not subject to collision (eg. sha-256), or refuse to use digest-algorithms subject to collision. A User could exhaust server resources by chance or purpose via: 1- sending a huge representation 2- digest calculation of the complete representation 3- forcing the server to evaluate the digest of the included representation [x] To consume huge representation-data, you may consider mechanisms sending progressive integrity checksums in the payload body and just use to provide the last checksum value. A malicious User could exhaust server resources via: 1- reconstruction of the complete representation 2- digest calculation of the complete representation 3- forcing the server to evaluate many different digest-algorithms for a given representation If you are exposed to this kind of attack because reconstructing complete representations of your objects is computationally intensive, avoid using [ ] Digest with mechanisms like Range-Requests and PATCH.
If you support multiple digest-algorithms: [ ] limit the supported digest-algorithms to the ones you really care for; [ ] establish a policy for validating only the digest using the stronger digest-algorithm. The recipient may skip Digest header validation by chance or purpose and still be compliant to the specification: as explained in {#digest-header} the recipient MAY ignore any or all the received representation-data-digests. This is because Digest was originally conceived in RFC3230 as a tool for the recipient to validate the received representation, but not for the sender to receive an integrity proof of the communication. [ ] You should not rely on the recipient having correctly verified the Digest value of the selected representation. If you want the recipient to validate the : [ ] agree on processing with your peer, like it is done in
Let's see if we can incorporate some of this into the security considerations.
all considerations should be inside the I-D once is merged
Thank, this works for me. Let's merge and we can iterate later if anyone thinks of something to add.
To address review comments and closing Issue
From NAME review: I reacted to the use of “forbidden” in this sentence. Would not “not intended at all for use in the Internet” be a better formulation? Because forbidden want me to invoke the Protocol Police if someone ever attempted to use it.
For me, this was meant to be stronger than "not intended", more like "confined to a limited to a controlled environment". RFC 8799 describes some of these cases, and could be a useful reference?
So I think a stronger wording is fine. But, an alternative formulation would be good that doesn't imply that you might get the protocol police after you.
Clarify that Accept-Ranges can be sent by any server, remove "none" from the ABNF because it is now a reserved range unit, and allow the field to be sent in a trailer section while noting why that is much less useful than as a header field For this is an alternative to
IMHO... allowing non-origins to service range requests, but disallowing them to advertise that is really really weird. At the end of the day, any "Accept-*" field value received is always a statement about the present, and not a promise for future requests. This is not different from other fields. Do you believe it would actually be harmful if a client was mislead to believe it can do a range request, and then it receives the full content with a 200?
A header field is defined by the intent of the people who minted and deployed it. That was Lou Montulli. Its original meaning was confused in the pre-RFC2068 draft because of an editorial mistake, not because the header field ever changed its meaning as deployed. The main use case was restarting a big download, and that is not specific to origin servers. Today, this field is largely ignored because of the poor specification. We can improve such things without harm.
I don't think this is worth too much more time, I'll just say I disagree -- it's not very useful in this form, and it differs from every other bit of similar metadata we put into headers (e.g., , , ). I'll make a suggestion to try to make the ambiguity here a bit more clear.
You are starting with an assumption that this is an origin characteristic and saying that this doesn't fit that assumption. I agree that the assumption does not fit the header field's definition, nor is it a fit for purpose. The field's purpose is to tell the client that range requests may help if there is a problem receiving the whole content. That's not limited to origin servers and has nothing in common with Allow or Vary. If a proxy cache can process range requests on large cached items (e.g., a company training video) and its clients can benefit from that, why would we not want to advertise that fact to the client?
The theory that this may cause a problem with multiple paths just doesn't hold for proxies (they are client chosen) and wouldn't matter anyway for range requests because the worst case is a 200 response. This was explained in 1996 and the definition was fixed in the next draft. It just wasn't fixed enough. This doesn't change the fact that the header field isn't very useful, simply because it is advisory only and most clients will ignore that advice when it doesn't matter to them if 200 is the response. That's okay.
Thanks NAME ready for re-review I think.
Oh, you proposed changing "handling" to "reporting": did you want to do that pervasively in this document?
Let's take that up separately.
Ready for merge I think.
I agree, but as this is substantive, let's run this by the working group.
As there is a draft deadline, I will open an issue for my niggle, and ask for forgiveness rather than permission.
It's not clear to me from RFC 7540 how an endpoint should behave upon receiving a frame that is erroneous in more than one way. For example, suppose a server receives the following frame when it has stream id 1 in half-closed (remote) state: According to §4.2, the frame "MUST be treated as a connection error" and the server "MUST send an error code of FRAMESIZEERROR" (because the length of 4 "is too small to contain mandatory frame data", namely the weight and header block fragment fields); According to §5.1, the server "MUST respond with a stream error (Section 5.4.2) of type STREAMCLOSED" (because a frame "other than WINDOWUPDATE, PRIORITY, or RSTSTREAM" was received for a stream that is in "half-closed (remote)" state); and According to §5.3.1, the server "MUST treat this as a stream error (Section 5.4.2) of type PROTOCOLERROR" (because "a stream cannot depend on itself"). That is to say, according to the RFC, the server MUST (at very least) respond to this frame with one GOAWAY frame and two RSTSTREAM frames. However, sending all these frames would violate other requirements: According to §5.4.1, "after sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection". This obviously prevents other frames from being sent. According to §5.1, sending a RSTSTREAM transitions the stream to closed state, in which "an endpoint MUST NOT send frames other than PRIORITY". This prevents any further RSTSTREAM frames from being sent for the same stream.