Sharing and revocation

Sharing has two layers:

1. Resource authorization decides who can see, sync, review, or manage a resource.
2. Cryptographic grants decide who can decrypt encrypted content.

Those layers are related, but not the same.

Organization roles and team roles

Viewport has separate role systems:

An organization admin may be only a team member inside a specific team. A team admin may be only an organization member. Team admin rights do not grant relay or billing admin rights.

For encrypted context, neither role automatically means decryption. Decryption requires a key grant.

Share with a team

When a vault is shared with a team, the control plane can authorize team members to discover or sync the resource according to the selected role. The encrypted content still needs grants for the epochs that should decrypt it.

In practice:

1. The resource ACL says the team can access the vault.
2. The trusted edge wraps vault key material to the active team epoch.
3. Team members materialize the team epoch through their own active user epochs and enrolled devices.
4. Adding a member queues a team epoch rotation. A trusted edge publishes the next team epoch, wraps it to each current member's active user epoch, and re-wraps vault grants to the new team epoch.
5. Removed members stop receiving future sync/access, but old local plaintext cannot be clawed back.

Revocation is soft

Revocation blocks future access. It does not rewrite history on already trusted devices.

This is the honest model for encrypted collaboration. Once a recipient had plaintext, the sender cannot prove it was forgotten. Viewport can stop future access, rotate future keys, write audit events, and require re-granting.

After a revoke, remaining recipients are not assumed to have the new key automatically. The owner trusted edge emits rotated grants, and each remaining recipient's trusted edge must pull and materialize the new epoch before the UI should show decrypt-ready access again.

For a device revoke, the user's epoch rotates. For a team member add or remove, the team's epoch rotates. That gives new members a fresh decrypt path and prevents a revoked device or removed member from unwrapping future grants. It does not erase plaintext already decrypted before the revoke.

Recovery after device loss

There are two normal recovery paths:

1. Another enrolled device exists. Use it to approve a replacement device, then revoke the lost device. The user epoch rotates and future grants target the new epoch.
2. No enrolled device exists. Use a recovery key backup, if you created one. The daemon fetches the encrypted backup, decrypts it locally with the recovery key, restores the user epoch, and immediately rotates to a fresh epoch.

Viewport cannot recover encrypted content for you without either an enrolled device or your recovery key. The platform stores only the encrypted backup envelope.

What org admins can and cannot do

Org admins can manage organization infrastructure. They can remove people, change relay settings, manage billing, and audit access.

Org admins do not automatically decrypt private or team-scoped encrypted context. If the org wants a break-glass policy, that should be an explicit grant and audit path, not a hidden privilege.

Recommended operating model

• Use teams for ongoing groups.
• Use share groups for short-lived or ad-hoc audiences.
• Keep vaults narrower than "everything the company knows."
• Rotate grants after sensitive membership changes.
• Treat rejected candidates as signal: too many rejected candidates means the repo prompt or workflow is too noisy.
• Document any break-glass decryption policy explicitly.