jiebi/CodeConvo huggingface dataset:
Code change:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <ins> 8.4. How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0 Token Exchange specification, both parameters MUST be present in the request.  The "actor_token" MUST autenticate the identity of the requesting workload. </ins> 9. 9.1. <del> Some "req_ctx" claims may be considered personal information in some </del> <ins> Some "rctx" claims may be considered personal information in some </ins> jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some

Related discussion:
text: PR raised a number of issues around processing of authorization details How are these details determined by the Transaction Token Service (i.e. where do they come from)? Should all the claims be visible to all workloads? or should they be restricted to a subset of workloads? Who is authoritative for specifying the claims of the object
Some thoughts: I think the spec should be un-opinionated about how the TraT service generates the value of claim. I can see in some instances that the requester has more control over what goes into the claim, and in some cases, the TraT service has more control. A TraT service could implement selective disclosure, although we could recommend in the spec that one should implement it by encrypting certain fields. Stating this makes the actual mechanism for selective disclosure outside the scope of the spec. I believe the TraT service MUST be authoritative for the claims of the object, because it is signing the TraT.
Regarding (1) -- I think we still need a way for the client to pass in data to the TTS that it can use to generate the values. Even if how all that works is out of scope for the specificatio. Regarding (2) and (3) -- I'm ok with leaving the rules out of scope for the specification. The TTS will be authoritative for the resulting object and whether it should be protected in some way or not. I am curious to hear from others as to their thoughts.
Suggestion to rename to and then add a processing rule to the effect of... "The TTS SHOULD propagate the data from the object into claims in the object as authorized by the TTS authorization policy for the requesting client"
This has been fixed AFAIK. Please reopen the issue if it hasn't been fixed by George's PR.
I suspect in many cases the AS that issues an accesstoken used to obtain an Txn-Token is going to be different than the Transaction Token Service. In that context, the issuer of the 'subject' of the transaction token is different than the issuer of the transaction token itself. Section 3.2.3 of RFC 9493 allows for the specification of an issuer and sub within the object. Should we require this format? or just leave out of scope of the specification what values are present in the claim of the transaction token?
I would definitely not require that format.
Code change:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <ins> 8.4. How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0 Token Exchange specification, both parameters MUST be present in the request.  The "actor_token" MUST autenticate the identity of the requesting workload. </ins> 9. 9.1. <del> Some "req_ctx" claims may be considered personal information in some </del> <ins> Some "rctx" claims may be considered personal information in some </ins> jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some

Related discussion:
text: As the current spec has replaced sub_id with sub, I appreciate that the sub claim is supported now.
Hi Kai, Thanks so much for your input in this process. Atul
Since we have removed sub_ids now, I will close this issue.
Wkn
Code change:
(bit size) to be able to describe the required Status Types for the application. <ins> The processing rules for JWT or CWT precede any evaluation of a referenced tokens status.  For example if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired. </ins> 6. 6.1.

Related discussion:
text: This feedback comes from applying the Status List to an implementation of a general OAuth 2.x server issuing JWT Access Tokens. Such implementation will typically not keep record of any issued JWT Access Tokens (their claims, expiry, etc) until they need to be revoked due any reason, e.g. getting leaked or just being explicitly revoked by the client. In such cases the issuer considers the token as VALID when issuing the Status List but this state will not necessarily reflect the token's validity as per the JWT validation rules for claims like nbf or exp. This is important to point out so that the status list is not mistaken for an alternative to actually validating the referenced token's claim set.
NAME could you merge with main and add a line to the document history please
Not a member, cannot merge.
I meant sync, sry. But I can add the history on main also.
NAME Please review and merge if you approve
Looks good to me. It might be better positioned in a dedicated Verification Processing section once we have that but its good for now
Code change:
1. <del> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </del> <ins> The JSON-based representation of claims in a signed JSON Web Token (JWT) RFC7519 is secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> This document describes a format for signed JWTs that supports selective disclosure (SD-JWT), enabling sharing only a subset of the

Related discussion:
text: PR for URL
Done, and also cleaned up the intro slightly (repeating 'document' is superfluous there).
Code change:
reason, then it MUST request a new Client Attestation JWT from its Client Backend. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of <del> the end user using the client instance through claim values </del> <ins> the end user using the Client Instance through claim values </ins> (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 7. </del> <ins> 8. </ins> The guidance provided by RFC7519 and RFC8725 applies. <del> 7.1. </del> <ins> 8.1. </ins> The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay

Related discussion:
text: Based on the discussions had at IETF 119 in the OAuth WG, this PR attempts to make the following changes to the draft Move away from usage of the assertion framework defined in RFC 7521 and RFC 7523 for conveying the client attestation and client attestation pop. Instead use two newly defined HTTP headers OAuth-Client-Attestation and OAuth-Client-Attestation-PoP for conveyance in an HTTP request, akin to how DPoP works. Explicitly mention this mechanism could be used in a variety of places including with a resource server. Note, there are still many outstanding items I would like to add, however I felt this PR was already big enough as it is, these include Error responses for the token endpoint Optimisation for when this mechanism is used with DPoP to avoid having to send two PoP's Formalising whether this mechanism still constitutes a form of client authentication
For some reason it seems to not create an html version? This is the rendered text: URL
I think there were potential objections mentioned about moving to headers as to whether we'd run into size limits (I think 8 KB was mentioned as a common restriction) and people felt jwts with embedded x5c headers etc may get close to these limits?
NAME indeed. We may have a client attestation with an huge x509 certificate chain or an openid federation trust chain with several metadata, trust marks and jwks. I don't see the benefit of moving from what it is actually more efficient (wa~wa-pop) more over, technically we can have multiple client_assertions that embedes their pop (using ~), while having multiple http headers that divide attestation from pop forces the implementations to loop all the assertions and all the pop to find the matching ones
Added client instance definition and updated to use US based spelling of authorization instead of authorisation.
NAME NAME I can understand the desire to want to use X.509 certificates to validate the client assertion (e.g as an alternative key resolution mechanism to resolving a JWKS document from a domain), however I don't see how the certificate chain would be more then 1 certificate (maybe 2) in length (bearing in mind the root certificate(s) would be communicated to the issuer out of band and pre-trusted for the client).
Code change:
reason, then it MUST request a new Client Attestation JWT from its Client Backend. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of <del> the end user using the client instance through claim values </del> <ins> the end user using the Client Instance through claim values </ins> (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 7. </del> <ins> 8. </ins> The guidance provided by RFC7519 and RFC8725 applies. <del> 7.1. </del> <ins> 8.1. </ins> The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay

Related discussion:
text: Right but to be clear, the current draft does not handle multiple wallet attestations either though so I think this a new requirement that we should discuss separately, would you mind opening a seperate issue?
The issue extends beyond the realm of multiple wallet attestations, as there could also be multiple DPoP tokens involved. An additional consideration, which we have not yet fully addressed but may emerge as a future requirement, is the scenario where a wallet instance operates under more than one trust framework, necessitating specialized assertions for each. While we have consciously chosen to limit the scope to a single wallet attestation to simplify implementation, it's important to acknowledge that this decision does not preclude the possibility of requiring multiple assertions in the future. Implementers may need to adapt or extend the specification to accommodate such needs. However, to avoid digressing further, let's focus on the matter of handling multiple DPoP headers for now. The approach currently documented, which aims to streamline the process by limiting it to a single attestation, is designed to offer the same benefits while minimizing computational overhead.
While it is possible to reconfigure these options, it is important to keep default values of the wide-spread implementations in mind to allow an easy path for adoption. I took the time to look at some of the frameworks I would say are good indicators: nginx: --> 8KB for 1 header max envoy (used in istio): --> 60 KB for headers URL --> 16KB for headers traefik: --> re-uses go/http: 1MB for headers --> After looking at this, I would say we can go with headers
An OpenID Federation trust chain with two intermediates, the trust anchor entity configuration with a long list of trust mark issuers and the leaf entity configuration with a very verbose configuration, such as an AS + Openid4VCI + OpenID4VP (considering an EAA provider), with policies and a consistent number of trust mark might be 20KB. A serialized X.509 certificate chain, with 4 intermediates, custom extensions and QWACs ... Considering each certificate up to 2.2KB, might it be 8.8KB?
Code change:
reason, then it MUST request a new Client Attestation JWT from its Client Backend. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of <del> the end user using the client instance through claim values </del> <ins> the end user using the Client Instance through claim values </ins> (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 7. </del> <ins> 8. </ins> The guidance provided by RFC7519 and RFC8725 applies. <del> 7.1. </del> <ins> 8.1. </ins> The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay

Related discussion:
text: (please, consider that openid federation brings policy languages, trust marks and multiple protocol specific metadata) I'm worried about these aspects: loop required for parse/matching the correct DPoP when multiple DPoP are present, while WIA~WIA-POP doesn't bring this problem. What's the benefit of having this breaking change that reduce the flexibility while increasing the complexity? size limitations: Do we have to imagine to standardize something upon the assumption that a federation topology should not have more than 2 or 4 or 8 intermediates, since this decision is out of scope on this specification.
A bit off-topic for the current discussion: We need to fix the examples - they are way too long which breaks the rendering/conversion and will cause problems with the datatracker. I do believe that this is also the reason why the html file was not created.
Note that rfc9449 does not allow for multiple DPoP headers. It could maybe have been stated more clearly but is kinda implied and was absolutely the intent of the RFC overall and specific text like URL
NAME as I implied with my earlier comment, the current draft text doesn't support multiple attestations so I don't view this proposal to shift to headers as removing functionality, it appears this is a new usecase and I think we should discuss it in a seperate issue. No I dont think we do, what was identified above is that there is no size limit on headers in HTTP rather defaults that servers apply which can be adjusted, in reality web servers also apply limits to the body of an HTTP request (although often much larger then what is allocated for headers).
Discussed with NAME I will add an implementation consideration around the default size limits for HTTP headers.
NAME what about using compressed values? unfortunately this sounds like giving a solution that may bring other problems, at the same time we can consider zlib (RFC 1950) for doing this.
Something broke with linking the html rendered versions properly Rendered html: URL
It just (re)occurred to me that specs defining new HTTP headers (which the cool kids call fields nowadays) are supposed to request their registration in the . I don't want to hold up this PR for this but will create an issue from this comment so as not to lose track of it.
Code change:
reason, then it MUST request a new Client Attestation JWT from its Client Backend. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of <del> the end user using the client instance through claim values </del> <ins> the end user using the Client Instance through claim values </ins> (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 7. </del> <ins> 8. </ins> The guidance provided by RFC7519 and RFC8725 applies. <del> 7.1. </del> <ins> 8.1. </ins> The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay

Related discussion:
text: I do believe there should be a discussion about terminology (attestation vs assertion) as it seems to create quite a bit of confusion, but I do think a different issue/PR is better suited for that. Minor nit: Client Attestation seems to be used in lower and upper case somewhat inconsistently. Should every usage be upper case (e.g., also client attestation mechanism)?
Code change:
Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. <del> 6. </del> <ins> 7. </ins> See the security considerations section of:

Related discussion:
text: This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
Code change:
Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. <del> 6. </del> <ins> 7. </ins> See the security considerations section of:

Related discussion:
text: There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.
Code change:
not use TLS. Once TLS negotiation is complete, both the client and the server MUST <del> send a ConnectionHeader. </del> <ins> send a preface. </ins> 3.3.

Related discussion:
text: As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.