Delegated Authorization for Relationships [Intermediate]

Thank you all for coming. If you were here for the last session, this is going to be quite different. My name is George Fletcher. I'm an Identity Standards Architect at Practical Identity LLC. I've spent the last 20 years doing identity standards and helped on the definitions of OpenID2, OAuth1, OAuth2, all of these things. And also spent those last 20 years doing identity architecture for SIAM deployments, a major media company and a financial institution. So that's a bit of my background. Also happen to be a photographer, so this particular picture is from EIC 2022.

So we live in a delegated-oriented world, and our authorization standards were built for a simpler one. And if you think about it, OAuth as a protocol was really about how do I, as a human, share a resource with a client. And that's pretty much it. Delegated authorization is all over, as you'll see in a minute. So this talk is really about a mental model that I've been working on and would love input on around how do we think about delegated authorization, what are its subcomponents, and how do we then potentially enable digitization of complex delegated problems.

So you have a couple of them here, like how do you deal with a power of attorney case or cross an organizational trust boundary? We don't have good ways of doing this. What are the bits and pieces we need to enable these kinds of use cases? So to start with, I'm going to define what I mean by delegated authorization for the context of this particular talk, because words are important and we all have slightly different definitions of what we mean.

So in this particular case, delegated authorization is the act by which a principal authorizes another party, actor or agent, to act on the principal's stead, exercising a subset of the principal's rights to complete specific tasks. And I want to separate this a little bit from what some may call delegated access, which I think is more of a sharing perspective on delegated authorization, where you're looking at what can someone else do with a resource. This is more the inline, I want to perform some action, what delegation is necessary for that action to occur.

So let's go do some use cases, simple to more complex. We already talked about the OAuth1, well supported by standards. We're in a pretty good place. User-managed access came along, and it talked a lot about delegated access and a lot of the kinds of things that you need to think about from delegated authorization, but the logic and the structures for understanding that were all buried in the UMA authorization server. So there was no protocol mechanisms that sort of described what's happening in the delegated authorization. It was all buried inside the UMA authorization server.

So I could tell Justin he could visit my vacation photos, and I could say that you can only visit them if you agree to not download them, not sell them, not print them. So that kind of additional constraints around the sharing access, but again, not based in the protocol bits itself. Then we have what has been a classic on behalf of use case. Alice calls customer care, talks to Bob the agent, and Bob needs to do something on Alice's behalf.

And we have solved this problem multiple times, and I suspect if I asked for a raise of hands, how many people have solved this problem in your IAM deployment, I would get a lot of hands raised. And I suspect that every one of your implementations would be different. And that's largely because the only constraint or the only mechanism we have in standards today is this thing called the ACT claim defined in RFC 8693 or OAuth token exchange, which was brilliantly put there, forward thinking, but without a lot of specification. So there's no sort of standard way to do this.

Now, I will say within the last three weeks, there has been an individual profile proposed to the IETF called the OAuth actor profile by Carl McGinnis that is trying to put some structure and standards around how to use the ACT claim for these kinds of delegated authorization use cases. And then finally, I just picked up power of attorney here, but you could click health care power of attorney.

I'm one of the people participating in the death in the digital estate community group of the OpenID Foundation, and having experienced the loss of people, important people in my life, there's a lot of delegated authorization use cases in that space as well. How do I get access to the medical site, which is sending me subscriptions that my wife set up?

Today, the only mechanism I have is what's called benevolent impersonation, or at least what I call benevolent impersonation, i.e., I have her credentials and I can log in. So this is an important use case. There is work in the EKYC and IDA working group with a draft called the authority draft that defines claims for how to represent some of these authority mechanisms. But it's really focused from a relying party perspective. How does the relying party get this information out of the IDP as opposed to how do I present that information in the context of some task I'm wanting to complete? Okay.

So if you notice, those first four use cases had nothing to do with AI, right? I will throw one use case in here for a different reason, but the point of that really is AI is a forcing function that's driving, that's sort of illuminating gaps in standards. Carl and I did another sort of identity office hours podcast you can find on LinkedIn talking about gaps in standards. But there's a whole ton of gaps that AI is a forcing function for illuminating. Delegated authorization is just one of them.

In this particular travel use case, right, I wanted to book a trip to see someone in concert in a town that was within driving distance of where I live. Turns out in this particular case, I live in northern Virginia. The person I was going to see was a country artist, and I didn't really want to see the country artist in non-country country. So I drove to Knoxville, Tennessee. And I realize that that has very little reference for people that are not familiar with U.S. territories, but just think it was a seven-hour trip, driving trip, so that I was in the right spot. I needed to book a hotel.

I needed to book the concert. I needed to potentially make a restaurant reservation. I wanted the hotel to be within walking distance of the concert venue because I really hate dealing with long lines in parking lots, and I'd way rather walk even if that's a kilometer or two. If you think about this in this use case, how do you handle the delegation of this is what I want you to do? How do you manage that from an attenuation perspective across these different trust domains? What does it mean from a privacy perspective, right?

Because all of this stuff is really private information about what I'm doing, right? Where does that come into play? If the orchestrator agent needs to go through three workloads in order to get the orchestration done, and then it crosses a trust boundary to the hotel agent, how much of that internal stuff should or shouldn't be leaked to the hotel agent because it doesn't really care? What do you do about audit and tracking of the transaction across all of these different trust domains?

So there's a bunch of important problems here, and I think it's a useful use case to sort of highlight where we have issues from a standards perspective. So having, like I said, worked in standards for the last 20 years, I do a little bit feel like we, the standards people, dropped the ball on delegated authorization, and now if you heard any of the keynotes this morning or any of the other talks touching on authorization, everybody's doing a whole bunch of different things trying to fill this gap that exists. So what are some of the things that are missing?

We already talked about Bob on behalf of Alice, that we don't have a good way to do that. But what about Bob acting for the benefit of Alice, and what does that look like? How do you sort of represent that? Could be a trustee or guardian, potentially even a financial advisor that's doing things on your behalf, but they're not really, like, trying to do them as George. They're doing them as your financial advisor, but it's for George.

Personas, there's interesting work with Glyph and the VLEI work that's ongoing, but that just sort of establishes the fact that George may be the CFO of some organization. It doesn't really touch on authority issues, and you'll see that come up in a minute. And all of this sort of led me to this realization that relationship is missing as a first-class artifact in delegated authorization.

If you think about what we have today, in most sort of your defined protocols, you have a subject claim, or kind of like a principle, but in the OAuth OpenID Connect world, it's a subject claim, and then embedded in that ACT claim of the token exchange, there's another sub, and you can basically say that one is acting and sort of pseudo-ish on behalf of the other one, and that's about all that exists today. So this is kind of my mental model for breaking down delegated authorization into subcomponents.

And we've sort of got three layers here, a trust layer, an intent layer, and an execution layer. We'll spend most of the time on the trust layer and the intent layer here, and there are many different other words you could substitute for intent, right?

Again, Carl McGinnis has talked about this from the concept of mission. Other people have used the word mandate. Other people have used the word charter. We probably need good terminology and definitions in this space, and we don't have them, but let me sort of start at the beginning. We need a relationship, and that relationship sort of defines who the delegator is and who the delegatee is, and the authority that goes with it. I'll go into each of these areas in more detail, so I'm just sort of going to cover the top part. Authority covers basically not only your...

It basically covers why is the delegator authorized to delegate as well as what is being delegated, right? You need both aspects of authority. Obligations and constraints are more focused on what is it the user wants to do right now, or the machine, the entity, the organization wants to do. So it's more sort of task- or mission-oriented. And then the execution layer is sort of like what are the raw things that have to be present in order to complete those tasks. So let's look at these in a little bit more detail.

The interesting thing about relationships is that it isn't, like I said earlier, one-to-one, but it can be one to a group of people. It could be organization to organization, and it can even be kind of entity to policy. And so I'll give you that last one just as something to think about. If you think about a doctor authorizing a narcotic for a patient, and the delegatee is the person who has to administer it, it's probably not delegated to a... It might not be delegated to a specific nurse.

It may be delegated to a policy that says, if you meet these qualifications, you may administer the narcotic. And we have no way in our world today to represent any of that. Like I said, it's pretty much one-to-one today. So I think we need to expand our definition of relationships. And I think the ability to... Sort of maintaining some sort of authority delegation chains and the right to delegate could potentially live in that relationship structure. And then you could sort of focus the authority structure on what authority is being delegated.

The other interesting thing here is that relationships come and go. There's a life cycle to them, and there's a time bound to them. And what is delegated can change. Because in certain jurisdictions, a parent has certain rights over their child up through age X, and then the rights get reduced a little bit. And at age Y, they get reduced a little bit more. And at age Z, the child is a full independent adult, and the parent has no rights. So these things are modified by time. And then the other interesting point about authority is it actually creates some bounds on what can be accomplished.

So if what's been delegated is health care power of attorney, the delegatee can't go open a bank account because that wouldn't be within the context. I think this relationship authority structure is generally longer lived, though it could come into existence if you think about potentially an agent spawning a subagent. You could potentially have it be short-lived. But in a lot of real-world use cases, the relationships tend to be longer lived.

Oh, all right. I'm way out of time. The intent layer is really obligations are what do you need to do to complete the task? So that's book the hotel on this date in the city. Constraints might be within walking distance. So it's kind of trying to capture. And this becomes another plane for modifying what can happen. So we've heard a lot about run-time control planes, run-time authorization planes. The relationship and authority combined with obligations and constraints put bounds around effectively what are the permission capabilities and the protected access.

So permission capabilities are sort of what are the entitlements that are given to that running piece of software. And then these other pieces bound that. So the permission capability might be book a hotel, but all those other things then restricted it. Protected access, I'm still, to be quite honest, working through exactly how that might work.

But fundamentally, if I want to book the hotel with my loyalty points, somewhere in this process, the system has to be able to deliver to that hotel a credential that says, George is authorizing the hotel booking agent to book this hotel reservation with points. So there's some interesting things there. How much of the constraints get embedded in that credential? How you mint those credentials? Who mints those credentials? When do they get assigned? I think are all interesting questions. So there's some critical design considerations that you have to care about.

And even in the keynotes this morning, this trust domain boundary problem was not really addressed. It was just focused on how do I do authorization control planes within my enterprise. But I think in many real-world use cases, even within the enterprise, you're going to cross a trust domain boundary. When my internal task needs to talk to Salesforce, I just crossed a trust domain boundary. And there's really interesting pieces that happen. How do I manage the delegation chain?

Again, like I said, if I went through three workloads within my enterprise before going to Salesforce, Salesforce probably doesn't need to know about the three internal workloads I went through. The privacy aspect, like how much of that data needs to be removed. If I just need one small thing when I cross that trust domain boundary, how do I remove the rest of it, right? Attenuation becomes really interesting because the scopes within trust domain one are not likely the scopes within trust domain two. And so how do you match that as close as possible to still attenuate what's being requested?

And then obviously the audit and compliance problem is really interesting, especially, again, when you cross these trust domain boundaries, how do you get that data from the other domains into your system so that you can audit it? What does that look like? What mechanisms do we have for doing that? So there is a boatload of work happening in delegated authorization.

And this, seriously, this was like one simple query to the robot that pulled in about, you know, 50 odd articles and I added a few more. So this sheet was generated from 60 references and it's happening everywhere, right? I think I'd shared somewhere else. I was representing identity at a U.S. National Science Foundation event that was focused on where do we need to set up new research ideas for academia, right? And some guy comes up to me after, you know, the panel I was on, he's like, oh yeah, we did this thing at Ohio State University and, you know, here's the paper.

And of course I'd never heard of it at all. Another one got, I got tagged in another one this morning. So it's happening everywhere. You'll see this in a minute. But this is problematic and I think we're going to have to deal with the uncertainty and the fragmentation for a while. So let me sort of give you some call outs or takeaways here.

One, it would be nice to have a place where we could have this conversation. I don't know how feasible that is. But for sure, trying to coordinate across these has become untenable.

I, for a while, was trying to sit in the three that I knew about that were talking about these kinds of things. The IETF has two, maybe three, boffs to spin up new working groups in addition to the two or three that already exist that are tackling bits of this problem. So how we coordinate across that from an industry and a standards perspective, I'm not sure. I think it's critical that any time we try and solve this problem, we have to solve the trust domain, crossing those trust domain boundary problems. If we don't, we're going to end up, you know, basically pinning ourselves in a corner.

And I think we need to figure out how to both work on the problem and let the experimentation happen. So we need to think about what's the right layering piece and focus on that. And then figure out how to weave the experimentation and the work that's going on in. So that's pretty much it. And I know I'm at time. I will leave you with this slide, if you want to take a picture, which was some of my thoughts on things to consider if you're evaluating a solution internally or a standard. So thank you very much.

Yeah, so thank you very much.