[cap-talk] Opinions of oauth?

[David Barbour]

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
> synchronization.
>

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
>> system?
>>
>
> 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
capabilities.

Regards,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20120105/bc6ef904/attachment.html