jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
text: Some of the most common include: TLS authentication of the server using X.509 certificates and <del> bearer token, encoded as JWTs. </del> <ins> client bearer token, encoded as JWTs. </ins> Mutual TLS authentication using X.509 certificate for both client and server.
Code change:
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.

Related discussion:
text: authorization by verifying that the authenticated identity has the appropriate permissions to access the requested resources and perform required actions.  This process involves evaluating the security <del> context described previously.  The workload validates security context, checks validity of permissions against its security policies to ensure that only authorized actions are allowed. </del> <ins> context described previously.  The workload validates the security context, and checks the validity of permissions against its security policies to ensure that only authorized actions are allowed. </ins> 3.2.4. <del> TBD. </del> <ins> When source workloads send authenticated requests to destination workloads, those destination workloads may rely on upstream dependencies to fulfill such requests.  Such access patterns are increasingly common in a microservices architecture.  While X.509 certificates can be used for point-to-point authentication, such services relying on upstream microservices for answers, may use delegation and/or impersonation semantics as described in RFC 8693 OAuth 2.0 Access Token Exchange. WIMSE credentials constrain the subjects and actors identified in delegation and impersonation tokens to be bound by TrustDomains, and to follow their issuing authorities' trust configurations.  Upstream workloads should consider the security context of delegation and/or impersonation tokens within and across Trust Domains, when arriving at authorization decisions. </ins> 3.2.5. <del> TBD. </del> <ins> Source workloads may send authenticated asynchronous and batch requests to destination workloads.  A destination workload may need to fulfill such requests with requests to authorized upstream protected resources and workloads, after the source workload credentials have expired.  Credentials identifying the original source workload as subject may need to be obtained from the credential issuing authority with appropriately-downscoped context needed access to upstream workloads.  These credentials should identify the workload as the actor in the actor chain, but may also identify other principals that the action is taken on behalf.  To mitigate risks associated with long-duration credentials, these credentials should be bound to the workload identity credential such as an X.509 certificate or Workload Identity Token (WIT) of the acting service performing asynchronous computation on the source workload's behalf. </ins> 3.2.6.
Code change:
[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

Related discussion:
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 <del> typing JWTs) in Media Types [3]. </del> <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
Code change:
[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

Related discussion:
text: [2] https://www.iana.org/assignments/params/params.xhtml <del> [3] https://www.iana.org/assignments/media-types/media-types.xhtml </del> <ins> [3] https://www.iana.org/assignments/jwt/jwt.xhtml [4] https://www.iana.org/assignments/media-types/media-types.xhtml </ins>
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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
Code change:
Change trust root to trust anchor, to align with Trust Anchor terminology as used in rfc5280.
sure

Related discussion:
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> <ins> tied to an authorized issuer cryptographic trust anchor through some </ins> 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> <ins> of an issuer, trust domain and a cryptographic trust anchor MUST be </ins> communicated securely out of band. 6.2.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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 <del> MAY then further use the WIMSE identity in applying authorization </del> <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 <del> the client MUST match the WIMSE identity in the certificate against </del> <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 <del> portion of the WIMSE identity in a deployment specific way. </del> <ins> portion of the WIMSE identifier in a deployment specific way. </ins> 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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
sorry about the trailing spaces ...
Some editorial things, content-wise I'm happy.

Related discussion:
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
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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.
Code change:
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.

Related discussion:
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> <ins> TODO: "tth", "wth" and maybe "oth" claim in JSON Web Token Claims Registry [4] </ins> 7.1.
Code change:
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.

Related discussion:
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.
Code change:
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

Related discussion:
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> <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.
Code change:
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

Related discussion:
text: inclusion proof which increases the size of multiple payload signed inclusion proofs. <ins> Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. </ins> 6. <del> TBD </del> <ins> See the privacy considerations section of: </ins> 6.1.
Code change:
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

Related discussion:
text: 7.1.1. <del> IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point. </del> <ins> This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Algorithm Parameters' registries in the 'Standards Action With Expert Review category. 7.1.1.1. </ins> Name: tree_alg <del> Label: TBD </del> <ins> Label: TBD_1 </ins> Value type: tree_alg