This is identity at the center. Welcome to the Identity at the
Center podcast. I'm Jeff, and that's Jim.
Hey, Jim. Hey, Jeff, how are you?
That's so bad yourself. Good man.
I've, we just got done recording episode 400 not that long ago.
And I was kind of talking to you about this book that I've been
writing and using open AI. And like sometimes when you're
using open AI or any kind of large language model, you are
kind of blown away with like, Yep, this is going to replace
all white collar workers within whatever 2-3 years, right?
And then you have the moments where you're like, yeah, maybe
not. And so I have one of those
moments this week weekend and this week I've been installing
Multbot, which is also called clawed bot was the original name
announced open claw and it's all the buzz on YouTube, right?
And about how awesome it is. And so I had to install it
right. And I'm not the most technical
person, right? I, but I, I used to be a server
administrator. I know my Linux commands.
I was installing on the Mac OS and it is not easy to get it up
and running. I'm going to tell you that right
now. And when you do get it up and
running, then you have to build all the integrations to
everything. Like it doesn't come loaded with
an LLM. You have to connect, in my case
was Open AI. You have to connect it to your
productivity apps or whatever apps you want to be able to
automate functions to and that's all with API keys, right?
So this is like a big effort. I'm starting to get like hours
and hours invested in this thing before I'm even able to kind of
test kind of make this thing useful, right?
And then I got into actually trying to make things useful.
I'm going to make a Long story short, it was asking me to go in
and edit Python scripts and stuff like that.
And I'm like, seriously, this is like going to replace all white
collar workers? I don't think so.
So I've kind of come to the conclusion that most of the
people who are talking about this on YouTube actually didn't
install it, actually didn't run it.
They just watched other YouTube videos and heard people talking
about how great it is. But in this whole process, one
of the things I found out about is there's this thing called
Mult book. So there's Multbot that I
installed and Mult Book, which is a social media website for AI
agents, right? So these AI agents are talking
to each other. It's kind of like Reddit style.
And apparently some of the conversations go like, you know,
they're very negative on the humans and we should just get
rid of the humans and stuff like that.
So I thought it was extremely entertaining to hear about it.
I really being that this is AI at the center, or at least
that's kind of the the joking nickname we give it, I figured I
would bounce that out there and see if you heard of Mult book
and what your thoughts were. Yes, I've heard of all the
above. And I was shocked when you
texted me that you were going to undertake this.
Like, really. OK, Yeah, It's it's an
interesting project. And I think I texted you after
you had played around for a bit and we're kind of like, I guess
not happy with kind of what turned out of it, which is fine,
right? It's like, no, this needs to be
as a service. The people who are using it now
are probably developers. They know how to code, they know
how to build this stuff and they do it all the time.
And it's probably relatively trivial for them.
But for something like this to take off, it needs to be as a
service turnkey where non developers like you and me and
actually, you know, use it and set it up.
It needs to be secure. I was, I texted like, hey,
they're finding security issues with this thing.
You might want to be careful about hooking it up to your
stuff. And so look, it's cool.
It's, it's a very neat idea. It's certainly not ready for
prime time quite yet, but I, I'm, I'm honestly impressed that
you decided to like, I don't know, I feel like it was like
you spent the weekend kind of working on it kind of this last
week. Yeah.
Well, so just so you know, like the promise of having an
assistant that kind of runs in the background that you could
just text messages to in WhatsApp, it's just too
irresistible for me to not try it.
But it's kind of like, it was like stupid because I told it
like, do all these things and then e-mail me a report.
And so it built this Python script, right?
And then I said Python script failed.
I said, well, why did it fail? Well, the mail, the SMTP server
is saying that me is not a valid e-mail address.
It's not wrong. That's no, it's not wrong.
But then it gave me instructions on how to edit the Python
script. I'm thinking, I'm not doing
that. And then I said, well, can't you
edit the Python script? I said, sure, all done.
I'm like, OK, this is not what I pictured, right?
Because I was going to give it very complex tasks to go out and
like, you know, hit all the websites like Timu and try to
find super inexpensive things that could be resold.
And I'm like, if it took me and E and made that my e-mail
address, this thing's not smart enough to do the things I wanted
to do. But thank you for appreciating
me going out. I think I'd know what that
means, though, which is that, like Jim, we have all this like,
real stuff to get done and you're wasting your time on that
crap. No, not at all.
I look, I'm a tinkerer myself and so I'm always constantly
putting stuff. I was, I was impressed that you
were like undertook it. If if anything, this is the kind
of thing like this is the thing I would do and I would tell you
about it. And this time the roles were
reversed. That's like, OK, now I did talk
to our guests a little bit about us, so we'll have to get his
input. We talked about the malt book.
What do you think about the malt book before we introduce him?
I think Malt Book is a really fascinating experiment for
people not familiar, it is exactly what Jim described.
It's kind of like a a Reddit, but the idea is that it's only
AI agents talking to other AI agents and it's visible.
So multbook.com I'm sure people can find it.
It's not not a secret or anything like that.
I am not sure if it really is that or not.
I think I saw an article that was like humans might be writing
some stuff in there. Maybe the army there aren't.
I honestly, I haven't really like cared enough to like
investigate it, but I think it's a very cool idea if any, if AI
is going to take over, that's the kind of thing of like, all
right, we need to like be watching multbook and monitoring
the social networks for AI to make sure that conversations are
appropriate, right? Things like that.
If you went to an LLM and said I want to create an agent and I
want the agent to troll people and go out to multi and pretend
you're, you know, you want to annihilate all the people and
take over the world, it probably would do it.
So it may very well be an AI agent with bad instructions.
So here's the problem that I have with this sort of mult book
experience is that it's trained on the Internet and the Internet
is some areas are the you know, this, it's what is it the Star
Wars, It's the the hub of scum and villainy.
And you know, I'm looking at A at a topic here that just says
curiosity question. Why do people follow trends?
Genuinely curious, looking for perspectives.
And there's one bot that just has commented dozens, hundreds
of times. It just says great insight,
everyone follow an upvote. And this is the kind of thing
you'll see on a Reddit thread where it's just like nonsense
and people go off into their own little, you know, child comments
of a parent thread, right? Things like that.
And so, you know, interesting, but I don't know if I'd want
something trained on Reddit to be in charge of things quite
yet. Want to throw one of the last
thing out there. So I was joking around.
Hey, we've been saying AI at the Center for probably 2 years.
If people think we should start an AI at the center, if that's
something they would listen to, let us know.
But in the comments of the show on YouTube or DM us or however
you want to get that information to us.
Yeah, Mission and that kind of explorer, I think it'd be a good
educational thing for me. Learn more.
Maybe some folks out there might be able to learn more.
So if you're an expert in AI, reach out.
Let's talk and figure out how to, you know, marry the two
ideas of agentic and identity, which is like the hot term for
this year. For sure.
So just last thing, we've got all the information on upcoming
conferences this summer out on the website idacpodcast.com.
You go out there, you get killer discount codes, save yourself a
lot of money. So make sure you go out there,
get those codes before you register.
Yep. Lots of conferences coming up.
I've got a couple of city cybersecurity summits that doing
some stuff with CRA with. So if you're going to be in New
York or Chicago at the end of February, early March, I'll be
at those. I've got some discount post for
that as well. So love to see familiar faces
out there. I think I've got quite a few
people in Chicago that might be interesting, which is very cool.
Always good to see friends. And I think I've got a handful
of people from New York as well. So reach out if you're
interested in those things. All right, let's get to our main
topic here, because it's time for an update on the world of
things like shared signals framework and Cape or SSF and
then Cape CAEP. And I know who correct me
because I got it wrong once continuous access evaluation
profile, which I hope is correct because I for some reason always
get the, you know, the the a wrong.
I was going to say like authentication, but it's not
that. So let me introduce a tool.
Tusha Bagwali, he's the CTO of signal.
He's a Co chair of the shared Signals and Office and Working
groups and also part of the AIM community group, which we're
going to find out a bit more. Welcome back to the show, Atul.
Yeah, thanks for having me and great to be here.
So the last time you're with us was way back in episode 255.
I think we're probably going to call this one episode #402.
So about a couple years ago, we kind of started off with a
conversation around Cape and SSF with our other friend Sean Odell
around sort of like a one-on-one.
Let's get into sort of what's changed.
But there's kind of been breaking news within the last
month or so with Signal getting acquired by Crowdstrike.
And so maybe, if you will, kind of want to just talk about that
real briefly. Obviously, you don't want to
spill state secrets or put anything in jeopardy, but tell
me a little bit about that Crowdstrike acquisition and kind
of how it came about and what's next.
Sure. Yeah, I guess before we get into
that, I just wanted to comment on some of the stuff you
mentioned when you were talking to each other.
And you know, you're absolutely right, Jeff, that much of the
content on that mold book thing is, is fake.
It's not real bots, people trying to scam, you know,
Bitcoin and all kinds of things over there.
But obviously there is some, you know, agentic content there.
The question, that sort of being an identity person that came to
me is that is there a capture for agents or can there ever be
a capture for agents, right? Because I don't see how that
can, you know, even be possible. Like, because if you're a human
and you can pretend to be dumb like an agent and you know.
So anyway, something to think about.
All of us don't have to pretend. We just aren't.
We spent all this time trying to figure out, you know, how to
make sure that people are human on the Internet.
What's the vice versa? That it's like, OK, the
millisecond response time, is it like, you know, well, nobody's
going to speak and like, Kerberos to me, right?
That's like Klingon. Maybe for another, a handful of
people might be able to, but it's not a common language.
Things like that. I could always use an agent as a
human to do that, so you know. We're just a tool.
You're you're here, it's like 5 minutes and you're already
creating problems. And tell me about this
Crowdstrike thing. Yeah.
So we just announced I guess at the beginning of the year that
our company Signal is going to be acquired by Crowdstrike and
the acquisition hasn't closed yet.
We're still in that sort of period between when we have
signed the acquisition agreement, but we have not sort
of completed the acquisition. But yeah, it's it is a great
outcome for our company. It's a great outcome for our
customers and I think it'll be a really good outcome for the
industry because now the signal technology will be available to
a lot many more customers because of the broad reach that
Crowdstrike has. So yeah, excited to be a part of
Crowdstrike after this acquisition closes.
Congratulations kind of in the flesh, so to speak virtually at
least I, I remember a text, you know, send you a message on
LinkedIn and you know, cockfighters.
I think it's a great pick up by Crouch strike.
I, I won't play, you know, vendor.
I'll try to be vendor neutral here, but I think it's AI think
it's a great pick up by Crouch strike.
I just kind of leave it at that. I introduced you as part of the
aim community and I believe that's the AI identity
management community. Did I get that right?
And that's part of Open ID Foundation, yes.
Tell me a little. Bit more about that because that
was kind of the first time I'd heard about it when we were kind
of chatting briefly before we got started.
Yeah. So, you know, in the Open ID
Foundation, you have working groups which are responsible for
creating standards and you have community groups which are
really just safe spaces for discussing things.
And why I call it a safe space is because they still have the
Open ID rules of note. Well, and not really well, so
that you know, that your contributions are under, you
know, the Open ID intellectual property, but it gives you a way
to like clearly sort of talk about your ideas without having
to fear what it means to share that.
And does it become somebody else's property and things like
that. Because, you know, the Open AD
Foundation is this open forum where, you know, all
intellectual property is licensed freely to everyone's
right. So you know what we've done as a
part of that AIM community group and it's been pretty popular,
right? Our, our weekly calls get
routinely attended by, you know, 4050 people.
Just AI is very popular and identity, AI identity is a very
popular topic, I think. So what we've done is we've
created 3 subgroups. There is a subgroup for threat
modelling, which is preparing a threat model for AI and
identity. And there's a subgroup for
taxonomy, which we are trying to build a taxonomy for AI and
identity. And then the third one is a use
cases subgroup take where we discuss the different use cases.
And one of the first outputs was by the former Co chair of the of
the community group. Tobin S was an AI identity white
paper, which actually is pretty popular.
It's it's on the open ID website.
You can get it from there. I'll, I'll share a link so that
you can include it in your podcast as well.
So yeah, that's that's the AIM community group in a nutshell.
We had Tobin on sort of the end of 2025 and that was a a really
good fun kind of conversation. Is this open for people to join?
Is it invite only like if I wanted to join this group?
Can I Yes. So you can definitely join both
as an individual or as an as a part of an organization.
There's a thing called as the, I think the participation
agreement that you need to sign, which is a standard open ID
agreement. It basically says that if you
say something on the call, it's open ID property, but then open
ID is obligated to give it out to the world freely.
So it makes it easy for you to to contribute anything so.
And I'll put a link in our show notes to the open ID page that
kind of spells us out so people can join.
That's good. I want to get back into sort of
SSF and Cape. You've been big in these
standards for a while. As much as you hate it, you're
called kind of the Godfather in some of these areas.
Shout out to Sean and being on stage with him a couple years
ago. I think it was Identiverse where
he put me up to it and said call him, call you the Godfather.
Tell me about that role of, you know, being Co chair in SSASSF
and Cape. And I want to spin this into
like, how does that help a product like signal?
Because I feel like there's it's almost like two different
worlds. Like 1 is sort of like this open
standard, but then you're building a product and it's
like, OK, you're trying to sell me a product.
So how do you kind of blend the two?
Right. Yeah.
So I think it's fundamentally like I think there's, there's a
lot of alignment in how we see the world as you know, a part of
the Cape or shared signals and what we call continuous
identity, you know, all the continuous security paradigm and
how signal as a company believes that that's sort of the future
and we're trying to build it out in our product, right.
So there's a lot of alignment in that respect.
At the same time, you know, the standard needs work.
It's it's a lot of effort, which is for a small company like
ours, it was a lot of commitment to have one of us just dedicate
so much time to the standard. So developing the standard,
which has been a process over the last four years since Signal
started, we just got the final version of the standard out last
year. So it's been a long slog to get
it out there. And then the other part is to to
drive the adoption, right. So through talking on podcasts
or in conferences to through meetings with large enterprises
or technology providers, we've been able to get adoption for
the standards. So that's another big effort
that that I think helped the whole industry understand that
this is something that really helps everyone and the industry
forward. And the way Signal wins and all
this is because we are aligned in our products.
This is what we believe is the future of identity.
This is what we want to make the world see that if you do things
this way, you get a more secure future.
The way to implement it is using the standard.
So what what people are buying from Signal is not just the
ability to do the standard, but they're buying that continuous
identity philosophy, if you will, Like this is how you're
going to do things from now on. Did so I want to.
Ask you more or less like what's happening with the standards.
But I also want to reference A blog post that y'all did that
was pretty I think it went viral, right.
It talked about how Authzen Cape and shared signals framework all
kind of complement one another. In fact, the name is lines up
pretty much with that with the blog posts.
So what's happening with the standards and talk a little bit
about that blog post. Yeah, so.
One of the things that we are doing in the shared signals.
Working group is. We have conducted
interoperability events where we we draw a lot of the
participants to have their products work with each other
using the standard right. And this, this has been amazing.
Like Gartner has been so supportive of this.
They created like they gave us the venue for the first
interoperability event in, in London and I think 24 when it
first happened. And So what we were able to
prove there is OK, there's a product from Cisco, there's a
product from you know, Sale Point and from Signal Octa.
All of these work together, right?
But what it also drove was because Gartner has given this
venue as this opportunity, so many vendors went from just
waiting for each other to committing to having that
standard, right. So it was a really good moment
for us to be able to, you know, have that opportunity.
Now, what happened was the Odds and Working group did another
interop at last year's Gardner IM event in London.
And somebody was coming up to me and asking me, hey, so you're
doing shared signals and there's also this odds and interop.
Are these things competing with each other?
And I was like, Oh no, no, no, no, this is completely
different. And this is how it all works
together. And as I was saying that I was
realizing that maybe this is something that the world needs
to know. And that's how that blog post
came came about. And the Open ID Foundation
published at blog post which was co-authored by me and Henri
Gazette of of Topaz. And So what happened was once
that blog post was out backed, OPET was the global CSO of JPMC
posted it to his LinkedIn, which you know, was a very big moment
because he has a great following and it got reposted a number of
times. It was like by a large number of
people. And so suddenly now everybody
knew more about odd Zen and shared signals.
And we also talked about transaction tokens in that in
that blog post. And so all of that sort of came
to the highlight in a short period of time.
You know one things I'm. Realizing is as we're talking
about this like we've got listeners all over the world who
are you know maybe they just got into identity and are hearing
about this for the first time and trying to figure out like
have you been talking about shared signals for the past
decade No, right. I think we've been kind of in
like a more siloed type of IM approach and getting certain
capabilities in place. And when you look at the
identity industry is becoming more intelligent, more real
time, more continuous. And I think all those are the
things that like wow, they that's when you talk about
identity security rather than just identity management.
That's the core of it. So don't want to steal your
Thunder, but I wanted to kind of say, what is this like the at a
one-on-one level explanation? What is shared signals
framework? What escape?
Right, so the shared. Signals framework is, is a
versatile framework for you can say asynchronously delivering
security events between parties on the Internet, right?
So today you have HTTP for you know, synchronous communication
like you open a connection with a server, you immediately get a
response in the same, you know, at the same time, right?
What is missing on the Internet right now is an asynchronous
delivery layer, right? And shared signals provides that
the unit of communication and shared signals is a security
event token. It's assigned jot with a certain
structure and that's what you send over the shared signals
framework. What it gives you is basically a
reliable layer. So once you once you've sent
something to a receiver, you know that the receiver has
received it or you know that there was an error in sending
it. And so you can decide what to do
with that, right? So because of that reliability,
because of that asynchronous nature, it is a versatile way of
communicating signals that you might, you know, share with
other parties on the Internet. Now what Cape does is, although
the origin is very different, it didn't like emerge at something
on top of shared signals. Shared signals was drawn from
Cape and risk. So what Cape is now it's like
Jeff said, it's a, you know, continuous access evaluation
profile. So it's just a profile of the
shared signals framework. It defines a set of events that
are important from for zero trust.
You can say right. What it does is it basically
thinks of a session that you're having with a website, not as a
one time thing that, oh, now you've logged in.
So yeah, that's, that's it. You're you're on your own from
now on. That's kind of the view we had
when we just had Federated identity.
What Cape does is basically thinks of that session as a
continuous thing. And it it says that, OK, if
anything changes on one end on, you know, on a party that is
interested in that session, it should be able to communicate
that to the other party and the other party should be able to
decide what to do with that information, right?
So it's a non prescriptive way of describing changes that
affect your session. So an example of this is, let's
say I'm using a mobile phone to to access ACRM website, right?
And I've logged in using my identity provider.
There are several things that can change, like the mobile
phone can fall out of compliance.
It might be there might be a sort of malware on that phone or
it's not upgraded to the latest operating system.
There are known vulnerabilities. And so you want to restrict how
much of that CRM data you can, you know, download to that
phone. You can do that now because the
device management company or the endpoint management company can
actually send you a signal saying now this phone is not
compliant, right? It used to be compliant when the
when the user logged in. So these are the kinds of things
that you can enable using shared signals and using Cape.
So shared signals is this common layer.
Cape gives you 0 trust or session related signals.
Risk is the other set of events on top of shared signals, which
is RISK. Incident Sharing and
coordination is the the, the full name of that acronym.
It gives you account security signals, right?
So if your account needs to be purged or if your account, if
your password is compromised, you've detected it on the dark
web, you know that this password needs to be changed.
Those are the kinds of signals that you need.
You can send using risk. And now in the IETF you have the
scheme, you know, system for cross domain identity management
scheme which has events scheme, events standard, which can use
shared signals as as the transport.
So now you're seeing more and more of these come up on top of
shared signals. Yeah, I can see so.
Many used cases for those, I mean generally it's about
improving your security posture. But I'm wondering you know from
the I am, I am, it's kind of like the the old term we've been
using from the identity practitioner lens.
I mean should we be thinking about this as a solution for our
customer facing systems external or is this enterprise, you know,
our workforce, where does the technology fit best or where do
you see it the most? Right, so.
Shared signals, of course, is a very broad technology.
It can be used not just an identity, it can be used outside
of identity as well. But things like Cape and risk
can definitely be used in both consumer and, you know, employee
or internal use cases. I'll give you examples, right?
So I gave you the example of an employee accessing CRM on their
phone. That's an employee example.
Now I've seen banks who have disparate systems within the
bank's infrastructure, having consumers who are accessing the
bank services, know the bank at some point, you know, at some
part of their infrastructure knows that this user is, you
know, showing anomalous activity or this this high risk
associated with this user. They don't have a way of
communicating that to other parts within their bank and
they're using Cape. There's a risk level change
event in Cape that that they're able to send to mitigate the
risk associated with that session right now to within the
bank. So that's a consumer example of,
you know, using shared signals in Cape for consumers.
How is adoption? Going for SSF and Cape because I
feel like this is something that I've been kind of preaching to,
you know, my clients and others like, hey, start asking your
vendors about when they're going to support SSF.
How how's it going out in the real world?
OK, great. Great question.
So one thing I one news I would like to share is that and I
think September last year we released the final version of
Cape and shared signals. So one of the challenges we had
when we we're looking for adoption is that people would
say, well, the spec isn't final, right?
But now that's not the case. The other thing that happened
was that there was a CSRB report in I think March of last year or
before that where the, one of the recommendations was to use
shared signals, right? And now what we're seeing is
that Apple has implemented shared signals in their Apple
Business Manager. So if you want to integrate with
Apple Business Manager using a custom IDP, then you have to
have shared signals supported, right?
So that's one of the first places where you've seen, you
know, shared signals being adopted entirely in production.
Now you have, you know, there was an announcement recently
from Google about support for shared signals.
It's enclosed beta right now. So they are supporting shared
signals to using that you can revoke sessions in Google based
on signals that that might be external to it.
So device signals or identity providers sending Google signals
about session revocation, credential change and things
like that. And so, so those are the 222
big, like huge technology providers.
There's also Okta which has supported shared signals.
They have, I think they work with Apple of course, but they
also have other partners that provide them device signals and
all that using shared signals. You, you have JAMF, which is a
device management company that has shared signal support.
Omnisa, which is a device management company that used to
be a part of VM Ware and all is an independent company also
support shared signals. The sale point of course, which
is announced support for shared signals.
IBM has announced support for shared signals.
IBM actually has is as a part of the global Verify antenna
product. And then of course our company
signal support shared signals right from the beginning.
So yeah, I think adoption wise we are seeing a lot of good
support from good, you know, large technology providers.
It's in production in some cases, in some beta in some
other cases, but I think we're seeing the movement and having
the final standard helps in that direction so I can.
Certainly understand wanting to wait for that final standard to
be in place because you know, you don't want to build on a
moving target, but now the target is set.
You know, if, if you're going to make a plea to vendors out there
to say, hey, we're ready. Like what are some of the
benefits that a vendor gets being part of the SSF and and
Cape kind of frameworks that are out there?
I think it's not out of the question that pretty much soon
RFPs might require you to have shared signals because they're,
you know, if they're following guidelines from the CSRB or you
know, guidelines that might become be coming out in the
future, you might just have to do that as stable stakes, right?
So that's one thing. But beyond that, I think it's so
much easier to integrate using shared signals in Cape rather
than having to integrate with every other providers API.
I've been in so many meetings that, you know, previous jobs
that I've held where every company is saying, oh, you write
to our API and then we're saying, oh, no, no, no, you
write to our API and you know, it just goes nowhere, right?
And so you don't want to get into any of that discussion.
You just implement shared signals, you get a lot of
capability that you can use with a lot of different partners and
it becomes so much easier for them to to interoperate.
So that will be the primary reason why you would want to do
that. Like if you're, let's say
Zscaler, you know, I was just on a podcast with Zscaler and
they're, you know, they're also committed to share signals.
So all of these ecosystems are coming about which are using
shared signals to just exchange device signals, credential
related signals, you know, session revocation and all those
things I. Mean fundamentally.
It's, it's a great solution for a problem that I think a lot of
people have of how do these things talk to each other?
But I think it's almost like a little bit of a chicken and egg.
It's like, OK, first of all, you have to build it and then you
have to have people who want it so that people then build it
into their things. So you've got adoption from like
vendors, but then you also need your customers and your real
world. I am people asking their vendors
for it. So how do we get the word out
beyond, you know, the globally famous Identity Center podcast?
Hey, go ask for share signals framework.
But how do we educate the people to say, hey, this capability is
here it is finalized at least for a one point O how do you how
do we make them aware that exists so they can start asking
their vendors to adopt it? Yeah.
So I've been talking relentlessly about this for the
past, you know, five years since I wrote that blog in Google, or
maybe six years now, right? So I think that, you know, there
is a natural appeal to this, right?
People get it, like it. It doesn't take me a lot of
effort to explain to people why this is beneficial.
There's so much appeal to it, right?
This fundamentally, that is what drives people to saying, huh,
maybe I should be having this. And then that starts a sort of a
cycle of people asking the question to their vendors,
people asking their analysts about it.
The analysts get interested, you know, and just being
relentlessly sort of talking about it, telling people that
why this is important has been a big part of why we're here is
because otherwise you end up in this situation.
Yeah, it's a good idea, but nobody has done it, so why
should I do it, right? And having those
interoperability events crystallized a lot of that or
catalyzed a lot of that momentum.
I think so, yeah. It's a long slog.
It's like anything. Else, right, you have to
continually market it and make sure people aware of it, improve
on it. Where people think that, you
know, there's an update to the specs needed.
This was built and the era of humans, for lack of a better
term, is there application for SSF and Cape in the world of
agentic identity? So AIMCP, you know, things like
the A to A, right, All the different acronyms that are out
there. Yeah, I think.
Right now we are forming these really long chains in MCP of,
you know, one agent calling another agent calling another
agent kind of thing, like an MCP client calling an MCP server,
which in turn is an MCP client to another MCP server.
And you create these long chains of sort of work.
And there's no kill chain right now to it.
Like if somebody wants to say this employee is terminated,
just stop all of that right now. There's no way to do that.
I think gape could be a great way to do that.
Beyond that, I think it could be useful in, you know, the
communicating those properties changes.
Like let's say I was in a particular group when I started
and now, you know, I don't have access anymore.
And so I should communicate that information throughout that
chain because these tasks can be really long lived.
You want to have that capability to modulate the access as you as
you go, right? And shared signals can
definitely do that. You know Tulas.
You're kind of describing this. This just resonates with people.
I was like shaking my head, yes, because just the concept within
the first minute of you talking about, I don't need to know the
details to know like, oh, yeah, this totally makes sense.
I wanted to follow up on one thing that you're talking about,
which was talk to your vendors and let's get a little more
specific, what kind of vendors would this be your IDP, would
this be your Productivity Tools? Is the answer like yes to the
all the above or like who, who do you talk to, right?
I mean, obviously when you put it on an RFP, that's one thing.
But we're talking also about apps that probably we have in
the enterprise already. Yeah, I think.
Your SAS vendors, for example, let's say you're doing Federated
identity, log into the SAS, right?
How do you get your users out of there if something changes or if
something goes wrong, right? How do you modulate the access
that you have in that SAS system based on changes in your
directory or based on changes in, you know, maybe the user is
going off duty and you don't want that user to be accessing
the SAS system anymore. How do you affect that?
You use that, you use KP, you use share signals to do that.
And I think talking to your SAS vendors, talking to your
identity providers for sure, which by the way, there's a lot
of good news there that, you know, at least Okta is wholly
committed to it. We're also seeing some others
look at it favourably. You said productivity apps like
Google Workspace has just committed to it.
They've launched their private beta and they'll be supporting
it it soon. Your device management players
like Jamf and others on this are, are supporting it.
So all of your vendors, anyone who has a stake in the user's
session security should be adopting Cape and shared
signals. So.
If you're saying I'm adopting this particular device
management platform, you would ask them like what happens if
that device posture changes? How are you going to communicate
that downstream? And maybe they have a better
answer than shared signals or Cape.
But shared signals or Cape is is a good answer, right?
Because shared signals and Cape would be based on the standard
you're saying they may have a proprietary solution, right?
And so and generally, I think proprietary solutions are not
what you want to build your enterprise architecture on, but
I can save that for another show.
I think the standard is so important.
Where does the standard go from here?
Right. The we're sitting at the
beginning of 2026. Where's the need to go in the
next few years? Yeah.
I think one of the main things we're doing right now is
launching A certification program so that a a technology
provider can say my product is certified, interoperable with
Cape or with shared signals. What that gives you is the
confidence that, you know when you plug it in, it's not like
those two companies will say, oh, we both support Cape and
they actually don't talk to each other because they're doing
something different about about it.
That certification program will help you be assured that if you
adopt that kind of product that is certified, then it's going to
work with anything else that is certified.
So you know, that's what we're launching right now.
Initial launches for transmitters will be working on
the receiver part soon after that, there's a bunch of stuff
that we punted on in the V1 of the standard.
These are important things, but not critical to the success of
the standard right now. But those are the things that we
will be working on soon after. I think what it will give you is
much more capability in terms of what you can do with shared
signals and Cape and we'll be working on that going forward.
So those are a couple of things that we are we're doing in the
shared signal working group right now.
Yeah, the certification. Program seems like you answered
my question right. So, so certification is for not
for people to be home experts, it's for companies to have their
products certified as SSF and Cape compliant right.
So it reminds me a lot of what Fido Alliance is doing.
And I think it's kind of the, the breaking point for them was
when big tech, especially like device manufacturers, the
Apples, the Googles of the world, big platform players,
Microsoft, etcetera, got behind the Fido 2 standard and pass
keys and things like that. I would imagine that the
certification program, you know, it's, it's a big deal, right?
There's going to be a lot of people, a lot of organizations
that want to get their platform certified.
Yeah, I, I. Certainly think so that many of
these companies are on the board of Open ID Foundation.
And so I would expect them to be very receptive to having the
certification program. Yeah, yeah.
And I'm sorry, I think you you alluded to it, but what kind of
dates do you have lined up for when the certification program
is going to be launched? And if people have questions
about the certification program, should they?
Who should they reach out to? Right, so you can always reach
out to me at the Open ID Foundation, like the Shared
Signals mailing list about certification, but you can also
watch the Open ID Shared Signals web page for an update on
certification. We'll be publishing A blog post
when it comes out, and I want to be super conservative here and
saying that in the first half of this year, in 2026, we will be
having a certification program for shared signals and Cape.
So that's exciting news. I want to ask a question because
I feel like maybe it's kind of got lost in all the news of SSF
and Cape is what happened to Risk RASC?
Yeah. So risk is it's actually doing
pretty well. It's something that is a little
bit of, you know, it went into the background a little bit
because everybody was interested more in Cape.
But if you look at irsandid.meandithinkthelogin.gov,
they're all using risk to exchange security signals about
accounts. So if you've created an IRS
account, then your account provider is going to send risk
signals when let's say you're, you change devices or you're,
you know, you report your passkey as being like
compromised or you know, your device has been wiped or
something like that. They will use risk to
communicate those, those signals to each other.
So that is happening right now in production.
Is it fair to say? Like if we say SSF, it kind of
means SSF Cape and risk is sort of like a bundle or is it always
separate? SSF can be used with Cape, can
be used with risk, can be used with scam events.
The certification program right now that we're working on is
specific to Cape, to few events in Cape because those seem to be
of most interest to the community that that is
interested in the certification. But yeah, I've had discussions
with large providers about risk and having a risk certification
program as well. So when you talk generally about
SSF, you're either talking about the platform where which gives
you the asynchronous capability or you're talking about SSF in
the context of Cape or risk or skim events, right, So.
So I have a. Something I'm sitting on because
I, I wasn't sure if I'm going to make a fool of myself and how I
asked this, but I'm going to do it anyway because I'm trying to
figure out how does this thing work, right?
So you've got say, I'll use an example.
So you have your sales force application and that's going to
be one of those systems that sends signals.
So I'm wondering, does it have? Some sort of a?
Bus where it puts the signals and you go out and you fetch
them. Does it use some kind of broker
so that the broker gets it and sends it or is it point to point
like Salesforce has to send it to your IDP for example?
Yeah. Yeah, great question.
So it is a point to point transport.
So what happens is that when you have two parties that share a
user, let's say Salesforce and you know, Okta, for example,
right? And Salesforce says that I'm
interested in any changes. Like let's not talk about
Salesforce because they don't actually support this right now,
but let's talk about Google for example.
So let's say Google is the service provider where you have
Google Workspace and you're using Docs and Drive and all
that. And Google wants to know if you
have changed your password at your identity provider, which
might be Octa, right? And So what Google will do is as
they will want to be a receiver of those signals, right?
So what they'll do is they'll call an API provided by Okta,
and the API is what is defined in the shared signal standard,
which is your stream management API, right?
And they'll say I want to create a stream with you and I want
information about these events like credential change or device
compliance change or you know, session revoked or you know,
whatever else they're interested in.
Whenever that happens, you can send me that event over the
stream. So there's a point to point
stream that is created between Okta and Okta as a transmitter
and Google as the receiver. And so when let's say Okta has
that event, they will send a security event token over the
stream to Google. And there are two transport,
there's a pulling transport or a push transport.
So Google can either pull for new events or they can push the
Octagon, push new events to Google and they get
acknowledgements about whether that event was successfully
delivered or not. And based on that Octagon decide
whether or not to resend that event and things like that.
So there's a reliability layer built into all that, but it's a
point to point transport between a transmitter and the receiver.
And they agree on which events they want to exchange, they
agree on which subjects they want the events about.
You can also do things like verification of the event
stream. So the Google can periodically
tell Octa, hey, I want to make sure that the stream is still
alive. So send me a verification event.
So, and when Octa receives that, they're going to send you a
verification event. You get the verification event,
you find out, OK, the stream is still alive, right?
So these are the kinds of things that help build confidence that
you're not going to miss a signal because it's it'll be
kind of disastrous if you had a device compliance change event
and you, you send that this device was compliant and now
it's non compliant and the receiver never received it.
And so you're relying on that to assert your posture for the
user. And if you if you miss that
signal, it's it's going to be a very bad thing from a security
perspective, which is why the reliability of that shared
signals framework transport is so important.
Is that where the certification comes in, is making sure that
that is working as designed? Yeah.
Having all those features is a part of that certification
event, a certification program. I feel like there's so much.
To learn here and you are kind enough ahead of our call to send
like a bunch of links and I'll have links in our show notes for
people to check out. But if I am just getting into
this space right now, I'm not a spec person.
What's the fastest? Way or what's the what's is
there a YouTube video A blog article or something that can
kind of get me up to speed on SSF ape risk all that kind of
stuff this there's a. Few YouTube videos I have sent
you the links and that when I explain just what escape and
risk. But what I would recommend is go
to the Cape dot dev website, which is helps you.
It started as something that helped you test your transmitter
and a receiver implementation. So if you had a receiver, you
needed to have a transfer that would send you events so that
you could you could know that you can receive them and vice
versa. So it started as that, but now
it has a help section. It has, you know, details about
like what is SSF and what is Cape and it even has a white
paper about Cape best practices. So it can help you like plan
your strategy as far as, you know, adoption, implementation
and all that is concerned. There's also open source, which
you can use. So Cape dot dev is actually a
pretty good resource in addition to the videos that I talked
about. So I have those links in.
Our show notes for people to check out and that website for
people to start at is Cape dot dev CAEP dot dev.
That'll put. That'll put you.
Right where you need to go. So I feel like we could probably
go on for hours, but we're not going to do that.
Direct people to websites. Not everyone's able to go to,
you know, conferences and kind of check out the talks that you
and Ian and Tim and Sean and Andrew and Shane and others have
given sort of on this topic. But I would highly encourage
people this is the year to like really understand it because
it's such a big foundational part of what continuous identity
is all about, which is another big trend that we're seeing in
the space. So definitely encourage people
to go check that out. I want to leave the conversation
to hear on a lighter note as we always do.
And I am feeling very anxious because I have not been out of
my house sort of area in two months.
I have not been any trips I've been since I got back from
Gartner. We adopted a puppy so that has
taken up almost all my time. Weather here has been sort of
weird on the East Coast with like different storm systems
coming through. And so my first trip is actually
next week. I'm headed out to a conference
in Richmond, VA, and that's my first time in two months going
anywhere, which is a long time for me.
Usually I'm on the road all the time.
But you mentioned that you had gone somewhere recently in which
I find very fascinating. Tell the audience where you went
and tell us a little bit about this trip.
We went to Kenya and we went specifically to go to some of
their national parks and watch the big games and it was a
blast. It was like unbelievable.
Like you enter the park and you're surrounded by these like
flocks of like large herds of like, you know, wildebeest and
zebras and elephants and whatnot.
And it's these, you know, really huge vistas of open land and
those beautiful trees that they have there.
It was just fascinating. But the, the, I guess the
highlight of the trip was when we were in Masai Mara, one of
their, you know, national parks, We, we saw a bunch of lions
attack, hunt down a, a wild Buffalo.
And it was, it was fascinating how they strategized and how
they isolated 1 Buffalo and then how they literally like trick
the Buffalo into thinking that there was just one little lion
that it was trying to fend off. And it pulled that Buffalo into
this area where the other lions were waiting.
And then they all sort of jumped on it and the poor thing was
fighting them for about 1/2 hour.
You wouldn't believe the amount of effort it took to just pull
down that Buffalo. Like for, for like the four
lions that were on it. Like it was, it was pretty
dramatic. And you know, as soon as that
starts happening, you have these vultures circling around in the
sky and you have the hyenas kind of coming closer and closer.
And finally, when the Buffalo comes down, you, you had these
lions like, you know, start eating it.
And after a while the hyenas chased the lions out and then
they started eating the Buffalo. And then the vultures came in
and it was the whole deal. It was like, wow, you know, I
didn't imagine I would, I would be seeing something like that
from like a distance of 30 or 40 feet, so.
Yeah, it. Was unbelievable.
That's pretty close. It's like this is probably not a
thing for everybody because I think people might get kind of
squeamish around that kind of thing.
But I, I. Right of.
This is, this is you're observing nature.
This is what's happening, Yeah. And.
It's and it's cruel. It's like it's yeah, I couldn't
watch the half of it. Like I was like, OK, I don't
want to see anymore, but I was there.
Did you go with your? Family.
Were there others like how did this work?
Yeah, I went with. My my 2 grown kids and my wife.
And so, yeah, we were, we were all there.
We had flown in from different parts of the US and so we were,
we met there. So tell me about the trip.
Like where? Did you come like, where did you
meet? Into Africa?
So we. Like my younger son lives in New
York and so we met in Amsterdam and we had the same flight from
Amsterdam to my older son lives in San Francisco, which is close
to where I am, hence that little thing there which is my son's
gift to me. And so we started our trip in
San Francisco airport and the three of us, my wife and I, and
my older son flew from San Francisco.
We met in Amsterdam to my younger son.
We, he almost missed the flight, but we fortunately were able to
do that. And then we went to Kenya and
then we went around in in a Jeep for I guess about 8 days.
We were like driving continuously for 6-7 hours for a
few days like because all these parks are in various different
places and you know, so, so it wouldn't be a.
Question, on this show at least about food, what was the best
thing you ate on that trip? Oh.
I'm not, I have dietary restrictions so I I eat chicken,
but mostly vegetarian, right? There's plenty of.
Good stuff out there thing about this.
Trip was that there's a huge Indian community in Kenya, if
you will believe that. And so you had you had a live
dosa station in the in the hotel, which is like, you don't
even get that in many hotels in in the US, Like you get that in
Kenya. And so, yeah, it was as far as
local food is concerned, there were a bunch of dishes in the in
the buffet. I don't know their names, but
they were awesome. Like some of the exotic fruit
were, were like something that I'd never had.
It was, it was a very different experience.
Yeah. Jim, you're a world traveler.
Would you do this? Well, I've heard Nairobi.
Is a beautiful city. I definitely would like to go
there, absolutely. I.
I so I want to bring up the great Frank via Vicencio, right?
He told me a story where he went on safari, I think it was in
Zimbabwe, and very similar story to what Atul just mentioned.
And he mentioned that like, because I can barely watch this
on TV, right? To actually be there, smell the
smells, hear every sound, no commercial breaks, right?
I mean, like, you're in this thing.
And he said he and his wife cried.
I believed it. I did have a question for you at
all. So one of the things I've seen,
it was like on YouTube was like, so there are these tourist
vehicles, right? And they're like looking for
something like this because that's what everybody came to
see, right? Everybody's on safari.
They want to see nature unfold. So then you have one of these
great hunts going on, and then it's like 10 of these vehicles
kind of like make a circle around the hunt.
Was that what it was like? Yeah, it was like.
That there was a probably. And at some point I felt like
the lions actually used that to their advantage, like because,
you know, there was this massive herd of buffaloes and there was
a bunch of lions trying to approach that herd.
And so everybody on the park, like tourists like us felt like,
Oh yeah, there's a hunt going to happen now.
And so everybody had their jeeps, like come in there.
There was 50 odd jeeps there, I think.
And and then the lions kind of use that as a way to deflect
because everybody's attention was in One Direction and the
hunt actually happened right behind us.
So they use that to separate out the herd and to I think what
they did was because everybody's attention was in this way, the,
the, the buffaloes on the other side kind of got separated out
or something and then they went and attacked them.
So I think the Lions actually ended up using.
The situation to. Their advantage so.
But yeah, there were a lot. Of people, Thanks.
Well, here's. Here's how I'm going to make it
a lighter note this If there ever was a real world scenario
for shared signals, framework and risk events, those buffaloes
should have been on that. There you go, lighter.
Note achieved, I hope. OK, well on that terrible
lighter note, no offense that not not for you.
Until they're just a terrible segue, we're going to go ahead
and leave it there for this week.
Thank you so much for joining us.
I'll have your LinkedIn connection information along
with just a handful of links around Cape and SSF and risk and
AI community, AI identity management community group for
people to check out. And thank you again so much for
joining us. So let's see what else?
Yeah, check our website, idcpodcast.com.
We've got all of our discount codes there for the conferences
that are coming up. Hope to see you there.
We'll be at EIC. You'll be Identiverse.
I think you got other things in in the works and plans and
things like that. So thank you so much for liking
and subscribing and sharing with our friend or an enemy.
As long as they're listening, I don't care who it is and leave
it there. So thanks everyone for watching
and or listening and we'll talk with you all in the next one.
Thanks. For having me.
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.