- From: James G Smith <JGSmith@tamu.edu>
- Date: 2000年8月02日 09:34:07 -0500
- To: http-wg@cuckoo.hpl.hp.com
- Cc: JGSmith@tamu.edu
- Message-Id: <200008021434.JAA24654@hex.tamu.edu>
I think I recall some mention that security related issues were not being dealt with by this group, but then I saw the RFC for Basic and Digest Access Authentication among this groups RFCs... If this has been answered already, then a gentle reminder of where I need to look will be sufficient :P +--- | | I would like to propose an extension to the HTTP standard to include yet another authentication scheme. This would allow for clients to use a third-party URL (third party being not the client and not the site requiring authentication) to generate the authentication credentials. This would allow for one site to know who someone is without having access to the information which would prove their identity. This requires that the site requiring authentication trust the site issuing the credentials. This allows for a central authority to issue credentials without untrusted sites having sufficient information to reproduce those credentials. This can be important when the identity of the untrusted sites may be unknown, or when the information used to authenticate to the central authority may be legally protected. This scheme also solves the problem with POST requests and other requests with a body when trying to implement this scheme with the current standards (cookies and redirects) and with finite credential lifetimes. With the client unaware of the overall process, the user experience is severly affected. I believe this can be done within the present framework outlined in RFC 2617. The auth-scheme would be "ticket" or "third-party" or some other sensical tag. The auth-param would be `realm' as presently defined. Any parameters required by the site issuing the credentials would be included in the URL for that site (see next paragraph). In addition to the challange, a location header would need to be sent so the client knows where to go to obtain the credentials. The client would need to not retry the request requiring the credentials until it has obtained those credentials from following the actions at that location. Any request for credentials with this scheme should preempt any other request for credentials with this same scheme. This allows a client to only track one such request at a time, without requiring an unbounded stack of nested requests, or even unrelated requests. This also allows for the third-party site to use any other authentication scheme it might find necessary before issuing the credentials. The third-party may issue the credentials in the response header with the `Authorization' header line. The client should be able to use the contents of this header line verbatim in retrying the | original request. | +-- This is a bit rough in the description, but if there are any questions, let me know. If this is something worthwhile, I'll put together a more formal description. -- James Smith <JGSmith@TAMU.Edu>, 409-862-3725 Texas A&M CIS Operating Systems Group, Unix
Received on Wednesday, 2 August 2000 07:34:54 UTC