Re: Google Docs as capabilities as data

Domenico Rotondi wrote:


è  I agree that the credential sharing risk exists; in contexts like the ones we address with the Event Notification Service there are formal constraints (company policies) that come into play and reduce that risk (or at least have the guy sharing is credentials liable for infringing the company rules).

The general rule is to make the secure way to do something easier than the insecure way.  Blocking delegation does the opposite.


è  In other contexts a "plese don't delegate flag" could be more effective.

I believe that most policy violations are accidental.  A “please don’t delegate” flag is a big help in avoiding them.


è  Reagrding the revocation procedure we follow the check is not so "simple";

It can be.  I’ve used three approaches.


1.       The holder of a capability can revoke it, which we implement by having each object implement a revoke method.

2.       The delegation operation returns to the delegator a separate, delegatable revoke capability for the capability being delegated.

3.       In our Zebra Copy work, which is similar to yours, a valid revoke request is one signed by the same key used for the delegation.

None of these approaches needs a separate revocation service.


è  We implemented the Revocation Service has a distinct service for convenience (so to reduce the load on the PDP),

I don’t see that revocation puts much load on the PDP.  Revocation isn’t common in my experience.  It’s even less common if capabilities can time out.


è  but logically it can be considered as exposing a further API/service of the PDP.

That’s better than a generic revocation service, which is what I took your paper to be saying.

________________________
Alan Karp
Principal Scientist
Enterprise Services, Office of the CTO
Hewlett-Packard Company
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk