[cap-talk] Opinions of oauth?
dmbarbour at gmail.com
Thu Jan 5 14:39:04 PST 2012
On Thu, Jan 5, 2012 at 1:37 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
> Membranes are possible when (1) a shared TCB exists,
I think you assert a stronger requirement here than is necessary.
Suppose a server has a method to associate a fresh name with one of the
server's existing resources, and the request may include a token to later
revoke that association. This would be sufficient for a revocation
membrane. One needs trust no more entities than without the feature.
> (3) the definitive graph is stored within a single membrane's domain.
Why would this be necessary?
> If continuing access to other (still authorized) datasets requires that
> they connect, we can delete their deauthorized objects at that time through
Yikes. This sounds like one of those computer insecurity features. It
doesn't actually provide security - the data is already shared. It only
punishes the innocent - the people who don't replicate data when they have
opportunity to do so. But it might make admins feel better about the
security of their system.
> 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.
A useful approach is to model the intermediate state - i.e. a state for
`preparing to sign the document`. I've spent some time sketching suitable
widgets for real-time and occasionally-offline CSCW, and it seems that
explicitly modeling expected intermediate states - and thereby allowing
collaborators to observe the intermediate states and adjust their behavior
accordingly - is essential to all of them.
> 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.
The problem becomes much easier if resilience is built into the protocols
and programming models. Clean recovery from failures at scale is a big
reason I favor eventless reactive systems and limit access to state via
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk