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?

.micah


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

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

Received on Friday, 23 March 2001 19:35:24 UTC