Yes- the thing you didn't mention is the distinction I'm making between Dropbox URLs/UUIDs/etc and fds/Fuchsia capabilities, which is that the former are bit patterns and the latter are pieces of state in a trusted kernel.
The attack surface of "bit pattern" capabilities is much larger than that of "trusted state" capabilities- even if you can't practically guess one, all you need to break it is to discover its bit pattern somehow. Trick someone into printing it out, read it out of their memory space, leak it via a side channel, attack their UUID generator, etc. For this kind of capability, sure- periodic revocation might be a worthwhile mitigation technique.
But for "trusted state" capabilities, which is where this thread started, and what file descriptors exemplify, this all goes away. The attack surface is reduced to the kernel and the component's own API (nothing new here) and its use of a finite set of capability delegation APIs. Leaking an fd number does not leak the corresponding capability the way leaking a Dropbox URL does, so there is relatively little purpose in rotating those out.
I wouldn't call it attack surface, I would call it a threat model. And yes, the threat model of capabilities includes the fact that knowledge of the capability connotes the capability. If it didn't, it wouldn't be a capability.
Then you've spent this entire thread arguing over clearly-explained terms of art, what a colossal waste of effort. I'm sorry to inform you: this is not how Fuchsia uses the word "capability."
Using your version of the word, since you appear incapable of operating in any other frame, Fuchsia does not use capabilities, and thus does not have the problem of leaking permissions via bit patterns. The original question of whether they need to be rotated periodically does not apply here.
There's really no debate here. I'm right. A capability is defined as I have defined it. You can say "well Fuschia says otherwise", that's fine, people are wrong about things all the time. Such is life.
Of course I've spent this entire thread explaining a clearly defined term, was that not obvious?
And yes, rotation is relevant to capabilities because leaking capabilities is a critical failure. It's not the only way to protect capabilities though, you can add ACLs or namespaces, which is what Fuschia seems to do.
The attack surface of "bit pattern" capabilities is much larger than that of "trusted state" capabilities- even if you can't practically guess one, all you need to break it is to discover its bit pattern somehow. Trick someone into printing it out, read it out of their memory space, leak it via a side channel, attack their UUID generator, etc. For this kind of capability, sure- periodic revocation might be a worthwhile mitigation technique.
But for "trusted state" capabilities, which is where this thread started, and what file descriptors exemplify, this all goes away. The attack surface is reduced to the kernel and the component's own API (nothing new here) and its use of a finite set of capability delegation APIs. Leaking an fd number does not leak the corresponding capability the way leaking a Dropbox URL does, so there is relatively little purpose in rotating those out.