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

[Priscilla Chung]

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?

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?

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").

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060828/9236e384/attachment.html