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 for a user calling for help to complete a transaction. This is a follow up to a previous post where I was discussing the nuances of delegated authorization and the more specific on-behalf-of use case.

Let's start with a concrete use case. 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.

There are a couple of key concepts that must be present in such a flow:

• Transparency and explicit consent - Bob needs Alice to explicitly consent to allow him to complete the transaction on her behalf. Alice needs to clearly understand what authorization she is delegating to Bob and the limits of that authorization (in this case, to complete the funds transfer). The consent needs to be bound to the specific transaction and not a generic delegated authorization for all funds transfer.
• Prevent insider misuse - the system must protect against Bob being an "insider threat" and consenting on Alice's behalf to transaction she didn't request.
• Notification of activity - At the completion of the flow when the funds have been successfully transferred, a "receipt" of activity needs to be sent to Alice so that she has a record of what happened. Transparency through notification is another key aspect of this flow.

Next let's look at how to implement such a flow. This sequence diagram is not at the protocol step level but rather at the conceptual level of the flow. Another post can dig into what the actual "bits on the wire" might look like and what kinds of validation and processing are necessary. For now, I just want to propose a general flow that addresses the points above.

To address the issue of "transparency and explicit consent", the Identity Platform is the service that is communicating intent to Alice via a push message to the financial institution app on her phone. This push message can include the intent to transfer funds, the customer care agent she is talking to, etc along with a one-time-code that expresses Alice's explicit consent to allow Bob to transfer the money on her behalf.

Regarding "prevent insider misuse", Bob is completely unaware of the one-time-code provided to Alice by the Identity Platform. This means that Bob is dependent on Alice to provide the correct code in order for the transfer to be successful. The Identity Platform can associate other context with the issued one-time-code so that Bob can't change the intent when the customer care software asks for the on-behalf-of access_token.

Finally, "notification of activity", is accomplished through the receipt of funds transferred in step 14. This allows Alice to confirm that her request was carried out correctly.

Next Steps

What do you think of this proposal? Is it headed in the correct direction? What did I miss? What other variations of this flow are necessary for other on-behalf-of use cases? I look forward to continuing the conversation in the comments.