ucan-wg
Restricting redelegation
User Story
Agent X wants to delegate capability A on resource B to agent Y, but they wish to prevent agent Y from redelegating to Agent Z (ideally a-priori rather than by later revoking Agent Y's delegation, or by keeping the expiry so short that the damage of a re-share is trivial)
Use Cases
- god I hate to say this but, DRM
- there are many cases where there are security concerns with sharing access that can be reshared
Questions
- Has this been considered already? Is there a reason it's not possible? Is this possible already and I'm just not smart enough to see it?
- Could it be baked in as a policy on the delegation itself, especially if the invoker were somehow a field in the caveats?
Has this been considered already?
TLDR: yes, this comes up every few months.
"Preventing delegation" comes up from time to time (there are prior Issues addressing it, it may be in the FAQ). When know from real world cases in earlier systems that in this case people share private keys (by analogy: kind of like Netflix password sharing) to work around this scenario, which is a significantly worse tradeoff for the system as a whole. This is not just in UCAN, but many previous systems (a couple decades of history). In general we STRONGLY discourage relying on such designs.
We don't recommend it but you can still achieve the kind of thing that I think you're asking for by requiring that an invocation that shows membership in a server proxy allow list.
// Invocation
{
cmd: "/my/command",
args: {
allowlist: "merkle...proof...of..membership...in...allowlist",
then: ["more", "args"]
}
}
This has the same problem where a user could share their private key with the user we intend to restrict — there is no known way around that — but also we can't prevent you from working around UCAN itself.
Actually I'm going to reopen this. It definitely used to be i the FAQ but may have been lost when we split the specs up and should be in there.
yea, since I imagine it will come up frequently, it would be helpful to have an explanation. I think the baseline explanation is important for enterprise sales cases -- the idea that you hand off a delegation to someone and they can redelegate forever has creates an intuitive anxiety reaction for pretty much anyone in corporate IT.
FWIW, the counterpoint to the Netflix argument is that if you assume the netflix password is your private key, there's a higher cost to sharing a private key than making another delegation.
it would be helpful to have an explanation
👍 will do
the idea that you hand off a delegation to someone and they can redelegate forever has creates an intuitive anxiety reaction for pretty much anyone in corporate IT.
Agreed that's likely true — and in that case they may want to trade off for a system with worse scale and agency, but higher centralized control. No auth system (or distributed systems architecture more broadly) will be the right choice for every possible use case. Perhaps we should totally put together a guide to help folks know when they should choose a different technology. It's not straightforward — you'd expect Google to be on what you describe as the "corporate" side of this tradeoff, but they've also been moving towards delegable auth because they can't handle the volume of requests that they get on a single central auth server, so centralization is also a YMMV. The Merkle proof version given above is in essence in Google's suite of auth scaling strategies.
FWIW, the counterpoint to the Netflix argument is that if you assume the netflix password is your private key, there's a higher cost to sharing a private key than making another delegation.
I'm not sure that I follow. Indeed, your Netflix password is the key to your account. We want to make the less secure thing (handing out root access to your account) less convenient than delegation (which can be attenuated, granularly revoked, etc)