Road to EIC: What’s Next in Digital Identity Standards?

So, welcome to our KuppingerCole Analyst webinar, which is part of our series Road to EIC, to the European Identity and Cloud Conference. And this one is a panel about what's next in digital identity standards. For this panel, we gathered, I think, a very interesting group of people, which is Joni Brennan, who's president of DIAG, the Digital Identity and Authentication Council of Canada, which is Pamela Dingle, director of identity standards at Microsoft, which is Mike Neuenschwander, vice president, global head of research strategy at KuppingerCole Analysts, and which is me.

I'm principal analyst at KuppingerCole Analysts. So this webinar, as I've said, is part of a series of webinars, which are leading to and sort of giving some preliminary insights into what we will discuss at the European Identity and Cloud Conference, which will run in June 4th to 7th this year in Berlin. So don't miss this event. It's the event around digital identity and identity and access management with a ton of topics we will discuss. So this is definitely something you must not miss.

Having said this and having hinted on DIC, I'd like to turn on the others, turn the others on their cameras again, and then we directly can get started with our webinar. So welcome, Joni, welcome, Pamela, welcome, Mike, a pleasure to have you here. I stopped sharing my screen, so we all should be very visible on the screen right now. Yeah. So maybe if someone doesn't know you, I think probably everyone knows you anyway, but maybe we do a very quick round of introductions and start with Joni and Pamela and then Mike.

Hello, everyone. It's great to be here.

Thank you, Martin, for the invitation to join this conversation today. I'm Joni Brennan. I'm the president of the DIAC, the Digital Identity and Authentication Council of Canada. I've been in this role focusing on risk management and assurance frameworks or trust frameworks that layer on top of standards, so helping with adoption on those types of standards by managing risk. And before I was with DIAC, I have been with other nonprofits in the space, so about 20 plus years in nonprofits working on identity management standards, policy and innovations. Thank you. And I am Pamela Dingle.

I am the director of identity standards at Microsoft, meaning that my team works directly in standards bodies to try to create the actual documents that people then attempt to implement. And sometimes that works and sometimes there's challenges. But I will say that, Joni, I think I've known you, actually, I think I've known everyone on this panel for most of two decades. So it's really nice to be here. Thank you. Yeah. I'm Mike Neuenschwander. I've been at Couplinger and Cole now since August last year, but I've been in the identity space for really almost my whole career.

And I am really glad to be here with everyone else because we've got a lot of expertise here in the virtual realm. So that's it for me. Okay. So let's get started. And I think the first question is, why do we need standards? So what is it what makes standards so relevant? And maybe we also can look a bit at what is the standard versus what is related to standards, but not exactly a standard and what makes up a standard. So who wants to start? I can start. I have an analogy, heaven forbid. I do love my analogies.

So for me, standards are like blueberry muffins. So when I go to make a blueberry muffin, I do not try to imagine in my head what a blueberry muffin looks like from scratch. I go find a recipe. And what that means is when I have a recipe, I can follow the recipe and I can get the same results every single time if I follow the recipe exactly.

Now, I mean, the difference between, say, a de facto practice or a de facto pattern and a standard is the level of detail that goes into deciding how the recipe gets measured out, if you will, and what the steps are. So when we talk about standards, we generally talk about what we would call over the wire standards or sort of deeply technical standards, which are example standards might be TLS for encryption of web or OAuth or SAML, secure assertion markup language, if any of you are familiar with that.

I mean, those are sort of the deep technical plumbing types of standards. But we also have another standardized type of interaction, which is on the regulatory side. So describing not necessarily the exact bit you have to put on the wire, but the the outcome that has to be guaranteed.

Joni, does that does that work for you? I love I love the analogy. I think as well, you know, the analogy of the blueberry muffin helps a lot because while we may have a process for producing a standards based process, let's say for producing this thing called the blueberry muffin that we should all get out something that in our minds is a blueberry muffin. The implementation of that process, one person might put a whole lot of blueberries in and one person might put, OK, I only want three blueberries in.

And so having a standard gives us a singular way concept of how to create a method or a process. It doesn't mean that what comes out of the other side is exactly the same copy as as as the next person who uses that standard. I would also add that from what is a standard perspective, I would bind that very much to a set of defined processes that use some feedback channels that use can be public commentary process, uses consensus, uses voting.

And I would add into that as well that within the standards ecosystem of developing a standard, we have national and international standards where one must be part of a national body. And under a strict set of rules from a from a national or international perspective, it just can be arguably a bit more closed way forward. And then we have industry standards which are tend to be more open, more degrees of open for how those types of standards get developed.

So a lot of the process who's in who has the permission or who's earned the right to be in the room, whether that's a high bar, medium or a low bar for that access, which is also not exactly the same as open source, but we're not there yet. So when I think standards, I think defined processes that kind of may increase their rigor or loosen in their rigor depending on the body who's developing.

Mike, anything to add here? In this context, what does the blueberry represent? Curious or I don't know. I think that a lot of times we're making something or baking. So it's a good analogy, but I think that we're baking something very complicated in many ways. Right. It has way more ingredients. So but I like what you had to say, Pam, about whether whether you're focused on sort of repeating a process or actually delivering kind of protocol wise, ensuring that the that the payload is correct, something that I think that's what you're getting at. I think that's an important distinction.

Yeah, I mean, there's there's syntax and semantics. They're both really important. They both have to be right.

I mean, for example, another analogy, you know, if you decide you want to make your own lamp and you make your own plug to go on the lamp, your own electrical plug, it's not going to work. You can make you can go ahead and make that plug as beautiful as you want. But if it doesn't fit into the socket with the right clearance and it doesn't conduct electricity, then your lamp will not work.

And so, I mean, the other thing about standards is that they enable scale. I don't have to make my own plug. If I make the plug that matches the standard, then every you know, every lamp I produce will work within a given country.

Now, every country has standards and and that's a problem as well. It's not like there's always one standard. But but that idea of interoperability, of making sure everything you make works with everything everyone else makes, is also another huge driving factor.

Yeah, I think interoperability is very, very essential when we talk about standards. So and what I believe also is very important is that when I talk about standards, it's something that is widely used. So I would say of all the things that have been described also from or via standard bodies, only a relatively small fraction becomes a real standard in the sense of that it's really widely adopted. But it's also the nature of things, because sometimes there are sort of competing initiatives. There always are a lot of learnings.

I think what we see with every standards development at the beginning, there's a first standard and then there's usually a version 2.0, which is much better than the first version, at least for many of the standards. And then we see a lot of things around standard evolving that then support specific use cases, solve additional problems that are to add to a standard. I think this is just in the nature of standards development.

So when we look at identity standards, which are the topic of today, so which ones do you think from the ones that appeared in the past couple of years are in that sense, the most relevant, the most successful standards? So I would start probably with O-AWS and OIDC, as a set of standards, because they are so widely used. I think you also have to talk about SAML. SAML is decades old and the gold standard and works fine. And unless you have specific native mobile app or API needs for any given federated connection, right?

And federation, by the way, I define as basically a secure introduction across domains. So all of those pieces, OpenID Connect, SAML, those are mechanisms for secure introduction across domains. And they're not, it is almost set and forget technology, I would say.

Yeah, and I think part of a qualifier as well is that we live in an ecosystem where multiple standards will exist at the same time. And some of those standards, identity standards, may be finely tuned better for a particular use case or set of use cases versus another set of use cases. And so the ecosystem where SAML continues to coexist with OpenID Connect and OAuth ecosystem is one that will be here over time. And I don't see that going away soon.

While newer entrants around W3C data models from an industry standard perspective or ISO mobile driver's license from an international standards body perspective are some of the interesting newer entrants that I believe will coexist along with the suite of standards that we've already mentioned that have been in the ecosystem for a long while now. Yeah, and I don't see an issue, honestly, with having very few competing and frequently also complementary standards. So it's not a one-to-one replacement when we look at SAML versus DOI, DC, and OAuth format.

It's really something which is complementary, which has different strengths, different focus. And so as long as we have a strong adoption of all of them and they help us in really solving our real-world problems, and that is what these standards actually do, then I think it's what we are looking for when we talk about identity standards. Mike?

Well, yeah, I think I have what I call the first mile problem, which is instead of the last mile problem, which I think that in some ways we could argue that SAML and OIDC both have solved the first mile problem, which was the simpler one, authentication, for example. But as we start talking about authorization, scopes, attribute, whatever it may end up being, those things are used, but they're not quite as standardized because there's a lot of semantics that you get involved in. And I don't know that those standards have really helped us achieve all of that.

You can do it in a scoped kind of, to use the word scope again, within an enterprise potentially for some applications that you control, but they're not necessarily generally just immediately available to you at any random sort of federated partner. But yeah, by the way, the attendees in the chat, so SAML also came up quite a number of times, but there was also SCIM as one we didn't touch yet. And that is also one of the standards that definitely gained a lot of traction in the sort of the past couple of years.

Yeah, there's a lot of work going on in SCIM right now. So for those of you who aren't aware, SCIM stands for Simple Cloud Identity Management, and it is a specification written in the IETF. So if you go to IETF.org or if you just search IETF and SCIM, you can find it. The interesting thing about SCIM is that the work that's happening now is all about data at scale. And so we are we're working on new specifications to deal with some of the gotchas of SCIM, for example, the fact that there was never an ability to do a dynamic query. You could never do an incremental search.

And oh, I guess I should say the other thing to know about SCIM is that it's essentially a REST endpoint that's standardized, that lets you search or authenticate or provision user data. So you can imagine a REST endpoint called slash users, and you use all the standard get, a put, a post, a delete to be able to manage identities at scale over the Internet. So that's this idea of being able to do this for millions and millions of users in one shot.

You know, that's really the thrust of the working group right now. By the way, there's an interesting comment.

Oh, go ahead, Joni, first, and then I'll come to the comment from the chat. So I only wanted to call out one piece as well around the standardization discussion, which is the standards that we're talking about are, you know, in my mind, more about packaging transit, transit of identity data, in this case, at scale, moving it around, making sure that it's not tampered.

On the other side of standardization is more in the frameworks and legislative perspective, because what we're not talking about when we're talking about OpenID Connect or SCIM or SAML, we're not talking about the set of standardized processes by with the information in the credential or the information in the ecosystem was verified. So that's complementary to the technical ecosystem and also another suite of standard standardization that plays more in the frameworks and legislative space.

So a little distinction between how we're moving and packaging the data versus how verified is the data and what processes did we use for that. Mm hmm.

Okay, great. Come before we go to to to another aspect, which is about what is lacking in standards and what do we see happening currently in the standards bodies. And there's one comment, which I find very interesting. It says standards reflect the economical interests of the organizations pushing them. I'm I don't think I agree with that, that way of looking at standards, because I feel that, yes, organizations engage because they feel they can do a better business when there are standards or when something becomes standard.

I think a good example has been have been have been, for instance, the FIDO2 or the FIDO standards where some vendors felt, yes, we need something that helps us having a standardized way of communication between a biometric device on an end point and the backend authentication system. And yes, the vendors felt a standard would help them doing a better business. But they also felt there is something which hinders adoption of something which is very valuable and that there is a business case behind it because business case is because people need it.

And when we look at the adoption of FIDO2, it shows very clearly that there's a huge value for for for billions of people probably already in having these standards. So I I think, yes, if someone starts spending time and standards bodies and working on that, then there's in some way, frequently some interest in having a standard becoming successful. But it is because there's a problem to be solved. And I think this is the point, you never will make a successful standard if it doesn't solve a real world problem.

Well, I think that's kind of what Joni was getting at with with Trust Frameworks. You want to say a little bit more about that? Maybe Joni can kind of give us an example.

Yeah, I think I think as well, you know, to the original comment that standards are driven by economic drivers, I would I would say inherent to the nature of laws and physics and standards and nature are motivations. So there are always motivations. Each stakeholder brings motivations into what they're doing from a standards based perspective. And so typically there's a problem that we commonly agree that we want to solve that problem and we want a common way to solve it. And we'll compete on top of those on top of that desire, that common desire to solve a problem.

So so everyone brings motivations to the table. I would say that they're economic, they're cultural, they're strategic, they're there. There's a lot of different flavors of what those motivations can look like in the standards ecosystem and kind of a bit more into the Trust Framework side of things underneath the the the ISO structure. There's also something called a scheme owner. And in the context of a scheme owner, the the body that is shepherding that standard or that scheme to move forward also has a voice in this day. And so we also have as a scheme owner.

And so DIAC is is is acting as a scheme owner underneath the ISO definition where DIAC as an organization brings a voice into the table of vendors, governments, providers who are all trying to solve that problem. And our voice is also meant to balance out what do we see as the market needs? What do we see as the societal needs? What do we see from an impartial and neutral perspective? So I think the original comment is very narrow.

I think that economic is one set of motivations and there are many types of motivations that different stakeholders bring into the standards ecosystem, developing standards. Right.

Yeah, I would just add that I'm definitely team economic factors, if you will. There are economic factors, but there's the the economics of the short term and the economics of the long term. And those are very different things. And not every vendor or company has the ability to consider both at the same time. So if you look at FIDO, I mean, FIDO, you can legitimately argue that that our investment in FIDO, which is a 10 year investment, has cost us millions and millions of dollars. It's absolutely true that it costs money to implement standards when you do it up front.

It costs money to develop standards. It's painful. It's time consuming. You have to make your product teams talk to other entities.

I mean, developing in a bubble is much more economic in many ways in the short term. But the long term, I mean, 10 years in, we have this ability, you know, we we didn't even have the security landscape 10 years ago that we have now. But right now, ninety nine point nine nine percent. Right. If you're using a password. Then that ninety nine point nine nine percent of of attacks that we're seeing on our platform apply to you. Right.

And it's not to say that if you're using FIDO on our platform, those you're not being attacked, but you're being you're not being attacked at the same velocity with, you know, with the same type of success rate. So did we you know, we knew we knew 10 years ago that it could change how we detect fraud, how our you know, what our fraud numbers are. And that in the long term is an extremely beneficial thing for Microsoft, for Microsoft's customers. Right. But but that is I mean, like Joni said, that's multivariable calculus to try to understand the risk versus reward of working on standards.

What I love is that we're at the point in the industry where I think people have generally accepted that in the long term, that reward is there. But by the way, some already of the participants already started using the chat, you also can use the Q&A in the events tool. So if you want to contribute to this discussion, you should use the chat or just ask a question.

Oh, by the way, finally, there's the first one. Just looking at it. So I think this is this is something. When we look at the standards, we talk about the identity standards and then we have the ISO standards on the other side. We have missed those standards. So how do these different bodies. Sort of different things we are talking about relate to each other. I can jump in on that one. Yes. So we you know, in the identity professional ecosystem, we're constantly working through words and what they mean and what we think they mean on that day.

Or maybe they mean something a little different the next day. So but to to add maybe to demystify a bit. We have these tools and I tend to think of them as I think of it as a suite of technical methods for how to get something done. And in my technical methods box, I have technical protocols like SAML. I have a protocol like OpenID Connect. I have maybe I also have an open source like I have Hyperledger in the Ares, not a standard, but but another technical method of how to get a thing done on top of that ecosystem.

We have quite often frameworks and those frameworks may be driven by industries or industry and national collaboratives or international collaboratives. They may be driven by international or national space. So in this case, NIST is the national standards body for the US. It sets up basically a framework, which is guidelines for identity, setting identity assurance, identity authentication. And what are the criteria for measuring the security and trust within a federation? What are those three components and what is NIST set?

Now, an organization like NIST sets its standards for the national perspective and technically for different private sector or public sector service providers that are offering services to the to the federal government of the US. So the scope of something like NIST is is very tightly scoped, but it does become a de facto standard as it gets iterated and the criteria get pulled into other approaches.

So when we think about the the layer of the technical standards, quite often a national standard or a trust framework is actually setting more risk and assurance based criteria for measurable outcomes to measure how a technical standard was implemented. And therefore, what is the trust and assurance of the widget, of the credential, of the token, of the of the authentication of the federation? So these pieces work within and on top of each other.

However, there's a difference between NIST as a national standards body and the process that it uses that it defines and has authority over to define its standards, which are very outcome based versus the processes that IETF uses to define its standards and to define its outcomes from a technical process perspective. They're all complementary. It's just that some are more industry and collaborative based. And in the NIST case, it's more authoritative under a singular government with its priorities of that government being at the center of that design. So you kind of think of those nuances.

ISO is similar to NIST, but from an international body perspective as well. So there's a little bit of a different kinds of tools. And the fine grained detail of the method is often set in technical bodies like W3C, like IETF, OpenID Foundation, whereas NIST and ISO are typically setting outcomes that are measurable on top of different technical methods. I hope that gives a little clarity on the differences between the two.

Yeah, I would also just add that NIST, the great thing about NIST is that everything they make is published, you know, anyone can read it. Some of the ISO work is not, some of it is, but that does change a little bit about the influence, right?

I mean, ISO is massive. When when ISO creates a standard in some countries, as I understand it, it goes into law. So that's that is the incredible power that both of these standards have. But I literally, I just had to show you, I literally have the 863 standard SP 863 here because it's kind of a daily reference, especially for the authentication side of the house. If you want to understand, you know, it not only talks about, it defines what different authenticator types can be, but it also gives the properties of what makes it that thing.

And so, you know, that is something greater than just the United States. It is a reference that I think is valuable in the entire, you know, globally, in my opinion. They've done a great job.

OK, so in the interest of time, let's look a bit at what is going on currently, what are the areas you say they are, you know, a lot of people are working on that and you feel they will impact the sort of the new future of digital identities. So anything that comes to your mind. I would start probably with everything around decentralised identity, which is still sort of a mix of things done, things under sort of development and also a lot of governmental initiatives, like you look at the EDI wallets and things like that, when you also look at EIDAS, the legislative thing in the EU.

So that would be my take on what is the hottest thing that is currently sort of very close to impacting our daily life and the reality of digital identities. Yeah, I'd say that definitely in an era where that's becoming a reality, where it's been kind of sitting around for quite a while, but there are, I think it's important to distinguish between a couple of different use cases that are coming out of that world.

The self-sovereign identity, for example, is a different approach from sort of a decentralised enterprise identity concept and where FIDO is going as well, especially on the consumer side, things like that. So the and then there's this mix of using something like DigWeb or a blockchain or a ledger of some kind to connect the trust systems. So there's a whole bunch of technologies that kind of relate to each other in a certain way. But enterprises are thinking about using them as a kind of way to do more of a business to business type transaction.

Retailers are looking, of course, to take advantage of some of the improved security like Pam was talking about around FIDO for consumers and that kind of thing. But then there's also a self-sovereign identity action and they are related, but I think they're distinct.

Pam, you want to go? I'll go after you. Sure.

I mean, I have a big list, like I have a list of 15 things that we could talk about, but if we're going to stick with decentralised identity, from my perspective, we actually need to stop with the plumbing specifications and we need to get much more detailed on the guidance of how to do it, how to use these things securely. So I would call out the Open Wallet Foundation, if any of you have heard of that. Open Wallet.Foundation is the URL for that. They are working on what the guidance should be for a secure wallet.

How do you know that the wallet you have isn't going to just rug pull your identities and run away with it? So that's probably the biggest thing. The other one that's very interesting in my mind is what's happening in IETF around ST JWT. So that is a Selectively Disclosable JWT, a JSON web token. And so the whole idea of that is that you can chunk up the claims in your token and you can cryptographically pull some of those claims out of the token and still serve the token and the token can be validated. So I think that one's got a lot of a lot of interesting feature in it.

Yes, because I think we have to think about a world where we have a lot of verified credentials we are using, when we think in all these things in scale or at scale, when things are so much bigger. So I definitely also am curious about the other, I think, 13 on your list, aside of the two you've already mentioned. But maybe we'll let Trony first.

Yeah, well, staying in the decentralized ecosystem side of things, I would say that we really look at the decentralized ecosystem as a gradient from fully open and permissionless to fully permissioned and more trusted with gradients in between, which often depends on the governance or the stack that's being used in those decentralized ecosystems or flavors of decentralized ecosystems.

And so for us, one of the things that we are very focused on right now is the concept that we would call trust registries in previous or existing language, that the words that were used around this were more of trust status lists, but that's evolved into trust registries. So if we think about trust registries, if we're in a very decentralized or hybrid decentralized ecosystem, trust registries provide a layer of verification of a pocket of authority around a particular credential or set of credentials.

And so that we know that when we have a trust registry, maybe that's a set of authoritative government data, maybe that's a set of authoritative data about professional credentials. But these trust registries assert cryptographic assurance and verification around the data in a particular credential. So you can have a very decentralized ecosystem with pockets of authoritative data that can be cryptographically verified, which I think is as we get more and more decentralized, where and how governance applies gets more and more challenging to understand.

So having authoritative trust registries for different sets of credentials, I think, is an important piece of assurance and verification in a very decentralized ecosystem. Yeah, I think that I mean, you describe the magic word without using the magic word, and the magic word right now in the standards world is attestation. Right. How do you how do you know the person or entity that you are talking to is the person or entity you think it is? Right. So the trust registry allows authorities, for example, or root systems to attest to the veracity of the statements being made.

And that is that's a piece that is widely developed in the standards world in about 85 different silos, every different type of identity, whether it's machine identity or, you know, certificates or, you know, PKI, any of that stuff, they all have their different attestation mechanisms. And I think that is one of the things we're going to see change in the next little while is that those systems are going to start being viewed as similar to each other rather than as, you know, sort of separate, special children in each of these different vertical silos.

OK, outside of the decentralized identity world, where do you see the most interesting things happening currently, which are on the road? So from my perspective, multi cloud identity is the most interesting sort of new area. So our workload identity is another way we talk about it. There is a working group in IETF called WIMSE, W-I-M-S-E, which I won't try to expand that acronym. But if you search IETF and WIMSE, you will get there.

What that is, is the folks who were the original authors of SPIFFY, if any of you are familiar with SPIFFY, have come together with the folks who do OAuth, that those communities have sort of realized that they have commonality and that they have problems to solve together. And they are working in that WIMSE working group right now to try to understand how you can safely derive identity, you know, from from your environment, how you can have different workloads in different clouds talk to each other. So I think that's a really exciting and important part of, you know, the new.

Is that a replacement for SPIFFY Inspire, or is that is that I'm just curious. I don't know. I'm not sure. I can't tell you that.

I mean, it's just starting. So I think the trick would be to get somebody on who's a super expert on that area. But it is specifically for workload identity and not so much for personal identity. It is.

Yes, that's right. Mm hmm.

Yeah, I think we're seeing a lot of interest in from a non-decentralized perspective, biometrics, photo ID capture. We're seeing a lot of interest in the tools that can help to verify that a that a physical identity card is authentic, as well as the combination of existing tools around credit file method identity. So identity verification, I think, is the big space, whether that's using government ID, photo capture, liveness, biometrics, credit file method, dual process method.

I think in our ecosystem, in the Canadian ecosystem in particular, we're seeing a lot of adoption around that at the front lines of trust for lawyers who need remote tools to verify their clients. What I think is also exciting about seeing that type of identity verification tools adoption is that it also helps to demonstrate to authorities like governments that there is demand for digital credentials that people and organizations can use, whether it's verifying real estate or mortgage transactions or higher value transactions.

So I love that these are getting adopted to also provide real demand numbers to those authorities to know that we have a need for these types of digital credentials and particularly government issued digital credentials. I would I would just add that speaking of economic incentives, the FinCEN, which is a U.S. financial crimes enforcement organization in the government, they just released that in 2021 alone, there was two hundred and twelve billion dollars U.S. in identity related fraud. So if anyone is wondering why identity verification is suddenly very big, it might be related to that.

You know, I see in Europe, for example, especially where there where there is this desire to have really strong digital identities that are bound to a physical identity. But I also see with what's happening in AI as you start using something like a GPT or an agent that then goes and does things on your behalf. And even even in the case of searching Google or Bing or something like that now, that identity is not necessarily transferred.

And so there's there's some disruption most likely going to happen in both the search market, but certainly with almost any business in that you may not be directly you might have kind of a virtual identity that is that is not directly you. We could be acting on your behalf, doing something very specific. So so on the one hand, we're getting like really strong physical credentials. And on the other hand, we're kind of moving away from it with with AI. Right. And I think you're directly leading over to the next section of our talk, which is about what is lacking.

And I think this is one of the areas that will become extremely interesting. So how do we deal with virtual incarnations of ourselves that act on our behalf? I will not have multiple of them, which is different, so to speak, entitlements. And it goes also into this huge world where a lot of things already are there and a lot of things are happening around identity of things. And how are these related to each other, relationships, things. So I think this is a huge area for itself. When I look at things that are that are, to my understanding, still open gaps.

So we talked a lot about identification and authentication. We didn't talk about. Authorization, I think that's in the authorization field.

Also, maybe we're on policies. We still have some. Some open gaps, and I think we have another very interesting point here from from the audience, which is asking about do we have now a workable standard for application developers to expose the entitlements catalog of their application and access right assignments to facilitate onboarding in and governance by IGA solutions? So how do we expose really at a very fine grained level of the entitlements catalogs and the current state of entitlements? Which is. Maybe a bit more detailed than Skim currently does.

Well, I thought Johnny was sort of bringing that up earlier with that. I mean, that's it's an approach. It's not per se an IGA approach, I wouldn't say. Right. But the trust framework idea, at least it gives you, it gives you some, you know, for lack of a better term, verifiable credentials. So you have trustable attributes, at least.

Yeah, but it's the other side of it. So the one thing is I come in and I say I have sort of trustable attributes or verified credentials. The other side of it is you have an application and that application says this is, these are the entitlements, so to speak, you can order, you can use, you can assign to someone, and this is the status of assignment, which is an IGA problem, which is, I think, a very interesting, very important problem, which also is a bit about making things more dynamic. So because these models may change and they may need to be updated very rapidly.

So I have to say from what I know, no standard or no standards initiative I'm aware of is looking at this. So maybe Pamela, it's one of the remaining 12 items on your 15 item list. So I think there are places where that specific thing is being discussed. There is an entitlements draft in SCIM, which is just the mechanism of how you could look up the entitlements that go with a given, you know, for a given domain.

There, I believe, is discussion going on in WIMSY. There is also discussion in a group called the AuthZen working group with an OpenID Foundation. And by the way, if you want to join OpenID Foundation, it's a very small fee to join as an individual. I think it's $25 or something. So if you wanted to go be part of that conversation, it's very affordable to do so. But here's the issue I have. The problem is not the technical plumbing.

I mean, this is a perfect example. The problem is semantic. The problem is that my, you know, my definition of an entitlement could have exactly the same name as your definition of an entitlement and mean something absolutely, completely different.

And, you know, that's where, you know, that's why WIMSY is interested, because that's the multi-cloud piece of this, right? OPA would be another example of a case where you're trying to define everything about a given, you know, a given relationship, a given policy.

And yeah, there's just there are big problems that that aren't solved with standards in this area, in my opinion. But back to the three of you, what would you love to see as an area where we have standards where you say, OK, we are not yet there? So I just and to follow on to Pam's response, I think that. Some of these answers really depend on the jurisdiction that you're in, and so they're not always when we say we, you know, we might be we Canada, we US, North America, European Union. So we don't always have a common set of criteria for what is needed in our ecosystem.

But I will say that in one of the things in the Canadian ecosystem that I think is very much needed is this policy based definition of entitlement from an entitlements perspective and a policy based definition of a Canadian citizen and residents entitlement to access and control authoritative data about themselves and government's duties to provide that data and authority to provide that data to their citizens and residents, whether those citizens and residents are acting in personal personas or whether they're acting on behalf of businesses that they own or that their directors or different qualifications.

So it's not quite GDPR. We don't quite have that code of that that entitlement to access and control authoritative data about us codified into policy. And I personally believe that if we did have that policy data governance codification around authority and duty to provide, as well as an accountability model where trust frameworks do come into play as well. But I think that's the fuel that really powers the identity standards, the verifiable credentials, the wallets. I think that's the fuel that powers this ecosystem, whether it's decentralized or more traditional federation.

OK, so. A lot of areas where we still have to work on, a lot of things going on, a lot of stuff which is there and where a lot of people have done a fantastic job over the past couple of years, and I think we definitely made a lot of progress, progress around identity standards when we when we look back over the past couple of years. But I have a couple of questions here from the audience, and I want to throw these questions on you and ask for relatively short answers here. So. With GDPR and the focus on not provisioning non-active users, we see that trust and time provisioning might grow fast.

Any thoughts on that? Yeah, I mean, it is already fast, just in time provisioning is, I think, very, very common because it doesn't require a whole lot of infrastructure to do. So for anyone who's not familiar with just in time, it means that at the time you have a single sign on, the time you log in, your data is included in the token that you single sign on with rather than having a big pushing provisioning thing in the back end. The problem with just in time provisioning is that there is no deep provisioning.

So, you know, just in time provisioning does not solve the GDPR issue. Right. As long as GDPR, it also requires you to remove the user promptly at the time the user loses access.

But yeah, but there's maybe also the point that we potentially can't trust automatically provision and reprovision again. So that would be one solution. The other thing is, I think there's also the element of just in time access, which means really saying, OK, what are people allowed? This brings us to authorization. So saying you don't have any standing entitlements anymore or standing privileges, which are anyway problematic, which also would sort of solve a bit the problem that was touched on in a previous question around how to expose entitlements.

So if there are no entitlements in the application because the application at one time just asked for an authorization, then it still means you need to expose some things around policies and what could be asked and so on, what needs to be in the policy. But at the end of the day, we would probably get rid of a lot of problems that are based on today's approaches of static entitlements. So I think it's definitely an interesting area. Anyone else who wants to add to this question or response?

No, I would only say I do agree that not having standing access is a basic security hygiene reality now, like you should not have privileged roles attached to you every single day. And being able to to step into those roles is important, but also having a system that's assessing the risk in real time and and telling you when people have stepped into inappropriate roles or telling you when people have behaved differently when stepping into those privileged roles is really important, too.

Yeah, it's it's actually an important distinction to when we talk about just-in-time access versus just-in-time provisioning, you can lose access but then still keep the account on file. Right. So that's that's normally what you do with just-in-time access is you retain the account itself, you cut off the access. So that's more of a security concern and less of a GDPR one. Right. So of course, it's possible to create a routine that continually cleans out the actual account. I just want to point out that that's the distinction.

OK, and next question. How do you see SSF slash CAEP evolve? I have to admit, I'm a bit lost because I don't know which what is exactly meant SSF slash CAEP.

But Pam, you surely know. I can tell you SSF is the Shared Signals Framework. And it is. Yeah. And CAPE is a profile of a type of signal that you can send through the Shared Signals Framework. So I see SSF and CAPE getting more and more pervasive, more and more embedded as just simple plumbing that's in every application. And the reason for that is because nobody can base any kind of risk mitigation on expiring tokens. If your token lasts an hour and you get breached five minutes in, that extra 55 minutes is not acceptable in today's world.

So, Joni, you probably have some thoughts on how those token lifetimes have to be managed. No, I do have a lot of thoughts on token lifetimes and disappearing proofs in the distributed ecosystem as well. I'd like to see I'd like to see that those for use cases based.

But no, I don't have I don't have too much to add, except that I would say fully agree that shared signals is an important feature set. We're not deeply embedded and involved in that. But setting your risk profile for how long those tokens should exist or what they I think there's underwritten work or underestimated work in determining your risk profile of your ecosystem and what your tolerance is for how long that token should exist or be valid within that ecosystem. So don't underestimate your risk assessment and what your what types of transactions your ecosystem is performing.

OK, great. We are already close to the end, to the top of the hour, to the end of our panel. To wrap it up, I think we've we agree that there has been a lot of positive evolution around standards, around identity standards in the past years and decades. There are definitely a number of very interesting things currently going on, which are around machine identities, which are around decentralized identities, which are around shared signals, which are also increasingly around our sourceation policies. So we see quite some evolution happening here.

And I think this is what I personally feel is super important that we have the people who really and the organizations that invest, spend time in working on standards. And so I personally believe this is super, super important. And as I've said before, that is something I just want to quickly, so to speak, bring up again.

This will be also one of the things we will look at very deeply at our upcoming European Identity and Cloud Conference, where the standards are always a very important topic and where a lot of discussions over the past decades we have been running the conference, it's always, yeah, 17 years or so. There have been always a lot of discussions about standards, a lot of people meeting, bringing in new ideas. So definitely don't miss to be at BIC.

With that, I think it's about me to thank first you, Tony, you, Pamela, you, Mike, for participating in this panel and this webinar. Saying thank you to all the attendees that brought in their ideas, their comments, why I had a chat and why I had a Q&A. So there were quite a number of comments. Also some very valuable hints on the links to standards, initiatives, et cetera, all showing up in the chat. So thank you very much for being so active in this webinar. And there will be a couple more of these Road to EIC webinars in the next coming week. So don't miss them.

I hope they all will be as interesting as this one has been. So thank you again for being here and being part of this event. I hope to see you all in person at EIC so that we can exchange our positions, our thoughts, our ideas when meeting in person. It would be super. Thank you. Thank you. Thank you. Hope to see you in Berlin.

Bye, everybody.