matheus23
commented
11 months ago Ideally one keeps the amount of capabilities per UCAN to a minimum: When delegating, you'd delegate multiple UCANs for separate capabilities. And when invoking a UCAN, you'd only collect them up in a single UCAN that refers to all the delegations in the prfs.
The reason we batch together capabilities in UCANs at all is mostly an optimization: We save space referring to DIDs and we only need to sign a thing "as a package" once.
If you didn't have to worry about these things, it'd have been nice to restrict UCANs to single capabilities. It makes attenuation verification logic somewhat easier, and makes the "best practice" of single-capability-per-ucan the only option.
Anyways, just chipping in with some of the things I remember from discussions in the past.
In theory multiple-capabilities-per-ucan allows you to make revocations "atomic". I.e. "revoke everything or revoke nothing", but I don't think that's a use case for anyone. Just noting.
Gozala
expede
When two UCANs get bundled into an amplification UCAN, its time bounds must be within the intersection of the bundled UCAN time bounds, as per the spec.
This accidentally attenuates time bounds, could we avoid it?
E.g., by allowing time bounds to be derived from the proof chain, preserving original time bounds of each bundled capability. The concept @Gozala introduced, being discussed here.
E.g., to have time bounds at the capability level, perhaps in Caveats.
E.g., to represent amplification as a collection of UCANs Pro: preserves granularity of capabilities, allowing to manage them separately, e.g., revoking only some. Con: these UCANs would need to be individually authorized. Something that attenuation as a bundled UCAN spares us from. Con: and individually revoked later on, if one wishes.