[cap-talk] delegatable-with-probable-cost capabilites

[ross mcginnis]

> Date: Mon, 28 Jan 2008 00:19:56 +0000
> From: david.hopwood at industrial-designers.co.uk
> To: cap-talk at mail.eros-os.org
> Subject: Re: [cap-talk] delegatable-with-probable-cost capabilites
>
> ross mcginnis wrote:
>> Hello all,
>>
>> I have been thinking about non-delegatable password capablilities in
.....
>> who delegates such a capability can potentially lose their bond.
>
> I would like to respond more constructively to your post, but I don't
> see any discussion of motivation (given that you don't claim it is
> workable as an anti-spam scheme, and do not present any other example).
>
> Delegation of authority is not undesirable -- quite the contrary.
> It's particularly desirable to support it between processes, but it's
> also desirable to support it between people. The only valuable
> enforced restrictions on delegation are those that arise from restricting
> communication channels (which incidentally, most non-capability
> systems do a really bad job of). 

For me this is the crux of the matter.  I disagree with you here because in reality the vast majority of exchanges that occur in people-people network (ie: society generally) happen on a network that is totally unrestricted with respect to its communication channels, ie: everybody is allow to say what they like, when they like to who they like- everybody has a communication channel to everybody else.  This is the norm -not the exception- in a 'civil' society .  It is only in rare extreme circumstances that exchange happens where the network nodes are confined and are forced to communicate over well defined and restricted communication channels: the nodes (people) are only ever confined at places like military institutions where they are physically located at remote isolated areas and can talk to other people only over dedicated communication channels.

> [...]
>> Please note: I'm not advocating non-delegatable or
>> delegatable-with-probable-cost capabilities for use with high-security
>> setups. They cannot prevent conspiring proxy attacks.
>
> Designers of security mechanisms don't determine what situations they
> will be used in. There is no dichotomy between "low-security" and
> "high-security" systems. 

For me there is a definite destinction between low and high securtiy in people-people networks: 
low security is normal everyday exchange that occurs over the normal undefined and non-restricted communication channels
high security is the rare exchange that occurs between confined people over fully defined and knowningly restricted communication channels

For access control in the low-security network we have basically two options: password cap and ACLs.  Society has chosen to use mainly password caps.  I agrue that there is a real benefit gained in many circumstances by being able to control a password cap's copying/delegation- 
Examples of Password Caps in everyday life: phone numbers, email addresses, movie tickets, bus tickets, car keys, house keys, night-culb reentry stamps, ISBN of a book (to retrieve it at a library), the serial no. of a car part (to order the part at a spare-parts shop), etc, etc, etc.  These can all be modelled as Password Caps due to the fact that: 1)They are all that the bearer is required to have to be able to access the service/object that they reference, 2)These caps are all exchanged over an totally unconfined network of people.
In all of these examples (except the last two) it is either required or would be beneficial in particular circumstances that they are not -copyable and/or delegatable-.
Examples of Access Control List: swanky member only clubs that control access with patron list, etc.
None of these examples can ever be re-modelled usefully by Object Caps because of the fact that the objects are not exchanged/accessed over confined networks.  In the networks that these objects are exchanged over everybody is connected to everybody else.  In this respect they are everyday low security systems.

To summarise my stance: 
- Non-confined (universally connected) network <-> everyday low security -> password caps (which in many cases gain utility by having controls placed on their copying/delegation) or ACLs.  
- Defined and confined network <-> high security -> object caps (which should always be delegatable) or maybe in a very, very few cases ACLs.


ross

(PS: Thanks for corresponding with me. I'm really enjoying this discussion :)   )
_________________________________________________________________
What are you waiting for? Join Lavalife FREE
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30288&_t=764581033&_r=email_taglines_Join_free_OCT07&_m=EXT