Implementation Status of OAuth Identity Chaining and Transaction Tokens

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. They appear here only within quoted proposed text addressed to the editors of the parent drafts. This document itself is descriptive (Informational) and imposes no normative requirements.¶

2. Introduction

This document reports the implementation status of two Working Group drafts of the OAuth Working Group at the IETF, prepared in accordance with the guidelines in RFC 7942 ("Improving Awareness of Running Code: The Implementation Status Section"). The two reported drafts are identified in Section 3.¶

The intent of this report is to provide the editors of the two parent drafts with material that can, at the editors' discretion, be incorporated into the parent draft as an Implementation Status section, used to inform Working Group Last Call discussions, or otherwise referenced during progression of the parent drafts to RFC.¶

The implementation reported in this document is in production deployment under the name "authgent" (see Section 4), and is offered as an interoperability partner for any other implementation of either parent draft.¶

3. Reported Drafts

This document reports the implementation status of:¶

1. The Internet-Draft "OAuth Identity and Authorization Chaining Across Domains," version -14 ([I-D.ietf-oauth-identity-chaining]). At the time of writing, this draft has been approved by the IESG with a request for a revised Internet-Draft.¶

2. The Internet-Draft "Transaction Tokens," version -08 ([I-D.ietf-oauth-transaction-tokens]). At the time of writing, this draft is in Working Group Last Call.¶

Subsequent revisions of either parent draft may necessitate revision of this report.¶

4. Implementation: authgent

This section provides per-implementation metadata in the format recommended by Section 2 of RFC 7942.¶

Organisation:

Independent. Author of record: Dhruv Agnihotri.¶

Name and URL:

authgent (https://github.com/authgent/authgent).¶

Description:

An open-source OAuth 2.1 authorisation server implemented in Python, with both cross-domain identity chaining (per the first reported draft) and transaction-token issuance (per the second reported draft) as first-class flows on the token endpoint.¶

Maturity:

Production. The implementation is published as the authgent-server distribution on PyPI and as the authgent distribution on PyPI and npm. Continuous-integration test surface: 476 tests with 83 percent line coverage as of the date of this document. A live demo deployment of the implementation is published via the repository above.¶

Coverage:

All normative sections of both reported drafts that this implementation could realistically exercise from a single-organisation test harness. See Section 5 and Section 6 for per-section detail. One open issue per draft is recorded in Section 7.¶

Version compatibility:

identity-chaining: tracks revision -14. transaction-tokens: tracks revision -08.¶

Licensing:

Apache License, Version 2.0.¶

Implementation experience:

Roughly six months of implementation effort by a single author. No unworkable spec text was encountered; the open issues recorded in Section 7 were resolved by local interpretation but interop testing has not yet been performed against a second implementation.¶

Contact:

dagni@umich.edu.¶

Last updated:

The date of this Internet-Draft.¶

5. Coverage of identity-chaining-14

This section maps each normative requirement of [I-D.ietf-oauth-identity-chaining] to the source location in the authgent implementation that fulfils it. Source paths are relative to the repository root.¶

Section 2.1 (Overview / sequence):

Implemented across two functions in services/token_service.py: _issue_chaining_grant (Domain A) and _handle_jwt_bearer (Domain B).¶

Section 2.2 (Discovery via Protected Resource Metadata):

Discovery is served by endpoints/wellknown.py, conforming to [RFC9728].¶

Section 2.3.1 (Token Exchange request):

_handle_token_exchange in services/token_service.py branches on requested_token_type=urn:ietf:params:oauth:token-type:jwt.¶

Section 2.3.1 (audience or resource REQUIRED):

Enforced. The token endpoint raises an error of type InvalidRequest when neither parameter is present.¶

Section 2.3.2 (policy and claims transformation):

Trust-domain policy is applied via a configurable trusted_chaining_targets allowlist. Claim transformation is delegated to services/claims_transcription.py, which exposes a pluggable Protocol so that operators can provide their own transformation policy without modifying core code.¶

Section 2.3.3 (aud MUST identify Domain B):

The audience claim of the issued JWT authorisation grant is populated from the audience_target derived from the inbound audience or resource parameter.¶

Section 2.4.1 (urn:ietf:params:oauth:grant-type:jwt-bearer):

The grant type is recognised by the token endpoint and dispatched to _handle_jwt_bearer.¶

Section 2.4.2 (assertion validation per RFC 7523):

Implemented in services/chaining_verifier.py function verify_assertion, which applies the validation steps of Sections 3 and 3.1 of [RFC7523].¶

Section 2.5 (claims transcription):

services/claims_transcription.py ships two transformation policies: preserve_sub (default), which copies the parent sub through; and minimize, which carries only idp_iss and idp_sub. See Section 7.1 for an interpretation question encountered while implementing this section.¶

Section 3 (metadata field

¶

identity_chaining_requested_token_types_supported):

Advertised by endpoints/wellknown.py, conforming to [RFC8414].¶

Section 5.1 (client authentication):

Inherited from the OAuth 2.1 framework support in the implementation. Both client_secret_post and client_secret_basic are supported.¶

Section 5.2 (sender constraining via DPoP):

When the inbound subject token is DPoP-bound, the cnf.jkt thumbprint is propagated into the Domain-B access token, in conformance with [RFC9449].¶

Section 5.3 (authorised use of subject_token):

Revocation is checked via verify_and_check_blocklist before any Domain-B token is minted.¶

Section 5.4 (no refresh tokens for chaining):

The _handle_jwt_bearer function omits refresh-token issuance, matching the spec recommendation.¶

Section 5.5 (short-lived; single-use):

The chaining grant time-to-live (parameter chaining_grant_ttl) defaults to 60 seconds. The jti claim of each consumed assertion is added to the token blocklist with reason chaining_grant_consumed, and any subsequent attempt to consume the same assertion is rejected.¶

Test surface for identity-chaining: server/tests/test_identity_chaining.py, 17 tests, named after the spec sections they exercise.¶

6. Coverage of transaction-tokens-08

Section 3 (token type URN):

The constant TXN_TOKEN_TYPE is the value urn:ietf:params:oauth:token-type:txn_token.¶

Section 3 (typ header txntoken+jwt):

The signing helper sets the JWT header typ field via _jwks.sign_jwt(claims, headers={"typ": "txntoken+jwt"}).¶

Section 3 (required claims):

The claims iat, aud, exp, txn, sub, scope, and req_wl are constructed in _issue_transaction_token for every issued Txn-Token.¶

Section 3 (optional tctx, immutable transaction context):

Carried verbatim from the request_details form parameter on the token endpoint when present.¶

Section 3 (optional rctx, requester context):

Composed in _issue_transaction_token with auto-derived req_ip and authn values.¶

Section 3 (response shape):

issued_token_type is set to the value urn:ietf:params:oauth:token-type:txn_token; token_type is set to N_A.¶

Section 7 (short-lived tokens):

The Txn-Token time-to-live (parameter txn_token_ttl) defaults to 120 seconds.¶

Section 7.2 (scope MUST NOT exceed subject_token):

An inline subset check (requested.issubset(parent_scopes)) is applied before issuance; on violation, the implementation raises an AccessDenied error.¶

Section 11 (no refresh tokens):

The token-endpoint response omits the refresh_token field for Txn-Token issuance.¶

Test surface for transaction-tokens: server/tests/test_transaction_tokens.py, 8 tests.¶

7. Open Issues Surfaced During Implementation

This section records ambiguities encountered while implementing the two parent drafts, and proposes specific text the editors may wish to consider for a subsequent revision.¶

8. Implementation Status

This section records the status of known implementations of the protocols defined by [I-D.ietf-oauth-identity-chaining] and [I-D.ietf-oauth-transaction-tokens] at the time of posting of this Internet-Draft, in accordance with the guidelines in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

The single implementation reported here is described in Section 4, with per-section conformance maps in Section 5 and Section 6, and open-issue candidates in Section 7.¶

Note to RFC Editor: this section, and the per-section conformance maps referenced from it, are to be removed before publication of any parent draft as an RFC. The reference to RFC 7942 may also be removed at that time.¶

9. Interoperability Offer

The implementer offers interoperability testing against any other implementation of either parent draft. Interested implementers may make contact at the address in the front matter of this document, or by opening an issue on the GitHub repository identified in Section 4.¶

10. IANA Considerations

This document has no IANA actions.¶

11. Security Considerations

This document reports the existence of an implementation. The security considerations of the protocols implemented are addressed in the parent specifications: [I-D.ietf-oauth-identity-chaining], Section 5; and [I-D.ietf-oauth-transaction-tokens], Section 11. Implementers and reviewers are referred there.¶

The authgent implementation reported here is open source. Security properties relevant to the parent drafts (in particular, sender constraining of access tokens via DPoP [RFC9449], blocklist-backed revocation, single-use semantics for the JWT authorisation grant, and scope-reduction enforcement on Txn-Tokens) may be inspected in the repository identified in Section 4.¶

12. References

Appendix A. Acknowledgments

The author thanks the editors of [I-D.ietf-oauth-identity-chaining] (Arndt Schwenkschuster of Defakto Security, Pieter Kasselman of Defakto Security, Kelley Burgin of MITRE, Michael Jenkins of NSA-CCSS, Brian Campbell of Ping Identity, and Aaron Parecki of Okta) and the editors of [I-D.ietf-oauth-transaction-tokens] (Atul Tulshibagwale of CrowdStrike, George Fletcher of Practical Identity LLC, and Pieter Kasselman of Defakto Security) for the specifications this document reports on.¶

Author's Address