Re: how to extend a capability on a data source?

What is a stateful, explicit membrane and what does one look & feel like?

thank you kindly,
rob

On Nov 1, 2013, at 9:33 AM, Mark S. Miller <[email protected]> wrote:

> Well, when you do. I've got a zillion questions, but they're not worth formulating until I can stare at an example ;).
> 
> 
> On Fri, Nov 1, 2013 at 7:12 AM, David Barbour <[email protected]> wrote:
> The implicit membrane doesn't look like a membrane. I suppose some Kerberos ticket-granting strategies might be a close analogy. Tickets expire, but in some cases can be renewed and replaced, with the expectation that users switch to the new ticket before the old one expires. In the same sense, distributed capabilities in an RDP system are periodically expired and replaced - with a little bit of overlap for smooth, latency-tolerant transitions.
> 
> Anyhow, I don't have time at the moment to build a proper example. Sorry.
> 
> 
> 
> On Fri, Nov 1, 2013 at 7:55 AM, Mark S. Miller <[email protected]> wrote:
> Hi David, what does this implicit membrane look like in your model? Could you post an example?
> 
> 
> On Fri, Nov 1, 2013 at 5:43 AM, David Barbour <[email protected]> wrote:
> I am developing a system where all capabilities grants are uniformly visible, revocable, auditable, attenuable. It is based on a reactive programming model: a capability must be continuously, declaratively granted. Conceptually, the old capability is continuously expired, and a new one continuously replaces it. Of course, I can't actually implement "continuous" revocation, but the implementation can approximate continuous revocation by replacing and expiring capabilities periodically or randomly or whenever changes are needed. 
> 
> A consequence is that capabilities in this model are not used as persistent values, and the risk of a temporary capability leak is mitigated. Explicit, stateful membranes don't seem to be necessary in this design, since the implicit membrane based on dataflow seems to cover all use-cases. However, user-defined security policies - i.e. the code that controls how the capabilities are distributed - can be persistent. 
> 
> Best,
> 
> Dave
> 
> On Fri, Nov 1, 2013 at 2:31 AM, William ML Leslie <[email protected]> wrote:
> On 1 November 2013 17:43, Rob Withers <[email protected]> wrote:
> > the widget isn’t as nearly important as the relationships one builds.
> 
> Well, that's an interesting point.  Has anyone got a service where
> users are creating their own membranes?  Have any of you attempted to
> store user-defined membranes in a relational database?  How is it
> done?
> 
> --
> William Leslie
> 
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely may reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to deny you those rights would be illegal without
> prior contractual agreement.
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> 
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk

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