Can UCANs be revoked?

[bmann]

I was curious whether UCANs, being self-validating and decentralized, have the ability to be "revoked" before they programmatically become invalid (expired timestamp, etc)? Just thinking in the case a UCAN was accidentally issued with a valid timestamp for say the next 1_000_000 years and you didn't want that floating around.

I’m posting this on behalf of someone else. Feels like we should have a FAQ on the home page. And I’m looking for a high quality answer to this to kick it off!

[cdata]

Yes, they can be! There is a whole section on it in the spec: https://github.com/ucan-wg/spec#66-revocation

We also recently added revocation support to Noosphere that I think fits within the prescription of the spec. Although, I have this open issue to quibble with the spec text a little: #112

[matheus23]

This answer is great, I just want to add a little bit of extra info, specifically to this part of the question (wording is from the original Q on discord):

UCANs, being self-validating with no centralized authority

It's true that UCANs are self-validating and there doesn't exist a centralized authority. But each capability in a UCAN is meant to be "used" somewhere that a resource exists at some point. That could be different things, but one example is - lets say - a DNS record setting service that authorizes changes to DNS records via UCANs.
If a user wants to revoke a UCAN that they accidentally issued that grants DNS changing capabilities, then they know they need to tell that DNS service! So the user creates a revocation object as described in the UCAN spec.
In another example, if the UCAN contains a capability that allows anyone in a p2p system to use each other's resources, then you need to gossip the revocations in the p2p network.

[expede]

The other way to say this is: delegation is instant, revocation is eventually consistent. This is a fairly weak claim, so you can absolutely PUT a revocation directly to (e.g.) a server that controls a resource (email, DNS). You can also let messages gossip through a peer network. The advantage of this at the spec level is that you have the flexibility to make this determination for all cases, from local-first/highly distributed apps all the way to "single node" resources.

[gobengo]

https://eprint.iacr.org/2022/1362

https://github.com/decentralized-identity/revocation

[expede]

ALLOSAUR: Accumulator with Low-Latency Oblivious Sublinear Anonymous credential Updates with Revocations

Well that sounds the a useful primitive 👀

[expede]

cc @matheus23