[cap-talk] (no subject)

[ross mcginnis]

Oops, I wrote in a previous email-
>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.

I'm surprise that no-one has picked up on my mistake here:  (I'll assume that no-one is reading my posts any more- which is good cause now I know I can ramble on without upsetting anyone :) ) -
I've said stated that there is benefit gained in being able to prevent copying of a password cap.  This is not the case.  We may use revocation instead of non-copy.  eg: In the case of a movie ticket cap- the only requirement is that it be used atmost once.  ie- the movie theatre owner doesn't care who enters the theatre, they only require that never more people than the number of tickets sold enter the theatre.  This requirement can be achieved by producing a unique ticket for each seat sold.  Once the ticket is presented to the usher guarding the theatre entrance it is revoked. Thus the cap is used atmost once.  The ticket may be copied by the ticket holder as many times as they like, they may distribute the copies to who ever they like.

There is still benefit gained in being able to prevent transfer/delegation of a password cap.

Flushing out all of the possible scenarios- 4 possible oject access cases using passwords caps:
1) don't care who uses it,  don't care how many times used : the password cap by itself perfectly fulfills this. eg: part number of a car-part, ISBN, etc.
2) don't care who, do care how many times used : cap + revoke mechanism perfectly fulfills this. eg: movie ticket, bus tickets, night-club reentry stamp
3) do care who, don't care how many times used : delegatable-with-probable-cost-cap fulfills with high confidence- can fail due to cooperative conspriacy or people not enticed enough to collect the bond. eg: lifelong-member-only clubs, spamless email addresses, etc.
4) do care who, do care how many times used : delegatable-with-probable-cost-cap + revoke fulfills with high confidence.  eg: a special trial offer to a members only club.
If these cap-use cases haven't already been named (I suspect they have years ago) I suggest that they could be called: 1)reference (or visible-reference to empahise that they are password caps to distinishguish them from object-caps which are always opaque), 2)ticket, 3)key and 4)limited use key.

Comparing the above cap cases with indentity based control- 4 possible access cases for using indentity based control:
1) access control requirement is fulfilled by not have any control present, but have lost the utility gained by being able to reference (name) the object.  Can only pass the actual object. eg: to buy a new car-part have to physically take the old part in to the shop. eg: book libraries are basically impossible to implement because you need to already have a copy of the book before you can retrieve another copy.
2) is perfect from the perspective of the controlor but does prevent transfer-of-access which is a utility that the some controlees may desire: eg. while the theatre-owner is satified that never more people than the number of seat sold watch the movie, a moive goer cannot buy and then transfer the access right to a friend as a present.
3) is perfect
4) is perfect


PS: by-way-the I think I should have pointed explicitly pointed out in previous emails, that in what I call a low-security network (ie: one where the network links mean that anyone may talk to anyone, or the network is not fully-defined/known) it is still possible to have a private conversation.  eg: in people-people who can talk in a whisper, in computer network you can communicate with encryption. 

_________________________________________________________________
New music from the Rogue Traders - listen now!
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=832&referral=hotmailtaglineOct07&URL=http://music.ninemsn.com.au/roguetraders