Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delegation groups #23

Open
Gozala opened this issue Dec 7, 2022 · 0 comments
Open

delegation groups #23

Gozala opened this issue Dec 7, 2022 · 0 comments

Comments

@Gozala
Copy link
Collaborator

Gozala commented Dec 7, 2022

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:[email protected]"])
   G2[\did:key:group/] --with:* can: *--> B(["did:mailto:[email protected]"])
   G2[\did:key:group/] --with:* can: *--> M(["did:mailto:[email protected]"])
Loading

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 [email protected] is been considered ucan-wg/spec#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant