jiebi/CodeConvo huggingface dataset:
Code change:
due to device or system constraints.  Avoid using if the protected resources are sensitive, high value or business critical.  Always deploy additional mitigations like proximity or only allow with pre- <del> registered devices. </del> <ins> registered devices.  Do not use for same-device scenarios (e.g. if the initiating device and authorization device is the same device). </ins> 5.2.2.

Related discussion:
text: Added additional text making it clear that cross device flows should not be used for same device scenarios as suggested by Joseph Heenan (see )
From Joseph Heenan: URL I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Also, in this text: "If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel Authentication (CIBA) provides an alternative, provided that the underlying devices can receive push notifications.” It might be best to use a term other than ‘push notifications’ there or otherwise rewording this, as there are alternatives. e.g. I think there’s at least one CIBA implementation out there that can use email to notify the user of an authorization request. Thanks Joseph
Code change:
Change Controller: IESG <del> Specification Document: Section purpose of this specification </del> <ins> Specification Document: Section txn-token-claims of this specification </ins>

Related discussion:
text: Updated the text to more clearly profile the token exchange specification for use with Transaction Tokens.
In PR , the token exchange parameter is profiled to carry the purpose or intent of the transaction and its value is copied into the claim of the resulting Txn-Token. Is this how we want to handle the 'purp' claim?
I propose that the draft should allow value of the claim in the TraT request be independent of the claim in the TraT, because the requesting service may not know sufficient details about how the TraT is actually going to be used. For example, the requester may say the is "buy stock", whereas the claim could have a value like "equity trade"
Ok, so allow the TTS to transform the input scope to the appropriate value (if necessary). I'm ok with that.
Recommended change that the TTS MUST take the value of the parameter to determine the claim of the TraT.
Based on this feedback, the claim is being made REQUIRED.
Should we allow the use of and to be used as a means of client authentication for the Transaction Token Service? If not, should explicitly prohibit the use of these parameters in the profile of the Token Exchange spec.
Since RFC8693 (Token Exchange) refers to the as "A security token that represents the identity of the acting party", we should not use it in the TraT request. I thought we wanted to have some way to convey the inbound token to the TraT service, and that's why we were using , but that is inconsistent with RFC8693. I think we should neither require nor disallow the use of because some implementations may want that for client auth, and some implementations may want to do something else (e.g. mTLS) for client auth.
This is kind of what the spec says today. It's not required and up to the implementation. It is just referenced as an example. However, I'm fine removing the example and just being silent in the spec on the topic.
Recommendation to update example and be silent on use of and . Add a section to Security Considerations to talk about client authentication and add some non-normative examples.
Removed the additional text regarding possible client authentication methods and just left it that the client MUST authenticate itself to the Transaction Token Service and that the specific client authentication method is out of scope for this specification.
Code change:
Change Controller: IESG <del> Specification Document: Section purpose of this specification </del> <ins> Specification Document: Section txn-token-claims of this specification </ins>

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:
Change Controller: IESG <del> Specification Document: Section purpose of this specification </del> <ins> Specification Document: Section txn-token-claims of this specification </ins>

Related discussion:
text: And would again suggest that RFC 9493 isn't needed in the Txn-Token context and good enough.
My concern with relying on the JWT's subject is that the Transaction Token is issued by the Transaction Token Service which is potentially different than the AS that say issued the access token from which the claim is determined. In that context, I think the Transaction Token should carry the issuer of the claim which means the default and claims of the JWT are not sufficient. Or if the entity requesting the Transaction token is the service that receives inbound mail, and that service wants a transaction token with a purpose of , is the Transaction Token Service the correct issuer of the which is an email address?
I feel like there might be an undue emphasis on a relationship between and that doesn't truly exist. RFC7519 only mentions uniqueness in the context of an issuer URL but not ownership or correctness or semantic meaning.
In the context of OpenID and id_tokens there is a clear relationship between the and the such that the globally unique identification is the combination of and . I've always viewed the relationship of those two claims in that light. Maybe that is an OpenID Connect centric view.
Yeah, I am somewhat familiar with OpenID Connect ;) But this isn't OpenID Connect. With a Transaction Token the subject just needs to be identified within a single trust domain.
So that assumes that the claim MUST be unique within the single trust domain as identified by the claim. This might require the Transaction Token Service (TTS) to do some sort of identifier transformation as well as requiring both the AS and the TTS to both be authoritative for the claim value. This is easy if the AS is managing the transaction token request endpoint but if the TTS is it's own service and deployed in a distributed way, would that still be true? I can see the TTS being authoritative for the single trust domain but not necessarily for the identifier. However, I'm ok with moving in the direction you are suggesting Brian; I just want to make sure we aren't prohibiting some deployments by making that simplification.
From discussion... 'iss' claim is optional be clear that there is no relationship between iss and sub claim sub is unique within context of the 'aud' or trust domain go back just supporting the claim (no sub_id)
Added a new commit to PR to address this issue.
A few months ago, I also suggested to support the sub claim as per JWT RFC.
Code change:
Change Controller: IESG <del> Specification Document: Section purpose of this specification </del> <ins> Specification Document: Section txn-token-claims of this specification </ins>

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:
serialization), ease of processing and availability of implementations. <del> At a high-level, a claim is a COSE single-signed object (i.e. "COSE_Sign1") that contains the correct set of protected headers. Although issuers and relays may attach unprotected headers to claims, transparency services and verifiers MUST NOT rely on the presence or value of unrpotected headers in claims during registration and validation. </del> <ins> At a high-level that is the context of this architecture, a Claim is a COSE single-signed object (i.e.  "COSE_Sign1") that contains the correct set of protected headers.  Although issuers and relays may attach unprotected headers to claims, transparency services and verifiers MUST NOT rely on the presence or value of additional unprotected headers in claims during registration and validation. </ins> All claims MUST include the following protected headers: <del> algorithm (label: "1"): Asymmetric signature algorithm as integer, for example "-35" for ECDSA with SHA-384, see COSE Algorithms registry [2] </del> <ins> algorithm (label: "1"): Asymmetric signature algorithm used by the claim issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2]; </ins> issuer (label: "TBD", to be registered): DID (Decentralized <del> Identifier, see W3C Candidate Recommendation [3]) of the signer as string, for example "did:web:example.com" </del> <ins> Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com"; </ins> <del> feed (label: "TBD"): the issuer's name for the artifact </del> <ins> feed (label: "TBD"): the issuer's name for the artifact, as a string; </ins> <del> payload type (label: "3"): Media type of payload as string, for </del> <ins> payload type (label: "3"): Media type of payload as a string, for </ins> example "application/spdx+json" registration policy info (label: "TBD"): a map of additional <del> attributes to help enforce registration policies </del> <ins> attributes to help enforce registration policies; </ins> DID key selection hint (label: "TBD"): a DID method-specific <del> selector for the signing key </del> <ins> selector for the signing key, as a bytestring. </ins> Additionally, claims MAY carry the following unprotected headers:

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: <del> Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server. </del> <ins> Note that this calculation is intended to reduce clock skew by using the clock information provided by the origin server whenever possible. </ins> When there is more than one value present for a given directive (e.g., two

Related discussion:
text: replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...
Code change:
5. HTTP messages use key/value pairs to convey data about the message, <del> its payload, the target resource, or the connection (i.e., control data).  They are called "HTTP fields" or just " </del> <ins> its payload, the target resource, or the connection.  They are called "HTTP fields" or just " </ins> ". <del> Every message can have two separate areas that such fields can occur within; the " </del> <ins> Fields that are sent/received before the message body are referred to as "header fields" (or just "headers", colloquially) and are located within the " </ins> <del> " (or just "header section") preceding the message body and containing "header fields" (or just "headers", colloquially) and the " </del> <ins> " of a message.  We refer to some named fields specifically as a "header field" when they are only allowed to be sent in the header section. Fields that are sent/received after the header section has ended (usually after the message body begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a " </ins> <del> " (or just "trailer section") after the message body containing "trailer fields" (or just "trailers" colloquially).  Header fields are more common; see trailer.fields for discussion of the applicability and limitations of trailer fields. </del> <ins> ".  One or more trailer sections are only possible when supported by the version of HTTP in use and enabled by an extensible mechanism for framing message sections. </ins> Both sections are composed of any number of "

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
Would result in the following "@query" value: <ins> If the query string is absent from the request message, the value is the leading "?" character alone: </ins> If used in a related-response, the "@query" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: Includes several document cleanups for signatures, to publish as -09
Also: If there is no query string should the corresponding signing text be or ie. should the query value be empty or just consist of one Should we return with this request and return on this request This is what I opted for in my implementation. See shows that http4s makes the distinction between blank queries and empty queries is simpler I think this is a corner case that is worth explicating very clearly, perhaps even with a test.
There are quite a few occurrences of the header in the draft. From an implementation point of view, Go "swallows" the header and it is not part of the standard Request structure. There's a good reason for the Go library to do it, and in fact the draft recommends to use NAME instead. Can we remove from examples, e.g. Sec. 2.1, so we don't train people to do the wrong thing?
There are only a couple instances of the "host" header in the current draft left, and one of them (section 2.1) is specifically about how to format headers. It could be removed from the other example signature input strings without affecting anything negatively. Same with the "date" header, which could be confused with the "created" parameter, see
This sentence is correct: But it's true for most reasonable uses of , and people will still be using this parameter. So why not add:
No, we explicitly did not want to conflate this with the jwa registry. We also didn't want to have a second tier choice like having "alg=jose" and then having the actual algorithm elsewhere, since a big problem with late editions of the Cavage draft were exactly that process. (See the mess around "hs2019"). The editors discussed this at length and decided the best compromise was to define a way that jwa algorithms could be used in an interoperable fashion, but not to allow runtime signaling with them. Better to have the choice of jwa be signaled within the application level. Additionally, it's preferable to not use the runtime parameter to signal the algorithm any way, which is discussed at length in the security considerations.
All good, so why aren't you using normative language?
It's not normative because this section defines the algorithms, not the parameter.
Code change:
Would result in the following "@query" value: <ins> If the query string is absent from the request message, the value is the leading "?" character alone: </ins> If used in a related-response, the "@query" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: We didn't want to make it seem like the parameter was the "right" way to signal algorithms here, and most certainly is not required. You'll notice that none of the other sections have "MUST use the alg parameter value of 'foo'" either. Older Cavage drafts relied on the parameter, albeit in a much less secure fashion, and implementations were susceptible to algorithm substitution in the same way that naive JOSE implementations tend to be -- the "alg: none" attack all over again, more or less. The value of the parameter already MUST be something from the registry, and the registry does not (and will not) contain JWA values. So you already aren't allowed to do it, normatively, and the note is our attempt at explaining the why. Ultimately, an implementation is allowed to use whatever algorithm they want and makes sense. What this whole section does is define a set of common usable algorithms as well as provide a pattern of applying crypto primitives that applications can follow for their own algorithms. If someone defines a new algorithm that's generally useful, like we recently did with the ed25519 here, it can be registered for use with the parameter. But if a system can base the algorithm selection off of the key material or another part of the protocol (like with GNAP), that's highly preferable and less vulnerable to substitution at runtime. I'd be happy to know how we can make this clearer in the text, but I'm not comfortable with that kind of normative construct in that section.
NAME -- would you like to chime in? I recall from our discussions you having another, more specific reason for this decision, but I can't remember the details beyond us agreeing to do it the way we have it in the spec right now.
Neither Java nor JS subtleCrypto come out of the box with PKCS1 PEM support. (for java ). It is not immediately obvious to work out that the PEM formats of the private key in in PKCS1 format (the spec could point that out). When building an implementation it helps to have the test suite clearly map to the data in the spec (e.g. ) so as to make error reporting clearer. That is even though using the following openssl command to convert the keys work, it makes it difficult to see if an error was introduced at some point.
Code change:
Would result in the following "@query" value: <ins> If the query string is absent from the request message, the value is the leading "?" character alone: </ins> If used in a related-response, the "@query" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: To support PKCS1 the developer has to depend on further less well tested libraries and add additional code (as I ) leading possibly to new bugs. Furthermore, I will need to go through the same process for JavaScript now, doubling the work. Since PKCS8 is as expressive as PKCS1 ( and see ), it would make life easier for devs if the keys were all in PKCS8 format. Unless there really is something that PKCS1 offers that PKCS8 does not? I will try doing this using the Web Crypto API next. But there we find that supports the PKCS format.
While I am at it. I am having trouble with verifying the signature for 3 out of 4 examples from the spec that I tried out in . Currently the only one that works is the . I am able to produce and verify a signature for , and examples, but the signatures don't correspond to what is in the spec. That may very well be a mistake in my code, which I am working on as a to bobcats scala and scala-js crypto library. But I just wanted to check how confident you were in your examples. I am going to re-implement next in JS, so that will give me another reference point.
I am working my way through this with JS. I was able to parse the and keys after translating them to pkcs8 format with openssl, but am having trouble importing in the console of Chrome, Chrome-beta, Chrome-Dev and Safari. I guess that is in pkcs8 format already. I don't have trouble parsing that key with BouncyCastle... I guess this is a little config problem, but it's difficult to work out what that could be... Perhaps someone has an idea?
NAME Since this all has to do with the examples in the text and not the spec itself, I think we'd be fine with having the keys in multiple formats if it's useful for developers. However I'll note that in many code libraries you need to add the PEM headers of and for their compliant parsers to parse an EC key in PEM format, for example. I've been able to parse these keys in both Java and Python, and in fact all the examples are generated using a python script: URL Also, note that RSA-PSS and ECDSA are non-deterministic signatures that incorporate a source of randomness into the signature calculation.