Eve Maler - UMA deep dive - GDPR, PSD2 - pivot to CIAM

Course officio of Uma heart in the new days after the XML girl, Samuel days. And now it's it's Jason and lady Jason and yes. And of course, band leader of Z, Z a love token, Z Z said said whichever.

No, no. I refuse to accept which country I'm in. Okay. So in that case off to even thank you so much.

Well, thanks. Go. Yeah.

In fact, I realize, I think I have five Twitter handles. I got XL girl. I do have lady Jason, long story, late night, lot of wine. I Have mud junk. That's my real band here in Seattle. Maybe I'll have to get CZ off, nobody grab it.

And so I, my remit for this next little while here is actually, it it's kind of a tall order because I was asked to talk about GDPR general data protection regulation in EU PSD, two second version of the payment services directive, financial regulation in the EU consumer customer, IM as we've been talking about this morning already, and the role of this protocol, this standard user managed access, which is now coming up to version 2.0, having been developed in Cantar initiative and its role with respect to this new regulatory environment.

So what I thought that I would do first is summarize perhaps my perspective on C IAM, which I'll do in three slides. What can we observe about cion first of all, a critical thing about the philosophy of cion is you're not the boss of them. Those people that you're doing, I am about, they do what they want. You have to gracefully degrade, they get to pick the devices they use. You can't tell them don't use that.

Samsung, what was it? The note seven?

Well, until it got regulated away, they get to pick the wizzy new thing. That's insecure. They get to use Android devices that you barge your employees from using that's something you could do with employees and they get all comfy and get strolled around like this awesome Dog here. Second thing is, it has a scale of its own. That's kind of what our active directory conversation was that Pam brought up, you know, ad is comfortable up to okay, ad on premises anyway, maybe not Azure ad to what, you know, a hundred thousand employees and then it starts creaking. Mm.

But when you talk in the 50 millions, the hundred millions, and as you get into the devices and the sensors that, you know, go way, way up for every single user that falls apart, and then you talk about the relationships between them. We did talk a little bit about, you know, you got a VIN number attached to a human being and all the sensors I've, you know, been in conversations about, you know, much larger devices that might have a quarter of a million sensors on them. And you wanna have interactions with many multiples of humans and now you're into identity relationship management.

And so the more identities we manage, the more significant the relationships among them become. So I was reminded of Monte Python here. We're all individuals, this is actually relationship graph visualization. And there's this one little thing sticking out. I'm not. So that's actually a really important thing is you start managing relationships. That is to say the arcs between the nodes as first class citizens, as something you have to start doing, it's a whole other world. And at scale that's where this kind of thing becomes important.

You know, no SQL databases in graph databases and things like that for your policies, for your provisioning, for workflows. It, that actually is a kind of new technology that, you know, you don't have time to talk about before. And then finally, yeah, I had to do Ave. This is probably my most recent event, but it's actually of 2012 vintage. And at first I called this the VE of business drivers of identity, but it's really just the VE of drivers of identity and Ram. And I were just talking about, you know, how do you value a thing? It's actually, how do you value anything?

And it's what you use it for. And I made an mnemonic out of it because talking to reporters and whoever, I can't, I don't know, my brain's like a steel C, everything just falls through. And sometimes I forget the third one, I say two things, and I forget the third anyway, but so the drivers of identity or, or of authentication, Pam said, you know the difference between authentication and authorization.

Well, you never authenticate for your health. You know, people don't wake up and say, I think I'll log in today, cuz it'll be so much fun. And it departments don't implement IAM systems because they love trying to get budget and spending money. You do them for one or more or all of these reasons. So what does the first P protection stand for? Security protection, privacy protection within security protection. You can think of access control. So authorization is in there, but it's never the only reason that you might use authentication identity writ large for even for enterprise scenarios.

So I might differ with Pam just a little bit when she was saying that, you know, employees don't have preferences in the sense that well cross session saving of preferences is personalization. So you remember that who somebody is so that you can at least present them with, you know, hi Doug, whoever you are and you save, you know, some preferences from the last session. So that's personalization in a consumer context, personalization personalization takes on much more meaning because now you're talking cross sell upsell.

That's kind of personalization stands for deepening relationships and customer relationship management and relationship marketing and relationship selling and all those things. But it even applies to employees and then payment stands for not just, you know, money changing hands, but whatever transaction value is. And now we can talk about, you know, loyalty cards and fungible things that aren't strictly money, but you know, some governments are trying to regulate as money if they can. So even an employee context. Okay.

So, and so employee number 1, 2, 3 is allowed to cut a payment, a purchase order for up to $10,000, but no more. So one, two or three of these reasons are why we do identity and authentication for all populations. So what makes data privacy regulations? Okay. Not just some of the, you know, PS two is not just about privacy, GDPR. Isn't really just about privacy, but go with me on this. What makes data privacy regulations different this time around? We know that there's urgency when a regulation goes into effect. So general data protection regulation starts being enforced May 25th, 2018.

So we're all feeling that Y2K effect, except it's not Y2K, it's Y2K plus 18 and it has high penalties, really high penalties. So that's maybe different, but it kind of along with PSD, two has a particular effect of virality. I don't think that's a word, but you know what I mean? It's viral. So in what way is it viral? There's two ways in which it's viral. Number one, where data subjects go, the regulation goes.

So if somebody goes to the EU and data needs to be transferred to where they are, suddenly organizations need to adhere to the regulation, but it also has another kind of virality in that organizations basically are incentivized to have this race to the top where they only wanna work with other organizations that are kind of GDPR ready. And this has been much remarked upon if you follow kind of the literature and the news. So nobody sort of has an incentive to work with a kind of shotty from the wrong side of the tracks organization.

The second way in which these regulations are different is they have really high aspirations. And so what do I mean by that data protection is the phrase right in GDPR and in the EU data protection is used to kind of mean data privacy. And yet when I see the phrase data protection and I've had conversations like with Carsten, Ken asked, Dr. Ken asked is one of the Analyst Analyst of co or Cole.

He's also the smartest guy on the planet because when the data protection directive went into effect in the EU was now 15 years ago, he set up a DPO as a service company, basically a law firm that did this in Germany and has been very, very busy ever since. And I've had some conversations with him and with a whole bunch of other people about this phrase data protection. So it means data privacy, but GDPR doesn't just do things that, to me mean data protection, keeping stuff in.

And I know that's not what it just means, but to me, data protection means protecting data from getting out the fetal crouch of privacy, which is one of the reasons why the P word, you know, when you see privacy management tools, they're all about not letting data out and having that relationship with people. It does other things too. And I see it as a layer cake, a second layer is data transparency. So if I'm just talking to English phrases, I would say data protection is not letting data get out accidentally.

So around working hard, not to have there be breaches and doing timely breach notification, Equifax, but data transparency is about allowing people to know what's known about them and allowing people to know what's gonna happen. Purpose of use being specific and so on. And then the cherry on top of this layer cake is data control. There's a lot of elements about data control.

And if you look at, for example, the draft consent guidance that we've seen out of the information commissioner's office in the UK that I mentioned before, which is the, the regulatory body that's empowered to do things like fines of, of UK companies they use. I think I saw on the draft consent guidance. I think I searched on this and it was something like 29 instances of the phrase, choice and control. And they really mean this.

And if you look at the GDPR, the regulation text itself, and also if you look at PSD two and you look at the role of consent, and if you look at pita, for example, in Canada, a similar role for consent is ensconced in there. And if you look at the, the privacy guidelines in Australia, so you're starting to see this high water mark of regulations around the world.

And if you look at actually the earlier work done in New Zealand with things like the privacy domains, the notion of consent as a tool and sort of resting back the role of the word consent to me, what it used to mean, and not just you have me over a barrel, I have to do what you want is really remarkable. So that's what I mean by high aspirations. And we'll see if it can really happen, but I mean, the tools to do this are being given in the regulations. So putting my for drop hat on for a second, this is the advice that we are actually giving our customers.

And when I said, when I demurred from giving an answer and then Alan went and gave an answer that I was entirely in line with being sort of cynical, you get asked to give some, some advice. The reason why it's easy to be cynical is there's different stakeholders in companies. So the DPO CPO has an incentive to be on the side of the data subject because you know, it's their organization. That's gonna sort of go to jail and be responsible for paying the huge fines. It's the business unit owner that wants to find the legal way to use a and to collect and use as much data as humanly possible.

And that's just the reality. I mean, when I was at cloud identity summit in June, I got asked by, you know, three different companies. I'm not gonna name them, but how can I get the data and use the data? And those were the business units. That's just what they wanna do. And they wanna know how they can do it in an okay way. And so here's the steps I give them, everybody's got digital transformation on their minds and that's about the omnichannel experience.

And it's, it's about that, that kind of, that sort of like a boss thing that I was saying, you know, you're not the boss of them and you gotta do what they want, but they wanna identify the intersections between that the digital transformation opportunities and the risks or the gaps that you're creating in user trust. We see what happens when you tweak your privacy policy, even as supposed benign way, because what seems to be benign, what lurks behind there might not be so benign and people rightly don't trust you. And they have choices. I won't give examples.

Everybody's got their own examples in their heads, from some service they use or some OT thing they just bought or whatever it is next we say, start conceiving of data, personal data as a joint asset, the DPO already does that. It's their job. All of their incentives align with that. The business unit owner does not naturally align with that, but they're human beings in their daily lives too. And they buy smart home products and they use digital services and they have smartphones. They have to start putting themselves in that seat.

So I encourage it and that's my Pollyanna versus my cynical self, right? Because I live in both those worlds, third lean into consent. And literally what I mean by that. And most people are here, but I, I see some people who weren't here yet. I was talking about the six legal basis for data processing that GDPR defines one of them being consent. One of them being legitimate business interests, and that's where the monkey business can happen.

What I'm trying to do with UMAS, I'll talk about in just a moment is reduce friction from the choice of consent, where it's appropriate, where it's not appropriate, where you have to collect the data for some, you know, public, you know, government reason. You should never offer the consent choice because if they say no and you have to collect it anyway, you're in the wrong, but where it's an appropriate choice.

Well, let's make it easier to offer the choice. And then finally take advantage of, I am for doing this stuff. Identity centered security and privacy is in most cases, the right answer, as we're seeing from all the IOT, malware things, all of those so far have been device identity theft cases for injecting the malware. Okay. So how can user managed access be relevant to these, these imperatives? The ment two specs are now broken into these two halves. I'll tell you more about that in a second. Here are the benefits enumerated one by one wonder.

So first benefit in the Uma extension grant is the resource owner. You guys all know OAuth, right? All right.

Peeps, the resource owner authorizes protected resource access to who to clients used by entities that are in a requesting party role. Normally the way OAuth works, it's used by the resource owner. Again like, you know, Alice, Alice, the resource owner is usually the one in OAuth who's used the client. But in this case, we were talking about Bob in a requesting party role, a different party.

So what you're enabling is party to party authorization, Alice to Bob sharing of access, rather than just authorization of application, access alone benefit one benefit to the authorization server and resource server. So normally in OAuth, the way you see that deployed is they're in the same security domain.

I mean, you don't know any better as to whether they're apart, but you assume they're together because you look at RFC 67, 49, there's no arrows between them. So what Uma does is it allows them to interact with the client and, oh, sorry, I'm getting my head on myself. Take back what I just said. The authorization serve and resource server interact with the client and requesting party in a way that is asynchronous with respect to resource owner interaction.

So this lots of resource owner go off to the authorization server and configure it with policy conditions at will rather than authorizing access token instruments, synchronously just after authenticating. So you all know the oof pattern of authorized button deny button. What you can do here with Uma looks a lot like a web access management pattern, except that Alice is playing the role of kind of the enterprise.

You know, enterprises do this all the time, configure policies, and then go away. And then somebody hits the resource and maybe there's policies there that say what to do. So Alice can go off and be sleeping when surfing is, I often say she could be doing whatever. If there's policy configured, Bob can get in or not. Or what I like to say is think of Google docs or, you know, office 365 or whatever. You press a share button. You can figure what you wanna have happen. And Bob gets in or not. Okay.

Other benefits, no, multiple resource owner servers operating in different domains can communicate with a single authorization server operating and get another domain that acts on behalf of resource owners. So, as I was saying that, I ask you to forget, and I'll ask you to remember in OAU, you have an as and an RS and they live in the same place. It's deployed by an enterprise. Maybe that's Google. Maybe it's your enterprise. Maybe it's, I don't know Twitter, if you're talking oof.

One in this case, what we're seeing is, you know, Atlas has got a whole bunch of her digital stuff, living on the interwebs, maybe starting off in devices and going up to a cloud or something, would it be nice if it were possible for all of her digital stuff, to communicate with a single authorization server to be managed in that one place that makes it convenient to do so. And I'll show you how that works.

But Uma has managed that next benefit, a service ecosystem can use that to automate resource protection so that the resource owner can monitor and control all that policy conditions over time. And then finally, the way that we've done the access token of Uma built on top of OA is that authorization grants can increase and decrease at the level of individual resources and scopes. So you've got the token revocations spec in OAuth that lets you kind of kill a token. But what if you wanted to just say, I'd like to just tweak the scopes.

This is the resource owner saying I'd like to tweak what scopes Bob gets. I'd like to tweak what resources Bob gets at this resource server that can be done. So let's translate that with a couple of examples. What does this enable for one thing, pinpoint sharing without caring, what others want first. So typically a client says, well, I want these scopes. Do you wanna give them to me? Now? The only SDK that I know lets you do unchecking of scopes is Facebook. I might be wrong about that, which is ironic, maybe typical OAuth SDKs. They don't really have an incentive, a business incentive.

If we're talking about economics, the business incentive, as in so many opt-in interfaces is for the client side to just say, Hey Alice, I want scopes a, B and C and they'll tend to over ask if they think they can get away with it. And Alice really wants the service.

This is, this is why. If you look at the ICO consent guidance, all it talks about is privacy dashboards. And opt-in it doesn't know about any other paradigm. There is another paradigm that paradigm is what healthcare would call consent directives, which means saying what you want to have happen before anybody asks you. So here you have an example of a patient steps onto her smart scale. I don't know what units these are in. These are impossible numbers. If you imagine the units, we actually have two labs. We have two labs in Oslo and San Francisco.

And with real numbers, they wouldn't look like this. The weight is kilo. Yeah. I guess if it's yeah. Then the body fat might make sense.

Yeah, can't be, is that, that maybe. So in this case, we're assuming that this body scale has a resource, which is this manufacturer of the scale has an API that allows access to a resource, a single resource, which is the scale and has a notion of scopes of access, which Alice can control. And if she wants Dr. Dr.

Walker, her doctor to see some of this information, that's coming off of a scale, she can allow Dr. Walker to see a subset of it. And this is the subset.

Well, how might she have enabled seeing that subset? Well, it might look something like, and it's deliberately kind of looking like Google docs here. The resource is the body scale made by the smarty corporation. And she has an opportunity to share different. These are scopes. We call 'em permissions here in the interface. So it's important that she's sharing this without external influence. That's not an opt-in interface. That is a directed mode. It's a proactive mode of sharing. And as in something like Google docs, you know that you can change that at any time.

It's not a privacy interface. It's a selective sharing interface. And I actually submitted through a can tower process, some feedback to the IC consent guidance, people to say, you missed a trick here. We have existence proofs of other ways of people having impairment. What else does it enable?

Well, single pan of glass control will forgive me the for rock branding here. This is just an example of what digital pan of glass control can actually mean. So this is just a snippet of what gathering together, all your digital stuff in one place could look like. Now this depends on business models and business relationships and the like, but it's not too too different from imagining relying parties coming together and using a single IDP. And we can have a philosophical conversation about that, but this is federated authorization, not federated authentication.

So it's resource servers relying on a single authorization server for authorization decisions, a bit like PPPs, relying on a PDP, similar with a little bit of business consequence. So we had 1.0, and now we've got this 2.0 what's 2.0 all about what are the, the different benefits. So UBA one built all of this capability using oof and open ID connect, open ID connect was kind of a optional part, but it's obviously helpful.

Uma was started early enough that some of its design actually preceded and an influenced modern OAU open ID connect, jot practice, and some of the specs like dynamic client registration throughout all this, we collected a lot of implementation experience. And in the meantime, OT economy became a thing. It turned out that that was a really good fit for OMA. And we use cases. Also the health relationship trust working group at the open ID foundation happened. And I'm a co-chair of that group with Debbie Bucci of us health and human services office of the national coordinator.

And the heart group is actually profiling, oof. And open ID connect in Uma for patient centric, privacy, sensitive health data share and use cases. That's going really well. The implementer's drafts of those profiles were approved pretty recently. So we embarked on this upgrade roadmap. What was in the roadmap, three related things simplify, and I'm invented a new word, oy, and those two things are kind of related together. So basically not just be kind of application of OAuth, but actually make it sort of true OAU. And we achieve that also improve IOT friendliness.

Like you could use it for T, but we wanted to be sure that things like disconnected use cases were sort of fully possible cuz you know, being always connected is good for a subset oft use cases, but we wanna be sure it was good for all of them and then make suitable for wide ecosystem. So what do you mean by that?

Well, if Alice knows who she wants to share within the real world, like somebody's gonna come to your door and you have a smart lock and doorbell, but her authorization server has never met them before you wanna make sure that works. And the way we had done Houma one, we had thrown in and sort of embedded use of OAuth. That seemed like it was really efficient, but it was getting in our way and it added some extra flows and it forced an authentication kind of an early evaluation of, of who Bob was that was getting in our way for this notion of wide ecosystem. And we took that out.

So with all these interconnected goals, it turns out that they all had something to do with each other. And by basing Uma two more closely on OOA effectively, what we did was we designed an extension OAuth grant and took out lots of stuff.