Web 2.0との潮流の中で、Webアプリケーションを開発する際に、いわゆる「マッシュアップ」が卑近に行われるようになってきている。「マッシュアップ」という用語は、音楽DJが複数の楽曲を組み合わせて新たな音楽を創造する過程になぞらえて、ソフトウェアをAPI呼び出しによって組み合わせて構成することを表現するようになっている。このような「マッシュアップ」を行う際のセキュリティに関する論点を扱うWGが、インターネットの標準化団体：IETF（Internet Engineering Task-Force）において発足しており、Websec WGという。
　また、アイデンティティ管理技術を構成する専用のプロトコル（OAuth 2.0等）において、時流を反映してJavaScriptで書くJWT（Json Web Token）を用いるクレデンシャル仕様が規定されるようになってきている。
　本稿においては、今期、IETFにおける、これらの動向を解説する。

(1) 概況

　Websecワーキンググループ（以下、WG）は、第78回IETF（Maastricht）において開催されたHASMAT（HTTP Application Security Minus Authentication and Transport）BoF（Bird of Fether）が盛況であったことを受けて2010年10月に設置された新しいWGである。このように「Authentication（本人認証）」の論点は、当初から対象外とされていた。ただし、「HASMAT」という名前は、HASMAT（Hazardous Materials Response Team）と同様に発音されていたが、Webセキュリティとは異なる種類の畏れの念を起こさせることもあり、一般に伝え易く、かつ、他で使われていない名称として「Websec」に改名された。当初、Websec WGのチェアは、Tobias Gondrom氏のみであった。Gondrom氏は、かつてLTANS（Long-Term Archive and Notary Services）WGのチェアを勤めていた。ちなみにLTANS WGは、今年の7月をもって正式に終結した。当初から共同チェアも募集されていたが、今年4月からAlexey Melnikov氏が共同チェアとなった。
　このWGは、W3Cと連携しており、Webアプリケーションセキュリティに関するプロトコルについての論点整理と、その中から選択された案件についての標準化を行う[1]。まず、論点整理は、下記のI-D（Internetr-Draft）に書かれている。これは、Informational RFCとして策定中である。

• “HTTP Application Security Problem Statement and Requirements”

　一方、具体的に選択された標準化案件は、下記の3件であった。これらすべては、Standards Track RFCとして策定中である。

• Webコンテンツについての源泉概念（Web Origin Concept）
• 厳密なトランスポートセキュリティ（Strict Transport Security）
• メディア種別の嗅ぎ分け（Media Type Sniffing）

(2) 論点整理：”Web Security Framework: Problem Statement and Requirements”

　今年3月に発行された00版のI-Dの目次構成は、下記のとおりであった。9月に発行された01版[2]においても目次構成は変わっていない。

目次 Introduction Document Conventions Overall Constraints Overall Requirements Attacks and Threats to Address Use Cases Detailed Functional Requirements Extant Policies to Coalesce Example Concrete Approaches Security Considerations (To Be Determined) References Informative References

　まだ、詳細は書き込まれていないが、8章の見だしに見られるように、現存している複数の対策技術仕様のポリシーを合体する（Coalesce）アプローチが行われている。01版において対策技術仕様としては下記のものが掲げられている。

• CORS（Cross-Origin Resource Sharing）
• XDomainRequest
• toStaticHtml
• innerSafeHtml
• X-Frame-Options
• CSP（Content Security Policy）frame-ancestors

(3) 選択された標準化案件

　選択された標準化案件について、該当Webページの不備によって複数のI-Dの最新版がリンクされていない状態になってしまっている。また、紛らわしいことに同一名称の文書が複数、存在することになってしまった。それらの所在を明確にすると共に概説する。

Webコンテンツについての源泉概念（Web Origin Concept）
　同一源泉ポリシー（Same origin policy）の標準化は、源泉の判定ルールを規定するものであるが、これはW3CのHTML5に由来する。この案件については、紛らわしいことに、ふたつのI-D文書が並存していた。

• 　draft-abarth-origin-
  こちらは、informational RFCとするとされたが、結局、更新されなかった。


• 　draft-ietf-websec-origin-
  こちらがwebsec WGによるものとされた。02版[3] が6月に発行され、その後も更新され続けている。

   

  注： 2011年12月に RFC 6454 として発行された。（日本語訳）

厳密なトランスポートセキュリティ（Strict Transport Security）
　STS（Strict Transport Security：厳密なトランスポートセキュリティ）も@ W3Cに由来する案件である。この案件は、途中でファイル名の番号部分以外も変更されているので、追跡する際には注意を要する。

• 　draft-hodges-strict-transport-sec-
  02版の後、下記のようなファイル名に変更された。


• 　draft-ietf-websec-strict-transport-sec-
  00版から再開し、01版[4] が3月に発行され、更新され続けている。

メディア種別の嗅ぎ分け（Media Type Sniffing）
　これは、HTTPレスポンスのメディア種別について、セキュリティと互換性の両方のバランスを図りつつ実質的に判定するアルゴリズムを規定する案件である。この案件についても、途中でファイル名の番号部分以外も変更された。

• 　draft-abarth-mime-sniff-
  06版まで更新された後、下記のようなファイル名に変更された。


• 　draft-ietf-websec-mime-sniff-
  上記の06版と、この00版は、同一の内容のものである。03版[5] が5月に発行され、更新され続けている。

HTTP Header Frame Options等
　CSRF（Cross Site Request Forgery：リクエスト強要）やClickjackingに対する対策仕様として、サーバからブラウザにヘッダー中に渡されるポリシーに基づく制御方法の規定についてもI-Dが草稿され始めて、3月には01版[6] が発行された。

• 　“HTTP Header Frame Options”
  draft-gondrom-frame-options

　このような制御に用いるヘッダー項目の仕様には同様ながら別の仕様も策定されつつあり、代表的なものとして、W3Cには下記のふたつの案件がある。技術仕様の状況を整理する必要性が認識されつつある。

• 　“The From-Origin Header” or “Cross-Origin Resource Embedding Exclusion”
  http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
• 　“Content Security Policy”

　CSP（Content Security Policy）は、Gecko 2.0系のブラウザによる実装が先行してきたが、W3Cにおいても検討されている。

(1) JWT（JSON Web Token）とは

　JSONは、JavaScript Object Notationのアクロニムであり、データ記述言語である。2006年7月にRFC 4627 [7]として規定されている。JSON仕様は、YAML（YAML Ain't a Markup Language：JavaScript（ECMAScript）におけるオブジェクト表記法）の部分でもある。
　今期、アイデンティティ管理において、このJSON規格を用いたクレデンシャル仕様を規定する動向があり、このようなクレデンシャルはJWT（JSON Web Token）と呼ばれている。

• 　“JSON Web Token (JWT)”[8]

　JWT[8]は、符号化にbase64urlを使い、ディジタル署名が付されたり、オプションとして暗号化したりするものである。
　最近、このJWTが用いられるプロトコル仕様が策定されるようになった。代表的な例として、OAuth 2.0のBearer token仕様のひとつとして策定されつつあることが挙げることができる[9]。
　base64urlとは、base64に基づく符号化であり、RFC 4648, “The Base16, Base32, and Base64 Data Encodings”（の5章）中に規定されている。
　変更点は、通常のbase64が` +’と`/’を使用しているところに、それぞれ`-‘と`_’を使用する点のみである。これによってURLの記述が攻略されて意味が変わることがないように設計されている。

例： base64の場合ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ base64urlの場合ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

　また、JWTにおいてパディングを行うことは禁じられている。

(2) JSONを使う長所

　JSONによってアイデンティティ情報のようなデータを運ぶことの長所として、下記の事項が挙げられる。

• XMLを書く際のようにタグを覚えることが不要であるので簡単に書ける。
• 文字列を規則的に符号化することによってシリアライズされたひとかたまりのデータとなる。
• 特殊文字としてエスケープ処理する必要がある文字が少なく限定的である（「”」のみ）ので失敗が少なくなることを期待できる。
• ディジタル署名を付すことや暗号化することに問題が無いため、アイデンティティ情報を運ぶのに向いている。

　このような長所は、来たるHTML5の世代においても存続する見通しである。

(3) JWT（JSON Web Token）仕様

　JWTを規定するI-Dの04版[8] の目次構成は、下記のとおり。

目次 Introduction Terminology JSON Web Token (JWT) Overview JWT Claims JWT Header Rules for Creating and Validating a JWT Base64url encoding as used by JWTs Signing JWTs with Cryptographic Algorithms Unsigned JWTs IANA Considerations Security Considerations (To Be Determined) Open Issues and Things To Be Done (To Be Determined) References

　まだ、書かれていない章が多く、11章の「セキュリティについての考慮事項」についても埋まっていない。
　OpenIDの後継仕様やOAuth 2.0においても、JWTは採用される。OpenIDは、シングルサインオン用プロトコルであり、現行仕様は2.0であるが、次期仕様としてOpenID Artifact Binding/Connectが策定中であり、この中で採用される。一方、OAuth 2.0は、代理アクセス認可用プロトコルであるが、複数の「grant type（トークン公布種別）」というシステム構成パターンに対応するように仕様が規定されている。その「grant type」に、”JSON Web Token (JWT) Bearer Profile for OAuth 2.0” [9]という仕様が追加される。
　IETFにもWOES（Web Object Encryption and Signing）BOFのメーリングリストが設置され、検討が進められている。

(4) 他のJSON Web仕様

　OpenIDコミュニティには他のも暗号技術の「JSON Web *」機能として、JWS（JSON Web Signature）とJWE（JSON Web Encryption）があり、暗号技術以外の仕様として、SWD（Simple Web Discovery）も検討されている[10]。

以上

[1]	Websec WG 憲章（charter） http://tools.ietf.org/wg/websec/charters
[2]	“Web Security Framework: Problem Statement and Requirements” 00版（2011年3月7日） http://tools.ietf.org/html/draft-hodges-websec-framework-reqs-00
[3]	“Web Origin Concept” 02版（2011年6月24日） http://tools.ietf.org/html/draft-ietf-websec-origin-02
[4]	“Strict Transport Security” 01版（2011年3月14日） http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-01
[5]	“Media Type Sniffing” 03版（2011年5月7日） http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03
[6]	“HTTP Header Frame Options” 01版（2011年3月15日） http://tools.ietf.org/html/draft-gondrom-frame-options-01
[7]	RFC 4627, “The application/json Media Type for JavaScript Object Notation (JSON)”（2006年7月） http://tools.ietf.org/html/rfc4627
[8]	“JSON Web Token (JWT)” 04版（2011年3月30日） http://tools.ietf.org/html/draft-jones-json-web-token-04
[9]	“JSON Web Token (JWT) Bearer Profile for OAuth 2.0” 00版（2011年3月28日） http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00
[10]	Michael B. Jones, “The Emerging JSON-Based Identity Protocol Suite” （2011年4月27日） http://self-issued.info/papers/The_Emerging_JSON-Based_Identity_Protocols.pdf