jiebi/CodeConvo huggingface dataset:
RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.
NAME was confused by the text here and I confess that I don't remember why it was added. There are actually esoteric cases where you get server data that you can read before the handshake is complete (QUIC tends to enable that sort of mess), but there is no circumstance where the client can read the 425 but can't also determine whether that the handshake is not done to its satisfaction. The client might decide that it wants to abort and not provide a certificate or something, but most implementations don't really allow that sort of messing around.
Source:
It's completely irrelevant to the recipient what port number was used for an upstream intermediary, which is why it says MAY here.
There are two issues here: 1) The protocol-name doesn't reflect the scheme in use, for HTTPS, it's still 'HTTP'. The practical implication of that is that when HTTPS is used, the port needs to be explicit, even if it's the default for HTTPS. A clarifying note might help here. 2) HTTP/3 uses UDP, not TCP. Omitting 'TCP' from the MAY requirement might help.
This is for Via. HTTPS is not a separate protocol. "https" is a scheme that, among other things, doesn't allow an intermediary to forward HTTP messages until they are beyond the origin secured connection (and hence no longer HTTP/TLS). Whatever the post-TLS origin does to forward its messages via CDN or downstream origins is beyond the scope here.
Yes, we can just remove TCP from that sentence.
That would be acceptable.
This PR attempts to address the problem of documenting the various ways that known key content types, such as and are discovered from opaque strings or URIs such as and . This PR also explains how DIDs are similar to OIDC.
I have a working demo of this on URL, URL URL Its also possible to do same thing with did methods other than , for example ... There is a demo of that working with index db here: URL This shows that there is interoperability across issuers that use different did methods, that conform to the same resolution and dereferencing interfaces.
made comments, but I think a bit more discussion/work is needed.Asked Kristina to also look at this.a proposal for discussion @ IETF 117 Hackathon and meeting seems very useful to me. :+1: LGTM to merge as a baseline for future discussion
Proposed fix in URL - note that this is an incompatible change.
FWFW, if the argument is that not escaping the escape character is actually ok for this purpose...: in that case the prose should actually explain this.
I actually do think it's ok to not escape the escape character. If you've got non-ASCII header values you're already kinda out in the weeds in terms of processing the header bytes. Ultimately the signature base really only needs to have bytes, but its input is constrained to ASCII because (1) all derived components are already constrained this way (2) component names and arguments are already constrained and (3) header component values (here) are SUPPOSED to be constrained to ASCII, but might not be in some weird corners as you've pointed out. All that the newly-introduced percent encoding is doing is putting bumpers around the weird corner that isn't supposed to happen but might in some cases. I'd honestly be happier with putting advice to use the binary sequence wrapping ( flag) on problematic non-ASCII header values instead of doing percent-encoding and requiring universal escape of the escape character when the encoding isn't going to hit the VAST majority of use cases. That would reverse the previously-applied fix but I'm fine that.
That works for me. If we combine that with the "MUST produce an error for non-ASCII" in the signature base generation (and people actually do that check), we should be safe.
OK, I'll work on that, unless you want to take a swing at it.. Since we've already got the cut-out for fields that don't behave nicely as lists (specifically Set-Cookie), we've got a good space to put this advice. I think an error on generation makes perfect sense here too. I'll back out the percent-encoding for non-ASCII headers at the same time (but note it'll stay for query parameters, where I do think it makes sense to use).
Good clarification, with a few nits to reduce and clarify the text
All edits have been addressed. I believe this is ready for merging.
Thanks, NAME Sounds like we can address this suggestion separately and we can merge this as-is
For the next submission deadline, RegInfo needs more detail to convey it's purpose. Maybe... it may even need a new name, as RegInfo might not be limited to key/value pairs about registration policy?
LGTMI would prefer "The key/value pair semantics are application-specific, or even possibly specified by each Issuer for each of their Feed." but I am fine with both formulations. Thanks.
Add security consideration for replay attack prevention and add nonce as optional value for PoP JWT URL
Currently the specification does not define a mechanism for an AS contributed nonce to feature in the client attestation PoP meaning replay attack detection by authorisation servers requires tracking the JTI within the time window set by the PoP's iat claim. We should elaborate on an AS contributed nonce for the specification.
What about using the authorization code or pre auth code as suggested in our demo?
I think this is an option, however the nonce for client authentication becomes dependent on the grant type which creates a bit of an awkward coupling when an application wants to say use this mode of client authentication for grant type other than pre auth code or authorisation code.
How many implemantations out there actually use different grant types than auth-code? Given that this serves our purposes and imo everybody is using auth-code, I think that we should RECOMMEND that scenario but I#m ok with showing up alternatives as you suggested. NAME What's your opinion on this?
I think the flow can be used with and without nonce. If it is used without nonce, jti and short expiration must be used to limit the risk. If a nonce is used, I think using the codes is a pragmatic option. Alternatively, the AS could provide a dedicated nonce with the credential offer or authorization response. It could also provide the nonce with a token error response.
discussion on 23.05 is leaning towards DpoP-style error providing nonce
can we please bring this issue forward, it is very important? I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR).
on that topic, I would suggest such an AS provided nonce should be good up until the AS says otherwise. That would allow a client to use the same nonce for PAR and token endpoint.
Update provided in
PR
PR
Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this
and . if messages must be known, explicit message lengths are redundanct except for OBJECT and messages with parameters. This also eliminates a whole class of potential errors where the message length does not match the actual parsing of the message. Not checking this -- and not have any message type be potentially zero-length -- greatly simplifies the parser.
And trying to use messages without negotiating an extension/version just won't work for MoQ. We're designing a protocol explicitly for relays so you do need relay cooperation, or at the very least some information on how to forward unknown messages.
Also I love that you're using "parameter count" instead of "parameter size (bytes)". It makes it much easier to build a streaming encoder/decoder without allocating temporary buffers.
I thought we agreed to allow extensibility by allowing new message types to be created.
Like to see us agree on a extensibility strategy before deciding what to do on this. We also need to decide if messages can have optional fields
We have version negotiation, and presumably we'll have extension negotiation too. What's the use-case for adding new messages without negotiating them? The problem is that we can't relay unknown messages, so all it takes is a single uncooperative relay on the chain to shallow them. I think we need explicit negotiation as a result.
If we have extension negotiation, I agree. But if our extension negotiation mechanism relies on not getting an error on unknown messages .... PR is wrong place to discuss this but I think what I would like to see is a good way to do extension negotiation, and then like you have here, error on any message that is not part of a negotiated extension. I think I would lean that way if we had an extension negotiation mechanism. Note this is the opposite direction of HTTP which is often our model for things. HTTP just skips past unknown headers.
Fail, or pass over?
IMO fail. We have version negotiation and should add extension negotiation so it should never happen. The problem with ignoring messages is that MoqTransport is designed for relays. If an intermediate relay doesn't support a message, it then gets silently dropped. At the very least we need enough information on where to forward unknown messages.
If it's going to Fail, then most Message types don't need a length field at all (OBJECT and ANNOUNCE_OK would be the exceptions)
Individual Comment: Is there any reasonable action a relay can take on an unknown message, besides discarding it? See how HTTP recently added a "Capsule" concept which is an envelop with a default relay action of "forward", which allows for end-to-end extensions without upgrading all intermediaries. Given that MoQ handles forwarding on a per-track level, I think there probably isn't any way to generically forward a message that isn't associated with an active subscription. That said, it makes me wonder if we want to add a capsule-like extension message, or does the existing OBJECT definition give enough flexibility?
Yeah exactly. It's impossible to know the intended destination of an unknown message with the current ANNOUNCE/SUBSCRIBE mechanisms. I'm using the (as the track namespace) and instead of . This actually does let you forward unknown messages from publisher -> subscribers and subscribers -> publisher since each session is associated with only a single track namespace. Session pooling is always the issue...
I think we need extensibility. We want the protocol to be extensible so a given server might support extension A and C and another server supports extension A and B. It is very hard to do that using just a version number.
Rereading all this - II think this whole issue just need to be uplevel to what is the extensibility strategy then this detailed part of it will be easy.
There was support for not requiring a length and failing on unknown message types at the Interim, so the intent is to land PR after review.
LG. The agreement at the interim was to follow up with separate frame types for object with and without length, but do that in a separate PR.I love it. It also means you can implement streaming encoders. Prefixing each message with the length required a temporary buffer or 2nd pass to compute the length.LGTM
and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm
Clarify method case requirements. Add justification for use of empty query string.
Comment by NAME : >If the query string is absent from the request message, the value is the leading ? character alone: When would it make sense to sign this component although empty? Might be good to add some clarification for the reader.
URL I would drop the "and conventionally standardized method names are uppercase US-ASCII". Method names are case-sensitive, that's what is relevant. The second part somewhat weakens that statement.
This is a note to implementors and doesn't change the normative requirements or behaviors -- I think we should leave it in. Note that the text in question appears in section 9.1 as referenced:
Good catch, and I should have objected to that. Anyway; I don't think it makes sense to note it here. It doesn't help at all - the method name is what appears in the request message. The note doesn't add anything useful, but might cause confusion. Take this ticket as proof.
Having seen people try to normalize things by lowercasing because "it made sense", I disagree that the note doesn't add anything useful. I'd like to leave it in.
Just to clarify: my concern is that implementers will take that as a suggestion to uppercase.
which can be found at
I think the following change might be cleaner per in Jefferey's review. "9. Check that the Key Binding JWT is valid in all other respects, per [NAME and [NAME -> "9. Check that the Key Binding JWT is a valid JWT in all other respects, per [NAME and [NAME
Sure, that's done in 4442c3a06767498ee24154024d8dff987325b08f
While reviewing URL, I had to understand some of the SD-JWT verification algorithms. I noticed some issues, which I've listed here. I haven't filed individual issues yet because I'm not sure how you'll want to group them. Thanks to NAME for doing a first pass; any remaining mistakes are probably because I didn't take his advice. [x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] "The claim name, or key, as it would be used in a regular JWT payload. The value MUST be a string." <- I assume the "value" is the key, and not the key's value in the JSON object? [x] Why is 128 bits only recommended and not required for the salt?[x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] This mentions "bytes preceding the KB-JWT in the Presentation", but several other places mention "Key Binding is provided by means not defined in this specification", in which case the relevant bytes don't precede the KB-JWT. These should be consistent.[x] Are "Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that" and "The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT" accomplishing the same thing? [x] "Separate the SD-JWT" should cite an algorithm for doing that. I think it's "5. SD-JWT Data Formats" which implies it's just "split on '~'"?
[x] "Ensure that a signing algorithm was used that was deemed secure" disclosure and then call a recursive element-processing-and-replacing function, but this isn't too bad. [x] "Remove all array elements for which the digest was not found" probably won't confuse anyone for long, but my first reading said that an array in the payload like [1, 2, 3] would wind up empty since no digests were found for the elements. [x] "Check that the SD-JWT is valid using claims such as nbf, iat, and exp" should say where those claims are defined and what part of which object they appear on. (URL, and the top level of the payload, not the header, right?) [x] The "required validity-controlling claim"s should probably be an input parameter to this algorithm. Possibly all the IANA-registered JWT claim handling should be passed in, or this algorithm should return all the claims for the caller to deal with.[x] "create a Key Binding JWT" <- refer to the section that says how to do this. [x] "Assemble the SD-JWT for Presentation" <- This should at least refer to "5. SD-JWT Data Formats" and possibly just write out the algorithm of "make an array of the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT, and join the array with '~'."[x] This is clearer that "Verifiers MUST ensure that" is accomplished by the steps in the following algorithm, but I don't like the redundant MUST. You can just say "Verifiers need to ensure that" and then leave the normative requirements to the algorithm. [x] "according to the Verifier's policy" should be an input parameter to this algorithm, that the verifier provides along with the bytes of the presentation. [x] "verify the Key Binding according to the method used" <- how? This might be URL, but you should cite the details. [x] "Determine the public key for the Holder" <- how? This might be the 'cnf' claim, but you should say so. [x] "Ensure that a signing algorithm was used that was deemed secure" <- as above, this should be an input parameter to this algorithm or computed from the public key.
[x] "Validate the signature" <- again, cite how to do this. [x] "the typ of the Key Binding JWT" <- is that in the header or payload? (cite 5.3. Key Binding JWT and possibly URL) [x] "within an acceptable window." <- should be an input parameter [x] "validating nonce and aud claims" <- The instructions for doing this should be an input parameter to this algorithm. [x] "Check that the Key Binding JWT is valid in all other respects" should call a particular algorithm from the other specs that it cites.[x] Many of these should be normative. For example, base64url is used all over the normative parts of this specification, and it comes from [RFC7515] in this section.
Thanks for the review Jeffrey! I'm acknowledging it with this comment but also noting that there's a lot here so response/action will take some time.
1c1f165ab821dea5350f62225f103bdceff31532 one was an oversight and one was a tooling issue and oversight. I think that covers them tho.
Those other specs don't have algorithms that can be called nor do they have suitable sections to reference directly.
Some contributors want to leave open the option of a more computationally expensive hash with smaller salt values.
Yes and I've tried to remove any ambiguity there by just not using the word "value" with d015a3de2ae50623b4a294590fb2d0249e7d33b5
Per , "JWTs are always represented using the JWS Compact Serialization" the compact serialization is already specified.
That is for the claim in Key Binding JWT so isn't relevant elsewhere.
& Yeah, with 2a0e270f2e1dbfa9664bb5ce4989a2f6a1765217 I basically applied your suggestion to both places.
Yup 7d68d4ed9b91e49a0aa00254475bf7c116669dd6
Yes but I believe it's sufficiently clear in the context of the draft.
This draft is not structured such that it has input parameters to algorithms so suggestions to make something an input parameter to an algorithm are not actionable or practical.
e9acd5ed665b107776b6b41355680470cde89f2c
is a JOSE header. Will cite sec 5.3. where that's more explicit 64a4c4519668c7a63f1a0be215176657895fa0c8
That sentence starts with "If Key Binding is provided by means not defined in this specification," so there are not specific details to cite. mentions that other ways of proving Key Binding are possible. DPoP/rfc9449 is one possibility but not the only one. Nor a particularly likely one. At least not likely enough to warrant mention here.
The very next part of that sentence says "in the processed payload" and that's a non-exhaustive list of JWT claims for which a citation/reference isn't really needed.
I feel like it's sufficiently clear from context and shouldn't confuse anyone for too long.
Noted.
This draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do (e.g. URL, URL, etc). A map from (issuer ID, key ID) pairs to public keys is one application but certainly not the only one.
referencing that 072a0605bcb62937e343aaa7812aa8ef86d8379f
That's a somewhat existential and loaded question but common usage of the word doesn't preclude it describing nested items and array elements. And this draft is not alone in that. In the intro it also says, '"Claims" here refers to both object properties (name-value pairs) as well as array elements.'

"create a Key Binding JWT" <- refer to the section that says how to do this. cbee5f8457f447574400377dc6f7c9fe7f1c3c18
a474e2b0b0ff7635af38c2ac95e70b40b2f82798 makes things a little more a bit more prescriptive about suggesting RFC7800 cnf/jwk be used to convey the Key Binding key and references that section from the "Verification by the Verifier" section.
Thank you so much, Brian! overall, agree with all the responses.