[MINUTES] CCG Atlantic Weekly 2026-01-27

Meeting Summary: CCG Atlantic Weekly - 2026/01/27 Topics Covered:

   - Use cases for Identity and Access Management (IAM) / Access Management
   - Challenges and limitations of traditional IAM systems
   - Introduction to capabilities as an alternative access control model
   - Comparison of capabilities with Access Control Lists (ACLs)
   - Implementing capabilities and overcoming adoption challenges

Key Points:

   - *Limitations of Traditional IAM:* Alan Karp presented a historical
   perspective on IAM, highlighting that many systems struggle with
   complexity, usability, and security vulnerabilities due to being designed
   for overly simplistic use cases. He illustrated this with examples from
   early access control lists, SOA standards, and even modern systems like AWS
   Cedar and Solid.
   - *Hazards in Access Control:* The discussion identified numerous
   hazards in current IAM practices, including:
      - *Excess Authority:* Programs running with all user permissions,
      leading to vulnerabilities like ransomware.
      - *Delegation Issues:* Challenges in managing delegation,
      responsibility tracking, conditional policies, and preventing misuse.
      - *Transit of Access:* Problems arising when access needs to be
      passed through intermediaries or across multiple jurisdictions.
      - *Confused Deputy Vulnerability:* A widespread issue where a service
      incorrectly uses another party's permissions.
      - *Cross-Jurisdiction Challenges:* Difficulty in managing identity
      and access across different organizations or legal entities.
      - *Service Composition Risks:* Security implications when combining
      services from unrelated parties.
   - *Capabilities as a Solution:* Karp advocated for a "capabilities"
   based approach, where access is granted via unforgeable, transferable
   permissions. This model, rooted in early computing research, is argued to
   naturally support delegation, revocation, and cross-jurisdictional access
   without the complexities and vulnerabilities of traditional IAM.
   - *Authorization-Centric vs. Authentication-Centric:* The talk
   contrasted authentication-centric approaches (e.g., identity federation,
   ACLs) with an authorization-centric model based on capabilities. The latter
   prioritizes the question "Should I honor this request?" over "Who are you?".
   - *Addressing Hazards with Capabilities:* Capabilities are presented as
   a way to mitigate many of the identified hazards, including impersonation,
   delegation control, revocation, and the confused deputy problem, often by
   moving policy evaluation off the critical path.
   - *Challenges in Capability Adoption:* Despite their advantages,
   widespread adoption of capabilities is hindered by:
      - *Unfamiliarity:* Programmers are more accustomed to ACL-based
      systems.
      - *Key Management:* The need for secure key management and
      communication between users and wallets.
      - *Perceived Loss of Control:* A common objection, even though
      traditional control is often an illusion.
      - *"Conspiracy Theory":* A speculative explanation suggests
      historical efforts by intelligence agencies to stifle capability research
      in favor of ACLs.
   - *Bridging the Gap:* There's a call to action for the community to
   actively implement and showcase capability-based systems to build awareness
   and comfort, using examples like Digital Bazaar, Agoric, and hardware
   implementations. Verifiable Credentials are also discussed as a potential
   area where capability concepts could be applied, though caution is advised
   to avoid misapplying them for permissions.
   - *Dmitri Zagidulin* highlighted the ongoing work of a new working group
   focused on "delegatable authorization for agents" and the challenges of
   building user interfaces for capability-based systems.
   - *Joe Andrieu* emphasized that the pervasiveness of Linux-style
   permissions and ACLs in programmer education is a significant barrier to
   adopting fundamentally different models like capabilities.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-atlantic-weekly-2026-01-27.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-atlantic-weekly-2026-01-27.mp4
*CCG Atlantic Weekly - 2026/01/27 11:55 EST - Transcript* *Attendees*

Alan Karp, Alan Karp's Presentation, Alex Higuera, Benjamin Young,
Christoph Dorn, Dmitri Zagidulin, Elaine Wooton, Erica Connell, Greg
Bernstein, Harrison Tang, Hendry Poh, Ivan Dzheferov, James Chartrand,
JeffO - HumanOS, JeffO -HumanOS, Jennie Meier, Joe Andrieu, Kaliya Identity
Woman, Kayode Ezike, Leo Sorokin, Mahmoud Alkhraishi, Phillip Long, Rob
Padula, Ted Thibodeau Jr, Vikas Malhotra, Will Abramson
*Transcript*

Will Abramson: Hey.

Alan Karp: How it should I try sharing my screen?

Will Abramson: What's coming on? yeah. You test out here.

Alan Karp: Let's see how this works. Okay. let's see window screen says
you're going to have to restart Chrome.

Will Abramson: No tried it.

Alan Karp: I don't know what this is all about.

Alan Karp: So I don't want audio recording. Hang on.

Alan Karp: What's the site will be able to see the kind. All right. What
are the instructions to your Allow screen recording for Chrome in system
settings. Give me a break.

Will Abramson: Yeah,…

Will Abramson: that might be because the meeting is being recorded.

Alan Karp: I guess I Okay. Allow.

Will Abramson: it's

Alan Karp: All right, I'm back. Let's see if I can share the screen now.
Let's see which one this screen and…

Will Abramson: Yep, I can see it.

Will Abramson: Fine. Do you want to? Yeah, perfect.

Alan Karp: see the slides.

Will Abramson: Yeah, that's great.

Alan Karp: Okay, I can't see what's going on. there's no way in Keynote to
turn off the clock window or the speaker notes window. So I can't see
what's going on. So you'll have to tell me if there are questions or hands
raised or…

Will Abramson: Yeah,…

Alan Karp: anything. Okay.

Will Abramson: no problem. Alan, I can handle the queue. yeah, we'll give
folks another minute or…

Alan Karp: Yeah.

Will Abramson: and then I'll do the admin and…

Alan Karp: Yeah. this is about 2530 minutes long.

Will Abramson: then Okay, perfect. Yeah, have some time for questions.
Great.

Ted Thibodeau Jr: While we're waiting, if you wouldn't mind pasting that
PDF link to the chat, that would be helpful. Thanks.

Alan Karp: I'll have to some okay. Okay.

Will Abramson: I can do it.

Will Abramson: I can do it. Yeah, it's on.

Alan Karp: Or just type it.

Will Abramson: All Yeah. So, that's the link. That should be right. okay.
It says 17 of us.

Will Abramson: I think we can get started. So, hello everyone. Welcome to
today's credentials community group call. Today we have Alan Park joining
us to talk to us about use cases for identity access management or access
management. before we get into that, I'll just run through the standard
field. So, we follow the W3C code of ethics and professional conduct. So
please familiarize yourselves that if you haven't already and let's
continue to make this a joyable environment for everyone to next the IPO so
anyone's welcome to participate in these calls however substantiative
contributors to any CCG work items must be members of the CCG with full IPR
agreements signed.
00:05:00

Will Abramson: If you have any questions about that, just reach out to me
on Mammoo or Den. so yeah, these calls are recorded and are made available
on the mailing list sent out. I think there is an action that I'm going to
look at to try and make them on get them onto YouTube or some other
platform, but I haven't got around to that yet. But maybe they'll be
available more widely in the future. But for now, just remember this is a
recorded call and it will be transcribed by the Google's reintroduction.
Does anyone want to jump on the queue and say hello to the community today?
You're welcome. Okay. Not seeing anyone on the queue.

Will Abramson: Are there any announcement or reminders that people want to
share with the community today? Okay, it's a quiet day. That's fine. Last
one. I imagine there's not been any updates on any of the work items that
people want to share. hearing no one. So with that, I will hand over to you
Alan and take it away. And I'll manage the queue. So I don't know if you
want to have questions at the end or if you don't mind people jumping in,
but I Okay, great.

Alan Karp: people can jump in the middle. That's great. I hate for
misconceptions to linger through the whole talk.

Alan Karp: But I can't see hands go up.

Will Abramson: Yeah, I'll manage the key.

Will Abramson: No problem.

Alan Karp: So I'm going to give you everything of substance that I'm going
to say is in this document. So if you prefer bedtime reading or just find
my voice annoying, you don't have to stick around. this talk is unusual in
that the story behind it starts 30 years ago. It's a bit embarrassing for
me as you'll see. what I learned was that finding the answer to a question
and knowing you found it are two very different things.

Alan Karp: so what took me so long? 30 years ago, I was designing access
control for a system of a million machines, which sounded like a big number
at the time. The only mechanism I knew was access control lists, alles. and
it took me about a New York minute to realize that wouldn't scale. I
eventually figured out a solution, but it also got me interested in how
others dealt with the problem. And what I found surprised me. Every single
system I looked at had serious problems. Some had actual vulnerabilities.
All of them were complex and had really serious usability issues. And the
question And this talk is my answer to that question. So let me give you a
few examples. back around 2000, the servicesoriented architecture was all
the rage.

Alan Karp: everybody and her brother-in-law was developing standards for
it. At one point I counted 87 unique standards. also around that time I was
a regular speaker at the RSA conference which meant I got a full conference
pass and so I attended a lot of AM sessions. One in particular was by the
Liberty Alliance and it caught my eye because they claimed they could do
something I didn't think They gave a great talk, but at the end they said
their system didn't quite work for this one particular case, but they come
back next year with a new standard to fix it. Next year, One use case
didn't work. Same for the next year and the one after that. At that point,
RSA stopped accepting my talk proposals. And I wasn't going to shell out
2,000 bucks for a full conference pass. So, I don't know what happened. For
all I know, they're still going.

Alan Karp: Another example is Cedar from AWS which is a great system. I
highly recommend you look at it if you have to manage access policies.
However, the way people use it introduces a performance problem that can
lead to a security weakness as I'll show you later. And solid is Tim
Berners Lee's reinventing of the web and they're doing a lot of good work,
but it's Apple based and they're running into the scalability issues that I
encountered. come on. All right. jump ahead some 15 years.
00:10:00

Alan Karp: we were working with the US Navy on an access control problem
and came up with a solution that actually solved problems the Navy didn't
even know they had. And I thought that made the work a great idea for a
paper. But the Navy's problem had a lot of components that made it hard to
describe. So I abstracted it to a simple use case. Here, Alice uses Bob's
backup service, which he implements using Carol's copy service. Something I
call the transit of access problem. It captures the essence of the problem
the Navy brought to us. We won a best paper award at a conference nobody
ever heard of, which I guess is better than not winning a best paper award
at a conference nobody ever heard of.

Alan Karp: And then another 15 years went by and I was sitting at the
closing circle at IW waiting for it to start when I had the My example from
15 years before answered my 30-year-old question and it had taken me that
long to realize it. The answer is that the identity and access management
systems had those problems because they were designed for use cases that
were too simple. And it's embarrassing how long it took me to realize that.
And since I realized that, I've been looking at identity and access
management systems that people are developing. And again, their use cases
are too simple. So I put together this report and this talk to explain that.

Alan Karp: as I go through the set of use cases of increasing complexity,
for each one, I'll point out the hazards that your system has to deal with.
And hazards are not failures, of course, unless you can't handle them.
They're just things you have to deal with. So, here's basic access control.
We're all familiar with this. there are two users, Alice and Bob. three
resources X, Y, and Z that have APIs with two methods, query and update.
And the lines show who has permission to what resource. This was the only
use case for our earliest multi-user operating system. And this use case
neglects delegation, leaving only impersonation.

Alan Karp: If Alice wants Bob's help on working on X, she has to share her
credentials with him. And this has the real problem of excess authority.
What it means is that every program you run runs with all your permissions.
This is why viruses and ransomware are such a big problem. But in fact,
this picture is a Just think for a second. What's the lie? We don't give
permissions to the program. We give permissions to Alice, the person. And
we never asked the question back then. Does every program Alice run need
all of Alice's permissions? We did ask that question in 2000, which is why
our mobile operating systems are easier to secure.

Alan Karp: Just imagine how much better life would have been if we'd asked
that question in 1970. All right. So, we've identified delegation as an
important use case. giving Alice a way to selectively share one or more of
her permissions with Bob. in these pictures, green denotes a delegated
permission. and note that the picture doesn't show how that permission was
delegated, just that it exists. There are a number of hazards. The first is
how you make the change in the rules. In most of our operating systems such
as Linux, you add Bob to the access control list On Mac OS, Windows, and
others, only an admin or the owner can make that change. The hazard here is
Alice delegating to Bob if she's neither admin nor the owner.

Alan Karp: That explains why you typically ran as with admin privileges on
early Windows systems. Another hazard is responsibility tracking. The log
file shows that the resources owner changed the yle. Does it show that's
because Alice asked? It could, but I've never heard of one that Another one
is conditional policy. So let's say that Alice wants Bob to have access
only certain circumstances such as work hours. How does she express that?
The Apple could include a place for it, but again I've never heard of one
that does. Another hazard is non-Apple systems like Cedar. it allows for
delegation v via policy changes.
00:15:00

Alan Karp: So if the policy for Alice allows query access to X, she can
create a policy for Bob that grants him that permission. Very clever. The
problem is not that it's the way it's used. Bob's policy is evaluated when
he makes the request, which can take a lot of time for a complex policy.
the Cedar folks are working really hard to optimize, but the risk is that
people will use simpler policies than they need and those policies will
overprovision users. Another use case is change Alice delegates to Bob who
delegates to Dave. And you're going to hear this hazard you've lost
control. everybody wants to block it.

Alan Karp: I hear this all the time and it's a mistake. Experience has
shown that people will share credentials to get around the restriction. If
you can block credential sharing, even if you can block credential sharing,
which Bob can always proxy request for Dave. In either case, the system is
harder to use and less secure. And it even prevents an important pattern.
Maybe Dave is a program that Bob would like to run but doesn't trust with
all his permissions. That's what he's going to have to do if he can't
delegate this one permission to it. So the lesson here don't prohibit what
you can't prevent. Then there are times when the delegator doesn't have a
communication path to the delegate and must go through an intermediary.

Alan Karp: In this example, Alice wants to delegate to Dave but doesn't
have a communication path to him. She must permiss pass the permission
through Bob. But the hazard is that she doesn't want Bob to have the
permission. So, can your AM design handle this case? And of course, you
need to be able to revoke delegations. Perhaps Bob has changed jobs and
should no longer be see future changes to X. One hazard is who has
permission to revoke. Alice asked the owner to change the alle is the owner
expected to remember that another hazard is redellegation. if the owner
only changes the access control is for Bob, Dave still has access but maybe
Dave is a sock puppet controlled by Bob.

Alan Karp: So that means when you need to revoke all downstream
delegations, but the information you need isn't usually recorded in
existing systems. There's an interesting example that Alice is a department
head and Bob is one of her managers. Shes to Bob who's delegated to Dave
and a bunch of other people in the department. Dave's permission should be
revoked if he gets fired. But what if Bob isn't available? If Alice revokes
Bob's access, nobody else in the department will be able to query X because
of the sock puppet problem. So, can your AM system handle this case?
Another example is independent delegations. Both Alice and Dave have
delegated the same permission to Bob.

Alan Karp: So when Bob queries X, can if he's using the delegation from
Alice or the one from Dave? Consultants would like to have that information
so it make it easier to keep billing their clients straight. But what if
Alice revokes her delegation to Bob? Can he still use the delegation from
Dave? not in any ALE system I've ever heard of. And then there are composed
delegations. Say that Dave gets a permission for one resource from Alice
and a permission from a different resource from Bob. Can he use them
together? Can he make one call with two parameters with each of these
permissions? And the answer is yes in most systems, but there are some
role-based access control implementations that let you only be in one role
at a time, in which case the answer is you can't.
00:20:00

Alan Karp: so far we've assumed that all invocations involve a single
resource, but APIs frequently take multiple resource arguments. In this
example, Alice is asking Bob to update Y based on data from X. But what are
you going to do if Alice supplies an output argument that she doesn't have
permission to update, but Bob does? The red line and let red letter U
denote the effects of Alice invoking Bob this way. It's as if she had the
actual permission. This is the confused deputy vulnerability and it's
widespread. Examples include cross-sight request forgery, clickjacking, and
others. You might think that Bob can prevent the attack by checking Alice's
permissions, but I'll show you an example later where that would break the
law.

Alan Karp: the confused deputy vulnerability actually confuses a lot of
people. I've run across two access management systems that have features
designed to prevent the confused deputy vulnerability, but the
vulnerability they're preventing has nothing to do with this. So I think
the Wikipedia article describing it is quite good and I would use that one.
But the essence is if Bob is using his permissions for a resource
designated by somebody else, that's the essence of the confused deputy
vulnerability. so far we've been talking about one machine or maybe one
jurisdiction. I like the word jurisdiction because a jurisdiction makes its
own rules and the word isn't overloaded like the word domain.

Alan Karp: You'll notice I still have the word domain on the slides and
that's just because it's shorter. but what if one or more of accesses of a
resource comes from a different jurisdiction? Here I'm showing two
companies, Aperture and Cyd Cyberdine. In a conventional systems, Alice's
and Bob's identities get federated into Cyberdine and Errol has delegated
some permissions to Bob and Bob has delegated them at least a subset of
them to Alice. When everything is in one jurisdiction, Carol has a way to
attach Alice, the user Alice, with a person she can hold responsible. But
that doesn't work across jurisdictions.

Alan Karp: The best she can do is report Alice's misconduct to Aperture.
And of course, there's a confused deputy vulnerability. But here, it's
harder to deal with. It might even break the law for Bob to know if Alice
has update permission to the resource labeled V. Perhaps Cyberdine is a
health care provider and that would run counter to HIPPA requirements. And
then we get to the service composition. And in the pictures I'm using now,
it looks like an employee of Aperture, has delegated to Bob in Bluth, who
in turn delegates to Carol at Cyberdine. What makes this example different
from the others is that access to resources is being shared by parties that
have no relationship. They may never even have heard of each other.

Alan Karp: So let's say that we're federating identities. Aperture has a
contract with Bluth won with Cyberdine and Aperture and Cyberdine have no
relationship with each other at all. So Aperture federates Bob's identity
into its system after a security audit of Bluth. The only way for Bob to
delegate to Carol is for her identity be federated into Bluth and for Bluth
to federate it into Aperture. But note that Aperture never did a security
audit of Cyberdine. In the case of the target breach, the attacker
exploited a vulnerability in a subcontractor system. So this use case has
really important implications.

Alan Karp: There's also the issue that Bob has entries in the alkaline
aperture that he'll never use. So, they're subject to misuse by accident or
exploit. And they can't be revoked without revoking Carol's access. And we
have the same audit failure we saw before. Here though, the unknown
identity is from an unknown jurisdiction. Alice doesn't even know that
Cyberdine exists, much less that Carol works there. And there's the
confused deputy vulnerability. In the next set of slides, I'll show you a
number of variants that might surprise you. And I think that's what the
program committee at that conference liked. Here, Bob's resource Z gets
changed based on a request from Alice, but the log shows that Carol did the
update.
00:25:00

Alan Karp: In this variant, Alice is able to change the contents of a
resource in Carol's jurisdiction. Even though these companies might even
know about each other, must have a contractual relationship. And this one's
my favorite. Alice can even arrange to see the contents of anything Alice
can see, even though those companies have no relationship. So, what have we
learned from these examples? If your design doesn't consider all the ways
your system will be used, you'll have vulnerability, complexity, and
usability issues. And that's why all the IM systems I looked at had these
issues. You should also have noticed that many of these issues come from an
identity first approach. So what are we going to do about it?

Alan Karp: We won't be able to fix the problems without a deeper
understanding of the access control process and why these use cases are
important. Mark Stigler has identified seven aspects of sharing that are
well supported in meat space but not in cyerspace. It's dynamic. You need
to be able to delegate in a timely manner. That means even when the owner
isn't available. It's attenuated. We're talking about delegation, not
impersonation. It's chained. You must be able to redelegate. These last two
are really important. Without chaining, every private is saying, "Yes, sir,
Mr. President." And without attenuation, that private ends up with
permission to launch nukes. it has to be composable.

Alan Karp: You can combine permissions from different sources in a single
request and accountable even across jurisdictions as we saw in the three
jurisdiction Revocable, which is much more complicated than many people
think, and cross domain. It's got to work across jurisdictions. To see how
to support those seven aspects of sharing, we need to look more closely at
the access control process.

Alan Karp: I contend it consists of four steps. Feitiously, that's knowing
who to throw in jail. Seriously, it's assigning a responsible party.
Authorize. A job comes with rights and responsibility. This step is how you
get the rights to carry out your responsibility. Authenticate. You're not
in the machine. Programs need to prove that they're running on your behalf.

Alan Karp: so that the system knows to apply your policy to those programs.
And then there's the access decision to determine if a request is
authorized and should be honored. Each of these can be done before the
invocation or with it and in the user's jurisdiction are the services. Now,
it only makes sense to do the identification in the user's jurisdiction
before any requests are made. I got hired by HP. They checked my driver's
license, took a thumb print, a DNA sample, they did the identification then
before I even knew what I might want to do. Similarly, it only makes sense
to make the access decision in the domain services jurisdiction when a
request is received. We have flexibility with the other two.

Alan Karp: So let's start with an authentication first approach which is
what identity federation and ales are all about. In an identity first
system we set up the alle in the service jurisdiction before the request is
made. That's why we federate identities to have a place to put that
information. You also authenticate when you make your request so the system
knows which to look In an authorization first approach, users authenticate
and authorize in their own jurisdiction before making any request. And this
change has important implications and That name is capabilities.

Alan Karp: so went the wrong direction. so what is a capability? It's an
unforgeable transferable permission to use the thing it designates. So
think for a minute a second five seconds. Have you ever used a capability?
I was going to do a Zoom survey but I couldn't figure out how to do that.
For those of you who said no, do you want to change your mind? In fact,
capabilities are very close approximations to them are pervasive in the
physical world. If we want to support the seven aspects of sharing online,
maybe we should adopt them there. So, let's go through the use cases again
with an authorization first mindset.
00:30:00

Alan Karp: there are many ways to implement capabilities. For this talk
I'll assume we're using cryptographically signed certificates and as you'll
see capabilities handle all the hazards. So our first example is from the
1970s and delegation can be built in as was demonstrated in 1968 by Dennis
and Van Horn. So this is not a new idea at all and it handles the hazard of
impersonation because now you can start your program with only the
capabilities they need. So there's no more risk of crypto locker just
because your solid pair program got hacked. How about availability? Alice
can create a new delegation from one of hers without help from anyone else.

Alan Karp: The certificate incl can include the delegation chain and you
can offiscate the parts that might violate privacy. That was part that the
Navy liked very much about this. The certificate can also contain what some
people call caveats that contain policy statements that can be evaluated
when a request is received. In a system like Cedar where you use the policy
engine, instead of using it at request time, use it to hand out
capabilities that can move the policy evaluation off the critical path.
Essentially, the capability is a cache of the policy decision and that can
be used until the policy changes at which point it gets revoked.

Alan Karp: We have changed delegations where Alice has delegated to Bob and
Bob to Dave. and this hazard of you've lost control doesn't go away. Stand
your ground. The control people think they have from limiting delegation is
an illusion. What about Revocation is easy since the capability says what
resource it's for. The delegator tells the resource to stop honoring this
particular capability and the resource knows that the delegator is the one
with the permission to revoke and the verifier knows not to honor
downstream delegations from one that's been revoked. Skip revocation can be
handled in a couple of ways.

Alan Karp: One is the verifier allowing revocation at any point deeper in
the chain than the revoker or by making revoke an explicit permission on
the capability. Here Bob gets independent delegations and normally Bob
would just use the appropriate capability to make accounting easy. Using
the wrong one would simply be a bug. So capabilities don't solve all
problems. And if Alice revokes the capability she gave to Bob, he still has
the one he got from Compose delegations work just fine. The capabilities
are separate certificates, so they can be used in any combination. And what
about the confused deputy?

Alan Karp: The source of the vulnerability is Bob using his permissions to
access a resource designated by Alice. And in a capability system, you
designate the resource by its capability. Some capability systems don't
require this, which I think is a mistake. But there can be no confused
deputy because Alice can't designate Z with an update permission because
she simply doesn't have that capability. Cross jurisdiction delegation
doesn't require any federation. All it needs is a way to get a capability
from here to there. I have a talk I proposed to RSA that they rejected
called identity federation is difficult, expensive, and unnecessary.
00:35:00

Alan Karp: And this is why there's no audit failure because the capability
Alice uses shows that Bob delegated to her. And that means that ol how
knows to hold Bob responsible if Alice does something bad. And you can even
delegate your summon you don't trust with the permission. You just issue
the capability certificate to a public key where only Carol knows the
corresponding private key. And there are none of the transitive access
hazards. For example, Bob can just forget the capabilities he doesn't need
and Carol can still use them. So the lessons we've learned, the same ones
we started at the beginning with another one that all can be more easily
addressed with an author authorization centric IIA.

Alan Karp: ask yourself the What is the most important question you should
ask when your service reques In an authorization in an authentication
centric approach, you would say who are you? And then you would use that
information to somehow look up if the request was authorized. It's that
indirection from who are you to is this request authorized that's the
source a lot of complexity and vulnerability instead the most request
important question to ask is should I honor this request in other words is
this request authorized and that's the authorization centric approach so
those stuck around now I'll take questions

Will Abramson: Yeah, I have Ted on the queue. I didn't…

Will Abramson: if you want to jump in on that, Ted.

Alan Karp: I can't see the key.

Ted Thibodeau Jr: Yeah,…

Ted Thibodeau Jr: this is really simple. If we could get a download link
for the slide deck as opposed to the full paper.

Alan Karp: The full paper has everything of substance that I mentioned and…

Alan Karp: explained much better.

Ted Thibodeau Jr: I believe you.

Ted Thibodeau Jr: It's just that the deck gives you a condensed thing to
process.

Alan Karp: Okay.

Ted Thibodeau Jr: I will read them both together and I will get more out of
it than just from the paper.

Alan Karp: I'll have to put the deck on a plate It's not in a place that's
accessible. It's just on my machine right now.

Ted Thibodeau Jr: Fair enough. If you could send the link to the mailing
list, that's perfect.

Alan Karp: Okay.

Will Abramson: Okay, great.

Will Abramson: Thanks, This was excellent. I really enjoyed this walk
through after different cases. I guess I have a question, but let's take
Carson first. Harrison.

Harrison Tang: Yes, great talk. So, I read one of your, papers on the, I
think it's like introduction to capabilities. You talk about how,
capability is one way to collapse the access, matrix into one dimension.
and ACL access control list is also a way to collapse access met matrix to
another dimension right so the two dimensions are …

Alan Karp: right?

Harrison Tang: who and what resource right and my question is have why not
have both capability and ACL's right because if capabilities is one way to
collapse

Harrison Tang: a two-dimensional matrix into a vector and then ACL is
another way but collapsing a different dimensions. why not have both
dimensions to ensure that no edge cases gets through right or…

Harrison Tang: got skipped. Yeah.

Alan Karp: So that was tried in the early 80s primarily by Lee Gome and…

Alan Karp: what happened was it introduced additional vulnerabilities. He
thought that it would provide security in depth by having an extra barrier
to cross. But in fact what it was it introduced an independent set of
channels to attack. So instead of adding an extra wall to your castle, it
was introducing an extra gate. So now you had two places to protect instead
of the main difference between those two models of collapsing the access
matrix the ACO model does not include a mechanism for how to update the
access matrix whereas capabilities it's inherent and that's why
capabilities naturally support delegation and it's extremely awkward in the
AK model. Hope that answered your question.
00:40:00

Harrison Tang: All right, thanks

Alan Karp: you can go back to Lee Dong's papers to see…

Alan Karp: what he did and you'll see the additional vulnerabilities

Will Abramson: Great. Thanks,…

Will Abramson: Dimmitri.

Dmitri Zagidulin: I wanted to add a comment to the previous question about
why not have both. In a way, you could have the user interface for both but
have the root of the system still rest on capabilities. And this was
briefly mentioned in one of the slides that Alan mentioned which is that
cedar slide that policy engine slide you can have the alle any kind of for
example group logic right let's take a concrete example where is alles
useful with groups but the thing is you don't need to have the system
understand alles you just need

Dmitri Zagidulin: the policy engine to understand s the storage system or
whatever the access control system just needs to understand capabilities,
So you can have both without the security vulnerabilities by composing and
by treating the ales on the UI and the policy level but not on the
authorization.

Alan Karp: That's exactly And in fact, companies, enterprises have spent
enormous amounts of money building attribute-based access control
mechanisms. And you don't have to throw them away. you just in the Cedar
case, you use those mechanisms to decide what set of capabilities to give
to each employee. But then when it comes time to make an invocation, you
use the capabilities. then you look up use the policy to hand out
capabilities,…

Alan Karp: not to make the access decision. So Demetri is exactly right.

Will Abramson: Yeah,…

Will Abramson: I really liked…

Will Abramson: what you were saying. I think you called it it's a cached
policy decision or policy evaluation, right? That's a lot the nice mood.

Alan Karp: And it doesn't have to be just with Cedar.

Alan Karp: It could be with your Arbback system that you're com Yeah.

Will Abramson: You on the

Mahmoud Alkhraishi: Thank you so much for the call, for the talk on this
has been wonderful. I'm going to echo Ted's request for the slides. I know
you already said you're going to do it, but this has been absolutely great.
One question for what are the biggest pitfalls with implementing
capabilities and what has been the biggest challenges with implementing
capabilities that you've seen?

Alan Karp: So, I've been lurking on a number of these groups. and my goal
is to help people avoid the newbie mistakes that I made when I was a
newbie. and one of the mistakes is to issue a digital certificate that
designates a set of resources. You can actually end up with a confused
deputy vulnerability if you do that. Now it's convenient for delegation but
my point is that you can't use that for invocation.

Alan Karp: The invocation has to be a real capability that deitates a
thing, not things. because then you would be separating designation from
authorization, which is the root cause of confused deputy. So that's the
number one thing that I see people dealing with. And the other one is
attempting to block delegation. that just breaks so many things. And it's a
hard battle to win. The other thing I've seen happen now with the
verifiable credentials work is those credentials were designed to handle
things that I would call claims. You graduated from this university. You
passed your driver's test. and they want to use those certificates for
permissions. You may read this file.

Alan Karp: you may invoke that service and that is a mistake because what
does delegation mean for you passed your driver's test? revocation is done
quite differently if it's for permission or they found out you plagiarized
your thesis and want to revoke that certificate. And I've been battling
against that for the longest time. And the concern there is that developers
will introduce vulnerabilities by being confused about exactly…
00:45:00

Alan Karp: what they're doing depending on the case. So those are the ones
that I run into u most often.

Will Abramson: Thanks Alan and…

Will Abramson: De don't mind I just have a question but kind of following
on to that just I think you make a great case for capabilities what do you
think is stopping why aren't we using capabilities more why aren't they
more adopted throughout our software systems and even like you say some of
the same patterns are getting reproduced in verifiable credentials work and…

Will Abramson: there is work to build verifiable credential capabilities a
data format like Zcaps I don't know if you have any insight there about why

Alan Karp: There is a conspiracy theory.

Alan Karp: I don't know if I should say it on the recording, but I'll go
ahead anyway. when I was working at HP Labs, we got a new director or guy
to handle relationships with the government and he had spent most of his
career at the NSA and he said he couldn't answer our questions directly but
the way he nodded his head blinked we could infer things. So the conspiracy
theory is that back in the mid to late 70s the NSA decided that they would
not be able to break into a capability-based operating system but they
could do one based on ales so what they did was they arranged funding for
capability research by people who did not understand capabilities who
fundamentally

Alan Karp: ly misunderstood the basis of them and the that have two pieces
of evidence for that. One is Lee Gong's work that I've already mentioned
and the other is Jack Dennis who was the inventor of capabilities. I ran
into him at a conference and I asked him if he was still working on them
and he says no. His funding dried up by 1980. So he moved on to other
things. Now it's a pure conspiracy theory with only circumstantial evidence
to support it.

Alan Karp: So that may not be why, but at least it's fun to think about.

Will Abramson: Thanks guys.

Will Abramson: Very interesting. Demetri

Dmitri Zagidulin: So I can offer an additional non-conspiracy answer to
that which is so the perspective is so I'm an implementer of Zcaps of
capabilities in decentralized storage protocol wallet attached storage so
the additional non-conspiracy answer is several things are hard and this is
going to be familiar to all of you. Why do we not see more capability based
systems especially for cross domain authorization?

Dmitri Zagidulin: It requires key management which requires giving websites
and mobile apps the ability to communicate with wallets. So all of the
answers to why are we not seeing more verifiable credentials which
essentially boils down to cuz wallets are hard.

Joe Andrieu: Copy.

Dmitri Zagidulin: Why are wallets hard? because protocols between web apps
and apps are tightly controlled by the OS system manufacturers and we
essentially only have the identity credential API and…

Dmitri Zagidulin: Chappie I suppose that still reduces it to a conspiracies
theory so it wasn't quite but I raised my hand for a different question
ahead go ahead Alan

Alan Karp: Yeah. I was just going to respond that you need the wallet…

Alan Karp: if you're issuing the key to Carol's private public key. But in
fact, I think things get a lot easier if you just issue them to a public
key that Carol told you to use that was created specifically for this case.
And then I don't know if you actually need a wallet because the key doesn't
need as much protection as an important key that used for many things. So I
don't know I haven't done that implementation.

Alan Karp: We did do an implementation using SAML assertions.
00:50:00

Alan Karp: Sample 1.1 that's how long ago it was. and we didn't find a
problem with key management in that case but we used oneoff keys. Okay. Yes.

Dmitri Zagidulin: …

Dmitri Zagidulin: you' You're absolutely right. for a lot of the use cases,
you don't need wallets. And so, the hard thing there is newish it's not
unsolvable. we're going to solve we're going to go through this but it's
just slightly more unfamiliar to developers how to do that user interface
for Alice's word processing to ask the permission of this particular file…

Alan Karp: Yeah. I just want to comment that we have a paper.

Dmitri Zagidulin: but yeah

Alan Karp: We did a prototype and we got a bunch of users and we did such a
good job.

Alan Karp: One of our users asked us how to turn on security. because it is
with capabilities it's possible to as we said in the title of the paper
make policy decisions disappear into the user's workflow.

Alan Karp: So we could infer exactly what the user wanted to do from their
actions in the UI. We never had to ask a security question.

Dmitri Zagidulin: I have no doubt the UI problems are solvable. they're
just a little new to developers.

Will Abramson: So, yeah,…

Dmitri Zagidulin: I wanted to address Yeah.

Will Abramson: go for it. I just want to fight. There's three people on the
ce to get through them all, but yeah, you have a question. Go for it.

Dmitri Zagidulin:

Dmitri Zagidulin: Super quick. those of you who are listening to this and
are like hey are there specs or libraries that we can do this. I want to
invite you all to a diff working group that just started up recently that
are working on this exact thing which is delegatable authorization for
agents. So those of you…

Dmitri Zagidulin: who are interested invite to collaborate over there.
Thanks.

Will Abramson: Great. Thanks,…

Will Abramson: Demitri Mammud.

Mahmoud Alkhraishi: What are the big arguments against capabilities that
you have other than it's difficult?

Alan Karp: Yeah. the number one is that you've lost control.

Alan Karp: Even though that control was an illusion, that's the number one
argument I run into against them. also that they're unfamiliar. People
think it's some brand new idea even though it's been tried and tested.
There was a capability based operating system in the early 80s called
Kikos. We now have seal for Linux kernel. We have the Cherry hardware
implementations now available from ARM and Risk 5. So, the main objection
is…

Alan Karp: if they're so great, why don't we use them? And to that I go
back to the u to the conspiracy theory but in fact they are being used in
production by digital bazaar at scale. So of course digital bazaar does a
good job hiding that on their web page but their github repository is a
good explanation of what they're doing.

Will Abramson: Great. Thanks,…

Will Abramson: Joe

Joe Andrieu: Yeah,…

Joe Andrieu: I just wanted to say I think the biggest obstacle here is that
everyone most programmers in the world learned had access to Linux style
permissionings as part of their fundamental baptism into what does it mean
to code and how do you manage digital environments and so the ACLU
architecture that every programmer has to become familiar with just to pass
the introduction to C++ class is the querty version of this problem that
we're sort of locked into the familiar the understood the wellstudied and
this stuff all just looks different and it feels weird and I think that's
the biggest obstacle

Alan Karp: I agree. I think that that's quite true. But, things are
breaking and I have a talk that I give about I'm old enough to have lived
through all the wrong decisions we made. so I can explain at each step why
the decision made sense and why it was wrong. But we got to this point and
it's hard to change what you're familiar with.

Alan Karp: Although in the physical world we have no problem handing our
car key to the valet or giving a movie ticket to a friend.

Will Abramson: Yes. …

Will Abramson: what Jo said kind of made I think this talk is some way to
addressing that in a bit, sort of getting some more visibility over these
things, but are there other things that we as a community could or should
be doing to make people more aware of, more comfortable with using
capabilities, building with capabilities, even recognizing that that's an
option in their systems. I just wonder…
00:55:00

Alan Karp: Yeah, I think the number one thing is do it,…

Will Abramson: how we can make progress.

Will Abramson: Mhm.

Alan Karp: use it for your customers to show that it works. I pointed to
digital bizaar and Kikos and the hardware implementations. the more we have
the easier it will be to convince people that they should at least consider
it. So if anybody is using capabilities in production, let me know. Gino is
setting up a website where we can list those cases. by the way, it's being
used also by Agoric to do smart contracts on blockchain. they're using not
a certificate-based capability system but a different kind but not based on
digital certificates and by the way we've digital certificates have the
performance hit of having to deal with all the signatures.

Alan Karp: So there's macaroons that do hashing which is faster and it's
easy enough to use just simple opaque strings essentially bearer tokens for
systems that need high performance. We designed a system for HP that did
many thousands of requests per second per server using beer essentially
bearer tokens as capabilities.

Alan Karp: So there many architectural options.

Will Abramson: Great.

Will Abramson: Any final questions? I'm happy to give people five minutes
back. leave some space there.

Alan Karp: Can I just send you the slides? How about that? You have the
slides.

Alan Karp: I sent them to you. Can you have a place to put them for the
group,…

Mahmoud Alkhraishi: Yeah, if you send it so we can share with the Ready?

Will Abramson: …

Alan Karp: Yeah, you can share and I sent him as a backup in case I have
technical problems. I'm a belt and suspenders kind of guy.

Will Abramson: Yeah, I can share them with the group. I forgot about that.
That's fine. I'll send an email out.

Alan Karp: Okay. Bye.

Will Abramson: No problem. Okay, wonderful.

Will Abramson: Thanks everybody and I guess we'll see you next week if not
before. Cheers. Thanks again Alan.
Meeting ended after 00:59:38 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*