Amplification accidentally attenuates time bounds

[andrewzhurov]

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.

The time bounds MUST also be equal to or contained inside the time bounds of the proof's time bounds.

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.

[matheus23]

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]

Not taking sides here, but I do want to point out that we found a way in UCAN invocation spec to authorize multiple invocations using single cryptographic signature by signing set of CIDs been authorized. That is to say in theory we could do something similar with UCANs and authorize multiple delegations with one signature. That said it will still incur overhead of iss and aud field, which we can also pull into auth field, but then if we try to optimize exp away as well we kind of end up back where we started 🤷‍♂️

It is also worth mentioning that we have been discussing idea around dropping prf fields in #130 which would allow principal to provide a bag of UCANs and let the validator find a valid path, which allow forwarding capabilities without having to recreate delegation chains.

[expede]

Responded here: ucan-wg/invocation#21 (comment)

As Irakli cited above, amplification has been removed from Delegation since we can now express those cases in Invocations