jiebi/CodeConvo huggingface dataset:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
I took a stab at another rewrite of Subscribe message which attempts to not use special group and object values. Also add support for multiple subscription flows that have been discussed. As this is a control message, we should be Ok to be elaborate in describing the subscriber needs. This leaves 0 as a special value for the StartObject and EndObject.
NAME updated the PR .. please let me know .. thanks
I like that this would move us away from stealing special values from obejct id / group id space.
This looks good NAME .. thanks for the update
As currently defined, you can SUBSCRIBE starting from the following points: The latest group and latest object An absolute group and latest object An absolute group and absolute object You cannot SUBSCRIBE to a. The latest group with an absolute object b. The latest group from the beginning c. The next group after latest, from the beginning I'd like to remove 2) (absolute group, latest object). If this group is in the past, then likely the group is complete and no new objects will come in that group, so it's equivalent to (absolute group + 1, object 0). If this group is in the future, then it's equivalent to (absolute group, object 0). If the group is current, it's equivalent to latest/latest. Does anyone have a use case that requires this mode? I'd also like to add b) (latest group, first object) and c) (next group, object 0). This can be done now with an extra round trip via TRACKSTATUSREQUEST, so perhaps this is an optimization we can tackle later.
It's currently ambiguous if or happens. When , then is not present but doesn't have a specified default. If then occurs, and if then occurs. The correct behavior is IMO since groups are intended to be sync points. +1 to removing .
And I don't think we should support without a good use-case. It's too racey for ABR and too delayed for initial playback. It's also barely an optimization since the alternative is making the TRACKSTATUSREQUEST, which primarily eats into time that would have been spent waiting for the next group to start anyway.
means you can only start at: b. The latest group from the beginning An absolute group and absolute object Everything else is accomplished with , forcing the subscriber to converts relative values to absolute.
I think we should eventually bring back Locations so the publisher can do this conversion too without an additional RTT, but the desire was to simplify start/end ranges.
FWIW, I thought/intended start_group=0 to correspond to b. Also +1 to removing case 2.
Thanks for summary. +1 to remove case 2 (abs/latest). I also thought we had b. today but we need case b so lets update to make it clear we have b (latest/0). I don't think we have a use case for a (latest/abs), +1 on remove. I originally was in favor of case c (next/0) but I have changed my mind for now. IF you need this, you just do case 1 (latest/latest) and toss out object until you get to the next group. If there was not enough bandwidth to do this, then there is probably not enough bandwidth for the next group when it arrives. If we get a bunch of code running and can show that (latest/latest) is not good enough and we really need (next/0), then I will change my mind but for now, I think we can live without (next/0). And +1 to point that TRACKSTATUSREQUEST solves most problems.
A +1 to all these points Regarding starting at the latest group at the beginning, this seems like the default starting use case for many players. Therefore per Luke's comment -
Fixed by
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
For . Here, I moved the text that covers the calculation of the dynamic header table size up into a new section. Then, I reworded the text to reduce the direct dependency on HTTP/2 and its settings. The emphasis is now on the using protocol setting a maximum, of which the HTTP/2 setting is just an example. Apologies for the diff, I'll try to split the move commit out to make it more readable.
OK, the first commit does the rewording, the second only moves text around.
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Feedback gathered from URL
Consider attempting better CDDL by applying URL We would like some time to discuss this draft at IETF 117: URL https://ietf-URL We've made several changes that were requested at 116. We provide a sample implementation demonstrating how to use RFC9162 tree algorithm with COSE Sign1 to create signed "inclusion" and "consistency" proofs. We updated the draft to support registration of other tree algorithms which can be specified in separate documents. If there are other changes folks would like to see, we are happy to try to get them in before the cut off date. Regards, OS ORIE STEELE Chief Technology Officer www.transmute.industries
This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier.
And not to forget, this well-known location also could work well with openid-federation. Moreover, any additional VC issuer metadata we will come across can be added to this endpoint. BTW: I think a dedicated issue would be the better place for this discussion.
I am actually in favor of . This mechanism is meant to be general enough to be used with not just a 'verifiable credential'. and I don't think anyone would think to use with ID Tokens and Access Tokens, UserInfo responses , etc. that are JWTs.
I understand your point NAME below my thoughts Why defining jwt-issuer for general purpose in a spec that's specialized for VC? Requirement: definition of a specs in IETF for general purpose JWT Issuer metadata (enabling client metadata, that today is only available in openid-federation...) I agree that jwt-vc-issuer semantically collides with credential-issuer, and we should not do collisions why we can't use .well-known/openid-federation? Federation entity discovery is required for the entities that builds trust chain according to the federation specs, nothing prevent to publish all the metadata of all thw "JWT-role" in a single metadata, that should not be signed if request (content-type) asks it in plain text I suggest to use to consolidate a unique way to publish all the metadata types and roles of an entity. coming back to the name change proposal. Why we use the term since the metadata contains also general capabilities not related to the issuance? in a more general purpose way, wouldn't it be a ? then the question: if that entity has more functionalities and roles, being at the same time a RP and a AS, how the metadata should be organized? We've resolved this issue in openid-federation, with the below schema, where a RP can be also a OP, AS, Client, credential-issuer and so on: URL
I'm a little embarrassed, but to be honest, I still don't understand the reasoning. "A stable issuer identifier" is represented by the claim, not by the URL of the well-known endpoint, isn't it? A possible reason for necessity of a well-known path I guess is "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path under the domain."
An example with concrete values would be "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path () under the domain ()." It might be beneficial to define as the ultimate fallback general-purpose option for locating the public key required to verify the JWT's signature (not as the sole rule for every VC to follow), especially when it is challenging to reach a consensus on a single method within a limited timeframe among the following. starting with Others However, maybe I'm still missing something, sorry.
The well-known endpoint is indeed also a stable identifier. But it depends on a certain well-known location, i.e. different well-known locations are different identifiers. I'm looking for a stable identifier for the issuer that works across .well-known locations and is not bound to a certain key. That's pretty simple with well-known locations as the iss value can be extended by several different .well-known locations, but the identifier is still the same, right? So for example, the issuer could use the jwt-issuer mechanism share keys and (at the same time) be part of an OpenID Federation as shown in the following: /.well-known/jwt-issuer /.well-known/openid-federation The same issuer's URL could also at the same time used in an external data structure at the verifier or at a trusted 3rd party. Effect: I can establish trust in a certain issuer/entity/server that works across different roles/perspectives. I hope that explains better.
this would allow an entity to use different keys to sign ID Tokens, VCs, access tokens, etc.
my question is how to specify different capabilities for different metadata protocols? this is an example in oidc federation URL here we're saying, this is the wallet provider metadata, where multiple metadata/roles cohexists in a single .well-known how jwt-issuer endpoint achieves this?
If the JWS header indicates that the JWT is a VC (e.g. ), the following paths also can work. (defined in OID4VCI) (proposed by this issue) I'd like to understand why the generic name is chosen. The generic name is subject to interpretation where authorization servers, relying parties and any JWT-issuing systems should provide to expose their metadata (at least or ) as the last resort.
What if one server behaves as both an authorization server and a credential issuer? Should the authorization server publish the same content at both and ? Should intermediate authorities and trust anchors of OIDC Federation also provide ? Such a conflict is what I'm (and ordinary server implementers will be) concerned about. The latest draft of "" defines and jwt-issuer metadata. If so, there is no reason to prevent adding the same metadata to OID4VCI as well. Basically, I believe the metadata should be added to OID4VCI regardless of the discussion about jwt-issuer.
Potentially fixed by
NAME raises an important question that we need to address, at least by giving guidance. I don't have a good answer to that at the moment. Besides that, I don't see a need to rename to .
NAME correct me if I'm wrong. I understand you prefer over , right? And whether the key data will be added to the is a different topic (that's how I read your last statement). Please conform.
We will need more discussions on that topic. Potentially at IETF 117. This means, we won't be able to resolve this issue for our individual draft 03.
We had a small discussion on this and I created a new issue so we can separate between the 2 discussions overlapping here (name of the endpoint and intended usage).
Regarding the path, I have been losing confidence in my own opinion. As an implementer who has implemented numerous OAuth/OIDC specifications and been leading development of Authlete that holds the most OpenID certifications in the world, my intuition told me "The path should be avoided due to possible conflicts with other specifications." However, I haven't received as much support for my opinion as I expected. For now, I will implement my OID4VCI implementation using the path. Please let me withdraw my opinion.
I agree the position of NAME while in the italian solution we're implementing openid-credential-issuer as metadata within the .well-known/openid-federation endpoint, according to OpenID Federation 1.0. This doesn't prevent to include also a jwt-issuer metadata type but there's the decision by our side to wait and the same time give evidence of our implementation to help the consolidation of the vc-jwt-issuer specs
NAME An off-topic question out of curiosity.
If an authorization server / OpenID provider and a credential issuer are hosted on the same server, the payload of the entity configuration published at of the server contains the following, right?
Hey NAME I'm sure that you meant The answer Is yes, even if we have used a snake case like here URL It's still an initial draft without an official release, several editorials and implementation compromises needs to be resolved but the most of the work Is there, feelfree to open issue for discussion here URL
To make progress with this. Are folks comfortable with renaming "JWT Issuer Metadata"? And if so, would folks be fine with "SD-JWT VC Issuer Metadata" or "VC Issuer Metadata"? I like "VC Issuer Metadata" better because it is more future looking. What do folks think? cc NAME NAME NAME NAME NAME After we agreed on a new name I'd ask NAME to update PR .
Agree that "jwt-issuer" is too general and am in favor of a renaming.
It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it
updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL
refers to a captive portal as a type of intermediary; we should make sure this aligns with the more recent CAPPORT drafts (IIRC current usage of that term is for the origin that the user is redirected to when captured; it's not an intermediary).
It is probably enough to strike "captive portal". "Interception proxy" will do, if "attacker" does not. The term was never something that RFC 7230 relied on and as you say the modern understanding of the term has evolved.