Network Working Group S. Shankarlingam Internet-Draft HexaEight Intended status: Standards Track 20 October 2026 Expires: 23 April 2027 Linking an Agent's DNS Name to its OAuth Client draft-shankarlingam-oauth-agent-dns-link-00 Abstract Software agents increasingly call agents and services operated by other organizations. A receiving organization often wants to know two things about any such caller: that it is the agent it claims to be, and that the organization operating it still authorizes it. Existing approaches to the second question require a trust relationship between the two organizations' authorization servers. This document defines a DNS record by which the owner of a domain links an agent's DNS name to the OAuth client that the agent uses at the owner's own authorization server. The sending agent presents a fresh access token for that client; the receiver verifies the token against the record and against the issuer's published keys. No trust relationship, registration or federation between the two organizations is needed, and disabling the client at the sending organization's authorization server stops the agent being accepted by every receiver. 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 23 April 2027. Shankarlingam Expires 23 April 2027 [Page 1] Internet-Draft Agent DNS-OAuth Link October 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Establishing the Sender's Name . . . . . . . . . . . . . . . 5 3.1. Channel Mode . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Sender-Constrained Mode . . . . . . . . . . . . . . . . . 6 4. The Link Record . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . 7 5. The Link Token . . . . . . . . . . . . . . . . . . . . . . . 7 6. Sender Procedure . . . . . . . . . . . . . . . . . . . . . . 8 7. Receiver Procedure . . . . . . . . . . . . . . . . . . . . . 8 7.1. Once Linked, Always Linked . . . . . . . . . . . . . . . 9 7.2. Freshness and Revocation . . . . . . . . . . . . . . . . 10 7.3. Authorization Policy . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.1. Token Replay . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Misuse by the Receiver . . . . . . . . . . . . . . . . . 11 8.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.4. Authorization Server Compromise . . . . . . . . . . . . . 11 8.5. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . 11 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 11.1. HexaEight Agent . . . . . . . . . . . . . . . . . . . . 12 12. Relationship to Other Work . . . . . . . . . . . . . . . . . 13 13. Normative References . . . . . . . . . . . . . . . . . . . . 13 14. Informative References . . . . . . . . . . . . . . . . . . . 14 Shankarlingam Expires 23 April 2027 [Page 2] Internet-Draft Agent DNS-OAuth Link October 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction An agent operated by organization A (for example agent01.a.example) calls an agent or service operated by organization B. Before answering, B wants assurance that: 1. the caller is agent01.a.example, and 2. organization A still authorizes agent01.a.example to act. Question 1 is answered by whatever mechanism authenticates the caller: an authenticated channel, a client certificate, a sender- constrained token, or an agent identity system. Question 2 is usually answered inside one organization by its authorization server: when an administrator disables a client, that client can no longer obtain tokens. Across organizations, question 2 is harder. OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining], OpenID Federation [OpenID.Federation] and cloud workload identity federation all work, but each requires the receiving side's authorization server or trust anchor to be configured to trust the sending side's, pair by pair or through a shared anchor. For agents that call many partners, this setup does not scale, and in practice organizations fall back to long-lived API keys that are not disabled when the agent is. This document takes a narrower approach. The sending organization publishes, in DNS under the agent's name, which issuer and client identifier the agent uses. With every call the agent presents a short-lived access token issued to that client. Any receiver can check the token using only public information: the DNS record and the issuer's published signing keys. The receiver does not need to trust the sender's authorization server for anything beyond a signed statement that it recently issued a token to the named client. The token grants nothing. It is issued for a dedicated audience that no resource server accepts, and serves only as evidence that the client is still active. The receiver continues to make its own access decisions. 1.1. Goals * Link an agent's DNS name to an existing OAuth client with no change at any authorization server and no per-partner configuration. Shankarlingam Expires 23 April 2027 [Page 3] Internet-Draft Agent DNS-OAuth Link October 2026 * Give the operating organization a single control (disabling the client) that takes effect at every receiver. * Let any receiver verify the link without prior contact with the sender. * Prevent a linked agent from evading the check by omitting the token. 1.2. Non-goals * Authenticating the agent's name. That is the job of the channel or of a sender-constrained token (Section 3). * Granting access. The token carries no permissions; the receiver applies its own authorization policy. * Conveying the identity of users on whose behalf the agent acts. 1.3. Requirements Language 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. 1.4. Terminology Agent name: A DNS name identifying an agent, for example agent01.a.example. Sender: The agent that makes a call and presents a link token. Receiver: The agent or service that receives the call and verifies the link. Link record: The DNS TXT record defined in Section 4. Link token: An access token as described in Section 5. Linked agent: An agent name for which a valid link record exists. Authenticated sender name: The agent name of the sender as established by the receiver through a mechanism outside this document (Section 3). Shankarlingam Expires 23 April 2027 [Page 4] Internet-Draft Agent DNS-OAuth Link October 2026 2. Overview Organization A Organization B +---------------+ (1) client credentials | Authorization |<------------+ | Server (iss) |-----------+ | +---------------+ (2) token | | ^ v | | +------------+ (3) call + token +----------+ | | Sender |----------------->| Receiver | | | agent01... | +----------+ | +------------+ | | | (5) issuer metadata + JWKS (public) | | +---------------------------------------------+ | | DNS: _agent-oauth.agent01.a.example TXT (4) lookup <------+ "v=agent-oauth1; iss=...; client_id=...; aud=..." 1. The sender authenticates to its own authorization server as an OAuth client (for example with the client credentials grant, Section 4.4 of [RFC6749]). 2. It receives a link token for a dedicated audience. 3. It presents the token with each call to a receiver. 4. The receiver looks up the link record for the sender's agent name. 5. The receiver verifies the token's signature using the issuer's published keys, and checks that issuer, client identifier and audience match the record. 3. Establishing the Sender's Name This document links an agent name to an OAuth client. It relies on the receiver already knowing, or being able to establish, the sender's agent name. Two modes are defined. 3.1. Channel Mode The receiver obtains the authenticated sender name from the channel over which the call arrives. Examples include an end-to-end authenticated and encrypted channel provided by an agent identity system, or mutual TLS with a certificate whose subject alternative name is the agent name. Shankarlingam Expires 23 April 2027 [Page 5] Internet-Draft Agent DNS-OAuth Link October 2026 In channel mode, the link token MUST be carried inside the protected channel so that it is not exposed to intermediaries, and the channel MUST bind the token to the authenticated sender name (that is, an intermediary cannot move a token from one sender's messages to another's). 3.2. Sender-Constrained Mode The sender states its agent name in the request, and presents a link token that is sender-constrained, for example with DPoP [RFC9449] or mutual-TLS certificate-bound tokens [RFC8705]. The receiver verifies the sender-constraint as specified for that mechanism, then verifies the link as described in Section 7, using the stated agent name. In this mode the agent name is established by the link itself: the receiver learns that the caller holds the key bound to a token issued to the client that the domain owner has published for that name. The strength of the name binding is therefore that of the DNS lookup (Section 8.3). Because a forged DNS answer would let an attacker impersonate the agent entirely, sender-constrained mode SHOULD NOT be used unless the receiver validates the link record with DNSSEC. A receiver MUST NOT accept a link token that is neither carried in channel mode nor sender-constrained, because a bearer token could be replayed by anyone who obtains it. 4. The Link Record 4.1. Location The link record is a DNS TXT record [RFC1035] at the underscored name _agent-oauth beneath the agent name [RFC8552]: _agent-oauth.agent01.a.example. IN TXT ( "v=agent-oauth1; iss=https://login.a.example/; " "client_id=7f3c2a90-1b4e-4c55-9d1a-2e6f8b0c4d11; " "aud=api://agent-proof" ) 4.2. Syntax link-record = version *( ";" *SP field ) [";"] version = "v=agent-oauth1" field = key "=" value key = "iss" / "client_id" / "aud" / ext-key ext-key = 1*( ALPHA / DIGIT / "_" / "-" ) value = 1*( %x21-3A / %x3C-7E ) ; printable, no ";" or space Shankarlingam Expires 23 April 2027 [Page 6] Internet-Draft Agent DNS-OAuth Link October 2026 A TXT record consisting of several character-strings is concatenated before parsing. Fields: iss (REQUIRED): The issuer identifier of the authorization server, exactly as it appears in the iss claim of tokens it issues. client_id (REQUIRED): The client identifier of the agent's OAuth client at that issuer. aud (REQUIRED): The audience value for which link tokens are issued (Section 5). Receivers MUST ignore unknown keys. TXT records at the same name that do not begin with v=agent-oauth1 MUST be ignored. 4.3. Validity The record is valid if exactly one TXT record at the name begins with v=agent-oauth1 and it contains each required field exactly once. If more than one such record exists, or a required field is missing or repeated, the agent name MUST be treated as linked with an invalid record, and calls from it MUST be refused (Section 7). Publishing an invalid record therefore fails closed. The domain owner SHOULD sign the zone with DNSSEC [RFC4033]. Receivers SHOULD validate DNSSEC when it is available. 5. The Link Token A link token is a JWT access token [RFC9068] issued by the authorization server named in iss to the client named in client_id. In addition to the requirements of [RFC9068]: * The aud claim MUST contain the value published in the record. That audience MUST be dedicated to this purpose: it MUST NOT be an audience accepted by any resource server. * The token MUST NOT grant anything. It MUST NOT carry roles, permissions or entitlements, and MUST NOT carry scopes other than at most one scope that the issuer defines for this purpose and that no resource server accepts. * The token MUST identify the client. [RFC9068] uses the client_id claim, and receivers MUST use it when it is present. As a compatibility allowance for widely deployed issuers that do not follow [RFC9068] in this respect, a receiver MAY instead use another claim that the issuer documents as identifying the client (for example azp, appid or cid), but only when client_id is absent Shankarlingam Expires 23 April 2027 [Page 7] Internet-Draft Agent DNS-OAuth Link October 2026 and only one such claim is present. Receivers that differ in which claims they allow may reach different results for the same token; issuers that conform to [RFC9068] avoid this. The sender MUST inspect each link token before using it and MUST NOT present a token that fails these requirements. This protects the sender's organization if its client is misconfigured: a token that granted access to the sender's own resources would otherwise be handed to every receiver. 6. Sender Procedure 1. Obtain a link token from the issuer for the configured audience. 2. Inspect it as described in Section 5; if it grants anything, do not use it and report the misconfiguration to the operator. 3. Cache the token and present it with every call to a receiver, renewing it before it reaches the receiver's maximum age (Section 7.2). 4. A linked agent that cannot obtain a valid link token is in a failed state, and SHOULD report it to its operator. Calling without a link token is not a fallback: receivers that perform the checks in this document refuse such calls. A sender MAY still attempt a call, for example for diagnostics, but it MUST NOT treat calling without a token as an alternative way to operate. A sender MAY be configured not to present link tokens to particular receivers. Receivers that perform the checks in this document will refuse such calls. 7. Receiver Procedure For each incoming call: 1. Establish the sender's agent name (Section 3). 2. Look up the link record for that name. * No record: the sender is not linked. The receiver proceeds with its normal policy, except as described in Section 7.1. * Invalid record: refuse. * Valid record: a link token is REQUIRED; continue. Shankarlingam Expires 23 April 2027 [Page 8] Internet-Draft Agent DNS-OAuth Link October 2026 3. If no link token is present, refuse. 4. Obtain the issuer's metadata using [RFC8414] or [OIDC.Discovery] at the iss value from the record, and its JSON Web Key Set [RFC7517]. Metadata and keys MAY be cached according to HTTP caching rules. 5. Verify the token's signature with those keys, and verify that: * iss equals the record's iss; * the client identifier equals the record's client_id; * aud contains the record's aud; * the token has not expired, and iat is not older than the receiver's maximum age (Section 7.2); * the token grants nothing (Section 5). 6. In sender-constrained mode, verify the sender-constraint. 7. Remove the link token from the request before passing it to any other component, log or model. 8. Apply the receiver's authorization policy (Section 7.3). Any failure MUST result in refusal. A receiver SHOULD record each verification result, including the agent name and client identifier, in its audit log. 7.1. Once Linked, Always Linked If an attacker can cause a receiver's DNS lookup to fail, an agent that is normally linked could appear unlinked, and a call without a token could be accepted. A receiver that has once seen a valid link record for an agent name SHOULD continue to require a link token from that name until it observes, through a successful (and, where available, DNSSEC-validated) lookup, that the record has been removed. Shankarlingam Expires 23 April 2027 [Page 9] Internet-Draft Agent DNS-OAuth Link October 2026 7.2. Freshness and Revocation When the operator disables the client at its authorization server, no new link tokens are issued, but tokens already issued remain valid until they expire. Receivers bound this window with a maximum age measured from iat. The effective revocation delay is at most the smaller of the token lifetime and the receiver's maximum age, plus the DNS and key caching periods. A maximum age of 120 minutes or less is RECOMMENDED as a general default. Deployments in which an agent's actions take effect quickly, such as payments, trading or automated changes to production systems, SHOULD use a much shorter maximum age (for example 5 to 15 minutes) chosen from their own threat model; senders then renew correspondingly more often, subject to the issuer's rate limits. A receiver MAY apply different maximum ages to different senders or operations. Removing the link record does not revoke the agent at receivers that apply Section 7.1; it only stops new receivers from requiring a token. Disabling the client is the revocation mechanism. 7.3. Authorization Policy Verifying the link establishes that the operator still authorizes the agent. It does not decide what the agent may do. Receivers SHOULD express policy for linked agents in terms of both the agent name and the client identifier, and a policy entry that matches any agent name (a bare wildcard) SHOULD NOT by itself admit a linked agent. 8. Security Considerations 8.1. Token Replay A link token is evidence, not a credential, but a stolen token could be replayed to another receiver by an attacker claiming the sender's name. Channel mode prevents this by keeping the token inside a channel bound to the authenticated sender; sender-constrained mode prevents it by binding the token to a key. Bearer link tokens outside either mode MUST NOT be accepted (Section 3). Shankarlingam Expires 23 April 2027 [Page 10] Internet-Draft Agent DNS-OAuth Link October 2026 8.2. Misuse by the Receiver Every receiver sees the sender's link tokens. If the token's audience were a real resource server, each receiver would hold a working credential for it. The requirements that the audience be dedicated and that the token grant nothing (Section 5), and the sender's duty to refuse such tokens, address this. A receiver that forwards a link token to a third party claiming to be the sender fails at the third party: in channel mode the channel authenticates the receiver, not the sender; in sender-constrained mode the receiver lacks the sender's key. 8.3. DNS The link record is only as trustworthy as the DNS answer. Without DNSSEC, an on-path attacker could forge or suppress the record. Forging it lets the attacker name a client it controls; this matters most in sender-constrained mode, where the record also establishes the name. Suppressing it can downgrade a linked agent to unlinked; Section 7.1 limits this. Receivers SHOULD use a validating resolver and short cache lifetimes. 8.4. Authorization Server Compromise A compromised issuer can mint link tokens for its clients. This affects only agents linked to that issuer, which are operated by the same organization that operates the issuer. 8.5. Clock Skew Receivers SHOULD allow a small tolerance on exp and iat. 9. Privacy Considerations The link record discloses the issuer and client identifier used by an agent. Neither is secret, but together they reveal which authorization server an organization uses. Link tokens may contain other claims about the client; senders SHOULD use clients whose tokens carry no information beyond what this document requires. The mechanism conveys no information about end users. 10. IANA Considerations IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]: Shankarlingam Expires 23 April 2027 [Page 11] Internet-Draft Agent DNS-OAuth Link October 2026 +=========+==============+=================+ | RR Type | _NODE NAME | Reference | +=========+==============+=================+ | TXT | _agent-oauth | (this document) | +---------+--------------+-----------------+ Table 1 11. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described 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". 11.1. HexaEight Agent Organization: HexaEight Description: An agent runtime that implements the link in channel mode. The sender's name is established by the HexaEight agent identity channel, which authenticates and encrypts each message end to end; the link token travels inside the encrypted message. Implements the sender's inspection of tokens that grant anything, the receiver checks, once-linked-always-linked, a configurable maximum age (default 120 minutes), removal of the token before logging, and policy rules naming agent and client identifier. Differences from this document: The deployed record uses the prefix hexaeight-oauth=v1 at the agent name itself rather than v=agent- oauth1 at _agent-oauth. Sender-constrained mode is not implemented. Shankarlingam Expires 23 April 2027 [Page 12] Internet-Draft Agent DNS-OAuth Link October 2026 Maturity: Implemented. Interoperability testing between independently operated organizations is in progress. Licensing: Commercial. Documentation: https://www.hexaeight.com/docs/concepts/oauth/ (https://www.hexaeight.com/docs/concepts/oauth/) 12. Relationship to Other Work OAuth Identity and Authorization Chaining [I-D.ietf-oauth-identity-chaining] and OpenID Federation [OpenID.Federation] let a receiving domain issue or accept tokens based on a configured trust relationship with the sending domain. This document needs no such relationship; in exchange, the token it conveys grants nothing and the receiver keeps all access decisions. The OAuth Client ID Metadata Document [I-D.ietf-oauth-client-id-metadata-document] identifies a client by a URL. The two are complementary: this document links an agent name to a client at the agent operator's own issuer. HTTP Message Signatures [RFC9421] and the work built on them for automated clients identify the operator of a client by a key published under its domain. They do not convey whether the operator's own authorization server still authorizes the client. The WIMSE working group's guidance on authenticating AI agents [I-D.ietf-wimse-aims] describes building agent authentication on existing OAuth specifications; this document is offered as one such building block for calls across organizations. 13. Normative References [OIDC.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", 2014. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Shankarlingam Expires 23 April 2027 [Page 13] Internet-Draft Agent DNS-OAuth Link October 2026 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . 14. Informative References [I-D.ietf-oauth-client-id-metadata-document] Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf- oauth-client-id-metadata-document-02, 6 July 2026, . [I-D.ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, . Shankarlingam Expires 23 April 2027 [Page 14] Internet-Draft Agent DNS-OAuth Link October 2026 [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [OpenID.Federation] OpenID Foundation, "OpenID Federation 1.0", 2026. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . Author's Address Sriram Shankarlingam HexaEight Email: sriram.s@hexaeight.com Shankarlingam Expires 23 April 2027 [Page 15]