Hi Micah and John,

The password encrypting idea is the same type of thing I was getting at with the idea of sending the hash of the password rather than sending it clear text, though I think the hashing example is more likely to occur.

However, perhaps we could further consider whether the notion of 'password' is a data issue or a presentation issue.  Right now, it seems to me to be more of a presentation issue.  The 'data' transferred to the data model should be the hashed (or encrypted) version of the clear text.  Otherwise there would be a difference in data between that which I can access through the client-side DOM versus that which I receive on the server side.

Moreover, one would still have to translate a data type such as 'password' into presentation layer constraints (e.g. a password can only bind to a textbox (or input) if it has an echo attribute that hides the text).  It would be interesting to think about the accessibility constraints that would need to be effected (e.g. passwords can only bind to widgets that communicate to non-sighted users that they are now supposed to communicate a password).  Even if the data model knows about password, the presentation layer must also know.

Again, much more could be said (e.g. about the server side of handling password as string), but this seems to suffice for now.

John Boyer
Senior Product Architect, Software Development
Internet Commerce System (ICS) Team
PureEdge Solutions Inc.
Trusted Digital Relationships
v: 250-708-8047  f: 250-708-8010
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>    

-----Original Message-----
From: Micah Dubinko [mailto:MDubinko@cardiff.com]
Sent: Friday, March 23, 2001 4:32 PM
To: 'John J. Barton'; 'www-forms@w3.org'
Subject: RE: One more possible hole in UI?

Interesting. Our architecture would certainly support this.

Lexically, an xform:password datatype would be identical to xform:string,
right? I don't see encryption being part of XForms 1.0, but that would be on
target for a future version. And you are correct: a password (or any "secret
text") deserves to have special semantics, even if common usage today
doesn't allow that to be expressed.

I wonder if there are P3P implications to a 'password' datatype?


-----Original Message-----
From: John J. Barton [mailto:John_Barton@hpl.hp.com]
Sent: Friday, March 23, 2001 4:06 PM
To: XForms Mailing List
Subject: RE: One more possible hole in UI?

At the risk of clouding this discussion on passwords,
here is a different perspective.

The XFORMs goal is to separate presentation, logic,
and data.

Shouldn't the "data" representation for a password
different than "string"?  Yes I suppose a few million
passwords have been sent as "string" (clear text),
but at least we could contemplate encrypted text as
the default for a new world of XFORMs.  If XFORMs
has a special type for currency, wouldn't one for
passwords be ok?

If one had a datatype password, then various presentations
can fill such slots.  One presentation could be textbox.
The user agent would be obligated to apply "*" over
inputs to any textbox that solicits input for type "password".
Another presentation could be a table of buttons like
an ATM keyboard.


John J. Barton          email:  John_Barton@hpl.hp.com
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100