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

Start with a simpler concept: revocable capability pattern.

http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Revocable_Capabilities

We can call this 'explicit' because we must explicitly call
'makeCapabilityRevokerPair', and we must explicitly track the revoker. If
we didn't have the foresight to do this, we're out of luck (unless we stop
our whole machine). We can call this 'stateful' because of how revocation
is modeled: changing mutable state on a reference.

The revocable capability pattern is easy to extend. For example, instead of
just 'revoke', we could introduce methods that allow us to install auditors
or switch the capability at a later time. Another extension to the
revocable capability pattern is the membrane pattern, which is essentially
a deeply recursive revocation pattern, which also touches any capabilities
one shares through the revoker:

http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Membranes

It is worth noting that, by nature of being deeply recursive, membrane
patterns are a lot more difficult to extend with auditing or other features
in a sensible way. Anyhow, that's an explicit, stateful membrane.

I do something very different here, which removes the need for explicit
revokers and membranes, and is also much more expressive for precise
auditing and so on. However, this is accomplished in part because I
abandoned "message passing" as a basis for communication, and switched to a
more streaming/dataflow model that implicitly maintains connectivity, like
a spreadsheet for the real world.



On Sat, Nov 2, 2013 at 2:08 AM, Rob Withers <[email protected]> wrote:

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

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