delegation groups

[Gozala]

I just had conversation with @mikeal about how can we go about "group sharing" that is fairly common (especially in corporate settings). Capturing here the current thinking so we can turn it into a spec when we start actively working on this.

There are two pieces of the puzzle here:

1. Creating a group.
2. Adding members to the group.

We do not really need much around the first one, group can simply be a space (did:key) or an account (did:mailto) when human readable name is desired.

Adding a member to the group is simply a delegation like this:

{
  iss: group,
  aud: member.did(),
  att: [{ with: group.did(), can: "*" }]
}

Group membership could be temporary through exp in delegation and group owner can kick member out by revoking above delegation.

Changing group permissions is delegation / revocation of capabilities to the group.did() which forms delegation chains like

flowchart
   Photos("with: did:key:zPhotos<br/>can: store/add") -->  G1[/did:key:group\]
   Docs("with: did:key:zDocs<br/>can: store/list") --> G1[/did:key:group\]
   G1-.->G2
   G2[\did:key:group/] --with:* can: *--> A(["did:mailto:alice@web.mail"])
   G2[\did:key:group/] --with:* can: *--> B(["did:mailto:bob@gmail.com"])
   G2[\did:key:group/] --with:* can: *--> M(["did:mailto:mallory@icloud.com"])

The dotted line there indicates that delegation chain is split because delegating to the group and delegations to the members, because we don't want to reissue group to member delegations to thread new delegations every time group gets a new delegation.

Above is not currently possible with UCANs however adding such feature to UCAN@0.10 is been considered https://github.com/ucan-wg/spec/issues/130. If split chains proofs don't make it into UCANs we still can fall back to reissuing delegations to all group members which with web3-accounts spec should be a fairly convenient still.