[cap-talk] Opinions of oauth?

Jonathan S. Shapiro shap at eros-os.org
Thu Jan 5 15:15:17 PST 2012

I need to leave in a moment, so responding quickly...

On Thu, Jan 5, 2012 at 2:39 PM, David Barbour <dmbarbour at gmail.com> wrote:

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

I don't agree. The problem lies in the fact that a membrane which does a
capability exchange protocol must be trusted to manage both sets of

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

Offhand, that seems to provide unidirectional trust, but not bidirectional.

>> (3) the definitive graph is stored within a single membrane's domain.
> Why would this be necessary?

Because the other membranes run on machines that provide no TCB. But it is
true that we need not require a *single* definitive graph. The requirement
is that all definitive copies reside within commonly trusted TCBs.

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

Nonsense. There is no confusion here about the fact that the data has been
shared. But there are several realities:

   1. A departing employee will surrender their machine
   2. A transferring employee will need to reconnect as a function of
   performing their job.
   3. Regardless of any security implications, there are legal obligations
   in restricting access to certain information that the company must in good
   faith attempt to comply with.

There are more issues in the universe than security issues! As I have said
repeatedly, some of this is about legal compliance expectations.

It only punishes the innocent... - the people who don't replicate data when
> they have opportunity to do so.

I'm not clear how they are punished. They can choose not to replicate in
either case, and be the proud holders of equally out-of-date results.

> But it might make admins feel better about the security of their system.

Sadly so. But hopefully not the smart ones.

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

Complicated solution to a simple problem.

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

More information about the cap-talk mailing list