jiebi/CodeConvo huggingface dataset:
That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock > wrote: Thanks for the additional time Mike and Ivo. I support moving this along, but I would like to perform a detailed read through. I have some time set aside for this and will have comments back next week. Mike Prorock founder - URL Ivo and I reviewed the results of the WGLC and there have been no responses whatsoever – even from the authors. We are therefore extending the WGLC for another two weeks until Tuesday, August 27th. Unless multiple people support progressing the draft, we will not request publication. Please send your reviews and feedback on the draft. Thank you, -- Mike and Ivo From: Michael Jones > Sent: Tuesday, July 30, 2024 10:53 AM To: EMAIL Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL
Media over QUIC is just the name of a mailing list and a general area of discussion. In some places, the draft refers to it ambiguously where a read may interpret it as the name of a protocol or working group. Maybe can call out that it is not those things and disambiguate references with "Media over QUIC mailing list" or "Media over QUIC problem space"?
I think the issue (or at least the resolution) is also tied to - the objectionable (or at least the obsolete) text in needs to change, and making the changed text also define all the ways we've used the label "MOQ" seems helpful. Expect a PR that attempts to resolve both.
Streams are equally capable of moving media, though the number of different ways to design a protocol have expanded with the addition of datagrams.
Absolutely. It might be worth mentioning that QUIC datagrams in their current state have caveats. They are congestion controlled, elicit acknowledgements, and these acknowledgements . QUIC datagrams certainly have their benefits, but protocols need to be designed to use them properly. Otherwise SRTP and DTLS might be better options.
This term may imply latency constraints that may not exist in all use cases. Further, I wonder if the framing as 'encapsulation of a media transport protocol as a payload' jives with what Victor mentioned during our call -- that part of what's interesting is using QUIC as a transport protocol.
NAME - two things (one each, for your two excellent points): this draft started out as a survey of what was being described as "Media Over QUIC" last summer (after the IETF 111 side meeting), then lurched downhill to being focused on RTP over QUIC, and then lurched BACK uphill, but not all the way uphill, to focusing on a subset of what's been proposed under the banner of "MOQ". Thanks for helping us spot places in the draft that haven't completed the trek! Agreed about reframing the framing, and if we suck any of the other use cases in - there was a lot of discussion around needing help with gaming for sub-100 ms latencies at the IETF 112 side meeting, so that might happen - the current framing might be even less helpful. Definitely worth fixing. Expect a PR soon.
I've been using the phrase "live media", defining it as "media that is actively being produced and consumed". It's not perfect but neither is drawing a numeric latency number in the sand.
NAME - just so that I understand (better) - are you saying that the media is being consumed at (roughly) the rate it's being produced? Any answer is fine, I just want to make sure I know what we're talking about here.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
Addresses issues with language about the jti claim in the client attestation and pop jwt.
The spec states: "The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token. The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant." However the is not shown in the example in the same section.
The text says jti is required URL but the example doesn't have jti URL
Duplicate of
The Client Attestation JWT seems like a long(er) lived credential that should be reusable so the client instance doesn't have to go get a new one each time (right?). But this text for the Client Attestation JWT has 'The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant' that suggests the AS might limit them to single use. I think that sentence can just be removed. \ right: URL
Agreed, need to remove this sentence from step 7 of 4.1.1.
This is how a SCITT Signed Statement associates an Issuer making a statement about an Artifact, which has been core to the draft from the start. Previously, these were properties in the protected header, aligned with DIDs: See The use of was to align with other existing standards, for how we associate these concepts. An alternative is to lift these two properties, independently, to the protected header. We already have an in the protected header for additional properties, reducing the duplicity of in the cwtclaims and protected header, potentially simplifing the model. The approach of using cwt claims allows users to benefit from existing cwt libraries, which seemed the better of the choices.
OK so the answer is yes then. I am happy with it, but this is a small, tight PR deleting the editors note, I wanted to understand the implication before I (and maybe others) understand before I approve.
Resolve Section :
LGTM
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Cc NAME
well that's one way to solve it!
URL Change "applications" to "deployment" for clarity
Looking at making the change, there are ~12 places we'd be changing "application" to "deployment" and it's not clear that it would improve the readability or clarity of the text. Furthermore, I'll also point out that this is the language used in RFC 8414, and it seems to have worked for people there, so I'm reluctant to make this change, given I don't think it would be a significant enough improvement to warrant being different. cc NAME
My comment about this section was that it was generally quite hard to follow, not that "application" should be replaced by "deployment". This sentence took a while to parse: "Different applications utilizing OAuth protected resources in application-specific ways may define and register different well-known URI path suffixes used to publish protected resource metadata as used by those applications. " I think the intent here is to say that an application may be composed of different OAuth protected resources, and each of those may have their own protected resource metadata, and if this is the case, your describing a scheme on how the application may expose the resource metadata to clients for each of the underlying OAuth protected resources. If that is the intent, changing from "application" to "deployment" may not help (these are different concepts). Perhaps just an introductory sentence for that paragraph - something like: "An application may access multiple OAuth protected resources in order to complete an operation. Each OAuth protected resource may have their own resource metadata. In this case, the application may define and register different well-known URI path suffixes used to publish protected resource metadata as used by those applications to enable a client to obtain the resource metadata for each of the underlying resources. As I write this, I think my confusion here was more about the lack of clarity on the relationship of the application (which may itself be an OAuth protected resource?) and the OAuth protected resources (which it relies on to perform an action).
NAME talked about this in Rome. The term "application", as used, encompasses all the components used to accomplish the task for the use case. That can include OAuth clients, authorization servers, and protected resources, inclusive of the code running in each of them. Applications are built to solve particular problems and may utilize many components and services.
The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
There seems to be some disagreement about this, but I think that Roy is right. It's not critical how it is registered, since it shouldn't appear in a valid request anywhere, but it meets the criteria.
I really don't think it matters, so I'm fine with it either way. Theoretically, there may be some compat value in having it listed as safe/idempotent since an intermediary may be more likely to let such methods pass. But the time slice in which this registry has existed and HTTP/2 hasn't will be miniscule -- I expect any HTTP/2-unaware intermediary won't look at the registry values either.
To the extent that it matters (i.e., very little, as you point out), I think that the intermediary example weakens the case for safe+idempotent. I really don't want HTTP/2 to pass an intermediary without triggering some deliberate recognition; that has been the source of some very serious bugs in the past.
This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.
By removing the word negotiating and avoiding the actual identifiers, we can get the important point across
Maybe a hangover from trying to tear up the photos of the "http" URI and upgrade dance. But this seems to read oddly. On one hand: on the other: I don't have a solid suggestion to improve things.
How about we just remove "h2c" from the latter statement.
OK, that isn't going to fly. I just tried it. Pulling that string is unwise. We agreed to keep "prior knowledge" in the document, and the "h2c" ALPN token is part of that. The "h2c" upgrade token has been removed already. (Too subtle? Probably.)
To fix Issue , I found that removing Example 2b is the best way to go. I tried to fixate the nonces used in the examples despite decoys being generated in one of the examples, but that got quite messy and introduces a lot of unsafe code paths into the python code. An alternative would be to manage the example manually, but that is a source for errors, so let's not do that.
The decoy concept is intuitive enough that a separate example isn't needed, I think. And per the separate example that has a completely different set of digests might cause confusion. So removing 2b seems like a good course of action. The change is larger than I'd have expected. Are all the other file changes due to regenerating examples? I think so but it caught my attention. And it seems like and this will be difficult to resolve. But maybe you've already considered that.
Why remove an entire example, if we can add a text clarifying that "Example 2b uses the same data as 2a, but because even for the same claim values, different nonces are used, not just the decoys but all digests are different from those in 2a"?
That was my initial approach, but with that change there's really not that much value to the example: It just shows a bunch of digests, where the number of digests is higher than it was previously. The fact that the digests are different can be confusing for readers at worst and the example is not very helpful at best.
So instead of showing the decoy digests in the examples you propose to list them seperately and not show a complete example with decoy digests?
We agreed on our call to generate a snippet of markdown code to explicitly list the decoy digests to improve the explanation.
I updated the python script and the spec to show the decoy digests: URL
Other than the little nit about the the text that says the decoys in the example are about the address, this looks pretty good.
Do you want to mention something in the doc history?
Good point, done!
NAME Can you please review this?
states that it was created using data from , but adding decoy values. I'd expect its param to be a superset of example 2a's, but it's not the case. Am I missing something?
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM
to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!
This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by