Long-lived UCANs for asynchronous state verification

[cdata]

Re-posting this question from Zoom since we didn't have time to discuss it:

Long-lived UCANs are kind of an enigma for me.

On the one hand, I want to use a UCAN chain as a "proof" that some change of state I'm reviewing in IPLD is valid at the time it was made. For example, some new revision to state is signed by the author, and the proof chain is encoded in the data structure alongside the signature. I want a reader to be able to come along at any time in the future and verify that the author of the revision was authorized to make it.

On the other hand, I can't have an infinitely live UCAN, so such a proof chain will eventually expire. Also, long-lived UCANs seem like they should be avoided in the "service invocation" case. And, this doesn't even touch on the complexity implied by revocations.

Does anyone here deal with this duality, and how do you think about it? Are UCANs the right tool for this?

[cdata]

I want to call out that @expede gave a nice explanation of "anchoring," which at least speaks to part of my uncertainty: #95 (reply in thread)

[matheus23]

Technically it would be possible to anchor UCAN hashes on a blockchain. That way you'd have a decentralized way of verifying some piece of information existed at some point in time, assuming whatever runs the blockchain doesn't get compromised. (EDIT: My view of this discussion was stale, this is exactly the anchoring linked to from the other comment!)

Does anyone here deal with this duality, and how do you think about it? Are UCANs the right tool for this?

Yeah. Fission is thinking about this for WNFS as well: wnfs-wg/spec#7 (see specifically the 1st point in the second list).

The vague picture we have in mind for WNFS is this: WNFS likely gets updated often enough, if you tack on the UCAN used to change the file system onto it, it'll likely get replaced with another UCAN that's valid before the current one expires. Keep in mind that a UCAN with "equal or more" rights can essentially "attest" the validity of another UCAN for its own lifetime. The reasoning being "either you attest that the other UCAN was valid at that point of time, or if you really wanted to, you could do the change yourself, since you have equal or more rights".

[expede]

On the other hand, I can't have an infinitely live UCAN

You can have a "practically infinitely lived" UCAN (e.g. set the expiration to 1000 years). The requirement on the exp field is there to make sure that if you set it to 1000 years, you need to actually explicitly write that large number.

long-lived UCANs seem like they should be avoided in the "service invocation" case.

You 100% have the right intuition here around the principle of least authority (POLA). In general, you should delegate the least capabilities that it needs, for as short a time as possible. Sometimes that's 10s, sometimes it 1000 years.

You're right that for "service invocation", the UCAN will usually be pretty short-lived. There's definitely use cases for longer-lived credentials, such as cron jobs. We plan to develop a separate invocation wrapper that is one-time-use separating "here's a capability" from "please do this once or on a schedule".

Does anyone here deal with this duality, and how do you think about it? Are UCANs the right tool for this?

On the duality itself: they're intentionally flexible. Between your devices, you probably do want to make a long-lived credential — this is generally considered safer than moving the secret key around, because 1. the key can't be intercepted on the wire, and 2. you can revoke the second device if needed (and I suppose: 3. it's a consistent API across all use cases).

All auth systems (ACLs, SPKI, OCap) have a core tradeoff of how to revoke a credential after it has been issues. Revocation is a requirement for all of them; the difference is in the mechanism (of course they have differences along many axes). in the case of UCAN this is "revoke before expiry". UCAN has a fairly "weak" system of revocation: eventual consistency, and we expect that most systems will adopt a gossip mechanism. This makes it work well under network partition, while giving the freedom to further strengthen the revocation list by (e.g.) forcing it into a central list for some resource.

[cdata]

Thank you for those clarifications and insights @expede

I also noted after reviewing the delta between 0.8.1 and 0.9.0 spec revisions that exp is now explicitly allowed to be null for the case of an infinitely long-lived UCAN: https://github.com/ucan-wg/spec/blob/main/README.md#:~:text=If%20the%20token%20explicitly%20never%20expires%2C%20the%20exp%20field%20MUST%20be%20set%20to%20null.%20If%20the%20time%20is%20in%20the%20past%20at%20validation%20time%2C%20the%20token%20MUST%20be%20treated%20as%20expired%20and%20invalid.

For my purposes that's a suitable allowance to enable me to feel like I'm not holding it completely wrong 😅

[matheus23]

I also noted after reviewing the delta between 0.8.1 and 0.9.0 spec revisions that exp is now explicitly allowed to be null for the case of an infinitely long-lived UCAN

I'm pretty sure that's an error in the spec! The "Not before" timestamp should be optional, not the "Expiration".
I'll create an issue

[matheus23]

Oh no I'm wrong 😛
I missed the last column "Required".
Okay, yeah the expiration field is required, but may be null. All is fine. Ignore me :D