Policy enforcement decisioning have to be very local, but the
policy itself that's going to be used in the in the policy
decision engine, it can be pushed in so it can be
administered somewhere else and then pushed in.
So that it basically is, you know the policy decisions
running locally and that that addresses the performance
concerns which a lot of these SAS applications are going to
have in in these situations. So I guess that's the benefit of
standard, right? Is that absolutely all the
applications can kind of subscribe to the same standard
and you get greater adoption of this model?
Yep, yes, I mean that. And again, this is this is not
available now, this is still early.
This is some of the evolution of all of Zen and where it, you
know, where it's sort of going to, but it's to enable some of
these use cases where, you know, a policy can be developed, you
know, and controlled by a, you know, a customer organization
and pushed into lots of different SAS applications.
So they all you know, so you all have individually different
policy that you can use in those situations.
This is identity at the centre if it has anything to do with
IAM. This is the go to podcast now
your hosts Jim McDonald and Jeff Stedman.
Welcome to the Identity of Center podcast.
I'm Jim McDonald. I am not joined today by Jeff
Sedman. Unfortunately, he was not able
to make it today due to business travel, but I've got a great
show lined up for you today. We're going to talk about
adaptive authentication and fraud prevention.
So if that's right up your alley, you're on the you tuned
into the right episode. You know, before we get started,
it's our tradition to go through our discount codes.
I've got only two today, but there are big ones if you're
going to the European Identity and Cloud Conference that are
known as EIC 2025. It's in Berlin and the dates are
May 6th through May 9th. We've got a code, it's IDAC 25
MKO that gets you 25% off the conference rate.
The second conference discount code we have is for Identiverse
2025. It's in Las Vegas.
It's that's the Mandalay Bay this year.
So if you haven't been to Mandalay Bay, it's going to be
exciting for that reason, but it's always one of the best
conferences of the year. That's June 3rd through June
6th. We're going to have you use the
code IDV 25, dash IDAC 25. That will get you 25% off these
two codes. By the way, you're not going to
find better out there. So I get the temptation to go
out to Google and look for discount codes.
I'm just going to let you know ours is the best one available.
So as I mentioned, we're going to talk about adaptive
authentication and fraud prevention.
Joining me today is Patrick Harding.
He's the chief product architect at Ping Identity.
Welcome to the show, Patrick. Jim, thank you very much.
Thanks for having me back. Appreciate it.
Yeah, I'm really glad to have you here.
Let me ask you a quick question. Are you going to be at night
Danvers this year? I am actually going to be at
universe, yes. Also probably going to be at EIC
as well so I'll be at both. Oh good, good.
We can. We can share a beer and one or
both, or not share a beer. But I have a beer at the same
time and the same. Value, Jim.
I'll buy. I'll buy you a beer.
How's that? Let's do that.
All right. All right, And I don't have to
share with anyone. That you can do.
It's all yours. All yours.
I can. Almost Yeah, my my girlfriend
might have might argue with that, she might want me to share
with her, but. Well, there you go.
So Patrick, you, it's kind of our tradition around here to ask
how did you get into identity and did they choose you or did
you choose it? Actually, so Jim, I'd say it's a
little bit of both. Back in the day, late 90s, I was
doing cybersecurity before it was called cybersecurity,
actually doing a lot of firewall infrastructure, network security
infrastructure, things like that.
In the kind of the early days of the web at a company called
actually Fidelity Investments in Boston, I quickly realized at
that time that poking hose holes through firewalls kind of wasn't
going to be the right approach to secure web interactions and
stuff like that. So I ended up looking and
thinking about kind of identity and, you know, those sort of
things. And actually coincidentally, at
around the same time, Scott Mcneely, the CEO of Sun
Microsystems, contacted the CEO at Fidelity and said, hey, Ned,
there's this thing called Microsoft Passport that I'm sort
of worried about basically. And, you know, think of it as
centralizing all authentication on the web, owned and controlled
by Microsoft. We don't think that's a good
idea. We'd like you and a bunch of
other companies to join us at this thing called Liberty
Alliance and you know, come up with approaches to basically
deal with that. Obviously back at that point in
time, you know, 2000 and one 2002, Microsoft's reputation was
very different than it was than it is today.
I would say. So if Fidelity joined, I got
involved and that work at Liberty Alliance ended up being
the foundations of what was what became SAML or SAML 2 to be more
specific. That work I did with SAML 2 led
me to Ping Identity where we started to do the first, you
know, Federated single sign on capabilities, dedicated
Federated single sign on and you know, gives me 20 years later
basically, you know, still, still solving identity problems
because, you know, we, we, we, we, we never finished it seems
basically. It's kind of a cool story.
I kind of feel like you just said something like, so I was
sitting there with Thomas Jefferson and John Adams and we
were kind of talking about, Hey, what if everybody came to the
table and voted for the leaders and, and, you know, like had
that level of conversation because you just being dropped
some some heavy hits in the beginning of, you know, identity
kind of becoming what it is. So I thought that was a pretty
cool, pretty cool story. Put you right there in the in
the as a founding father. Yeah.
Well, it was early days, definitely.
And it's it's kind of come a long way.
Obviously we'll talk later about the evolution of Samuel and Open
ID Connect and stuff like that. But yeah, there's a there's been
a lot going on over the years. Yeah, yeah.
So I wonder every once in a while I like to do a topic that
you kind of feel like, all right, we've been talking about
this for a decade or more, maybe 2 decades.
And it's kind of old hat. But we got to remember new
people are coming into the industry and trying to kind of
wrap their brains around some of those.
And I had a recent conversation with one of my colleagues and he
was asking me about authentication and more
specifically adaptive authentication.
So he had a SAS application that he had a particular part of this
SAS application that this kind of that admin section and he
wanted to force users when they access this part of the
application to give a multi factor authentication.
So it's kind of like the the classic use case for adaptive, I
think. And so I was thinking this would
be a great topic for a podcast and then you and I started to
collaborate about having you on. I thought you'd be the perfect
guess to talk about this. So I'm just starting with, I
want to start, Patrick, with, you know, what are some of the
questions that you had asked this friend of mine in terms of
trying to uncover what he was trying to do?
So what what he's trying to do is something we used to be able
to do quite easily actually back in the days when we were, you
know, when organizations were running these applications
themselves in the data center. We had, we had much more
flexibility in terms of being able to apply policy essentially
to, to different things. And I would say I, I would point
at the, the WAM products, the web access management products
back in the day like the site minders, the Oracle access
managers, you know, the Sun had a product in that world.
Everybody had a product in that world.
They, they were actually very good at helping companies
actually do this. We can, we can talk about why,
but with the evolution of SAS, you know, SAS really emerged
where the, the point of SAS was that it's going to be easier and
simpler for you to, you know, to, to use this application, you
know, Mr. Enterprise, but we're going to take away a lot of
flexibility, all right? We're not going to give you all
the bells and whistles you might have had if you were able to run
this same application on premise.
And so that if you're going to get what you get and don't get
upset, as I used to say to my kids basically.
So you know, that's really, you know, the fundamental sort of
issue here is that SAS applications have not done a lot
over the years to cater to, you know, different enterprise
requirements that might emerge on a case by case basis because
they don't give you a lot of flexibility.
I, I kind of had the same thought pattern that you just
went over there where, you know, when you had what we call legacy
authentication or web authentication, web auth and
systems, you'd have essentially some sort of filter in front of
your web server that would examine every request that
you're making. And you can set a policy that it
would look at that HTTP and say you're trying to access slash
admin. We're going to kick it back and
determine whether or not you're authenticated at the right
level. And if not, we're going to step
you up. Absolutely.
That's where I started as well. And then I started to think,
well, you know, there's the legacy piece, but there's also a
lot of application now, single page applications.
And you can't always just do URL filtering.
So it's that too. So I think I so in, in terms of
that really, you know, so where we are today, I think in so we
don't see a lot of adaptive authentication being enabled on
SAS applications. We are we still seem to see it
though on I'll say and when SAS applications are more focused
on, you know, for enterprise and for workforce, things like that.
But we do do it see it in our customer facing applications
where organizations are building and developing and deploying
those applications themselves. Because you know, to me
adaptable adaptive authentication is actually a
authorization or policy enforcement problem.
You, you basically need to apply policy at certain points in the
application where you where you want to make a decision on, OK,
do I want to essentially reauthenticate, step up the
authentication, whatever it might be at this point on this
transaction essentially. And as you said, when we had WAM
products, web access management products, we could use a web
agent or a, or a proxy as, as a place to do that enforcement.
You know, we could check a certain URL, things like that.
You can also do that with AP is as well.
API gateways can do the same sort of thing, which is how you
might address it with single page apps that might be talking
against APIs as opposed to sort of legacy sort of, you know, web
interactions and stuff like that.
So we can do adaptive auth on applications, SIM applications
that are built and deployed by, you know, different, you know,
by our customers, but much more difficult now to do it with SAS
applications because we don't have the ability to do that
enforcement so easily. Essentially, you're kind of at
the mercy of the the provider of that application, right, the
service provider. Absolutely.
So the one thing they've done is they've enabled, you know,
single sign on, all right. So they've basically given you
flexibility to control how authentication's done.
And we do that with things like SAML, you know, SAML mostly with
SAS applications, but, and that allows you to sort of do
adaptive authentication at login time because you control, you
know, you, you control the login essentially as an organization.
So you can basically make a, you know, a decision at that point
based on different factors about what level of authentication you
might want at login. But once the once the user is
inside is is, you know post authentication interacting with
the SAS application directly. Very few SAS apps give you the
controls the policy controls to allow you to make policy
decisions at different points in the applications for.
Different places, right? Anywhere other than the front
door, right? Pretty well, yeah.
So there's been, so there's there's been a sort of attempts
and efforts at that. So if you think, if you look at
the what was called the Casby market, like the cloud access
security brokers, I think they were called, they've acted as
proxies in front of SAS applications.
So you know, there's an element of, of of attempting to apply
policy there. But that tends to be more, you
know, sort of risk based where if they think there's this is a
risky device now they might automatically push you out to
get you re authenticated. It doesn't allow you to do very
easily do policy that says, all right, on this transaction type
with this entitlement in this situation, this is, this is high
risk. And I want you to
reauthenticate. Think, think of, think of the
analogy to a banking application, all right, where
like a, you know, we, we have a, we have a banking application
and you know, they want to set policy that says, OK, if it's
high risk, if it, you know, if I think the user's high risk, then
reauthent, reauthenticate them, you know, adapt, you know, adapt
the authentication. But they have other policies
that says if this is a payment, all right, automatically re
authenticate them. Or if this is a payment and it's
over $10,000, re authenticate them.
So there's certain, you know, application transaction types
that can get quite granular where they look, you know, that
are considered a high risk. And and you know, not every
organization is the same, not not every bank's the same, not
every customer of sales force is the same in in their risk
profile. And that's where we've lost that
level of customization on the risk policies that people might
want to put in place, I would say.
Yeah, yeah. And you're getting into an area
that I really want to explore, but you've mentioned the earlier
that got me thinking about, OK. So if the depth of
authentication, it's hard to do it kind of that that next level
which I always call that coarse grained authentication or coarse
grained authorization. Right.
And it seems like this, you know, kind of SAML IDT model
really works at like the resource being like the front
door for the application, like you either have access or you
don't have access. Maybe we're going to send some
attributes in the payload, but for the most part, based on how
you come in and you were talking about the device luxuriacy, but
there's more context to it, right?
At least the kind of the way I conceptualize it in my head is
you've got the the actor, which has a context.
That could be the device, it could be where the person is
coming from, it could be, you know, several different
attributes about that actor and they're trying to access a
resource. And at some level, I mean, and I
don't know if it's just marketing buzz or if this is the
way it really works is that the actor has a risk score via that
score of like, you know, very low or very high.
However, it works and the resource has a risk score and as
long as the resource matches or is better than the excuse me, if
the actor is less risky than what's required to access the
resource, they get right in, but if not they get challenged.
Is that kind of the way it's working in like the modern actor
or modern description for adaptive authentication?
Really. Yes, somewhat.
I mean, I just think that with SAS apps, there's, there's,
yeah, from what we see, there's just limited controls right now,
I think. And and I don't think we can
really apply the agent prop, the agent model or the proxy puddle
very well. And it's also very difficult.
I mean, we've externalized authentication from these SAS
applications, but externalizing authorization is actually much,
much more difficult, All right. And the SAS applications
themselves really don't want to do that as much as possible.
But one of the one of the things the SAS applications have done
is they've exposed APIs to allow you to programmatically control
entitlements. All right, things that you're
allowed to do. And that's something we never
had on traditional on Prem applications like, you know, we
never had that level of programmatic control where I can
call an API to adjust the entitlements.
It used to be you had to go into the database and change them
manually or go through some, you know, weird web console to do it
and stuff like that. So what we can actually think
about doing now as an alternative to this actually is
to think about it as you know, you're standing privileges of
what you can do in this SAS application are fairly limited
and that you might be granted privileges to do certain things,
you know, for periods of time. So as I mentioned, quite often
when you want to do adaptive auth, it might be on higher risk
transactions like I want to download the financial data for
the company or, you know, I want to approve a, a money transfer
of X, things like that. So you could actually think
about this now to say, all right, maybe by default, I, I'm
not allowed to do this and I have to request permission
basically with a with, with basically just in time access
where I rest request permission for this entitlement, it gets
approved. And then I'm able to do this for
some period of time, maybe 15 minutes, 20 minutes.
And then it's then it's taken away from me basically.
So it's another way to think about how to control and limit
risk essentially, which is what this is all about limiting risk
on what people can do in these applications essentially.
So it's just a slightly different approach, but.
It works within the constructs of what SAS applications allow
you to do right now essentially if they have this API based
access to control entitlements. I want to get into the other
scenario that you're talking about.
You were giving that banking example and you know, further, I
can't really go back to my original example.
Talking with this colleague, he actually wanted to do more than
just protect this admin application.
You want to say, well, kind of take it to the next level and
I'm going to make up an example that there's these workers from
France and if somebody goes in and wants to access their
account, that within the admin application, actually if they
want they want to access their account or change their account,
that's when we would kick him in the backroom.
So in other words, we would trigger that risk score based on
a an action and that action might be based on the data.
So it's kind of like, you know, if you're transferring 10,001
dollars, it gets flagged. If you're transferring 10,000,
it doesn't, but it's based on the data and some kind of policy
or rule set. Yep, that seems to me like
that's advanced fraud analytics. That's more than your typical
IDP is going to achieve for you, right?
There's there's some kind of additional system that is kind
of examining that process, is that right?
Yeah. I mean, unless the application
itself like a sales force, you know, I'm talking about
workforce applications now, like a sales force or a service now
or a work day, unless they build that in directly into their into
their applications, you know it, you know, they're going to have
to take those requests from customers and sort of add that
capability basically. And you know, not a lot of them
are doing that where just because what, what is considered
risk risky for different, you know, different customers is
different. Basically the fact is that in
this case it was France. France is a big deal.
They've got to they won't have different policies because it's
a French, it's a French user, non French user.
That might not apply for other, you know, for other customers.
What but what I think can be done and what's evolving is
standards that allow us to externalize policy from the SAS
applications. The SAS applications might make
the policy decisions and, and, and the enforcement themselves,
but the policy itself as opposed to actually, you know, creating
it inside the admin console of Salesforce based on what they
can do. There are opportunities to
externalize that and use standards like emerging
standards like Author's Ed or ZED or Zen or Zen, I should say.
Also. Zen yes, as a as a, as a
mechanism to build those policies externally and then,
you know, push them into the applications essentially so that
that starts to give you the flexibility of all right,
different, you know, different policies can be written by
different customers, but they can be enforced by the
applications and enforced locally basically in this
situation and that gives you more flexibility.
So the application winds up reaching out to this external
process. I was wondering if there's
actually like some kind of proxy that data would.
I would, I would, I would say it's working the other way.
One of the things that when you, when you talk about centralizing
authorization is that if you think of there's policy
enforcement and policy decisioning and you know,
basically those things generally need to work very fast.
All right, You can't, you can't be calling out over the Internet
for every policy decision to be made.
You can't be phoning home like Salesforce can't call back to
their customer for every policy decision to be made.
Essentially, it's, it's just too slow.
So policy enforcement decisioning have to be very
local, but the policy itself that's going to be used in the
in the policy decision engine, it can be pushed in so it can be
administered somewhere else and then pushed in.
So that it basically is, you know the policy decisions
running locally and that that addresses the performance
concerns which a lot of these SAS applications are going to
have in in these situations. So I guess that's the benefit of
standard, right? Is that absolutely yes, all the
applications can kind of subscribe to the same standard
and you get greater adoption of this model.
Yep, yes, I mean that. And again, this is this is not
available now, this is still early.
This is some of the evolution of all of Zen and where it, you
know, where it's sort of going to, but it's to enable some of
these use cases where, you know, a policy can be developed, you
know, and controlled by a, you know, a customer organization
and pushed into lots of different SAS applications.
So they all you know, so you all have individually different
policy that you can use in those situations.
I'm kind of getting the sense from this conversation that it's
really like the the benefit of a SAS application is that it's
easy to get integrated with initially.
You can provide the services and a pretty good level of security,
at least from an authentication standpoint by integrating into
your IDP. The downside is that if you want
to get real fine grain, you know, there's only so much that
you can do. So that's kind of where I
summarize where we are so far. But something that's in the back
of my head is also, you've got SAML to as the methodology to
integrate, you've got Open ID Connect.
And I'm wondering if there is, if the ability to handle
authorization is part of the reason why you would choose one
over the other. Is there a major advantage to
integrating with Open ID Connect versus SAML when it comes to
this whole topic that we're talking about and being able to
either Dr. Adaptive authentication or, you know,
have more control over authorization?
So this, so it's interesting, I think it's, it's, it's
interesting how SAML has become sort of the, the de facto
default SSO standard for enterprise SAS applications.
And that was originally driven by Google and Salesforce
adopting it back in, I don't know, almost 20 years ago.
And generally speaking, most SAS vendors now kind of adopt that
by default because they know that most of their customers are
going to have a SAML IDP capability.
But there hasn't really been much innovation happening in
SAML for the last 1015 plus years.
It kind of works. It does it's thing where where
we are starting to see innovation still is in the Oauth
and Open ID Connect world. And even though I'd say today
Open ID Connect doesn't offer any major advantages, probably
the, the one major one is it's kind of easier to set up and
configure and you, you can avoid some of the complexity around
certificate management and stuff like that because it can be more
dynamic in it's nature that, you know, some of the innovation
emerging there. Well, any innovation we do is
going to emerge in those areas. So I, you know, that's why I
believe all the Zen is actually part of the is happening within
the constructs of the Open ID Foundation.
All right, so it's close. It's going to be closer to Open
ID Connect than ever. It's going to be the SAML.
So definitely as we evolve to some of these newer protocols to
address problems, you know existing problems, they're all
happening in that open ID connect oriented world.
I don't think there's ever going to be a pre req that you need
open ID connect, but it it's all happening there and I think will
evolve there over time. And you know, most generally
speaking, any customer today that has a IDP that supports
SAML, that IDP is also going to support Open ID Connect as well.
So it's not like it's it's more the SAS vendors themselves
choosing to build something beyond SAML, given that that's
been the default for so long. So it's the advantage that there
are today, but it's also where everything is heading, or I
shouldn't say where everything is heading, but if you're
expecting innovation, especially like things to do with Austin,
any kind of let me just make city easily where things are
heading. If you have the choice between
Samuel and OIDC, choose OIDCI. Think you made the point earlier
though that you know, if you look at a basket of size
applications, it's more than likely that the majority
supporters, Samuel, they're still, I always find it like
amazing and there's an enterprise grade application
that doesn't even support SAML or that they they charge the
integrate via SAML. And that I was going to, I was
going to mention that there's two things actually.
So one thing with we've seen over the last few years is that,
you know, a lot of a lot of large organizations still have a
lot of, I'll call them on premise applications or
applications that might be now deployed in, in their, in their
cloud infrastructure, basically as cloud native, like running in
that customer's AWS environment or GCP environment or Azure
environment. So, you know, I'll just say it's
a, it's a derivative of on Prem. It just happens to be in their
cloud. They still want single sign on
to those applications. And actually what we've seen
there is, you know, 15 years ago, 10-15 years ago, they might
have used a web access management product.
They've actually instead now shifted over to support Open ID
Connect. So you're seeing Open ID Connect
used for those sort of on Prem cloud native applications that
the enterprise is using, but it's quite often SAML for the
SAS applications. So I could definitely see SAS
applications evolving to Open ID Connect as well, just to make it
consistent across the organization actually.
Do you find? That do.
You find that the level of refer to.
Let's say, you know, you had some application that 10-15
years ago you wanted to quote UN quote webify and you had a
consulting firm come in. They they filled this app.
It's not integrated even with SAML, but now's the time.
It's like maybe you have it behind a reverse proxy, but you
say it's not going anywhere. You want to get reverse proxy
out of your environment and you say OK well I could convert it
to SAML or OIDC. Is there a significant
difference in the amount of effort to do one over the other
and is that driving developers decisions a lot of times?
Yeah, I think, I mean, traditionally, you know, you
know, we learned a lot from SAML.
The Open ID connect is definitely a lot simpler.
Just you know, because we learn a lot from, you know, you know,
there were certain mistakes and things we did in SAML that, you
know, we chose to fix an Open ID connect.
And actually now with with open ID connect, there are servers
and even, you know, web agent plug insurance and and proxy
plug insurance like nginx plug insurance to and you know, open
ID connect enable your applications.
Like a guy that used to work for me, Hans, you know, built, built
the Apache, you know, you know, the Apache and the nginx mod
open ID connect as a, as a plug into Apache that you can
basically use to open ID connect your applications.
So it's a, it's a lot, you know, it's, it's, it's a lot, lot
lower barrier to entry to have your application support those
protocols right now. So there's really no reason they
shouldn't, essentially. Yeah, absolutely.
I want to go back to your. I want to go back to your point
though, about SAS applications now charging for SAML and what,
what, what completely freaks, you know, freaks me out here is
that I've, I've heard more, yeah, more and more SAS vendors
are charging for their enterprise grade features.
I'll say that you've got to pay extra for them.
And those enterprise gauge features include SAML single
sign on. But now there's, you know, you
know, companies emerging that are saying, Hey, we, you know,
you can, we'll give you single sign on to your SAS
applications, but but do it in a way that you don't have to pay
the SAS vendors to support it. And the way they're solving this
is actually through password vaulting, all right, which is
basically goes back to what we were doing 20 years ago in, in
terms of password vaulting people to get access to these
applications. We've now gone back to it
because people don't, don't want to have to pay for single sign
on anymore through things like SAML and stuff like that.
So it's kind of, I don't know, kind of annoying anyway.
There's a website called SSO dot tax.
It's kind of the single sign on Wall of Shame.
OK, I hadn't actually even heard of that.
That's interesting. I've got to go check that out.
But yeah, this is like it. You know, you try and do the
right thing and, you know, capitalism gets in the way.
I'll say that. So, Patrick, in the future, you
know, you keep hearing about these AI agents and they're
going to play a pretty heavy role in terms of how we get our
work done. And I think adaptive
authentication winds up playing a role in that because we wind
up delegating work to them, right?
So they're authenticating on our part.
They're essentially, you know, pretending they're us or getting
work done for us. And obviously, there's the
potential that they will be seen as robots, bad code, malicious
code, whatever you want to call it.
Let's keep the basic and first start with this concept of AI
agents. What are AI agents?
And then feel free to kind of go off on what I just said, whether
I was right or wrong, You know, how does this topic of adaptive
authentication fraud prevention play into, you know, this AI
agent future? Sure.
So, but we've been thinking a lot about AI agents over the
last probably 12 months and the impact they're going to have and
the impact's going to be huge. And I don't think people quite
understand yet how big an impact they're going to have.
Honestly, the, you know, we kind of didn't touch on it earlier,
but you know, one of the key points about adaptive oath is
the fact that, you know, it might not be policy based, it
might be risk based. If you get a risk score back
from your fraud system, you might choose to adjust how you
authenticate. That's a really traditional sort
of model. And those frisk and fraud
systems quite often are looking to detect bots and stuff like
that to prevent ATATO attacks and things like that.
So then, you know, as we evolve into, you know, the notion of AI
agents, you know, think of, you know, to me, AI agents are
different because they are processes that can actually, you
know, reason and dynamically change over time.
So unlike a traditional computer process where you have a certain
set of inputs and you, you know, you know, you're going to get
the same outputs every time, AI agents evolve and the input, you
know, you know, the inputs one day will drive different outputs
over time as they, you know, as they dynamically learn, you
know, they reason, you know, they, they just, they get
smarter over time, stuff like that.
So a lot, a lot changes with the way you think about an AI agent.
So AI agents are going to sort of appear in a couple of
different ways. Where I think it gets
interesting is when AI, an AI agent can actually interact with
a gooey, like the gooey that's on your on your laptop and it
appears like a human. All right.
I mean, this is like what the operator operator tool from open
AI does. It'll literally drives the
browser and it does that while it actually, you know,
basically, you know, tries to complete a, a task or a set of
tasks. So now if you can imagine you've
got AAI agent on your desktop that's basically looking to do
things automatically add things to your calendar, automatically
update Salesforce with certain data that you got thick that
that's, that's workforce examples in consumer examples,
it could be automatically search across 3 websites looking for a
cheap pair of jeans and then buy those jeans, stuff like that.
Whatever it might be. We now have to basically, you
know, AI agents are going to see, you know, be used.
How do websites differentiate an AI agent from a bot?
All right, where traditionally we've thought of bots to be bad.
So we have to have ways to basically distinguish an AI
agent from a bot. And then we have to have ways
for that AI agent to be able to authenticate through that
website, all right, such that it can do things on behalf of the
user. One of the, you know, one of
the, you know, and obviously adaptive fits into this in many
ways because we're going to adapt basically understanding
whether this is a bot or, I'm sorry, an agent or a human.
And if it's an agent, we want to handle authentication
differently, things like that. The in the case where the AI
agent now needs to authenticate, the last thing we want to do is
have the AI agent essentially impersonate the user.
And by that I mean just use the credentials that the user
generally uses. So I don't want the AI agent to
basically just take my ID and password and log in as me.
All right, What what we're creating at that point is
essentially what's what, you know, what we, what a lot of the
in the banking world, the Yodelies and the mints have the
world did when they did screen scraping to basically use my
banking credentials and log into the bank, screen scrape stuff
and return it. The banks hated that.
And you know, there's all sorts of security risks associated
with that and AI agents, if we don't fix this or address this
and just going to do this, you know, 10 orders of magnitude
more, it's going to happen everywhere.
So what we really need to, you know, address or push for is the
notion of delegation. All right, by Patrick and going
to delegate this AI agent to go do this on my behalf.
So that means applications that want to be kind of agent aware
need to sort of support this notion of delegation where, you
know, I can delegate responsibility to this agent
acting on my behalf to do things basically.
And you know, the agent still has to authenticate itself, but
it can do that. You know, we, we can start to do
that in ways that doesn't require, you know, similar to
the ways we might have done this with sort of traditional Oauth
and stuff like that where you, you consent to an Oauth client
to act on my behalf to do things, things like that
basically. So that's what.
We're going to evolve to yes. I mean, you think, think about
the way you talked about there with so, so the security problem
is systems that are meant to detect bots, while the AI agents
are bots if they're doing their job by saying you can't proceed,
but they're good bots. So now the question is, how do
you tell the good bots from the bad bots?
So we're, we're actually looking at, we're actually looking at
ways where a website can advertise and, and, and, and let
AAI agent know that, hey, if you're an AI agent, go do this,
all right. And it basically, you know, it's
kind of lets the AI, it tells the AI agent what to do
essentially. And it would be distinct from
what a human would be doing if they're interacting with the
website in that way as well. So it, it's, it's challenging
and actually it's going to force a lot, a lot of organizations to
have to update the way and how they sort of they think about
interacting with these things basically to support this if
they want to, you know, if they want to take advantage of it.
Yeah, I heard one of these quote, you know, quote UN quote
outlandish statements. What will be the first one
person company worth a billion dollars, you know, and the idea
is you could have agents or bots running your entire company.
You can imagine actually the example that you bought or you
brought up, which is you go out, look for the cheapest pair of
jeans. Now say you're doing that on a
wholesale level, you're buying them.
Maybe you're warehousing virtually and you're shipping
virtually. So you're taking orders online
and you're just moving these items and taking payments and
your whole company is basically bots.
Yes. Well, the, so the other example
here is, you know, I gave an example of where a user is kind
of, you know, bringing in their own agent and it's, and it's
going to do work on my behalf. But there are also examples of
agents that are being created that are kind of more autonomous
and they're acting as kind of digital workers where they're
autonomous off basically independently doing things, you
know, for an organization. And there might be 10s of
thousands, hundreds of thousands of these digital workers that
are going off performing tasks. Those agents likely are going to
need identities of their own, because to me, they're no
different to a human user, especially if they're
interacting with systems that humans interact with.
And now the digital worker, that agent is a digital worker is
doing it instead. Those applications are going to
have to actually know, all right, this digital worker has
an identity. It's going to authenticate to
me, all right? It's going to be given a set of
entitlements to do things. It's going to, you know, the
entitlements and, and it's identity is going to have to be
this life cycle of management around that.
It's going to have to be, you know, granted and taken away.
Access is going to have to be approved.
It it's going to act very similar to the way we think
about kind of IGA today for human users and what they can
do. But we're going to apply it at
massive scale for, for these, you know, you know, digital
workers that are, they're essentially just AI agents in
these situations. So there's, there's a whole
other class of stuff that's happening there sort of inside
the organization as well in terms of what's happening too.
So, you know, again, it's, it's, it's, it's all coming.
And I know a lot of people are thinking about this and talking
about this, but I think it's going to come a lot faster than
we than we might imagine actually.
So do people wind up being replaced by the AI agents in the
end to do we serve any purpose if the AI agents can do it all
themselves? I know it.
It almost seems like a silly question, but people brought it
up a long time ago. And every once in a while you
hear somebody say I'm not going to have a job in two or three
years because this does all the you know, you look at like say
the copilot assistant or the transcriber in the teams
meeting. Now you don't need anybody to
keep notes. In fact, usually the notes that
you're going to get from the teams that you are way better
than a person could keep anyway. So I, I, I mean, I've been
thinking about this a lot and I, I think this boils down to
efficiency, all right there that we are going to make people,
people are going to become much more efficient in what they do
if they have access to these AI agents to essentially do you
know, the repetitive stuff effectively that we've done,
done before. And I'm not saying that AI
agents won't require at least for some period of time, sort of
a human in the loop before we, we're ready to actually just
give them full autonomy. I, I imagine that humans are
going to be in the loop approving things that an AI
agent sort of says, does Axon creates whatever that that'll
exist for a while. So I, you know, that that
doesn't go away, But I, I think people, they just become more
efficient. And I don't think it's any
different to when, you know, the personal computer emerged and
everybody thought the personal computer was going to replace
all sorts of, you know, roles and jobs and stuff like that.
The stenographer, the, you know, the, the typing pool, the, you
know, whatever it might have been, yes, you know, they get
replaced. But I still think there's, you
know, it's not like there's all these people out of work.
People's skills evolved. People learn how to use these
things. They'll become more efficient.
They've got to embrace it and go with the times sort of thing in
that regard. Yeah, I, I feel the same way.
It's like you can't prevent progress, right?
The progress is going to happen. So you have to position yourself
on the right side of it. You don't want to be the person
who's constantly falling behind, like the person who went around
and lit all the street lights before there were Electro
lights. If they they stuck to it and
maybe they were lighting the last few.
Eventually they have new skills for the future.
I'd say, look, you know, this is something that Andre has shared
with me multiple times over the years.
Andre, the CEO of, of King, that organ, you know, capitalism, you
know, and, and you know, and organizations are hyper focused
on that they will find and drive efficiency, you know, constantly
or good organizations will, you know, and capitalism drives
efficiency. Basically everybody's looking to
do things faster, cheaper, better all the time.
All right? And it, it's constantly moving
in that direction, I say, and this is just the most recent
example of it. I think that we're going to see
so. Yeah.
What is your question, Patrick? If you were, if you had a son or
daughter who was in college, what would you tell them to
learn right now? And and don't tell me art
history, because that's cheating.
So yeah, what? You know what's interesting?
I've got like I've asked this, a couple of people have ping as
well. And so it the, the one thing
that none of my kids have gone into which I went into was
computer science. So my kids didn't go into
computer science. One of them is doing pre Med.
My oldest son that graduated, you know, did actually business
and data analytics are my youngest sons doing kind of
business and doesn't really know yet.
So I, I'm actually, you know, to me, honestly, learning the
business side of things gives you the opportunity to
understand how to run a business, how to build a
business, be a little bit more entrepreneurial, all right,
because you understand how businesses function.
And I still think that's going to be necessary.
People who understand how to operate and run a business is
always going to be needed, irrespective of what that
business is. And I think that's just a great
set of skills to have. I, I'm more way more concerned
if I was, you know, about going into computer science now,
because I, I mean, I was a software developer and I wasn't
a very good software developer, perfectly willing to admit it,
all right. And I don't think I would
survive through what it means to be a developer now, given how
much more efficient developers can be made using things like
now what's it called, you know, tow pilot and stuff like that,
that the. If you're a lazy developer, you
could you might be able to get by right?
You figure out all the ways to get.
Yeah, but I, I all. Your work is done by doing
nothing. That's true, but I just think
the number of, I mean, again, efficiency is going to drive
that, you know, developers are going to become more efficient
and therefore we're not going to need as many developers to to,
you know, develop the code. And the other thing is, look, I
mean, what's a developer really doing?
A developer is translating business analyst type
requirements into a language that a machine understands.
If I can now just use natural language to tell the machine
what I want to happen, do I really need that post in the
middle that's turning, you know, those requirements into code?
I can just give the machine, you know, I can just give the, you
know, the AI the requirements. So now becomes sort of more a
case of, all right, maybe people should be learning about prompt
engineering and understanding how to actually define these
requirements in a way that the AI can use it to actually build
the applications itself essentially.
So it just becomes a different language you have to learn
essentially to be able to, you know, develop the applications
that people want to. Use.
Yeah, I've been encouraging my son to do the prompt engineering
and really get good at that. He's a little sophomore in a
cybersecurity degree program, and I wouldn't say he's a lot of
a tinkerer. He was a tinkerer.
You know, early in his years he was setting up his own PC for
doing video games and trying to figure out how to, you know, get
the fancy sorting in his game without actually doing the work.
So, but I would love to see him tinker with getting the open
source code and seeing what he could do, seeing what kind of
data sources he could plug it into and figure out how it
works, because I think that's the skill that businesses are
going to be very hungry for. Yeah, absolutely.
And I don't think that, you know, I talked to him about,
like, are they teaching you this in school?
And he's like, no. And I believe him because I, I
remember going out in his when he was, you know, looking for
colleges and asking questions about things such as that, such
as cloud computing. And it's like these professors,
they were behind where we are even in, in the business world.
And I was like, man, oh man, I can't believe you guys aren't
like on the cutting edge of this stuff.
Maybe it's just the schools we were looking at.
I don't know. Yeah, that's a problem, I agree.
But yes, I think, you know, learning and understanding how
to translate, you know, so, and this gets back to the business
side of things. It's like being able to
translate the business requirements instead of actually
into code as we know it, But into, you know, to to to
basically tell an AI what it what you need.
I think is the where this evolves to over time
essentially. There'll still be need for
hardcore developers obviously, but I just think a lot of
organizations aren't going to need as many of them you know
it'll be. It'll look very different in 10
years time as an example. Oh yeah, for sure.
Patrick, you've been super generous of your time.
We had a great conversation today.
I know you're out there on LinkedIn, so I sent you an
invite to get connected. I don't know how you are
connected given you're on the show before, but I'm sure other
people after the show will be sending you invites.
I already get a number of invites per day and I love it.
I want to talk to all of our listeners and get to know you
all. And a great way to get to know
people is through the conferences mention we've got
discount codes for EIC and Identiver, so please make sure
to take advantage of those. And Patrick, I'd like to go out
today with a a lighter note question.
Given those two conferences, EIC in Berlin and Identiverse in
Vegas, what are your tips for each of those to do's for
whether it's a first time conference goer or maybe
somebody's been there a few times, they've got any like
secret Nuggets for each one of those?
I, I've spent a lot more time at, at Anniversa over the years
than EIC, so I'll sort of focus on that.
It's, it's honestly you, you got to get it outside your comfort
zone and just engage and talk to people and you know, you know,
at whether it's at, you know, might be a lunch or a breakfast,
you know, sit down at a table where you don't know anybody,
start talking to people. Everybody starts in the same
situation where, you know, they don't know a lot of people in
the community. But I've always found the
identity community to be very open and embracing of new people
and old timers essentially. So you know, that to me is, is
the key here. You know, everybody, everybody
was in your place at some point in their career and felt the
same way. So, you know, don't be afraid
just to open up and reach out and ask questions and introduce
yourself and stuff like that. Essentially is the is the key.
The same thing applies in the EIC as well with with Martin and
those guys too. So, you know, I would say the
same thing there as well. Yeah, this seemed to be my first
time in the EIC. I've been to Germany before, but
never Berlin. I hear that, you know, it's a
very lively city. Of course, there's a lot of
history there, a lot of places to check out like the Berlin
Wall and you know, I mean, heck, I'm not going to do as good of a
job. If you're interested in looking
for sites to see YouTube, Google, there's tons of
information out there. I have actually been to Las
Vegas probably 20 or more times. I my biggest pro tip is to pace
yourself. I mean, especially if you're
somebody who likes to have a good time, you get to Vegas.
If it's your first time in Vegas and all those lights are on and
you go into, you know, go through the casino, they just
have a way with all the bells and the lights and they pump
extra oxygen into the room, makes you feel energized and you
should enjoy that. My recommendation with my my
recommendation with Vegas is don't end up inside for three
days like I have a couple of times.
Get out and get some fresh air in the middle of it if you can,
because you know, I, I've, I've inadvertently spent three days
indoors in Vegas and never saw the sun.
So. Yes, that's that's good advice.
I've I've never done the whole 3 days indoors, even though Jeff
has told me he's done that a few times.
I'm not like a when I was a kid I wanted to be outside around
the clock, but you know, as I've gotten older, found lazier about
it. But I think for a certain amount
of time, I'd just go stir crazy in indoors and and but here.
So my advice is pace yourself. Don't try to have all your fun
fun upfront. You know, a little bit at a
time. There's a lot of like after hour
parties, but that doesn't have mean you have to be out until
midnight every night because the shows you know, take place in
the morning. Get off to a fresh start, have
breakfast, get in there, be mentally aware, engage.
Try also to break away from work for a little bit because yes, I
know, I understand. And I've fallen into this trap
many times over the years where you're right in the middle of
like a hectic project. But if you travel all the way
out from Las Vegas and you go to two, two of the sessions or
something like that, you're really going to regret it.
You've got to try to find a way to get up early, do your call,
maybe save some of the calls till later today.
Maybe take a break in the middle, but make sure you're
going to a number of the sessions otherwise you're going
to end up being disappointed in the end.
Yep, good advice. Yeah.
So that's what I've got for you for this time, Patrick.
Again, thanks for joining us. For everybody out there, find us
on the web idacpodcast.com and our YouTube channel is
idacpodcast.tv. That'll drop you right into our
YouTube. Again, love hearing from
everybody on LinkedIn, so find us there.
And thanks again, Patrick. Until next time, everyone.
Thanks, Jim. Bye.
You've been listening to Identity at the Center.
We hope you've enjoyed the show. Make sure to like, rate and
review, and we'll be back soon. But in the meantime, hit the
website at identity@thecenter.com.
See you next time on Identity at the Center.