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

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