Re: Google Docs as capabilities as data

On 30 Jan 2014 at 2:14, Karp, Alan H wrote:
Hi Alan,
thanks for your comments.
My answers on line.
More details are in the paper.
Ciao
   Domenico

Domenico Rotondi wrote:
 
è within the EU FP7 IoT@Work project (http://www.iot-at-work.eu/) we used 
    capabilities to manage access to a publish/subscribe service tailored for shop 
    floor events collection and dispatching.
 
An interesting piece of work.  Thanks for telling us about it.  I’ve only skimmed your paper, 
but it clearly deserves a closer reading.  I do have a couple of comments on your email.
 
è Starting from this root capability, the administrator (using the stand alone 
    application) can generates new capability tokens for other subjects, he/she 
    trusts, granting all or part of his/her rights (including the right to further 
    delegate the 1+ of the granted rights).
 
Attempting to prevent re-delegation is both futile and counterproductive.  It is futile because 
people can and do share credentials.  It is counterproductive because when they share 
credentials, you lose accountability.  Further, you force them to give up all their permissions 
in order to share a few of them.  I am now proposing that the Do Not Delegate flag be treated 
as a warning to indicate “Please do not delegate.”   In an enterprise setting, the employee will 
be informed that continuing with the delegation would violate policy and be given the 
chance to provide a justification for management.

Our delegation system doesn't force a subject to delegate all his/her rights. When you 
create a new token based on the one you own you can select which of the rights hou 
have (and for which you are also allowed to delegate) you actually grant to the other 
subject. Therefore if, for example, I have both read and write rights for resource X 
and I have the delegate right only for the read operation I can only grant you the 
read right to you creating a new token (actually the schema file we use supports also 
a delegation depth attribute, but this attribute is not currently accessible via the UI of 
our tool).
Therefore we have a "can delegate" flag for each granted right. If you don't want a 
subject delegates received rights, simply don't set this flag in his/her capability token.
Regarding the sharing of credentials. We use X509 certificates and digital signatures 
to protect the tokens (and as a proof of ownership when submitting an access 
request). So users have to share their private keys if they want to share a capability.
We know this issue exists, but: first the owner of the X509 in any case remains 
accountable for his/her private key, and he/she's violating company policies (don't 
forget that the context of our system is to do access control to shop floor events in 
manufacturing).
 
è For the revocation we used a similar distributed approach by using what we 
    call revocation requests that are submitted to a specific revocation service
 
I don’t believe you need a separate revocation service.  Since the capability must be 
presented to the service when it is used, only the service itself or its PEP (Policy 
Enforcement Point for those unfamiliar with DoDese) needs to be told that the capability has 
been revoked.

We have a PDP (Policy Decision Point) and a PEP (which actually is the 
Authorization Service of the pub/sub system). So each request is first locally checked 
by the Authorization Service (e.g., if the capability token is acceptable, the request is 
compliant to the capability token, ...); then the Authorizaiton Server asks the PDP for 
further checks (currently only if the capability token is reported as revoked or not).
We designed the Revocation Service to manage revocation requests and, if the 
revocation has to be performed, report this to the PDP and to the subject that 
reuqested the revocation (this "report" could be deferred in time due the 
decentralised nature of our system; so the Revocaiton Serivce/PDP could not have all 
the info for immediately taking a decision if a capability token must be revoked or 
not).
________________________
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