[cap-talk] Opinions of oauth?
Jonathan S. Shapiro
shap at eros-os.org
Thu Jan 5 13:37:51 PST 2012
On Thu, Jan 5, 2012 at 12:24 PM, <ihab.awad at gmail.com> wrote:
> On Thu, Jan 5, 2012 at 12:14 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
>> But none of this appears to address the requirement that is introduced by
>> users entering and leaving collaborations: the ability to revoke one user's
>> future access to a shared pool of objects without (a) revoking the access
>> of other users, or (b) damaging the internal fabric of the object graph.
>> Problem (a) can be solved by issuing distinct capabilities to each user,
>> but that seems awfully complex. Problem (b) requires that we do *not* issue
>> distinct capabilities on a per-user basis, lest intra-graph capabilities
>> are stored by one user that cannot be wielded by a second.
> In my experience, we have generally proposed that problem (a) be solved by
> the extensive use of membranes. I'm curious about the complexities you see
> with that scenario.
Membranes are possible when (1) a shared TCB exists, (2) full knowledge of
object semantics (necessary to support cap exchange for graph storage) is
feasible, and (3) the definitive graph is stored within a single membrane's
domain. In a system build on synchronization, including the one I am
contemplating conditions [1,3] do not hold.
The good news, in the case I'm concerned about, is that the
container:object relationships are 1:N. At the moment there appear to be no
inter-object capabilities. Given that a revoked user may hold a local
disconnected copy of the dataset, we can't prevent continuing access in
any case. What we *can* prevent is further updates to their dataset. If
continuing access to other (still authorized) datasets requires that they
connect, we can delete their deauthorized objects at that time through
The case that's actually more interesting concerns workflow. Suppose we
have a form with a chain of signatures. Once the form is signed by the
manager, we don't want further edits by the original user to be allowed,
but they should continue to be able to do status checks (by reading) the
form. The interesting problems here are:
- Due to synchronization delays, the fact of signing may not be
observable yet at your local store.
- No trustworthy TCB exists at your local store.
One could appeal to copy-on-update designs, but there are other form
scenarios for which that isn't acceptable.
The saving grace in all this is that the synchronization relationships are
hierarchical, and we *can* rely on the upstream dataset to implement TCB
requirements. Propagation of effects may be delayed, but that is (in
practice) a manageable problem.
As for other manifestations of (b) -- where a user truly crosses domains of
> management and provisions objects with authority that is later found to be
> ephemeral and breaks the system -- is that not an endemic risk in any
If the user *intends* to do this, screw 'em and they get what they deserve.
The issue here is that it's very hard for a *well-intentioned* user to *
avoid* doing this, and the computational and storage overhead imposed to
achieve the simple outcome are prohibitive at scale due to the sizes of the
C-list exchange tables involved.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk