jiebi/CodeConvo huggingface dataset:
Code change:
For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., <del> 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 often the SD-JWT VC was used. </del> <ins> and host the JWT VC 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 often the SD-JWT VC was used. </ins> Verifiers are advised to establish trust in an SD-JWT VC by pinning specific Issuer identifiers and should monitor suspicious behaviour

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:
For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., <del> 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 often the SD-JWT VC was used. </del> <ins> and host the JWT VC 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 often the SD-JWT VC was used. </ins> Verifiers are advised to establish trust in an SD-JWT VC by pinning specific Issuer identifiers and should monitor suspicious behaviour

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:
For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., <del> 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 often the SD-JWT VC was used. </del> <ins> and host the JWT VC 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 often the SD-JWT VC was used. </ins> Verifiers are advised to establish trust in an SD-JWT VC by pinning specific Issuer identifiers and should monitor suspicious behaviour

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:
For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., <del> 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 often the SD-JWT VC was used. </del> <ins> and host the JWT VC 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 often the SD-JWT VC was used. </ins> Verifiers are advised to establish trust in an SD-JWT VC by pinning specific Issuer identifiers and should monitor suspicious behaviour

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:
3.1. The urgency parameter ("u") takes an integer between 0 and 7, in <del> descending order of priority. </del> <ins> descending order of priority.  This range provides sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. </ins> The value is encoded as an sh-integer.  The default value is 1.

Related discussion:
text: We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...
Code change:
The "ttl" value is optional and defaults to 1209600 (14 days). <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id"

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
9.3.2. <del> The "Cookie Attribute Registry" will be updated with the </del> <ins> The "Cookie Attribute Registry" should be created with the </ins> registrations below: 10.  References

Related discussion:
text: The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by
Code change:
This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track.  In <del> this example the namesapce is absent, which infers that each track must inherit the namespace of the catalog. </del> <ins> this example the namespace is absent, which infers that each track must inherit the namespace of the catalog.  Additionally this example shows the presence of the supportsDeltaUpdates flag. </ins> 3.4.3.

Related discussion:
text: by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4. </del> <ins> 5. </ins> <del> 4.1. </del> <ins> 5.1. </ins> Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a

Related discussion:
text: Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.
Code change:
If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the <del> redirect URI using the "application/x-www-form-urlencoded" format, per application-x-www-form-urlencoded: </del> <ins> redirect URI using the query string serialization described by query- string-serialization, unless specified otherwise by an extension: </ins> REQUIRED.  The authorization code is generated by the authorization server and opaque to the client.  The authorization

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
allow for more than one level of complexity of audit procedures (potentially depending on criticality) <del> 3.6. </del> <ins> 3.7. </ins> Some software is deployed on systems not connected to the Internet. Authenticity checks for off-line systems can occur at time of deployment of released software.  Off-line systems require appropriate configuration and maintenance to be able to conduct <del> useful authenticity checks.  If the off-line systems are operation are part of constrained node environments, they do not possess the </del> <ins> useful authenticity checks.  If the off-line systems in operation are part of constrained node environments, they do not possess the </ins> capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.

Related discussion:
text: Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!
Code change:
frame from this client to the remote and receive a response. The value is represented in milliseconds. <del> 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams which it will allow.  By default there is no limit.  For </del> <ins> 4 - SETTINGS_MAX_CONCURRENT_STREAMS indicates the maximum number of concurrent streams which the sender of the SETTINGS frame is willing to allow the peer to open.  Note that this limit is directional.  By default there is no limit.  For </ins> implementors it is recommended that this value be no smaller <del> than 100. </del> <ins> than 100, so as not to unnecessarily limit parallelism. </ins> 5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.

Related discussion:
text: This updates the concurrent streams in the XML and updates the HTML too (which picked up some other changes).
"For implementors it is recommended that this value be no smaller than 100" - what is the significance of "for implementers" here? I'm concerned this language is ambiguous enough to cause trouble. E.g., some may read it as pure advice; others might take away that values smaller than 100 can be assumed to be 100. Best way to specify is with MUST/SHOULD/MAY, identifying who it applies to (sender / recipient), and ideally specifying what should happen on both ends of the wire (when generating and receiving).
I agree this is ambiguous. I snuck in a short explanation there. I feel like we should take this back to the working group mailing list. I propose we either commit as is, as my extra explanatory clause is innocuous, and open an issue to resolve the ambiguity. Or I can withdraw this pull request for now, go back to the mailing list, and proceed with the flow control pull request first.
I'm happy to merge now and note an issue; just trying to minimise the number of such edits we cause with each change, as they have a tendency to stack up.
Code change:
"65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt. <del> "65535" (status list): REQUIRED.  The status list claim MUST </del> <ins> "65533" (status list): REQUIRED.  The status list claim MUST </ins> specify the Status List conforming to the rules outlined in status-list-cbor.

Related discussion:
text: Adds a claim key for used in the status list token in CWT format and fixes the reference.
Code change:
the context is set to the structure described in <del> the exporter output length is set to 32 bytes (see output) </del> <ins> the exporter output length is set to 48 bytes (see output) </ins> 3.1.

Related discussion:
text: In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this
Code change:
track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). <ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application specific information.

Related discussion:
text: Since they're on different streams, an object can arrive before its SUBSCRIBEOK. This is easy to process because the Subscribe ID and Track Alias must have been the ones that the subscriber chose. What if the publisher then sends a SUBSCRIBEERROR? Is this valid behavior or an error? (If it weren't for the Expires field, SUBSCRIBE_OK would be entirely redundant and we could get rid of it.)
Individual Comment: This is covered a bit in and Luke expressed a desire to document the full state machine in . My read is that you can't send objects before SUBSCRIBE OK (but they can arrive out of order). I don't think you can send SUBSCRIBEERROR after SUBSCRIBEOK (objects or no objects), instead, use SUBSCRIBE_RST?
I agree that SUBSCRIBEERROR cannot follow SUBSCRIBEOK. I think you're saying that if Objects are in flight, then SUBSCRIBEOK must be as well, so a SUBSCRIBEERROR would in itself be an error. That sounds reasonable to me.
We're clear that only one of SUBSCRIBEOK or SUBSCRIBEERROR can be sent: the subscription, via SUBSCRIBEOK ({{message-subscribe-ok}}) or the SUBSCRIBEERROR {{message-subscribe-error}} control message. The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either SUBSCRIBEOK or SUBSCRIBEERROR. I wrote to clarify that you can't send objects and a SUBSCRIBE_ERROR.
Code change:
The claim indicates the hash algorithm used by the Issuer to generate the <del> digests over the salts and the claim values.  If the </del> <ins> digests.  When used, this claim MUST appear at the top level of the SD-JWT payload.  It MUST NOT be used in any object nested within the payload.  If the </ins> <del> claim is not present, a default value of </del> <ins> claim is not present at the top level, a default value of </ins> <del> is used. </del> <ins> MUST be used. </ins> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash

Related discussion:
text: Text looks good but it's going to clash with the array spec work URL
It's a small change, we can sort that out when merging either.
Now that is allowed at multiple locations in the JSON document, including recursively, I would expect Sec. 5.1.2 to define explicitly where the claim should appear. Once at the top of the document? Can it also appear alongside claims located deeper in the document? Also, please change the section heading from "hash function" to "hash algorithm", for consistency.
Thank you! The intention is that there is only one at the top level. We will clarify.
Concur with NAME
+1