jiebi/CodeConvo huggingface dataset:
Code change:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> 4.1. </del> <ins> 5.1. </ins> <del> A JWT Issuer Metadata configuration MUST be queried using an HTTP </del> <ins> A JWT VC Issuer Metadata configuration MUST be queried using an HTTP </ins> <del> request at the path defined in jwt-issuer-metadata. </del> <ins> request at the path defined in jwt-vc-issuer-metadata. </ins> The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to

Related discussion:
text: 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."
Code change:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> 4.1. </del> <ins> 5.1. </ins> <del> A JWT Issuer Metadata configuration MUST be queried using an HTTP </del> <ins> A JWT VC Issuer Metadata configuration MUST be queried using an HTTP </ins> <del> request at the path defined in jwt-issuer-metadata. </del> <ins> request at the path defined in jwt-vc-issuer-metadata. </ins> The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to

Related discussion:
text: 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.
Code change:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> 4.1. </del> <ins> 5.1. </ins> <del> A JWT Issuer Metadata configuration MUST be queried using an HTTP </del> <ins> A JWT VC Issuer Metadata configuration MUST be queried using an HTTP </ins> <del> request at the path defined in jwt-issuer-metadata. </del> <ins> request at the path defined in jwt-vc-issuer-metadata. </ins> The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to

Related discussion:
text: 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.
Code change:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> 4.1. </del> <ins> 5.1. </ins> <del> A JWT Issuer Metadata configuration MUST be queried using an HTTP </del> <ins> A JWT VC Issuer Metadata configuration MUST be queried using an HTTP </ins> <del> request at the path defined in jwt-issuer-metadata. </del> <ins> request at the path defined in jwt-vc-issuer-metadata. </ins> The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to

Related discussion:
text: 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.
Code change:
4.3. For transporting the SVC together with the SD-JWT from the issuer to <del> the holder, the SVC is BASE64URL encoded and appended to the SD-JWT </del> <ins> the holder, the SVC is base64ur-encoded and appended to the SD-JWT </ins> using as the separator.  For Example 1, the combined format looks as

Related discussion:
text: reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
Code change:
4.3. For transporting the SVC together with the SD-JWT from the issuer to <del> the holder, the SVC is BASE64URL encoded and appended to the SD-JWT </del> <ins> the holder, the SVC is base64ur-encoded and appended to the SD-JWT </ins> using as the separator.  For Example 1, the combined format looks as

Related discussion:
text: We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.
Code change:
authorization server MUST: ensure that the authorization code was issued to the authenticated <del> confidential or credentialed client, or if the client is public, ensure that the code was issued to "client_id" in the request, </del> <ins> confidential client, or if the client is public, ensure that the code was issued to "client_id" in the request, </ins> verify that the authorization code is valid,

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.
Code change:
inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with <del> third-party HTTP servers ought to conform to user agent requirements </del> <ins> third-party HTTP servers needs to conform to user agent requirements </ins> on the gateway's inbound connection. A

Related discussion:
text: This isn't a place for equivocation. This could have been MUST except that that isn't good to use here. I considered just "conforms to" as well. That would also work, but that is incompatible with "wishes to" and I was less confident in removing that. I could do "conforms to" with "gateway that interoperates with inbound HTTP servers", but that's a bigger change.
Code change:
SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) <del> draft-terbu-sd-jwt-vc-latest </del> <ins> draft-terbu-oauth-sd-jwt-vc-latest </ins> Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.

Related discussion:
text: Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.
Code change:
programs perform for a particular connection.  The same program might act as a client on some connections and a server on others. <ins> HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </ins> 3.4. HTTP is a stateless request/response protocol for exchanging

Related discussion:
text: The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'
Code change:
<del> tus - Resumable Uploads Protocol </del> <ins> Resumable Uploads for HTTP </ins> draft-ietf-httpbis-resumable-upload-latest Abstract

Related discussion:
text: Closes URL
I suspect a title like "HTTP Resumable Uploads" or "Resumable Uploads for HTTP" would be more clear -- not referring to HTTP will pull in readers looking for other things, and calling it a protocol reinforces that it's separate, when we're trying to make it an extension to an existing protocol.
Good idea to include HTTP in the title! I updated the PR.
Great suggestions, Lucas! Thank you very much!
LGTM, thanks for picking it the pen.
The title of the resumable uploads draft starts with "tus", which is a little weird as the inclusion is entirely unexplained. If the intent is to acknowledge something, might I suggest the Acknowledg[e]ments section.
Agreed. I think this helped during the "pitch period" as a differentiator for this proposal vs others. However, now its an adopted document the lone use of the term is odd. I'll prepare a PR that gives a nod back to the tus v1 spec that inspired this.
+1
I opened a PR for this: URL NAME Let me know if you had something different in mind.
Code change:
Announce Error codes <del> Unsubscribe Error codes </del> Track format numbers Message types

Related discussion:
text: This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.
Code change:
[2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/priorities <ins> [4] https://iana.org/assignments/http-priority [5] https://iana.org/assignments/http-priority </ins>

Related discussion:
text: Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.
Code change:
allowed to have, and restricting the length of time an upload resource can exist. <del> 17. </del> <ins> 18. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Related discussion:
text: splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!
Code change:
REQUIRED.  The protected resource's resource identifier, which is <del> a URL that uses the "https" scheme and has no fragment components. This is the location where ".well-known" RFC5785 resources containing information about the protected resource are published. Using these well-known resources is described in PRConfig. </del> <ins> a URL that uses the "https" scheme and has no query or fragment components.  Using these well-known resources is described in PRConfig. </ins> OPTIONAL.  JSON array containing a list of OAuth authorization

Related discussion:
text: As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.
Code change:
5.1. <del> The example HTTP/1.1 message in ex-request shows the content of a "message/http". </del> <ins> The example HTTP/1.1 message in ex-request shows the content in the "message/http" format. </ins> Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0a and 0x0d).  For simplicity and consistency, the content of

Related discussion:
text: 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