The very nature of WebFinger is experimentation.
This means we are likely to see implementation before a fully baked specification. Since at the moment the various bits and pieces of the protocol are somewhat scattered across multiple drafts, this post will attempt to provide a quick implementer guide for those looking to jump right in and get something working.
WebFinger is an updated take on the Name/Finger protocol using HTTP, XRD, and host-meta (instead of a direct TCP connection on port 79) to obtain information about user accounts. It works by defining a new account URI scheme and a protocol for resolving it into an extensible descriptor of the account and its owner.
The account URI, using the newly proposed ‘acct‘ scheme, is used to identify user accounts at a given host which are typically used for the purpose of resource management and establishing local identity (at the host). User accounts include a local identifier (username, screenname, or handle), and a host which can resolve and (usually) authenticate the local identifier.
The protocol consists of:
- A URI scheme to identify accounts using a familiar syntax.
- A simple protocol for resolving account URIs into an extensible descriptor.
There are few events more productive than Internet Identity Workshop.
And few that I enjoy quite so much. I’m an engineer at heart, even though these I play a pseudo-lawyer and write specifications. While I enjoy the meta conversations about the social web, I love talking code. The real thing, like working with a group of people on a new XML schema using a whiteboard, or walking through use cases and designing protocols. Ultra-geek stuff.
Continuing the themes of the last week, this week provided another approach to explaining XRD by comparing it side-by-side to XRDS. Even those new to this branch of discovery will find the comparison helpful in explaining the XRD architecture. Next came two posts about extending OAuth beyond the 3-legged scenario and into access sharing among multiple third-party applications. And last, I posted a quick report from the IETF 74th meeting regarding the outcome of the OAuth BoF.
It was a busy week but very productive (hence the slow posting).
The most significant difference between XRDS and XRD is who gets to describe related endpoints, and how this information is expressed in the descriptor document. Comparing the two formats side by side helps people familiar with XRDS understand the new architecture, but also demonstrate to new readers why the other approach is being deprecated.
It is important to note that while the <XRD> element appears in both formats, each uses a different XML namespace. The two elements share very little other than their name.
This is best explained with an example…
This week was all about XRD.
After the new XRD schema sneak-peak, I spent this week explaining how it could be applied to the two use cases on many people’s minds: OAuth and OpenID. I stared with applying XRD to the current OpenID discovery flow, something I hope the OpenID community will take on. Next I gave some background about the previous attempts at OAuth discovery, and then describe what I’m thinking for the new OAuth discovery protocol.
The next two posts (and the one to follow next week) focused on the overall architecture, breaking the XRD document into three sections, and describing using examples the XRD extensibility model.
And last, I would like to remind you that the IETF OAuth meeting will take place Monday at 1pm during the 74th IETF meeting in San Francisco. We plan to finish the charter and get some work done. Hope you join us.
The XRD schema is intentionally minimalistic. It includes a small number of elements, leaving it up to each application to define new use-case-specific elements and attributes. The XRD schema allows new elements at every level, and new attributes in every element. It uses standard XML namespaces to accomplish this. Extensibility is, after all, right in the name: eXtensible Resource Descriptor.
Let’s consider a simple use case.
A weather service is being updated consistently every few hours. Clients using the service need to know how often to come back and check for new forecasts. The service and client developers meet, and decide to write a specification for this so that others can use it to enable interoperability. They all agree that XRD fits their requirements well.
The question is, how to express the weather update frequency information using the XRD schema?