jiebi/CodeConvo huggingface dataset:
Code change:
Note: The examples throughout this document use the <del> claim to include the raw public key by value in SD-JWT. </del> <ins> claim with the member to include the raw public key by value in SD-JWT. </ins> 5.2.

Related discussion:
text: More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key
Code change:
5.1.14. <del> Use cross device authentication after a successful phishing resistant authentication.  The unauthenticated channel between the initiating and authenticating device allows attackers to obtain a QR code.  When the QR Code is presented after a successful phishing resistant authentication, this prevents the attack from being initiated. Scenario A user would like to verify an identity on a web application using an identity stored on a separate mobile device in a phishing resistant way.  Using verifiable credentials from a secure and trusted wallet and presenting this to a trusted verifier service would be an example of this.  The flow is initialized using a QR Code created inside a secure session on the target service after a phishing resistant authentication.  The verifier could validate the identity from the authenticated session where the QR Code is presented, and the identity sent in the verifiable credential. </del> <ins> By requiring a user to authenticate on the initiating device with a phishing resistant authentication method before initiating a cross- device flow, the server can prevent an attacker from initiating a cross-device flow and obtaining QR codes or user codes.  This prevents the attacker from obtaining a QR code or user code that they can use to mislead an unsuspecting user.  This requires that the initiating device has sufficient input capabilities to support a phishing resistant authentication mechanism.  Note that this does not prevent the attacks described in Example B5: Illicit Network Join [4] and Example B7: Illicit Session Transfer [5] and it is recommended that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [6] and Example A7: Transfer a session [7]. </ins> 5.1.15.

Related discussion:
text: Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.
Code change:
3.2. SD-JWT VCs MUST be encoded using the SD-JWT format defined in <del> Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </del> <ins> Section 4 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </ins> of an SD-JWT VC MAY contain a Key Binding JWT. Note that in some cases, an SD-JWT VC MAY have no selectively

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.
Code change:
3.2. SD-JWT VCs MUST be encoded using the SD-JWT format defined in <del> Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </del> <ins> Section 4 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </ins> of an SD-JWT VC MAY contain a Key Binding JWT. Note that in some cases, an SD-JWT VC MAY have no selectively

Related discussion:
text: Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:
Code change:
3.2. SD-JWT VCs MUST be encoded using the SD-JWT format defined in <del> Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </del> <ins> Section 4 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </ins> of an SD-JWT VC MAY contain a Key Binding JWT. Note that in some cases, an SD-JWT VC MAY have no selectively

Related discussion:
text: and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.1. </del> <ins> 4.1.1. </ins> The following rules apply to validating the "status" (status) claim The claim value MUST be a valid JSON object. The claim value object MUST contain a "typ" (type) attribute with <del> a string based value that represents the type of status list </del> <ins> a string based value that represents the type of Status List </ins> referenced.  The value MUST be equal to that of the "typ" <del> attribute in the "status_list" claim for the referenced status list. </del> <ins> attribute in the "status_list" claim for the referenced Status List. </ins> The claim value object MUST contain an "idx" (index) attribute with a numberic based value that represents the index to check for <del> status information in the status list for the current JWT.  The </del> <ins> status information in the Status List for the current JWT.  The </ins> value of this attribute MUST be a non-negative number, containing a value of zero or greater.  Refer to xx for details on the validation procedure. The claim value object MUST contain a "uri" attribute with a <del> string based value that identifies the status list containing the </del> <ins> string based value that identifies the Status List containing the </ins> status information for the JWT.  The value of this attribute MUST be a uri conforming to <del> 3.2. </del> <ins> 4.2. </ins> <del> The following rules apply to validating a JWT based status list. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating a JWT based Status List Token.  Application of additional restrictions and policy are at the </ins> discretion of the verifying party. The JWT MUST contain an "iss" (issuer) claim that contains a

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
Code change:
7.2. The "subject_token_type" parameter value MUST be a URI RFC3986.  It <del> MAY be any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"), or it MAY be a self-signed JWT, as described below, or it MAY be a custom URI agreed to between requesters and the Txn-Token Service. </del> <ins> MAY be: </ins> <del> The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter.  Any value used in this parameter MUST be a URI as specified in RFC 8693 RFC8693. </del> <ins> Any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"). A URN type name when the subject token is a self-signed JWT, as described below. A URN type name when the subject token is an unsigned JSON object, as described below. A custom URN agreed to between requesters and the Txn-Token Service.  The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter. </ins> 7.2.1.

Related discussion:
text: The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
Code change:
7.2. The "subject_token_type" parameter value MUST be a URI RFC3986.  It <del> MAY be any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"), or it MAY be a self-signed JWT, as described below, or it MAY be a custom URI agreed to between requesters and the Txn-Token Service. </del> <ins> MAY be: </ins> <del> The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter.  Any value used in this parameter MUST be a URI as specified in RFC 8693 RFC8693. </del> <ins> Any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"). A URN type name when the subject token is a self-signed JWT, as described below. A URN type name when the subject token is an unsigned JSON object, as described below. A custom URN agreed to between requesters and the Txn-Token Service.  The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter. </ins> 7.2.1.

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
A publisher SHOULD begin sending incomplete objects when available to avoid incurring additional latency. <del> A relay that reads from a stream and writes to stream in order will </del> <ins> A relay that reads from one stream and writes to another in order can </ins> introduce head-of-line blocking.  Packet loss will cause stream data <del> to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write stream data out of order subject to flow </del> <ins> to be buffered in the library, awaiting in-order delivery, which could increase latency over additional hops.  To mitigate this, a relay MAY read and write stream data out of order subject to flow </ins> control limits.  See section 2.2 in QUIC. 6.

Related discussion:
text: One small normative change: I relaxed a SHOULD to a MAY when discussing relays writing data out of order. No one is implementing this right now.
Here are some editorial notes on the document Line 72. “MOQT is a generic protocol is designed to work” Line 91-93. “The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.” This sentence is intriguing. What does the robustness of QUIC mean? Latency, workflow efficiency, relay support are not “areas” or maybe area should be defined. (side note on the missing Oxford comma in this sentence) The Section 1.1.1. Latency as a whole is very confusing. HTTP-based streaming is not designed for low latency mostly due to the essential request-response paradigm. Queuing on the path has a insignificant impact on the end-to-end latency for HAS. The “speed at which a protocol can detect queuing” is not related to the relatively high latency issues of HAS. Overall, I see a mix of unrelated subjects here, which makes the paragraph overall meaningless. I would recommend starting the paragraph with a topic sentence (which may be the last one of the current paragraph). Line 120. “Applying QUIC to HAS …” (and the following sentences) is not necessary. The reasons for which QUIC does not bring advantages to HAS are still debatable on many points. This QUIC-on-HAS remark could raise unnecessary questions although the beginning of Section 1.1.2 is clear and sufficient to convey the message. Line 125. “Universal” has a too broad sense. Do you mean “Unicity of protocol in the whole pipeline” (or something like this)? Line 127. “Internet delivered media today has protocols optimized for ingest…” I don’t understand this sentence. Line 127. Some examples of protocols could be good to support these claims. Note that WHIP is an attempt to unify the protocol. Line 146. “to treat relays as first-class citizens of the protocol” is an excellent marketing message but it does not mean anything in a technical norm. Furthermore, see my two reserves above. I’d claim that the current draft is not making relay first-class, on the contrary.
Code change:
A publisher SHOULD begin sending incomplete objects when available to avoid incurring additional latency. <del> A relay that reads from a stream and writes to stream in order will </del> <ins> A relay that reads from one stream and writes to another in order can </ins> introduce head-of-line blocking.  Packet loss will cause stream data <del> to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write stream data out of order subject to flow </del> <ins> to be buffered in the library, awaiting in-order delivery, which could increase latency over additional hops.  To mitigate this, a relay MAY read and write stream data out of order subject to flow </ins> control limits.  See section 2.2 in QUIC. 6.

Related discussion:
text: Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.