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

[Mimi Yin]

Since Sheila sent out this email, we've slightly altered the design  
proposal. Instead of using the ticket as a password, we've decided to  
give the user an option to add password-protection.

Proposed workflows

Option 1: No password protection (Same as Today)
+ Publish collection
+ Copy URLs to clipboard (Read-only and Read-Write tickets)
+ Send tickets to sharees in some out-of-band way (email, IM)
+ Sharees click on ticket to access share in Cosmo UI

Option 2: Add password protection
+ Publish collection
+ Check option to 'Add password protection'
+ Type a password into a field
+ Confirm password
+ Copy URLs (tickets) and password to clipboard
+ Send tickets + password to sharees in some out-of-band way (email, IM)
+ Sharees click on tickets to access share in Cosmo UI
+ Sharees must type in the password in order to view / edit the share  
(depending on the ticket)

Our rationale: From an implementation standpoint, it is redundant to  
require both a ticket and a password, we decided on this proposal for  
the following reasons:
+ We want the password to be optional
+ However, we don't want users to pass around plain English  URLs  
that would be dead simple for everyone to hack (e.g. osaf.us/bcm/work)
+ Machine-generated tickets are better used as a URL, something the  
user clicks on
+ On the other hand, passwords will be more user-friendly if they are  
user-defined (more likely to be something the sharee can remember, at  
least remember for long enough to type it into a password field to  
access the Cosmo UI.)

We brought this up last week at the Cosmo Sprint and there seemed to  
be some concern about the proposal. I am throwing this on the list  
now to invite more discussion.

On Jul 28, 2006, at 1:43 PM, Sheila Mooney wrote:

> + WHERE WE ARE NOW & NEXT ACTIONS:
>
> 	+ There seems to be general agreement that we need some security  
> model/privileges in order to accommodate all potential users in the  
> long-term.
> 	+ We need to be able to support additional security as a choice  
> but not a requirement for all users.
> 	+ There is acknowledgment that going with forced security or none  
> in the short-term will be a barrier for some people.
> 	+ There is some suggestion that tickets are not appropriate for  
> the long-term.
> 	+ We don't yet know the cost of any of the proposals that were  
> presented.
> 	+ Spelling out the target user group and their needs in more  
> detail will help us figure out the right solution for the short- 
> term and the long-term.
> 	+ There are definitely some options in the short-term (Beta), that  
> would meet the design requirements and enhance the security for users.
> 	+ The design and dev teams will continue to explore the optimal  
> solution to put in place for 1.0.
> 	+ The design team would also like to do a LAST CALL on the idea of  
> using the tickets as a password as a proposal for Beta.
>
>
>
>
>
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/20060821/558e5ee4/attachment.html