[Design] [Cosmo] [Proposal] Anonymous login with Ticket + Password

[Sheila Mooney]

On Aug 28, 2006, at 10:23 AM, Priscilla Chung wrote:

> On Aug 21, 2006, at 4:46 PM, Brian Moseley wrote:
>
>>  i don't have any problem with
>> that as long as we also provide (eventually) for people who want
>> better security (eg acl).
> +1
> I realize there is huge amount of development work to add ACLS  
> before beta. I guess what I'm unclear about is how much ACL work is  
> really needed for post beta and has anyone investigated how to  
> phase this in?

I think figuring this out needs to be part of the planning work for  
Cosmo. As we mentioned during the sprint, we are planning Cosmo  
beyond Beta so this is something we will discuss. Step #1 starts  
tomorrow during our design session where we will be reviewing in  
detail the items on BCM's dev wish list.

>
> After having a better understanding of the mission and goals for  
> the beta release, adding a password doesn't necessarily solve any  
> additional issues. In fact, it adds development time (though it may  
> be minimal it still adds some development time) and adds complexity  
> and inconvenience to the user. For example, what happens when the  
> users forgets their password? This happens frequently. How will  
> they retrieve new one? Does the 'Sharee' have to keep pestering the  
> 'Sharer' for the password if they keep losing the password?

As far as I understand the "sharee" would only need the password to  
actually subscribe to the collection. Once they have done that, they  
don't need it anymore so I think it's unlikely that they would have  
to keep pestering the sharer for it, unless they keep having to setup  
their shares again (but we will have that restore settings and shares  
feature). The "sharer" would get the password from the manage share  
dialog or something like that if they forget it.

>
> If the longer term is to add in ACLs why not try to find a solution  
> that brings us closer to the end goal? If the first option is a  
> 'trust' model and that is part of the mission and goal of OSAF then  
> my vote would just go to option 1.
>
> If I could interject with another option which I'll name the  
> 'accountability' option, it might work a little like this:
>
> + When a user wishes to publish a calendar they may require anyone  
> who uses the calendar to sign up for a Cosmo account. This becomes  
> a property of the calendar, independent of the tickets.
> + Tickets work pretty much the same as they do in the current  
> 'trust' model with a notable exception
> + Upon clicking on a ticket to see a calendar, the user is  
> presented with a dialog that says the calendar requires the user to  
> sign up for a Cosmo account (i.e "this is a secure calendar, you  
> will need an account to view").

I am not convinced this solution is on the path to ACLs anymore than  
the password one. When we have ACLs sharers will have to obtain  
specific usernames for people they want to give access to. I will  
know that it's Mimi editing my calendar because she gave me the  
account name "hamstar".  I wouldn't be specifying that any random  
person with an account could access the share. I enter people  
individually and give them a particular privilege level.  I would  
argue that there really isn't much accountability in the scenario you  
describe. Sure, we could probably turn off the account etc if we see  
that someone is modifying a calendar maliciously, but simply having a  
username and password on the server doesn't truly identify someone. I  
just setup an account on Cosmo, username=cooluser, full name = Cool  
User and some bogus email. I get a hold of your read write ticket and  
edit away. How do you know it's me or anyone else you trust to make  
changes to the calendar.

>
> Reasons for this option --Pros
> + It's still keeps the original goal of the 'trust' community.
> + It introduces a notion of accountability when a calendar creator  
> wants it
> + Users will create accounts because a sharer wants accountability,  
> not because of a demand of the software.
> + This is a step in the ACL direction where users would be  
> accountable and potentially need permission
> + The 'Sharee' would not have to store their collections in their e- 
> mail - the account is a good way to access all of your  
> subscriptions without having to keep all of the sharing tickets you  
> received.
>
> --Cons
> + You're not actually password protecting anything (yet), you're  
> just setting the stage for it.
>
> -Priscilla
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060828/516c476a/attachment.htm