[Auth]simple logon proposal feedback

[Ron Burk]

> The advantage of using an URI scheme is that websites
> do not need to define a new MIME type.

I couldn't quite follow how this would work in detail.
Can you give an example of exactly what modification
the web page designer has to make to an existing
logon page, and spell out how the client software
is going to be able to intercept that request in
IE or Netscape?

> 2. Instead of using the EMBED tag, one could use the
> SCRIPT and NOSCRIPT tags to activate the logon.

True, but I think that many more corporate policies
disable scripting than disable plugins (since the latter
prevents music, video and reading of PDF files),
so I think <embed> would work more universally.
The specific attributes offered by Albert seem to solve
my previous concerns about using <embed>.

> 3. In addition to supporting plain text password
> authentication (similar to the HTTP Basic
> Authentication) the logon scheme should also support
> the newer Digest-MD5 authentication, which uses a
> challenge-response protocol without having to transmit
> the plaintext password. The challenge information may
> need to be part of the x-dotgnu file, which means that
> it cannot be a static document.

Do Netscape and IE provide an defined mechanism for
plugin software to intercept and respond to HTTP
authentication challenges? This is a mechanism that,
in practice, would require implicitly accessing the
user's password for many pages at a given web
site rather than just at a single logon page, right?

> Perhaps we should name it "info retrival" instead of "auth".

Good idea, or simply use a root tag that is specific
to this standard, rather than "<dotgnu>".

> We should use every way to increase security. Education is the one that will
> last longest and is the most difficult.

It's a good point and you make the case well.I think,
as you've framed it, this is a policy decision rather
than a technical one. I can understand the motivation to try
to force increased security on users of the standard, but
my vote is still to let the market decide. If we succeed at
enlisting lots of vendors and web sites, then users will almost
certainly have choices that include very strict security,
including options like "don't transmit any information unless
if the web site is using a GET or not using HTTPS".
I will try to incorporate your point into the proposal
as an issue to be decided.

Ron Burk
HighTechInfo.com, www.hightechinfo.com