Skip to content

rpc: Settle on strong/weak ID semantics and their implications for capability design

This stems from a discussion in !1200 (merged).

We can't define a sensible "drop" method for a weak ID, because the weak IDs for an object are automatically deduplicated. Thus, if you remove a weak ID for a given circuit, you're actually removing every weak ID for that circuit.

@Diziet has additional thoughts about the situation at !1200 (comment 2905558) .

Here are some alternatives; there may be more.

  • There are no weak IDs. (This would make some programs hard to write without making sure that the API user manually drops everything, and would make some APIs hard to provide. Probably not a good idea)
  • Weak IDs do not get deduplicated. (This would probably lead to OOM conditions if an API user does something that gets it a zillion weak IDs for the same object.)
  • You can't drop weak IDs. (This is the status quo, but it means that any capability represented by a weak ID is undroppable, unless you can trust yourself to "forget" the ID.)
  • Dropping a weak ID drops every weak ID for the same object. (This leads to nonlocal behavior issues, since IDs can get invalidated by parts of the API user that don't even have the ID.)
    • As above, but this is a different operation from the regular "drop". (This mitigates the nonlocality problem a little by making it hard to do by accident, but it does make weak-ID-dropping a risky proposition.)
  • Weak IDs are not capabilities. (This is potentially hard to design. If we assume "every ID is a capability", then writing a secure API is as simple as "don't give out an ID to something the user shouldn't have access to" and "Don't access anything without an ID." But if we say only strong IDs are a capability, it's not clear what weak IDs can even allow you to do; it seems like we might need additional access control in the objects that do have the strong IDs.)
  • Weak IDs exist within named tables. (@Diziet suggested this in the above-linked comment.)
  • Weak IDs are namespaced relative to strong IDs. (This may be the same as @Diziet's design above. It would imply that every weak ID is somehow seen as a facet of something that you have a strong ID for, such that dropping the strong ID will expire all the weak IDs.)