[8643] in www-talk@info.cern.ch
Re: 3 Proposals: session ID, business-card auth, customer auth
daemon@ATHENA.MIT.EDU (Roy Fielding)
Tue Jul 18 17:38:43 1995
To: "Daniel W. Connolly" <connolly@beach.w3.org>
Cc: Brian Behlendorf <brian@organic.com>, www-talk@w3.org
In-Reply-To: Your message of "Tue, 18 Jul 1995 07:09:26 EDT."
<199507181109.HAA25087@beach.w3.org>
Date: Tue, 18 Jul 1995 17:27:47 -0400
From: Roy Fielding <fielding@beach.w3.org>
Resent-From: www-talk@www10.w3.org
Here I thought I'd finally have a week to focus on my writing ...
>******* 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
A) Must be optional (it can indeed be used to identify individuals,
if the individuals are not sophisticated enough, or if the tracker
is persistant). Besides, all headers are optional in HTTP.
B) Should be shorter (optional marketing gunk has low priority)
C) Belongs as a comment in From:
>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).
Henrik and I talked about that as well. The From header can indeed
include this information in the form of a comment (keeping in mind
that it may already include a comment. Thus,
From: (#342%33a4d443 12)
is a perfectly valid header for HTTP/1.0, as is
From: "Roy T. Fielding" <fielding@beach.w3.org> (#342%33a4d443 12)
[Note I am using "(#" as the key.] This can be accomplished by a
simple agreement between the client developers, without any change
to the protocol.
>******* II. The business-card authentication scheme
I don't like this proposal, because it combines two orthogonal
concepts.
1) A way for users to keep a standard business-card stored in
the client, so they don't have to re-type it by hand.
2) authentication, which should never include unnecessary information
Defining a standard business-card format for browsers is a good idea.
However, I would implement it by also defining standard FORM input
names, such that when presenting an HTML form for the first time,
the browser could pre-fill the data fields for field names that
match its predefined business-card field names.
The user would then have complete control of the content, including
whether or not to press the submit button, and the information is
only transmitted once. The content provider can also make it optional,
only ask for specific standard names (like zipcode), or request
additional information within the same form.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
(fielding@w3.org) (fielding@ics.uci.edu)
