Services/Sync/WEP/110
Contents
WEP 110 - Site Auto-registration and Password Change
- Status: Draft
- Created: 28 Oct 2009
- Reference Implementation: None
- WEP Index
Introduction
As part of the Weave Identity extension, we should support auto-registration and management of user accounts at websites and also manage passwords on behalf of the user. This WEP tackles the specific issue of the metadata that a site must provide to Weave in order to enable these features.
Metadata
Websites should include a <link rel> tag on every page that requires the presence of an identity (pages behind authentication, or registration pages).
<link rel="identity" href="/identity.json" />
Suggested alternate values for rel value: autoregister
Alternatively, this value could be placed in an HTTP response header.
JSON Format
The href attribute of the identity <link rel> should point to a JSON file that describes the interface the website provides to auto-register accounts and manage them. The format of the JSON file is described in this section. The JSON file must be present on the same domain as the web page that pointed to it, or could alternatively be a chrome URI. The best way to describe the format is by example:
{ domain: "http://example.org/", methods: { "login": { path: "/login", method: "POST", params: { userName: "usr", password: "pwd" } }, "logout": { path: "/logout", method: "POST", }, "register": { path: "/register", tos: "/register/tos.html", method: "POST", params: { userName: "name_field", givenName: "first_name_field", familyName: "last_name_field", emailHome: "email_field", password: ["pw_field", "pw_field2"] } }, "password": { path: "/pwchange", method: "POST", params: { userName: "usr", password: "pwd1", newPassword: "pwd2" } } } }
The identity JSON object MUST contain the domain and methods properties. The domain property MUST match both the domain which hosts the identity JSON object as well as the page that contained the <link rel> pointing to it.
The methods property MUST contain at a minimum the login property and MAY contain additional register and password properties. Each of these properties, if present, MUST contain a single "Form Definition Object", which is described as follows.
FDO
A Form Definition Object (FDO) describes the fields usually present in a standard HTML form and provides information on where and how to submit it in order to execute an action (currently, one of "register", "login" or "password" change).
An FDO MUST contain the path and params properties, and MAY contain the method and tos properties.
path represents a URI endpoint on which the operation will be performed, relative to the previously described domain.
method CAN be one of POST or GET. If not present, POST is assumed. This represents the HTTP method used to reach the URI endpoint for the action.
tos is a URI relative to domain that describes the terms of service the user MAY be required to accept before registering an identity. If this property is present, Weave will present the page and require the user to accept its contents before proceeding with the registration. If the site requires the user to read other documents (eg. Privacy Policy), this property's value may be an array containing multiple URIs relative to domain.
params describes the data included with the POST or GET method. Each property in this object MUST correspond with a key that describes some portion of the user's identity. Keys available are (they match those used in the People Store):
- userName
- givenName
- familyName
- emailHome
- emailWork
- password
- newPassword
- address1
- address2
- city
- state
- country
- pincode
- gender
The value of these properties MUST be set to the value of the form field key that will be sent with the POST or GET request. The value MAY be an array of field names, in which case the same value will be sent for all those fields.
Once an action has been performed, standard HTTP codes will be interpreted by Weave to indicate success or failure.
Function
When Weave detects the presence of an identity tag, it will act as follows:
- If the user is currently not logged in:
- If there is an identity in local store corresponding to the current domain:
- Offer the user to login with that identity (or) auto-login
- If there is no identity associated with the domain:
- Offer the user to auto-register with the site using a particular local identity
- If there is an identity in local store corresponding to the current domain:
- If the user is logged in:
- Show a small UI element (key in the address bar as we did with the Weave auto-login feature?) that allows the user to log out or switch identities on the current domain.
Obviously, no sites currently adopt the metadata specs described on this page. In order for us to refine the spec and hack on the underlying code, we may use Jetpack as an interim solution to inject the appropriate <link rel> tags and JSON files for a set of sites for which we know the mechanics of registration, login, and password change.