Why can't the tokens in a UCAN's proof give access?

#1

Hi,

I just discovered UCANs and I don’t get how the prf tokens can be present while not giving their privileges.

Let’s take a concrete example. Alice has the following UCAN A1:

A1 = {
  "scp": "/foo.txt"
  "ptc": "READ/WRITE/COMMENT",
  "prf": null,
}

She wants to authorize Bob to read and add comments, so she issues the following UCAN B1:

B1 = {
  "scp": "/foo.txt"
  "ptc": "READ/COMMENT",
  "prf": hash(A1),
}

As only a hash is used, of course, the server can verify the proof of B1 and Bob cannot use A1 for himself. But the presentation of UCANs says the full proof could be in Bob’s UCAN. Then it would look like that, wouldn’t it?

B2 = {
  "scp": "/foo.txt"
  "ptc": "READ/COMMENT",
  "prf": A1,
}

In this latter case, what would stop Bob from extracting A1 and using it to write the file?

#2

Hello @kephasp :wave: :slight_smile:

UCANs are signed. So A1 additionally has two things: (1) the audience for the UCAN, which is essentially a public key, then (2) a signature from alice that signs the whole UCAN. This makes sure that Bob can’t forge UCANs to impersonate alice.

Additionally, bob can’t use A1, because essentially the issuer and audience fields in A1 are explicitly stating “this is giving rights from alice to bob”, but a service would only accept an operation if given a UCAN that says “this is giving rights to the service”, i.e. a request to a service needs to have the audience set to the DID of the service. Think of it like giving the service temporary (30 seconds?) access to your resource by delegating it to the service.

This is actually one of the interesting properties of UCANs: Reading a UCAN doesn’t give you any access (unless the UCAN is addressed to the service already, but these UCANs tend to be very short-lived).
We explicitly need that property since browsers are really hostile environments and e.g. extensions can read almost all website data, except for non-exportable asymmetric WebCrypto keys, which is what becomes the basis for UCAN’s security!

2 Likes
#3

OK, the text said that UCANs follow the object-capability model, but with ocaps, you don’t care about the identity of the agent using a capability, just the capability, hence my understanding.

Does that mean it’s impossible to make an open delegation that anyone can use?

#4

Right. With UCANs you don’t get rid of identity, since it’s still very much related to permissions conceptually, but you detach identities from the service checking them.

Anyone can create a key pair and get capabilities delegated to them.

This sounds interesting, but also confusing.

  1. Will that open delegation be readable publicly or just sent to some group/individuals?
  2. Should the open delegation’s capabilities only be granted to the first person using them or all?

Essentially I’m confused why you’d need a permissions system if you want to open it up in some way, although I might just totally misunderstand your use case!

1 Like
#5

With UCANs, if Alice wants to delegate to any member of a dynamic group of people, everytime a new member of the group wants to actually use the delegation, there needs to be an interaction between that new member and Alice.

Whereas in the ocaps model, Alice can send a capability to a place that’s readable by the group members, whoever they were, are, or will be, and anyone with read access to this place can make use of the delegation, even when Alice isn’t reachable. It’s precisely one of those scenarios that shows that permissions and identity are orthogonal in many cases.

Moreover, when delegation gets bound to identity, it fails in this scenario, because if a group member is cast out, when a delegation has been given to them individually by Alice because they were previously member of the group, then they retain access but they should lose it.

In the ocaps model, the capability given to the group by Alice would be encapsulated in a membrane and a group member would see its membrane revoked when they are cast out of the group (which would transitively revoke all accesses gained through the membrane, cf. Analysing
Object-Capability
Security, by Toby Murray).

2 Likes
#6

Not necessarily. Since members of the group have that capability as well, they can just delegate this capability to the new member themselves.

This is also exactly how revocation in UCANs works: Any identity can revoke any delegated UCAN it created. Once a UCAN is revoked, this transitively revokes all UCANs delegated from the revoked UCAN.

But a group is an identity, even though it’s not an individual. And your example actually shows really well that group identity semantics are really complex: Who decides to cast out a group member? If there’s a single member that decides who is cast out of a group, then that member should just be the receiver of Alice’s capabilities initially, and then delegate capabilities to all other members of the group.
If it’s some sort of voting of m-of-n behavior, then that needs to be done differently and carefully thought through.

How would revocation work in this case? If reading a certain token/thing/message is the only thing needed for access to a capability, then there’s no way to revoke without revoking your own rights. Let’s say Mallory is part of the group and reads that message and is thus granted the capability. Mallory instantly forwards that message to their friend Bob. The group doesn’t know about that. At any point after reading this message, the group might want to cast out Mallory from the group, but they’ll have no way of revoking rights from Bob.

2 Likes
#7

Ha, the article said nothing on revokation, is there a documentation on it?

But that means that if it was Bob who delegated to Carol within the group, then casting out Bob will break Carol’s access. (not a huge deal but it is annoying)

Also, I’m pretty sure this transitive revocation isn’t what a membrane does.

If Alice delegates A1 to Bob in the group, and Bob delegates BA1 to Carol, and Carol invokes a method of BA1’s that produces its own UCAN, giving it its public key, she’ll get a UCAN A2 that has nothing about Bob or BA1 and Bob can’t revoke A2 when Carol is cast out of the group.

No, the membrane is another way.

Actually, if they revoke Bob’s membrane, Mallory will lose access and noone else.

That’s what a membrane does.

#8

What article?

We’re in a weird transitioning period where we’re extracting out a UCAN working group out of fission, so some things are hard to find. Fission’s whitepaper isn’t where the most recent spec lives anymore (and that version of the specification left a lot of holes, too). The new spec can be found here: https://github.com/ucan-wg/spec

Regarding membranes: I must be misunderstanding them. The slides didn’t really explain the mechanisms to me. I see it’s based on a thesis, but I’m not quite ready to read 200 pages, is there a more concise resource you could point me towards for an explanation of membranes?

1 Like
#9

I was referring to the article UCAN: Authorizing Users Without a Back End. Thanks for the link to the spec!

As for membranes, their basic code in E with the rationale is on figure 9.3 (p. 71) of Mark Miller’s thesis Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.

1 Like
#10

Oh yeah, in that case - you’re in for a ride! There have been quite a few additions & changes to UCANs since that article was published :grinning_face_with_smiling_eyes:

Oh Mark Miller rings a bell - @expede, who wrote the UCAN spec must be aware of his work - he’s cited in the Acknowledgements of the UCAN spec.

#11

UCAN is a decentralized auth system with an OCAP / capabilities approach. @expede designed it and we now have a UCAN working group where the spec is evolving https://github.com/ucan-wg.

The spec is evolving based on use cases in the wild and how things can be designed from a developer experience and user experience perspective, not to necessarily implement exactly how Miller’s work is described.

We’re generally in touch with a lot of those people and hope that UCAN can evolve and be implemented in a number of languages and apps and see what works.

#12

Thanks for digging in to this stuff :tada:

UCAN is actually SPKI, not full blown OCAP. The two are closely related (both capability-based), but SPKI is kind of like OCAP-lite. Some of the tradeoffs are that SPKI-based systems can work in presence of a network partition, but doesn’t have confinement (by default). We need the partition tolerant behaviour specifically, and thus you can’t always ask the originator (e.g. Alice) for permission subdelegate, can’t use delegate proxies, and so on, and thus do not have a full OCAP system.

As such, there does not need to be an interaction with Alice when a new member joins a group. That has tradeoffs, as cited above. These are tradeoffs that even Mark Miller has signaled “good enough” (or at least in the right direction) for in earlier SPKI systems, given the constraints of some distributed systems use cases.

And yes, we should go back to old posts and get tighter with the language. Our initial intention was to do OCAP, but it’s actually not a good fit for many of our use cases, but we do use capabilities more generally via SPKI. The article that you were reading is several years old, and we’ve made a BUNCH of changes and learned a lot since then.

1 Like
#13

Yes, I’m familiar with his work :+1: We even give him a shout out in the UCAN spec, and link to erights.org in several places

1 Like
#14

A couple pull quotes from the spec

Two related models that work extremely well in the above context are Simple Public Key Infrastructure (SPKI) and object capabilities (OCAP). Since offline operation and self-verifiability are two requirements, UCAN adopts an approach closely related to SPKI. UCANs follow the “capabilities as certificates” model, with extensions for revocation and stateful capabilities.

We want to especially recognize Mark Miller for his numerous contributions to the field of distributed auth, programming languages, and computer security writ large.

1 Like
#15

@kephasp I’d love to get your thoughts on the current spec if you have time. I need to highlight again that it is a SPKI system, not OCAP, so a lot of the active process stuff that you’re talking about above with the classic OCAP concepts with vats and membranes and whatnot will not apply as fully.

1 Like
#16

Very interesting topic. Looking at the example with the cinema ticket for simplification reasons:

As described the ticket(OCAP) does not prevent impersonation. In fact it’s not illegal to hand your ticket to a fellow unless it’s tied to an ID at time of purchase and checked by a guard at entry(ACL). So in essence OCAP and ACL are mutually exclusive based on identity.

Since UCAN is tied to identity it seems that it’s more of an ACL with stronger security and DID support rather than OCAP. Capabilities do exist in JWTs out of the box but the delegation logic is definitely something new and unique helping to avoid centralization.

Awake also seems relevant to the discussion:

  1. AWAKE - Fission Whitepaper

“Eve :woman_supervillain: has no incentive to delegate rights other than to hide from detection. However, in this scenario where she somehow already has a valid UCAN, the game was already over. There are remedies available (revocation & rotation) were that to happen. AWAKE aims to minimize this possibility from the outset (Alice :woman_technologist: would have to agree to granting Eve :woman_supervillain: these rights due to human error).”

Does this mean that we still need security practices similar to OAuth 2.0 to ensure revocation & rotation policies in place in the case of impersonation?

Who enforces those policies?

In the context of pubsub it seems that this has to be enforced on the pubsub level rather than by producers and consumers so that identities are matched before communication starts rather than dealing with each other. This does not contradict with decentralization it merely moves the responsibility from the participants to the messaging protocol/media.

The client-server model architecture has that clear set of responsibilities whereas in a completely decentralized environment this is probably going to be determined by either whoever would be more affected by the breach or if it’s a network-wide casualty it has to go a level deeper where the peer protocol(Fission or IPFS) needs to protect the network as a whole. In a way the core protocol becomes the new decentralized backend when it comes to security so to speak(not in the physical sense but in the responsibility context).

#17

UCAN is a variant of SPKI Capabilities As A Public Key Infrastructure

Per the spec (https://github.com/ucan-wg/spec/#0-abstract)

UCANs follow the “capabilities as certificates” model, with extensions for revocation and stateful capabilities.

1 Like
#18

Yes, the idea is to have a fuller protocol that can replace the traditional concept of a backend :+1:

You cannot impersonate someone without their private key, so it’s more self contained. It’s still possible — though much less likely than in an ACL system — to have a confused deputy, but only if the validator is unclear about who the root owner of a resource is.

UCAN is still very much a capability system. Pictorially, the arrows in the diagram point the opposite way from ACLs:

Screen Shot 2022-02-14 at 20.34.32
Screen Shot 2022-02-14 at 20.34.321744×882 156 KB

(https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf)

The above is “capabilities as columns” — SPKI doesn’t maintain a central list this way, but does illustrate the direction of pointers correctly

Any agent invoking the UCAN. It’s a bit like a state channel, but for auth. When some actually wants to use their authority, anyone can check that they have the right to do so based on the ownership if that resource. This is defined on a per-resource level, but e.g. in our file system it’s the public key associated to it in DNS (and soon right on the file system at a .well-known).

It’s enforced by the agents themselves. In AWAKE, we only bootstrap a secure session on top of UCAN to prevent PITM attacks; we’re not discharging any authority. Once that channel exists, you only know that they can delegate the desired capabilities (and thus “are equivalent to the root user in this context”) and that there’s no one in the middle, but you still need to validate anything that they send you. You don’t know who they are directly, since it can be even a throwaway DID.

1 Like
#19

Object-capabilities have been shown to be a strictly more expressive than ACLs. Any policy you can enforce with ACLs can be enforced with Ocaps, but not the other way around.

Not that this is only true for Ocaps, because some policies cannot be enforced without confinement, which isn’t present with capabilities like Waterken’s web-keys or any capability as certificate.

1 Like