jiebi/TextFlow huggingface dataset:
Original text:
authentication of one workload to another, such as in the case where one service is making a request to another service as part of a larger, more complex application.  Following authentication, the <del> request to the service offered by the workload it needs to be </del>  authorized.  Even in this simple case the identity of a workload is often composed of many attributes such as:

Reviewer comments:
Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.

Revised text:
authentication of one workload to another, such as in the case where one service is making a request to another service as part of a larger, more complex application.  Following authentication, the  <ins> request to the service offered by the workload needs to be </ins> authorized.  Even in this simple case the identity of a workload is often composed of many attributes such as:
Original text:
Some of the most common include: TLS authentication of the server using X.509 certificates and <del> bearer token, encoded as JWTs. </del>  Mutual TLS authentication using X.509 certificate for both client and server.

Reviewer comments:
Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.

Revised text:
Some of the most common include: TLS authentication of the server using X.509 certificates and  <ins> client bearer token, encoded as JWTs. </ins> Mutual TLS authentication using X.509 certificate for both client and server.
Original text:
URN Namespace for IETF Use [2] somehow.  Or maybe nothing.  Or maybe something else.  6.1. TODO: "application/wimse-id+jwt" or appropriately bikeshedded media type name (despite my ongoing unease with using media types for <del> typing JWTs) in Media Types [3]. </del>  6.2. TODO: "Workload-Identity-Token" from  7.  References 7.1.  URIs

Reviewer comments:
[8:31 AM May 30 in slack] To summarize the near term plan: Joe: security considerations and interaction with TLS Brian: ID Token and DPoP-inspired Yaron: Message Signatures this is the "DPoP-inspired" part A preview editors' copy of this PR can be seen at URL

Revised text:
URN Namespace for IETF Use [2] somehow.  Or maybe nothing.  Or maybe something else. <ins> TODO: "tth" and maybe "oth" claim in JSON Web Token Claims Registry [3] </ins> 6.1. TODO: "application/wimse-id+jwt" or appropriately bikeshedded media type name (despite my ongoing unease with using media types for  <ins> typing JWTs) in Media Types [4]. TODO: "application/wimse-proof+jwt" ... </ins> 6.2. TODO: "Workload-Identity-Token" from <ins> TODO: "Workload-Proof-Token" from </ins> 7.  References 7.1.  URIs
Original text:
[2] https://www.iana.org/assignments/params/params.xhtml <del> [3] https://www.iana.org/assignments/media-types/media-types.xhtml </del> 

Reviewer comments:
[8:31 AM May 30 in slack] To summarize the near term plan: Joe: security considerations and interaction with TLS Brian: ID Token and DPoP-inspired Yaron: Message Signatures this is the "DPoP-inspired" part A preview editors' copy of this PR can be seen at URL

Revised text:
[2] https://www.iana.org/assignments/params/params.xhtml  <ins> [3] https://www.iana.org/assignments/jwt/jwt.xhtml [4] https://www.iana.org/assignments/media-types/media-types.xhtml </ins>
Original text:
of interaction between two workloads.  This is the core component of the WIMSE architecture I-D.ietf-wimse-arch.  Assume that Service A needs to call Service B.  For simplicity, this document focuses on <del> REST services, and the service-to-service call consists of a single HTTP request and its response.  We define the credentials that both services should possess and how they are used to protect the HTTP exchange. </del>  There are multiple deployment styles in use today, and they result in different security properties.  We propose to address them

Reviewer comments:
There's nothing necessarily RESTful about this nor should it be limited to REST. Let's just not use the term. URL is a fun semi-related read, if you have or can find the time.
Quoting the article: I am not as young but I agree with this sentiment. Having said that, I guess a standard needs to be reasonably precise in its usage of terminology, and so I accept the PR.

Revised text:
of interaction between two workloads.  This is the core component of the WIMSE architecture I-D.ietf-wimse-arch.  Assume that Service A needs to call Service B.  For simplicity, this document focuses on  <ins> HTTP-based services, and the service-to-service call consists of a single HTTP request and its response.  We define the credentials that both services should possess and how they are used to protect the HTTP exchange. </ins> There are multiple deployment styles in use today, and they result in different security properties.  We propose to address them
Original text:
Many use cases have various middleboxes inserted between pairs of services, resulting in a transport layer that is not end-to-end encrypted.  We propose to address these use cases by protecting <del> the REST messages at the application level (app-level). </del>  The other commonly deployed architecture has a mutual-TLS connection between each pair of services.  This setup can be

Reviewer comments:
There's nothing necessarily RESTful about this nor should it be limited to REST. Let's just not use the term. URL is a fun semi-related read, if you have or can find the time.
Quoting the article: I am not as young but I agree with this sentiment. Having said that, I guess a standard needs to be reasonably precise in its usage of terminology, and so I accept the PR.

Revised text:
Many use cases have various middleboxes inserted between pairs of services, resulting in a transport layer that is not end-to-end encrypted.  We propose to address these use cases by protecting  <ins> the HTTP messages at the application level (app-level). </ins> The other commonly deployed architecture has a mutual-TLS connection between each pair of services.  This setup can be
Original text:
Workload A obtains a credential from the Identity Server.  This happens periodically, e.g. once every 24 hours. <del> Workload A makes a REST call into Workload B.  This is a regular REST call, with the additional protection mechanisms defined </del>  below. Workload B now authenticates Workload A and decides whether to

Reviewer comments:
There's nothing necessarily RESTful about this nor should it be limited to REST. Let's just not use the term. URL is a fun semi-related read, if you have or can find the time.
Quoting the article: I am not as young but I agree with this sentiment. Having said that, I guess a standard needs to be reasonably precise in its usage of terminology, and so I accept the PR.

Revised text:
Workload A obtains a credential from the Identity Server.  This happens periodically, e.g. once every 24 hours.  <ins> Workload A makes an HTTP call into Workload B.  This is a regular HTTP request, with the additional protection mechanisms defined </ins> below. Workload B now authenticates Workload A and decides whether to
Original text:
defined by the issuer.  Using a WIMSE ID without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain.  Additionally, the trust domain must be <del> tied to an authorized issuer cryptographic trust root through some </del>  mechanism such as a JWKS or X.509 certificate chain.  The association <del> of an issuer, trust domain and a cryptographic trust root MUST be </del>  communicated securely out of band. 6.2.

Reviewer comments:
Change trust root to trust anchor, to align with Trust Anchor terminology as used in rfc5280.
sure

Revised text:
defined by the issuer.  Using a WIMSE ID without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain.  Additionally, the trust domain must be  <ins> tied to an authorized issuer cryptographic trust anchor through some </ins> mechanism such as a JWKS or X.509 certificate chain.  The association  <ins> of an issuer, trust domain and a cryptographic trust anchor MUST be </ins> communicated securely out of band. 6.2.
Original text:
WIMSE certificate may contain SubjectAltName extensions of other types such as DNSName. <del> WIMSE identities may be used to validate server and client connections.  When validating a WIMSE identity the relying party MUST validate that the CA issuer for the WIMSE identity is authorized to issue certificates for the trust domain of the WIMSE identity in the certificate.  Other PKIX path validation rules apply. Servers wishing to use the WIMSE identity for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document. </del>  WIMSE clients and servers MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the

Reviewer comments:
Editorial.
Commenting as identity enthusiast as opposed to WIMSE co-chair. Consider replacing WIMSE Identities with WIMSE Credentials since it is the credential that is being verified, which may include a Workload identifier and possibly other claims.
WIT stays though.

Revised text:
WIMSE certificate may contain SubjectAltName extensions of other types such as DNSName.  <ins> WIMSE certificates may be used to secure both server and client connections.  When validating a WIMSE certificate, the relying party MUST validate that the CA issuer for the WIMSE certificate is authorized to issue certificates for the trust domain of the WIMSE workload identified by the certificate.  Other PKIX path validation rules apply. Servers wishing to use the WIMSE certificate for authorizing the client MUST require client certificate authentication in the TLS handshake.  Other methods of post handshake authentication are not specified by this document. </ins> WIMSE clients and servers MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the
Original text:
It is RECOMMENDED that the server certificate contain a DNS SAN that the client can use to perform standard host name validation <del> (RFC9525).  The client SHOULD also extract the WIMSE identity from </del>  the certificate if it is present and validate that the WIMSE trust domain matches the intended trust domain for the server.  The client <del> MAY then further use the WIMSE identity in applying authorization </del>  policy to the server.  If the client does not use the DNS SAN then <del> the client MUST match the WIMSE identity in the certificate against </del>  the WIMSE identity of the workload of the intended server according to a locally defined policy.  The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of RFC9525 but rather as a trust domain.  The server identity is encoded in the path <del> portion of the WIMSE identity in a deployment specific way. </del>  5.2. <del> The client or server application may retrieve the WIMSE identity from the TLS layer for use in authorization, accounting and auditing.  For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer. </del>  6.

Reviewer comments:
Editorial.
Commenting as identity enthusiast as opposed to WIMSE co-chair. Consider replacing WIMSE Identities with WIMSE Credentials since it is the credential that is being verified, which may include a Workload identifier and possibly other claims.
WIT stays though.

Revised text:
It is RECOMMENDED that the server certificate contain a DNS SAN that the client can use to perform standard host name validation  <ins> (RFC9525).  The client SHOULD also extract the WIMSE identifier from </ins> the certificate if it is present and validate that the WIMSE trust domain matches the intended trust domain for the server.  The client  <ins> MAY then further use the WIMSE identifier in applying authorization </ins> policy to the server.  If the client does not use the DNS SAN then  <ins> the client MUST match the WIMSE identifier in the certificate against </ins> the WIMSE identity of the workload of the intended server according to a locally defined policy.  The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of RFC9525 but rather as a trust domain.  The server identity is encoded in the path  <ins> portion of the WIMSE identifier in a deployment specific way. </ins> 5.2.  <ins> The client or server application may retrieve the WIMSE identifier from the TLS layer for use in authorization, accounting and auditing. For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer. </ins> 6.
Original text:
3.2. <del> This document defines a workload identity as a URI RFC3986.  This URI is used in the subject fields in the certificates and tokens defined later in this document.  This specification treats the URI as opaque. The format of the URI and the namespace for the URI are at the discretion of the deployment at large.  Other specifications may define specific URI structures for particular use cases.  An example of a defined identity format is the SPIFFE ID [1]. A workload identity only has meaning within the scope of a specific issuer.  Two identities of the same value issued by different issuers may or may not refer to the same workload.  In order to avoid collisions identity URIs SHOULD specify, in the URI's "authority" field, the trust domain associated with an issuer that is selected from a global name space such as host domains.  However, the validator of an identity credential MUST make sure that they are using the correct issuer credential to verify the identity credential and that the issuer is trusted to issue tokens for the defined trust domain. </del>  4.

Reviewer comments:
Revised the workload identity section to align with RFC 5280 and include trust domain. Aligns closely with SPIFFE, but allows other schemes to be defined.

Revised text:
3.2.  <ins> This document defines a workload identifier as a URI RFC3986.  This URI is used in the subject fields in the certificates and tokens defined later in this document.  The URI MUST meet the criteria for the URI type of Subject Alternative Name defined in Section 4.2.1.6 of RFC5280. In addition the URI MUST include an authority that identifies the trust domain within which the identifier is scoped.  The trust domain SHOULD be a fully qualified domain name belonging to the organization defining the trust domain to help provide uniqueness for the trust domain identifier.  The scheme and scheme specific part are not defined by this specification.  An example of an identifier format that conforms to this definition is SPIFFE ID [1].  While the URI encoding rules allow host names to be specified as IP addresses, IP addresses MUT NOT be used to represent trust domains except in the case where they are needed for compatibility with existing naming schemes. </ins> 4.
Original text:
A signed response would be:  5. The WIMSE workload identity may be carried within an X.509

Reviewer comments:
sorry about the trailing spaces ...
Some editorial things, content-wise I'm happy.

Revised text:
A signed response would be: <ins> 4.4. The two options for protecting the workload's traffic vary with respect to implementation complexity, extensibility and security. Here is a summary of the main differences between dpop-esque-auth and http-sig-auth. The DPoP-inspired solution is less HTTP-specific, making it easier to adapt for other protocols beyond HTTP.  This flexibility is particularly valuable for asynchronous communication scenarios, such as event-driven systems. Message Signatures, on the other hand, benefit from an existing HTTP specific RFC with some established implementations.  This existing groundwork means that this option could be simpler to deploy, to the extent such implementations are available and easily integrated. Given that the WIT (Workload Identity Token) is a type of JWT, the DPoP-inspired approach that also uses JWT is less complex and technology-intensive than Message Signatures.  In contrast, Message Signatures introduce additional layers of technology, potentially increasing the complexity of the overall system. Message Signatures offer superior integrity protection, particularly by mitigating message modification by middleboxes. A key advantage of Message Signatures is that they support response signing.  This opens up the possibility for future decisions about whether to make response signing mandatory, allowing for flexibility in the specification and/or in specific deployment scenarios. In general, Message Signatures provide greater flexibility compared to the DPoP-inspired approach.  The draft (and subsequent implementations) can decide whether specific aspects of message signing, such as coverage of particular fields, should be mandatory or optional.  Covering more fields will constrain the proof so it cannot be easily reused in another context, which is often a security improvement.  The DPoP inspired approach could be designed to include extensibility to sign other fields, but this would make it closer to trying to reinvent Message Signatures. </ins> 5. The WIMSE workload identity may be carried within an X.509
Original text:
"jti": A unique identifier for the token.  "ath": Hash of the OAuth access token, if present in the request, which might convey end-user identity and authorization context of the request.  The value, as per RFC9449, is the

Reviewer comments:
Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.

Revised text:
"jti": A unique identifier for the token. <ins> "wth": Hash of the Workload Identity Token, defined in to-wit. The value is the base64url encoding of the SHA-256 hash of the ASCII encoding of the token's value. </ins> "ath": Hash of the OAuth access token, if present in the request, which might convey end-user identity and authorization context of the request.  The value, as per RFC9449, is the
Original text:
WPTs with an expiration time unreasonably far in the future SHOULD be rejected.  Optionally, check that the value of the "jti" claim has not been used before in the time window in which the respective WPT would be considered valid.

Reviewer comments:
Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.

Revised text:
WPTs with an expiration time unreasonably far in the future SHOULD be rejected. <ins> The "wth" claim is present and matches the hash of the token value conveyed in the "Workload-Identity-Token" header. </ins> Optionally, check that the value of the "jti" claim has not been used before in the time window in which the respective WPT would be considered valid.
Original text:
URN Namespace for IETF Use [3] somehow.  Or maybe nothing.  Or maybe something else. <del> TODO: "tth" and maybe "oth" claim in JSON Web Token Claims Registry [4] </del>  7.1.

Reviewer comments:
Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.

Revised text:
URN Namespace for IETF Use [3] somehow.  Or maybe nothing.  Or maybe something else.  <ins> TODO: "tth", "wth" and maybe "oth" claim in JSON Web Token Claims Registry [4] </ins> 7.1.
Original text:
token issued to an OAuth 2.0 client running inside the workload by the second authorization server. <del> It is important to note that the workload does not use the Service Account Token with resource servers directly but instead obtains access tokens from this second authorization server.  To obtain these access tokens, the OAuth 2.0 client running in the workload uses the JWT client authentication grant, as defined in RFC7523, with the Service Account Token as input.  The obtained access token may be a bearer token, or a proof-of-possession token. fig-arch illustrates the interaction in the architecture graphically. </del> In recommendations we provide more details about how the content of the tokens and the offered security properties.

Reviewer comments:
Taking our last conversation into account I wanted to contribute my take on the problem and wrote the introduction the way I see it. This is not a version that can be merged, but the best way to show it in a diff and allow comments. Let me know what you think.

Revised text:
token issued to an OAuth 2.0 client running inside the workload by the second authorization server.  In recommendations we provide more details about how the content of the tokens and the offered security properties.
Original text:
Abstract This specification describes three CBOR data structures for primary <del> use in COSE envelopes.  A format for Merkle Tree Root Signatures with metadata, a format for Inclusions Paths, and a format for disclosure of a single hadh tree leaf payload (Merkle Tree Proofs). </del>  1.

Reviewer comments:
These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now

Revised text:
Abstract This specification describes three CBOR data structures for primary  <ins> use in COSE envelopes.  A CBOR encoding of Merkle Roots for use in COSE payloads.  A CBOR encoding of Inclusions Proofs for use in COSE unprotected headers.  A CBOR encoding of Consistency Proofs for use in COSE unprotected headers. </ins> 1.