[Cosmo-dev] Sharing format questions
morgen at osafoundation.org
Tue Jul 25 14:27:34 PDT 2006
On Jul 25, 2006, at 2:02 PM, Bobby Rullo wrote:
>> Depending on how you look at it, tags are equivalent to collections.
>> I was thinking about how to deal with items, collections/tags and
>> ACLs this morning, and I am starting to like this approach:
>> - On Cosmo, Items are in a soup, identified by UUID.
>> - We define the term "Principal" which represents a Ticket, an
>> Account, or a Group (where a Group can contain Accounts or other
>> - There are two types of Permissions: Read-only and Read-write
>> - An "Access Control Entry" (ACE) indicates a certain Principal
>> has a given Permission for a given Item
>> - An "Access Control List" (ACL) is a list of ACEs
>> - There are special items called Tags which contain an ACL
>> - The Principal who originally PUTs an item to Cosmo is the
>> "owner" and always has full permission to that item regardless of
>> - An Item may be "tagged" (associated with existing Tag items) or
>> - A Principal's access to an Item is determined by iterating all
>> the Tags associated with that Item and examining the ACEs to see
>> if any match that Principal; the most lenient permission wins
>> (Read-write trumps Read-only)
> What if I have a specific tagged resource that I want to protect?
> In other words using your semantics I don't see how it would be
> possible to say "All 'home' collection items are read/write, except
> for XXXX, which should be read-only"
> Not sure if it's an important use case, I'm just sayin'.
Yeah, I guess that's an argument for allowing an ACL directly on an
item, and having that override ACLs from Tags.
>> - A Principal which has Read-only permission to an item may not
>> alter it in any way (including tagging/untagging); this solves the
>> problem of someone getting a hold of an item Read-only and then
>> moving to a collection they have Read-write access to and suddenly
>> being able to modify that item.
> I think user's should be able to modify read-only items somehow, so
> that changes appear only on their local machine and on their
> account (Scooby needs to see this stuff too)
> Once use case for this is alarms - I subscribe to a read-only
> schedule, and I want to set an alarm to remind me to go to a
> particular event. I can't though, cuz it's read-only. iCal actually
> has this problem, and it's annoyed me several times in the past.
Ok, that's a good requirement to make sure we handle. We'll need to
figure out where to store such "annotations" outside of the item's
> Also, people should be able to somehow move read-only stuff into
> other collections - I should be able to copy stuff from an Office
> Address-book into my own address-book for instance. Maybe this
> means that the item is copied instead of moved, giving it a new
> UID, with some meta-data that points to the original object.
If you are placing a read-only item into another collection and you
plan on modifying the item in ways that are not just personal
annotations, then perhaps a copy with new UUID is the way to go.
>> - A Principal which has Read-write permission to an item may
>> modify or delete it; they may also tag or untag the item using any
>> Tag that the Principal has Read-write access to. Therefore if a
>> Principal only has Read-only access to a Tag, they may not
>> associate that Tag with any items even if they have Read-write
>> access to those items. In other words, just because I have write
>> access to an Item doesn't mean I can add it to any Tag I want -- I
>> must have been granted Read-write permission for that Tag also.
> Right, you shouldn't be able to pollute other people's collections.
>> There are some details to work out, for sure. Such as:
>> - Who can modify the ACL of a Tag? Any Principal which has a Read-
>> write ACE in that ACL?
>> - Should Tags be hierarchical?
> Would be nice. I would hate to give up the hierarchies I have in iCal.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev