[Auth]<auth> tags, etc.

[Ron Burk]

You raise interesting points.

> I would suggest to add <auth> tags inside the <dotGNU> tags, because in the
> future, there will be more things we want to do than just authentication.
>
> <?xml version="1.0" ?>
> <dotGNU>
>   <auth>
>     <method>POST</method>
>     <url>https://www.hightechinfo.com/login.asp</url>
>     <AccountName>name</AccountName>
>     <Password>secret</Password>
>   </auth>
> </dotGNU>

But that's not the only use of even this limited standard,
so the next question is: is it better to try to also define
all the possible information usages, or simply use
a separate tag for all requests this standard supports?
For example, I may have an account with a web
site for quite a while before I actually buy something
and therefore encounter a request for credit card
information. The request for a credit card number
or for a shipping address is not authentication.
Should that request reside under a different tag and,
if so, what is it, other than a general request for
personal information?

How exactly will any software behave differently
based on the "type" of personal information request?
I wonder if they would be more likely to care to
differentiate based on the actual fields themselves,
rather than any classification of the overall request.
For example, I might like client software that lets
me say "always ask me before giving out my email
address", and having that constraint followed whether
the email address is being given for authentication
or for obtaining an e-newsletter, or permitting email
notification of a physical shipment.

> Furthermore, the location of the file which contains the requested
> information should not be hardcoded (/login.gnu). Instead, this should be a
> parameter in the <embed> tag or similar.

I'll try to make that clearer -- that's the nearly entire purpose of the
<embed> tag, to have an HTML way of specifying a reference
to another document (the src attribute of the tag has that definition).
The other reason for choosing the <embed> is that I think(?) it
makes it easier for client software to "hook" just those particular
pages (hoping to avoid having anyone actually write code to scan each and
every page that the web browser fetches for dotGNU references).
AFAIK, browser add-ins have opportunities to register themselves
to get invoked when a specific MIME type (or it's associated file
extension) is fetched, or appears in the src attribute of an <embed>
tag.

> For security reasons, the method must be POST, because with GET the password
> is visible in the address bar (I guess). Should we restrict the url to be
> always https://? Or at least the client software should warn the user every
> time that the transmission is insecure if http:// is used. Maybe this is a
> small barrier for websites, but it would make the internet more secure in the
> future.

Those are issues for the client software (which we,
fortunately, don't have to write), but I would not
forbid any HTTP method. Some systems use a GET,
and not supporting it simply means they will continue to
use it only without the convenience of supporting this standard.
Someone standing behind your shoulder generally has
multiple opportunities to steal passwords no matter what
is masked on the screen (or at least keyboard reading
was popular sport in the olden days when I went to college
and mainframe account resources were difficult to come
by).

One could argue that forbidding GETs at least greatly
reduces the opportunities for over-the-shoulder attacks.
But keep in mind that we're building a single logon system.
That means the attacker only has to read one password
off the keyboard to get all your passwords. Perhaps it's
better to push for users to learn that people can read what
you're typing (even if it's not displayed on the screen),
than to feel that eliminating GETs has appreciably
increased security. I believe that telephone credit cards
have had to go through this cycle of education already,
at least in travel hubs at major cities, where a pair of
binoculars used to provide thieves with a steady stream of
stolen long distance credit.

Ron Burk
HighTechInfo.com, www.hightechinfo.com