What might an on-behalf-of token look like?

What might an on-behalf-of token look like?

In a previous Obtaining an on-behalf-of Authorization Token, I described a method for obtaining an on-behalf-of authorization token and some requirements for user approval/consent for such a token to be created. In this article I’d like to briefly describe what such a token could look like.

The key aspects of an on-behalf-of token are the actors involved in the delegated authorization, the relationships of those actors, the validity constraints of the issued token and the authorization conveyance enabled by the token.

Let’s go back to the use case from the previous article: Alice calls her financial institution’s customer care number in order to get help completing a transaction; say transferring funds between accounts. Alice is connected to customer care agent Bob who will help her complete the task. The customer care software Bob is using will need to obtain an on-behalf-of token so that Bob can act as Alice's fiduciary for this transaction.

If we break down the use case into it's component parts we get the following elements:

  • Actor: Alice - entity delegating authority to Bob
  • Actor: Bob - entity acting as the fiduciary of Alice
  • Relationship: Bob as the customer care agent for Alice
  • Constraints: short lived (60 secs)
  • Authorization: transfer funds from Checking account to Savings account


Using a JWT based access token structure (RFC 9068) we can represent these components as follows.

{
    "iss": "https://idp.example.com/",
    "sub": "<Alice>",
    "aud":   "https://rs.example.com/",
    "exp": 1618354150,
    "iat": 1618354090,
    "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
    "client_id": "s6BhdRkqt3",
    "authorization_details": [
        {
            "type": "funds_transfer",
            "locations": [
                "https://rs.example.com/transfer"
            ],
            "instructedAmount": {
                "currency": "EUR",
                "amount": "123.50"
            },
            "srcAccountName": "Checking",
            "srcAccount": {
                "bic":"ABCIDEFFXXX",
                "iban": "DE02100100109307118603"
            }
            "destAccountName": "Saving",
            "destAccount": {
                "bic":"ZGWEDFASEFS",
                "iban": "DE02100100109309420568"
            }
        }
    ]
    "act": {
        "sub": "<Bob>",
        "rel": "custCareAgent"
    }
}        

Note that the authorization_details claim comes from the Rich Authorization Request (RFC 9396) specification and the act claim comes from the Token Exchange (RFC 8693) specification.


Tobin South

AI Security & MCP, Stanford Research Fellow, WorkOS Agents Lead, Prev: MIT PhD, 🇦🇺 Fulbright Scholar

7mo

Super interesting and useful in an AI context.

Looking across this comment thread so far, it seems worth mentioning that when it comes to delegation to any entity that *can* have a fiduciary duty (human or legal entity), we need to get a lot more precise in our "delegation semantics" language (a la my "Level 1 vs. 2" comment perhaps). UMA allows that breadth because it's between such entities, but doesn't prescribe any particular answer. OAuth makes an implicit presumption that a client app is acting under the (unspecified level of) control of the resource owner. But an ordinary OAuth client is just a hunk of software that can't have "fiduciary duty", and the company that operates/published/hosts it isn't generally considered in the resource owner's trust model. If an AI agent is delegated to, someday it *might* gain human-like rights to take on fiduciary duty, though today it doesn't have those.

These delegation patterns is going to be very important when we get into the world of Agentic AI. We may already have most of the tools, but we do need to write down how to use them to ensure we establish the right patterns and have a chance for interoperability.

George Fletcher

Identity Standards Architect | Identity Expert | Conference Speaker | Standards Editor | OpenID Foundation Board Member | Inventor

8mo

UMA doesn’t address how to represent the on-behalf-of relationship in a token. Meaning Bob acting as a fiduciary of Alice. UMA does cover how Bob can access Alice’s resources as authorized by Alice. Regardless the “fiduciary” aspect of the relationship is “hidden” within the UMA Authorization Server. Pinging Eve Maler to correct any of the above :-)

Could this token be an OAuth Transaction Token, where the "purpose" is "delegated authorization" and the details are contained in the tctx claim of the TraT? Re-use of tokens is a good thing, because developers already have a huge cognitive load with a myriad of new tokens, each with contents that differ slightly.

To view or add a comment, sign in

More articles by George Fletcher

  • When Science Fiction becomes Reality

    This morning as I was preparing for the 41st addition of the Internet Identity Workshop, I started down this rabbit…

    2 Comments
  • Identifiers for Agentic AI

    I’ve seen many discussions regarding identifiers for Agentic AI when it comes to security, audit, compliance and…

    46 Comments
  • A Delegated Authorization Use Case

    This use case has come up in previous articles and posts, and I’d like to take a deeper look at what’s possible today…

    20 Comments
  • Is Federated Authorization a thing?

    While I don’t often hear these words combined, I do see work that could be classified this way. Take for instance the…

    14 Comments
  • Components of an on-behalf-of delegation pattern

    While at the OAuth Security Workshop (Feb 2025) and more recently the Internet Identity Workshop (April 2025), I had…

    29 Comments
  • Authentication or Authorization: Which comes first?

    I remember having this conversation with Ian Glazer at an European Identity and Cloud Conference a few years ago. We…

    24 Comments
  • Delegated Authentication

    We all know about Federated Authentication (more commonly known as Single-Sign-On [SSO])… so what is Delegated…

    15 Comments
  • Obtaining an On-Behalf-Of authorization token

    In this article I want to focus on what steps are required for a customer care system to obtain an on-behalf-of token…

    21 Comments
  • The importance of "Consent Receipts" in an AI Agent world

    In my last post on the topic of delegated authorization use cases, the comments brought up the use case of an AI Agent…

    11 Comments
  • Off to New Adventures!

    Today marks my last day at Capital One. The last 3 years have been rewarding, unexpected and challenging both…

    76 Comments

Explore content categories