jiebi/CodeConvo huggingface dataset:
alternative to based on NAME 's comment "I can't help but wonder if it'd make sense to have the spec be only about SD-JWT VCs and treat the plain JWT VC as just a special case of an SD-JWT with no selectively disclosable claims." no changes to the basic structure. simple clarifications what to do when there are no selectively disclosable claims ie no claim and no Disclosures. Might need some more details but this is how it might look like. (cc NAME NAME linked to rendered preview
Generally, I really like this approach! Some examples could be useful for key binding with JWT (no disclosures)
I'd expect the typ for both to have +jwt if that were really the case. There is another draft up for multiple suffixes. URL Is it simple enough to support now?
should this be titled ? I think this should be changed as well as the title before merging to make sure we are calling out that this covering SD-JWTs and JWTs
Yes. Will make a change once we have a decision whether PR or this one is the way to go…
What is the position of this specification? From my understanding it defines a VC with JWT claims it defines a profile for the JWT claims it defines a profile for securing the VC There's an open discussion between the sd-jwt and JWS protection. Relevant discussion has been started URL - sd-jwt introduces an encoding that becomes incompatible with JWS in the limit where selective disclosure is not used. In other words, it introduces a first-order phase transition. Let's see how this topic resolves. IMO, the data model and securing mechanisms should support both sd-jwt and JWS.
I do like this approach, but I am a bit concerned that even in the 'no disclosures' case, we'll have the trailing tilde in the issuance and presentation (when no KB is present). A JWT is not a special case of an SD-JWT for this reason.
I agree with the concern.
IMHO keeping the trailing tilde is preferable as it keeps the model consistent.
from what I am sensing, there seems to be a lot of preference towards the approach in this PR over , partially because it is simpler and gives one credential format and not two (consolidation, yay!), with one major discussion point being a ~ after a JWT VC when it is issued.
a bit of the context... this trailing ~ is the result of the decision being taken in SD-JWT spec to better align the issuance and presentation formats, (URL does it, and it has not been merged yet). One option is to keep issuance and presentation formats separate in SD-JWT (as-is) so that there is no ~ when (SD-)JWT VC is issued. but that is not that clean from a pure SD-JWT processing perspective is I think the opinion of its authors (NAME NAME so the question is really what to do with a trailing ~ when there is no SD in SD-JWT based VC.
should be good to merge once NAME takes a look and approves
I'm ok with this direction. I personally don't like the trailing tilde but we can fix that in another PR. I'll open an issue in the repository.
Merging this PR since a lot of approvals and no objections.
approving but will create an issue to address trailing tilde.I approve this approach over as, the specification is much cleaner I expect implementations to be much cleaner I don't see confusion with trailing tilde, because typ is not jwt but sd-jwt most interop profiles will require SD support anywayI prefer URL since I find its description of what we're achieving more natural / less surprising. But I can live with this description as well, provided the distracting "with JSON Claims" language is removed.
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.
Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100.
The transparency service knows that animal products require certificates to be imported, and issues a challenge token that looks like this: iss: "https://transparency.example" aud: "https://transparency.example" iat: ${now} exp: ${now + 7 day} currenttreehead: ... (not all TS are trees) currentpolicyhash: ... (not all policies are stored in trees) entrynumber: 42 htscodes: [ 16056100 ] The holder starts registering signed statements, each is bound to the same "challenge token". The first signed statement covers a phytosanitary certificate for the sea cucumber processing facility. The regulatory requirements change. The second signed statement covers the (now required) export certificate for sea cucumbers. The transparency service would normally have rejected the second signed statement, but because of the context in the challenge token, the transparency service knows that the second signed statement is now actually required. The holder did not need to request a "new challenge token" when the regulatory changes happened, and the holder still had to prove possession of the public key bound to both certificates ( and these public keys are different ). I chose to make this context scenario about sea cucumbers, but it could easily have been about network capable hardware devices that need to comply with regulations specific to Radio Antennas and GPUs... In those cases there would be firmware certifications required, and compliance requirements might change inside the transaction window. This also solves the problem of forcing the issuer to commit to the registration policies as they exist at the time the "challenge token" is issued. The TS can reject registrations that are committing to stale policies, or accept registrations that are commiting to stale policies, because the TS will know which policies the issuer is committing to by checking the challenge token. In the case that proof of possession is not required, and there is no need to commit to policies, the challenge token can be omitted, and the registration can proceed exactly as it is specified today. OS ORIE STEELE Chief Technology Officer www.transmute.industries
adding SD-JWT claim Note: need to update the examples to include it once we agree this claim is needed (cc NAME )
We need to say in the checking algorithm that verifiers MUST check the alg and MUST only accept hash_algs they understand and deem secure.
information about the hash function should probably be included inside SD-JWT. Based on NAME 's comment to the PR URL
Yes, needed indeed. This and more details about hash formatting (how to transform inputs into byte arrays to be passed to the hash function).
The alternative is to use the same hash function as was used for the signature. This is done in OpenID Connect Core at URL in the definition (as well as in the definition. The language is:
You might want to use a different hash function to reduce the SD-JWT size (e.g., SHA-256 truncated to 128 bit), or decide on a stronger hash function with iteration to reduce the size of the salt (again, to minimize the size of the artefact). Bottom line, choosing the hash function independently might be useful.
As discussed in the call, if we allow different hashes to be used, we may want to make a recommendation that for simplicity an implementor may want to use the same hash algorithm to minimise implementation errors.
Assuming we're not going to use the trick that OpenID Connect uses to determine the hash algorithm implicitly, then I approve of this approach.
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.
Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class.
In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.
Sounds like a good idea to me.
from the editor's copy >7. "message/bhttp" Media Type The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. is this a typo and it should be >The message/bhttp media type ? Also defining this type at section 7 seems quite late. The first instance of is in examples in section 5, easily missed due to the similarity and prevalence of that is mentioned as a contrasting type. I think it would help a bit to talk about the bhttp type earlier. Probably in the introduction, just after you talk about the old type.
LGTM thank you
Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.