jiebi/CodeConvo huggingface dataset:
Code change:
Recommended HTTP status code: <del> 2.3.32. </del> <ins> 2.3.28. </ins> Name: proxy_internal_error

Related discussion:
text: While I can understand the appeal for providing 'informational' statuses, any suggestion beyond a level of is probably too normative, and unsupported by the underlying specifications and best practices.
NAME the context here is a CDN or other reverse proxy reporting back errors in HTTP response headers, for debugging. There are no requirements around sending them (and senders are cautioned against leaking information that could aid an attacker). So, at one end a Boolean doesn't really help, and at the other end, the full list of errors by any one library (or all of them) is impractical. The list of alerts from NAME seems promising, and I note that we already have , whose value can be any TLS Alert string. However, That's intended to convey alerts received (and perhaps we should communicate that more clearly). The desired semantics here are that the problem indicated by the alert is generated in the client itself, not received by it. That leads me to believe that there are two viable paths forward: Rearrange the errors so that they mirror the alerts above (leaving 's semantic as stated above); e.g., we'd have , , and so forth Reduce everything into two errors, and or similar. Both would carry the TLS Alert value as an additional payload item. I think the difference is mostly stylistic, so NAME and I can figure that out. The bigger question is whether this is the right set of errors to focus upon.
But I think this is missing an important detail: from the perspective of a client, the only stable output is the boolean. For example, OpenSSL's reporting of errors is symptomatic of deeper flaws within its certificate verification; fixing those errors necessarily means some existing errors can't effectively be reported. This is covered at some length in . Ultimately, the set of errors that are relevant are, to an extent, subject to local policy: it's rare for certificate validators to think of errors in the ontology laid out by the TLS layer. Typically, a client just does a "best guess" (or just maps straight to ) when trying to map to the TLS layer, in part so it doesn't disclose extra information. This is certainly true when you think about local policy, such as limits on validity or the requirement of associated metadata, potentially delivered over TLS, such as Certificate Transparency or OCSP Must-Staple.
Code change:
Recommended HTTP status code: <del> 2.3.32. </del> <ins> 2.3.28. </ins> Name: proxy_internal_error

Related discussion:
text: I think the core question is whether you expect the client and the proxy to be in the same management domain. If they aren't, and the ED seems to be oriented around this scenario (where server and proxy are likely same administrative domain, but proxy and client aren't), then it seems better served as an opaque diagnostic string. As RFC 4158 calls out, beyond the 'boolean' is really just an administrative/diagnostic capability, not something meant to be semantically rich, meaningful, or stable, and certainly not to allow next-hop policy decision making.
Just to be clear - the user agent isn't involved in this at all, beyond receiving the header so as to make it available to someone diagnosing a problem (Likely someone from the origin, from the CDN/reverse proxy operator, and/or a help desk talking to an end user). What I think I hear you saying is that we should define a generic error and allow implementations to convey textual detail in it. Does that make sense? I also still see some value in distinguishing a TLS alert received from the origin by the proxy (in its role as TLS client) from this case (a problem it encounters as a TLS client).
Yes. This matches with Criterion 2 of URL and the dual mode trade-off in URL , which perhaps more clearly highlights the local policy aspect ("Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information"). 100% agreed here. I was only commenting to the extent at which the proxy validates the peer certificate independent of the TLS layer framing. Perhaps poorly stated, but my comment in URL was trying to capture that Option 2 from URL () would likely just reduce to a boolean anyways, in a well-behaved TLS client.
Code change:
Additional considerations can be found in OWASP_SSRF. <del> 6.2. </del> <ins> 8.2. </ins> When defining ecosystem-specific rules for the verification of the public key, as outlined in issuer-signed-jwt-verification-key-

Related discussion:
text: Add general SD-JWT VC Type Metadata framework based on NAME work: URL See preview here: URL
Yep, good point. I18N is definitely needed although I'm not too sure about name/description since those are intended for developers only, not for end-users. I'll create a ticket to consider I18N, and also discuss whether this is needed for dev-only fields. I18N is definitely something we should add to metadata but needed some PR to start with first.
We have 3 approvals and no new comments coming in after 2 weeks. I propose to merge this PR NAME NAME . PR was created 1 month ago.
We should define more clearly what a credential type (identified by the claim) actually means. The current description is a bit handwavy and that may be a sign that we have not yet defined the concept well. I think that there is a set of metadata usually associated with each SD-JWT VC type, for example Display information for the whole credential A schema for the JSON structure (may or may not be defined in JSON schema) Information about the claims, including Display information Type information Status information (self-attested vs. verified etc.) Maybe: What kind of binding is supported/usually used for this credential type Maybe: What issuers are allowed to issue this credential type Such metadata would help Wallets (e.g., for displaying the credential to the user) and Verifiers (e.g., for determining the status of claims). It would also help developers of Verifiers, as they would get structured information about the credential they can expect. The need for such metadata has been discussed in Issue and similar approaches have shown up in . The metadata may or may not be embedded into the credential itself, or provided externally. Assuming we allow for registered values (e.g., ), this metadata could go into the registry. It could also be distributed manually. But it can also be made discoverable, e.g., by providing it at a .well-known URI derived from the URL in . Here is a completely made-up example of what this metadata could look like: Important: This mechanism will not be format-agnostic, but defined only for SD-JWT VC for now.
Code change:
Additional considerations can be found in OWASP_SSRF. <del> 6.2. </del> <ins> 8.2. </ins> When defining ecosystem-specific rules for the verification of the public key, as outlined in issuer-signed-jwt-verification-key-

Related discussion:
text: There are overlaps with mechanisms defined in HAIP, for example, and part of this issue here is to figure out what data should go where and to avoid duplications by getting the concept right. I think that the element defined for the credential issuer metadata in could be replaced by just a identifier (the metadata could be discovered from there, or retrieved from the registry).
Interesting point, I have the following approach to satisfy the requirement of having the credential metadata along with a credential: using openid federation a trust chain is needed to attests the cryptographic keys of the issuer to verify the credential. Within the trust chain the openidcredentialissuer metadata is provided. in the openidcredentialissuer metadata there are the display information for all the credential types. Then, using this approach, the credential doesn't need any metadata. Fed trust chain can be made available in a static form, within the credential jws/MSO headers Let's see other points: I would not use , because its value seems more close to the concept of issuance type. I would say set(, ). Also the name may semantically collide with all about status lists It would be up to the trust model and the credential metadata or trust marks or attestations. We cannot allow an italian PID provider to issue a Polish PID, then the domestic italian credential identifier must be linked with one or more italian credential issuers. This information must be made available according to the infrastructure of trust, where the issued credentials are not involved yet. During a discovery phase the user/holder knows which are the credential issuers, which credential types they offers to users. Generally this is made available in the openidcredential_metadata and must be granted by an accreditation body. That's why I mentioned trusted lists or federation trust marks or X.509 custom extentions (for strong stomachs) or federation metadata policy. Without openid federation I would have to find a solution and the credential metadata sounds resonable but I use federation and this requirement is already satisfied. Another point of interest is that the credential metadata should be issued by credential issuer and bound to the credential. I would change this sentence we have in the current text: because the metadata should be issued by credential issuers and be tamper proof, otherwise a bogus implementation would use a valid credential with a fake presentation of the claims that may swaps some value and change the interpretation of the data to a verifier.
Code change:
Additional considerations can be found in OWASP_SSRF. <del> 6.2. </del> <ins> 8.2. </ins> When defining ecosystem-specific rules for the verification of the public key, as outlined in issuer-signed-jwt-verification-key-

Related discussion:
text: Let's imagine that Giuseppe Marco would be swapped to Marco Giuseppe and pass through a supervised verifier as Marco, while the credential is still valid and verified
I like the idea to define schema and display information in the context of the credential definition (in contrast to issuance protocol) as I believe this information should be consistent across issuers and needs to be available for verifier developers. I also believe some information could be useful at the level of individual credentials for visual customization in the wallet.
we may add: type of binding of the vc ,e.g. key-binding, claim-based-binding, none vct could be either URL linking to the resource directly or an identifier that links to e.g. an (ISO) specification to get the credential metdata IANA registry is probably not a good option versioning of the metadata protection against change e.g. put a hash of metadata in the vc It might be worth to consider reducing the credential format specific Issuer metadata defined in OpenID4VCI and define that in a credential format specific credential metadata resource: However, there will remain issuer-specific things e.g. cryptographic support that should stay in the Issuer Metadata. These would need to be defined in SD-JWT-VC.
Using the VC type metadata, one could also include an ecosystem-specific parameter that contains a that allows you to map to any data model one want. It would also allow automatic fetching and executing the transformation algorithm quite easily.
I prepared a first draft for the SD-JWT VC metadata. I wrote this as a separate draft for working on it, but of course we can consider integrating this into SD-JWT VC — whatever works best. I'm looking forward to your feedback. URL
NAME I like the document and think it's a great start. I think there's a lot more to do around JSON Schema, similar to the work we've put into . I'm happy to help here. Similarly, the display reminds me of , which could be a standalone thing. Perhaps the types document should be transformed to a 'hub' document?
For all these "human readable strings", please make sure to have an i18n story, and ideally reference PRECIS, or DisplayStrings, etc .
Code change:
The HEADERS frame changes the connection state as described in FieldBlock. <del> The HEADERS frame can include padding.  Padding fields and flags are identical to those defined for DATA.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> The total number of padding octets is determined by the value of the Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </ins> 6.3.

Related discussion:
text: The old text stated padding things were identical to DATA frames. That might not be entirely true. So just spell out the requirements expicitly.
I just realised RFC 7540 was always this way, but it doesn't seem right to me. The DATA frame definition includes normative requirements on sender and receiver using the field. I presume the HEADERS frame is supposed the treat padding the same but it isn't written down. edit: plus PUSH_PROMISE
Ah, it's stated in a separate paragraph at the end of each frame definition section. That's annoying but I guess its fine.
Yeah, so the short answer there is that they behave differently in some ways (at least with respect to flow control). If you think there’s a better way to structure the section I think you’re welcome to take a crack at it.
I didn't actually make the leap to flow control, that makes me more inclined to avoid the cross reference to DATA frames. I made to just make everything explicit at the cost of a few more lines of text.
Code change:
1.1. <del> In the so-called Three-Party-Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </del> <ins> In the so-called Issuer-Holder-Verifier Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </ins> cryptographically signed statements about a Subject, typically the Holder.

Related discussion:
text: Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm
Code change:
that it serves resources that require authentication.  This document proposes a new non-probeable cryptographic authentication scheme. <ins> Unprompted Authentication serves use cases in which a site wants to offer a service or capability only to "those who know" while all others are given no indication the service or capability exists.  The conceptual model is that of a "speakeasy".  "Knowing" is via an externally-defined mechanism by which keys are distributed.  For example, a company might offer remote employee access to company services directly via its website using their employee credentials, or offer access to limited special capabilities for specific employees, while making discovering (probing for) such capabilities difficult.  Members of less well-defined communities might use more ephemeral keys to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by having that entity metering the availability of keys temporally or geographically).  Unprompted Authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </ins> There are scenarios where servers may want to expose the fact that authentication is required for access to specific resources.  This is left for future work.

Related discussion:
text: For example, a company might offer remote employee access to company services directly via its website using their employee ID, or offer access to limited special capabilities for specific employees, while making discovering (probing for) such capabilities difficult. Members of less well-defined communities might more ephemeral identifiers to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by that entity metering the availability of user identifiers temporally or geographically). Unprompted authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users.
"security by obscurity", yes?
Code change:
3.1. <del> Lists are arrays of items (item) with one or more members.  Members </del> <ins> Lists are arrays of items (item) with zero or more members.  Members </ins> can also be an "inner list", itself an array of items. The ABNF for lists in HTTP/1 headers is:

Related discussion:
text: This modifies parsing to consider empty or not-present header fields as empty containers; serialisation omits them from output.
The SH syntax does not directly allow empty field values, such as defined for Accept, although this might be allowed by field definitions like MyField = [ sh-list ] Likewise, the list types do not allow for empty lists. sh-list = list-member *( OWS "," OWS list-member ) list-member = sh-item I think this is a very odd choice for a generic syntax because the empty set is often given semantic meaning in generic communication. It's hard to do math without zero. If this is intended, the rationale should be explained in the spec, and there should be some discussion with examples about defining fields as an optional value.
FWIW, even if empty lists may be problematic top-level, the situation is different when they are nested...
ietf104 - interest in the room in supporting empty (perhaps null?) syntax
I agree this is something important. It may be used to mean "I know I must pass the info but I don't know the info", which is different from "I don't care about the protocol" or passing a dummy value just to fill the hole.
In the original base material of header definitions, empty values were generally just not sent at all. Having a specific Null value may or not make sense, not sure.
I personally like the distinction between "known to be empty" and "not presented either because I don't know or because it's empty". Some semantics might explicitly require the presence of some fields which we would enforce by the protocol. This doesn't mean they can't be empty, they must be present, for example, to make sure they weren't dropped in the middle. For example, "Connection: foo" gets rid of the field, not just the value. Just my two cents, Willy
Do we have any RFC'ed headers where there is a difference between a non-present and an empty header ?
There's an accept-something if I remember well. Also I've been using "Host:" in many occasions with HTTP/1.1 requests when I didn't know the host name and this tends to work where no Host field fails ;-) Willy
I'm not against a '?N' null token (along the lines of true/false), but I have a hard time thinking of a use for it.
Code change:
3.1. <del> Lists are arrays of items (item) with one or more members.  Members </del> <ins> Lists are arrays of items (item) with zero or more members.  Members </ins> can also be an "inner list", itself an array of items. The ABNF for lists in HTTP/1 headers is:

Related discussion:
text: URL
Wouldn't an empty list be equivalent to an empty value, thus we don't need a new syntax?
Putting an empty list where for instance an integer is expected, just to say that there will be none, sounds counter-intuitive to me.
On Fri, Apr 05, 2019 at 01:37:11AM -0700, Julian Reschke wrote: Indeed, probably.
On Fri, Apr 05, 2019 at 03:11:00AM -0700, Poul-Henning Kamp wrote: Agreed in general. My point was that sometimes specs use "MUST send" when the sender doesn't know, resulting in stupid values appearing. That's exactly what led a number of agents to place a content-length with stupid values (0 or huge ones) with the CONNECT method a long time ago. An empty value where an integer is needed by the application is more of an application-level error than a protocol-level one in my opinion : it's up to the application to decide how to recover from this missing piece of information (is it really needed to process the request or not). For me it can mean "don't care", "don't know" or "not representable". After all floats support "NaN" for the same reason :-) Willy
If there is a "MUST send" requirement, there must also be something available in the same spec that can be sent ?
There is not, and never has been, an interop problem with sending empty field values. They are a list value of zero items or a string item of zero length. Accept and Host, respectively.
NAME how do you know that?
Because if a recipient drops an empty Host field the request will be rejected with 400. There have been no reports of such breakage in 25 years. It isn’t even a likely scenario given how message fields are parsed and reproduced.
If a recipient doesn't drop an empty host header, the request will still be rejected with 400, surely? Regardless, I'd note that many headers address this situation with a reserved value like . Is there value in standardising on one such value for future headers?
Code change:
3.1. <del> Lists are arrays of items (item) with one or more members.  Members </del> <ins> Lists are arrays of items (item) with zero or more members.  Members </ins> can also be an "inner list", itself an array of items. The ABNF for lists in HTTP/1 headers is:

Related discussion:
text: I'm not convinced, but I'd note that we also have many headers that use to denote "all"; it seems to me that if we're going to do null, we should do that too (but again, I'm not convinced this is adding value).
On Mon, Apr 08, 2019 at 05:16:41PM -0700, Mark Nottingham wrote: It depends on the header field that was empty ;-) I've used the empty Host header field quite a bit (even in health check requests). My observation has been that while HTTP/1.1 without Host naturally causes a 400, HTTP/1.1 with empty Host is often processed similar to HTTP/1.0 without Host or as 1.1 with an unknown Host. I'd say "why not", but it's useful to consider lists and the iterative processing that can happen, removing one item at a time. Having to place a specific value to denote emptiness would require specific processing (i.e. check for emptiness after removing any item just for the sake of replacing it with the special value). By the way, speaking about lists makes me think we may complicate interop when a header field appears multiple times. For example if we have this in a request : List: a,b,c,d Foo: bar List: e,f,g,h It's not unreasonable to think that some simplified implementations may replace the first occurrence of List with "none" after processing it, leading to this : List: none Foo: bar List: e,f,g,h Or possibly this : List: none Foo: bar List: none Which may be processed as "List: none,e,f,g,h" or "List: none,none" respectively. Just my two cents, Willy
Willy, I think that would be clearly broken, and we should be able to catch it with tests. I think we're talking about all of the container types here (dict, list, list of lists, parameterised lists), correct? Julian, you gave as an example. Given that the behaviour recommended is exactly the same as if the header was missing, that's not very compelling. Besides the potential stripping issue (I have heard of implementations that strip empty headers, but don't have details on hand), some header libraries may not make a distinction between missing and empty headers.