hueniverseThoughts on Technology, Standards, and the Open Web2010-09-06T06:16:57Zhttp://hueniverse.com/feed/atom/WordPresshttp://creativecommons.org/images/public/somerights20.gifHueniversehttp://feedburner.google.comEran Hammer-Lahavhttp://hueniverse.com<![CDATA[How to Enter a Standards Working Group]]>http://hueniverse.com/?p=13502010-09-06T06:16:57Z2010-09-06T06:16:57Z<p>As the OAuth specification editor, I am approached daily with comments, questions, ideas, and some very odd solicitations. It is quite fun. It seems that most people joining the work are determined to undermine their contribution by doing their best to alienate or insult the community, and often the editor.</p>
<p>This is not unique to OAuth – I have seen the same mistakes in many other places. Since working on an early draft of the OAuth 2.0 specification, I started collecting tips for newcomers. Here are some that would make your entrance into a standards working group much smoother and productive.<span id="more-1350"></span></p>
<p><strong>Don’t start with a proposal, start with a question.</strong></p>
<p>Assume you don’t understand everything, especially if you have feedback or ideas for changes. Instead of jumping in with some new re-architecture of the entire protocol, start by asking why it is the way it is. Engage the community first with a question, and work your way to change requests based on the answer you receive. By asking a question, you allow for the possibility that whatever if bugging you has a valid reason.</p>
<p><strong>Keep your message as short and to the point as possible.</strong></p>
<p>You are an unknown so people will look for reasons to ignore your message. Most people don’t even open messages from newcomers. Instead, they wait to see if a thread develops. In other words, they wait until someone else puts in the extra work to deal with the new guy. If your message is short, it is more likely not to be ignored.</p>
<p><strong>Don’t email the editor privately, asking for permission before asking the list.</strong></p>
<p>You don’t need permission to ask questions or post to the list. All the specification editors I know (and certainly me) are usually busy and work in bursts. This means your email is most likely going to be moved to some queue of questions and feedback about the specification, to be processed right before the next editorial cycle. You are also wasting their time by forcing them to read your message twice (once directly and once on the list), and in many cases, repeat the discussion. This is why we have a public list – just join and post away.</p>
<p><strong>Don’t prefix your message with I’m new here.</strong></p>
<p>It’s never a good idea to start a relationship with an excuse. The only reason to put an “I’m new here” disclaimer on your message is if you were too lazy to do your homework, read group archives, read the full specification (and revision history), and think before writing. If you do all that, your contribution is as valid and relevant as that of anyone else. The working group regulars know you are new.</p>
<p><strong>Focus on what you know best.</strong></p>
<p>Pick an area where you have experience and provide feedback to show you know what you are talking about. Don’t start with a multi-page review of the entire specification. Instead, focus on the areas you are most knowledgeable about and demonstrate your skills and experience through the quality of your contribution. Don’t provide a summary of your career – saying you have many years of experience is the least effective way to get that message across. Let you work speak for itself.</p>
<p><strong>Never start with an editorial suggestion.</strong></p>
<p>Editors like to write, and they take pride in their work. They also have their own unique voice. Starting a relationship with a specification editor by criticizing their style is not a good way to get them to listen. Typos, mistakes, and other technical issues with the specification are always welcomed, but offering replacement text or ideas on how to say something differently will most likely be ignored, no matter how good the suggestions are. Wait for an editor to ask you to suggest text before sending in your own revision.</p>
<p><strong>Start with a compliment, show good progress.</strong></p>
<p>Pick something you think is good about the work, and highlight it. This isn’t rocket science, just common sense. Don’t compliment any one person in particular (like the editor or chair). Compliment the work and the community and do it in a way that adds value, like highlighting what is strong and good about the work, providing additional support.</p>
<p><strong>Clearly state your role and introduce yourself.</strong></p>
<p>Spend a few words to introduce yourself the first time you write something. Don’t just barge in – it’s rude. Also, standards are highly political, and in a political environment, people want to know who they are dealing with. No need for life story, just the basic facts (lurker, developer, representative for a big company). And don’t assume everyone know who you are just because you think you are important.</p>
<p><strong>Do your political homework.</strong></p>
<p>Identify the key participants and align yourself with those you agree with, showing you are well versed in the internal politics. Joining the discussion through agreement with a primary participant allows you to establish a work relationship with those most likely to be in a position to listen and impact. Agreeing with someone is usually better than disagreeing – it adds emphasis to an existing view, and doesn’t cost you political points going directly against someone else.</p>
<p><strong>Make sure to be right if you are going to keep a thread going.</strong></p>
<p>If you are going to stand your ground and keep an argument going, against the group consensus, make sure you know what you are talking about. It is perfectly fine to keep an issue going if you are unhappy with the resolution, but if you are new, this behavior is more likely to alienate the group than win your argument. If you are going to keep at it, make sure to add new facts and new examples to make your point.</p>
<p><strong>Don’t explain basic standards principals.</strong></p>
<p>Assume everyone knows what bike-shedding, design by committee, or KISS are. Don’t lecture the working group about process and other philosophical ideals. For most of the people involved, this is probably not the first standard.</p>
<p><strong>Don’t prefix more messages with “I’m still new here”.</strong></p>
<p>You didn’t need to state it the first time, so please don’t keep repeating you are (still) new. Yes, we got it, you are new here.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/oqemuOCuPng" height="1" width="1"/>0http://hueniverse.com/2010/09/how-to-enter-a-standards-working-group/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[All This Twitter OAuth Security Nonsense]]>http://hueniverse.com/?p=13432010-09-02T22:53:58Z2010-09-02T22:49:13Z<p>In a <strong>wordy </strong><a href="http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars">article </a>that could have been much shorter and a lot less sensational, <a href="http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars">Ryan Paul of ArsTechnica throws</a> mud mostly at Twitter, but saves plenty to throw at OAuth. Unfortunately, Ryan Paul (who clearly is a smart guy) is heavy on the accusation but light on the arguments. Typically, I would go over this article an item at a time, but I’m right in the middle of draft 11 of OAuth 2.0 which is a much better use of my time. If you want to read a great rebuttal, <a href="http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/">Ben Adida’s response</a> (as always) is a great read.<span id="more-1343"></span></p>
<blockquote><p>The OAuth standard has many significant weaknesses and limitations. A number of major Web companies are collaborating through the IETF to devise an update that will fix some of the problems, but it’s still largely a work in progress. The current version of the standard—OAuth 1.0a—is an inelegant hack that lacks maturity and fails to provide clear guidance on many critical issues that are essential to building a robust authentication system.</p></blockquote>
<p>First, the current version of the standard is <a href="http://tools.ietf.org/html/rfc5849">RFC 5849</a>. The RFC not only changed a lot of the terminology, highlighted the known security limitations, and has completely new prose, it also explicitly clarified at least one of the author’s issues regarding the handling of timestamps (which most companies don’t even bother to check anyway).</p>
<p>My favorite silliness from the article, when discussing the lack of specification details about using client secrets in installed applications:</p>
<blockquote><p>Part of the problem is that the specification doesn’t provide much guidance about what implementers should do instead, which has forced them to improvise. Facebook and Google Buzz have both come up with reasonable solutions and offer desktop-appropriate OAuth authentication flows that do not require a secret key or require the end user to go through a complicated copy/paste process.</p></blockquote>
<p>The specification is very clear (as the article quotes) – don’t use client secrets in installed applications! The reason why the specification doesn’t say much more is because there is no solution. It does not exist for a distributed application unless you issue a different secret to each installation. To say that Facebook and Google came up with reasonable solutions is pure sensationalism. What is their reasonable solution? They don’t use client secrets. In other words, they do exactly what the specification says.</p>
<p>The article does bring up important points implementers should pay attention to when using OAuth, such as the secrecy of their client credentials, the exact details of their user experience, how they authenticate the user (cookies, etc.), and an overall awareness to phishing. But OAuth, just like other security protocols, is designed to be implemented by security experts. In addition, there are simply no widely available solutions for many of these problems.</p>
<p>If Twitter uses the client secret in installed application for anything other than gathering statistics, well, they should <strong>reconsider</strong>. But it’s not like they have other alternative. That’s the only valid “news” the article has to offers.</p>
<p>It’s easy to<a href="http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/"> throw mud without getting dirty with making a fully baked technical argument</a> – and it makes for a fun read too. But when it comes to a widely deployed security protocol, scoring page views by scaring readers about security is<strong> not fair game</strong>. It is always valuable to highlight OAuth’s weakness, but in context, with the right security risk analysis, and with clear comparison to other alternatives.</p>
<p>I expect more from ArsTechnica.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/3fObPZN5EYM" height="1" width="1"/>7http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/Will Meyerhttp://www.willmeyer.com/<![CDATA[An Introduction to OExchange]]>http://hueniverse.com/?p=13292010-06-10T06:19:05Z2010-06-10T06:19:05Z<p><a href="http://hueniverse.com/wp-content/uploads/2010/06/oexchange_128x128.png"><img class="alignleft size-full wp-image-1338" style="margin: 10px;" title="oexchange_128x128" src="http://hueniverse.com/wp-content/uploads/2010/06/oexchange_128x128.png" alt="" width="128" height="128" /></a><strong>OExchange</strong> is a <a href="http://techcrunch.com/2010/06/02/oexchange">newly-introduced</a> protocol stack that allows users to share URL-based content with any service on the web. It covers posting links to social networks as well as sending content to things like online translation and printing services.</p>
<p>The protocol — driven by the folks at <a href="http://www.clearspring.com">Clearspring</a> (where I work) with the support of a long list of online services — builds on several existing open web specifications. It is backed by an open development <a href="http://groups.google.com/group/oexchange">list</a>, <a href="http://www.oexchange.org/tools">tools</a> for developers, and lots of additional <a href="http://www.oexchange.org">resources</a>.</p>
<h3><strong><span id="more-1329"></span></strong><strong>The Problem</strong></h3>
<p>Lots of services accept URL-based content — social networks, news and bookmarking sites, communication tools, long-tail forums, translation utilities — and more appear every day. Why do blogs only allow users to share to the top few social networks? Why can’t users engage with more personal, relevant, dynamically-discovered options? Why are sharing tools and publishers still “integrating” with services individually?</p>
<p>As I’ve written <a href="http://www.addthis.com/blog/2010/06/02/the-future-of-open-sharing-is-the-web">before</a>, users should be able to send content to any of an unbounded number of services. Sharing features should dynamically adapt to support the communities of interest users actually participate in and the tools they use, whatever platforms they are built on, and whether or not they are well-known. Services should be able to receive content from anywhere, in a common way. Basic interoperability benefits the web at large — services, users, and content providers — and we see a tremendous gap when it comes to simple URL exchange.</p>
<h3>The Solution</h3>
<p>A common protocol means more content for services, easier integration for tools, more personalization for users, and more traffic back to publishers. OExchange defines the technical solution in three areas (take a look at the complete <a href="http://www.oexchange.org/spec/">spec</a> for all the gory details).</p>
<p><strong>1. A way for services to receive content</strong></p>
<p>Known as an “Offer” in OExchange terminology, this method maps onto the dominant model already deployed widely today. Specifically, for a service to be able to accept content via OExchange, it exposes an endpoint of the form:</p>
<pre>http://www.example.com/share.php?url=http://hueniverse.com</pre>
<p>This endpoint (which can be located at any path) accepts a set of <a href="http://www.oexchange.org/spec/#offer">standard</a> arguments. Only one of these arguments, the url, is required. Anyone can send content to this service by sending the user’s browser to this endpoint. The receiving service controls any relevant authentication as well as other aspects of the user experience — the service is the one that defines what actually happens once the user sends their URL there.</p>
<p>A common method removes any and all service-specific integration requirements — all supporting services can accept content in the same way.</p>
<p><strong>2. A way for services to make themselves discoverable</strong></p>
<p>By building on top of the established <a href="http://hueniverse.com/xrd/">XRD</a> and <a href="http://tools.ietf.org/html/draft-hammer-hostmeta-12">host-meta</a> specifications, OExchange makes it possible to integrate with services that you, as a content publisher or sharing tool, didn’t even know about at development time.</p>
<p>A service defines everything about itself in a structured and machine-readable document format (known as the OExchange <a href="http://www.oexchange.org/spec/#target-xrd">Target XRD</a>), and anyone that wants to integrate with it can easily locate this document using established means (such as host-meta references).</p>
<p>This makes it possible to determine that a service exists, and how to send content to it, dynamically as opposed through manual integration. The full discovery flow is outlined in the <a href="http://www.oexchange.org/spec/#discovery">spec</a>.</p>
<p><strong>3. A decentralized, user-centric model for expressing preferred services</strong></p>
<p>We are big believers in the promise of <a href="http://www.abstractioneer.org/2009/04/personal-web-discovery.html">personal discovery</a>. In OExchange, we recommend the use of <a href="http://hueniverse.com/2009/08/introducing-webfinger/">WebFinger</a> and, eventually, <a href="http://xrdprovisioning.net/">XRD Provisioning</a>, to let a user publish a set of services they actually care about, in the form of service XRD URLs. The key idea here is that it should be possible to look up the set of link-accepting services (each expressed as machine-readable documents) appropriate for a given user. Tools can inspect this list and present the right options to the user at runtime.</p>
<p>Importantly, this list may include services the tool doesn’t actually know about — it can use the basic OExchange discovery mechanism to then figure out how to send content to this service. For example, imagine visiting a blog and being presented with not only the option to share content to the mainstream social networking service on which you have an account, but also the long-tail service no one but you and your 5 friends has heard of.</p>
<h3>Do we need another protocol?</h3>
<p>There is quite an open web capability stack available at this point, and OExchange leverages established protocols extensively. That said, there are a few things missing to accomplish certain domain-specific use-cases. For example, though there are any number of relatively domain-specific protocols that can be used to send content from one service to another, there are none which can offer a simple interoperability layer without introducing substantial requirements on the implementor. Its our belief that these requirements can counteract the benefit of the additional content to the service, and hamper adoption.</p>
<p>For anything that OExchange is newly-defining, it therefore keeps the recommendations as simple as possible, and actually takes pains to map onto predeployed models. Really, OExchange is as much a packaging of existing protocols into a specific use-case stack as it is a new protocol.</p>
<h3>What next?</h3>
<p>The strategy we’ve taken with the specification is to first codify an existing practice and be compatible with a wide range of existing deployed services, then to add a new service discovery capability on top of that, then to expand from that point into additional protocol actions and modes. In this vein, along with encouraging adoption and working to support the stack in the products we’re all building, we’re now beginning to focus in earnest on the additional capabilities. One often-cited example is an exchange mode that can take place without popping a new browser window/tab.</p>
<p>If you’re interested in getting involved in the development of the spec, please join <a href="http://groups.google.com/group/oexchange">the discussion</a>. If you just want to get going on implementing it, check out the quick start <a href="http://www.oexchange.org/guide">guide</a>.</p>
<p>We’re pretty excited about a more interoperable web, thanks for the chance to outline it!</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/XKL0mV7WSck" height="1" width="1"/>1http://hueniverse.com/2010/06/an-introduction-to-oexchange/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[How the Open Community Can Beat Facebook]]>http://hueniverse.com/?p=13252010-06-08T07:38:40Z2010-06-08T07:38:30Z<p>Well, the open community can’t beat Facebook.</p>
<p>But companies using open technologies can – by building better products. Outside the echo chamber of web standards fanatics, the vast majority of web users don’t care about how the web works. They care about their user experience, where their friends are, and when something goes wrong, protecting their privacy.</p>
<p>When I read about Google Buzz (and other open-based products), it is repeatedly described as the open alternative to Facebook. Does this information help me (as a consumer) make a better decision about which product to use? No. That’s like telling the average cell phone buyer that the difference between the iPhone and Android is that the latter uses an open source operating system. When it comes to selling phones, Google relies on their search reputation and brand, not the openness of their platform.<br />
<span id="more-1325"></span><br />
Getting consumers to use your products, like any other retail interaction, requires offering something useful that is better than other alternatives. It is true that sometimes a backlash against one company leads consumers to switch to someone else, but they don’t “vote for the new guy”, they “vote out the old guy”. If users leave Facebook to use Google, it is not a victory for Google – it is a loss for Facebook.</p>
<p>When it comes to showing the value in open technology, very few efforts can show how being open makes products better. Even if OpenID solved all its problems, <a href="http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/">found a less offensive solution to the NASCAR problem</a>, got providers certified and trusted, provided a legal framework for managing liability, educated consumers, and actually worked, it will still fail without the wealth of data offered by Facebook.</p>
<p>Why should publishers (content and service providers) choose a solution that doesn’t deliver actual consumer value?</p>
<p>In an attempt to address this, the OpenID community has been looking for ways to compete with Facebook. The OpenID/OAuth Hybrid proposal was one approach. Adding rich profile data was another (in the <a href="http://factoryjoe.com/blog/2010/01/04/openid-connect/">conceptual proposal for OpenID Connect</a>). But these are all focused on enabling technologies, not products. Even if there was a complete open solution for every Facebook feature, it would still not offer a compelling value proposition because without actual data behind it, it is nothing but empty containers.</p>
<p>If Facebook asked me, I would recommend using open technologies because it is good for business (when available and applicable). But to everyone else I would recommend focusing more on the product and less about the openness of the platform. Open is certainly a selling point in the enterprise market, but it is not in the consumer market.</p>
<p>Two years ago the big fight was against the “walled-gardens” and user data, now it is about open standards. It didn’t make a difference back then (users didn’t care) and it won’t make one now. Facebook didn’t change their data policies because of what users wanted – they changed it because of what publishers demanded, and the publishers asked for data, in whatever shape or form Facebook wanted to give it.</p>
<p>The reason why the <a href="http://openidconnect.com/">newly proposed OpenID Connect protocol</a> is actually promising is that it focuses on mobility instead of federation. Instead of trying to build a fully distributed and federated identity framework, the proposal uses <a href="http://hueniverse.com/2010/05/introducing-oauth-2-0/">OAuth 2.0</a> to build vendor-specific identity solutions that are all implemented the same way. By allowing publishers to move from one compliant vendor to another, it lays the groundwork for future federation and distribution.</p>
<p>In other words, the fact that it doesn’t embrace discovery at its core, but starts with reliance on client registration and vendor specific relationship is an assets because it guarantees better products with built-in mobility. That mobility will allow publishers to take their business elsewhere if they don’t get the data and services they want.</p>
<p>Good technology enables better products. Being open is just the cherry-on-top.</p>
<p>Then of course, there is the other option: <a href="http://hueniverse.com/2010/05/open-vs-fast-good-vs-evil-google-vs-facebook/">if you can’t beat them, join them</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/-eX4Be1Fcwc" height="1" width="1"/>4http://hueniverse.com/2010/06/how-the-open-community-can-beat-facebook/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[XAuth – a Terrible, Horrible, No Good, Very Bad Idea]]>http://hueniverse.com/?p=13182010-06-08T05:27:42Z2010-06-06T06:31:12Z<p><a href="http://hueniverse.com/wp-content/uploads/2010/06/xauth.png"><img class="alignright size-full wp-image-1320" title="xauth" src="http://hueniverse.com/wp-content/uploads/2010/06/xauth.png" alt="" width="188" height="306" /></a>A few weeks ago, a handful of web companies lead by Meebo and Google (with moral support from Yahoo!) <a href="http://googlesocialweb.blogspot.com/2010/04/simplifying-social-web-with-xauth.html">announced their support</a> for a new protocol called <a href="http://xauth.org/info/">XAuth</a>. The idea is very simple and seemingly appealing – create a sort of shared-cookie service for sites to use to store and find which identity providers a user prefers, solving the <a href="http://factoryjoe.com/blog/2009/04/06/does-openid-need-to-be-hard/">OpenID NASCAR problem</a>. It is a similar idea to existing commercial products such as <a href="http://www.janrain.com/products/rpx">JanRain’s RPX</a>.</p>
<p>I’ve heard about this proposal a few months ago and have been rolling my eyes ever since. Why? Because this is – to borrow from one of my son’s <a href="http://www.amazon.com/Alexander-Terrible-Horrible-Good-Very/dp/0689300727">favorite book</a> – <strong>a terrible, horrible, no good, very bad idea</strong>. It is a dangerous and over simplified hack aimed at solving a complex problem – how to manage online identities and improve the usability of distributed identity providers.<br />
<span id="more-1318"></span><br />
The <a href="http://xauth.org/spec/">XAuth proposal</a> is a privacy and security nightmare. It relies on the use of a single, shared domain name which is currently <a href="http://www.networksolutions.com/whois-search/xauth.org">under the control of one company – Meebo</a>. While I have nothing against Meebo, other than proposing and promoting this, I certainly don’t trust it to manage the web’s identity preference layer. I heard suggestions of handing control over to the OpenID Foundation, but I don’t trust it either. If it is controlled by a single entity, it fails the most basic test of distributed identity services.</p>
<p>In addition, XAuth is a cookie-like mechanism that suffers from all the same problems, and as such, is an easy target for abuse and manipulation. And guess what – it is an <a href="http://xauth.org/">opt-out mechanism</a> per browser.</p>
<p>This is a misguided attempt to solve a problem browser vendors have failed to address. It is true that getting browser vendors to care about identity and innovate in the space is a huge challenge, but solving it with a server-hosted, centralized solution goes against everything the distributed identity movement has tried to accomplish over the past few years.</p>
<p>As for the name, I resent the association between XAuth and the OAuth brand, using a cloned logo and a very confusing name. This is especially true considering it has nothing to do with OAuth, and everything to do with OpenID. And by the way, the name is <a href="http://en.wikipedia.org/wiki/X_Window_authorization">already taken</a>.</p>
<p><a href="http://www.amazon.com/Alexander-Terrible-Horrible-Good-Very/dp/0689300727">I think I’ll move to Australia.</a></p>
<p><strong>Update</strong>: This post <a href="http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html">sparked a response</a> from Google’s John Panzer (someone I highly respect, and respectfully disagree with) as well as an <a href="http://lists.openid.net/pipermail/openid-specs/2010-June/thread.html">interesting thread on the OpenID list</a>. A couple quotes I complete agree with:</p>
<p>From <a href="http://lists.openid.net/pipermail/openid-specs/2010-June/007166.html">Peter Watkins</a>:</p>
<blockquote><p>The current XAuth implementation has sites using IFRAME elements to access the XAuth service/JS code. Web browsers send Referer headers with IFRAME, so whoever runs xauth.org is in a position to see information about what Extender and Receiver sites a user accesses. Currently auth.org has pretty good settings — cache control headers telling browsers they can cache the page for a week. But that could change. Move responsibility into the browser and that problem is solved.</p>
<p>Also, xauth.org could start delivering JS code that reports information to the xauth.org mothership in addition to simply “working”. Say the local government tries to compel xauth.org to deliver additional code to specific IP addresses (not that Google has *ever* had any trouble with any government legal pressure, right?). xauth.org could deliver pristine, trustworthy JS to everyone else. How would the government targets, let’s say political activists maybe, be able to tell their privacy was being subverted? Move the function to the browser and that hole is closed.</p>
<p>This is by no means a comprehensive list (shoot, it’s been less than 24 hours since I startd reading up on XAuth), but I think it’s enough that you can’t say there are no privacy issues that going to an in-browser model would solve no privacy issues.</p></blockquote>
<p>From <a href="http://lists.openid.net/pipermail/openid-specs/2010-June/007169.html">Philip Hallam-Baker</a>:</p>
<blockquote><p>As often happens in these debates, we have a proposal that has an acknowledged issue that we are being told isn’t an issue because the developers don’t see it as an issue.</p>
<p>I really take offense when I raise an issue and someone says ‘that does not matter to anyone’ or ‘that issue has been dealt with’. The one issue that I have never found it difficult to get the industry to agree on is the necessity of ensuring that no party gains a proprietary leverage in a communication protocol.</p>
<p>I don’t see how the promise that the issue will be fixed in future changes anything. Either the centralization is easy to eliminate from the protocol or it isn’t. And if it is easy to eliminate then why introduce it in the first place?</p>
<p>The starting point for identity in my view is that I have to entirely own my name. There cannot be any entity that can use the investment I make in my name to extract rent at a future date. No corporation, no not-for-profit, no non-profit, no industry group. Nothing.</p></blockquote>
<p><em>(Image adapted from the book “Alexander and the Terrible, Horrible, No Good, Very Bad Day” by Judith Viorst, illustrated by Ray Cruz.)</em></p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/jnWH4kwFr3c" height="1" width="1"/>18http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Open vs. Fast, Good vs. Evil, Google vs. Facebook]]>http://hueniverse.com/?p=13152010-05-28T18:34:02Z2010-05-28T18:34:02Z<p>The landscape of the community-engineered social web, the one based on open technologies, has changed dramatically over the past few months. If you took a year off and just came back, you would probably not recognize it at all.</p>
<p>The movement that started with protocols such as OpenID, OAuth, and Activity Streams, is now mostly gone. All the cool kids got grownup jobs and the market is back again driven by a small number of corporations. In fact, it is so small it can be counted on two fingers. A year ago, a meeting with Chris Messina, David Recordon, Joseph Smarr, Monica Keller, Will Norris, Luke Shepard, and John Panzer represented 7 different organizations or communities – a well-balanced mix of big and small, corporate and independent.</p>
<p>Today it’s just Facebook and Google and that has significant implications. But when examining how these two companies engage in the development of open technologies, the findings are quite surprising. On the product side, Google is famous for their openness while Facebook is notorious for their closed garden. But when it comes to their community engagement, these two giants behave in a rather reverse fashion.<br />
<span id="more-1315"></span><br />
<strong>Open technology is slow by definition</strong>.</p>
<p>That’s assuming you accept my definition of Open Technology:</p>
<blockquote><p><span>Developed in the open with full transparency<br />
Open process for anyone to participate freely<br />
Everyone is free to implement<br />
Decisions are made based on technical merit<br />
</span></p></blockquote>
<p>Open technology doesn’t have to happen in a standards body or format open source organization, but important work usually does; because if it’s important, there are simply too many people collaborating to be successful without a well-defined process and governance. Successful open technology acts very much like a proprietary one – they both tend to block or delay new innovation. As soon as something becomes successful, it poses high risk to those absent from the process.</p>
<p>OAuth 1.0 created a myth that it is possible to develop open technology fast. But in reality, <a href="http://hueniverse.com/oauth/guide/history/">OAuth 1.0 took a little over a year</a>, and that’s with a tiny, well-aligned group of people almost exclusively from one town, with very little at stake. The numbers are even less impressive if you include getting to revision A as part of the 1.0 lifecycle.</p>
<p>OpenID had a very similar experience where version 1.0 (really 1.1) took little time (mostly created by two people) while version 2.0 took a very long time. Deciding what the next version of OpenID looks like seems to take even longer.</p>
<p>Two years ago I was one of the leaders of this movement. It was the main driving force behind creating the <a href="http://hueniverse.com/2009/03/explaining-the-open-web-foundation-why-a-new-process/">Open Web Foundation</a> (i.e. a <a href="http://hueniverse.com/2009/03/explaining-the-open-web-foundation-new-kind-of-legal-framework/">lightweight legal framework</a> suited for small, community driven projects). The problem with this approach is that it ignores why and how companies develop open technology, and the real reasons why it takes time.</p>
<p>People new to standards like to accuse the excessive process and legal framework for the time it takes to produce a standard. But this argument is simply not grounded in reality. For example, XRD 1.0 which is quickly becoming one of the building blocks of the social web took over 2 years to mature from XRDS through XRDS-Simple to XRD. During those 2 plus years, the OASIS process (where the work was done) did not slow us down by more than a week or two. What slowed XRD’s development was lack of feedback, review, and editorial time. But even these factors were not the primary reason.</p>
<p>There are two reasons why specifications take time: building consensus and reaching maturity. Consensus time is usually a function of the group size. The bigger the group the longer it takes. Maturity however, is a function of taking intentional breaks during the process to let the technology sink in, and allow time for experimentation. Maturity is what differentiates a useful technology from an essential one.</p>
<p>If I listened to the many calls to get XRDS-Simple done two years ago because people wanted to ship stuff “<strong>now</strong>“, we would have ended with broken discovery architecture and a complex format that no one really needed. On occasion, these demands for finalizing specifications took the form of subtle threats to develop competing proposals. Getting the right people to read specifications takes time, and it often means waiting for the use cases to catch up with the vision.</p>
<p>If you compare the <a href="http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/">initial proposal of site-meta</a> with the final <a href="http://hueniverse.com/2010/04/rfc-5785-defining-well-known-uris/">RFC for Well-Known URIs</a>, you immediately notice a remarkable transformation which was the result of a yearlong discussion and collaboration across three standards bodies. My discovery work follows the same pattern, from the initial OAuth Discovery work to the current, much simplified host-meta proposal (and the retirement of the LRDD stand-alone specification).</p>
<p>Like anything else, early adopters have to accommodate this reality, and it can often lead to frustration. The Open Web Foundation is one example for how this frustration with standards bodies materialized into an (<a href="http://hueniverse.com/2009/12/whats-in-a-name-that-which-we-call-the-open-web-foundation/">unsuccessful</a>) attempt to create a whole new framework. While the foundation was very successful in creating a useful legal license, it was not significant enough to get new technology out faster. Ironically, it made it much easier for companies to develop new technologies internally, the open them up when done.</p>
<p>In order to understand the forces that drive the development of open technologies, we must first examine how companies address these issues. There are generally three categories of companies when it comes to interaction with open technology: <em><strong>conservative, agile, and delayed-open</strong></em>. It is important to understand that these categories are specific to how companies interact with open technology, and are not an indication of how the interact in the marketplace.</p>
<p><em><strong>Traditional </strong></em>companies are rarely first to adopt new technology, wait for final versions before implementing, and actively participates only when a specification takes a wrong turn. They are usually absent from the process or lurk around, but engage with some form of indirect support (such as sponsoring events or supporting the community). Traditional companies tend to focus on building business relationships with other similar companies and establish back-channel alignment, which enables them to let others represent their interests. Yahoo! and Twitter are good examples of traditional companies.</p>
<p><em><strong>Agile </strong></em>companies live on the cutting edge, deploying early drafts and are not afraid to change quickly. They are usually very hands on, often leading the development efforts, and maintain some level of control over the process, which helps reduce risk by having better understanding of the proposal’s stability. Agile companies are usually very small where being agile provides a necessary edge, or very big where they can afford to take more risk and experiment because of their market dominance. Facebook and (the now defunct) Pownce are good examples of agile companies.</p>
<p><em><strong>Delayed-open</strong></em> companies are very selective in what they choose to participate in, and are rarely involved in efforts they do not control. The basic strategy of delayed-open companies is to develop as much as possible internally and confidentially. They only share their work when they are ready to ship a product or when they are confident in the stability of the technology. While these technologies end up being open (typically by opening their development to final enhancements, or by contributing them to a standards body), by the time they are opened up, very little can really change. Google and Microsoft are good examples of delayed-open companies.</p>
<p>Companies looking to engage in the development and utilization of open technologies must find the right balance that fits their culture and market needs. Google and Facebook provide important case studies on how companies approach open technology from opposite ends of a given market. When it comes to social web applications, Facebook is the undisputed market leader, while Google is one of the (hardest trying but) least successful players.</p>
<p>Both companies recently made high profile hiring moves, grabbing every free-agent open technologist in the space. Facebook hired David Recordon and Monica Keller (joining Luke Shepard and others), while Google hired Chris Messina, Joseph Smarr, and Willl Noris (joining John Panzer, Brad Fitzpatrick, and others). But their reasons for doing so are fundamentally different, dictated by their involvement category.</p>
<p>Facebook, with time on their side, hired people to help open up their technology and use their market dominance to influence and lead new efforts. Their position allowed them to deploy an early draft of OAuth 2.0 in a highly publicized fashion, and to promise keeping their production code up to date as the specification matures. To accomplish that, their engineers engaged early and intensely, contributing the first draft and running code. The more Facebook invests in open technologies, the longer it takes these technologies to mature (due to their sudden importance and popularity), but with a higher likelihood of maturity.</p>
<p>Google on the other hand, hired top caliber talent for very different reasons. Google is significantly behind Facebook and cannot afford to take years (or even months) for new technologies to mature. They need to build products and ship them quickly, and that requires much more control than is available in open development. By hiring highly respected individuals like Chris Messina and Joseph Smarr, Google is hoping to get away with doing more work delayed-open. Salmon, PubSubHubbub, WRAP, and their OpenID extensions are all examples of past technologies developed successfully using this method.</p>
<p>While Facebook shipped an early draft of OAuth 2.0, Google shipped WRAP. Both promised to ship the final OAuth 2.0 protocol.</p>
<p>It is hard to say which category ends up making the biggest contribution to the development of open technologies. Google is clearly a leader in adopting open technology in general, but the way in which they get comfortable doing so isn’t always the most open or polite. Google’s style helps get more free technology faster, but it also makes is much harder for other companies to participate when the foundation is established. Google is leading an Open war, and in war, there are often innocent casualties.</p>
<p>There is a direct correlation between a company’s ability to control the process and their embrace of the technology. Facebook came in late to the WRAP party, leading them to favor the (at the time) less prominent and less successful OAuth 2.0 effort at the IETF (while Google did their very best to derail the IETF effort). In the same spirit, Google’s bear hug of HTML5 came only after they guaranteed their strong control over the process by hiring the specification editor (for the sole purpose of getting HTML5 done fast).</p>
<p>The manifestation of these two approaches is sometimes ironic. Facebook who is not known for their embrace of open protocols and technology, is the one enabling open communities to take their time and spend a little longer to get the details right. On the other hand, Google who is considered the biggest champion of openness is doing their best to push efforts to a quick conclusion, strongly aligned with their immediate needs.</p>
<p>While this analysis includes a slight bias in favor of the contribution of agile companies, delayed-open companies play an important role in creating alternatives, not possible by purely open means alone. Facebook only turned the page and joined the open community when it felt the open community no longer posed a threat to their dominance, and their behavior depends greatly on the individuals leading the effort. The Facebook influence at the hands of David Recordon (who at this point is by far the most influential voice in advocating open technologies) is an extremely constructive force. However, it is clear that without Google chasing their tail and portraying them as closed, Facebook will be much less motivated to open up.</p>
<p>It is also important to remember the significant contribution of traditional companies. They provide the final seal of approval for new technologies and are the key to mass adoption. They are also critical in getting enough community sponsorship to allow work to continue.</p>
<p>At the end we rely on a few individuals to do the right thing. On the Google side, we rely on people like Chris Messina and Joseph Smarr to know where to draw the line between delayed-open and fully-open. Because delayed-open leave very little for the community at large to influence, they must find the right balance between pragmatic time-to-market and forcing their own ideas on the rest of us. When Chris and Joseph joined Google, I <a href="http://www.readwriteweb.com/archives/how_chris_messina_got_a_job_at_google.php">predicted exactly this kind of shift</a>. I have confidence that their work will continue to be innovative and inspiring, but the silence and disengagement coming from the Google team over the past six months is a real cause for concern.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/mYJCnph-jsU" height="1" width="1"/>6http://hueniverse.com/2010/05/open-vs-fast-good-vs-evil-google-vs-facebook/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Introducing OAuth 2.0]]>http://hueniverse.com/?p=13032010-05-15T07:13:43Z2010-05-15T07:06:38Z<p><a href="http://hueniverse.com/wp-content/uploads/2010/05/OAuth2.png"><img class="size-full wp-image-1305 alignright" style="margin: 10px;" title="OAuth2" src="http://hueniverse.com/wp-content/uploads/2010/05/OAuth2.png" alt="" width="223" height="223" /></a>Two weeks ago, the <a href="http://tools.ietf.org/wg/oauth/">IETF OAuth Working Group</a> published the first draft of the <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">OAuth 2.0 protocol</a>. OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords. <a href="http://oauth.net/core/1.0">OAuth 1.0</a> was published in December 2007 and quickly become the industry standard for web-based access delegation. A minor revision (<a href="http://oauth.net/core/1.0a">OAuth 1.0 Revision A</a>) was published in June 2008 to fix a security hole. In April 2010, OAuth 1.0 was published as <a href="http://tools.ietf.org/html/rfc5849">RFC 5849</a>.</p>
<p><strong>OAuth 2.0 is a completely new protocol</strong> and is not backwards compatible with previous versions. However, it retains the overall architecture and approach established by the previous versions, and the same introduction (from the Official Guide to OAuth 1.0) still very much applies.<span id="more-1303"></span></p>
<blockquote><p>Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.</p>
<p>As the web grows, more and more sites rely on distributed services and cloud computing: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services.</p>
<p>The problem is, in order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provide these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.</p>
<p>OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.).</p>
<p>For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service. Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.</p></blockquote>
<p>The <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">new draft</a> represents a yearlong <a href="http://www.ietf.org/mail-archive/web/oauth/current/maillist.html">discussion</a> around <a href="http://hueniverse.com/2009/11/planning-for-oauth-2-0/">goals and requirements</a> for the protocol with participants from a wide range of companies including Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google. OAuth has long been the poster-child of rapid open technology adoption, and 2.0 is no exception – Facebook and Twitter already announced support even before the first draft was officially published.</p>
<h3>Why a New Version?</h3>
<p>OAuth 1.0 was largely based on two existing proprietary protocols: Flickr’s API Auth and Google’s AuthSub. The result represented the best solution based on actual implementation experience. With over 3 years of experience working with the protocol, the community learned enough to rethink and improve the protocol in three main areas where OAuth 1.0 proved limited or confusing:</p>
<h4>Authentication and Signatures</h4>
<p>The majority of failed OAuth 1.0 implementation attempts are caused by the complexity of the cryptographic requirements of the specification. The fact that the original specification was poorly written didn’t help, but even with the newly published <a href="http://tools.ietf.org/html/rfc5849">RFC 5849</a>, OAuth 1.0 is still not trivial to use on the client side. The convenient and ease offered by simply using passwords is sorely missing in OAuth.</p>
<p>For example, developers can quickly write Twitter scripts to do useful things by using their username and password. With the move to OAuth, these developers are now forced to find, install, and configure libraries in order to accomplish what was before possible with a single line of <a href="http://curl.haxx.se/">cURL</a> script.</p>
<h4>User Experience and Alternative Token Issuance Options</h4>
<p>OAuth includes two main parts: obtaining a token by asking the user to grant access, and using tokens to access protected resources. The methods for obtaining an access token are called <strong>flows</strong>. OAuth 1.0 started out with 3 flows: web-based applications, desktop clients, and mobile or limited devices. However, as the specification evolved, the three flows were merged into one which (on paper) enabled all three client types. In practice, the flow works fine for web-based applications but provides an inferior experience elsewhere.</p>
<p>As more sites started using OAuth, especially Twitter, developers realized that the single flow offered by OAuth was <a href="http://hueniverse.com/2009/02/beyond-the-oauth-web-redirection-flow/">very limited and often produced poor user experiences</a>. On the other hand, Facebook Connect offered a richer set of flows suitable for web applications, mobile devices, and game consoles.</p>
<h4>Performance at Scale</h4>
<p>As large providers started using OAuth, the community realized that the protocol does not scale well. It requires state management across different steps, temporary credentials which are more often than not discarded unused, and typically requires issuing long lasting credentials which are less secure and harder to manage (and synchronize across data centers).</p>
<p>In addition, OAuth 1.0 requires that the protected resources endpoints have access to the client credentials in order to validate the request. This breaks the typical architecture of most large providers in which a centralized authorization server is used for issuing credentials, and a separate server is used for API calls. OAuth 1.0 requires the use of both set of credentials: the client credentials and the token credentials which makes this separation very hard.</p>
<h3>So What’s New?</h3>
<p>The following is a subset of the new features available in OAuth 2.0:</p>
<h4>6 New Flows</h4>
<ul>
<li><strong>User-Agent Flow</strong> – for clients running inside a user-agent (typically a web browser).</li>
<li><strong>Web Server Flow</strong> – for clients that are part of a web server application, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0.</li>
<li><strong>Device Flow</strong> – suitable for clients executing on limited devices, but where the end-user has separate access to a browser on another computer or device.</li>
<li><strong>Username and Password Flow</strong> – used in cases where the user trusts the client to handle its credentials but it is still undesirable for the client to store the user’s username and password. This flow is only suitable when there is a high degree of trust between the user and the client.</li>
<li><strong>Client Credentials Flow</strong> – the client uses its credentials to obtain an access token. This flow supports what is known as the 2-legged scenario.</li>
<li><strong>Assertion Flow</strong> – the client presents an assertion such as a SAML assertion to the authorization server in exchange for an access token.</li>
</ul>
<p>Native application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.</p>
<h4>Bearer tokens</h4>
<p>OAuth 2.0 provides a cryptography-free option for authentication which is based on existing cookie authentication architecture. Instead of sending signed requests using HMAC and token secrets, the token itself is used as a secret sent over HTTPS. This allows making API calls using cURL and other simple scripting tools without having to canonicalize the request and sign it.</p>
<h4>Simplified signatures</h4>
<p>Signature support has been significantly simplified to remove the need for special parsing, encoding, and sorting of parameters. It also uses a single secret instead of two.</p>
<h4>Short-lived tokens with Long-lived authorizations</h4>
<p>Instead of issuing a long lasting token (typically good for a year or unlimited lifetime), the server can issues a short-lived access token and a long lived refresh token. This allows clienta to obtain a new access token without having to involve the user again, but keeps access tokens limited. This feature was adopted from Yahoo!’s BBAuth protocol and later its OAuth 1.0 Session Extension.</p>
<h4>Separation of Roles</h4>
<p>OAuth 2.0 separates the role of the authorization server responsible for obtaining user authorization and issuing tokens from that of the resource server handling API calls.</p>
<h3>When is it coming out?</h3>
<p>OAuth 2.0 is currently in development by the <a href="http://tools.ietf.org/wg/oauth/">IETF OAuth Working Group</a>. The <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">latest draft</a> is considered stable but with many features being changed or added. Partial support is already available from Facebook and Twitter. The final specification is expected by the end of the year.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/tcIZROyNnNs" height="1" width="1"/>14http://hueniverse.com/2010/05/introducing-oauth-2-0/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[JRD, the Other Resource Descriptor]]>http://hueniverse.com/?p=12822010-05-24T23:21:54Z2010-05-14T07:39:55Z<p><a href="http://hueniverse.com/wp-content/uploads/2010/05/jrd.png"><img class="alignright size-full wp-image-1294" title="jrd" src="http://hueniverse.com/wp-content/uploads/2010/05/jrd.png" alt="" width="253" height="85" /></a>(Yes, that was a <a href="http://tools.ietf.org/html/draft-hammer-discovery">LRDD</a>-inspired pun.)</p>
<p><a href="http://hueniverse.com/xrd/">XRD 1.0</a> is the result of 5 years of community development and actual deployment experience. It represents the most concise, yet extensible way to describe web resources using well understood constructs such as links. It uses XML as its extensible backbone, enabling protocols to extend pretty much every element as needed. For a long time, XML was the source of XRD’s (and its predecessor, XRDS’s) extensibility.<span id="more-1282"></span></p>
<p>But XML is no longer what puts the ‘X’ in XRD. XRD utilizes the <a href="http://tools.ietf.org/html/draft-nottingham-http-link-header">Web Linking</a> framework for accomplishing cross-format interoperability of link relation types, as well as URI-namespaced key-value properties (for both the resource properties and links). XRD 1.0 is extensible without having to define new elements or attributes. It is accomplished simply by using its <Link> and <Property> elements as-is.</p>
<p>There might be cases where protocols will want to extend the schema, and that is where the XML foundation comes in handy. In addition, XML provides a mechanism for digital signature (which has as many critics as fans), and a clean way to add new elements without name collisions.</p>
<p>However, XML is a heavy format, and is no longer the format of choice in many new web protocols. <a href="http://json.org/">JSON</a>, a simple but powerful serialization format is getting more and more popular. OAuth 2.0 is likely to support JSON, following its adoption by popular services such as Twitter and Facebook as the default format of their APIs.</p>
<h3>Introducing JRD</h3>
<p>JRD, pronounced “Jared” and stands for JSON Resource Descriptor, is a JSON-formatted XRD document. It takes the XRD schema and converts it to a JSON structure, giving up some XML-based features, but gaining simplicity and adaptability to JSON-centric protocols and applications. JRD is based on a few simple rules:</p>
<ul>
<li>XRD is the canonical representation; JRD is meant as an alternative format offered in addition to XRD.</li>
<li>JRD does not include support for new extension objects (XRD elements); it is meant for cases where the core XRD elements are sufficient.</li>
<li>XRD can be converted to JRD; a lossless conversion of JRD back to XRD is not always possible.</li>
<li>Obtaining JRD is designed as a special case request for an XRD using the HTTP Accept header or format request parameter; JRD is available where XRD is available.</li>
</ul>
<p>In other words, services should continue using XRD as the primary format for their descriptor documents, and XRD should remain the default format for resource descriptors using the XRD schema. However, services may also support obtaining a JRD version of the document by allowing clients to specify a preference for JSON instead.</p>
<p>JRD supports the following XRD elements: <Subject>, <Alias>, <Expires>, <Property>, <Link>, and <Title>, as well as the attributes of the <Link>, <Property>, and <Title> elements. It does not support digital signatures.</p>
<p>Since nothing explains formats better than examples, the following fully-featured XRD document:</p>
<pre class="brush: xml;">
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://blog.example.com/article/id/314</Subject>
<Expires>2010-01-30T09:30:00Z</Expires>
<Alias>http://blog.example.com/cool_new_thing</Alias>
<Property type='http://blgx.example.net/ns/version'>1.2</Property>
<Property type='http://blgx.example.net/ns/ext' />
<Link rel='author' type='text/html'
href='http://blog.example.com/author/steve'>
<Title>About the Author</Title>
<Title xml:lang='en-us'>Author Information</Title>
<Property type='http://example.com/author/role'>editor</Property>
</Link>
<Link rel='author' href='http://example.com/author/john'>
<Title>The other guy</Title>
</Link>
<Link rel='copyright' href='http://example.com/copyright' />
</XRD>
</pre>
<p>Is represented by the following JRD document:</p>
<pre class="brush: jscript;">
{
"subject":"http://blog.example.com/article/id/314",
"expires":"2010-01-30T09:30:00Z",
"aliases":
[
"http://blog.example.com/cool_new_thing"
],
"properties":
{
"http://blgx.example.net/ns/version":"1.2",
"http://blgx.example.net/ns/ext":null
},
"links":
{
"author":
[
{
"type":"text/html",
"href":"http://blog.example.com/author/steve",
"title":"About the Author",
"titles":
{
"en-us":"Author Information"
},
"properties":
{
"http://example.com/author/role":"editor"
}
},
{
"href":"http://example.com/author/john",
"title":"The other guy"
}
],
"copyright":
[
{
"href":"http://example.com/copyright"
}
]
}
}
</pre>
<p>JRD does not support extension XRD elements or attributes. Future specification with use cases for extending JRD can define how to avoid name collisions (such as using a public wiki, registry, or namespaces).</p>
<h3>Obtaining a JRD Document</h3>
<p>In general, endpoints should not return a JRD representation by default. They should return an XRD document. Clients looking for a JRD representation make their preference known by using the HTTP ‘<strong>Accept</strong>‘ header with the ‘<strong>application/xrd+json</strong>‘ media type, or include the ‘<strong>format</strong>‘ parameter with a value of ‘<strong>json</strong>‘ in the request (or both).</p>
<p>For example, requesting a host-meta using JRD:</p>
<pre class="brush: xml;">
> GET /.well-known/host-meta?format=json HTTP/1.1
> Host: example.com
> Accept: application/xrd+json
</pre>
<h3>Updates</h3>
<p>5/24: Removed extensibility, changed array names to plural, turned links into a hashed list using rel values. Added title and titles object for the simple and complex use cases. Changed mime type to application/xrd+json.</p>
<p>5/14: Changed ‘namespace’ to ‘ns’ and ‘title’, ‘ns’, and ‘properties’ from array of objects to an object.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/byLljp_5Qis" height="1" width="1"/>21http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[The Light at the End of the Discovery Tunnel]]>http://hueniverse.com/?p=12752010-05-12T07:08:22Z2010-05-12T07:04:40Z<p><a href="http://hueniverse.com/wp-content/uploads/2009/11/Hammer-Stack.png"><img class="alignright size-full wp-image-858" style="margin-left: 10px; margin-right: 10px;" title="Hammer Stack" src="http://hueniverse.com/wp-content/uploads/2009/11/Hammer-Stack.png" alt="" width="194" height="189" /></a>After almost three years working on various <a href="http://hueniverse.com/discovery/">discovery</a> proposals, I’m finally starting to see the light at the end of the tunnel. While slow, good progress is being made and the drafts are reaching maturity and gaining popularity.</p>
<p>Just a quick update on the status of the various parts of the discovery stack (aka <a href="http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux/"><em>The Hammer Stack</em></a>):</p>
<ul>
<li>What <a href="http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/">started as site-meta and changed into Well-known URIs</a> is now <a href="http://hueniverse.com/2010/04/rfc-5785-defining-well-known-uris/">RFC 5785</a>.</li>
<li><a href="http://tools.ietf.org/html/draft-nottingham-http-link-header">Web Linking</a>, the heart of the entire discovery stack was finally approved for RFC publication with a new registry for link relation types coming shortly.</li>
<li><a href="http://hueniverse.com/xrd/">XRD 1.0</a> concluded its second public review with no material changes and is moving to Committee Standard next week.</li>
<li><a href="http://tools.ietf.org/html/draft-hammer-hostmeta">host-meta</a> is under review by the IETF Applications area director and pending IETF Last-Call.</li>
<li>New draft available for <a href="http://tools.ietf.org/html/draft-hammer-discovery">LRDD</a> – the top-most component of the discovery stack where everything comes together into a single discovery flow. The new draft incorporates all the feedback received (mostly editorial), and is hopefully ready for last-call in a week or so.</li>
<li>First draft of the <a href="http://hueniverse.com/2009/08/making-the-case-for-a-new-acct-uri-scheme/">‘acct’ URI</a> specification (as used by the <a href="http://hueniverse.com/2009/09/implementing-webfinger/">WebFinger protocol</a>) is due shortly.</li>
</ul>
<p>If you care about any of this, it is critical to review the <a href="http://tools.ietf.org/html/draft-hammer-hostmeta">host-meta</a> and <a href="http://tools.ietf.org/html/draft-hammer-discovery">LRDD</a> documents. They are both short and include plenty of detailed examples. Feedback would be greatly appreciated on the <a href="https://www.ietf.org/mailman/listinfo/apps-discuss">Apps Discuss list</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/A1RLpXHBiIw" height="1" width="1"/>3http://hueniverse.com/2010/05/the-light-at-the-end-of-the-discovery-tunnel/Anthony Bryanhttp://metalinker.org<![CDATA[Metalink/HTTP]]>http://hueniverse.com/?p=12722010-05-12T06:54:19Z2010-05-11T17:36:37Z<p><a href="http://www.metalinker.org/"></a><a href="http://hueniverse.com/wp-content/uploads/2009/11/Metalink.png"><img class="size-full wp-image-982 alignright" style="border: 0pt none; margin: 10px;" title="Metalink" src="http://hueniverse.com/wp-content/uploads/2009/11/Metalink.png" alt="" width="185" height="57" /></a>Metalink is an <a href="http://hueniverse.com/2009/12/introducing-metalink/">XML format for describing downloads</a>. Publishers pack information about a download into a Metalink XML file, such as mirrors and checksums, to overcome many common download problems like a server going down or file corruption. Other useful information can be included as well.</p>
<p><strong>Metalink/HTTP</strong>, or mirrors & hashes in HTTP Headers, is another way currently being developed to improve the download situation. It relies on <a href="http://tools.ietf.org/html/draft-nottingham-http-link-header">Web Linking</a> (recently approved for RFC publication as a proposed standard) for mirrors and Instance Digests (<a href="http://tools.ietf.org/html/rfc3230">RFC 3230</a>) for cryptographic hashes.<span id="more-1272"></span></p>
<p>The nice thing is that it relies on existing standards (using a newly proposed “duplicate” relation type) with the addition of <a href="http://tools.ietf.org/html/draft-bryan-ftp-hash">FTP HASH</a> – a way to request the hash of a file over FTP.</p>
<p>Metalink/HTTP can use Metalink/XML too, for certain features like partial file hashes that would be too verbose over HTTP headers. At this stage, Metalink/HTTP only has a few implementations, but existing Metalink/XML clients can be converted to support it quickly.</p>
<p>Metalink/HTTP clients begin a download with a standard HTTP GET request to the Metalink server. Alternatively, they can use a HEAD request to the Metalink server to discover mirrors via Link headers. After that, the client follows with a GET request to the desired mirrors.</p>
<pre class="brush: xml;">
> GET /distribution/example.ext HTTP/1.1
> Host: www.example.com
</pre>
<p>The Metalink server responds with the data and these headers:</p>
<pre class="brush: xml;">
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 14867603
< Content-Type: application/x-cd-image
< Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
< Link: <http://www2.example.com/example.ext>; rel="duplicate" pref=1
< Link: <ftp://ftp.example.com/example.ext>; rel="duplicate"
< Link: <http://example.com/example.ext.torrent>; rel="describedby"; type="application/x-bittorrent"
< Link: <http://example.com/example.ext.metalink>; rel="describedby"; type="application/metalink4+xml"
< Link: <http://example.com/example.ext.asc>; rel="describedby"; type="application/pgp-signature"
< Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlODYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
</pre>
<p>From the Metalink server response the client learns some or all of the following metadata about the requested object, in addition to also starting to receive the object:</p>
<ul>
<li>File size.</li>
<li>ETag.</li>
<li> Mirror profile link, which may describe the mirror’s priority, whether it shares the ETag policy of the originating Metalink server, geographical location, and mirror depth.</li>
<li>Peer-to-peer information.</li>
<li>Metalink/XML, which can include partial file checksums to repair a file.</li>
<li>Digital signature.</li>
<li>Instance Digest, which is the whole file checksum.</li>
</ul>
<p>A client request to a mirror server, using the Range header:</p>
<pre class="brush: xml;">
> GET /example.ext HTTP/1.1
> Host: www2.example.com
> Range: bytes=7433802-
> If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
> Referer: http://www.example.com/distribution/example.ext
</pre>
<p>The mirror servers respond with a 206 Partial Content HTTP status code and appropriate “Content-Length” and “Content Range” header fields. The mirror server response, with data, to the above request:</p>
<pre class="brush: xml;">
< HTTP/1.1 206 Partial Content
< Accept-Ranges: bytes
< Content-Length: 7433801
< Content-Range: bytes 7433802-14867602/14867603
< Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
< Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlODYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
</pre>
<p>Partial file checksums are especially useful for large files. HTTP mirrors can be coordinated, meaning they share the same ETag policy which allows for early detection of file mismatches.</p>
<p>One of the nice things about Metalink/HTTP is that there is no dependency on XML, unless you want partial file hashes. Drawbacks include requiring changes to server software, where the XML version can even be created by users and requires no server side changes.</p>
<p>Metalink/HTTP is also bound to HTTP, where FTP or P2P clients won’t be using it unless they also support HTTP, unlike Metalink/XML.</p>
<p>We’ve been working on Metalink/HTTP for about 7 months and it’s still experimental, so if you have any ideas or comments then <a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">help us make it better</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/EpSEKkILdYk" height="1" width="1"/>0http://hueniverse.com/2010/05/metalinkhttp/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[RFC 5785: Defining Well-Known URIs]]>http://hueniverse.com/?p=12692010-04-06T22:49:41Z2010-04-06T22:49:41Z<p>This first piece of the discovery stack was published today as an RFC. <a href="http://tools.ietf.org/html/rfc5785">RFC 5785</a> defines a registry for new well-known URIs which will provide a standard location for the <a href="http://tools.ietf.org/html/draft-hammer-hostmeta">host-meta</a> document. This work started a year and a half ago as a well-known document called /site-meta, and slowly <a href="http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/">evolved into a simple registry</a>. While this isn’t a breakthrough idea, it does codify existing behavior and hopefully encourages people to share ideas, discuss proposals, and reusing existing well-known URIs.</p>
<p>Many thanks to my co-author <a href="http://www.mnot.net">Mark Nottingham</a> for got this ball rolling.<span id="more-1269"></span></p>
<p>From <a href="http://tools.ietf.org/html/rfc5785">RFC 5785</a>:</p>
<blockquote><p>It is increasingly common for Web-based protocols to require the discovery of policy or other information about a host (“site-wide metadata”) before making a request. For example, the Robots Exclusion Protocol specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences tells user-agents how to discover privacy policy beforehand.</p>
<p>While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV’s PROPFIND), the perceived overhead (either in terms of client-perceived latency and/or deployment difficulties) associated with them often precludes their use in these scenarios.</p>
<p>When this happens, it is common to designate a “well-known location” for such data, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated “well-known locations” and with pre-existing resources.</p>
<p>To address this, this memo defines a path prefix in HTTP(S) URIs for these “well-known locations”, “/.well-known/”. Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites’ URI space.</p></blockquote>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/britQhbVocE" height="1" width="1"/>1http://hueniverse.com/2010/04/rfc-5785-defining-well-known-uris/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Open Questions About OAuth 2.0 Authentication]]>http://hueniverse.com/?p=12652010-01-15T05:49:37Z2010-01-15T05:49:37Z<p>In an effort to resume work on the <a href="http://hueniverse.com/2009/11/planning-for-oauth-2-0/">OAuth 2.0 protocol</a> at the <a href="http://tools.ietf.org/wg/oauth/">IETF OAuth Working Group</a>, I posed three questions about the authentication half of the protocol. From my perspective as the specification editor, these questions are the main open issues currently standing between us and a draft covering the authentication process in OAuth 2.0 (of course, being an IETF effort, I might be completely off base).</p>
<p>Below are the questions with their explanations, as well as my personal views after each question.<span id="more-1265"></span></p>
<h3>1. Should OAuth 2.0 Require HTTPS for Any Unsigned Request?</h3>
<p><a href="http://hueniverse.com/2010/01/whats-going-on-with-oauth/">WRAP</a> got <a href="http://benlog.com/articles/2009/12/22/its-a-wrap/">some</a> <a href="http://www.links.org/?p=833">negative</a> <a href="http://www.links.org/?p=846">attention</a> because of how it sends requests without using signatures or over a secure channel. WRAP uses HTTPS only for obtaining tokens but does not mandate (or even suggests) using HTTPS for making protected resources requests. Instead, WRAP recommends short lived tokens that must be refreshed (using HTTPS). In other words, WRAP uses secrets that are easy to steal, but which are good for a short period of time, limiting their damage.</p>
<p>In a <a href="http://www.ietf.org/mail-archive/web/oauth/current/msg00951.html">recent thread</a> on the OAuth WG list, we reach a (low participation) consensus that the <strong>OAuth 1.0 protocol should be changed in the RFC draft to mandate HTTPS (or others technologies offing the same or greater protection) for the PLAINTEXT method and when requesting token credentials</strong>. The original community edition only <strong>recommends</strong> using HTTPS, but every implementation (known to me) requires HTTPS.</p>
<p><em>Are there any valid reasons (such that will pass IETF security review scrutiny) for allowing unsigned requests to be sent in the clear over an insecure channel? Are there real use cases for this kind of insecure flavor (not just speculations but actual services which we can point to)?</em></p>
<blockquote><p><span>Yes, OAuth 2.0 must require the use of a secure channel when making unsigned requests. I understand that some providers will not want to bother with the extra security for cost of performance reasons. I am willing to assume they are doing this fully aware of the repercussions of their actions. What I don’t understand is why should the protocol – which is aimed at interoperability – bother with it?</span></p>
<p>The working group includes people representing many companies, large and small. Can one of them please raise their hand and ask for this feature? And if they do, can they explain how they justify providing poor security to their developers?</p>
<p>I am no longer interested in the argument that somewhere there are valid use cases. Writing a protocol for scenarios that are not anchored in reality is bad. OAuth 1.0 does not require using a secure channel for sending token secrets because people claimed it will be a problem for some providers. So far, no such providers showed up.</p>
<p>If someone wants to argue the need of no-cryptography / no-secure-channel option, while showing how that need justifies subjecting the web to more bad protocols and poor foresight, I am eager to listen.</p>
<p>If a provider doesn’t care about security, it is free to implement the protocol poorly. There is no OAuth Police to force providers to check signatures and reject requests with bad ones. By forcing such providers to break the protocol, we are forcing them to make an explicit decision and we get their developers to notice.</p>
<p>There is also a case to be made about pushing the envelope when it comes to security. The more services use TLS, the cheaper and easier it will get. That’s economics 101. And unlike writing new code for new OAuth signatures, requiring TLS will simply mean linking another library and making a function call.</p>
<p>My vote is to start with an HTTPS requirement for any unsigned request, and let those who have real reasons to object show up. None of the current users of OAuth 1.0 will be able to claim this since they all use HTTPS for all such requests.</p></blockquote>
<h3>2. What to Sign?</h3>
<p>The <a href="http://oauth.net/core/1.0a">community edition</a> of the OAuth Core 1.0 protocol was designed to sign <strong>API requests</strong> which use common form-encoded parameters (in the URI or body). The main component of the 1.0 signature base string are the parameters. The host and HTTP methods are important but were never the focus on the signed content.</p>
<p>The new <a href="http://tools.ietf.org/html/draft-hammer-oauth">OAuth 1.0 RFC draft</a> does not change the process but does describe it very differently, changing the focus form signing API requests and parameters to <strong>signing HTTP requests</strong> (partially). The new <a href="http://tools.ietf.org/html/draft-hammer-http-token-auth">Token Authentication draft</a> (which is proposed as the basis for half of OAuth 2.0) takes this approach a step further and focuses on signing the <strong>raw HTTP request</strong> components, completely ignoring their meaning as used by API calls.</p>
<p>The end result is very similar but the differences are important.</p>
<p>Last month Brian Eaton – a WRAP co-author and a long time OAuth contributor working for Google – <a href="http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html">proposed an alternative approach</a> in which a message is signed instead of the API call or HTTP request. In his proposal, the HTTP request (or API call, whatever your perspective) is transformed into a message (Eaton’s proposal uses a JSON-based format) which is then signed. This additional layer of abstraction allows using the method with other transports, or in use cases in which parameters are not part of the request URI or body.</p>
<p><em>(Ignoring the details and proposed format of the message,) which style should OAuth 2.0 use?</em></p>
<ul>
<li><em>Process the HTTP request into a base string for signing (OAuth RFC draft style),</em></li>
<li> <em>Treat the request as an API call with form-encoded parameters (OAuth 1.0 community edition style), or</em></li>
<li><em>Convert the request into a normalized message and sign it (Eaton style).</em></li>
</ul>
<blockquote><p>Given the interest in using OAuth with XMPP, SIP, and other protocol, I think there is great value in introducing a simple process for converting the request into a message, and then signing that message. The part of the proposal I am not yet sold on is the added complexity of using JSON and the multi-tier structure.</p></blockquote>
<h3>3. Should the Normalized Request String Get Sent with the Request?</h3>
<p>In OAuth 1.0 the request is normalized into the signature base string by the client and the server independently. The base string itself is never sent with the request. In his <a href="http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html">outline</a>, Eaton proposed to include the signed string (message) with the request, removing the need for the server to regenerate the normalized string. It also allows the client to use the included string to send additional (signed) information that is not part of the HTTP request.</p>
<p>This is a significant departure from OAuth 1.0, but one that deserves an in-depth discussion.</p>
<p>Some advantages to this approach are:</p>
<ul>
<li>The server can easily verify what is being signed</li>
<li>The client can include additional parameters in the signed message</li>
<li>The request remains valid even if changed by proxies or other intermediaries</li>
</ul>
<p>Some disadvantages are:</p>
<ul>
<li>The request is sent twice, once raw and once normalized</li>
<li>It adds another place to make mistakes and create security holes if the server uses the raw data without fully comparing it to the normalized (signed) data</li>
<li>Since any server enforcing security will only use the data contained in the normalized portion, it will create a de-facto standard for API requests (not nearly as heavy as SOAP or WS-*, but) in which case the request itself is normalized before sending.</li>
</ul>
<p><em>What are some other advantaged and disadvantages to this approach? Should the normalized string be included with the request or even replace it?</em></p>
<blockquote><p>Unless someone raises some additional advantages, I can’t see how this makes sense. The request itself is what matters.</p></blockquote>
<p>Got answers? Please <a href="https://www.ietf.org/mailman/listinfo/oauth">join the conversation</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/yxxRHCoZna0" height="1" width="1"/>5http://hueniverse.com/2010/01/open-questions-about-oauth-2-0-authentication/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[What’s going on with OAuth?]]>http://hueniverse.com/?p=12622010-01-08T17:17:35Z2010-01-08T17:17:35Z<p><em>This post was written as a collaboration between <a href="http://factoryjoe.com/">Chris Messina</a> (Google), <a href="http://twitter.com/DickHardt">Dick Hardt</a> (Microsoft), <a href="http://davidrecordon.com/">David Recordon</a> (Facebook), and I, and was <a href="http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html">originally published on O’Reilly Radar</a>.<br />
</em></p>
<p><img style="float: right; margin-left: 15px;" src="http://radar.oreilly.com/2010/01/07/OAuth-Shine-200.jpg" alt="" /></p>
<p>The OAuth protocol and community have <a href="http://hueniverse.com/2009/11/wrap-and-the-demise-of-the-oauth-community/">seen a lot of changes</a> over the past couple of years. With the recent introduction of WRAP, the IETF working group, and discussions about OAuth 2.0, many developers were <a href="http://www.scripting.com/stories/2010/01/01/oauthIsBecomingACautionary.html">left confused</a> as to what was going on.</p>
<p>The OAuth protocol enables users to provide third-party access to their web resources without sharing their passwords; kind of like a valet key for the web. To date, OAuth 1.0a is the most successful such protocol deployed on the web. The <a href="http://hueniverse.com/oauth/guide/history/">origins of OAuth</a> date back to late 2006, when a small group of web engineers, tired of reinventing the API authorization wheel, came together to find a common, open solution.<span id="more-1262"></span>The protocol was derived from several existing API authorization protocols, including AOL, Flickr, Google, Microsoft, and Yahoo!. By developing a unified approach to API authorization, the goal was to reduce the burden of implementing any one of these protocols, and provide third party applications a more convenient and secure way to access user data. It is also well-established that security protocols are hard and often suffer from potential exploits. By focusing on an single, open protocol, the community could reduce the likelihood of an attack and respond faster when one occurs.</p>
<p>In the past two years, the number of services that require users to divulge their passwords to enable third-party access — the so-called <a href="http://adactio.com/journal/1357"><em>password anti-pattern</em></a> — has decreased dramatically. Today the most well-known and used deployment of OAuth 1.0a is the <a href="http://apiwiki.twitter.com/Authentication">Twitter’s API</a>. (If you’re interested in a more detailed explanation of OAuth, check out <a href="http://hueniverse.com/oauth/guide/">The Authoritative Guide to OAuth 1.0</a>.)</p>
<p>Last year <a href="http://www.ietf.org/dyn/wg/charter/oauth-charter.html">OAuth transitioned to the IETF as a new Working Group</a> to produce version 1.1 which would be suitable for publication as an <a href="http://en.wikipedia.org/wiki/Internet_standard">Internet Standard</a>. The working group was tasked with reviewing the security and interoperability properties of the protocol, while maintaining as much backwards-compatibility as possible. As is sometimes the case in such efforts, there was little interest among the community in such a minor cleanup.</p>
<h3>Introducing WRAP</h3>
<p>At the same time, new use cases emerged as well as a significant amount of hands-on experience about the shortcomings and gaps in the 1.0a version of the protocol. A small group of developers herded by Dick Hardt started work on simplifying the protocol, inspired by the <a href="http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html">OAuth Session Extension</a> proposed by Yahoo!. Originally dubbed “Simple OAuth”, it was later renamed to WRAP (Web Resource Authorization Protocol) to reflect the fact that it is a different protocol. It is now known as <a href="https://oauth.pbworks.com/OAuth-WRAP">OAuth WRAP</a>.</p>
<p>WRAP attempts to simplify the OAuth protocol, primarily by dropping the signatures, and replacing them with a requirement to acquire short lived tokens over SSL. It is not an even trade-off, and the new proposal has a different set of security characteristics, benefits, and shortcomings.</p>
<p>In 2007 when OAuth 1.0 was being created, SSL was used sparingly for APIs. As CPUs have become faster and more specialized SSL hardware has been deployed, it has become increasingly possible to operate APIs over SSL. Some APIs, like the <a href="http://code.google.com/apis/health/docs/2.0/developers_guide_protocol.html">Google Health Data API</a> or Yahoo!’s <a href="http://fireeagle.yahoo.net/developer/documentation/calling_the_api">Fire Eagle API</a>, operate fully over SSL anyway as developers are interacting with non-public data. Using SSL obviates the primary purpose of the cryptography used in OAuth 1.0a, which was designed for transferring data over insecure channels.</p>
<p>WRAP addresses two areas in which the 1.0a protocol is lacking: it offers new ways to obtain tokens, and it evolves the architecture to enable other roles to issue tokens (other than the server). OAuth 1.0a offers a single browser-based redirection flow used to send the user from the application to the server, obtain approval, and return to the application.</p>
<p>WRAP adds a few new flows for obtaining authorization and tokens mainly designed around providing better experiences on devices such as your XBox, desktop applications like TweetDeck, or fully JavaScript based implementations like Facebook Connect. And unlike 1.0a where the server issues and verifies every token, the tokens in OAuth WRAP are short lived and can represent claims issued by an authorization server, providing scale and security benefits for large operators.</p>
<p>Judging by the original “Simple OAuth” moniker, the goal behind WRAP was not to confuse developers or compete with OAuth. The intention, rather, was to promote OAuth and increase long term adoption by offering an SSL variant. Therefore, if you’re building a new API today and are trying to decide between deploying OAuth 1.0a or OAuth WRAP, nine times out of ten you should <strong>continue deploying OAuth 1.0a</strong>. But start experimenting with WRAP when its features are important to you and you are comfortable making changes as it evolves.</p>
<h3>Building OAuth 2.0</h3>
<p>WRAP brought the use cases and experiences that inspired it to the attention of the IETF working group. The consensus is that we now have enough implementation experience and new requirements to begin work on OAuth 2.0, instead of a minor revision. OAuth 2.0 will likely contain two parts, one defining an authentication scheme for accessing resources using tokens, and the second defining a rich set of authorization schemes for obtaining such tokens. By separating the two parts, we will be able to provide the right level of abstraction and modularity to support both the SSL-based approach taken by WRAP as well as the existing signature-based approach taken by 1.0a.</p>
<p>In many ways, OAuth 2.0 will be the result of combining the best ideas from both protocols. The authentication part will built on top of 1.0a while the authorization part will build on top of WRAP. It is important to remember that it is very early in the process, and that all these decision will be made by the members of the IETF OAuth working group. In other words, by those who show up. The goal is to have a set of stable drafts for OAuth 2.0 by the upcoming IETF OAuth Working Group meeting in March at the <a href="http://www.ietf.org/meeting/upcoming.html">77th IETF meeting</a>.</p>
<p>For those implementing OAuth 1.0a today, a new edition has been published as an <a href="http://tools.ietf.org/html/draft-hammer-oauth">RFC draft</a> which was accepted by the community as a replacement for the original 1.0a specification. This new specification does not change the protocol, but is more readable, includes many clarifications, errata, and examples, and thus easier to implement.</p>
<p>If you’re interested in keeping track of what’s going on with OAuth, <a href="http://hueniverse.com/oauth/">Hueinverse’s OAuth page</a> is a great place to watch. To get involved and take part in this important work, dig into the <a href="https://www.ietf.org/mailman/listinfo/oauth">IETF OAuth Working Group</a> and <a href="http://groups.google.com/group/oauth-wrap-wg">WRAP discussion list</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/pbMAvmu8a7Y" height="1" width="1"/>1http://hueniverse.com/2010/01/whats-going-on-with-oauth/Christopher Carrascohttp://chriscarrasco.tripod.com/<![CDATA[Who Needs Open When You Have Twitter?]]>http://hueniverse.com/?p=12592010-01-07T22:44:29Z2010-01-07T22:44:29Z<p style="text-align: center;"><a href="http://hueniverse.com/wp-content/uploads/2010/01/Twitter-API.png"><img class="size-large wp-image-1260 aligncenter" title="Twitter API" src="http://hueniverse.com/wp-content/uploads/2010/01/Twitter-API-1024x439.png" alt="" width="617" height="264" /></a></p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/m3wXnr61yh0" height="1" width="1"/>1http://hueniverse.com/2010/01/who-needs-open-when-you-have-twitter/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[2009 Year-End Status Report]]>http://hueniverse.com/?p=12552009-12-31T08:22:39Z2009-12-31T08:22:29Z<p>We made a lot of important progress in 2009, even if it doesn’t feel like it. While there were no big new ideas, no final drafts, and very little overall progress, the progress made was still extremely valuable. It represents the maturity and stabilization of these efforts and technologies. We are getting close to the finish line of the discovery stack.</p>
<p>The following is a quick report on the status of the efforts I am involved in and what to expect in the next few months.<span id="more-1255"></span></p>
<h3>XRD</h3>
<p>The <a href="http://www.oasis-open.org/committees/download.php/35678/xrd-1.0-wd11.html">XRD 1.0 specification</a> is <strong>stable, ready for implementations</strong>, and pending final review.</p>
<p>The latest draft is Working Draft 11 which will be elevated to Committee Draft 2 shortly after the end of the public review period on January 6th, 2010. Working Draft 11 already accommodates all the changes and feedback received during the review period. It is mostly a matter of following the OASIS process at this point to get XRD 1.0 published as a standard. The next steps include publishing a second Committee Draft, a shorter public review period, and if no significant comments are received, moving forward with an OASIS standard vote.</p>
<p>The XRD schema has <a href="http://hueniverse.com/2009/11/xrd-alignment-with-link-syntax/">changed dramatically</a> between Committee Draft 1 and Working Draft 11. I am not expecting any additional changes, at least not at that level. If you plan on reviewing the document, please do so before January 6th. At this point, the TC should not be accepting any new suggestions and focus on errors or problems in the specification. Any new ideas for making XRD 1.0 better would have to wait until the next version if submitted after January 6th.</p>
<h3>Defining Well-Known URIs</h3>
<p>The <a href="http://tools.ietf.org/html/draft-nottingham-site-meta">Defining Well-Known URIs</a> specification (aka /.well-known) is <strong>stable and pending publication</strong> as a Standards Track RFC, as well as the creation of an IANA registry.</p>
<p>The latest revision published December 30th, 2009 includes minor clarifications to resolve feedback received from the IESG, the IETF technical governing body. The draft should resolve all the pending issues and should move to publication shortly after the New Year.</p>
<p>This draft went through a year-long journey, starting from a document called site-meta and ending with a URI path prefix and registry. This short and simple specification represents a significant shift in how Web applications are going to be designed, and how the URI namespace is treated.</p>
<h3>Host-Meta: Web Host Metadata</h3>
<p>The <a href="http://tools.ietf.org/html/draft-hammer-hostmeta">host-meta</a> specification is <strong>stable and ready for implementations</strong>, but <strong>missing functionality</strong>.</p>
<p>Host-meta adds very little on top of XRD and Well-Known. The host-meta draft should be considered stable and is not likely to change. The protocol is still missing a trust profile – a workflow used to sign and verify the authenticity of a host-meta document – which will be either published separately or in the same specification.</p>
<p>While the current draft should be considered final (except for the missing feature), it can still change to accommodate trust requirements or feedback received during the normal IETF review process.</p>
<p>Host-meta is expected to move into IETF Last-Call by the end of Q1 2010 and published (if approved) by the end of Q2 2010.</p>
<h3>LRDD</h3>
<p>The LRDD specification is <strong>obsolete and not ready for implementations</strong>, pending a new draft.</p>
<p>After a long review period and many discussions, the LRDD specification is going to be transformed into a narrow, well-defined process for obtaining links. With the latest round of changes to the <a href="http://tools.ietf.org/html/draft-nottingham-http-link-header">Web Linking draft</a>, LRDD is going to register a new protocol-specific link relation type ‘<strong>lrdd</strong>‘ which will link to “The” resource XRD, or the “LRDD XRD”.</p>
<p>A <a href="http://groups.google.com/group/webfinger/browse_thread/thread/9f3d93a479e91bbf#">preview of the proposal</a> can be found on the WebFinger list. I expect a new draft published by the end of January, 2010.</p>
<h3>WebFinger</h3>
<p>The <a href="http://hueniverse.com/2009/09/implementing-webfinger/">WebFinger workflow</a> is <strong>stable, ready for implementations</strong>, pending dependencies and first draft.</p>
<p>It is still not clear what the WebFinger protocol includes, and how it will be published. As currently defined, WebFinger is not much more than a simple use case for XRD and host-meta (it is really a specialized case of LRDD, but only uses the proposed ‘<strong>lrdd</strong>‘ relation type).</p>
<p>The workflow going from an email-like identified – the <a href="http://hueniverse.com/2009/08/making-the-case-for-a-new-acct-uri-scheme/">account URI</a> – to an XRD document describing that account is stable and unlikely to change significantly. The content of the account XRD is still very much undefined. The format of the account URI is going to be based on the XMPP URI format, but is still pending a first draft.</p>
<p>It is not clear which specification is going to define WebFinger and what it will include. There is going to be a specification of the proposed account URI, and something to bring all the different parts together. A specification defining the account URI is expected by the end of February, 2010.</p>
<h3>OAuth</h3>
<p>The <a href="http://tools.ietf.org/html/draft-hammer-oauth">OAuth 1.0 Protocol RFC</a> (which can be considered as Revision B) is <strong>completed, ready for implementations</strong>, and pending IESG approval for publication as an Informational RFC.</p>
<p>The OAuth 2.0 Protocol is in its <strong>early proposal stage</strong>, but it likely to be based on the OAuth WRAP draft. I expect to have a set of stable drafts for OAuth 2.0 by the upcoming IETF OAuth Working Group meeting in March at the next <a href="http://www.ietf.org/meeting/upcoming.html">IETF meeting</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/1f7I54JB1zo" height="1" width="1"/>0http://hueniverse.com/2009/12/2009-year-end-status-report/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[On Contributions, Open Source vs. Open Standards]]>http://hueniverse.com/?p=11312009-12-24T06:52:05Z2009-12-24T06:52:05Z<p>Open Source software is one of the most important and inspiring movement in technology. It is responsible for a great deal of innovation and democratization of the internet and beyond. Open Standards on the other hand, are still very much the domain of big companies and professionals standards experts. There are plenty of good definitions for what constitutes an Open Source project, as well as plenty of well understood (or at least trusted) legal licenses available.</p>
<p>On the other hand, we are still struggling to define what an Open Standard is.<span id="more-1131"></span><br />
It is extremely tempting to bundle the Open Source and Open Standards together, even though they are two, discrete concepts. In many cases, there is a great deal of overlap between the people writing Open Source code and the people working on specifications covering the same area. Most people try to understand the standards world through their understanding of Open Source, given the human mind’s compulsory need to <a href="http://hueniverse.com/2009/11/how-we-interact-with-the-unknown/">apply known patterns to new ones</a>.</p>
<p>The problems start when we try to solve Open Standards problems with Open Source tools. On the face of it, it seems like a logical thing to do. They both need to be licensed, and both cover copyrights as well as patent rights. They are both nothing more than a set of instructions, one for machines and the other for people with the purpose of being translated to machines. In addition, many specifications include code, and some are written as pseudo-code.</p>
<p>The most important process in any open project is <strong>contributions management</strong>. From the way in which a contribution is made, through how it is discussed, approved or rejected, to how it is applied to the final product, the process dictates everything else. Any discussion about creating collaborative specifications or software must start from contributions management – otherwise, it is lacking the most important tool needed to produce a successful end result.</p>
<p>What makes the two so fundamentally different, despite their many similarities, is that Open Source contributions are pieces of code. From start to finish they maintain the same representation of machine-readable information. There are no two ways to understand what a piece of code does. Given a well-defined patent, it is possible to conclude if a piece of code infringes it or not. A code contribution is absolute – you either run it or not, it either uses a patent or not, <strong>you</strong> either contributed it or not. Any decent source control system can tell exactly were each line of code came from.</p>
<p>On the other hand, a specification contribution is almost always prose. It is an idea expressed in a human language, and as such, it is always open for interpretation. While many people can write functional code (pretty, ugly, efficient, wasteful), very few can write quality prose – prose that is likely to be understood the same way by different people, while at the same time, possess the typical properties desired in prose (elegance, efficiency, cultural sensitivity, correctness). For this reason, there are many layers of indirection between the contribution and the final result.</p>
<p>Regardless of how decisions are made about which contribution to include, the role of a specification editor is very different from the role of a software maintainer. Software changes are atomic updates, and are communicated in terms of differences from the current baseline. For many years, UNIX software updates came in the form of a diff file, applied to the kernel source code, and then compiled on each server. As long as the piece of code does what it is supposed to do and understood by a machine, it is good to go.</p>
<p>A contribution to a specification, however, is often communicated on a mailing list, a blog post, or over lunch, and id rarely applied to the specification as-is. It is the role of the editor to figure out how to accommodate the meaning of the contribution to the existing baseline. It is the role of the editor to ensure a consistent voice throughout the specification, which for code can be completely automated. And when people change words, they almost always change the meaning.</p>
<p>The nature of software contributions is what empowers Open Source, allows reusability, derivative work, incremental improvements, and large scale collaborations. Specifications, on the other hand, would be a pile of goo if directly authored by more than a handful of authors or editors.</p>
<p>Intellectual property rights and anti-trust are complicated areas and unfortunately, an integral part of everything we do. Add to that the desire for transparent government, democratic principles, and pragmatic progress, and the challenge of getting a large group of people to agree can get out of hand. The reason why every effort to change the way standards are created has reached the same conclusion and the same uninspiring, limited freedom, is because they are all based on the same primitive tools of managing contributions.</p>
<p>This must not be where our story ends.</p>
<p>The complexities of writing specifications, at least the contributions management part, should not dictate how specifications are created and used, but instead challenge us to come up with better models and tools. If we can develop new technologies and methodologies for bridging the gap between code and specifications, we will truly open the door to the freedom and democratization of ideas and innovation.</p>
<p>This is not simply a matter of making small adjustments (such as taking a mailing-list software and enhancing it to enforce CLA signatures). It requires rethinking the way in which contributions are made, discussed, and applied. Community-based software was around for a long time, but Open Source only became the force of change we know today when the models of creating it matured beyond the collaborative practices of the past.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/6iwJZJLcCUQ" height="1" width="1"/>3http://hueniverse.com/2009/12/on-contributions-open-source-vs-open-standards/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Elements of a Successful Standard Community]]>http://hueniverse.com/?p=11272009-12-22T21:07:32Z2009-12-22T21:06:26Z<p>At the last W3C meeting in Santa Clara, David Recordon gave a <a href="http://www.scribd.com/doc/24425262/Building-Social-Web-Standards-2009-W3C-Plenary">great presentation about the Open Web community</a>. He concluded (taunting the audience a bit) with a simple question: “<em>Why should Facebook join the W3C</em>,” given the progress and success made with efforts such as OAuth and OpenID.</p>
<p>David’s presentation was followed by a comment by Tim Berners-Lee. Tim’s point was that what the Open Web Foundation is trying to do now – with its very limited scope – is exactly how the W3C started. The problem was, as I have come to realize myself over the past six months, that it wasn’t enough. There is a long list of ‘stuff’ communities need in order to be successful.<span id="more-1127"></span></p>
<p>I spend most of my time as a specification developer. Almost every day I get a message asking me how come one of the specifications I am working on for more than a year is not yet finished. Two weeks ago I sent an<a href="http://hueniverse.com/2009/12/whats-in-a-name-that-which-we-call-the-open-web-foundation/"> open letter to the members of the Open Web Foundation</a>, questioning the foundation direction and accomplishments. When asked to provide more specific details about what I feel is missing, I came up with the following incomplete list.</p>
<ul>
<li><strong>Platforms </strong>- tools that integrate email, messaging, and collaborative tools with the specification development process. We need a mailing list system that manages CLA signatures. We need the source control system that is directly linked to and from email messages sent to the list with ideas and contributions. Open source is successful to a large degree because of the tools available. Until we can tell where changes to a specification come from, we are going to be stuck with a primitive IPR policy and governance models.</li>
<li><strong>Participation </strong>- it is surprisingly hard to get people to actually contribute to an open community specification. I have the benefit of comparing the quality and quantity of feedback received for my community work and my standards body work and sadly, they don’t compare. I now find myself having to beg for reviews (and still don’t get them). Asking folks at the IETF and W3C for feedback yields much better results.</li>
<li><strong>Editors </strong>- the most labor intensive part of writing a specification is writing it and editing it. For that reason (and scarcity of talent), it is very hard to find someone to edit open specifications. This is why the handful of specifications we have is largely written by the same small group of people (who are getting busier). They are also generally poorly written. We need experienced editors to help mentor new ones, and for that we need people to step up.</li>
<li><strong>Domains, websites, trademarks</strong> – someone needs to own and manage the logistics of creating public intellectual properties. I think people need to worry less about the OAuth IPR agreement, and more about who controls the ‘oauth.net’ domain. I wrote a new version of OAuth 1.0 – but who gets to decide if I can replace the existing one with this newer version? Who gets to decide if WRAP can call itself an OAuth profile?</li>
<li><strong>Open Source libraries</strong> – we are extremely poor in resources for writing quality libraries implementing these specifications. The majority of specifications do not even have a reference implementation or a comprehensive test suite. The main reason why people started working on alternative solutions to OAuth was that that the cryptography and request normalization was too hard and the libraries did a poor job.</li>
<li><strong>Chairs / leads</strong></li>
<li><strong>Governance models</strong></li>
<li><strong>Documentations and guides</strong></li>
<li><strong>Demos and experimental sites</strong></li>
</ul>
<p>I am sure there is more.</p>
<p>What specification communities need – and what existing standards bodies provide – are built-in participation, corporate by-in, editorial services, working group facilities, and legal hand-holding. The fact is that the Open Web Foundation would not exist if memberships in the W3C or OASIS were free, or without the insanely complex and insider-club nature of the IETF.</p>
<p>Some argue that protocols like <a href="http://en.wikipedia.org/wiki/PubSubHubbub">Pubsubhubbub</a> and OpenID are great examples of successful protocols created without the full support of a standards body. But these are misleading examples. OpenID has a fully-featured standards body – the OpenID Foundation, and Pubsubhubbub is directly sponsored by Google (which experience shows, is the single most important factor in producing a successful Open Web specification).</p>
<p>When we founded the Open Web Foundation, the one thing we all agreed on was that we were not creating another standards body. The foundation grew directly out of the OpenID and OpenSocial experiences. What got us here was the desire to avoid having to create these foundations for each specification.</p>
<p>What we missed was the fact that ‘these foundations’ are in fact mini standards bodies. If we are going to create something to replace ‘these foundations’, it needs to provide at least the same level of services. This might sound like I am proposing turning the Open Web Foundation into a standards body, alongside the W3C, OASIS, IETF, and others. I am not – but I am proposing a significantly different direction.</p>
<p>The obvious problem is that as long as we develop specifications the same way standards bodies do today (and we do), we are doomed to find ourselves coming back to the same problems and needs. And these needs are expensive, which is why the W3C and OASIS charge a high membership fee.</p>
<p>While the IETF is free to join, it has a pretty substantial budget from the <a href="http://www.isoc.org/">ISOC</a>, its events, and sponsorship. In addition, the IETF depends on companies employing members full time for the primary purpose of serving the organization. Ask any IETF Area Director about the amount of time, effort, and money it takes to do their job. For this reason, it has been getting harder to find qualified and available members to fill such demanding roles.</p>
<p>The Open Web Foundation is trying to solve a real problem but it is mostly using the same tools that have failed before, or leading communities in that direction. It is inevitable that these communities will find their way back into standards bodies as their participants mature, join companies who are already members of standards bodies, or find that they simply need more.</p>
<p>This will likely become a cyclical occurrence, as new generations of specification communities will go through the same process as we have. Ready for the New Open Web Foundation ten years from now?</p>
<p>Fortunately, the solution has been right under our noses this all time. We drew our inspiration from Open Source, but took the wrong part – the legal stuff. It is the process and tools that holds the real value and the key to breaking away from the broken, expensive, exclusive, and closed system we have today.</p>
<p>But that’s for another day.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/RjdBF1TT7nI" height="1" width="1"/>4http://hueniverse.com/2009/12/elements-of-a-successful-standard-community/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Sneak Peek: The Authoritative Guide to OAuth 1.0]]>http://hueniverse.com/?p=10832009-12-22T07:54:36Z2009-12-20T07:52:35Z<p>With the <a href="http://hueniverse.com/2009/12/oauth-1-0-rfc-edition/">new edition</a> and growing interest in <a href="http://hueniverse.com/oauth">OAuth</a>, it is time to revisit the old posts explaining OAuth and documenting its development. I am working on a new guide to replace the <a href="http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-i-overview/">Beginner’s guide</a> called <strong>The Authoritative Guide to OAuth 1.0</strong>. I plan to publish an expended version of it later as a book. While it is still early, I would like to give you a sneak Peek at the <a href="http://hueniverse.com/oauth/guide/history/">Protocol History</a> chapter. <a href="http://hueniverse.com/oauth/guide/">The rest of the guide</a> will show in sections over the next few weeks.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/uwVMDj84UQE" height="1" width="1"/>0http://hueniverse.com/2009/12/sneak-peek-the-authoritative-guide-to-oauth/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[What’s in a name? That which we call the Open Web Foundation]]>http://hueniverse.com/?p=10132009-12-11T03:42:01Z2009-12-11T03:35:16Z<p><strong><img class="alignleft size-full wp-image-415" style="margin: 10px;" title="OWF" src="http://hueniverse.com/wp-content/uploads/2009/09/OWF.png" alt="OWF" width="84" height="119" />This is an open letter to the members of the Open Web Foundation, posted to the <a href="http://groups.google.com/group/open-web-discuss/">open-web-discuss</a> mailing list.</strong></p>
<p>The one thing we do better than anything else is say what we are not about.</p>
<p>Over the past few months I came to the conclusion that the limited role we assigned this foundation – to produce a reusable legal framework for open specifications – does not justify the ‘Open Web Foundation’ name. In fact, it is the stuff we keep ruling out – the <a href="http://groups.google.com/group/openweb-group/web/openweb-org-proposal">proposed openweb.org advocacy site</a>, building infrastructure to host communities, or represent the Open Web community at large – which is what most people expect this organization to be about.<span id="more-1013"></span></p>
<p>I strongly believe this is one of those cases where doing little is more damaging than doing none. Having an organization called the Open Web Foundation that is doing so little to promote and develop the open web is standing in the way of motivating others to do more. Names and appearances matter.</p>
<p>A few months ago I wrote about <a href="http://groups.google.com/group/open-web-board/browse_thread/thread/d45e744d592ad3dc">setting a new course</a>. The general sentiment among the board was that we should remain focused on our initial limited objective of producing a reusable legal framework. There was little to no interest in raising funds and building a well-resourced organization that can deliver the infrastructure and support needed for end-to-end community projects.</p>
<p>At the same time, we are still being approached by other organizations to participate in the greater context of the open web, solely based on our name and perceived purpose. It is also the name that brings greater attention to what we do. Calling our license “<a href="http://openwebfoundation.org/2009/11/introducing-the-open-web-foundation-agreement.html">The Open Web Foundation Agreement</a>” makes people treat it differently than if it was called “The Open Specification Agreement”. This is like an organization called “The World Peace Foundation” produce a conflict resolution process aimed at solving fights between neighbors.</p>
<p>I am well aware of the complexity and risks involved in setting out to do much more than we are currently set to accomplish. I still believe it is well-worth it.</p>
<p>This organization was based on a reality that no longer exists. The communities we set to help are mostly gone or inactive. I am not aware of any new community-based initiatives emerging in the past 6 months.</p>
<p>At the same time, those who have been successful recently, such as the <a href="http://openid.net/government/">OpenID work with the US government</a>, demonstrate the need for a much higher level of engagement and resources. I am sure the existence of a well-established foundation helped OpenID to be taken seriously.</p>
<p>In addition, the recent experience with the OAuth brand (<a href="http://hueniverse.com/2009/11/wrap-and-the-demise-of-the-oauth-community/">as used in OAuth WRAP</a>) showed the danger in not having a well-established governance for this work. The people who created OAuth have for the most part moved on, and the lack of governance around it is now threatening its future.</p>
<p>The OAuth model (which we originally used to justify this effort), produced a successful specification in a very short period of time. However, this seems to be the exception rather than the rule. Projects like Portable Contacts and Activity Streams have been lingering for a long time without producing final specifications. They also seem to be getting traction without having a legal framework in place. What they can use is more help with editorial and publication work and resources for tools and documentation. They also need to figure out what to do with their trademarks, website ownership, and decisions about future version.</p>
<p>It is no longer clear to me that what we are trying to do is aligned with reality.</p>
<p>The <a href="http://openwebfoundation.org/legal/agreement/">OWFa</a> is an important document. I can tell you that I had multiple internal conversations at work where people suggested we used it for releasing work instead of creating our own license. Making it easier for companies to release IP under well-understood terms is a very good thing for the open web. But we don’t need a foundation with 100 members and a 9 seats board for that. The upcoming CLA work is important but is being proposed based on the state of the community a year ago.</p>
<p>Our name, missing, and actions are now out of alignment with each other and with the reality of the open web.</p>
<p>Before discussing solutions, it would be great to <a href="http://groups.google.com/group/open-web-discuss/browse_thread/thread/6b761ae869effea4">hear</a> how others feel about this.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/4Ccc1LoHYsc" height="1" width="1"/>1http://hueniverse.com/2009/12/whats-in-a-name-that-which-we-call-the-open-web-foundation/Anthony Bryanhttp://metalinker.org<![CDATA[Introducing Metalink]]>http://hueniverse.com/?p=10082009-12-24T22:59:44Z2009-12-11T01:30:12Z<p><img class="alignright size-full wp-image-982" title="Metalink" src="http://hueniverse.com/wp-content/uploads/2009/11/Metalink.png" alt="Metalink" width="249" height="77" />The majority of the time, downloads just work. Most downloads are relatively small files. But, when files are larger, you are more likely to encounter errors. Errors with large downloads can be frustrating and a waste of time. That’s even more true for areas with unreliable Internet connections, such as developing parts of the world.<span id="more-1008"></span></p>
<p>Download problems include when a server becomes overloaded, goes down, or if there are errors in transmission. Common download programs like web browsers usually don’t have the capability to recover from most errors, but external download managers do. Download managers are separate programs that your browser can pass downloads to. Download managers usually include features like making use of mirrors for fail-over or download from multiple servers.</p>
<p>Before <a href="http://www.metalinker.org/">Metalink</a>, downloading a large file like a Linux distribution (CD or DVD size) could involve copy & pasting various URLs for mirrors into your download manager. Once the download completed, you could manually checksum the file, if you had such a program, to verify that the download was not corrupted. If the download was corrupted, there were a few things power users could try, but most people had to start over from scratch.</p>
<p>With Metalink, we make this process automatic. Mirror lists, P2P sources, checksums, digital signatures, and other metadata about a download are included in an XML file which download programs can read.</p>
<p>Checksums allow errors in a file to be repaired. Other features include enhanced security, adding multiple files to a download queue, and simultaneously downloading from multiple sources, including P2P & FTP/HTTP. Clients are enabled to work their way to a successful download even under adverse circumstances. All this can be done transparently to the human user and the download is much more reliable and efficient. Most download managers support Metalink already, but if this feature is made available in browsers like <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=331979">Firefox</a> and <a href="http://code.google.com/p/chromium/issues/detail?id=1751">Chrome</a>, it will reach more people.</p>
<p>Metalinks are frequently used for large files or files stored on many mirrors. Because of this, many open source projects like cURL, OpenOffice.org, openSUSE, Fedora, Ubuntu, & others use them to turn their mirrors into a coordinated Content Distribution Network. About 50 applications support Metalinks. Package update programs like Appupdater and yum use them behind the scenes. File hosting services are starting to provide Metalinks for downloads, and search engines are starting to index them.</p>
<p>For example, The following is the Metalink document used with the Ubuntu distribution (ubuntu-9.04-alternate-amd64.iso.meta4):</p>
<pre class="brush: xml;">
<?xml version="1.0" encoding="utf-8"?>
<metalink xmlns="urn:ietf:params:xml:ns:metalink">
<file name="ubuntu-9.04-alternate-amd64.iso">
<size>732282880</size>
<publisher name="Ubuntu" url="http://www.ubuntu.com"/>
<license name="GPL" url="http://www.gnu.org/licenses/gpl.html"/>
<version>9.04</version>
<description>Ubuntu CD Image</description>
<logo>http://www.ubuntu.com/themes/ubuntu07/images/ubuntulogo.png</logo>
<os>Linux-x64</os>
<hash type="md5">3b5e9861910463374bb0d4ba9025bbb1</hash>
<metaurl type="torrent" priority="1">http://releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso.torrent</metaurl>
<url location="jp" priority="1">http://ftp.yz.yamagata-u.ac.jp/pub/linux/ubuntu/releases/9.04/ubuntu-9.04-alternate-amd64.iso</url>
<url location="de" priority="2">ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/ubuntu-releases/9.04/ubuntu-9.04-alternate-amd64.iso</url>
<url location="gb" priority="2">http://ftp.ticklers.org/releases.ubuntu.org/releases/9.04/ubuntu-9.04-alternate-amd64.iso</url>
<url location="us" priority="3">http://ubuntu.media.mit.edu/ubuntu-releases/9.04/ubuntu-9.04-alternate-amd64.iso</url>
</file>
</metalink>
</pre>
<p>Most of the elements are self explanatory: file name, file size, who published it, what license it is released under, what version, a description, a logo, what operating system, a file hash, and where the file is available (.torrent and FTP/HTTP mirrors). <url> elements contain a geographical location and priority. <metaurl> elements list metadata files, or metainfo files, like torrents, metalinks or others and have a priority attribute, that is used with <url>. In this instance, the download sources should be used in this order: Japan & torrent (if the client supports BitTorrent), Germany & Great Britain, and finally USA.</p>
<p>The Metalink project and the XML format are 4 years old. Over a year ago, we started working on an <a href="http://tools.ietf.org/html/draft-bryan-metalink">IETF Internet Draft</a> to better specify Metalink. The new XML format is an evolution of the previous one and offers all the same features. If you’re interested, please take some time to <a href="https://www.ietf.org/mailman/listinfo/apps-discuss">help us improve it</a>.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/qVZFD384j_E" height="1" width="1"/>0http://hueniverse.com/2009/12/introducing-metalink/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Authorization Miscommunication]]>http://hueniverse.com/?p=10032009-12-08T07:26:33Z2009-12-08T07:24:56Z<p><img class="aligncenter size-full wp-image-1004" title="WRAP" src="http://hueniverse.com/wp-content/uploads/2009/12/WRAP.png" alt="WRAP" width="500" height="566" /></p>
<p><span id="more-1003"></span>I drew this one all by myself! (Yes, I’ll go back to writing specifications now.)</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/8tdtw4c-Uuw" height="1" width="1"/>1http://hueniverse.com/2009/12/authorization-miscommunication/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[It’s All About the Token]]>http://hueniverse.com/?p=9972009-12-24T23:09:54Z2009-12-08T00:47:13Z<p>What will eventually become <a href="http://hueniverse.com/2009/11/planning-for-oauth-2-0/">OAuth 2.0</a> is taking a first step.</p>
<p>After a couple weeks of <a href="http://www.ietf.org/mail-archive/web/oauth/current/maillist.html">intense discussions on the OAuth WG list</a>, I pushed out a new draft defining the <a href="http://tools.ietf.org/html/draft-hammer-http-token-auth">Token Access Authentication Scheme</a>. The new scheme replaces the <a href="http://tools.ietf.org/html/draft-hammer-oauth-08#section-3">OAuth authentication scheme</a> defined in <a href="http://tools.ietf.org/html/draft-hammer-oauth">OAuth 1.0</a>, and defines instead a general purpose authentication scheme for both 2-legged and 3-legged use cases. It builds directly on the experience and ideas in OAuth 1.0 but significantly simplifies the protocol.<span id="more-997"></span></p>
<p>The new draft removes all the parameter encoding from the first version at the expense of removing support for some features. The most noticeable change is lack of specific support for query or form-encoded parameters. Query parameters are now included as part of the request URI as an opaque string. Body form-encoded parameter can be included by hashing the entire raw body.</p>
<p>Another big change is removing support for transmitting credentials using the URI query of form-encoded body parameters. The new scheme uses the <a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication framework</a> exclusively and requires the use of the HTTP Authorization header field to send authentication parameters.</p>
<p>For example:</p>
<pre class="brush: xml;">
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Token token="h480djs93hd8",
method="hmac-sha-1",
timestamp="137131200",
nonce="dj83hs9s",
auth="djosJKDKJSD8743243/jdk33klY="
</pre>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/kX9iWzC9Ink" height="1" width="1"/>4http://hueniverse.com/2009/12/its-all-about-the-token/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[OAuth 1.0 RFC Edition]]>http://hueniverse.com/?p=9942009-12-02T06:42:58Z2009-12-02T06:41:38Z<p><img class="alignright size-thumbnail wp-image-414" title="OAuth Shine" src="http://hueniverse.com/wp-content/uploads/2009/09/OAuth-Shine-150x150.png" alt="OAuth Shine" width="150" height="150" />Pending approval by the IESG, the IETF governing body which provides the final technical review of Internet standards, my <a href="http://tools.ietf.org/html/draft-hammer-oauth">OAuth Core 1.0 Rev A rewrite</a> will be published as an informational RFC. This has been a time consuming effort which focused on two goals: increase the usefulness and readability of the document (an area the <a href="http://oauth.net/core/1.0a">current specification</a> lacks significantly), and address a list of known errata that has been identified over the past two years.<span id="more-994"></span><br />
From an editorial perspective, this is a <a href="http://tools.ietf.org/html/draft-hammer-oauth">brand new specification</a>. While it details the same protocol, it does so in very different terms, narrative, and detail. The majority of the specification was written from scratch using valuable feedback I collected over the past two years from those who were kind enough to provide detailed notes (and sometimes justified rants).</p>
<p>The new edition moves OAuth closed to the HTTP transport layer, explaining how the protocol interacts with HTTP requests. It also aligns its terminology with that of HTTP, discarding much of the invented terms (e.g. Consumer Key, Request Token). And most importantly, it separates between the authentication and authorization components, placing each in a separate section.</p>
<p>But what will matter most to implementers are the protocol changes and clarifications made in the new edition. The changes are<a href="http://tools.ietf.org/html/draft-hammer-oauth-07#appendix-A"> listed in an appendix</a> but they are worth highlighting here:</p>
<ul>
<li>Adjusted nonce language to indicate it is unique per token/timestamp/client combination.</li>
<li>Removed the requirement for timestamps to be equal to or greater than the timestamp used in the previous request.</li>
<li><strong>Changed the nonce and timestamp parameters to OPTIONAL when using the PLAINTEXT signature method.</strong></li>
<li><strong>Extended signature base string coverage which includes ‘application/x-www-form-urlencoded’ entity-body parameters when the HTTP method used is other than POST and URI query parameters when the HTTP method used is other than GET.</strong></li>
<li>Incorporated corrections to the instructions in each signature method to encode the signature value before inserting it into the ‘oauth_signature’ parameter, removing errors which would have caused double-encoded values.</li>
<li><strong>Allowed omitting the ‘oauth_token’ parameter when empty.</strong></li>
<li><strong>Permitted sending requests for temporary credentials with an empty ‘oauth_token’ parameter.</strong></li>
<li>Removed the restrictions from defining additional ‘oauth_’ parameters.</li>
</ul>
<p>In my next post I will translate this list into code changes service providers and library developers should make in order to align their code with this new draft. We plan to point visitors to the <a href="http://oauth.net">http://oauth.net</a> site to the new draft shortly, and would like to give developers some time to familiarize themselves with these changes.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/ywoAzFOkPwg" height="1" width="1"/>0http://hueniverse.com/2009/12/oauth-1-0-rfc-edition/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Stuff I didn’t Get to Write About]]>http://hueniverse.com/?p=9792009-11-29T07:37:38Z2009-11-29T13:00:49Z<p><a href="http://www.metalinker.org/"><img class="alignright size-full wp-image-982" title="Metalink" src="http://hueniverse.com/wp-content/uploads/2009/11/Metalink.png" alt="Metalink" width="198" height="61" />Metalink</a> is a document format for file download metadata. If you ever downloaded a large file or a LINUX distribution, you probably used a download manager. These are useful applications which help deal with the problems of downloading large files over sometimes unreliable networks. What Metalink does is help clients find the best place to grab a file from, and recover when needed. The <a href="http://groups.google.com/group/metalink-discussion">community behind Metalink</a> decided to publish their work as an <a href="http://tools.ietf.org/html/draft-bryan-metalink">IETF specification</a>, which is now pending Last Call. Feedback is always appreciated.<span id="more-979"></span></p>
<p>Two weeks ago the <a href="http://openwebfoundation.org">Open Web Foundation</a> reached its first non-bureaucratic milestone, the <a href="http://ycorpblog.com/2009/11/17/owf/">release of the Open Web Foundation Agreement 0.9</a>. The <a href="http://openwebfoundation.org/legal/agreement/">agreement</a> is the first building block created to help open web communities reach wider adoption by putting their work on sound legal grounds. The next steps are to form a <a href="http://groups.google.com/group/open-web-discuss/browse_thread/thread/9acc07a570a2da70">new legal affairs committee</a> and get going on <a href="http://hueniverse.com/2009/03/explaining-the-open-web-foundation-new-kind-of-legal-framework/">creating a Contributor License Agreement</a> (CLA).</p>
<p><a href="http://www.johnpanzer.com/">John Panzer</a>, one of my favorite collaborators, came up with a cool new protocol with a simple mission: get comments back to where they belong, where the content originally came from. <a href="http://www.salmon-protocol.org/">Salmon</a> is a new proposal for aggregators and other content sharing sites to feed comments left locally back to the original source. This will help reduce the problem of fragmented conversations and the lack of long term access to the community distributed conversation. And its using the <a href="http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux/">discovery stack</a>.</p>
<p>HTML5 started as a gigantic effort to “fix the web”. That included everything needed to make developing web applications predictable and consistent across browsers and other clients (e.g. search engines). One of these items is dealing with the somewhat broken state of <a href="http://en.wikipedia.org/wiki/HTTP_cookie">cookies</a>. This piece of the puzzle is now being proposed as an <a href="http://www.ietf.org/mail-archive/web/http-state/current/msg00297.html">IETF working group called HTTP-State</a>. They have a proposed charter and looking for feedback.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/vFXhiJ4M0bA" height="1" width="1"/>0http://hueniverse.com/2009/11/stuff-i-didnt-get-to-write-about/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Weekly Recap: XRD, OAuth, New Drafts, and We’re Back!]]>http://hueniverse.com/?p=9772009-11-28T21:09:06Z2009-11-28T21:09:06Z<p>We are back to our normal programming schedule.</p>
<p>The week started with a look at the OAuth community, the <a href="http://hueniverse.com/2009/11/wrap-and-the-demise-of-the-oauth-community/">new WRAP protocol</a>, and plans for <a href="http://hueniverse.com/2009/11/planning-for-oauth-2-0/">OAuth 2.0</a>. We reviewed the <a href="http://hueniverse.com/2009/11/xrd-alignment-with-link-syntax/">recent changes to XRD</a>, the <a href="http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux/">discovery protocol stack</a> (aka the Hammer Stack), and compared machine discovery to <a href="http://hueniverse.com/2009/11/how-we-interact-with-the-unknown/">how people interact with the unknown</a>. And we examined the <a href="http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/">new host-meta proposal and redesigned Well-Known URI specification</a>.<span id="more-977"></span>There is a lot going on across the many specifications and communities I am involved in, including the Open Web Foundation. It has been hard to keep up with everything, but as these efforts are reaching a stable state, it is time to resume normal blogging. The <a href="http://hueniverse.com/2009/11/a-little-bit-of-housekeeping/">new post labeling system</a> should help with staying up to date.</p>
<p>The main focus of the next few weeks is going to be getting OAuth 2.0 into a draft state. The IETF working group is working on two separate but related specifications, one dealing with authentication and the other with authorization. I hope to get the authentication part done first and quickly.</p>
<p>Also, if you are working on an Open Web specification or community, and would like to reach the audience of this blog, please let me know. I got a few new guest writers lined up for the next few weeks.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/tlAhPYpkS6k" height="1" width="1"/>0http://hueniverse.com/2009/11/weekly-recap-xrd-oauth-new-drafts-and-were-back/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[A Little Bit of Housekeeping]]>http://hueniverse.com/?p=9622009-11-26T20:25:49Z2009-11-26T20:20:31Z<p>The articles on this site tend to be very technical and represent the very latest in Open Web technologies. This means they are often obsolete and include incorrect information shortly after being posted. At the same time, people link to specific articles from tutorials and documentation which can be very confusing for those new to the many technologies covered.<span id="more-962"></span>To make things easier, and without taking away from the integrity of the article archive, I have decided to add four kinds of disclaimers to technical posts when they becomes out-dated:</p>
<ul>
<li><strong>Updated by another post</strong> – the content of the post has been updated by another, more recent post. Readers should simply ignore the older version and read the newer post. For example, <a href="http://hueniverse.com/2009/03/xrd-sneak-peek/">XRD Sneak-Peak</a>.</li>
<li><strong>Obsolete </strong>- the post is no longer accurate and should not be relied upon for implementations. For example, <a href="http://hueniverse.com/2009/03/xrd-based-oauth-discovery-sneak-peek/">XRD-Based OAuth Discovery Sneak-Peek</a>.</li>
<li><strong>Content updated</strong> – in cases when a few small changes can bring the post back to the forefront, usually in its examples, the post will be updated directly with a note indicating what has changed and the last time it was updated. For example, <a href="http://hueniverse.com/2009/09/openid-and-lrdd/">OpenID and LRDD</a>.</li>
<li><strong>Moving target</strong> – some posts are used to reflect the most recent changes to a specification in progress. In such cases, the post will be marked as a moving target until no additional changes are expected. For example, <a href="http://hueniverse.com/2009/09/implementing-webfinger/">Implementing WebFinger</a>.</li>
</ul>
<p>Hope you find this new system useful and as always, feedback is appreciated.</p>
<p>Happy Thanksgiving!</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/M37U5eRJCew" height="1" width="1"/>0http://hueniverse.com/2009/11/a-little-bit-of-housekeeping/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[XRD Alignment with Link Syntax]]>http://hueniverse.com/?p=8892009-12-24T22:38:39Z2009-11-25T23:57:23Z<p><a href="http://hueniverse.com/xrd/">XRD</a> is a simple generic format for describing resources. Unlike past attempts, this time we got it right, and truly deliver on the promise of simple. In fact, the XRI TC spent the past year throwing features out if they were not supported by well-established use cases. Last month the specification reached the important milestone of a <a href="http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html">Committee Draft</a> and was opened for <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri#feedback">public comments</a>.<span id="more-889"></span>While public review is open until January 6th (and we <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri#feedback">encourage feedback</a>), we decide to publish a <a href="http://www.oasis-open.org/committees/download.php/35274/xrd-1.0-wd10.html">new working draft</a> to address comments we already reach consensus on to help early adopters. The new draft, which the TC feels would be our last schema change, addresses all the comments received so far, but focuses on two comments:</p>
<ul>
<li>The use of a new structure for the <strong><Link></strong> element and its deviation from common practice (i.e. ATOM, HTML, XHTML).</li>
<li>The limited and confusing nature of the <strong><Type></strong> element.</li>
</ul>
<p>The new draft converts most of the <strong><Link></strong> child elements to attributes, and replaces the <strong><Type></strong> element with a <strong><Property></strong> element capable of expressing key/value pairs. I would like to thanks <a href="http://blog.unto.net/">DeWitt Clinton</a> and James Manger for their useful feedback.</p>
<p>An example XRD (updating the <a href="http://hueniverse.com/2009/03/xrd-sneak-peek/">previous sneak-peak</a>):</p>
<pre class="brush: xml;">
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://blog.example.com/article/id/314</Subject>
<Alias>http://blog.example.com/cool_new_thing</Alias>
<Expires>2010-01-30T09:30:00Z</Expires>
<Property type='http://blgx.example.net/ns/version'>1.2</Property>
<Property type='http://blgx.example.net/ns/ext'>lang</Property>
<Link rel='author' type='text/html'
href='http://blog.example.com/author/steve'>
<Title xml:lang='en-us'>Author Information</Title>
</Link>
</XRD>
</pre>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/ALn097J0PkU" height="1" width="1"/>6http://hueniverse.com/2009/11/xrd-alignment-with-link-syntax/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[How We Interact With the Unknown]]>http://hueniverse.com/?p=8642009-11-30T08:28:12Z2009-11-25T01:12:11Z<p><img class="alignleft size-full wp-image-880" style="margin-left: 10px; margin-right: 10px;" title="Human Arm" src="http://hueniverse.com/wp-content/uploads/2009/11/Human-Arm.png" alt="Human Arm" width="127" height="156" /><img class="alignright size-full wp-image-879" title="Robot Arm" src="http://hueniverse.com/wp-content/uploads/2009/11/Robot-Arm1.png" alt="Robot Arm" width="150" height="137" />Discovery discussions tend to be very technical and detail-oriented. I have been looking for ways to explain how the basic elements in my discovery proposals are based on simple concepts taken directly from how humans interact with the unknown. Our brain is nothing but a big pattern-matching machine, and machine discovery works in a very similar way.</p>
<p>The basic idea is that discovery is the combination of three concepts:</p>
<h4 style="text-align: center;"><strong>Discovery = Patterns + Interfaces + Descriptors<span id="more-864"></span></strong></h4>
<p style="text-align: left;">The following presentation explains these concepts as they apply to human interaction. The same concepts are found in XRD, LRDD, and pretty much any discovery protocol.</p>
<p style="text-align: center;"><object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="425" height="318" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowFullScreen" value="true" /><param name="allowScriptAccess" value="always" /><param name="flashVars" value="s=aT03MjMxMzk1NTUmaz1raUQ4aCZhPTEwNDI4ODk0X1FtOWpSJnU9SGFtbWVyLUxhaGF2JmU9MQ==" /><param name="src" value="http://hammer-lahav.net/ria/ShizVidz-2009090604.swf" /><param name="flashvars" value="s=aT03MjMxMzk1NTUmaz1raUQ4aCZhPTEwNDI4ODk0X1FtOWpSJnU9SGFtbWVyLUxhaGF2JmU9MQ==" /><param name="allowfullscreen" value="true" /><embed type="application/x-shockwave-flash" width="425" height="318" src="http://hammer-lahav.net/ria/ShizVidz-2009090604.swf" flashvars="s=aT03MjMxMzk1NTUmaz1raUQ4aCZhPTEwNDI4ODk0X1FtOWpSJnU9SGFtbWVyLUxhaGF2JmU9MQ==" allowscriptaccess="always" allowfullscreen="true"></embed></object></p>
<p style="text-align: left;">The full size video (which is easier to view) can be found <a href="http://hammer-lahav.net/Other/Work/10428894_Qm9jR#723139555_kiD8h-A-LB">here</a>. Due to the amount of animation in this presentation and special fonts, I am not sharing the PowerPoint document at this point.</p>
<p style="text-align: left;">Illustrations by <a href="http://chriscarrasco.tripod.com/">Christopher Carrasco</a>. Fonts used are High Fiber, Segoe Script, and Yank.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/UGYWL3uFlf4" height="1" width="1"/>5http://hueniverse.com/2009/11/how-we-interact-with-the-unknown/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[The Discovery Protocol Stack, Redux]]>http://hueniverse.com/?p=8572009-11-26T00:16:41Z2009-11-24T19:52:25Z<p>What started as a small, simple specification ended up spread over 5 (and counting) documents. Given that these are still moving targets, at least for a little bit longer, it can get very confusing for people trying to follow this work. A few months ago I wrote about the <a href="http://hueniverse.com/2009/03/the-discovery-protocol-stack/">new discovery stack</a> which included <a href="http://hueniverse.com/xrd/">XRD</a>, LRDD, and the three links. Since then, the design has changed to include new components and some shuffling of the existing ones.<span id="more-857"></span></p>
<p style="text-align: center;"><img class="size-full wp-image-858 aligncenter" title="Hammer Stack" src="http://hueniverse.com/wp-content/uploads/2009/11/Hammer-Stack.png" alt="Hammer Stack" width="354" height="345" /></p>
<p>The main components remain XRD, host-meta, and LRDD. They are slightly rearranged to move <a href="http://hueniverse.com/xrd/">XRD</a> lower in the protocol stack, as it no longer provides its own discovery flow, only a simply schema to describe resources. <a href="http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/">host-meta has been redefined and /.well-known added for the more generic use cases</a>. And last, <a href="http://hueniverse.com/2009/08/introducing-webfinger/">WebFinger</a> was added to present a more comprehensive picture of the discovery framework being discussed.</p>
<p>In addition, the latest draft of <a href="http://tools.ietf.org/html/draft-nottingham-http-link-header">Web Linking</a> removed the need to list the individual link locations (e.g. HTTP header, <Link> elements in HTML and ATOM). Web Linking is in its final standardization phase and will be covered by an upcoming post.</p>
<p>I am also working on reworking LRDD from a generic guide on linking to metadata, to a more restrictive protocol on finding specific links using linked XRDs and direct links. Stay tuned.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/1VePI0fFCuU" height="1" width="1"/>3http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux/Eran Hammer-Lahavhttp://hueniverse.com<![CDATA[Host-meta (aka Site-meta) and Well-Known URIs]]>http://hueniverse.com/?p=8522009-12-24T23:13:43Z2009-11-24T02:24:36Z<p><img class="alignleft size-medium wp-image-855" style="margin-left: 15px; margin-right: 15px;" title="host-meta" src="http://hueniverse.com/wp-content/uploads/2009/11/host-meta-194x300.png" alt="host-meta" width="101" height="157" />Over the past two weeks <a href="http://tools.ietf.org/html/draft-nottingham-site-meta">Well-Known URIs</a> (<a href="http://tools.ietf.org/html/draft-nottingham-site-meta">draft-nottingham-site-meta</a>) completed its last-call review at the IETF and is now pending IESG review before publication as an RFC. In addition, <a href="http://tools.ietf.org/html/draft-hammer-hostmeta">Host-meta</a> (<a href="http://tools.ietf.org/html/draft-hammer-hostmeta">draft-hammer-hostmeta</a>) was introduced to fill in the gap created by the recent revisions.</p>
<p>There is a lot of confusion about these drafts, not because they are complicated – they are pretty simple – but because of how they evolved and ended up solving different problems. It makes a good story for wannabe standards editors but that’s for another day.<br />
<span id="more-852"></span><br />
Well-Known URIs was originally proposed as ‘site-meta’, a well-known location document at the root of the domain, used as a registry of other metadata and policy documents:</p>
<blockquote><p>It is increasingly common for Web-based protocols to require the discovery of policy or metadata before making a request. For example, the Robots Exclusion Protocol specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences tells user-agents how to discover privacy policy beforehand.</p>
<p>While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV’s PROPFIND), the perceived overhead associated with them often precludes their use in these scenarios.</p>
<p>When this happens, it is common to designate a “well-known location” for such metadata, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated “well-known locations” and with pre-existing resources.</p>
<p>The idea was to create (one last) well-known location where all future documents will simply register and avoid the need to create more well-known documents. This was originally proposed as a new XML format but later changed to a simpler HTTP-header-like text-based format, and now, to a URI path prefix without any document format associated with it.</p></blockquote>
<p>The name site-meta was changed to host-meta to better reflect the scope of the metadata provided by the document. For many people, a site is functional term which often means multiple host names used together to provide a complete service. For example, <strong>http://twitter.com</strong> and <strong>http://search.twitter.com</strong> is considered by most people to be a single site, but two separate hosts. The term host is used as defined by <a href="http://tools.ietf.org/html/rfc3986">RFC 3986</a>.</p>
<p>As the proposal evolved, it became clear that it was not going to satisfy the needs of many protocols because it would have forced them to go through one more level of indirection (and having to deal with another file format) just to get to their metadata. Instead of creating a well-known location document, the proposal creates a directory under which future well-known location documents should reside.</p>
<p>It also establishes a registry to avoid name collisions within the <strong>‘/.well-known/’</strong> namespace. In addition, it added a <strong>‘.’</strong> character to the name to reduce the likelihood of conflicts with common username name-spaces in sites that allow users to use URI such as<strong> http://example.com/joe</strong> as their profile page.</p>
<p>The <a href="http://tools.ietf.org/html/draft-nottingham-site-meta">Well-Known URIs</a> proposal is currently pending IESG review and hopefully we be approved for publication as an RFC soon.</p>
<p>What also became clear during this process, is that there is a need for a metadata document about a host. The original idea for site-meta was to serve as a collection of links, but as we discussed more use cases, it became clear that we were also looking for a document to hold actual protocol metadata, not just point to it elsewhere.</p>
<blockquote><p>Web-based protocols often require the discovery of host policy or metadata, where host is not a single resource but the entity controlling the collection of resources identified by URIs with a common host as defined by RFC 3986. While these protocols have a wide range of metadata needs, they often define metadata that is concise, has simple syntax requirements, and can benefit from storing its metadata in a common location used by other related protocols.</p>
<p>Because there is no URI or a resource available to describe a host, many of the methods used for associating per-resource metadata (such as HTTP headers) are not available. This often leads to the overloading of the root HTTP resource (e.g. ‘<strong>http://example.com/</strong>‘) with host metadata that is not specific to the root resource (e.g. a home page or web application), and which often has nothing to do it.</p></blockquote>
<p>Another new feature of the <a href="http://tools.ietf.org/html/draft-hammer-hostmeta">host-meta proposal</a> is the use of <a href="http://hueniverse.com/xrd/">XRD</a> as the document schema. This simplifies the protocols looking to use it as they all already require the ability to parse XRD documents. For example, this simple host-meta document for the ‘<strong>example.com</strong>‘ and ‘<strong>www.example.com</strong>‘ hosts provides a link for host-wide copyright information and a link template providing a URI for obtaining resource-specific metadata for each resource within the host-meta document scope:</p>
<pre class="brush: xml;">
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:hm='http://host-meta.net/ns/1.0'>
<hm:Host>example.com</hm:Host>
<hm:Host>www.example.com</hm:Host>
<Link rel='license'
href='http://example.com/license'>
<Title xml:lang='en-us'>Site License Policy</Title>
</Link>
<Link rel='describedby'
template='http://meta.example.com?uri={uri}'>
<Title xml:lang='en-us'>Resource Descriptor</Title>
</Link>
</XRD>
</pre>
<p>The next step for <a href="http://tools.ietf.org/html/draft-hammer-hostmeta">host-meta</a> is to add a trust profile section which will handle with some security and authority issues common to many of the protocol looking to use it such as <a href="http://hueniverse.com/webfinger/">WebFinger</a>, <a href="http://www.salmon-protocol.org/">Salmon</a>, and OpenID. Since host-meta now includes many of the new features offered by <a href="http://hueniverse.com/2009/03/the-discovery-protocol-stack/">LRDD</a>, that specification will have to change as well.</p>
<img src="http://feeds.feedburner.com/~r/Hueniverse/~4/fNMeSKuMfbs" height="1" width="1"/>0http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/