Group delegation
Alan Karp
Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member. This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.
In an “object reference as capability” (ocap) system, you’d use a sealed box. Put the capability you want to delegate in the box and send the box. You can define group membership as those parties that have the corresponding unsealer.
You might want to have a separately auditable capability for each group member. If you know the members ahead of time, you can just send a bunch of sealed boxes, either separately or in a box sealed with the group’s unsealer. Things are more complicated if you don’t know the group membership ahead of time. In that case, you can seal a capability in the group box that the recipient can invoke to ask for a capability to a caretaker for the target object. Bearer tokens can be used the same way by substituting encryption/decryption for sealing and unsealing.
There’s a rather direct translation to certificate capabilities. In the first example, you can create a delegation certificate to the group’s public key and give all group members the corresponding secret key. Similarly, you can issue a separate certificate for each of the group members or issue one certificate to a list of public keys, one per group member.
You also have options when you don’t know the group membership at the time you create the delegation certificate. One approach that works like rights amplification (I prefer the term rights combination, but nobody else does.) is that any use of the delegation must be signed by a secret key proving group measurement instead of the secret key corresponding to the one the certificate is issued to.
Alan Karp