[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Auth]simple logon proposal feedback

From: Ron Burk
Subject: [Auth]simple logon proposal feedback
Date: Thu, 26 Jul 2001 11:22:05 -0700

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]