Each user in OConn has a profile. This profile represents a user's presence on the Internet. It can also be used in the context of one or more social networks or to interact with applications and games.
A profile has a unique address. Because the profile is machine readable and because people typically interact with web pages, they may also use the addresses of these web pages in place of their profile address. Thus, there are many ways to get to that address.
As an example, if a person uses their blog to host their profile, they may end up sharing their blog URL when asked for their profile URL. The blog's web page contains a link to their actual profile URL (called the profile base URL). By scanning the HTML for this link tag, a web service will be able to discover the actual profile service address. Likewise, their profile service address will return a link to the user's canonical web page URL (the profile page URL). In this example, it would likely be a URL to the same blog. This two-way relationship is called the profile cross link.
The profile cross-link allows a web service to discover the canonical set of URLs for interacting with a user's profile service, regardless of which URL may be given. It also allows web sites to discover the canonical, or “official”, profile web page.
For example, the profile page at the following address
http://blog.example.com/users/guy.mann/home.html
might contain:
... <link ref="oconn.provider" href="http://openconnections.net/1/profile/guymann" /> ...
A web service would find that address after scanning the HTML and would make a request to
http://openconnections.net/1/profile/guymann
which might return the following endpoints in the response:
... <endpoints> <service_url>http://openconnections.net/1/profile/guymann<base_url> <profile_url>http://blog.example.com/users/guy.mann/home.html<page_url> <endpoints> ...
thus establishing a cross-link between the two addresses. One address would be used for web services interactions via the REST API, while the other would be used in web page anchor elements. Each address would be discoverable from the other.
The service URL is the entry point for a web service to interact with all aspects of a profile. It contains basic public profile information, as well as a set of endpoints for the core methods of the REST API. These methods, in turn, may be interrogated to perform more in-depth queries as a web service interacts with a profile.
The service URL is intended to be embedded in the HTML link tag as a self-contained resource. It may also be copied into edit fields or other locations as a profile identifier. The URL must not contain any query parameters. This is to simplify the requirements for callers. The only parameter that is required to be accepted is format. The format argument can be either 'xml' or 'json' and is used by a caller to indicate the preferred response format.
OConn may be modified to use Yadis as the response format from the profile service URL. This would allow a profile service URL to also act as an OpenID URI. One outstanding question is whether XRDS may be represented as JSON. Supporting JSON is not an absolute requirement for the profile service URL, though a goal of OConn is to support XML and JSON uniformly.
An alternative would be to use Yadis as a discoverability mechanism for OConn. The OpenID 2.0 Yadis response would return the provider service URL as a distinct service in the XRDS response.