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:
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.
AI Security & MCP, Stanford Research Fellow, WorkOS Agents Lead, Prev: MIT PhD, 🇦🇺 Fulbright Scholar
7moSuper 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.
Identity Standards Architect | Identity Expert | Conference Speaker | Standards Editor | OpenID Foundation Board Member | Inventor
8moUMA 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 :-)
Gluu Founder / CEO
8moCould 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.