3 Proposals: session ID, business-card auth, customer auth

In message <Pine.3.89.9507172026.C29440-0100000@eat.organic.com>, Brian Behlend
orf writes:
>
>I apologize if I'm making a ruckus on this issue - but it's something 
>we're heavily involved with as well, and I have to *constantly* 
>*constantly* deal with clients and prospective clients who have been told 
>be overeager marketers from other companies what can and can't be done in 
>this and other technical arenas.  I don't doubt that there is a large 
>market for a good analysis tool a la getstats or wwwstat or the other 
>free analysis tools out there.  But I am very wary of unfulfillable 
>claims which have been getting way too much press.  There are real 
>solutions to this coming down the pipe that will give marketers a better 
>idea of who's visiting them without having to guess or derive flaky 
>heuristics that work one day and not the next, while still strongly 
>protecting the user's right to privacy. 

Hmmm... care to give some details about these "ideas coming down
the pipe?" Here are my thoughts, after having surveyed this space
for a while:


******* I. The Request-ID: header field:

Each HTTP request should include a header field of the form:

	Request-ID: $session $request++
e.g.
	Request-ID: 342%33a4d443 12

that is, at the beginning of each session, the HTTP client chooses a
random number, and each request in that session is identified by a
number that increases monotincally with time. A "session" is not
formally defined (other than "a set of requests with the same $session
id"), though I suggest that browsers begin a session when they are
invoked, and allow some user interface to say "start a new session"
(i.e. "choose a new random session ID").

One might argue (in fact, one has argued: Hi Henrik!) that this is an
extension of the From: field, and these data belong there. I don't
believe so: if the From: field is present, it should contain a valid
email address of the requesting user (clearly the server cannot depend
on the authenticity of the From: field, but that doesn't mean we
should corrupt it further in the protocol spec).

Even though the session ID is random, there may be privacy concerns:
some folks leave their browser running for a long time, and this
mechanism might allow unwanted correlations to be observed. So perhaps
there should be a preference to turn this feature off.

But I believe it is cost effective: just like the junk-mail
advertisements in your Visa bill envelope help reduce the annual
fee on that Visa card, providing extra information in requests
will allow information providers to increase their quality of service
by more accurately modelling the usage of their information.

Some details: the $request is incremented for each HTTP request,
including inline images; it is not reset when requests go to a
different server or anything like that. On the other hand, HTTP
clients which are not traditional user agents (e.g. multi-threaded
robots) may in fact use several sessions in parallel.

A proxy must pass the Request-ID: header through unmodified. One might
consider some sort of Proxy-Request-ID, though I doubt it would be
valuable.

******* II. The business-card authentication scheme

I propose a new http authentication scheme; let's call it
"business-card". Its purpose is to facilitate access control policies
similar to "I'll show you my information if you'll leave your business
card in the bowl."

An HTTP server may respond to requests with a 403 response, and
specify the business-card scheme in the challenge, along with a list
of required, suggested, permitted, and refused fields.

The HTTP client should retry the request, supplying the specified
fields, at the discretion of the user, in the Authorization: header
field.

For example, at installation, an HTTP user agent may provide a dialog
where the user may enter information typically available on business
cards: name, address, business phone number, email address, PGP
key fingerprint. The dialog would also allow the user to specify
the sensitivity of the fields, for example:

	* give this out to anybody who requests it
	* when anybody requests this, present a yes/no dialog to me
	* give this out to anybody in *.mybusiness.com
	* give this out to anybody _but_ *.mycompetitor.com



ok... I've run out of time for doing this right now, but rather than
stuff it away somewhere, I'm going to go ahead and send it out for
discussion. The IIIrd proposal is basically the Netscape cookie idea,
except that it ought to be re-cast as an HTTP authentication
mechanism.

I haven't had time to discuss the privacy issues in detail, nor talk
about the required but hidden IVth proposal, which is that proxies and
caches relay certain log info to information providers.

But this should provide some food for thought.

Dan

Received on Tuesday, 18 July 1995 07:09:34 UTC