jiebi/CodeConvo huggingface dataset:
What does it mean for a client to send, for example, a CONNECT request in the binary message. Is that permitted or prohibited?
I don't think that it needs to be prohibited. It's just not going to do anything that makes any sense. Worth a note perhaps.
I guess it could work if the thing you're delivering the binary message to actually actions the CONNECT, exchanging tunneled bytes would just look like content.
You would need somewhere for those bytes to go. A valid CONNECT request doesn't include a body. It's nonsensical basically.
(also adds two paragraph breaks)
Thanks! To be completely formally correct, the term from RFC3986 should not be quoted as "user authentication information in the URI" but as "user authority information in the URI". Is that correction possible?
WFM. NAME ?
No, it isn't correct to say that it is user authority information. The purpose of userinfo in a server-based URI format (this://server/) is to supply canned authentication data for use if the server requests such information. It is strictly for use on the client-side and is not directly passed in HTTP unless that (Basic) happens to be the form of challenge requested by the server.
That would be an override by HTTP of the definition in RFC3986 then? (Not saying that is illegal; HTTP predates this URI spec.)
The generalises the constrained use for authentication by allowing the entire URI to be a server-side spec and the client to derive a hint about it as a possible authentication user. This can end any such difference in interpretation between HTTP/bis and the URI format. I do know this is a broadening of the user concept in HTTP; I also believe that this is not without a need.
RFC3986 says: Specifically, the userinfo supplies the information necessary to gain access to the identified resource via a process of authentication. That process is selected and defined by the origin, not by the URI, and the username is not an identifier of authority. Note that userinfo for http and https URLs has never been allowed, going all the way back to RFC1738. Some applications do use that syntax, internally and in a way that is not subject to the Internet standards process, so we warn about it in general.
The states RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent. It only says and continues to describe the intricacies of ":password" handling. The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing. This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated. I have written an that places it in a header with the intention of adding user names in much the same manner as host names, as a selector for a naming scope of resources.
I believe that obscuring the authority for the purposes of phishing is not really mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups, but these are probably easier to remedy when credential inquiries are only made in response to and headers.
Discussed in Basel. Correcting the reasoning of why it was deprecated can be addressed editorially. Changing what was deprecated needs to be a much larger discussion and pull in the security community.
This were replaced in Subscribe Locations (hints)
These parameters have been replaced with explicit fields in the SUBSCRIBE message. All that's left (outside of SETUP) is AUTHORIZATIONINFO in SUBSCRIBE and ANNOUNCE. I would just as soon get rid of non-setup parameters entirely and have an "authinfolength" field in the messages which can be zero. At a minimum, we need to eliminate GROUP and OBJECT_SEQUENCE.
+1 I would go even further and make a dedicated AUTH message.
Whoops, those were deleted but must have been re-added in a merge conflict.
To facilitate this forward for submission on Monday, I'm going to merge a few changes for additional discussion/review.
Fair, could you provide a suggested change? [edit] let me elaborate: not making iat mandatory! But about the fact that extension points in Receipts can render them with an expiration date and that only in the architecture's base definition they do not expire.
After reviewing comments and the paragraph this change sits within, the merged suggestions make a minor improvement, and I don't believe rewinds any problems. While we can/should make additional improvements, can we adopt this change? NAME NAME you have blocking requests. If the merged suggestions don't resolve your concerns, can you either make an additional suggestion or comment on why this shouldn't be merged?
NAME here you go: URL
The changes that have been made to the pull request has lost somethings. The logical receipt itself does not expire. The evidence captured in the ledger is more than just the hash of the signed statement as it has to capture the tests done to the signature and the results. That evidence and where it sits in the ledger establishes a time basis for the decision. A new signature on top of that linkage to the evidence in the ledger is being equated as a whole as the receipt. The "thing" signed is the same (location into the ledger) and the only thing that has changed is possibly the identity key material and algorithm. It is this concept of "never" expiring that is important to key.
from :
Tagging NAME
NAME we'll close this in a week and can reconsider with a PR.
Referring to , the latest changes provide the flexibility for Transparency Services to maintain previous receipts and re-issue them or generate new receipts which may not be persisted. As such, I'm approving this PR as incremental progress.
SGTM. Feel free to merge if you are sure we won't need this. Kind regards, R
John Scudder raised during IESG review: algorithms that use a reserved token value that cannot be expressed in Structured Fields". This is a well-formed sentence but I have no idea what it means. I made a desultory attempt to suss it out by searching the document for "token" and this was the only occurrence. If people who will actually be making use of the registry can be expected to make sense of it, then feel free to disregard my comment, of course. This reminded me at some point, I'd sketched out a design for the "Hash Algorithms for HTTP Digest Fields" registry that worked differently with what we ended up with now. In that design, it would have been possible to register an algorithm in the table under some friendly name and then separately register some Structured-Fields identifier that it related to. This would have made it possible to register an algorithm but reserve it from being used, in order to (for example) try and maintain some parity with old digest. Needless to say, the original sketch design had flaws and we didn't go that way. Instead, the registry requires entries to be identified using a Structured Fields key, which makes the idea of a reserved status due to a key that can't be used rather strange. TL;DR lets remove the "reserved" status because it isn't used by anything already and doesn't have much logic behind how it would be used in future.
We need to evaluate and possibly pare down / adjust the flags in the frame, based upon real-world use cases. See Kazuho's evaluation: URL
I agree the need for evaluation. OTOH, I do not think we should pare down / adjust flags, since real-world use cases could change as time evolves. The way it is defined now represents the cache state as-is and I believe that it would be most resilient in the long term.
OK.
The "Refresh token binding" section requires "The client MUST also use the same Client Attestation." What is the intention of the requirement from the following options? The exactly same client attestation JWT. The refresh token becomes invalid after the client attestation JWT expires. Even if the attester issues a new client attestation JWT for the same client key, the new client attestation JWT would not work with the refresh token. If the requirement expects this behavior, AS implementations would simply use the hash of the client attestation JWT to judge whether the client attestation JWT presented in the refresh token flow is identical to the previous one. Any client attestation JWT for the same client key issued by the same attester. If this is the actual intention of the requirement, even after the original client attestation JWT expires, the refresh token can be used with a new client attestation JWT issued by the same attester. In this case, AS implementations would check the combination of the attester's identifier and the client key during the refresh token flow. Any client attestation JWT for the same client key issued by any attester the AS trusts. If this is the actual intention of the requirement, even after the original client attestation JWT expires and/or even after the attester ceases its service, the refresh token can be used with a new client attestation issued by any attester the AS trusts. In this case, AS implementations would check the JWK thumbprint of the client key only during the refresh token flow and would not check whether the attester is identical to the one of the previous client attestation JWT. FYI: defines a mechanism to bind an X.509 certificate to an access token. The specification states that a JWT access token should include (which represents the SHA-256 thumprint of an X.509 certificate) in its payload if the access token is bound to a certain X.509 certificate. It results in that certificate-bound access tokens and refresh tokens expire when their X.509 certificates expire and that renewing X.509 certificates for the same subject does NOT revive the access tokens and refresh tokens. Therefore, client applications have to go through an authorization flow again to get a new access token once the X.509 certificate bound to the previous access token expires. There are pros and cons.
The requirement will need to be rephrased depending on what the "refresh token binding" wants to achieve.
Yeah, the statement "The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued." is problematic and needs to be removed or rephrased. The intent, as I understand it from previously discussing/pushing the issue of RT binding for this draft, is that the RT needs to be bound to the client instance. And that means binding the RT to the client instance's key. I think Tobias didn't want to go so far as saying that b/c he thought it was too inflexible. But the client instance's key is currently the only thing here that uniquely identifies the client instance.
NAME is correct around the intent here, I agree the wording makes it unclear so it should be clarified that the binding is to the client instance key used when the RT was issued.
Why not just use the same client attestation JWT? That would not require any client instance identification and is also not a privacy issue. urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation -> urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation Originally posted by NAME in URL
Related to . The problem with this model is that the refresh token if bound to the client attestation JWT then limits the RT lifetime.
The text we landed for to define priorities (URL) indicates that we should use a 8 bits ( where is ) to convey subscriber priority and similarly a byte to convey publisher priority. ( URL ) ( URL ) The text also indicates that lower values have higher priority which I read as meaning 1 () should be sent before 10 (), (After) is 133 (u8) Edit: We should probably recommend that implementations use a mid-range value like as a default to allow for prioritizing both above and below it. (The MoQT spec doesn't need to define a default since these values are currently always explicit on the wire, but I think it would be helpful to provide guidance here.)
I have a slight preference for treating these priorities as signed values because it makes a good default for implementations to choose. That way it's possible to go above or below the default. The same is possible with unsigned values, too, but if we go that direction we may want to provide some guidance to that effect (recommending something like or as a default mid-range value).
Oh, nevermind, NAME noticed some text I missed in section 4: "with 0 being the highest priority" which would imply these are unsigned int values, . It may still be helpful to make that more explicit and recommend a default mid-range value.
I'm fine with some editorial text here if that's how we want to resolve it? (PRs welcome NAME ) I'm also ok with it being signed, since it it nice for 0 to be a 'default' value, but we don't use signed integers anywhere else in MoQ, so I'm a bit concerned that using them in exactly one spot could be confusing or error prone?
In some cases, things would work better if we allocated some ranges of priorities to specific DSCP like "less than best effort" or "best effort". That would end up making the actually numbers here have absolute meaning too instead of just relative meaning.
In the Terminology section, the Trust Domain value is being defined and referenced in the aud claim as universal resource identifier. It should be spelled Universal Resource Identifier and a reference to RFC3986 should be added. However, later in the document, the aud claim value is specified as defined in RFC7519. This RFC defines the aud claim as "StringOrURI". The different passages should be aligned. Furthermore, the examples for the aud claim values should be aligned accordingly. In section Txn-Token Request the POST request example to the token service uses: If an URI is used, I suggest to use 'https' instead of 'http'. Later the JWT body example of the Txn-Token just uses a string:
As brought up in , resumable uploads may interfere with intermediaries scanning the request content. This PR adds a paragraph in the security considerations. Closes URL
Some security measures that involve looking at incoming HTTP requests might be circumvented by resumable uploads. For example, a filter which looks for certain HTTP headers and corresponding text in the request payload might not be triggered when the header occurs in one request and the matching body fragment in a subsequent request. I don't believe there's anything we need to change about the protocol here, but it's probably mentioning this in Security Considerations. Perhaps guidance would be to ensure any security measures are either resumable-upload-aware or are explicitly called to inspect the final request between receipt of the last chunk and execution of the original request.
Thank you, that is a good point. I have opened to add a paragraph in this regard. Please let me know if that expresses the problem correctly.
clarifies that you can always ignore you can ignore when using SRI if you validate both, it is nice to provide useful errors
Me neither, but this comes from RFC3230.
Well. This is a standards track doc developed in an IETF WG. If we want to change things, we can.
"There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails. This document specifies no requirements or guidance for user agents that experience such cases." This makes it sound almost as if it could be ok to ignore an error on one level if there's no error on the other level. I think the spec should say that a user agent supporting both mechanisms must implement all requirements of both specs, no matter what.
Thanks Julian. I agree and will make a PR to tighten up the language.
NAME should we really specify what a SRI implementor should do? RFC3230 explicitly states that URL and we are not changing this.
That doesn't seem to be producing a list in the actual Internet Draft; see URL - maybe an indentation problem.
This is a PR to propose changes in the data model PR. Largely work in progress, but I wanted to first propose an organization.
The introductory text seems clear to me. I have questions about what it means for an object to be 'atomic' - since it can necessarily be larger than an MTU it might not get delivered. It can be repaired of course, but what are the consequences to other objects in the group or track if the object never completely arrives? Are there restrictions on receivers attempting to use partial objects? This reader is excited to read the next chapter :D
NAME The main consequence of "atomic" is that it is way better to send one complete object than two incomplete objects. That should very much guide scheduling of transmissions at relays. The other consequence is that if publisher can split a big blob of data into several objects that can be processed independently, they should. For example, instead of sending "the entire GOB as an object", they would get better results sending the GOB as a series of objects, with each object boundary becoming a proper "cut mark". And yes, I have to develop the text. I checked in a partial PR to Suhas' PR, mostly to test my editing chain...
thanks Christian for detailed text. I will merge it into my branch and do an updated version based on this.