You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Creating a group.
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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 likeThe 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
tomember
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.
The text was updated successfully, but these errors were encountered: