jiebi/CodeConvo huggingface dataset:
Code change:
When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure <del> that the response is a valid JWT Issuer Metadata configuration </del> <ins> that the response is a valid JWT VC Issuer Metadata configuration </ins> document before processing it. Additional considerations can be found in OWASP_SSRF.

Related discussion:
text: This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier.
Code change:
When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure <del> that the response is a valid JWT Issuer Metadata configuration </del> <ins> that the response is a valid JWT VC Issuer Metadata configuration </ins> document before processing it. Additional considerations can be found in OWASP_SSRF.

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:
When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure <del> that the response is a valid JWT Issuer Metadata configuration </del> <ins> that the response is a valid JWT VC Issuer Metadata configuration </ins> document before processing it. Additional considerations can be found in OWASP_SSRF.

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:
When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure <del> that the response is a valid JWT Issuer Metadata configuration </del> <ins> that the response is a valid JWT VC Issuer Metadata configuration </ins> document before processing it. Additional considerations can be found in OWASP_SSRF.

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:
When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure <del> that the response is a valid JWT Issuer Metadata configuration </del> <ins> that the response is a valid JWT VC Issuer Metadata configuration </ins> document before processing it. Additional considerations can be found in OWASP_SSRF.

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:
14.6. <ins> This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry IANA.OAuth.Params established by RFC8414. Metadata Name: status_list_aggregation_endpoint Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. Change Controller: IETF Reference: aggregation of this specification 14.7. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Related discussion:
text: yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change
Code change:
14.6. <ins> This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry IANA.OAuth.Params established by RFC8414. Metadata Name: status_list_aggregation_endpoint Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. Change Controller: IETF Reference: aggregation of this specification 14.7. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Related discussion:
text: Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.
Code change:
components are based on the Concise Signing and Encryption standard specified in RFC9052, which is used to sign released Statements about Artifacts and to build and maintain a Merkle tree that functions as <del> an append-only Registry for corresponding Signed Statements.  The format and verification process for Registry-based transparency receipts are described in I-D.birkholz-scitt-receipts. </del> <ins> an append-only Registry for corresponding Signed Statements. </ins> 1.1.

Related discussion:
text: As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM
Code change:
beneficial for a protocol to provide such an opportunity (e.g.  RTP/ QUIC -> RTP/UDP). <del> 7. </del> <ins> 8. </ins> This document makes no requests of IANA. <del> 8. </del> <ins> 9. </ins> As this document is intended to guide discussion and consensus, it introduces no security considerations of its own. <del> 9.  References </del> <ins> 10.  References </ins> <del> 9.1.  URIs </del> <ins> 10.1.  URIs </ins> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements <ins> [2] https://www.ietf.org/mailman/listinfo/moq </ins>

Related discussion:
text: This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.
Code change:
request: i.e., a response to a GET request, which contains a representation of the <del> resource identified by the request target (GET).  However, it is also possible to store redirects, negative results (e.g., </del> <ins> target resource (GET).  However, it is also possible to store redirects, negative results (e.g., </ins> ), incomplete results (e.g.,

Related discussion:
text: NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.
Code change:
the pushed response as a HttpResponse on a server-initiated stream that uses the promised stream identifier.  The server uses this stream to transmit an HTTP response, using the same sequence of <del> frames as defined in HttpFraming.  This stream becomes StreamStates after the initial HEADERS frame is sent. </del> <ins> frames as that defined in HttpFraming.  This stream becomes StreamStates after the initial HEADERS frame is sent. </ins> Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the

Related discussion:
text: CLoses .
: Does "the same sequence of frames as defined in " mean "the same sequence of frames as that defined in " or "the same sequence of frames, as defined in "? It appears to us that it means "URL that defined in ", but please advise. Original: The server uses this stream to transmit an HTTP response, using the same sequence of frames as defined in
It means "as that defined in Section 8.1".
Code change:
[8] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [9] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml <ins> [10] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml </ins>

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
initiated the Upgrade. The first HTTP/2.0 frame sent by the server is a SETTINGS.  Upon <del> receiving the 101 response, the client sents a SessionHeader, which </del> <ins> receiving the 101 response, the client sends a SessionHeader, which </ins> includes a SETTINGS frame. 2.3.

Related discussion:
text: Additionally, section 4.2.3 contains a lot of text that is similar to 4.2.2, but there may be a reason for that.
I'll try to remember to fix the content-length thing.
Code change:
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple. <ins> Applications that make use of content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header field in the request, the server is unable to include a signature that covers the request's content. </ins> 7.3. 7.3.1.

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
A "Digest" field using NOT RECOMMENDED digest-algorithms SHOULD NOT be used in signatures. <ins> Using signatures to protect the Digest of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </ins> 11.7. When used in trailers, the receiver gets the digest value after the

Related discussion:
text: adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256