jiebi/CodeConvo huggingface dataset:
-- Hoare's Law of Large Problems Snac mailing list EMAIL URL
Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple?
Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems
Remove initial underscore on for I do think this change is appropriate but think we should publish a -07 soon if we proceed with it.
It makes sense for to start with an underscore, since it is being inserted into a JSON object supplied by the caller and it needs to be something unlikely to conflict with an existing claim. The field appears in the key binding JWT, a format being defined by this document. So it can safely live without the underscore.
That's a fair point, I think.
I think the same argument also applies to . It's just a normal JWT claim, so it can be deconflicted using the usual registry process.
Really they are all just JWT claims and will be registered. The leading underscore isn't magical and doesn't exempt from registration. But it is a nicety to help avoid conflict, which is particularly relevant with where/how and are used. They both are in the issuer signed JWT where there is some potential for name conflicts with application supplied data (JWT's whole registered, public and private claims guidance is supposed to help here too but conflicts are still possible). For general clarity and consistency, I agree (I think anyway) with removing the initial underscore on . But is more similar to in usage/context and those two should keep their leading underscore.
To me the difference between and seems to be that is at the top level of the JWT claims, where we're used to dealing with . But can be down in the guts of the claims, which the JWT signer might have less control over. So I would go for , but and .
Registered claims (I'm a so-called DE on there so I have some familiarity) don't fully address conflicting names even at the top level with the possibility of the use of private claim names. More could be said about that registry and what it does and doesn't provide in practice but that'd be a digression... Anyway, that and show up in the content of issuer-signed JWT is my point of vew for keeping the underscore on both. Also for keeping those two similar to each other. Lastly note that and have been in the draft for many revisions (back to -02 I think) whereas was just introduced in -06. Changing at this point likely wouldn't impact implementations much but changing would.
I'd prefer to not see ANY public claim names that start with . It starts a convention which I would prefer not to see repeated.
In OpenID Connect, we decided that our "meta-claims" would start with underscore to visually distinguish them from normal claims. For instance, see the claims and in the registry at URL I support SD-JWT continuing to follow this convention and so would prefer that the leading underscore be kept for its meta-claims.
NAME What is the difference between "normal claims" and "meta-claims" here? And why did OpenID Connect go that way?
"Meta-claims" are claims about the structure of where actual claim values can be found - claim values that are not simply top-level members in the JWT Claims Set. They're road-signs saying where to go to get them - not the destinations themselves.
Thanks, that distinction makes sense. Applying that to SD-JWT, it seems directly applicable to , and sort of fits as well, since it tells you how to read the road-signs (to continue NAME metaphor). I'm OK with these keeping ``. But is not a road-sign, it's the main event. If you ignore or , you miss out on some claims, but nothing fundamental breaks. If you ignore , you're not enforcing the key security properties of the system. So I think the original issue here is still valid.
PR URL would remove the leading underscore on (and only there). Which is the original issue here.
Minor language tweaks aligning more to RFC 7521 in how the client authentication mechanism is defined as to not limit its application to only being used at the token endpoint.
There is an idea to send the Client attestation already in Authorization Request or PAR instead of with the Token Request. I see the following advantages: the client attestation could act as some kind of mobile capability descriptor, thus allowing the Authorization Server(Issuer) to check these before the user performs user authentication, otherwise this could result in poor UX as the user authenticates and the AS realizes only afterwards in Token Request that the level of client attestation is not enough (e.g. wallet can only handle key type xyz or LoA low) I see the following disadvantage: some flows do not require Authorization Request the user usually does not give consent before sending Authorization Request
The client attestation can for sure be used to authenticate with PAR. The HAIP already requires that.
The draft just needs to be clarified that this is a general purpose client authentication method that can be used with any interaction with an AS that is requiring or making use of client authentication.
Fixes field ordering reference
In 12.6: "Any mangling of Digest, including de-duplication of representation-data-digest values or combining different field values (see 5.3.1 of [SEMANTICS]) might affect signature validation." But 5.3.1 is "Request". (note that I didn't catch this earlier because it doesn't use the "Section X of [Y]" pattern; this should be gixed as well)
Issue
Can you give an example where this is relevant? With excluding private claims we make sure all claims are uniquely identifiable across all parties of the three-party-model.
claims we make sure all claims are uniquely identifiable across all parties of the three-party-model. I dont believe this PR discourages public claims it simply reflects that there are bunch of scenarios where VC ecosystems what to interoperate on claims that are perhaps not general enough to register as public claims.
Please merge
Also considering if "Security Considerations" can be "Compatibility Considerations".
I haven't renamed "Security Considerations" in this version. And I have no issue with calling this "Compatibility Considerations". But I have some recollection that this is a required section...
Yeah don't do that or various people will start to scream at you :)
Call me a perfectionist, but on reread, I realized there was a cleaner/shorter way to clarify. Let me know if you have any objection...
Thanks Martin!
Those changes are editorial.
specifies what to do when it isn't present (use the received time), but not what to do when it doesn't parse. The intuitive thing to do is align, and say that the received time should be used in this situation as well -- but probably not require implementations to replace it if forwarded. I might write some tests...
Okay, I am still waiting on those new glasses. Too much Age. It's fine with me if we interpret an invalid Date as the received time, but that assumes we know the received time when we parse the Date. I think as long as the scope is specific to Caching, we should specify that a cache always record the time received (regardless of Date) and use the received time if the Date field value is invalid.
is used in a number of places in caching, so that modification will be pretty invasive. Why do you think it needs to be restrained to just caching? I suppose it could be specified in semantics as something like 'If the Date field value does not parse, it MAY be replaced with the time the message was received. Caches SHOULD consider the message receipt time as the Date value when it cannot be parsed.'
The "it" in that last sentence has an unclear subject (is it the date, the arrival time, or the cache?), and "consider" -> "use".
The only reason I said it is okay for caching is because we already depend on the cache having a clock and storing time received. It seems reasonable, regardless of role, if the recipient has a clock. But I wasn't suggesting a new requirement.
I suspect this may require a little bit more thought, but want to sense-check the direction. NAME any feedback you have would be welcome.
NAME NAME thank you both for your feedback, I've rewritten the block again based on your feedback and hope this is a lot more clearer.
MoQ Transport, in combination with a MoQ Streaming Format, needs to support mechanisms to allow ad insertion. This ad insertion: Should be compliant with current IAB and SCTE standards such as SCTE-35, which specifies signals that can be used to identify advertising breaks, advertising content, and programming content. VAST (Video Ad Serving Template) VPAID (Video Player Ad-serving Interface Definition) VMAP (Video Multiple Ad Playlist) Should be able to participate in both server-side and client side ad insertion schemes. The server-side solution may have a mode in which the ad is stitched seamlessly into the primary content and the ad boundaries are indistinguishable to the client. Should be dynamic in nature, allowing for just-in-time decisions to be made for choosing which content to insert. Should allow access to, and compatibility with, a subset of existing ad inventory.
Some of my initials thoughts: To stick to the separation model of "church and state", we should also have agility to support more than SCTE-35/IAB specs in the transport layer Is it required that all streaming formats must support event tracks? Or is the requirement here that just the transport through the catalog enables it? Is there a benefit to describing these requirements more generically - although enabling advertising for live broadcast is clearly the obvious use case having this functionality could be useful for other reasons, such as: In teleconferencing, a presenter switching one (or all) viewer's video to a different source such as the slide show or the presenters camera Falling viewers over to another source when the current one ends e.g Twitch's "raiding"
Given the PR above is merged, I'm closing this noting the above issue on ingest will carry on.
This is kinda silly, but it seems like adding support for coalescing is something we could fix later. with the nuclear option.
the pull request is fine by me. I do wonder if we shouldn't make the json a tad more complicated to allow for a reasonable mixed definition in the future. But an unreasonable one is obviously possible :)
Can we coalesce http and https? The implication from everything we've said is "yes", but Erik remains reluctant.
to
I was not completely sure either and that's why I posted only the issue and no PR first. I still think that in chapter 5. the extra mentions are confusing as the text and the ABNF are separating the SD-JWT and SD-JWT+KB formats. In contrast, similar explicit mention in the verification section is clarifying to me.
I wasn't sure when first looking at it and actually thing it's okay either way but have come to think it's more okay this way.
The distinguishing of SD-JWT from SD-JWT+KB is a good clarifying change in -09. Some extra mentions of KB-JWT still remain that could probably removed: In : >An SD-JWT without Disclosures and without a KB-JWT and >An SD-JWT with Disclosures and without a KB-JWT The "and without a KB-JWT" could be removed as there are separate examples for SD-JWT+KB and SD-JWT is now defined not to include KB-JWT.
Thanks NAME PR does exactly what you've suggested.
approved the PR () too.
I am not sure these are actually extraneous, but ok looks good
with unclear definition and regex requirements with DN currently in draft.
Calling NAME for some
Perhaps I missed it, but what is the motivation of changing to a URI?
We are specifically customizing the usage of in CWT as defined in . In that document, it is a type and it seems like we shifting away from the base usage of URI to something else and with a regex spec I couldn't find in a relevant I-D, RFC, or standards doc that we can normatively cite as a reference. Is there something I am missing, and is there a valid reference we could use?
I agree the current text is not clear, as it doesn't define or reference any regex. However, stating that the must be a URI with no further specification is equally unsatisfying. How about we drop any mandate to use a particular format of if the protected header is present? The identity of the issuer will be sourced from the X.509 certificate, so the value is largely redundant.
There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear? I don't mind that if others have that feedback I'll close this out and start over. That will obsolete the feedback from Hannes that triggered this PR at the same time. I can bring that on list and reference this discussion.
Ah, yes, I forgot to mention: if we want to retain the use of the string representation of the subject DN of the X.509 certificate for the value, we can reference RFC 4514.
I can also bring that up as an option on list and adjust accordingly if that is ok.
I think it’s unclear, as there is no guidance on the content of the iss, only that it is URI-shaped.
It is similarly unclear to me in the architecture requirements what one should or must do with the DN. It is implied, but left to the implementer to decide for desired X.509 use cases. It is not clear what one should do with it to correctly validate the cert use per the claim, regardless of DN or URI is chosen. Can we both agree that is part of the problem?
In any event, I apologize for the delay, I have created the following thread on list to discuss before moving forward with the PR in any significant way.
I may stand corrected and others will prefer your approach (which I dubbed Approach ). URL
Deferring 'till the week of 8/19 as some folks are on vacation.
I support this change on behalf of the URL project.
8192 characters in length that fits the regular expression of a distinguished name. What is the "regular expression of a distinguished name"?
I do understand the intent, but it would seem that distinguished name is not clearly going to have a specific reference we can use. That reference sets aside the regex requirement. I understand the need but there is some assorted LDAP RFCs and other attempts, but none seem to be the right kind of reference, even if about distinguished names in X.509. I am going to propose we go back to what we know and then put forward my understanding and interpretation of the requirement, that we want a StringOrURI like the underlying CWT requires, perhaps with added length requirements?
LGTMLGTM Hello, Last week I attempted to pick up some issues thanks to the many contributions by Hannes Tschofenig. One such issue requesting clarification or change is issue . For that, I made an associated PR, pull request . URL URL So far there has only really been feedback from Corey Bonnell (and that has been most appreciated!). I wanted to poll the list for feedback and understand if there is consensus on using the X.509 Distinguished Name for the issuer of the claim, whether or not there is a clear regex and length requirement. The current text reads like so. characters in length that fits the regular expression of a distinguished name. https://ietf-wg-URL I see a few ways forward. Do nothing, leave the current statement in the specification as-is, and close the issue reported by Hannes as a WONTFIX because it is good enough. Keep the Distinguished Name, and add a useful regex from a relevant LDAP specification proposed by Corey in his comment, RFC4514. Adapt the requirement to match a subset of the underlying data type of the CWT claim iss field, URI (from stringOrUri), and not add an additional requirement for DN regexes and format parsing. Be most permissive and interoperable, remove this requirement entirely. Corey appears to support 2 (please correct me if I am misrepresenting your position, Corey), whereas I prefer 3.
I understand the intent of further constraining iss in the presence of X.509 certains and checking against their thumbprint. It makes it more convenient and consistent for the case of Issuers creating Signed Statements with X.509 certificates as a first class solution, but at the expense of the alternatives (short-term and long-term) and resulting interoperability in the long-term. Additionally, the requirement as-is appears to adapt the CWT field to match a differing purpose from its base specification that key use in the context of SCITT. To me, that seems undesirable. Do others have support for one of these positions or related feedback that motivated the current state of the change? Given the feedback over the next week, I will modify or close PR accordingly to meet consensus of authors and WG members who respond on list to the best of my ability. Sincerely, A.J. Stein
This addresses Issue . The rest of the text still refers to asymmetric signatures, but technically, an HMAC is now allowed.
The scope of this PR was intentionally to only remove the explicit prohibition on MAC. Not to explain how it might work or adjust other language about asymmetric signatures or private keys or similar. Just remove the explicit prohibition so that, should some deployment/ecosystem/jurisdiction need to MAC for whatever reason, it's not directly going against a normative must.
Arrow C is referenced in the text "[The code in the browser] obtains an access token via a POST request (C).". The arrow should have an arrowhead on both ends as it symbolizes both the token request and token response. "The JavaScript app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs." I think this sentence was misleading, because as of today there is no way for the app to store tokens securely in the browser. Arrow E was not referenced in the text.
This just fixes a typo, but this text has more problems. I'm having trouble connecting this final sentence to the text that precedes it. I think that the point is that including a body on GET is unwise because it might cause explosions. A point about side effects needs far more exposition, especially since GET is defined to be free from overt side effects (safe, idempotent, and all that business). If this were just another statement and the "As a result" is dropped, that's different.
Barg, I think that's a copy/paste error, will fix. thx.
Considerations for new method should mention that the target URI has to be absolute. from URL
+1, thanks for filing!
We currently say: Isn't that sufficiently clear?
It wasn't clear to me because I didn't read the whole doc when I was searching for this information.
It's weird to say this because a URI is always in absolute form (part of what makes it Uniform). Only a reference can be relative, like within the request-target of 1.1 (absolute-path) or anything called a URI-reference. I think what you want to add is a reminder that new method extensions cannot use the host:port or asterisk forms of request target. Note that this only requires a request target in absolute form if the scheme or host:port are necessary to define the target, which they are for CONNECT-UDP.
Thanks NAME - all the proposed changes look like definite improvements. Thanks I need more coffee today.
In HTTP, there are a number of restrictions on what characters are allowed in a path, headers, etc. I don't see any text restricting track names and track namespaces, but the examples are all ASCII, implying the namespace and name are not intended to be completely opaque and are instead intended to be human readable. There's nothing in the spec that prohibits them being treated as opaque identifiers, but I'm unclear if that's the intent and I think it'd be good to explicitly say what we intend.
Most of the restrictions in the HTTP world are derivative of the restrictions in URIs: see RFC 3986, sections 2 and 3. I'd suggest we adopt those limitations and the percent encoding method from HTTP. That allows folks to use a well-known set of methods and aligns with the idea that we might have one or more URI schemes in the MoQ protocol space.
I believe we currently don't have a way to put a track name or a track namespace into a URL, so I don't think those restrictions apply.
I agree that they don't apply now, but if we adopt them it will simplify the set we have to deal with (since we will have the same set as other parts of the protocol). I suspect people will want the namespaces to be easy to generate from FQDNs (which are also the authority part of HTTP URIs), as an example.
IMO a track name should be human readable. Otherwise we should use numeric IDs instead, like most containers. I also think the track namespace should be human readable since it will likely be exposed to the user. Currently you need a URL and track namespace to configure a player/broadcaster. It will be quite common to combine both into a single URL (ex. like my relay) so it would be nice if track namespaces could be encoded into URLs.
Maybe we should ask the flip side: is there a use-case that won't work if track names are utf-8?
Moq transport must not define the interpretation. At the moqt transport layer track name and track namespace are set of octets and relay perform fast match where needed. How things from application domain gets mapped and gets setup with Relay is out of scope of MoQ Transport.