Warning:
This wiki has been archived and is now read-only.

User Header

From Read Write Web Community Group
Jump to: navigation, search

Introduction

There would appear to be no simple way in HTTP, to indicate an HTTP URL referring to the User that is currently controlling a session. This would be useful for both clients and servers, and, in particular to allow client side applications to personalize a page. Architecturally, a clean, modular, separation of identity and verified identity (authentication) may be beneficial.

There has been some discussion on whether the "From" header can be used to identify a user in HTTP, but for historical reasons it's limited to email, any change to this may receive pushback.

The suggestion has been to choose another header, and the latest proposal is to create a new User header. The text below is very similar to the existing "From" header

Registration Template

Proposed Text

User

The User request-header field, if given, SHOULD contain an identifier for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by the "URI General Syntax" RFC 3986

   User   = "User" ":" URI

An example is:

   User: http://www.w3.org/People/Berners-Lee/card#i

This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.

The client SHOULD NOT send the User header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request.

Additionally, servers MAY send this header, having verified the identity of a user, enabling client side apps to personalize a page.

Use Cases

Page Personalization

The user header would allow a personalization of pages for client side apps. One might display a user's name, avatar and homepage, by dereferencing the URL and finding out more information.

Server Response

A server may respond with a user header to tell a client who is in control of the current session. The client may use this information to access locally stored information.

Endpoint Discovery

By dereferencing a URL it may be possible to find further endpoints, for example, in order to authenticate the idenitity.

Identity Verification

While the user header is simply a hint, it is possible to imagine a scenario where more information is provided, such as a key pair in TLS, or additional information such as the "Authorization" header, to enable the server to verify the authenticity of the User. For example using Basic Auth the user may not contain the ":" character, so this would, enable a URL to be associated with a password.

Mailing List Discussions

Implementations