當 ASP.NET 首次在 2002 年發布時，時代有所不同。 那時，Internet 仍處於起步階段，大約有 5.69 億用戶，每個用戶平均每天訪問 Internet 的時間為 46 分鍾，大約有 3 百萬個網站。 僅僅在 10 年之后，相同的測量指標揭示，大約有 22.7 億個 Internet 用戶，每個用戶平均每天訪問 Internet 的時間為 4 小時，大約有 5.55 億個網站。伴隨着網絡應用程序開發的不斷演進，ASP.NET也伴隨着產生了新的技術，比如ASP.NET MVC和ASP.NET WEB API。網絡應用程序開發的下一個方向是進入雲計算， Katana工程則為ASP.NET提供了基礎的模塊，使網絡應用程序變得更靈活、更輕量級、更容易移植以及擁有更好的性能 - 也就是說，Katana工程能夠優化你的asp.net程序。
Katana 項目實際可以追溯到 Microsoft 外部一個名為 Open Web Interface for .NET (OWIN) 的開放源代碼項目。OWIN 是一種定義 Web 服務器和應用程序組件之間的交互的規范（請參閱 owin.org）。 由於這一規范的目的是發展一個廣闊且充滿活力的、基於 Microsoft .NET Framework 的 Web 服務器和應用程序組件生態系統，因此它可以將服務器與應用程序之間的交互減少到一小部分類型和單個函數簽名，這個函數簽名被稱為應用程序委托（即 AppFunc）：
using AppFunc = Func<IDictionary<string, object>, Task>;
基於 OWIN 的應用程序中的每個組件都向服務器提供應用程序委托。 然后，這些組件鏈接成一個管道，基於 OWIN 的服務器將會向該管道推送請求。 為了更有效地使用資源，管道中的所有組件都應該是異步的，這體現在返回 Task 對象的應用程序委托中。隨着版本3的發布，Kanata目前已經完整地支持了.NET 4.5中新加入的異步編程模型。盡管ASP.NET從十年前就已經開始支持異步編程模型，但.NET 2.0中引入的IAsyncResult模型使用起來非常繁瑣，大多數開發者甚至都不知道它的存在。Node.js趁虛而入，它將自己稱為高級異步web開發平台，而微軟則希望通過在.NET 4.5中引入的async/await模型重新奪回這一稱號。
包括應用程序狀態、請求狀態和服務器狀態等在內的所有狀態都保存在應用程序委托上指定的 IDictionary<string, object> 對象中。 這種數據結構稱為環境字典，隨着請求通過管道時會從一個組件傳遞到另一個組件。 雖然任何鍵/值數據都可以插入到環境字典中，但 OWIN 規范為某些 HTTP 核心元素定義了鍵.
HTTP 請求的必需環境字典鍵
| 鍵名稱 | 值說明 |
| "owin.RequestBody" | 一個帶有請求正文（如果有）的流。如果沒有請求正文，Stream.Null 可以用作占位符。 |
| "owin.RequestHeaders" | 請求標頭的 IDictionary<string, string[]> |
| "owin.RequestMethod" | 一個包含請求的 HTTP 請求方法的字符串（例如 GET 和 POST）。 |
| "owin.RequestPath" | 一個包含請求路徑的字符串。 此路徑必須是應用程序委托的“根”的相對路徑。 |
| "owin.RequestPathBase" | 一個字符串，包含對應於應用程序委托的“根”的請求路徑部分。 |
| "owin.RequestProtocol" | 一個包含協議名稱和版本的字符串（例如 HTTP/1.0 或 HTTP/1.1）。 |
| "owin.RequestQueryString" | 一個字符串，包含 HTTP 請求 URI 的查詢字符串組成部分，不帶前導“?”（例如 foo=bar&baz=quux）。 該值可以是空字符串。 |
| "owin.RequestScheme" | 一個字符串，包含用於請求的 URI 方案（例如 HTTP 或 HTTPS）。 |
定義一組基本的環境字典鍵/值對，使得許多不同的框架和組件作者可以在一個 OWIN 管道中進行互操作，而不必強制實施對特定 .NET 對象模型的協議，例如針對 ASP.NET MVC 中的 HttpContextBase 或 ASP.NET Web API 中的 HttpRequestMessage/HttpResponseMessage 的協議。
應用程序委托和環境字典這兩個元素構成了 OWIN 規范。 Katana 項目是 Microsoft 創建和推出的基於 OWIN 的組件和框架集合。
在新的功能特性方面，新版本主要關注於“企業級認證功能以及基於聲明的標識（claims-based identity）”。參與了Katana 3項目的Vittorio Bertocci特別提到了以下三種協議：
- WS-Federation
- OpenId Connect (通過表單提交方式提供id_token以及id_token+code方式)
- 可在Web API中使用的OAuth2票據令牌認證
Vittorio還寫道：
這個版本的發布還解決了由於Twitter和Google API發生變動所引起的問題。如果你在應用中使用了Google認證，並且打算升級到Katana版本3，請確保你已讀過這篇帖子！
Katana可以作為NuGet包獲得。根據Katana網站描述顯示，取決於你所需的不同特性，共有總數超過20的包可以選擇下載：（這一點和傳統的ASP.NET形成了鮮明的對比，后者的方式是將幾乎所有特性都堆積在一個龐大的程序集中。）
- Microsoft.Owin – 提供了一組輔助類型，以及為簡化創建OWIN組件而建的各種抽象類型。
- Microsoft.Owin.Diagnostics – 提供了各種中間件組件，以輔助開發基於OWIN的應用程序。
- Microsoft.Owin.FileSystems – 這個包里提供了文件系統相關的抽象與實現。
- Microsoft.Owin.Testing – 提供了對OWIN組件進行單元測試的一些輔助類。
- Microsoft.Owin.SelfHost – 包含了為在自行指定的進程中托管基於OWIN的應用程序所必需的一些組件。
- Microsoft.Owin.Hosting – 提供了托管與運行基於OWIN的應用程序所需的默認基礎框架類型。
- OwinHost – 提供了一個單獨的可執行程序（OwinHost.exe），通過它可以托管一個基於OWIN的應用程序的運行。
- Microsoft.Owin.Cors – 這個包里包含了一些能夠在OWIN中間件中進行跨域資源共享（CORS）的組件。
- Microsoft.Owin.StaticFiles – 這個包里包含了一些OWIN中間件，能夠處理來自於文件系統資源的請求，包括文件與目錄。
- Microsoft.Owin.Security – 包含了一些各種不同的認證中間件組件所共享的 通用類型。
- Microsoft.Owin.Security.ActiveDirectory – 一組允許應用程序使用微軟技術進行認證的中間件。
- Microsoft.Owin.Security.Cookies – 允許應用程序使用基於cookie進行認證的中間件，類似於ASP.NET中的表單認證方式。
- Microsoft.Owin.Security.Facebook – 允許應用程序支持Facebook所使用的OAuth 2.0認證工作流的一些中間件。
- Microsoft.Owin.Security.Google – 包含了一組支持Google的OpenId及OAuth 2.0認證工作流的中間件。
- Microsoft.Owin.Security.Jwt – 一組允許應用程序保護及驗證JSON Web令牌的中間件。
- Microsoft.Owin.Security.MicrosoftAccount – 一組允許應用程序支持微軟帳號認證工作流的中間件。
- Microsoft.Owin.Security.OAuth – 允許應用程序支持任何標准OAuth 2.0認證工作流的中間件。
- Microsoft.Owin.Security.OpenIdConnect – 允許應用程序使用OpenIdConnect方式進行認證的中間件。
- Microsoft.Owin.Security.Twitter – 允許應用程序支持Twitter的OAuth 2.0認證工作流的中間件。
- Microsoft.Owin.Security.WsFederation – 允許應用程序使用WsFederation進行認證的中間件。
- Microsoft.Owin.Host.HttpListener – 基於.Net Framework中的HttpListener類創建的OWIN服務器，也是目前用於自托管的默認服務器。
- Microsoft.Owin.Host.SystemWeb – 也是OWIN服務器實現，但它允許基於OWIN的應用程序運行在IIS中，並能夠使用ASP.NET的請求管道。