jiebi/CodeConvo huggingface dataset:
a sample of links resulting from my research of the subject: URL URL URL URL URL URL URL URL
As for the percent-encoding, section 6 of RFC 3986 seems to have the answer that servers aren't allowed to interpret URIs differing only in them as identifying different resources. However, I have 3 more remarks: I wish the MUST requirement were stated explicitly to avoid confusion among implementors, content authors, server administrators and other audiences. The following excerpt seems to erroneously (because absolute examples are present in the following section) limit the whole chapter 6. to relative URI references, thus excluding e.g. the of s (RFC 7230, section 5.3.2.):The difference, introduced in RFC 3986, between URIs (which are always absolute and don't undergo resolution) and URI references (which may be absolute or relative and chapter 5. defines how to resolve them to obtain a URI) is subtle. Extra care to pick the right one each time should be exercised when using the terms. Particularly with normalization. Currently it's not easy to find and definitively interpret text in the standards clarifying whether both are normalized, when, and how normalization rules for them differ.
URL is useful to the extent it provides a way to talk about this. Would it be sane to say that servers MUST do the things described in 6.2.2 of that document? When I'm a client implementor I would be shocked, and my caching software might well break, in dealing with a server that didn't. Section 6.2.3? I think so probably, but it's not nearly as clear and concise as 6.2.2.
NAME I concur, make the language of 6.2.2 and 6.2.3 more precise and with uppercase MUSTs instead of present shoulds. On the other hand, 6.2.4 is bogus in this context, may be moved somewhere and rephrased to be clearly just informative advice. A trailing slash does make a URI semantically different, at least with the and schemes, unless it's immediately preceded by an authority.
Saying servers MUST do anything has the effect of requiring intermediaries to modify URIs on the way through.
That's clearly not going to happen, especially given how many different places URIs occur (request target, , , , etc.). OTOH there are some security implications if policy is applied before normalisation. Caches are less efficient as well (not an interop problem, just an efficiency one). Roy, you say 'The request target is whatever is provided by the client.' Do you mean the bytes on the wire (if so, what about h2/h3)? or do you mean after some amount of processing? I think we're just talking about the level of processing that's necessary before the protocol element is consumed (but not necessarily forwarded).
Is there a notion of a server which isn't an intermediary for a given request? If so, how about requiring it only of them? If not, can creators and administrators of resources (people minting URIs for them, either by hand or directing some tool to do it, possibly dynamically) be distinguished as an audience subject to its own set of requirements and have them MUST conform? The advantage of this approach would lie in abstracting from authorities, origins, websites, servers and intermediaries – just the assumptions about the semantics embodied in returned representations and metadata (responses in the case of HTTP) would count as the measure by which to judge conformance. (And they could achieve it with a single server, a server cluster, a CDN, proxies, including non-transparent ones, or whatever else.)
See PR.
Thank you, LGTM mostly. It still does allow minting URIs for different resources which are equal after normalization. It's a SHOULD NOT. I assume that the reluctance to go with MUST NOT results from the concerns raised above, but still it's such a corner case that support for it should IMO be trumped by clarity of semantics and ease of use and implementation. Though users and implementors are, by a MAY, explicitly allowed to conflate such URIs, making some resources unavailable via URI from their perspective, so it's a very strong SHOULD NOT and groups of people wishing to violate it for a good cause (whatever that may be, can you give a use case?) have to ensure there's nothing in either their systems or any intermediaries that would thwart their endeavour by performing normalization (which is always legal per the proposed spec).
Would it be feasible to spec that equivalent URIs simply do identify the same resource, and if different representations are returned for different forms, it's a strange but unambiguously identifiable resource? (That's exactly already the semantics for URIs resolved by servers using their file systems,which is the most popular method. If there's an RSS feed at , then the file gets deleted, and after some time a new webmaster (possibly even not knowing that there used to be an RSS feed) places an icon (like ) there (and configures the appropriate ), the resource doesn't change. It's just a weird resource whose representation (independent of other factors, thus no ) is an RSS feed for some period, then it has no representation ( or ), and still later it's represented by an icon.) It doesn't break backward compatibility with implementations doing crazy things, those things remain technically spec compliant, it just pinpoints the semantics, saying that, despite possibly different representations, some things are the same resource (which current specs leave unclear, so some might have assumed otherwise, but, as I wrote above, it's such a corner case that I'd be surprised to learn that somebody actually not only held this interpretation, but also relied on it). The added burden of compliance to the stricter semantics is on people minting URIs for resources. And if they're unaware of normalization, we'd actually do them a favour by defaulting to the anyway likely desirable thing – having all those other equivalent forms of the URI identify the same resource (and yield the same representation, unless they put enough effort to circumvent normalization and have different representations for the same resource depending on which of the equivalent URIs was used, but doing that indicates they do know of this stuff). One more nit. Is normalization all or nothing? Or are HTTP components allowed to e.g. only omit port 80 and keep dot segments? I think it should be specified and prefer the former (which also follows Postel's law), though I realize there may be popular implementations doing otherwise; if so, a SHOULD is probably the most that could be counted on. (For completeness: are they allowed to denormalize, e.g. introduce case variation in the authority part?)
This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.
I believe that NAME comment on that issue is already covered by the following section on Denial of Service.
If a malicious server claims support for a variety of common hostnames for which it doesn't actually possess certificates, browser clients with a long-lived connection to the attacker will probe for certificates when the user attempts to access those sites. This allows the server to monitor user behavior during the lifetime of the connection, even without valid certificates. One obvious strategy is to probe everything "interesting" ASAP after the ORIGIN frame, but that obviously leaks what the client considers interesting, which is its own privacy leak. Note that a DNS lookup of claimed hostnames prior to requesting the cert prevents this attack. Should probably recommend that clients which omit the DNS lookup never solicit secondary server certificates, but probably don't need to mandate anything.
In addition to monitoring user behavior, depending on client behavior (do you race two connections? fallback on error?), the malicious server could also deny access to other hostname or degrade performance.
Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!
Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.
see URL and URL
oh wow... I apparently didn't confirm the merge so this is still pending. I really thought it was done and published -11. Sigh. Sorry. Will look at doing a -12 soonish.
see
Thanks for these additional updates. Michael B. Jones, Sir, I have endeavored to reply inline below to the remaining comments and/or addressing them with further updates to the source of the draft, which will appear in the -11 revision that hopefully will be published soon. I have the honor to be Your Obedient Servant, B. Cam remain consistent with that. But will expand the text defining Holder to better accommodate its use throughout the document. possible" line of reasoning, the use of the words "array elements" to mean array elements is the most concise and meaningful terminology the document authors were able to conceive of to convey the concept of elements in arrays. I believe it would be a disservice to readers to embellish the wording. a different misunderstanding at play here... and Terminology", sufficient and appropriate for the mention of a piece of terminology established by convention in a previously published RFC. 5.3. DPoP/RFC9449 is actually a complete sentence and this draft will be fixed so that it will also have a complete sentence. 5.3.2. the cnf claim the way to enable key binding with that increased interoperability as a primary aim. factually incorrect. The current wording might not be as descriptive as you'd like but it is correct. In what way does the encoding make it not a SHA-256 Hash? Asking rhetorically. opinion, that supports the assertion that any of that is "best practice". There are two occurrences of "[like or such as] nbf, iat, and exp" in the draft. In URL they are mentioned in the context of "claims carrying time information", which is what they all are. In URL they are mentioned in the context of claims to check regarding the validity of the SD-JWT. The "nbf" claim, as you likely know from (I think?) having written the text in RFC7519 , has normative requirements around when the "JWT MUST NOT be accepted for processing." As such, it is entirely appropriate in the context of mentioning some validity-controlling claims.
The only normative requirement on the "iat" claim , however, is about the syntax of its value. Rejecting a token based on the "iat" value can be required by a specific profile of JWT, such as was done in DPoP, but is otherwise something that is at the discretion of an implementation/deployment and something that has apparently been the cause of some interoperability problems . Arguably "iat" shouldn't be in that list. 10.7. belong in this list. place of content omitted from the main payload. The ellipsis is often used in place of content omitted from the context at hand. 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.
Thanks very much for addressing the majority of my comments and for replying to the rest of them. I’m replying inline to the remaining ones that I believe should still be addressed. I’ve deleted the ones from this thread that I’m satisfied with the responses to. Best wishes, -- Mike From: Kristina Yasuda Sent: Wednesday, August 14, 2024 6:07 AM To: Brian Campbell Cc: Michael Jones ; EMAIL Subject: Re: [OAUTH-WG] Re: Review of draft-ietf-oauth-selective-disclosure-jwt-10 Thank you very much, Mike. Majority of your comments have been incorporated in this PR URL, which has been merged. Below, in bold, please find explanations for the points that have not been reflected. We appreciate your review. Best, Kristina Introduction: The usage of “Holder” in “used a number of times by the user (the "Holder" of the JWT)” inconsistent with its usage in the definitions, which defines “Holder” as being “an entity”. The usage here in the introduction makes the holder into a person rather than an entity. Please adjust the language here to not confuse the user who utilizes the holder with the holder itself. -> Holder is defined as an entity and a person can be considered an entity.
We also have a phrase "the user (the "Holder" of the JWT)" in the introduction. Hence the editors consider the current wording to be sufficient. Since “Holder” is sometimes used in the spec to refer to the Wallet software and sometimes used to refer to the person using the Wallet, I believe that readers would be well served to make a clear terminological distinction between the two. Introduction: In “"Claims" here refers to both object properties (name-value pairs) as well as array elements.” change “array elements” to “elements in arrays that are the values of name/value pairs” (or something like that). Without saying what the array elements are, readers will be confused about what’s being referred to. I’d apply this clarification in 4.1. SD-JWT and Disclosures and other applicable locations as well. -> There is a misunderstanding. the intended meaning here is exactly what the text says: "each element in the array (regardless if it is a name/value pair or not, an array element as a string counts too) can be selectively disclosed". The fact that a misunderstanding is possible and occurred leads me to believe that a clarification of this phrase is needed. Readers won’t necessarily know where the “array elements” being referred to occur in the data structures. That was certainly my experience, hence my initial comment. Possible wording that’s simpler than my initial proposed wording could be “array elements occurring within Claim values”. Or clarify it with different wording of your choosing. Feature Summary: In “A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name-value pairs) and array elements”, consider expanding “array elements” in the same manner as the preceding comment to make the meaning more evident. -> same as above. There is a misunderstanding. the intended meaning here is exactly what the text says: "each element in the array (regardless if it is a name/value pair or not, an array element as a string counts too) can be selectively disclosed". Same response as my previous comment. 1.2.
Conventions and Terminology: I suggest moving the “base64url” definition to the Terms and Definitions section and use a parallel structure to that at URL Specifically, say “The “base64url” term denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515].” Then introduce the rest of the definitions with the phrase “These terms are defined by this specification:” as is done in RFC 7519. The current presentation is fairly jarring. -> Current text already points to Section 2 of RFC7515. The editors consider the current definition sufficient and clear enough. Yes, the definition is clear, but it’s in the wrong place. Definitions belong in the Terms and Definitions section. The current location leaves it strangely hang in a different section by itself, separate from the other definitions in the spec. Key Binding JWT: Change “MUST NOT be none.” to “It MUST NOT be "none".”. -> Changed to “It MUST NOT be .”. it is exactly the same wording as in DPoP RFC. The current wording is a sentence fragment – not a complete sentence. The fact that that error slipped through in DPoP isn’t a reason not to correct it here. 5.3.2. Validating the Key Binding JWT: In “if the SD-JWT contains a cnf value with a jwk member, the Verifier could parse the provided JWK and use it to verify the Key Binding JWT.”, change “could” to “MUST”. Make this normative to increase interoperability! -> the sentence you point at is an example, so we cannot add a normative statement here. We changed "should" to "would" to reflect the intent behind the suggestion. OK. Please address this then by adding this normative sentence at an appropriate place in the specification. “When the SD-JWT contains a cnf value with a jwk member, this key MUST be used to very the Key Binding JWT.” 6.1. Issuance: There are many places from here on where the label “SHA-256 Hash” is used, for instance “SHA-256 Hash: jsu9yVulwQQlhFlM3JlzMaSFzglhQG0DpfayQwLUK4”.
Change all of these to “Base64url-Encoded SHA-256 Hash” for correctness. -> Editors consider it to be sufficiently clear from the specification text that it is a base64url-endoded hash. This would also require changes to the tooling and might unintentionally make the examples harder to read. The fact remains that the current wording is factually incorrect and therefore needs to be corrected. If this can be done by updating the tooling, that’s actually good, since it means that it will be consistently corrected everywhere the error occurs. Verification of the SD-JWT: Delete “nbf” from “claims such as nbf, iat, and exp” and everywhere else in the spec, other than in 10.7. Selectively-Disclosable Validity Claims, where both “iat” and “nbf” should be listed, as described in my comment there. “iat” (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas “nbf” (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare. -> "nbf" is used merely as an example here. the fact that it might be used rarely does not mean it cannot be used as an example, since it is a registered claim in JWT RFC. Sure, it’s an example, but the examples should nonetheless reflect best practices. Please delete “nbf” here. 10.7. Selectively-Disclosable Validity Claims: Add “iat (Issued At) to the validity claims list before “nbf”, and change “nbf (Not Before)” to “nbf (Not Before) (if present)”. “iat” (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas “nbf” (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare. Change all uses of “nbf” to “iat” elsewhere in the spec. -> same as above. "nbf" is used merely as an example here. the fact that it might be used rarely does not mean it cannot be used as an example, since it is a registered claim in JWT RFC. As above, the examples should reflect best practices.
Please at least add “iat” to this list, even if you choose to retain “nbf”. Everywhere: Consider changing the name “…” to something more indicative of its function, such as “sdelement” or “sd_item”. Or alternatively, at least provide rationale for why that non-obvious name was chosen. -> we have extensively bikeshedded this claim name, and this one was chosen because it is concise and natural since '...' is what is used when something is omitted in a list. there seems to have been some misunderstanding how disclosure in the arrays work, so hopefully with the clarifications above, this claim also feels more appropriate than before. I wouldn’t say that there’s a misunderstanding in how disclosure in arrays work. Rather, I’d say that the current exposition of array disclosure can leave readers wondering what is meant, and could be improved by the suggested clarifications above. Thank you for explaining that “…” is intended to be understood as the ellipsis character, and the intuition behind it. Its usage in that way is slightly odd, since the ellipsis character is used in place of omitted content, whereas in this case it’s used with the opposite meaning to introduce content that is NOT omitted (content that is disclosed). Be that as it may, I understand very well the reasons for keeping the claim name as it is. Nonetheless, I think it would be helpful to readers to add a comment when the claim name is introduced about why this otherwise non-obvious claim name was chosen. The sentence you add could be something like “The claim name “…” was chosen because the ellipsis character, typically entered as three period characters, is used in contexts where content is omitted (not disclosed).” Or choose your own wording. Give readers the intuition behind the choice. Finally, this comment was incompletely addressed: Section 11.1. Storage of Signed User Data: Please change “OpenID Connect” to “OpenID Connect [OpenID.Core]” (adding the missing citation). Best wishes, -- Mike
Adds some additional notes and warnings to developers on how to more carefully use SameSite cookies.
We are reporting on the behavior of cookies on cross-site windows opened through that goes against our assumptions (implied by the current specification) on when and how cookies should be isolated. Breaking these assumptions can lead to security issues, allowing the bypass of cookies as a defense mechanism against CSRF and XS-Leak attacks. The following table shows when cookies are attached to requests associated with s and pages opened through (where :x: stands for not attached/not accessible and :whitecheckmark: for attached/accessible): The behavior of cookies regarding page reloads for pages opened through from a cross-site position is evident from the : Currently, the specification mandates blocking cookies on user-initiated page reloads but not on reloads performed through JavaScript. We think that cookies should also be blocked in this scenario, as this interaction between JavaScript navigations and cookies allows attackers to bypass the restrictions imposed by (see 2.1). Additionally, we verified that cookies, even when not sent in the top-level request that loads a page, are still attached to requests that load subresources for that page. This behavior is not explicitly defined in the specification. However, its counterpart (setting a cookie) is defined as follows: Although these requests are not cross-site, they are performed implicitly by a page navigated from a cross-site context, effectively enabling an attacker to perform authenticated cross-site requests (see 2.1), or cookie tossing attacks. Following this argument, when considering that user-initiated page reloads are deemed cross-site and therefore do not attach cookies, it seems reasonable to assume both JavaScript navigations and subresource loads should also not attach cookies, as they are also transparent to the user. It is possible to abuse the previously described behavior to bypass CSRF protections An attacker can forge same-site requests starting from a cross-site position by abusing gadgets that result in secondary same-site requests. An example of one of these gadgets is a JavaScript-based redirect that performs a redirection using attacker-controlled data. Here is a possible attack flow: Victim visits URL, setting the cookie cookie for domain .