It is always exciting when one project leads to another equally as interesting. OAuth Discovery uses XRDS as its document format. XRDS is a rich format for describing services, and was adopted by OpenID for its preferred discovery method. Simply put, XRDS provides a method to list services and their properties in a flexible way. On the ‘simple’ side, XRDS allows listing services in groups with their URL and type. So if an application is looking for a service of a particular type, it can find a match and use the associated URL. On the ‘complex’ side, XRDS offers a wide range of tools to chain multiple documents and build advance selection criteria. It gets pretty sophisticated. Sometimes too sophisticated.
The problem with most powerful tools is the usually steep learning curve. This is true for XRDS. For many people, being part of the XRI Resolution space is the problem. XRI is surrounded with politics, some justified, some not. I am working on a post telling the story behind XRI and XRDS so more to come on that topic. But politics aside, the flexibility XRDS affords isn’t trivial to implement. Many think that the small subset adopted by Yadis and shown in OpenID examples is what XRDS is, but it is a very small fraction. If you implement an XRDS parser based on the OpenID examples, it will most likely to blow up parsing more complex XRDS documents.
OAuth Discovery is meant to be simple. Just like OAuth, the test is, can it be implemented by an average developer. There is an important difference between technology companies build internally and technology they expose. Google for example, will not adopt a complex API format even if its developers can handle it, because not all their customers are at the level of a Google developer. To base OAuth Discovery on the full XRDS specification is a problem for this exact reason. So we need something simple, but without inventing anything new.
Introducing XRDS-Simple. As the name implies, XRDS-Simple is a simplified version of XRDS. It is fully compatible with its big brother, but allows developers to state that their application does not require the power of XRDS and will restrict themselves to that of a smaller format. It doesn’t mean there is anything wrong with XRDS. Calling the new subset ‘Simple’ doesn’t imply anything negative on the full format. Tools should match the need, and there are many cases where XRDS-Simple is all that is needed, making the limitations an advantage.
As for the name, we wanted something that will keep us honest – pick a subset that is truly simple. The first draft of XRDS-Simple will be published as an appendix to OAuth Discovery Draft 2. Watch this space for the latest announcement on both specifications. Meanwhile, if you have use cases where XRDS-Simple sounds like what you need, let me know so that we can address a wide-range of use cases.
* * *
On a different note, I have decided to leave the Data Portability Workgroup, the community effort organized by Chris Saad everyone has been joining lately. Sometimes all the best intentions are not enough to make something work. At least not for me.