jiebi/CodeConvo huggingface dataset:
Code change:
Verify the certificate chain established by the node certificate embedded in the receipt and the fixed service certificate in the <del> TS parameters (see parameters) using the Issued At time from "sign_protected" to verify the validity periods of the certificates.  The chain MUST enable the use of the public key in the receipt certificate for signature verification with the </del> <ins> TS parameters (see parameters) using the Issued At time from the protected header of the Receipt to verify the validity periods of the certificates.  The chain MUST enable the use of the public key in the receipt certificate for signature verification with the </ins> Signature Algorithm of the TS parameters. Verify that "signature" is a valid signature value of the root

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
MUST be an "integrity metadata" string as defined in Section document-integrity. <del> 6.4.2. </del> <ins> 6.3.2. </ins> <del> A Consumer MAY use a registry to retrieve Type Metadata for a type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </del> <ins> A Consumer MAY use a registry to retrieve Type Metadata for a SD-JWT VC type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </ins> The registry MUST provide the Type Metadata in the same format as described in type-metadata-format. <del> 6.4.3. </del> <ins> 6.3.3. </ins> Ecosystems MAY define additional methods for retrieving Type Metadata.  For example, a standardization body or a community MAY

Related discussion:
text: Two approvals, merging now.
The text currently says: It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because is the best indicator but in Section 5 only described as RECOMMENDED. Proposal is that the Issuer may chose this and that the presence of in SD-JWT VC indicates jwt-vc metadata.
This is from HAIP: By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example? Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where has to be a URI. For that reason, SD-JWT VC says that the value needs to be encoded using the dns URI scheme. I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved. But I don't think is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer ( value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of with the presence of well-known if this is what you suggested. Furthermore, I believe your specific use cases is already supported by: using an HTTPS URI for the value hosting a well-known for that URI including a x5c header with a URI SAN entry that matches the value
I don't think using to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above.
Code change:
MUST be an "integrity metadata" string as defined in Section document-integrity. <del> 6.4.2. </del> <ins> 6.3.2. </ins> <del> A Consumer MAY use a registry to retrieve Type Metadata for a type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </del> <ins> A Consumer MAY use a registry to retrieve Type Metadata for a SD-JWT VC type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </ins> The registry MUST provide the Type Metadata in the same format as described in type-metadata-format. <del> 6.4.3. </del> <ins> 6.3.3. </ins> Ecosystems MAY define additional methods for retrieving Type Metadata.  For example, a standardization body or a community MAY

Related discussion:
text: Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?
using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.
I'm supportive of changing value requirements for the following reasons: using could be a bit misleading using to match against the SAN DNS value is error prone (some devs might forget to do and instead do ) and perhaps misleading if does not exist (although the domain exists). Perhaps an edge case but it might have security implications.
to chage the requirement to be not a URI but a string for cases when is a DNS SAN value? the point of in HAIP was that the issuer can use the same value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwtvcissuer with or without openid federation) or x509. so I am supportive of keeping a URI in sd-jwt vc, but change the scheme to as opposed to regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing is low, and the verifier supporting x509, would have to extract dns name from as part of validations steps, so I see your points, but still think the the benefits of the same with different key resolution mechanisms is strong.
I support this, see my reasoning here: URL
NAME and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.
NAME said she might have some suggested text or a PR along those lines
NAME I'm going to work on this tomorrow (hopefully) so if you have anything that might help in that effort, please comment or post it or whatever works.
Code change:
Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn <del> Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: URL
I was wondering if there might be a mistake in the encoding of the address given in example 4: The documentation says: I assume this should be ? It looks like the claims where added to the list on error and there is a missing hash. I would expect to see some additional disclosure elements for postal_code, ... (each with a nonce) similar to instead.
Thanks for catching that! There is definitely a mistake in Example 4a. But it looks like the problem has to do with decoy digests in that example. The decoys listed at URL got pulled from the wrong place and so don't match up with the other example content, which includes the address claim Disclosure you've pointed. That all makes parts of that Example 4a problematic and hard to follow. I think it'd be best addressed by not including decoys in Example 4a. This is related: URL FWIW
PR aims to fix this. A preview from that PR of that example: URL and specifically the Disclosure for address: URL
Thanks for the quick response! That looks much better. I was expecting the address to be passed in a way that allows the selective disclosure of single items (e.g., only the post code). Maybe you can add an additional comment which of the three options in 5.7 every example uses (here 5.7.1). To me, having three options in 5.7 makes it unnecessarily complicated. and 5.7.3 are basically the same when you would allow having non-selectively disclosable items in this as well. If that would be the case, this could probably also handle all cases 5.7.2 would be used for.
Thanks for reporting this and NAME thanks for the quick fix! NAME The options in 5.7 are meant to show what is possible with SD-JWT and are not meant to restrict or define how can be encoded. It is up to the issuer to decide for each claim whether it should be SD or not. Options 1-3 just show some of the possible results. I'm not sure I'm following what you mean by "having non-selectively disclosable items in this as well". Could you give an example?
Code change:
Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn <del> Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: I created this PR to ensure that our wording around the options is clear in that the options are non-normative and not exhaustive: URL
I was wondering, if 5.7.1 would allow to have non-selectively disclosable items in the address claim: This single definition could then cover all use cases of 5.7.1,5.7.2, and 5.7.3. But i see what you are up to (thanks for ). You do want to leave a maximum flexibility. However, i am a bit concerned of "creative" uses of what is technically possible and how to make sure to be able to parse/process all possible combinations in the openid4vp context.
Yes, this mixture is possible within the current specification. With the algorithm defined in Section 6.3 there is no need (for the Holder) to be aware of all possible combinations. (In other words, such assumptions should never be hard coded.) It is just the Issuer that has to make a decision on which pattern to use.
Sure, this should never be hard coded. However you need e.g., to come up with a user friendly way of displaying that kind of information in a wallet context. It is a challenge to find an intuitive/understandable way to inform the user which information will or can be disclosed and so on. But this is becoming way to off-topic ;) Thanks for your quick response!
URL merged
I don't know why but I think we should have more examples, but not going to go against these changes.
Code change:
[1] #example-1 [2] #example-1 <ins> [3] #enveloping </ins>

Related discussion:
text: update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative
Code change:
7. <del> TBD: Holder provided nonce via </del> <ins> The Privacy Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following privacy considerations need to be taken into account when using SD-JWT VCs. </ins> <del> . </del> <ins> 7.1. The Privacy Considerations in Section 10.5 of I-D.ietf-oauth- selective-disclosure-jwt apply especially to the claim. 7.2. Issuers and Holders have to be aware that while this specification supports selective disclosure of claims of a given SD-JWT VC, the claim is not selectively disclosable.  In certain situations this could lead to unwanted leakage of additional context information. In general, Issuers are advised to choose values following data minimization principles.  For example, government Issuers issuing an SD-JWT VC to their citizens to enable them to prove their age, have to avoid putting information into the value that allows third-parties to infer additional personal information about the Holder, e.g., country of residency, citizenship etc.  A better approach is to have more generalized types, for example an age-proof SD-JWT VC type. Additionally, Holders have to be informed that besides the actual requested claims what information is shared with the Verifier. 7.3. A malicious Issuer can choose the Issuer identifier of the SD-JWT VC to enable tracking the usage behavior of the Holder if the Issuer identifier is Holder-specific and if the resolution of the key material to verify the Issuer-signed JWT requires the Verifier to phone home to the Issuer. For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., and host the JWT Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD-JWT VC is verified.  This would allow the malicious Issuer to keep track where and how oftehn the SD-JWT VC was used. Verifiers are advised to establish trust in an SD-JWT VC by pining specific Issuer identifiers and should monitor suspicious behaviour such as frequently rotating Issuer identifiers.  If such behaviour was detected, Verifiers are advised to reject SD-JWT VCs issued by such Issuers. Holders are advised to reject SD-JWT VCs if they contain easiliy correlateable information in the Issuer identifier. </ins> 8.

Related discussion:
text: We should add something to the privacy considerations section that explains the risk of leaking more context info from the type in certain use cases.
Code change:
2.1. <del> All HTTP/1.1 messages consist of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format RFC5322: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. An HTTP message can be either a request from client to server or a response from server to client.  Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (message.body). </del> <ins> An HTTP/1.1 message consists of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format RFC5322: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. A message can be either a request from client to server or a response from server to client.  Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (message.body). </ins> In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats.

Related discussion:
text: As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.
Code change:
status code often leads to clients retrying requests, which could result in increased load. <ins> 6.4. In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  This leads to potential ambiguity about the status of requests and could lead to inconsistent treatment (see be-consistent).  Implementations MUST either ensure that any early data that is delivered late is either discarded or consistently identified and processed. </ins> 7. This document registers the "Early-Data" header field in the "Message

Related discussion:
text: The best and easiest plan is to discard, but we know that throwing out perfectly good packets can have bad effects on performance. It sends a bad signal to a congestion controller for instance. So we need to say either discard, or ensure that the data is properly attributed and consistently processed.
I think you covered it all this way. +1.
The conclusion in the draft is that early data is relatively "safe" (for some definition of the term, see the draft for details) if the handshake is complete. Early data in a transport that provides ordered delivery will always arrive before the handshake completes. But this is not the case in QUIC, or anything like DTLS. We should offer some advice for these situations. From martinthomson/http-replay
But can this really happen ? I mean, my understanding is that the handshake happens in response to a Hello message which also conveys early data. Can we have early data outside of a hello message, or may we receive a handshake response before a hello message ?
With reordering of packets in QUIC, you can get a packet that was sent before the handshake completes after the handshake completes. The order of sending might be "ClientHello, 0-RTT1, 0-RTT2, Client Finished", but the server can get "ClientHello, 0-RTT2, Client Finished, 0-RTT1". Early data is sent in separate packets (this is a hard rule right now, but we might change the format so that the packets can be sent together in future). This is unlike TCP fast open where you only get to send the "early data" in the SYN segment. You can send an awful lot of early data if you want.
OK thanks for the explanation. I tend to think that such behaviours are out of the current scope of the draft but will fall into it as QUIC progresses. Maybe all of this can be summarized (for now) as "In case a TLS implementation supports receiving early data after the handshake completes, such early data has to be silently discarded". That covers this case for QUIC and any possible TLS implementation specificity or even bug.
I think that we might add "... discarded unless the data can be unambiguously identified as being early data" or something like that.
Code change:
status code often leads to clients retrying requests, which could result in increased load. <ins> 6.4. In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  This leads to potential ambiguity about the status of requests and could lead to inconsistent treatment (see be-consistent).  Implementations MUST either ensure that any early data that is delivered late is either discarded or consistently identified and processed. </ins> 7. This document registers the "Early-Data" header field in the "Message

Related discussion:
text: After all, it's not replayed data if the handshake completes, so I don't want to prohibit its use. The main problem is that it's hard to properly identify and handle. FWIW, we debated this for our DTLS 1.3 implementation and chose to discard. That is the easiest answer.
I'd still be tempted to simply discard for now, just to avoid the problems of confusing the client with an out-of-order handshake that may make it think the "late" early data were lost while in the end they are considered. I'd rather avoid a client sending a request again as regular data and seeing the server concatenate it with the late arrived early data for example. I really think it's something we can improve later as the out-of-order use cases become more obvious. It would also offer us a safety belt allowing more fancy stuff in QUIC, otherwise we could end up saying "nah don't do this or that, it could cause trouble with early data". The rule might then be relaxed. It will not affect TCP-based implementations anyway.