[Dev] RE: [Design] Feature Request: passwords and forms

[Bruce Dykes]

--- Curt Hibbs <curt@hibbs.com> wrote:

> Bruce Dykes wrote:

> > If Chandler is going to be doing secure email and
> file
> > transfers, a full featured PKI keyring will be a
> must,
> > and you may as well throw a password manager into
> > that, too.

> > by providing a public API to the password manager,
> > somebody can write a Mozilla plugin to take
> advantage
> > of it, or sync conduit to password app on a pda.
> 
> This is en excellent idea!
> 
> With Chandler angling to be the user's information
> repository of choice,
> managing all of those pesky passwords is a natural
> fit. Other features of
> password management (built-in or added by third
> parties) could include such
> features as (semi)automated pasting of
> username/password into authentication
> forms and automated generation of random, secure
> passwords.

I'm copying this to the Dev list as there'll be some
drift into that territory...

To start with, Chandler will need some basic password
management to begin with, at the very least for
holding on to private keys, pop3 passwords, and access
passwords for various other services, so it's not
unreasonable to extend that out to a general purpose
password storage, retrieval, and display module, aka a
user password manager.

At it's most basic, a password manager need be nothing
more than a resource name (ie company.mail.server),
resource type  (pop3 server), and two data fields,
userid and password, and perhaps a flag for public API
exposure, if implemented.

An API exposure would be a good thing, as it would
allow third party apps, such as Mozilla and IE
plugins, and Chandler aware clients such as telnet
clients to be able to pass a resource name, and
collect a userid and password for a given resource.

Of course due attention must be paid to security.

To extend this another step out, it probably makes
sense to build that function as a subset of a general
forms manager api, that can supply address and phone
number info to apps that request it. 

Of course, Chandler should inform the user of these
access attempts, and request some sort of vetting by
the user to allow the data transfer to proceed.

Now to extend this function even further, I'm thinking
it would be a good idea for Chandler to provide a SOAP
compliant wallet or passport, or whatever the Liberty
Alliance has specced out for a personal information
data source. 

I haven't been following them close enough to know if
their spec is mature enough to include in 1.0 Chandler
release, or if it should just be a beta feature until
2.0, or whatever. It's just yet another thing to think
about adding to Chandler.

Bruce

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2